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
Totally_Lost wrote: > Peter Alfke wrote: > > It's hard to understand how grown-ups can indulge in this kind of silly > > argumentation... > > Peter Alfke > > For reference, a couple years back I had a couple XC2000E-8 parts in > Xilinx BG560 proto boards running a hand packed bit serial RC5 cracking > design at max clock rate ... petlier cooled, but could never get it > power stable, even after augmenting the power bypass caps and buss wire > to the socket. At first I blamed the sockets. Then put four of them on > PCBs and tried again .... never could get it stable anywhere close to > rated clock rate. ...snip... > If you, Austin, and Xilinx say XCV2000E/XCV2600E parts fully hand > packed with with bit serial compute engines should easily be stable > with solid cooling, I for one, will remain skeptical. > > If you want to say the XC4VLX200's packed the same way can be made > stable, or similar large XC5VLX parts, then I'll be happy to go back to > the client with that guarentee if Xilinx will stand behind it 110%. Is it possible that your problem is something other than heat? Power decoupling is more of a science than an art or guessing game. It is entirely possible that your decoupling was not adequate in spite of the augmentation. To fully decouple power for fast chips the power planes must be built with a lot of internal capacitance along with a range of different capacitor values to allow parallel resonances to be bypassed and a low impedance to be obtained over a wide frequency range.Article: 107276
"rickman" <gnuarm@gmail.com> wrote in message news:1156553990.451411.179250@m79g2000cwm.googlegroups.com... > To fully decouple power for fast chips the power planes > must be built with a lot of internal capacitance along with a range of > different capacitor values to allow parallel resonances to be bypassed > and a low impedance to be obtained over a wide frequency range. > Rick, You may find this enlightening! http://www.sigcon.com/Pubs/news/1_17.htm A range of values (in the same package size) is no help, it just bloats your BOM. Cheers, Syms.Article: 107277
rickman wrote: > Is it possible that your problem is something other than heat? Not heat, the XC2000E rolled over right after loading, room temp die. > Power > decoupling is more of a science than an art or guessing game. It is > entirely possible that your decoupling was not adequate in spite of the > augmentation. To fully decouple power for fast chips the power planes > must be built with a lot of internal capacitance along with a range of > different capacitor values to allow parallel resonances to be bypassed > and a low impedance to be obtained over a wide frequency range. You know, it's always possible. I stacked 0805/0603 caps right across the back side of the BG560 power/ground pads ... 0.01uf, 0.1uf, and 1.0uf on top of each other in a second test, and it just delayed the failure for a few seconds. It took abandoning the LUT SRL's to get any stability, plus backing the clock off. I personally don't think there is any way to fully load a large BG560 XCV2000E device with a dense bit/digit serial computational engine. I did notice that both Austin and Peter were not that quick to defend that is should be possible. The only bright spot, is that Austin sayslarge XC4V and XC5V can handle a fully loaded 1010101 design, which I would love to verify ... but I'm certainly not going to spend $10K to test it from my own funds. My personal belief is that the ground ring/net is probably shared with I/O pads, and is probably stable. I also suspect that it's the VCCINT pads that are dropping, which would make the worst case not 1010101 ... but a large number of 0->1 transistions in the fabric. Bit serial doesn't do that easily, or likely, but it does happen too when a MAC is cleared, the first add value for the next term is all ones. It does complicate the problem, when you also have heavy concurrent pin I/O in progress ... which I didn't. At least Xilinx is quick to rate the max number of up/down transitions for that problem. This mantra about 25% transitions is total BS for dense bit serial designs, SRL's or not.Article: 107278
John McGrath wrote: > You are right - they are totally contained within that always block - > so you most likely are getting away with it - but if you had used > noo-blocking <= statements, I wonder if the result may have been > different ;) (at least for behavioural sim). There are some imteresting True enough, but I've been trying to commit the "Verilog coding styles that kill" paper to memory so I didn't use non blocking statements :) > subtlties in verilog. I often use the verilog 2001 construct > > always@(*) > .... > > to ensure that the sensitivity list is always complete - should avoid > that problem. Sort of - I think really it would just hide the bugs in Xst. (but the price is right so I'm not complaining very much :) > As for the issue, it seems that the above is indeed not the issue from > your discription, and that it is most likely timing related. More's the pity really 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107279
Petter Gustad wrote: > I only store ONE file for Quartus, a tcl script to compile the design. > It includes all the pin assignments, global assignments to generate > SVF files etc. > > A typical build from a fresh checkout will look like: > > cvs co designname > cd designname/impl/ep1c6t144c8 > quartus_sh -t compile.tcl If only Xilinx made life that simple :( I'm not what you'd call a fan of the .ise file.. Project Navigator regularly corrupts it (usually after it's destroyed the backup copy), and the tools that interface to it are.. weak. pjcli can't even recreate a full project because it doesn't understand how to add a constraint file to it! And let's not get into the tool's obsession with absolute pathnames which make having 'beta' versions of your design very frustrating :( (but on the plus side I have a makefile which replicates the build functionality I need.. still working on generating simulation) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107280
zcsizmadia@gmail.com wrote: > The Digilent USB driver was the biggest task in this project. The > xc3sprog jtag interface doesn't really match the Digilent protocoll. So > I had to create a little bit different JTAG engine than xc3sprog to > support parport and USB, and to utilize the speed of Digilent USB > device, and to have a reduced speed version. > > The other problem what I had was, to create a infrastructure to support > multiple devices, where the algorithms may be similar, and to do that I > should have rewritten the whole xc3sprog anyway. Ahh fair enough. Pity.. it is frustrating to find several programs that have slightly different baseline functionality rather than having pooled resources to create one more complete program. Guess I'll download xilprog and send you some FreeBSD patches :) Any chance you can find out why anon CVS doesn't work? Having it checked out makes it much easier to generate diffs. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107281
Peter Alfke wrote: > I almost threw up when I read John Bass explain how he uses a > deliberately dumb-sounding name plus naive questions to light some fire > and create controversial flames. And just to correct the point .... I didn't ask any naive questions that Austin jumped on, both I made, and defended a statement which both You and Austin are pissy unhappy about. Totally_Lost wrote: > John_H wrote: > > You may run into power issues before you can consider overclocking. You > > could design so much high speed logic in a huge part that you can only run > > x% of the part at Fmax or all of the part at x% of Fmax. > > Right on John ... :) > > As I've noted before, you seriously need to "derate" large Xiinx FPGAs > for designs that have very high percentage of active logic. Since they > assume around 15-20% of the design will be active, it's very easy to be > unable to get power into the devices within the spec'ed voltage > margins, or to keep it cool if you do. Doing single point thermal > monitoring on the die, may not be enough to readily identify that other > portions of the die are well above that limit temp once you are > agressively cooling the part. > > Packing the device from edge to edge with active logic will cause > problems. At both high speeds and high density, many of the larger > parts are simply not usable. To which Austin insultingly asserts: Austin Lesea wrote: > Ray, > > I agree. Good post. > > Totally_Lost is, unfortunately, lost... totally. > > Austin and both of you end up eating crow for. That's your problem, take responsibility for it.Article: 107282
Symon wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1156553990.451411.179250@m79g2000cwm.googlegroups.com... > > To fully decouple power for fast chips the power planes > > must be built with a lot of internal capacitance along with a range of > > different capacitor values to allow parallel resonances to be bypassed > > and a low impedance to be obtained over a wide frequency range. > > > Rick, > You may find this enlightening! > http://www.sigcon.com/Pubs/news/1_17.htm > A range of values (in the same package size) is no help, it just bloats your > BOM. Yes, I see what you are saying. But the point is that you and Dr. Johnson make these statements with absolutely no supporting evidence. I was in the class, I saw the impedance plots and I even asked the exact same question about using the same package with the same parasitics. The issue is not the inductance, the issue is SRF. It took me awhile to understand why this is important. It was especially hard for me to grasp when I looked at the data for three different value caps superimposed to show that the inductive reactance region was nearly identical. But the smaller caps had a higher SRF. So combining a small number of 0.1 uF, a few more 0.01 uF and more of the 0.001 uF parts seem to provide the best solution. The impedance plot of the bare board with well coupled ground and power planes (no parts) shows the impedance dropping with frequency until it hits a SRF. The impedance goes up a bit and then seems to oscillate in the very high frequency region. Adding a single value of caps lowers the impedance at the low end, but actually makes the impedance higher at 150 MHz from parallel resonance between the cap and the plane. It is not clear to me that any reasonable number of additional caps would reduce this peak to be acceptable. Adding some caps at a smaller value added a new minimum in the impedance and raised the frequency of the parallel resonance. Adding a third value of caps makes the impedance plot quite acceptable with peaks less than about 100 mohm up to 3 GHz and the bulk of the graph under 25 mohm below 300 MHz. The graph is so very clear with the capacitor related minimums at about 20, 50 and 200 MHz. This guy chalenged some of my very deeply held beliefs in how to design power systems. I could not find a single thing wrong with anything he said. Others in the class would argue with him about their beliefs. But in the end it was beliefs vs. facts... no contest! There are two things that Dr. Johnson said that I want to address. "In addition, you have introduced the possibility of a resonance occurring, as you point out, between the lead inductance of the larger capacitor and the capacitance of the second, smaller-valued component." I think this is pretty clearly nonsense and I am surprised he said it. He refers to the two values of capacitors not being useful because they have the same inductance. Now he is saying that the inductance of one cap can interact with the capacitance of the other. Isn't that a contradiction? Wouldn't that produce the same result as the second capacitor's self resonance? The other thing he said is, "The best method for controlling the resonances between sections of the power system is to buy cheap, low-Q bypass components in the first place". Even though this seems counter intuitive, the data bears this out. The low quality (or high ESR) reduces the amplitude of the parallel resonance peaks and makes the impedance more even. Sounds odd, but correct, again the data bears this out.Article: 107283
fpga_toys@yahoo.com wrote: > rickman wrote: > > Is it possible that your problem is something other than heat? > > Not heat, the XC2000E rolled over right after loading, room temp die. > > > Power > > decoupling is more of a science than an art or guessing game. It is > > entirely possible that your decoupling was not adequate in spite of the > > augmentation. To fully decouple power for fast chips the power planes > > must be built with a lot of internal capacitance along with a range of > > different capacitor values to allow parallel resonances to be bypassed > > and a low impedance to be obtained over a wide frequency range. > > You know, it's always possible. It is good that you are open to possibilities. > I stacked 0805/0603 caps right across the back side of the BG560 > power/ground pads ... 0.01uf, 0.1uf, and 1.0uf on top of each other in > a second test, and it just delayed the failure for a few seconds. It > took abandoning the LUT SRL's to get any stability, plus backing the > clock off. Another odd thing about power that I learned was that the placement of the decoupling caps is not at all critical. This guy had designed a test board with caps at less than an inch from the test points and at about 3, 6 and 9 inches. The graphs of impedance between the planes are nearly identical regardless of which capacitor was populated. So it is clear that the caps don't need to be right on top of the power pins. But to make the smaller caps work well, you do need more of them than you need of the larger value caps. Not that I am doubting that you had enough. I am just pointing out what the data indicates is required. > I personally don't think there is any way to fully load a large BG560 > XCV2000E device with a dense bit/digit serial computational engine. I > did notice that both Austin and Peter were not that quick to defend > that is should be possible. > > The only bright spot, is that Austin sayslarge XC4V and XC5V can > handle a fully loaded 1010101 design, which I would love to verify ... > but I'm certainly not going to spend $10K to test it from my own funds. I have no doubt that there are some designs that will not do well in an FPGA. These are complex chips and it has got to be hard to design them for all applications. It is also possible that there are SI issues inside the chip. As you point out, ground and power bounce are very real problems and there is nothing you can do on the outside to mitigate them.Article: 107284
Austin Lesea wrote: > The ASSP vendors are very protective about their business: they > continue to make their little applications as tough to do as possible, > to keep out the 'big bad FPGA vendors' who seem to be eating up all > their businesses. (Hey, we are just trying to make our customers happy!) > > Too bad: when an industry is spending time being defensive, they have > already lost - any time spent not innovating means you are doomed to > failure. Ok ... I took the time to see who the little guys are at SATA-IO that Austin claims are running completely scared of the 'big bad FPGA vendors'. Frankly, when I read down the list, it becomes pretty obvious many of the players could aquire Xilinx with a day or two's free profits and not even worry about the investment costs if they paid twice what Xilinx was worth. The only two things obvious, is that Austin's/Xilinx's head is so full of shit if they think half these companies even care what Xilinx does with SATA, and that Xilinx is so full of NIH that they are failing to meet custmers needs by refusing to play nicely inside the industry wide SATA club. Anybody spot those that Austin claims "are running completely scared of the 'big bad FPGA vendors'."???? ACARD Technology Corporation Accusys Adaptec, Inc. Addonics Technologies Adtron Corporation Aeluros, Inc. Agere Systems Agilent Technologies, Inc. Allion Computer Inc. Alta Engineering AMCC (3ware) AMD Aska Technologies Inc. ATI Avery Design Systems Bell Microproducts BiTMICRO Networks BizLink Broadcom Buffalo Inc. Catalyst Enterprises Inc. CEVA CI Design Circuit Assembly Corp. Comax Technology, Inc. CRU-DataPort CRUZ Systems Dallas Semiconductor, Inc. DataStor Technology Co., Ltd. Dell Denali Software, Inc. Der An Electric Wire & Cable Co., Ltd DoTop Technology, Inc. Ease Software, Inc. Electronics Testing Center, Taiwan Emulex Corporation Epson Research & Development, Inc. EqualLogic Exar Corporation Expert I/O Faraday Technology Corporation FCI Finisar FirmTek, LLC Foxconn Electronics Fujikura/DDK Fujitsu Computer Products of America Fujitsu-Siemens Computers Genesys Logic, Inc. Golden Bridge Electech Inc. Hewlett-Packard Highly Reliable Systems HighPoint Technologies, Inc. Hitachi Global Storage Technologies Hitachi-LG Data Storage Korea, Inc. Horng Tong (HOMETOM) Enterprise Co., Ltd. IBM Corporation IIX Consulting Infineon Technologies Infortrend Technology, Inc. Initio Corporation Intel Corp. Intella Sys Corp. IntelliProp Inc. Interelectronix Iomega JAE Electronics Jalink Technology Inc. Jei Wei Electronic Co., Ltd. JMicron Technology Corp. Joinsoon Electronics Mfg. Co. Ltd. J.S.T. Mfg. Co., Ltd. Kano Technologies Kawasaki Microelectronics, Inc. KnowledgeTek, Inc. Knowlent Corporation LeCroy Corp. LaCie Landwin Electronic Corp. Link-A-Media Devices LITE-ON Technology Corp. Longwell LSI Logic LyCOM Technology, Inc. Marvell Semiconductor, Inc. Maxtor MediaTek Inc. Mentor Graphics Microsoft Mitac International Corporation Molex, Inc. M-Systems NEC Electronics Corporation Netcell Corp. Niketech Northstar Systems Corp. Nvidia Corporation Omneon Video Networks Oxford Semiconductor Ltd. Quantum Corp. Panasonic Semiconductor PDE Technology Corporation PHILIPS & BenQ Digital Storage Corporation Philips Semiconductors Pioneer Corporation Plextor Corp. PMTC NV Prolific Technology, Inc. Promise Technology, Inc. ProStor Systems, Inc. P-TWO Industries Inc. Rapid Conn RATOC Systems, Inc. Realtek Renesas Technology RITEUP Co., Ltd. ROHM Co., Ltd. Samsung Electronics Sanko Electronics Co., Ltd. Seagate Technology Scientific Atlanta Sierra Logic, Inc. SIIG, Inc. Silicon Image Inc. Silicon Integrated Systems Corp SiliconStor, Inc. SimpleTech SMK Corporation Soft Mixed Signal Corporation Sonnet Technologies, Inc. Space Shuttle Hi-Tech Co., Ltd. STMicroelectronics Sunext Technology Sun Microsystems, Inc. Sunplus Technology Co. Ltd. Synthesys Research, Inc. Synopsys Taiwan Electronics Co., Ltd. Tektronix Top Yang Technology Enterprise Co., Ltd. Toshiba Total Technologies, Ltd. Trimax Electronics Co., Ltd. Tyco Electronics ULi Electronics Inc. ULINK Technology University of New Hampshire InterOperablitity Lab Via Technologies Inc. Vitesse Semiconductor Corp. VMC Consulting VSO Electric Co, Ltd. Wavecrest Western Digital Corp. Wieson Technologies Co., Ltd. Win Win Precision, Co., Ltd. Wipro Limited Y.C. Cable USA, Inc. ZarlinkArticle: 107285
rickman wrote: <snip> > This guy chalenged some of my very deeply held beliefs in how to design > power systems. I could not find a single thing wrong with anything he > said. Others in the class would argue with him about their beliefs. > But in the end it was beliefs vs. facts... no contest! I love eye-opening engineering. It's not often that there's a spark of "oh yeaaaaah" like this. > There are two things that Dr. Johnson said that I want to address. "In > addition, you have introduced the possibility of a resonance occurring, > as you point out, between the lead inductance of the larger capacitor > and the capacitance of the second, smaller-valued component." I think > this is pretty clearly nonsense and I am surprised he said it. He > refers to the two values of capacitors not being useful because they > have the same inductance. Now he is saying that the inductance of one > cap can interact with the capacitance of the other. Isn't that a > contradiction? Wouldn't that produce the same result as the second > capacitor's self resonance? The SRF of a capacitor gives you the minimum impedance - as close to the ideal dead short as you can get. Above that frequency, the cap goes inductive but it's still a darn good impedance for several octaves of frequency. If you have another capacitor with a higher SRF, what you end up with isn't the *series* resonance, but an anti-parallel resonance (the "anti" looks strange but those were the terms used). Going back to the early book-learning, this anti-parallel resonance ends up as an open, not a direct short. The only thing saving that frequency point from being a dead-open is the non-ideal characteristics of those parasitics. SRF in a capacitor is a good thing. Resonance between a an inductor and a capacitor in parallel isn't so good. > The other thing he said is, "The best method for controlling the > resonances between sections of the power system is to buy cheap, low-Q > bypass components in the first place". Even though this seems counter > intuitive, the data bears this out. The low quality (or high ESR) > reduces the amplitude of the parallel resonance peaks and makes the > impedance more even. Sounds odd, but correct, again the data bears > this out. If you model the parallel L and C you get an open. If you sprinkle some R into those textbook equations, the impedance doesn't keep heading up to la-la land. Really neat stuff. I haven't had a chance to try this out myself, but I sure would like to.Article: 107286
rickman wrote: > Symon wrote: > >>"rickman" <gnuarm@gmail.com> wrote in message >>news:1156553990.451411.179250@m79g2000cwm.googlegroups.com... >> >>> To fully decouple power for fast chips the power planes >>>must be built with a lot of internal capacitance along with a range of >>>different capacitor values to allow parallel resonances to be bypassed >>>and a low impedance to be obtained over a wide frequency range. >>> >> >>Rick, >>You may find this enlightening! >>http://www.sigcon.com/Pubs/news/1_17.htm >>A range of values (in the same package size) is no help, it just bloats your >>BOM. > > > Yes, I see what you are saying. But the point is that you and Dr. > Johnson make these statements with absolutely no supporting evidence. > I was in the class, I saw the impedance plots and I even asked the > exact same question about using the same package with the same > parasitics. The issue is not the inductance, the issue is SRF. It > took me awhile to understand why this is important. It was especially > hard for me to grasp when I looked at the data for three different > value caps superimposed to show that the inductive reactance region was > nearly identical. But the smaller caps had a higher SRF. So combining > a small number of 0.1 uF, a few more 0.01 uF and more of the 0.001 uF > parts seem to provide the best solution. > > The impedance plot of the bare board with well coupled ground and power > planes (no parts) shows the impedance dropping with frequency until it > hits a SRF. The impedance goes up a bit and then seems to oscillate in > the very high frequency region. Adding a single value of caps lowers > the impedance at the low end, but actually makes the impedance higher > at 150 MHz from parallel resonance between the cap and the plane. It > is not clear to me that any reasonable number of additional caps would > reduce this peak to be acceptable. Adding some caps at a smaller value > added a new minimum in the impedance and raised the frequency of the > parallel resonance. Adding a third value of caps makes the impedance > plot quite acceptable with peaks less than about 100 mohm up to 3 GHz > and the bulk of the graph under 25 mohm below 300 MHz. The graph is so > very clear with the capacitor related minimums at about 20, 50 and 200 > MHz. > > This guy chalenged some of my very deeply held beliefs in how to design > power systems. I could not find a single thing wrong with anything he > said. Others in the class would argue with him about their beliefs. > But in the end it was beliefs vs. facts... no contest! For some good plotted-examples, of what you describe, see this pdf http://www.atmel.com/dyn/resources/prod_documents/doc4279.pdf <paste> > Another odd thing about power that I learned was that the placement of > the decoupling caps is not at all critical. This guy had designed a > test board with caps at less than an inch from the test points and at > about 3, 6 and 9 inches. The graphs of impedance between the planes > are nearly identical regardless of which capacitor was populated. So > it is clear that the caps don't need to be right on top of the power > pins. But to make the smaller caps work well, you do need more of them > than you need of the larger value caps. Not that I am doubting that > you had enough. I am just pointing out what the data indicates is > required. You'd need to be carefull in the description. In this case, the caps decouple the plane, and the plane decouples the device. So short connections to the plane are VERY important, and once you have those, then yes, the absolute CAP placement is less critical. - see fig 15 in the pdf above, for the plane vs trace nh/cm I think some PCB stackups, offer thinner plane separations, and higher permittivity, both to drive down the plane impedance ( for some cost trade off ). -jgArticle: 107287
zcsizmadia@gmail.com wrote: > I inject a dll into the impact.exe, and hook DeviceIoControl and some > other kernel32 APIs. impact.exe calls DeviceIoControl to read/write LPT > I/O port using windriver6 driver. Instead of calling original windrvr > DeviceIoControl function I just forward the TMS/TDI/TDO/TCK bits to > Digilent USB (or any other programmer cable). Easy enough to do that with LD_PRELOAD in Linux. (.so injection) Interesting idea! > On linux the easiest could be to create a brand new windrvr emulator > driver where we implement all the IOCTLs used by impact. BTW, I have no > clue why they are using the windriver as a device driver, because all > the features they do with the Jungo driver ius really simple and > generic(eg: user mode I/O access, USB acces to device, etc.) Assuming you can get the windrv header file, although I think you can probably reverse engineer it anyway. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 107288
Jim Granville schrieb: > http://www.eet.com/news/design/showArticle.jhtml;jsessionid=50HDYO5YS5YXCQSNDLRSKH0CJUNN2JVN?articleID=192300291 > > > Claims this : > > "Imapcar has 128 processing elements, each with embedded memory. The 128 > parallel processing elements use the SIMD (single instruction stream > multiple data stream) method. Each element processes four instructions > per cycle. Thus, total performance was 100 Gops running at 100 MHz, > enabling real-time image recognition at 30 frames per second." Hmm. 128*100M*4 = 100G Somehow I am missing a factor of two here. Kolja SulimmaArticle: 107289
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > > real world high density high clock rate > > designs tend to have average toggle rates of 20% or less. Bit serial > > designs have toggle rates that are a bit higher, but still usually well > > under 50%. I don't see dissipations more than about 20-25W, which can > > be handled with proper thermal design on any of the large FPGAs. In > > most cases, I'd say the average dissipation I've been seeing on large > > aggressive designs (2V6000, V4SX55, 2P70) is between 10 and 13 Watts. > > As a reference point, bit toggle rates of high density bit serial LUT > SRL designs are SIGNIFICANTLY higher, and depending on the statistical > distribution of 1's and 0's in the data easily hover around 75% or > better. Doing designs which ignore the data specific toggle rates by > simply assuming toggle rates based on traditional parallel designs is > folly at best. > > The RC5 design was interleaved and pipelined with NO parallel > operations. The nature of the RC5 data stream after the first stage is > highly random, IE 50% of the data has a changes state on each clock, > 25% of the data changes state at half the clock rate, and 12.5% of the > data changes state at 1/4 the clock rate, ... to an average of near > 75%, and short term variances that are statistically frequent much > higher than that. Now I'm totally confused TC. What does "highly random" data mean? Data with a 75% toggle rate is halfway towards the ultimate pathological case of "0101010101...". To me, highly random data implies a fairly flat distribution with a 50% average toggle rate, period. If any given flop has a 50% chance of toggling on any given clock cycle, your summation seems to imply that some flops (or srl cells) are toggling twice per cycle. That's a neat trick, and I don't get it. > The same was true of the high density heat simulation model based on > LUT SRL's and bit serial MAC's (inspired by your web page). The > floating point data, with an assumed leading one, and normalized, has a > nearly random toggle rate in the bit serial stream. It was necessary > again to word interleave the engine to facilitate parallel loading of a > multiplier, which shifted the ratio of LUT SRL's up to retime the > interleaved data. And again, toggle rates overall were well above 50%, > actually near 75%, and nothing like your "usually well under 50%" > guideline. > Reflecting on these two "normal" bit serial designs, I would suggest > that heavily pipelined bit seral crypto and floating point math engines > which are hand packed, and highly replicated, will easily exceed the > 50% toggle rates. This is especially compounded when considering the > serial shift costs of LUT SRL's. > > Replacing LUT SRL's with LUT RAM's certainly helps by removing the SRL > bit shifting power, but doesn't lower the design toggle rates below 50% > ... as they remain around 75% unless there are significant data > dependencies that cause significant runs of zero's or one's. Is crypto/FP data that different than other data? Perhaps there's an opportunity here. A clever recoding could replace highly toggling symbols by equivalent low toggle rate sequences. You could change your 75% to 25%, and get a 3:1 power reduction (um, tongue in cheek there). One parting comment, John, you're a fairly bright guy (I truly admire anyone with skills and patience to put together a language compiler), but everyone errs from time to time. In my callow youth, I designed a path in an XC3000 that relied on route/gate delay to take a signal across a clock boundary, to catch it on the next clock (In retrospect, 3000s were really tiny!). Come the die shrink, I got burned. Sounds like you did too, even more literally. I sympathize, but we live and learn. The caustic expletives don't help your cause, and really puts folks off here. Regards all, Just JohnArticle: 107290
Jim Granville wrote: > Austin Lesea wrote: > > Martin, > > > > No, and No. Sorry, even V5 does not have the frequency tracking agility > > to track the SATA spread spectrum clock. And because of that, we have > > no IP for it, either. > > > > The ASSP vendors are very protective about their business: they > > continue to make their little applications as tough to do as possible, > > to keep out the 'big bad FPGA vendors' who seem to be eating up all > > their businesses. (Hey, we are just trying to make our customers happy!) > > > > Too bad: when an industry is spending time being defensive, they have > > already lost - any time spent not innovating means you are doomed to > > failure. > > That probably depends on where you are standing. > > Could be, that the FPGA sector needs to innovate, and include > sufficent agility to track a SATA spread spectrum clock ? > > Sounds more an issue of who decides the market is large enough to > bother with, than any perceived fpga-vs-assp battles ? > > -jg I'll second this with an added comment: Spread spectrum clocks are an absolute must in some areas, and very desirable in others; I would *love* to use a spread spectrum clock in my newest design because it does not have a metal enclosure and EMI/EMC is a major issue. When you make FPGAs (or ASICs or any other chip for that matter) for a living but not shipping board and enclosure level products it's easy to forget 'little details' like this (regulatory compliance) that systems and board designers live with day in and day out. Spread spectrum obviously alleviates the problem significantly (in some very subtle ways too). A lot of vendors offer the ability to track a spread spectrum clock; why not FPGA vendors too? Cheers PeteSArticle: 107291
Ed McGettigan wrote: > vt2001cpe wrote: > > Thank you everyone for your quick and informative responses! In the > > event of a large number of bit errors, is it possible for a comma > > character to be incorrectly introduced? What would the effect be? Will > > the CRC fail and put the state machine into an error state, or will > > data continue to transmit, unaware? > > It is possible to generate more than a single bit error in the same > 8b10b word, but with a well designed link this is very unlikely to > occur. In any case your transmitter is completely unaware that an > error actually occurred and will happily continue transmitting. It's > your receiver logic needs to be able to handle any errors that happen. > > The worst case that could happen is that the error generates a comma > character that is out of alignment with the previous alignment. This > would cause a constant stream of errors until a correct comma character > is received and the link realigns to the correct 8b10b word. All of > this is fairly standard stuff and has been around for decades in > many different protocols. > > Since it doesn't look like you have a particular protocol in mind. I > would suggest that you take a look at the light weight Aurora protocol > http://www.xilinx.com/aurora Even if you decide to not use it, you > should be able to learn a lot from it. > > Ed McGettigan > -- > Xilinx Inc. As noted, much depends on the cable. I have used a lot of high speed cables, and the best of the bunch is made by Gore (and whoever they may have licensed their 'Eye-Opener' self equalising cable to) http://www.gore.com/en_xx/products/cables/copper/backplane/gore_eye-opener_airmaxvs_cable_assemblies.html I've run 4x InfiniBand over 11 metres on this type of cable and it was within the spec (10dB insertion loss max, amongst other things). That was the best I ever achieved with 4x cables. I once had a cable that could do <= 10dB attenuation of a single 2.5Gb/s pair at 17m. The further you want to run the signal, the more expensive the cable is going to be. Spectra Strip is usually the basis of most high speed cable assemblies, which is not particularly cheap. As always, the loss budget includes the transmitter and receiver specs. I haven't seen an FPGA that was IB compliant, but could run IB over limited distances. Of course, if you want to run faster than that (DDR IB comes to mind ;) then your cable length will be shortened proportionately. Cheers PeteSArticle: 107292
"PeteS" <PeterSmith1954@googlemail.com> wrote: >Jim Granville wrote: >> Austin Lesea wrote: >> > Martin, >> > >> > No, and No. Sorry, even V5 does not have the frequency tracking agility >> > to track the SATA spread spectrum clock. And because of that, we have >> > no IP for it, either. >> > >> > The ASSP vendors are very protective about their business: they >> > continue to make their little applications as tough to do as possible, >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all >> > their businesses. (Hey, we are just trying to make our customers happy!) >> > >> > Too bad: when an industry is spending time being defensive, they have >> > already lost - any time spent not innovating means you are doomed to >> > failure. >> >> That probably depends on where you are standing. >> >> Could be, that the FPGA sector needs to innovate, and include >> sufficent agility to track a SATA spread spectrum clock ? >> >> Sounds more an issue of who decides the market is large enough to >> bother with, than any perceived fpga-vs-assp battles ? >> >> -jg > >I'll second this with an added comment: Spread spectrum clocks are an >absolute must in some areas, and very desirable in others; I would >*love* to use a spread spectrum clock in my newest design because it >does not have a metal enclosure and EMI/EMC is a major issue. >When you make FPGAs (or ASICs or any other chip for that matter) for a >living but not shipping board and enclosure level products it's easy to >forget 'little details' like this (regulatory compliance) that systems >and board designers live with day in and day out. > >Spread spectrum obviously alleviates the problem significantly (in some >very subtle ways too). A lot of vendors offer the ability to track a >spread spectrum clock; why not FPGA vendors too? You can as long as you don't use the DCM (or anything like it) and route the fpga for the highest allowed clock frequency. If you use an external device to create your clocks and feed them into the fpga, there is no reason why an fpga won't work with spectrum spread clocks. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 107293
Nico Coesel schrieb: > "PeteS" <PeterSmith1954@googlemail.com> wrote: > > >Jim Granville wrote: > >> Austin Lesea wrote: > >> > Martin, > >> > > >> > No, and No. Sorry, even V5 does not have the frequency tracking agility > >> > to track the SATA spread spectrum clock. And because of that, we have > >> > no IP for it, either. > >> > > >> > The ASSP vendors are very protective about their business: they > >> > continue to make their little applications as tough to do as possible, > >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all > >> > their businesses. (Hey, we are just trying to make our customers happy!) > >> > > >> > Too bad: when an industry is spending time being defensive, they have > >> > already lost - any time spent not innovating means you are doomed to > >> > failure. > >> > >> That probably depends on where you are standing. > >> > >> Could be, that the FPGA sector needs to innovate, and include > >> sufficent agility to track a SATA spread spectrum clock ? > >> > >> Sounds more an issue of who decides the market is large enough to > >> bother with, than any perceived fpga-vs-assp battles ? > >> > >> -jg > > > >I'll second this with an added comment: Spread spectrum clocks are an > >absolute must in some areas, and very desirable in others; I would > >*love* to use a spread spectrum clock in my newest design because it > >does not have a metal enclosure and EMI/EMC is a major issue. > >When you make FPGAs (or ASICs or any other chip for that matter) for a > >living but not shipping board and enclosure level products it's easy to > >forget 'little details' like this (regulatory compliance) that systems > >and board designers live with day in and day out. > > > >Spread spectrum obviously alleviates the problem significantly (in some > >very subtle ways too). A lot of vendors offer the ability to track a > >spread spectrum clock; why not FPGA vendors too? > > You can as long as you don't use the DCM (or anything like it) and > route the fpga for the highest allowed clock frequency. If you use an > external device to create your clocks and feed them into the fpga, > there is no reason why an fpga won't work with spectrum spread clocks. > > -- > Reply to nico@nctdevpuntnl (punt=.) > Bedrijven en winkels vindt U op www.adresboekje.nl well in the case of SATA it is not so much an option. FPGA has no issues when external SATA PHY is used, but then we are not much talking about using MGT ofr SATA anymore. if we use external CDR circuitry that locks to SATA and spits out serial stream suitable for MGTs, then I think its still possible that MGTs dont lock anyway. and I dont think such an CDR IC is easier to find (or cheaper) then SATA PHY (what is almost impossible to obtain) BTW in my comment about V2Pro MGT issues I did mean the CDR clock region being too narrow +-100ppm (SATA +-300), those making V2Pro not to lock in some cases where initial clock is too far away - also when spread spectrum is not used. This issue has been fixed in V4FX ASFAIK - the CDR lock range is extended. AnttiArticle: 107294
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1156572617.852268.132070@m79g2000cwm.googlegroups.com... > Austin Lesea wrote: >> The ASSP vendors are very protective about their business: they >> continue to make their little applications as tough to do as possible, >> to keep out the 'big bad FPGA vendors' who seem to be eating up all >> their businesses. (Hey, we are just trying to make our customers happy!) >> >> Too bad: when an industry is spending time being defensive, they have >> already lost - any time spent not innovating means you are doomed to >> failure. > > Ok ... I took the time to see who the little guys are at SATA-IO that > Austin claims are running completely scared of the 'big bad FPGA > vendors'. Frankly, when I read down the list, it becomes pretty obvious > many of the players could aquire Xilinx with a day or two's free > profits and not even worry about the investment costs if they paid > twice what Xilinx was worth. > > The only two things obvious, is that Austin's/Xilinx's head is so full > of shit if they think half these companies even care what Xilinx does > with SATA, and that Xilinx is so full of NIH that they are failing to > meet custmers needs by refusing to play nicely inside the industry wide > SATA club. > > Anybody spot those that Austin claims "are running completely scared of > the 'big bad FPGA vendors'."???? > [snip] Dear Mr Brass! What has the World done to You? Did you lost your grannys savings in Xilinx stock or your own balls in the supermarket !? Some free advice to you: 1) go fly a kite 2) rent a movie titled "Joe vs Volcano", watch it, to the very end 3) think twice before claiming to know the contents of the heads of the others ------------- The ASSP vendors are very likely not directly scared, but for some reason almost every document regarding SATA IC's is only available under NDA and SATA PHY silicon is virtually impossible to obtain. The most reasonable use of SATA PHY would be an FPGA based product. As for the ASIC designs it makes more sense to integrate the PHY on chip. So for me its pretty much clear why SATA PHYs are not available, the same Silicon/IP vendors are also selling SATA IP, and selling bare SATA PHY as IC (to be possible be used with an FPGA) would make their possible earnings from ASSP and ASIC IP sales smaller. So some small guys are defenetly looking at FPGA vendors. Antti, who just returned from "flying the kite"Article: 107295
There is no difference between the Quartus II 5.1 Web Edition and Quartus II 5.1 Web Edition Full. The name difference stems from the fact that the Quartus II 5.1 Web Edition Full is a single file download while the Quartus II 5.1 Web Edition is a three file download (for folks with slower links). If you received a CD with web edition you would have the Quartus II 5.1 Web Edition Full. If you have a new license file go to Tools->License Setup and point to the file you have in the License File Entry at the top. Hope this helps, Subroto Datta Altera Corp. <edaudio2000@yahoo.co.uk> wrote in message news:1156519663.127711.210640@m79g2000cwm.googlegroups.com... > Is there a difference between Quartus "Web Edition" and "Web Edition > Full"? > > I bought the NIOS development kit which came with Quartus 5.1 Web > Edition Full > > I now want to replace it with the standard Quartus 6 WEb Edition, but > the program won't allow me to enter a new (downoladed) license file, > nor it will perform the automatic web license update Message: "Can't > find a newer license file for this system at the Altera website, > contact Altera Customer service" > > Does anybody know what may be going on? > > I have raised a service request on the altera website, but I suspect > they may take a very long time to respond. > > Any help appreciated > > TIA >Article: 107296
Go to windriver website and download the evaluation version. It includes the header files. ZoltanArticle: 107297
Patrick, what board are you targeting? If you can send me your design I'll have a look to see what might be wrong. It looks like you can download the bitstream with XMD and then connect to the PPC with XMD. You can download and run software to the PPC through XMD with $ xmd XMD% connect ppc hw -debugdevice icachestartadr <adr> dcachestartadr <adr> XMD% dow <elf file> XMD% run You might have a look at the xmd.ini file to see what the correct "connect" parameters are. You can also have a look at XAPP807. It is a small system that makes use of the UC2 and the TEMAC. - Peter Patrick Dubois wrote: > Hello everyone, > > First of all, big thanks to everyone who contribute to this newsgroup. > Most of the time, I can find a solution to my problem just googling > this newsgroup. Not this time however... > > I know that this is a long post but if you can help with the > UltraController II + SystemAce or UC2 + xmd, please read on. > > I'm currently trying to get a system with the UltraController II up and > running. To make a long story short (hopefully), I started with the > tools at v7.1, the UC2 reference design, and an eval board from Avnet. > I was able to successfully build a small system using the UC2 and a > Wishbone bus. I always ran the UC2 code using the debugger however (XMD > + GDB). > > Confident that the UC2 was a good solution for me (as I don't have > external ram), I spent a few months incorporating the UC2 in my real > design (3 FPGAs, two VP40 and one VP7). I used SystemC to simulate the > UC2 and now I reached the point of trying it out in hardware. That's > when the problems start... > > First of all, xmd can't even detect the PowerPCs in the JTAG chain in > the big design. So I took a step back and went back to the Avnet eval > board to play around more and get to understand the flow better. Right > now I'd like to accomplish two things: > 1- I'd like to be able to create a SystemAce file that loads both the > bit config file and the elf program file at boot-up (for the Avnet > board with a single VP7). > 2- I'd like to understand how xmd can load and run my software without > the GDB debugger. > > For the SystemAce, I used the modified genace.tcl script that comes > with the reference design but it doesn't work. To be more precise, I > can generate the ace file, the SystemAce loads everything in the FPGA > fine (done led goes up), but my code doesn't boot. The hardware part > seems okay because one of my debug led turns on (attached directly to > VCC in the fpga). Since the code doesn't boot, I tried to use xmd to > connect to the PowerPC. However, xmd doesn't detect the PowerPC (ERROR: > Unable to connect to PowerPC target. Invalid Processor Version No > 0x00000000"). That's strange because if I then proceed to load the bit > file using iMPACT, then xmd can detect the PowerPC fine. > > Now for xmd, I'd like know how to load and run my code with it. I > followed the instructions in XAPP571 (to properly use the DEBUGHALT > controller), but it doesn't work. I tried a few things but I'm really > in the dark as I don't have deep understanding of the whole EDK flow > (which is why I choose the UltraController in the first place). > > I appologize for the long post but I wanted to give as much details as > possible to whoever could help me... By the way, I opened several > webcases with Xilinx to help me along the way to where I am now, but I > thought I'd give this newsgroup a shot for any UC2 experts out there. > > Thanks. > > Patrick Dubois >Article: 107298
> I'm planning on using a Cypress CY7C67200 in a project. It has 2 USB > ports and one can be on-the-go, meaning it can switch between host > and peripheral mode as necessary. I really just need 2 host ports. > > The chip is 8051 based with support hardware. However it seems to > have some mode where it can get out of the way and be controlled > by an external device, which would be the FPGA. It's all theory, I > need to prove out functionality. > Thanks for the input. One of the devices under consideriation is the Cypress CY7C68016 which is 8051 based with USB, and I'm guessing similar in some fashion to the 7C67200 that you're using (but I'll take a look maybe that would be a better choice for us too). The only 'problem' is that the system as a whole has on the order of ~150-200 I/O pins (depends on other system level tradeoffs that we're considering). The logic to support those I/O pins won't take up many of the logic resources of any FPGA that can support the I/O pin requirements. Given that, and the fact that it appears (based on logic resources of the cores I'm looking at) that I can embed a processor and USB and the custom logic for all the other I/O all in one part and just skip over having a separate part just to get the USB functionality it seems irght now to be the least expensive product cost approach at the moment (even while adding the external USB PHY). But now the issues become: - Has someone really field tested and qualified the core? - Are their reference designs available upon which that qualification was based? - Linux drivers to support the core? Without 'yes' answers to each of the above questions it will drive up risk and development costs which need to be balanced into the equation for deciding. I'm not unwilling to pay for the core to get the above mentioned assurances, but if someone has already done this exercise with the OpenCores version it would be worth the time to persue that avenue as well. KJArticle: 107299
I questioned the availability of the Virtex5 back in July on this group and got some responses from Xilinx people saying it was being sampled and to get a sample I needed to get an order in immediately. I did that even though the parts were not even in distributors systems and the local Xilinx reps initially were not sure what delivery would be. I did get a response back from the rep saying there was a 13 week delivery for an engineering sample which would be in late Sept. and you could not get production parts until next year. I could live with that and proceeded with my design using a V5LX50. Yesterday we got a FAX from our distributor /rep saying delivery of the engineering sample would not be until May 2007!!!. This is a full year after the part was anounced. I have seen numerous advertisements for the Virtex 5 "Shipping NOW". Does anyone know the truth behind this part ???? Are there major problems with the part?
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