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
I think you are saying you want to add a constant phase shift of 90 degrees to your signal, in which case mixing it like you specified isn't going to do that. The mixer you've specified shifts the center frequency of the input signal by Fs/4 (multiplies the signal by e^(-j*2pi*t). To do a constant phase shift, you need to do a rotation of 90 degrees on the signal. Fortunately, 90 degrees is really easy: I<= -Qin and Q<=Iin. Noddy wrote: > Hi all, > > I was wondering if anyone can confirm this: if I want to, lets say, > digitally mix my bandwidth by pi/2, in other words shift the unit circle in > the z plane by 90 degrees, all I need to do is multiply my incoming samples > by the sequence 1,+j,-1,-j. Is this correct? I have implemented this in a > schematic design, but it doesn't appear to be working as I had hoped. > > Any other ideas? > > adrian -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33526
One note on the serial cascade: There is some recovery time required after switching delays...ie you'll need to be a bit more sophisticated if you need to support clock by clock tap changes. Ray Andraka wrote: > You can't use the F5/F6 mux in the same slice as 2 srl16's because the BX and BY lines which control the mux are shared with the write enables > for the SRL16's. Depending on your application, you might change the programming of the SRL16 address lines on two serially cascaded SRL16s, > which (without intervening FD's) gives you a delay between 2 and 32 clocks and no mux. You will need to translate the delay code into the 8 > select bits for the SRL16s. If you are concerned for speed, you'll want to register the output of each SRL16 with the FF in the same > half-slice. The clock to out time of the SRL16 is pretty lousy compared to that of the FF's. > > Huang wrote: > > > Hi, > > > > When using CoreGenerator for a SRL16 based shif register, say, a 32x1 shfit register, I found the result was 3 LUT, 2 for SRL16, 1 for mux. > > > > Does anyone know why CoreGen doesn't use MUXF5/6/7/8 for a more resource efficient result? > > > > Thanks > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33527
In article <20010729.133501.492067917.26595@polybus.com>, B. Joshua Rosen <bjrosen@polybus.com> writes >The coverage that the FPGA vendors provide is less than perfect but it's >good enough for most applications. In my experience, writing FPGA test >programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs have some >defect although the chance of any one pattern running into that defect is >in the neighborhood of 1 in 100. As a result the chance that any one >pattern will have a problem on any particular FPGA is about 1 in 5000. As >you raise the number of patterns that you run on a particular FPGA the >chances that you will run into a problem approached the 1 in 50 number. Many thanks for such a detailed answer. I come from an ASIC manufacturing background so the absence of scan would worry me. So there is a 1 in 5000 chance of detecting a faulty FPGA? This is equivalent to 200 dppm which is a good quality level. > >The way that you test FPGAs is different then the way that you test an >ASIC. FPGAs are mostly interconnect which makes them harder to test. On >the other hand because they are soft you can run an unlimited number of >different test patterns on them, which simplifies the problem as compared >to an ASIC. If you are concerned about shipping an >FPGA with a hidden defect then the way that you solve it is to run a >large number of test patterns on your FPGAs and throw >out the bad ones. The FPGA vendors do some of this but they are limited >by the amount of time that they can tie up a chip tester for. Generally >the vendor tests runs in under a second, in my experience it takes about A 1 second test time would be considered normal. A test time of 20 minutes would be very expensive. >20 minutes to really test an FPGA. If you are selling low volume high >value equiptment that contains a large number of FPGAs and loads many >different patterns into them, like and ASIC emulator, then this degree >of testing is necessary. If you are shipping high volume low priced >boards then it's cheaper to live with the one in 5000 fall out. Adding >scan logic to a particular circuit is useless because any change to the >pattern, including another place and route on the same design, will >change which resources are used inside of the FPGA. > > >In article <996308678.26850.0.nnrp-07.9e9832fa@news.demon.co.uk>, "Tim" ><tim@rockylogic.com.nospam.com> wrote: > >> "Andy Botterill" <csm@plymouth2.demon.co.uk> wrote in message >> news:YNNvDUAmacY7EwX0@plymouth2.demon.co.uk... >> >>> >Programmable parts have different test requirements to ASICs, so I >>> >guess the answer to your question is Yes. >>> >>> If you cannot insert scan into an FPGA how do you get a high fault >>> coverage? If you have a poor fault coverage you will be shipping >>> defective parts which is not good for your business. >> >> The FPGA manufacturers do this for you. They use a combination of the >> reprogrammability of the part and, presumably, a few undisclosed test >> structures. >> >> The result is closer to 100% tested than just about any ASIC. All you >> have to worry about is logical and timing errors :) >> >> >> >> >> -- Andy BotterillArticle: 33529
Truly interesting. Any comments from A or X? "B. Joshua Rosen" <bjrosen@polybus.com> wrote in message news:20010729.133501.492067917.26595@polybus.com... > The coverage that the FPGA vendors provide is less than perfect but it's > good enough for most applications. In my experience, writing FPGA test > programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs have some > defect although the chance of any one pattern running into that defect is > in the neighborhood of 1 in 100. As a result the chance that any one > pattern will have a problem on any particular FPGA is about 1 in 5000. As > you raise the number of patterns that you run on a particular FPGA the > chances that you will run into a problem approached the 1 in 50 number. > > The way that you test FPGAs is different then the way that you test an > ASIC. FPGAs are mostly interconnect which makes them harder to test. On > the other hand because they are soft you can run an unlimited number of > different test patterns on them, which simplifies the problem as compared > to an ASIC. If you are concerned about shipping an > FPGA with a hidden defect then the way that you solve it is to run a > large number of test patterns on your FPGAs and throw > out the bad ones. The FPGA vendors do some of this but they are limited > by the amount of time that they can tie up a chip tester for. Generally > the vendor tests runs in under a second, in my experience it takes about > 20 minutes to really test an FPGA. If you are selling low volume high > value equiptment that contains a large number of FPGAs and loads many > different patterns into them, like and ASIC emulator, then this degree > of testing is necessary. If you are shipping high volume low priced > boards then it's cheaper to live with the one in 5000 fall out. Adding > scan logic to a particular circuit is useless because any change to the > pattern, including another place and route on the same design, will > change which resources are used inside of the FPGA. > > > In article <996308678.26850.0.nnrp-07.9e9832fa@news.demon.co.uk>, "Tim" > <tim@rockylogic.com.nospam.com> wrote: > > > "Andy Botterill" <csm@plymouth2.demon.co.uk> wrote in message > > news:YNNvDUAmacY7EwX0@plymouth2.demon.co.uk... > > > >> >Programmable parts have different test requirements to ASICs, so I > >> >guess the answer to your question is Yes. > >> > >> If you cannot insert scan into an FPGA how do you get a high fault > >> coverage? If you have a poor fault coverage you will be shipping > >> defective parts which is not good for your business. > > > > The FPGA manufacturers do this for you. They use a combination of the > > reprogrammability of the part and, presumably, a few undisclosed test > > structures. > > > > The result is closer to 100% tested than just about any ASIC. All you > > have to worry about is logical and timing errors :)Article: 33531
B. Joshua Rosen wrote: > > The coverage that the FPGA vendors provide is less than perfect but it's > good enough for most applications. In my experience, writing FPGA test > programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs have some > defect although the chance of any one pattern running into that defect is > in the neighborhood of 1 in 100. As a result the chance that any one > pattern will have a problem on any particular FPGA is about 1 in 5000. As > you raise the number of patterns that you run on a particular FPGA the > chances that you will run into a problem approached the 1 in 50 number. > > The way that you test FPGAs is different then the way that you test an > ASIC. FPGAs are mostly interconnect which makes them harder to test. On > the other hand because they are soft you can run an unlimited number of > different test patterns on them, which simplifies the problem as compared > to an ASIC. If you are concerned about shipping an > FPGA with a hidden defect then the way that you solve it is to run a > large number of test patterns on your FPGAs and throw > out the bad ones. <snip> Very interesting stats. Besides shipping product, this also has issues for development itself. With a 1:50 chance of a defect, it would make sense to have two, or maybe three, (and probably with different date codes), test boards that are called on for second opinions when a curly fault arises. As these boards rack up more 'passes', they increase in value :-) Sounds like the tools could benefit from a 'randomise' switch - or maybe a start-from-other-corner placement alogrithm ? -jgArticle: 33532
In the earlier days of FPGAs and ASICs we had some tough times with unintended jitter added to signals targeted at telecom systems. Not a good thing. Something I've noticed in my years of being around these signals is that FPGAs are sensitive (more particularly in some I/O formats) to what else is going on inside - or at the interface to - the chip. You won't have a nanosecond worth of jitter added to things but if you want to keep to under 100ps, you may not have great luck within the FPGA. Keeping the signaling to LVCMOS style outputs (low impedance to each rail) may help because some of the "trash" seen on older programmable devices was riding on top of the logic high voltage and would affect the downward swing. Consider using a single-chip external register to resynch your counter divider to the original clock. The amount of signal feedtrough getting into your clock should be significantly limited at that point. If you need excellent jitter control this might be your quickest way to an end. With nothing else going in to the device and with well filtered rails to the register you should end up with very consistent results. Noise on your supply and noise on your input can both contribute to misplaced edges. - John Andrew Bridger wrote: > Hi, > In my application the FPGA is generating sampling clocks for various ADC's > and DAC's. I was planning to use a divide by N counter then divide by 2 to > generate the 50% duty cycle clock. I am wondering if there is any analysis > I can do to predict how much jitter the counter will add to my ADC clock? > It may be trivial for our application but I'm just not sure. > > The ADC max sampling rate is 8MHz, the ADC device itself has 50 ps aperture > jitter. (I notice a DLL adds 60ps max jitter, not that a DLL is part of the > clock chain in my design) > > Chip is XC2S100/200, Foundation ISE. > > Thanks > AndrewArticle: 33533
If your accumulation is gated don't just clear the register but decide whether to load the accumulator with a zero (not accumulating a sample this period) or a one (accumulating). This will allow a clean reset that doesn't lose a sample. If your accumulator isn't incrementing by one, just change to load value to be either zero or the accumulation value depending on the gate. It works so much nicer when cycles aren't excluded. - John Noddy wrote: > Hi all, > > I am using an accumulator to accumulate N samples. I have a seperate > counter to N which, when reached, will reset the accumulator back to zero to > begin accumulation again. My only problem is that the accumulator misses one > sample in this reset as it goes back to zero. I initially used a synchronous > clear pin, but after spotting the problem, tried to use an asynchronous pin. > My N counter goes high for one clockperiod to reset, so I tried AND gating > it with the clock period (both inverted and non inverted) to only reset for > half a clock period - this still doesn't work and the accumulator still > insists on going back to zero for one clock period. > > Any ideas? > > AdrianArticle: 33534
Date codes don't matter it's really a random process that causes problems. Having several boards is certainly useful in development but you would probably do that anyway. As I say the chances of actually hitting a problem are low, but if you go through 10 ro 20 spins you will likely have a one in a few hundred chance of hitting a defective switch. Josh In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" <jim.granville@designtools.co.nz> wrote: > B. Joshua Rosen wrote: >> >> The coverage that the FPGA vendors provide is less than perfect but >> it's good enough for most applications. In my experience, writing FPGA >> test programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs >> have some defect although the chance of any one pattern running into >> that defect is in the neighborhood of 1 in 100. As a result the chance >> that any one pattern will have a problem on any particular FPGA is >> about 1 in 5000. As you raise the number of patterns that you run on a >> particular FPGA the chances that you will run into a problem approached >> the 1 in 50 number. >> >> The way that you test FPGAs is different then the way that you test an >> ASIC. FPGAs are mostly interconnect which makes them harder to test. On >> the other hand because they are soft you can run an unlimited number of >> different test patterns on them, which simplifies the problem as >> compared to an ASIC. If you are concerned about shipping an FPGA with a >> hidden defect then the way that you solve it is to run a large number >> of test patterns on your FPGAs and throw out the bad ones. > <snip> > > Very interesting stats. > Besides shipping product, this also has issues for development itself. > With a 1:50 chance of a defect, it would make sense to have two, > or maybe three, (and probably with different date codes), test boards > that are called on for second opinions when a curly fault arises. > As these boards rack up more 'passes', they increase in value :-) > > Sounds like the tools could benefit from a 'randomise' switch > - or maybe a start-from-other-corner placement alogrithm ? > > -jgArticle: 33535
In Virtex, you'll get much better results if you use a differential clock standard. If you can't, then not using the any of I/Os in the same I/O bank as your clock input will drastically reduce the jitter introduced. John_H wrote: > In the earlier days of FPGAs and ASICs we had some tough times with unintended > jitter added to signals targeted at telecom systems. Not a good thing. > Something I've noticed in my years of being around these signals is that FPGAs > are sensitive (more particularly in some I/O formats) to what else is going on > inside - or at the interface to - the chip. You won't have a nanosecond worth > of jitter added to things but if you want to keep to under 100ps, you may not > have great luck within the FPGA. Keeping the signaling to LVCMOS style outputs > (low impedance to each rail) may help because some of the "trash" seen on older > programmable devices was riding on top of the logic high voltage and would > affect the downward swing. > > Consider using a single-chip external register to resynch your counter divider > to the original clock. The amount of signal feedtrough getting into your clock > should be significantly limited at that point. If you need excellent jitter > control this might be your quickest way to an end. With nothing else going in > to the device and with well filtered rails to the register you should end up > with very consistent results. Noise on your supply and noise on your input can > both contribute to misplaced edges. > > - John > > Andrew Bridger wrote: > > > Hi, > > In my application the FPGA is generating sampling clocks for various ADC's > > and DAC's. I was planning to use a divide by N counter then divide by 2 to > > generate the 50% duty cycle clock. I am wondering if there is any analysis > > I can do to predict how much jitter the counter will add to my ADC clock? > > It may be trivial for our application but I'm just not sure. > > > > The ADC max sampling rate is 8MHz, the ADC device itself has 50 ps aperture > > jitter. (I notice a DLL adds 60ps max jitter, not that a DLL is part of the > > clock chain in my design) > > > > Chip is XC2S100/200, Foundation ISE. > > > > Thanks > > Andrew -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33536
Where are you getting these numbers from? My experience with FPGAs over the past 13 years and several hundred designs certainly doesn't support such numbers. Is it possible you might have been violating timing??? What devices were you testing? "B. Joshua Rosen" wrote: > Date codes don't matter it's really a random process that causes > problems. Having several boards is certainly useful in development but > you would probably do that anyway. As I say the chances of actually > hitting a problem are low, but if you go through 10 ro 20 spins you will > likely have a one in a few hundred chance of hitting a defective switch. > > Josh > > In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" > <jim.granville@designtools.co.nz> wrote: > > > B. Joshua Rosen wrote: > >> > >> The coverage that the FPGA vendors provide is less than perfect but > >> it's good enough for most applications. In my experience, writing FPGA > >> test programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs > >> have some defect although the chance of any one pattern running into > >> that defect is in the neighborhood of 1 in 100. As a result the chance > >> that any one pattern will have a problem on any particular FPGA is > >> about 1 in 5000. As you raise the number of patterns that you run on a > >> particular FPGA the chances that you will run into a problem approached > >> the 1 in 50 number. > >> > >> The way that you test FPGAs is different then the way that you test an > >> ASIC. FPGAs are mostly interconnect which makes them harder to test. On > >> the other hand because they are soft you can run an unlimited number of > >> different test patterns on them, which simplifies the problem as > >> compared to an ASIC. If you are concerned about shipping an FPGA with a > >> hidden defect then the way that you solve it is to run a large number > >> of test patterns on your FPGAs and throw out the bad ones. > > <snip> > > > > Very interesting stats. > > Besides shipping product, this also has issues for development itself. > > With a 1:50 chance of a defect, it would make sense to have two, > > or maybe three, (and probably with different date codes), test boards > > that are called on for second opinions when a curly fault arises. > > As these boards rack up more 'passes', they increase in value :-) > > > > Sounds like the tools could benefit from a 'randomise' switch > > - or maybe a start-from-other-corner placement alogrithm ? > > > > -jg -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33537
Ray, thanks a lot for your answer. What I am trying to do is implementing a circular queque. The output of cascaded SRL16 will be modified and loaded as input. In the Virtex2 handbook chapter2, page 214, a 32bit shift register is implemented as two SELC16E and a MUXF5. Additionally, the verilog template for component instatiation by Xilinx does have a corresponding SRLC32E_MACRO.v, which is synthesisable. Is there any difference between Virtex and Virtex2 regarding SRL16?Article: 33539
The defect numbers quoted are definitely wrong. Xilinx ships about a million FPGAs per week. Just imagine the uproar in this newsgroup and elsewhere, if one in a thousand, or one in 10,000, or even one in 100,000 were found to malfunction. "Nobody is perfect", but the test coverage is pretty close to 100%. Peter Alfke, Xilinx Applications ==================================== Ray Andraka wrote: > Where are you getting these numbers from? My experience with FPGAs over the > past 13 years and several hundred designs certainly doesn't support such > numbers. Is it possible you might have been violating timing??? What > devices were you testing? > > "B. Joshua Rosen" wrote: > > > Date codes don't matter it's really a random process that causes > > problems. Having several boards is certainly useful in development but > > you would probably do that anyway. As I say the chances of actually > > hitting a problem are low, but if you go through 10 ro 20 spins you will > > likely have a one in a few hundred chance of hitting a defective switch. > > > > Josh > > > > In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" > > <jim.granville@designtools.co.nz> wrote: > > > > > B. Joshua Rosen wrote: > > >> > > >> The coverage that the FPGA vendors provide is less than perfect but > > >> it's good enough for most applications. In my experience, writing FPGA > > >> test programs for an ASIC emulator manufacturer, about 1 in 50 FPGAs > > >> have some defect although the chance of any one pattern running into > > >> that defect is in the neighborhood of 1 in 100. As a result the chance > > >> that any one pattern will have a problem on any particular FPGA is > > >> about 1 in 5000. As you raise the number of patterns that you run on a > > >> particular FPGA the chances that you will run into a problem approached > > >> the 1 in 50 number. > > >> > > >> The way that you test FPGAs is different then the way that you test an > > >> ASIC. FPGAs are mostly interconnect which makes them harder to test. On > > >> the other hand because they are soft you can run an unlimited number of > > >> different test patterns on them, which simplifies the problem as > > >> compared to an ASIC. If you are concerned about shipping an FPGA with a > > >> hidden defect then the way that you solve it is to run a large number > > >> of test patterns on your FPGAs and throw out the bad ones. > > > <snip> > > > > > > Very interesting stats. > > > Besides shipping product, this also has issues for development itself. > > > With a 1:50 chance of a defect, it would make sense to have two, > > > or maybe three, (and probably with different date codes), test boards > > > that are called on for second opinions when a curly fault arises. > > > As these boards rack up more 'passes', they increase in value :-) > > > > > > Sounds like the tools could benefit from a 'randomise' switch > > > - or maybe a start-from-other-corner placement alogrithm ? > > > > > > -jg > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.comArticle: 33540
Hi, Try ICARUS Verilog from: http://icarus.com/eda/verilog/index.html (FAQ says it runs on Windows + Cygwin32) I personally have used SilosIII (from http://www.simucad.com) under Windows 98. Good Luck, Srini -- Srinivasan Venkataramanan ASIC Design Engineer Software & Silicon Systems India Pvt. Ltd. (An Intel company) Bangalore, India "Dave Feustel" <dfeustel@mindspring.com> wrote in message news:9jugr9$5vr$1@slb4.atl.mindspring.net... > Modelsim licensing refuses to work on my computer. > > What alternatives to Modelsim are there for Verilog simulation > on Windows 2000? > > Thanks. > >Article: 33541
http://www.plxtech.com/ ClemensArticle: 33542
You can, just try several times. I had the same problem and finally got the file when I tried a bit later. ClemensArticle: 33543
I have that exact same issue. Xilinx apparently decided it was a mistake to make that chip and so thought it was best to screw everyone who bought it by refusing to support it in future software and crippling support in current software. To design on it, I use Synplify 5.0.8/a (the very last version to work correctly) which only runs on a Sun, and the non-y2k compliant XACT software which only runs on an HP. Fun Fun FUN. Joe <ja.gallegos@boeing.com> wrote in message news:<3B61E7E2.453B694@boeing.com>... > We have it on Sun OS4.1 -- XACT will not work on Solaris > > Werner Dreher wrote: > > > Joe, > > > > on which platform do you use the XACT software? > > We have a legal license for XACT (and the software itself) for > > Sun/SunOS, but the software doesn't run because of an y2k bug > > in the license deamon :-( > > > > Werner Dreher > > > > Joe wrote: > > > > > > Unfortunately, you will have to get a copy of Xilinx's legacy tool called XACT. We use both the Alliance and XACT toolset to support Xilinx legacy and new devices... > > > > > > Tran Cong So wrote: > > > > > > > Hi, > > > > I have now to design on a very old FPGA XC4010 (not E or XL). > > > > The problem is the current development softwware that I am using is Fondation ISE 3.1 and this version does not support for xc4000 family and the old software XACT Step 5.2/Sun is out of license. I tried to contact distributor to get new license but just have got the NOT SUPPORT because the software (XACTStep) is too old. > > > > Does any one have an idea how to be able to work with XC4000 family at this time ? The device is not replacable because replacement means to destroy the PCB. > > > > Thank you very much. > > > > Tran Cong So.Article: 33544
Hy Ray, can you better explain where I've to put the delay of the adder?? Ray Andraka <ray@andraka.com> wrote in message news:<3B590A8D.AE5DCA72@andraka.com>... > Oops, pushed the send too fast.... > > Antonio wrote: > > > 3) If for example one input of the multiplier is 10 bits, also the > > other must be ten bits ?? and how much for the output ??? > > No, you can have both inputs have arbitrary sizes. I believe the latest > Xilinx core generator allows you to set the widths of the inputs > independently. In your case, you do not need multipliers: each > coefficient is a constant that you are either adding to or subtracting > from the sum of products (you are multiplying by either 1 or -1), so > instead, use adder/subtractors with the signal input controlling the a/s > control. Since this is a filter, the signal is delayed in a tapped delay > queue. You can transpose the delay to the output side of the filter, > which allows you to perform the adds in a chain, then the structure is a > chain of adder/subtractors that have one input connected to a constant > coefficient, and the other to the output of the previous adder in the > chain. > > > > > > > 4) By the way , it is important that the inputs of the multiplier have > > the same rate ?? > > No, but they should both change as a result of transitions on the same > clock signal. For example, one input can change on every clock cycle > while the other only changes every 4th cycle. The multiplier in an FPGA > is generally deeply pipelined (takes several clocks before the product of > the inputs appears on the output). > > > > > > > 5) if for example the input of the following adder are both 10 bits, > > how much bits I've to provide for the output. > > In your case, you know the values at the input of the adders, since they > are constants. From these, you can compute the maximum value at the > output of each adder, which in turn tells you how many bits of > significance you need at that node. For example, the coefficient > mentioned above (previous post) could be represented with only 11 bits > instead of the 16 without loosing any more precision than the original > quantization. If you add that with another coefficient of similar > magnitude, you will likely need 12 bits to represent the largest possible > sum without overflow. > > > > > > > I know many of these question could be stupid , but, how I can say, > > I've not the answer so if you have some answer also only at some of > > them I'll be really happy if you tell it to me or also if you redirect > > me to some resource speaking strictly about these thinghs ... > > > > Antonio D'OttavioArticle: 33545
I've got these figures based on the tests that I have written for an ASIC emulator company. Each box has hundreds of FPGAs so we would typically find several bad FPGAs per system. I don't have exact figures for the Virtex family, although they seem to be better than the 4000 family, but the 1 in 50 number held for various incarnations of the 5200 and 4000 series. My tests do not violate any timing restrictions, in fact we run them at various clock rates and failures happen at the lowest speeds as well as for the higher speeds. Before adding these tests we would frequently run into problems with customer patterns, now that's much much rarer although it can still happen occasionally. Even with about 150 test patterns we are only getting coverage of 93% of the PIPs, although the coverage of the PIPs that we actually use is probably closer to 99%. Xilinx has added tests to their test suites which use the same methodology as my tests and it does seem that the Virtex parts have a lower fallout than the older families. I've also used a Xilinx internal tool to determine what my coverage is. I could be wrong about the chances of a particular pattern hitting a defect but I'm not wrong about defect rate. With my test patterns I will generally see 2 or 3 patterns fail on a bad part out of a suite of approximately 150. However my patterns are designed for maximum coverage, it's possible that a typical pattern has only a 1 on 500 chance of seeing the defect as opposed to the 1 in 50 that I see. So if 1 in 50 parts has a defect and 1 in 500 patterns hits it then you would see a 1 in 25000 fallout in real systems. If my test patterns are closer to the real world then the system fallout rate would be 1 in 2500. Either way the system fallout rate is low enough that you wouldn't notice it. Also without a test suite like I wrote for the emulator company you would have no way of knowing that it was the FPGA that caused the problem, the board will simply be declared a dog and tossed aside on the dog board pile. In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka" <ray@andraka.com> wrote: > Where are you getting these numbers from? My experience with FPGAs over > the past 13 years and several hundred designs certainly doesn't support > such numbers. Is it possible you might have been violating timing??? > What devices were you testing? > > "B. Joshua Rosen" wrote: > >> Date codes don't matter it's really a random process that causes >> problems. Having several boards is certainly useful in development but >> you would probably do that anyway. As I say the chances of actually >> hitting a problem are low, but if you go through 10 ro 20 spins you >> will likely have a one in a few hundred chance of hitting a defective >> switch. >> >> Josh >> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" >> <jim.granville@designtools.co.nz> wrote: >> >> > B. Joshua Rosen wrote: >> >> >> >> The coverage that the FPGA vendors provide is less than perfect but >> >> it's good enough for most applications. In my experience, writing >> >> FPGA test programs for an ASIC emulator manufacturer, about 1 in 50 >> >> FPGAs have some defect although the chance of any one pattern >> >> running into that defect is in the neighborhood of 1 in 100. As a >> >> result the chance that any one pattern will have a problem on any >> >> particular FPGA is about 1 in 5000. As you raise the number of >> >> patterns that you run on a particular FPGA the chances that you will >> >> run into a problem approached the 1 in 50 number. >> >> >> >> The way that you test FPGAs is different then the way that you test >> >> an ASIC. FPGAs are mostly interconnect which makes them harder to >> >> test. On the other hand because they are soft you can run an >> >> unlimited number of different test patterns on them, which >> >> simplifies the problem as compared to an ASIC. If you are concerned >> >> about shipping an FPGA with a hidden defect then the way that you >> >> solve it is to run a large number of test patterns on your FPGAs and >> >> throw out the bad ones. >> > <snip> >> > >> > Very interesting stats. >> > Besides shipping product, this also has issues for development >> > itself. >> > With a 1:50 chance of a defect, it would make sense to have two, >> > or maybe three, (and probably with different date codes), test boards >> > that are called on for second opinions when a curly fault arises. >> > As these boards rack up more 'passes', they increase in value :-) >> > >> > Sounds like the tools could benefit from a 'randomise' switch >> > - or maybe a start-from-other-corner placement alogrithm ? >> > >> > -jg > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. 401/884-7930 Fax > 401/884-7950 > email ray@andraka.com > http://www.andraka.com > >Article: 33547
The Athlon will probably be much faster. The P4 has a very long pipeline and really suffers on any code that takes a lot of branches. The relevant benchmark is probably the Linux kernel compile time where the Althon is about twice as fast as the P4. The place where the P4 shines is in highly vectorizable code like MPEG encoding. Place and Route and simulation programs aren't vectorized at all. Both of those tasks are compiler like so the Athlon is likely to be the best choice. In article <9j49st$9m4@dispatch.concentric.net>, "Pete Fraser" <pete@rgb.com> wrote: > We're upgrading a few of our old 800 MHz PIII machines to speed Xilinx > design. > > Has anybody published benchmarks to indicate if we'd be better of with > fast Athlons or Fast P 4s? > > Thanks. > >Article: 33548
Hi all,
I made this saturable adder from converting AHDL code in a previous
message.
It adds signed HEX numbers together, but doesn't roll-over if there's
an overflow.
I'm using leonardo-spectrum to generate an edif netlist, which is
compiled by altera maxplus2.
Where and how, if any, can i add technology-dependent optimizations
such as carry chains etc?
Also, are there such things as VHDL debuggers where you can single-
step thru the code and see what all the signals and variables are
doing?
LIBRARY ieee;
USE ieee.std_logic_1164.all;
PACKAGE types IS
subtype word is std_ulogic_vector(3 downto 0);
END types;
LIBRARY ieee;
USE ieee.std_logic_1164.all;
use work.types.all;
ENTITY saturable_adder IS
port(
a,b: in word;
s: out word
);
END adder;
LIBRARY ieee;
USE ieee.std_logic_1164.all;
use work.types.all;
ARCHITECTURE total OF saturable_adder IS
BEGIN
behav: PROCESS (a,b) is
variable sum: word;
variable carry_in,carry_out: std_ulogic;
constant msb:integer:=word'left;
BEGIN
carry_in:='0';
for ndx in 0 to (word'left-1) loop
sum(ndx):=a(ndx) xor b(ndx) xor carry_in;
carry_out:=(a(ndx) and b(ndx)) or (a(ndx) and carry_in) or (b(ndx)
and carry_in);
carry_in:=carry_out;
end loop;
sum(msb):=a(msb) xor b(msb) xor carry_in;
if( (a(msb) and b(msb) and not carry_in)='1' )
then
sum:=(others=>'0');
sum(msb):='1';
elsif( (not a(msb) and not b(msb) and carry_in)='1' )
then
sum:=(others=>'1');
sum(msb):='0';
end if;
s<=sum;
END PROCESS behav;
END total;
--
___ ___
/ /\ / /\
/ /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\
/__/ / Victoria, Australia, Down-Under /__/\/\/
\ \ / http://home.iprimus.com.au/rjshaw \ \/\/
\__\/ \__\/
Article: 33549I am quite new to this and am having all manner of problems designing a counter with the schematic capture side of Xilinx's WebPack. I am trying to implement a 16-bit binary counter using the library model CB16CE the output of which is read through 2 8-bit tri-state buffers hooked to a data bus. But no matter how I split/wire up the busses between the devices the WebPack compilation process fails with errors. Some say I have nothing connected to the 16 outputs of the counter, when from the schematic I have. If I try another way it complains about net names. Could some kind sole email me a schematic of such a counter that I could investigate? I've been through the help system specifically the part about busses but I can't get a grip on what I'm doing wrong. Many thanks JN
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