Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
KVP <kapilpatel@yahoo.com> wrote: > How can we extract clock from bi-phase encoded data (3.072Mbps - > AES/EBU Data) using CLKDLL of Xilinx FPGA. The clock should be able to > adjust itself to any slight drifting of the bi-phase data. consider to use a external AES/EBU receiver, like Crystal CS8413/14. Using techniques like clock-shifting-DLL etc.. in a FPGA for an AES/EBU receiver is not a good idea: The clock for the audio samples must be very accurate. You will get bad THD & SN-ratio. WD --Article: 75326
Eric <swankoski@nrl.navy.mil> wrote: : OK, so I'm trying to synthesize a huge design. Just for quick : reference, the inferred macros are below: : HDL Synthesis Report : Macro Statistics : # Block RAMs : 112 ... : # Multipliers : 480 What part do you traget for? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 75327
Is this reliability data availible? Can I find it in your Xilinx Device Reliability Report? And still there is the question, if CPLDs might have a higher reliability than FPGAs. Falk "Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:BDA7AF5C.99DE%peter@xilinx.com... > Let's keep things in pespective. > Yes, "SRAM-based" FPGAs can be upset by random SEUs. But how likely is > this? > We at Xilinx have done extensive real-time tests with thousands of large > devices (XC2V6000) over more than a year, and here is a snapshot of the > result: > A device of Virtex-II 1000 complexity ( "1 million FPGA gates") is likely > to > pick up a functional error due to SEU roughly once per thousand years of > operation. > The much smaller XC2V40 is about twice the complexity of the largest CPLD, > and it would encounter a functional error once per 25000 years. > That's a pretty good MTBF. Better than the FIT rate of many other, even > passive, coponents. > Peter Alfke, Xilinx Applications > ===================== >> From: "Benjamin Todd" <benjamin.toddnospam@cern.ch> >> Organization: CERN - European Laboratory for Particle Physics >> Newsgroups: comp.arch.fpga >> Date: Fri, 29 Oct 2004 11:37:38 +0200 >> Subject: Re: CPLDs and Safety? Re: ASICs Vs. FPGA in Safety Critical >> Apps. >> >> Could you post a link to the original article? >> >> There are lots more concerns other than the reprogramming. One such >> thing >> is the effect of Single Event Upsets. >> For example, configuration bits of the FPGA/CPLD can be flipped by SEUs >> (even at sea-level this is more important than MTBF) making the logic you >> designed behave incorrectly. >> >> Of course mitigation techniques exist, such as Triple Mode Redundancy, >> (and >> Device read-back and reconfiguration for some devices) >> >> Having said that CPLDs are much smaller devices, often at higher internal >> voltages, hence don't have the same problems with MTTE. If your system is >> small enough, and can be made fully redundant to cover MTBF failures, >> CPLD >> would be my advice. >> >> You want to check out the IEC-61508 Standard, and the Xilinx Military >> applications page. >> (or http://lhc-mpwg-reliability.web.cern.ch/lhc%2Dmpwg%2Dreliability/) >> HTH >> Ben >> >> >> >> >> "Falk Salewski" <salewski@informatik.rwth-aachen.de> wrote in message >> news:2uee97F28fi9jU1@uni-berlin.de... >>> I am interested in safety for embedded applications. So I read this >> articels >>> dealing with "ASICs Vs. FPGA in Safety Critical Apps." posted around >>> 1996 >>> with great interest. >>> >>> People listed a lot of advantages of FPGAs, however the major problem >>> (related to safety) left was that the FPGA has to be reprogrammed at >>> each >>> power up. >>> >>> My question: isn't an CPLD a good solution for small safety critical >>> applications? >>> >>> Falk >>> ---------------------------------------------------------- >>> Chair of Computer Science XI >>> RWTH Aachen University >>> Germany >>> >>> >> >> >Article: 75328
> Does anyone know how to preserve the "wire" names in the netlist so > that it is wasy for debugging the netlist. I used dont_touch command > with net name , but I think this will reduce the logic optimization > by the tool.. what do u think There's no easy way if you want the best optimization. The signals connected to registers are usually preserved, but after that you're more or less at the mercy of the synthesis tool. If you absolutely need to get some signals preserved, I'm not sure dont_touch will help that much. Probably the best way is to bring internal signals to the top as output ports and ask DC not to optimize them away if they're not connected. I assume there must a flag for this somewhere, though I haven't really looked into it. We've pretty much given up on even trying to get a nice match and have formal equivalence check validate the correctness of the netlist. Yes, this makes netlist hacking extremely painful: just try to make sure your RTL is correct. :-) TomArticle: 75329
Hi, One of the boards I use expects a 3.3 regulated voltage. Unfortunately the plug for the board is also compatible with my laptop (~ 12V). I have killed one board this way. In the lab we avoid this by connecting the board and the power cube before connecting the power cube to the power strip. For all of our labs, we provide the UCF file for the project. The boards cost about the same price of a text book. Perhaps the students should own the board. Cheers, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 75330
Mark, Please go to the website, and look up the University program, and make contact with them. Austin Mark Levitski wrote: > Greetings Antti, > > We do have one ML300 and can easily get 5 units, we're a University - this > board is supposedly cheaper and we're not "phasing it out" for our > project.... :) I might be wrong. > > Thanks for any info you provide, I relay all these Newsgroups postings to > our group professor/leader and fellow PhD stuidents (without disclosing your > emails). > >Article: 75331
On Mon, 1 Nov 2004, zerang shah wrote: > I work at a university, and we just got a bunch of FPGA boards with > Spartan 2E's on them. It's like five weeks into the quarter, and > already 6 of 20 boards have died. I contacted tech support for the > board manufacturer, and it seems that the FPGAs have been "fried" on > all six of the bad boards, judging from the fact that both the onboard > voltage regulators and FPGAs both get really hot, and the power-on LED > fails to turn on. Looking at the boards very closely I see no signs of > physical mistreatment though. > > The boards are being programmed using jtag cables + iMPACT with > bitfiles created with Foundation. At first I thought that maybe a > backward jtag cable would fry the FPGA, but it turns out that's not > the case. Really I have no idea what people could be doing to these > boards. > > So here's my question: How do you fry an FPGA?? I guess running like > 50 volts through it would do the job, but I don't think the cause of > these failures is a malicious user. Is there anyway to "accidentally" > synthesize a design that causes an FPGA to destroy itself??? > > Thanks for the help. > With my first attempt at VHDL about ten years ago, I inadvertantly instantiated two logic blocks to try to drive the same pin. I cooked two chips before finding the contention. This, however, was with a very rudimentary VHDL compiler with very little sanity checking. KeithArticle: 75332
Time borrowing is a concept that is used in latch based pipelines in which you typically have 2 stages of combinatorial surrounded by latches. If the first combinational piece of logic has a much longer delay than the second one, you can borrow some of the time of the second part to the first part. A somewhat more comprehensive explanatation can be found here: http://www.synopsys.com/products/logic/design_comp_tb.html Search for 'borrowing'... We have used this technique in FF based design where we captured the output of a RAM that was too slow to finished in a clock cycle and then registered it with FF's in a later stage. The use of latches in standard FF based design kills regular scan-based testing, so these technique should be used with great care! Since these latches aren't used a lot these day, my guess is that you unintentionally added latches to your design and this resulted in the warning above. If this is the case, just remove them and the warning will be gone. :-) TomArticle: 75333
Just an idea: could it be that you set the accuracy of the verilog simulator to 1 ns? In this case, all timings will be rounded up to a multiple of 1 ns... TomArticle: 75334
Eric wrote: > OK, so I'm trying to synthesize a huge design. Just for quick > reference, the inferred macros are below: > > HDL Synthesis Report > > Macro Statistics > # Block RAMs : 112 > # Multipliers : 480 > # Registers : 13434 > # Multiplexers : 1070 your design is two huge to be put in only one FPGA ... You will need to split your desing in more FPGAs. LaurentArticle: 75335
"Eric" <swankoski@nrl.navy.mil> wrote in message news:84d8efa2.0411020557.78be0f2e@posting.google.com... > OK, so I'm trying to synthesize a huge design. Just for quick > reference, the inferred macros are below: > "ERROR: Portability:3 - This Xilinx application has run out of memory > or has encountered a memory conflict..." most Xilinx errors are in the "Portability" DLL :( usually such error means you need to wait for next Service pack. or the next one, etc.. 2.5Gb is not enough :( I guess you are targetting VP100 not sure if more memory solves the problem, users with 3GB RAM have seen the same error even with VP70 Xilinx is "commited" to fix all fatal errors, such as yours, so just go start complaining! open webcase etc.. AnttiArticle: 75336
Hi Allan, Good points but, playing Devil's advocate, with just one address/control bus, there's only half as many signals to worry about. Duplicating the busses, you start eating up board area, lengthening the traces, making the problem worse than if you just placed the two DIMMs right next to each other on the same short bus. So, I vote for one bus. Especially as the DDR SDRAM data sheets are full of apps notes telling you how to do it! Cheers, Syms. p.s. If you're really worried, I believe Xilinx will tell you about the trace lengths in the BGA package substrate to include in your simulations. "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:g9heo0d68i44rl387ke5gahitnmnid6loh@4ax.com... > On Tue, 2 Nov 2004 09:12:11 +0100, "Quinn" > <quinn_the_esquimo@freenet.de> wrote: > > It will soon become apparent that a simple "point to point" connection > can be made to work at speeds up to several hundred MHz without too > much pain, but things are a little harder if you have multiple loads. > The signal will take longer to settle, and this will eat into your > timing margin. > > I assume that you will be using a clock of >= 200MHz, which means that > your timing margin is probably less than 1ns. > > Also, when simulating, don't forget to take the DIMM tracks into > account. You care about the signal quality at the chip pins, not the > DIMM pins. > > Regards, > AllanArticle: 75337
hmurray@suespammers.org (Hal Murray) wrote in message news:<cNmdnRwJMaA2TBvcRVn-uA@megapath.net>... > >I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. > >There appear to be some third party offerings. One may easily write > >one that does the job with sed (less than 10 lines). > > Standard cpp works fine. Everything gets much saner if you have a makefile. Hal, Thanks for the tip. I'll have to try it out sometime. My sed trick worked OK for small design differences, but it raised a few eye-browses because it was so ad-hoc. NewmanArticle: 75338
"Symon" <symon_brewer@hotmail.com> wrote in message news:2uprjlF2ectrlU1@uni-berlin.de... > Hi Allan, > Good points but, playing Devil's advocate, with just one address/control > bus, there's only half as many signals to worry about. Duplicating the > busses, you start eating up board area, lengthening the traces, making the > problem worse than if you just placed the two DIMMs right next to each other > on the same short bus. [snip] I'd agree with the single address/control bus as well if the two modules are placed next to each other as are typical dual-DIMM systems. The only difference here is that the bank selects are common to both modules rather than separate and there are twice the number of byte lanes. Otherwise, all dual-DIMM issues still apply. Different clocks go to the different modules so there is 1 load per clock. A preload of the address/control bus may be helpful. Check out the Micron app notes for DDR DIMMs and you'll see the issues that need to be addressed for using two DIMMs. If the board is too crowded with 16 bytes lanes going through 2 DIMMs (which does sound agressive) then the separate address/control for the separate modules would be helpful for DIMMs that aren't parallel.Article: 75339
Hi all, Is there any tutorial on web, where I can learn about working and architecture of FPGA and CPLD? Google turned out to be useless. Someone out there maybe is having some helpful pointer. Any suggestion regarding reference/text books is also appreciated. TIAArticle: 75340
I am working on project on ML310 board with Virtex 2 Pro There is a AES encryption that was converted to verilog from Systemc for usage. How do i callup and integrate this to C application i am developing in EDK?? Thanks in Advance Cheers ShakithArticle: 75341
What's the best way to get the Xilinx libs like Unisim working for simulating a design in FPGA Advantage 6.1? I got it working before, but I have no idea what I did last time, and I need to set it up again. Also, if I just comment out the library-related statements, should it synthesize properly in Precision? And is it possible to synthesize IP from the Xilinx EDK in anything but XST? Thanks, MikeArticle: 75342
Alan Fitch wrote: > > Something that is locally static can have its value determined purely > during analysis of that design unit, it doesn't require elaboration > of the complete design hierarchy. > > The standard defines static and locally static in section 7.4. Thanks. It says a function call has to be an "implicitly defined operator", which I can't find a meaning for. > It does look to me as though XST may be correct, as it says that > a constant is only locally static if it is initialized by a locally > static primary (which doesn't include a function call). It doesn't include the word "primary", just initialized by a locally static expression. > I don't understand what your TO_INTEGER function does, sorry :-( It just converts and array of three integers to another integer by treating them as exponents of 2 and summing them. The binary number 11010 could be represented as (1, 3, 4) which would be evaluated as 26 decimal. This was just to allow me to input my info in the form it was already in. Not a biggie, I have already fixed it by making it an expression. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75343
zerang shah wrote: > I work at a university, and we just got a bunch of FPGA boards with > Spartan 2E's on them. It's like five weeks into the quarter, and > already 6 of 20 boards have died. I contacted tech support for the > board manufacturer, and it seems that the FPGAs have been "fried" on > all six of the bad boards, judging from the fact that both the onboard > voltage regulators and FPGAs both get really hot, and the power-on LED > fails to turn on. Looking at the boards very closely I see no signs of > physical mistreatment though. > > The boards are being programmed using jtag cables + iMPACT with > bitfiles created with Foundation. At first I thought that maybe a > backward jtag cable would fry the FPGA, but it turns out that's not > the case. Really I have no idea what people could be doing to these > boards. > > So here's my question: How do you fry an FPGA?? I guess running like > 50 volts through it would do the job, but I don't think the cause of > these failures is a malicious user. Is there anyway to "accidentally" > synthesize a design that causes an FPGA to destroy itself??? > > Thanks for the help. One way to blow up a device is to try to download a bitstream that is targeted to a different device, like loading a 2s50 bitstream into a 2s200 part. Here's the link: http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=8436 Not that likely in a strict design environment, but I could see it happening quite often in a classroom setting. Notice this is no longer an issue for Virtex-II(Spartan-3) and later devices. HTH, Mike -- -- -- Please ignore the reply to address, and use -- mike -dot- peattie -at- xilinx -dot- com --Article: 75344
What does this mean? Maximum output required time after clock: 6.060ns Is this the time required for the clock edge at the pin to some register inside the fpga or from the edge to some signal at an output pin or something else? b r a dArticle: 75345
Phil Short wrote: > On Mon, 01 Nov 2004 00:32:27 -0500, rickman wrote: > >>Yes, but I explained how in a real time system, this only moves the >>problem from the clock domain to the system domain. Your chip can run >>at faster speeds when it is cooler or just a faster chip (process) but >>that won't be of any value since you have to design your system to the >>worst case chip delay. >> > > I wasn't talking about the system domain. You are correct in hinting that > there are significant problems interfacing between sync and async chips, > such that the literature suggests that most of the speed benefits of async > design may be lost in this case. It seems that it would be better if > everything in the system is async, rather than a mix. Just another > problem in gaining more widespread acceptance. Although risking pouring petrol on the embers of this discussion, the following might be of interest: ARM And Philips' Handshake Solutions Collaborate To Develop Clockless Processor http://www.arm.com/news/6936.html Regards, JohnArticle: 75346
John Williams wrote: <snip> > Although risking pouring petrol on the embers of this discussion, the > following might be of interest: > > ARM And Philips' Handshake Solutions Collaborate To Develop Clockless > Processor > > http://www.arm.com/news/6936.html Yes, that was the trigger to this thread, first noted by Symon on 28 Oct. Some silicon should appear in 2005, and then 'like process' comparisons can be made. It could be that this will be used for Async versions of the ARM-Cortex, ( http://www.arm.com/news/6750.html ) which would make 'like core' comparisons harder :) -jgArticle: 75347
Jim Granville wrote: > John Williams wrote: > <snip> > >> Although risking pouring petrol on the embers of this discussion, the >> following might be of interest: >> >> ARM And Philips' Handshake Solutions Collaborate To Develop Clockless >> Processor >> >> http://www.arm.com/news/6936.html > > > Yes, that was the trigger to this thread, first noted by Symon on 28 Oct. Oh no, I've triggered thread-recursion - prepare for a usenet meltdown! :) JohnArticle: 75348
>Looking at mail from other people and their expierence with that board, >I guess, I'm pretty happy without ;-) > I prefer to purchase through NuHorizons because our sales person takes good care of us by getting us samples quickly with the least amount of hassle. He has introduced us to great devices like the smsc 91c111 ethernet chip, ST line of small CPU's and Micrel's single chip MICRF505 radio transceiver, all of which are doing well for us. Because of NuHorizons good support when I decided to divest into FPGA the Xilinx line was a obvious choice and I purchased one NuHorizons HW-AFX-SP3-400-DB board and one Xilinx Spartan 3 Starter kit, both of which were in stock, delivered very quickly and worked out of the box. Both of the kits are relatively easy to use even though the Xilinx kit came with printed documentation. The world is changing and customer service is not what it used to be and people who work at companies act like they would rather be somewhere else but still get paid for it. NuHorizons has treated my company and I well for over two years and I prefer to work with them given my options. The NuHorizons Xilinx 3 evkit is a valuable and interesting design resource at a unbeatable price. That is my experience. Richard Newman PST Precision Design Allentown PA USAArticle: 75349
Mike, > One way to blow up a device is to try to download a bitstream that is > targeted to a different device, like loading a 2s50 bitstream into a > 2s200 part. Here's the link: > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=8436 > > > Not that likely in a strict design environment, but I could see it > happening quite often in a classroom setting. Notice this is no longer > an issue for Virtex-II(Spartan-3) and later devices. Can the same thing happen if I use the correct device, but the device does not successfully program? I have a particularly high programming failure rate with XST 6.2.02i. The parallel port programming cable is thin and it is right next to the power cord on the laptop, so there may be some noise issues. Regards, Jim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z