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
On Nov 11, 7:29=A0pm, Gabor <ga...@alacron.com> wrote: > On Nov 11, 12:45=A0pm, Guru <ales.gor...@gmail.com> wrote: > > > > > On Nov 11, 6:27=A0pm, Guru <ales.gor...@gmail.com> wrote: > > > > Hello everybody, > > > > I am developing a camera with a Spartan3A DSP and a sensor which uses > > > 1.8V LVDS. The Spartan 3A DSP datasheet says that only 2.5 and 3.3V > > > LVDS is supported. The signal rate is 108MHz DDR. > > > > Any suggestions what should I do? Specify in UCF LVDS_25 and pray to > > > work OK? > > > It is pretty much the same with a Spartan6. > > > > Best regards, > > > > Ales > > > I forgot to mention that transmitter (sensor) swing is typically 150mV > > (100-200mV) and need 100ohm termination. For termination I planned to > > use 110ohm IOB termination. > > > Best reagards, > > > Ales > > LVDS is LVDS regardless of the supply voltage. =A01.8V, 2.5V and > 3.3V LVDS all have the same common-mode voltage and differential > swing. =A0There should be mo problem interfacing these signals > to the Spartan 3A. =A0If the Spartan 3A doesn't have integrated > differential termination I would suggest using an external > resistor rather than burning up internal thevenin termination > current. > > Regards, > Gabor As far as i know It has internal differential termination. AlesArticle: 144126
Hi, On a board here I always load an EPCS16 without errors, and the FPGA (cyclone III) works as expected. But Quartus II it does not verify the EPCS16 it reports operation failed. However yesterday I had it verifying ok for more than 2 hours and today if fails again to verify. All other operations seem to work fine, erasing, examining, blank check etc. Is it a defective chip or anyone else has seen this behavior ? Luis C. p.s. Quartus II 8.1 / AS w/USB Blaster.Article: 144127
My requirement is to replace fifteen 7 segment display drivers using cpld logic. Total I/O connected to display will be 15*8=120. Each pin has to sink around 8mA, so Im planning to go for Xilinx XC95288XL CPLD. My doubt is that can the cpld sink 120 lines of 8mA simultaneously?Article: 144128
what is ngc file generated by Xilinx ISE. Can we look into that file?Article: 144129
On Nov 12, 3:09=A0pm, "stuboy" <guanxin1...@gmail.com> wrote: > what is ngc file generated by Xilinx ISE. Can we look into that file? you can. if you really have to, its two times packaged ASCII netlist AnttiArticle: 144130
>On Nov 12, 3:09=A0pm, "stuboy" <guanxin1...@gmail.com> wrote: >> what is ngc file generated by Xilinx ISE. Can we look into that file? > >you can. if you really have to, its two times packaged ASCII netlist > >Antti > Thank you. This file format is special to Xilinx, or is general used by many other EDA vendors? Where can I find some specific info about this file? I tried wiki, google, there are no good answer. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144131
On Nov 12, 1:09=A0pm, "stuboy" <guanxin1...@gmail.com> wrote:
> what is ngc file generated by Xilinx ISE. Can we look into that file?
Easiest thing is to run the "netgen" program to generate a VHDL or
Verilog version of the NGC netlist.
-Ben-
Article: 144132LC pisze: > Hi, > > On a board here I always load an EPCS16 without errors, > and the FPGA (cyclone III) works as expected. > > But Quartus II it does not verify the EPCS16 it reports > operation failed. However yesterday I had it verifying > ok for more than 2 hours and today if fails again to verify. > > All other operations seem to work fine, erasing, examining, > blank check etc. > > Is it a defective chip or anyone else has seen this behavior ? > > Luis C. > > p.s. Quartus II 8.1 / AS w/USB Blaster. Try with Jtag and indirect EPCS programming mode. AdamArticle: 144133
nishad, Why do you doubt? If the data sheet says an IO may sink 8 mA, then why not ALL IO at 8 mA? No problem. The only concern here is ground/Vcc bounce: yes, 128 * 8mA is a lot of current, and you should make sure your pcb has good power and ground planes, and the recommended bypass capacitors. AustinArticle: 144134
On Nov 12, 10:22=A0am, austin <aus...@xilinx.com> wrote: > nishad, > > Why do you doubt? =A0If the data sheet says an IO may sink 8 mA, then > why not ALL IO at 8 mA? > > No problem. > > The only concern here is ground/Vcc bounce: =A0yes, 128 * 8mA is a lot > of current, and you should make sure your pcb has good power and > ground planes, and the recommended bypass capacitors. > > Austin On the other hand if you really need 120 I/O's you may want to consider breaking it up into two packages. It might even save board area over one very large package. Of course that depends on how may additional pins you use to split the design in two. Sometimes it comes almost free, for example a two-wire serial bus. 1 Amp of switching current in a large PQFP results in lots of ground and Vcc bounce due to the large package lead inductance. Generally speaking, when using quad flat packs, the smaller the better because the die size of the chip inside gets closer to the overall package size as you get smaller, so the lead inductance is smaller, too. I'm not sure how it works with mature CPLD devices, but for FPGA's at least the price per I/O is better in smaller devices as well. Regards, GaborArticle: 144135
nishad wrote: > My requirement is to replace fifteen 7 segment display drivers using cpld > logic. > Total I/O connected to display will be 15*8=120. > Each pin has to sink around 8mA, so Im planning to go for Xilinx XC95288XL > CPLD. > My doubt is that can the cpld sink 120 lines of 8mA simultaneously? > > Do you actually NEED to drive them all with DC? Have you looked at multiplexing? One oddity of the eye's response is that the LEDs appear 90% as bright, even when only pulsed at 1/10th duty cycle. You can save a lot of pins, drive current, current limit resistors, etc. doing this. For 15 digits, you might use two sets of segment outputs, and have two digits illuminated at the same time. You would need either 8 or 15 digit select drivers, but those could be just SOT-23 P-channel FETs (or PNP transistors, but that requires a base resistor.) So, instead of 120 pins and 120 resistors, you go down to 16 resistors and 24 pins! If you don't have a lot of other logic in that CPLD, you can go down to a coolrunner in the 44 or 100-pin package. JonArticle: 144136
On Nov 13, 2:08=A0am, "nishad" <abnis...@gmail.com> wrote: > My requirement is to replace fifteen 7 segment display drivers using cpld > logic. > Total I/O connected to display will be 15*8=3D120. > Each pin has to sink around 8mA, so Im planning to go for Xilinx XC95288X= L > CPLD. > My doubt is that can the cpld sink 120 lines of 8mA simultaneously? A XC95288XLis an expensive shift register ? :) or is it doing other things as well ? LED drive is generally better done with smaller, daisy chained CPLDs, or even just shift registers. -jgArticle: 144137
On Nov 9, 6:04=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Nov 6, 11:35=A0am, Mike Santarini <mike.santar...@gmail.com> wrote: > > > Hi folks, we just finished publishing the fall edition of Xcell > > Journal, which has a cover story focus on the expanding role of FPGAs > > in the Global Information Grid. The issue also has a lot of great > > methodology and how-to content. We're now making it available in a one- > > click download as well as in the Ceros (flash) format. I hope you > > enjoy it.http://www.xilinx.com/publications/xcellonline/index.htm > > Hi Mike, > I want to be a subscriber of hardcopy of Xcell. Does Xilinx still > provide hardcopy of Xcell for free? I couldn't find the subject in the > Xcell website so that I think Xilinx may have canceled it long ago? > > Thank you. > > Weng Hi Weng, First of all, thanks for reading. Unfortunately, we no longer offer direct mailing print subscriptions (and haven't for a few years) but we do still print anywhere from 5,000 to 10,000 issues of each issue. Our sales force can order those and if you have a local sales person you deal with or even a distributor at Avnet or Nu Ho, they can order and deliver the print issues to you. If you live in San Jose and near our offices, you can always run into the lobby of Building 4 and see if we have one on the table. I receive requests for print copies quite often and while it probably isn't feasible to reinstate direct mail subscriptions (and the costs associated with mailing literature across the globe), we may offer users a way to directly order the issues on- demand from our printer. That of course would mean you would have to pay the printer for each copy, which perhaps users would be willing to do. I personally prefer the look, feel and true craftsmanship of a quality print magazines, but of course I'm an old-school journalist. Thanks again for reading. I hope you enjoy our pub and will even contribute an article or viewpoint in the near future (that is, if you are a Xilinx user). Cheers, MikeArticle: 144138
On Nov 12, 2:43=A0pm, Mike Santarini <mike.santar...@gmail.com> wrote: > On Nov 9, 6:04=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On Nov 6, 11:35=A0am, Mike Santarini <mike.santar...@gmail.com> wrote: > > > > Hi folks, we just finished publishing the fall edition of Xcell > > > Journal, which has a cover story focus on the expanding role of FPGAs > > > in the Global Information Grid. The issue also has a lot of great > > > methodology and how-to content. We're now making it available in a on= e- > > > click download as well as in the Ceros (flash) format. I hope you > > > enjoy it.http://www.xilinx.com/publications/xcellonline/index.htm > > > Hi Mike, > > I want to be a subscriber of hardcopy of Xcell. Does Xilinx still > > provide hardcopy of Xcell for free? I couldn't find the subject in the > > Xcell website so that I think Xilinx may have canceled it long ago? > > > Thank you. > > > Weng > > Hi Weng, > > First of all, thanks for reading. Unfortunately, we no longer offer > direct mailing print subscriptions (and haven't for a few years) but > we do still print anywhere from 5,000 to 10,000 issues of each issue. > Our sales force can order those and if you have a local sales person > you deal with or even a distributor at Avnet or Nu Ho, they can order > and deliver the print issues to you. If you live in San Jose and near > our offices, you can always run into the lobby of Building 4 and see > if we have one on the table. I receive requests for print copies quite > often and while it probably isn't feasible to reinstate direct mail > subscriptions (and the costs associated with mailing literature across > the globe), we may offer users a way to directly order the issues on- > demand from our printer. That of course would mean you would have to > pay the printer for each copy, which perhaps users would be willing to > do. I personally prefer the look, feel and true craftsmanship of a > quality print magazines, but of course I'm an old-school journalist. > Thanks again for reading. I hope you enjoy our pub and will even > contribute an article or viewpoint in the near future (that is, if you > are a Xilinx user). > > Cheers, > > Mike- Hide quoted text - > > - Show quoted text - Hi Mike, I have a good idea for XCell. I always think the XCell magazine one of the best in FPGA engineering and worth careful reading, and expecially articles in the How-To page. Can you print and send through email all How-To articles in different editions in one volumn? These articles are worth reserving and reading for many years, and some are the seminal papers and of great value in FPGA engineering. WengArticle: 144139
>nishad, > >Why do you doubt? If the data sheet says an IO may sink 8 mA, then >why not ALL IO at 8 mA? > >No problem. > >The only concern here is ground/Vcc bounce: yes, 128 * 8mA is a lot >of current, and you should make sure your pcb has good power and >ground planes, and the recommended bypass capacitors. > >Austin > Thanks a lot for the reply... --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144140
Hello,
I have an ASIC design using internal tri-state multi-sources buses
like below:
assign tbus = a_en ? a : Hiz;
assign tbus = b_en ? b : Hiz;
When implementing to FPGA, I found I can't strobe the right data from
the bus. After analyze the code, I think it's because the strobe
signal comes later than the enable signals for each source. For a real
tri-state bus, the value can still float on the bus so the ASIC can
work.
For the FPGA, I think I need convert the bus using latch to contain
the value when the enable signal has gone, so I designed the code like
below:
always @(*)
begin
if (a_en)
tbus <= a;
else if (b_en)
tbus <= b;
end
However the circuit doesn't work as I expected, I examined the
synthesis result, looks like my code is translated to a mux and a
latch like below:
assign temp = a_en ? a : b;
always @(*)
if (a_en | b_en)
tbus <= temp;
It seems Verilog doesn't accept an incomplete Mux, so b is set as
default.
Can anyone gives me some advise?
Thanks
Article: 144141On Nov 13, 9:19=A0am, jay <heavenf...@gmail.com> wrote: > Hello, > > I have an ASIC design using internal tri-state multi-sources buses > like below: > assign tbus =3D a_en ? a : Hiz; > assign tbus =3D b_en ? b : Hiz; > > When implementing to FPGA, I found I can't strobe the right data from > the bus. After analyze the code, I think it's because the strobe > signal comes later than the enable signals for each source. For a real > tri-state bus, the value can still float on the bus so the ASIC can > work. > > For the FPGA, I think I need convert the bus using latch to contain > the value when the enable signal has gone, so I designed the code like > below: > always @(*) > begin > =A0 if (a_en) > =A0 =A0 tbus <=3D a; > =A0 else if (b_en) > =A0 =A0 tbus <=3D b; > end > > However the circuit doesn't work as I expected, I examined the > synthesis result, looks like my code is translated to a mux and a > latch like below: > assign temp =3D a_en ? a : b; > always @(*) > =A0 if (a_en | b_en) > =A0 =A0 tbus <=3D temp; > > It seems Verilog doesn't accept an incomplete Mux, so b is set as > default. > > Can anyone gives me some advise? > > Thanks The problem is using a_en as both the mux select and the latch gate doesn't give any hold time when latching the A input. You may want to recode it using a S/R latch for the mux select to meet the hold time after a_en. As you have started to discover, FPGA's are not great at asynchronous sequential logic. At least they do contain gated latches, and you should check the synthesis results to be sure the latch is in use rather than trying to use LUT's as latch gate elements. Which FPGA family are you using? Regards, GaborArticle: 144142
On Nov 13, 6:19=A0am, jay <heavenf...@gmail.com> wrote:
> Hello,
>
> I have an ASIC design using internal tri-state multi-sources buses
> like below:
> assign tbus =3D a_en ? a : Hiz;
> assign tbus =3D b_en ? b : Hiz;
>
> When implementing to FPGA, I found I can't strobe the right data from
> the bus. After analyze the code, I think it's because the strobe
> signal comes later than the enable signals for each source. For a real
> tri-state bus, the value can still float on the bus so the ASIC can
> work.
>
> For the FPGA, I think I need convert the bus using latch to contain
> the value when the enable signal has gone, so I designed the code like
> below:
> always @(*)
> begin
> =A0 if (a_en)
> =A0 =A0 tbus <=3D a;
> =A0 else if (b_en)
> =A0 =A0 tbus <=3D b;
> end
>
> However the circuit doesn't work as I expected, I examined the
> synthesis result, looks like my code is translated to a mux and a
> latch like below:
> assign temp =3D a_en ? a : b;
> always @(*)
> =A0 if (a_en | b_en)
> =A0 =A0 tbus <=3D temp;
>
> It seems Verilog doesn't accept an incomplete Mux, so b is set as
> default.
>
> Can anyone gives me some advise?
>
> Thanks
What is your setup/hold of the data and the enables? You may need to
code this as
latches followed by a mux and not a mux followed by a latch.
always @(*)
if (a_en | (a & a_hold)
a_hold =3D a;
always @(*)
if (b_en | (b & b_hold)
b_hold =3D b;
assign t_bus =3D a_en ? a_hold : b_hold;
Make sure that the synthesizer infers the latches properly, you may
need to use the simpler:
always @(&)
if (b_en)
b_hold =3D b;
Adding the extra term in the "if" solves a race condition when the
latch enable is removed and you're
making the latch out of discrete gates. This is probably not needed
since the latch inferred by synthesis
should alreay take care of this.
I hope this helps!
John Providenza
Article: 144143Having just done on gigantic Merrick1 with it's 101 FPGAs we thought we would do a small board this time. Drigmorn2 http://www.enterpoint.co.uk/drigmorn/drigmorn2.html is aimed at student lab and the small end industrial controller type markets. It's MicroBlaze friendly with 128Mbit SPI Flash and 256Mbit of SDRAM. John Adair Enterpoint Ltd.Article: 144144
On Nov 6, 1:13=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Nov 6, 8:14=A0am, Mark McDougall <ma...@vl.com.au> wrote: > > > > > I've had it up to the eyeballs with Xilinx tools now. I'm seriously rea= dy > > to go postal in the lobby of Xilinx HQ. I don't expect perfection but t= his > > really is beyond a joke. > > > Can someone please put me out of my misery, and finally admit that you > > have _all_ been having me on for the past few years now! :O ...that it = has > > all been an elaborate hoax instigated by someone I offended in a past > > life. ...that a team of engineers has been working for years to produce= an > > IDE that crashes randomly, and steadfastly refuses to launch tools on > > Tuesday mornings and Friday afternoons? ...working for years on a > > synthesizer that removes random bits of logic, or sits spinning in an > > infinite loop on an entity that works in another project? ...that corru= pts > > my project file bi-monthly. > > > And worst of all - _you_ lot, telling me that Xilinx actually works, an= d > > that you _can_ use it for more than flashing LEDs on the Spartan starte= r > > kit. And I was gullible enough to believe you! :O :( > > > I've seen the light. You _cannot_ convince me that it is possible to > > produce a commercial product in silicon using these tools. Period. > > > Regards, > > > -- > > Mark McDougall, Engineer > > Virtual Logic Pty Ltd, <http://www.vl.com.au> > > 21-25 King St, Rockdale, 2216 > > Ph: +612-9599-3255 Fax: +612-9599-3266 > > Mark, > > you are taking it one level higher than I, I think i have said in > public > years ago that Xilinx has totally lost control over its software > development > and that their tools would come "completly unuseable" by the time 40nm > FPGA's come out to the market (unless they FIX their software > development flow!) > > well Xilinx 40nm FPGA's are not yet on stock at digikey, so based on > that > and on my prediction Xilinx has still time to reach the complete > useless > status with their software > > Antti That sounds bad for the X-sw team. I think that's the area they may want to check out first. Yup, they- themselves have bugs to de-bugArticle: 144145
On Nov 13, 10:45=A0pm, Gabor <ga...@alacron.com> wrote: > On Nov 13, 9:19=A0am, jay <heavenf...@gmail.com> wrote: > > > > > Hello, > > > I have an ASIC design using internal tri-state multi-sources buses > > like below: > > assign tbus =3D a_en ? a : Hiz; > > assign tbus =3D b_en ? b : Hiz; > > > When implementing to FPGA, I found I can't strobe the right data from > > the bus. After analyze the code, I think it's because the strobe > > signal comes later than the enable signals for each source. For a real > > tri-state bus, the value can still float on the bus so the ASIC can > > work. > > > For the FPGA, I think I need convert the bus using latch to contain > > the value when the enable signal has gone, so I designed the code like > > below: > > always @(*) > > begin > > =A0 if (a_en) > > =A0 =A0 tbus <=3D a; > > =A0 else if (b_en) > > =A0 =A0 tbus <=3D b; > > end > > > However the circuit doesn't work as I expected, I examined the > > synthesis result, looks like my code is translated to a mux and a > > latch like below: > > assign temp =3D a_en ? a : b; > > always @(*) > > =A0 if (a_en | b_en) > > =A0 =A0 tbus <=3D temp; > > > It seems Verilog doesn't accept an incomplete Mux, so b is set as > > default. > > > Can anyone gives me some advise? > > > Thanks > > The problem is using a_en as both the mux select and the latch > gate doesn't give any hold time when latching the A input. > You may want to recode it using a S/R latch for the mux select > to meet the hold time after a_en. =A0As you have started to > discover, FPGA's are not great at asynchronous sequential logic. > At least they do contain gated latches, and you should check the > synthesis results to be sure the latch is in use rather than > trying to use LUT's as latch gate elements. =A0Which FPGA family > are you using? > > Regards, > Gabor Good idea, S/R latch should work if I only had two enables, but there's more in my design. I think I need a state machine. I'm using spartan-3a, it has d-latch resources, probably no sr-latch.Article: 144146
On Nov 13, 10:58=A0pm, johnp <jprovide...@yahoo.com> wrote: > On Nov 13, 6:19=A0am, jay <heavenf...@gmail.com> wrote: > > > > > Hello, > > > I have an ASIC design using internal tri-state multi-sources buses > > like below: > > assign tbus =3D a_en ? a : Hiz; > > assign tbus =3D b_en ? b : Hiz; > > > When implementing to FPGA, I found I can't strobe the right data from > > the bus. After analyze the code, I think it's because the strobe > > signal comes later than the enable signals for each source. For a real > > tri-state bus, the value can still float on the bus so the ASIC can > > work. > > > For the FPGA, I think I need convert the bus using latch to contain > > the value when the enable signal has gone, so I designed the code like > > below: > > always @(*) > > begin > > =A0 if (a_en) > > =A0 =A0 tbus <=3D a; > > =A0 else if (b_en) > > =A0 =A0 tbus <=3D b; > > end > > > However the circuit doesn't work as I expected, I examined the > > synthesis result, looks like my code is translated to a mux and a > > latch like below: > > assign temp =3D a_en ? a : b; > > always @(*) > > =A0 if (a_en | b_en) > > =A0 =A0 tbus <=3D temp; > > > It seems Verilog doesn't accept an incomplete Mux, so b is set as > > default. > > > Can anyone gives me some advise? > > > Thanks > > What is your setup/hold of the data and the enables? =A0You may need to > code this as > latches followed by a mux and not a mux followed by a latch. > > always @(*) > =A0 if (a_en | (a & a_hold) > =A0 =A0 =A0a_hold =3D a; > > always @(*) > =A0 if (b_en | (b & b_hold) > =A0 =A0 b_hold =3D b; > > assign t_bus =3D a_en ? a_hold : b_hold; > > Make sure that the synthesizer infers the latches properly, you may > need to use the simpler: > =A0 always @(&) > =A0 =A0 =A0if (b_en) > =A0 =A0 =A0 =A0 =A0b_hold =3D b; > > Adding the extra term in the "if" solves a race condition when the > latch enable is removed and you're > making the latch out of discrete gates. =A0This is probably not needed > since the latch inferred by synthesis > should alreay take care of this. > > I hope this helps! > > John Providenza I haven't seen "always @(&)" before, a new syntax?Article: 144147
On Nov 13, 11:00=A0am, jay <heavenf...@gmail.com> wrote: > On Nov 13, 10:45=A0pm, Gabor <ga...@alacron.com> wrote: > > > > > On Nov 13, 9:19=A0am, jay <heavenf...@gmail.com> wrote: > > > > Hello, > > > > I have an ASIC design using internal tri-state multi-sources buses > > > like below: > > > assign tbus =3D a_en ? a : Hiz; > > > assign tbus =3D b_en ? b : Hiz; > > > > When implementing to FPGA, I found I can't strobe the right data from > > > the bus. After analyze the code, I think it's because the strobe > > > signal comes later than the enable signals for each source. For a rea= l > > > tri-state bus, the value can still float on the bus so the ASIC can > > > work. > > > > For the FPGA, I think I need convert the bus using latch to contain > > > the value when the enable signal has gone, so I designed the code lik= e > > > below: > > > always @(*) > > > begin > > > =A0 if (a_en) > > > =A0 =A0 tbus <=3D a; > > > =A0 else if (b_en) > > > =A0 =A0 tbus <=3D b; > > > end > > > > However the circuit doesn't work as I expected, I examined the > > > synthesis result, looks like my code is translated to a mux and a > > > latch like below: > > > assign temp =3D a_en ? a : b; > > > always @(*) > > > =A0 if (a_en | b_en) > > > =A0 =A0 tbus <=3D temp; > > > > It seems Verilog doesn't accept an incomplete Mux, so b is set as > > > default. > > > > Can anyone gives me some advise? > > > > Thanks > > > The problem is using a_en as both the mux select and the latch > > gate doesn't give any hold time when latching the A input. > > You may want to recode it using a S/R latch for the mux select > > to meet the hold time after a_en. =A0As you have started to > > discover, FPGA's are not great at asynchronous sequential logic. > > At least they do contain gated latches, and you should check the > > synthesis results to be sure the latch is in use rather than > > trying to use LUT's as latch gate elements. =A0Which FPGA family > > are you using? > > > Regards, > > Gabor > > Good idea, S/R latch should work if I only had two enables, but > there's more in my design. I think I need a state machine. > > I'm using spartan-3a, it has d-latch resources, probably no sr-latch. Actually there are flip-flops with async preset and clear. If you tie off the clock and D it becomes an SR latch. Regards, GaborArticle: 144148
All, http://tinyurl.com/yd7p3ah Above is a discussion of how Xilinx will now list the contribution of alpha particles emitted by the packaging materials in their latest generation of FPGA devices as a contributor to soft errors. Obviously, when something becomes significant, it has to be taken into account! All other manufacturers with-hold this information, as it is VERY BAD, and the alpha contribution to upsets is from 1 to 10 times as bad as the atmospheric neutron contribution in the latest technology nodes (45/40). In Virtex 6, and Spartan 6, not only is the intrinsic soft failure rate low, it is now lower than that of ASIC and ASSP devices. We crossed over (were equal) at 65nm. This rate of increase in soft error rate was predicted by Robert Bauman of TI in 2005, and it now has come to pass ... AustinArticle: 144149
On Nov 13, 12:25=A0pm, austin <aus...@xilinx.com> wrote: > All, > > forums.xilinx.com/t5/PL... > > Above is a discussion of how Xilinx will now list the contribution of > alpha particles emitted by the packaging materials in their latest > generation of FPGA devices as a contributor to soft errors. > > Obviously, when something becomes significant, it has to be taken into > account! > > All other manufacturers with-hold this information, as it is VERY BAD, > and the alpha contribution to upsets is from 1 to 10 times as bad as > the atmospheric neutron contribution in the latest technology nodes > (45/40). > > In Virtex 6, and Spartan 6, not only is the intrinsic soft failure > rate low, it is now lower than that of ASIC and ASSP devices. =A0We > crossed over (were equal) at 65nm. > > This rate of increase in soft error rate was predicted by Robert > Bauman of TI in 2005, and it now has come to pass ... > > Austin I seem to recall that in the very early days of dynamic RAM, it was discovered that ceramic packaged parts had more soft errors than plastic parts. This led to the discovery of package-generated alpha particles. Are ceramics still used in the new packages, or are some other materials emitting alpha particles? Regards, Gabor
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