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
Wayne Turner wrote: > > >1- FPGAs allow you to weed out 'all' the BAD devices > > via extensive device testing. > >3- FPGAs do not ever just flip a program bit randomly. > > Actually, they can. In flight applications for example, a heavy ion hitting > an SRAM cell can cause the value to change and thereby change the > functionality of the circuit without being able to detected before the > functionality has already changed. > > Read up on single-event upsets in SRAM devices (both memory and logic). > > >4- Loading of configuation data into an FPGA is 100% reliable > > if timing and voltage margins are met. > > > >If anyone has any evidence contrary to the above assumptions > >I'd like to see it. > > [...] > > See above... Yes, given enough energy, an SRAM cell in the FPGA array can be upset. The point I was making is that upset to the FPGA SRAM cell takes considerably more energy than the SRAM used for microprocessors to cause upset. This is due to the longer write cycle for the FPGA. The FPGA cells are deliberately designed with long write cycles to reduce the probability of upset. Since microprocessors are fairly well accepted in safety critical applications, the more stable FPGA cell should also be acceptable. In an application that could seriously compromise safety, the design has to be made fault tolerant regardless of what devices are used. This may mean duplicate circuits with voting logic, signal monitoring, extra circuits for data integrity checking (eg. parity checking or duplicate data paths) configuration monitoring via readback (in the case of SRAM FPGAs) or other measures. The later Xilinx parts do allow a CRC to be computed on the bitstream to verify the chip got what you thought you sent (implementation of the CRC is very easy). Additionally, they offer the ability to read the actual device state back. This permits you to monitor the configuration to catch any cell upsets. It is worth noting that the OTP devices (especially the eprom and eeprom types) are also susceptible to upset by high energy particles/radiation. In those cases, there is nothing that can be done short of reprogramming, or in some cases replacing the device. In the case of the SRAM FPGA, the fix is usually as simple as reloading it. From all the evidence I have seen to date, the SRAM devices are no less reliable than the OTP counterparts or dedicated ASICs (and are likely more reliable due to the degree of testing available). They do however offer the significant advantages of easy 100% functional testing, configuration monitoring and reprogrammability (both for time division multiplexing of the hardware and for product upgrades/enhancements/patches) -Ray Andraka, P.E. Chairman, the Andraka Consulting Group 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://www.ids.net/~randrakaArticle: 4851
Gerhard Hoffmann wrote: > So many questions... I'm really glad that a sailplane has no electronic > flight critical parts. > Then again, you would be shocked to see the insides of the avionics in my airplane (or any other general aviation plane for that matter). To put it bluntly, my PC is designed and constructed better than most of the avionics gear out there...and to think I stake my life on that equipment everytime I fly in weather! -Ray Andraka, P.E. Chairman, the Andraka Consulting Group 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://www.ids.net/~randrakaArticle: 4852
I've got a CPLD I've programmed via VHDL. I've inserted a test array (called test) to make sure some conditionals have been reached. Once set in a conditional to '1', the test vectors should stay latched until the system is reset in which case they are reset to '0': p2: process (rst,clk) begin if (rst='1') then ..... test(2)<='0'; elsif (rising_edge(clk)) then if(oen='0' and irq='0' and ....) then .... test(2)<='1'; end if; end process p2; However the test vectors keep toggeling even though reset never comes on again. Am I missing something with respect to how I think VHDL is describing my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated to 100Mhz) resulting in problems or can I have some race condition induced by poor code, or any other ideas? Functional simulations does not indicate any problems. Thanks in advance, Richard Gaupsas rgaupsas@cts.comArticle: 4853
Arnie Frisch wrote: > >In article <Pine.BSI.3.91.961217220540.8995A-100000@malasada.lava.net> "Alvin E. Toda" <aet@lava.net> writes: >>On 18 Dec 1996, Jan Vorbrueggen wrote: >> >>>jet@eskimo.com (James Thiele) writes: >..... >.... >... >.. >>Even here you have the backup of a co-pilot. If you look >>at the whole system, certainly there are airplane incidents each year >>but the accident rate is probably a lot lower than the auto accident >>rate. It's a lot safer to ride a plane than a car. > >That is a common misconception combined with an incorrect interpretation >of statistics. Traveling a given DISTANCE by commercial airline is safer >than traveling the same DISTANCE by car. Traveling for a given TIME on >a commercial airline is likely to be more dangerous than traveling for the >same time by car. This is true if the safety ratio is less than the speed ratio; out on the interstate cars hit 60; in the air planes average 500+ knots, or 550 mph. So at 9 to 1 the risk-per-time ratio would be the same as the speed ratio. >Estimating exposure to risk for airline flyers has to be measured in >deaths per people-mile to create a normalized statistic. > >This takes into account both the difference in speed and the difference >in numbers of passengers. Difference in number of passengers is moot since the same fate generally applies to all, whether on the highway or in an airplane; your crash is simultaneously a couple of hundred other peoples' crash, skewing the stats back where they came. As far as difference in risk per mile, it would help to have a number. Is the ratio 1.5 to 1, or 10 to 1, or what? - my Trivial Pursuit search engine is drawing a blank :-( .... but I *think* it's in single digits, which means that minute by minute the grim reaper should be less interested when you are in a car. Interesting factoid: allegedly you'd have to make one takeoff and landing every day for 1500 years or so to hit .5 probability of being in a commercial air crash. Now, since 40K people die annually in car wrecks, or roughly one percent of all deaths, you'd have to live about 3500 years to hit .5 probability of death by auto. On the other hand, how often do you use your auto to cover major inter-city distances? Ahh, apples and oranges and fruit salad! Pass the waldorf. Another death statistic: 300K people's livelihoods depend on growing, processing, and selling tobacco, not counting the doctors who deal with the aftereffects; and 300K people die from tobacco related causes each year. If your daddy's land won't grow anything else, you have my sympathy. >Arnold Frisch >Tektronix Laboratories >-------------------------------------------------------- >Any ideas or opinions expressed here do not necessarily >reflect the ideas or opinions of my employer. >-------------------------------------------------------- JoeHArticle: 4854
Hi all, does anybody know application notes of FPGA realizations of a I2C Bus interface? Stephan ------------------------------------------------ Stephan Gick Fraunhofer Institute for Integrated Circuits IIS Dep. Electronic Systems ESY Am Weichselgarten 3 D-91058 Erlangen EMail: gck@iis.fhg.de -------------------------------------------------Article: 4855
Wayne Turner wrote:
> >1- FPGAs allow you to weed out 'all' the BAD devices
> > via extensive device testing.
> >3- FPGAs do not ever just flip a program bit randomly.
>
> Actually, they can. In flight applications for example, a heavy ion
> hitting an SRAM cell can cause the value to change and thereby
> change the functionality of the circuit without being able to
> detected before the functionality has already changed.
.. And what if the heavy ion hits a cpu register or a latch in
the ASIC you have constructed from gates? Won't they flip? Will an
antifuse blow if a heavy ion produces a local latch up?
How far do you trust your antifuse device programmer? It applies
voltages that may be lethal to some parts of the device. How many
parts did you program with it successfully? 10-100-1000-10,000?
How many of the same type do you need to know that it _really_ works?
Were there programming rejects? Who was the culprit?
The chip, the computer, the OS, the programmer software? (no, not
you.:-)
Did it _really_ catch all the programming rejects?
The programmer changes the chip in many places. Did it re-apply a full
set of test patterns for every node or did it just verify that every
fuse
that had to be blasted looked that way? Is "The Golden Programmer"
driven by a MS Windows program? If not, has anybody else used it
before you?
OTOH i see that SRAM FPGAs can be tested exhaustively without changing
them forever; programming is half a page of C or just a ROM, and
you can verify the program memory any time you want. You may even
update the hardware if the chip is already in orbit. To me, SRAM FPGAs
look quite appealing from a safety point of view.
So many questions... I'm really glad that a sailplane has no electronic
flight critical parts.
Gerhard
--
Gerhard Hoffmann - Engineering Services
^ I insist on that second 'n'.
on the air: DK4XP
in the air: D-1441, Bergfalke III, jawoll!
Article: 4856In article <32B86B88.41C67EA6@redwood.dn.hac.com>, Mark Norton <mnorton@redwood.dn.hac.com> says: >Hello, first time designer here. > >I've got an application that takes a serial 200 MBit/sec data stream >that has a frame length of about 1024 bits give or take a few, [snip] Are you sure that FPGAs / CPLDs fast enough for 200 MBit/s are available? We do do stuff with FPGAs (Xilinx) and as far as I know practical (multi-stage-logic) designs run at, say, 40MHz or 50MHz. Your app would require 200MHz flipflop toggle rate, and most probably counters running at 200MHz. Counters tend to have carry propagation delays, at least when implemented conventionally. (Of course there are such things as Omura adders using non-canonical number representation, and LFSRs, both of which do not have the carry propagation problem.) Just asking, I'm no FPGA expert myself. (Just ordered the APS FPGA eval board, been following FPGA designs of a co-worker.) Gregor Glawitsch | Utimaco Safe Concept GmbH | Tel: ++43 (0)732 655 755 - 33 Europaplatz 6 | Fax: ++43 (0)732 655 755 - 5 A-4020 Linz, Austria | E-Mail: Gregor.Glawitsch@utimaco.co.atArticle: 4857
Richard Gaupsas wrote: > > I've got a CPLD I've programmed via VHDL. I've inserted a test array > (called test) to make sure some conditionals have been reached. Once > set in a conditional to '1', the test vectors should stay latched until > the system is reset in which case they are reset to '0': > > p2: process (rst,clk) > begin > if (rst='1') then > ..... > test(2)<='0'; > elsif (rising_edge(clk)) then > if(oen='0' and irq='0' and ....) then > .... > test(2)<='1'; > end if; > end process p2; > > However the test vectors keep toggeling even though reset never comes on > again. Am I missing something with respect to how I think VHDL is describing > my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated > to 100Mhz) resulting in problems or can I have some race condition induced by > poor code, or any other ideas? Functional simulations does not indicate any > problems. > > Thanks in advance, > Richard Gaupsas > rgaupsas@cts.com I do not know why your "test" toggles. But I think you need to add "oen", "irq" and ... to the sensitivity list for the synthesizer to interpret the code right. sundarArticle: 4858
In article <32BA2173.5620@ids.net>, Ray Andraka <randraka@ids.net> wrote: >Wayne Turner wrote: >> > >> >1- FPGAs allow you to weed out 'all' the BAD devices >> > via extensive device testing. >> >3- FPGAs do not ever just flip a program bit randomly. >> >> Actually, they can. In flight applications for example, a heavy ion hitting >> an SRAM cell can cause the value to change and thereby change the >> functionality of the circuit without being able to detected before the >> functionality has already changed. >> >> Read up on single-event upsets in SRAM devices (both memory and logic). >> >> >4- Loading of configuation data into an FPGA is 100% reliable >> > if timing and voltage margins are met. >> > >> >If anyone has any evidence contrary to the above assumptions >> >I'd like to see it. >> >> [...] >> >> See above... > >Yes, given enough energy, an SRAM cell in the FPGA array can be upset. >The point I was making is that upset to the FPGA SRAM cell takes >considerably more energy than the SRAM used for microprocessors to cause >upset. This is due to the longer write cycle for the FPGA. The FPGA >cells are deliberately designed with long write cycles to reduce the >probability of upset. Since microprocessors are fairly well accepted in >safety critical applications, the more stable FPGA cell should also be >acceptable. Actually, I believe from a physics standpoint that it has to do with the fact that SRAM cells in FPGAs are larger then those in memory and therefore require more energy to change state. True, that does make the FPGA SRAM cell have a longer write cycle as well, but it is a result of the cell geometry. >In an application that could seriously compromise safety, the design has >to be made fault tolerant regardless of what devices are used. This may >mean duplicate circuits with voting logic, signal monitoring, extra >circuits for data integrity checking (eg. parity checking or duplicate >data paths) configuration monitoring via readback (in the case of SRAM >FPGAs) or other measures. The later Xilinx parts do allow a CRC to be >computed on the bitstream to verify the chip got what you thought you >sent (implementation of the CRC is very easy). Additionally, they offer >the ability to read the actual device state back. This permits you to >monitor the configuration to catch any cell upsets. Not necessarily before it has impacted your functionality. If that part of your FPGA has been running anything between when the upset occurred and when the CRC is complete, then your functionality has been compromised. >It is worth noting that the OTP devices (especially the eprom and eeprom >types) are also susceptible to upset by high energy particles/radiation. >In those cases, there is nothing that can be done short of >reprogramming, or in some cases replacing the device. In the case of >the SRAM FPGA, the fix is usually as simple as reloading it. I would believe that a hard-programmed device is much less susceptible to upset however. The energy required to change the value in an EPROM cell would be enormous compared to that needed to change an SRAM cell, I would think. >From all the evidence I have seen to date, the SRAM devices are no less >reliable than the OTP counterparts or dedicated ASICs (and are likely >more reliable due to the degree of testing available). They do however >offer the significant advantages of easy 100% functional testing, >configuration monitoring and reprogrammability (both for time division >multiplexing of the hardware and for product >upgrades/enhancements/patches) I find it hard to believe that all of these engineers designing flight and space equipment have been hoodwinked all of these years. When you are talking about failure rates that must be calculated over a 20-year product lifespan (i.e. aircraft), it is pretty accepted that ASICs and OTP devices are more reliable than SRAM. WayneArticle: 4859
In our Fast Ethernet/ATM product we have decided to use the PCI bus as our local interconnect. Have any you folks implemented PCI bus based designs using some of the dense FPGA's(Altera 10K, Xilinx 4K)? The design is fairly intensive and we ruled out CPLD's due to its limited gate count. I appreciate you sharing your experience. Thank you SundarArticle: 4860
In article <32BA76D5.4590@berlin.snafu.de>, ghf@berlin.snafu.de wrote: >Wayne Turner wrote: > >> >1- FPGAs allow you to weed out 'all' the BAD devices >> > via extensive device testing. >> >3- FPGAs do not ever just flip a program bit randomly. >> >> Actually, they can. In flight applications for example, a heavy ion >> hitting an SRAM cell can cause the value to change and thereby >> change the functionality of the circuit without being able to >> detected before the functionality has already changed. > >... And what if the heavy ion hits a cpu register or a latch in >the ASIC you have constructed from gates? Won't they flip? Will an >antifuse blow if a heavy ion produces a local latch up? Who knows? I was merely talking about SRAM susceptibility to an SEU. Also, many flight app processor systems are redundant lock-step systems for those reasons. I suppose one could do the same with an FPGA. >How far do you trust your antifuse device programmer? It applies >voltages that may be lethal to some parts of the device. How many >parts did you program with it successfully? 10-100-1000-10,000? >How many of the same type do you need to know that it _really_ works? >Were there programming rejects? Who was the culprit? >The chip, the computer, the OS, the programmer software? (no, not >you.:-) >Did it _really_ catch all the programming rejects? Is this some wacky conspiracy theory? >The programmer changes the chip in many places. Did it re-apply a full >set of test patterns for every node or did it just verify that every >fuse >that had to be blasted looked that way? Is "The Golden Programmer" >driven by a MS Windows program? If not, has anybody else used it >before you? Let see; one gunman or many; what about the grassy knoll? >OTOH i see that SRAM FPGAs can be tested exhaustively without changing >them forever; programming is half a page of C or just a ROM, and >you can verify the program memory any time you want. You may even >update the hardware if the chip is already in orbit. To me, SRAM FPGAs >look quite appealing from a safety point of view. > >So many questions... I'm really glad that a sailplane has no electronic >flight critical parts. Me too... ;) WayneArticle: 4861
I have been investigating the use of SRAM and/or Anti-Fuse FPGA's in a
Low Earth Orbit satellite, hence the interest in this thread. Some
comments/questions follow:
The only data I could find on FPGA's that have been subjected to radiation
testing have been on the Actel Anti-Fuse FPGA's [IEEE. Transactions on
Nuclear Science, Vol. 43, No. 3, June 1996].
According to that article, the A1280 had a Single Event Dielectric Rupture
(SEDR) rate of 3x10^{-5} per device-year.
It was also stated that "the eight month Mars Pathfinder primary mission,
which incorporates seventeen flight-critical A1280As in single string
mission critical circuits, has a 99.96% change of not experiencing a SEDR."
During discussions with an Altera representive it became clear that
they have no interrest at all the radiation hardend/tolerant market. Apart
from Actel, Xilinx seems the only other major player in this market?
Does anyone have references on equivilant SRAM tests?
Any ideas to what damage could be caused by a flipped configuration cell?
Internal signal driver contention resulting in driver/device destruction?
--
Hans Grobler <grobh@nolian.ee.sun.ac.za>
Department Electrical & Electronic Engineering
University of Stellenbosch, South Africa
Article: 4862On 20 Dec 1996 13:19:34 GMT, gregor.glawitsch@utimaco.co.at (Gregor Glawitsch) wrote: >In article <32B86B88.41C67EA6@redwood.dn.hac.com>, Mark Norton <mnorton@redwood.dn.hac.com> says: >>Hello, first time designer here. >> >>I've got an application that takes a serial 200 MBit/sec data stream >>that has a frame length of about 1024 bits give or take a few, > >[snip] > >Are you sure that FPGAs / CPLDs fast enough for 200 MBit/s are >available? For what it's worth an engineer in my group has just finished an FPGA design using FPGAs from QuickLogic which, under normal operation, is expected to run at 100MHz. However, he's tested it to 200MHz without problems. C.Article: 4863
Hans Grobler wrote: > Any ideas to what damage could be caused by a flipped configuration cell? > Internal signal driver contention resulting in driver/device destruction? I can think of lots of nasty things that can go wrong... In particular, what if an output of the FPGA controls a power transistor or MOSFET. In some circuits if two MOSFETs are on at one time the power supply will short out. This would be most distressing to some devices. Driver/device destruction is "minor damage" compared to the potential effects of it's desctruction. Imagine what'd happen if the steering of a rocket went out because of a faulty FPGA... Just a thought... David Kessner dkessner@cyclades.comArticle: 4864
Stephan Gick <gck@iis.fhg.de> wrote: >Hi all, >does anybody know application notes of FPGA realizations of a I2C Bus >interface? >Stephan About a year ago, I considered the same thing. I really looked, and I didn't find anything. But the more I thought about it, the more I realized it shouldn't be too hard to do from scratch. Good luck. >------------------------------------------------ >Stephan Gick >Fraunhofer Institute for Integrated Circuits IIS >Dep. Electronic Systems ESY >Am Weichselgarten 3 >D-91058 Erlangen >EMail: gck@iis.fhg.de >-------------------------------------------------Article: 4865
Actually, Xilinx has a PCI "macro" available. I believe the target version is final and available (cost is ~$10,000 I think - I got info from Hamilton-Hallmark about this but I don't have it in front of me. Check their web site for more info.). As far as a PCI bus-master goes, I'm not sure if they've done that yet. Perhaps more info is at Xilinx's home page. It sounds like you want a bus-master for your application though, though I suppose a slave approach could also be used. Sundar Gopalan <sundar@com21.com> wrote: >In our Fast Ethernet/ATM product we have decided to use the PCI bus as >our local interconnect. Have any you folks implemented PCI bus based >designs using some of the dense FPGA's(Altera 10K, Xilinx 4K)? The >design is fairly intensive and we ruled out CPLD's due to its limited >gate count. > >I appreciate you sharing your experience. > >Thank you > >SundarArticle: 4866
Stephan Gick wrote: > > Hi all, > does anybody know application notes of FPGA realizations of a I2C Bus > interface? I think that I2C may be of sufficient complexity and commercial interest that even if people have developed one, they are not willing to share. I posted same question a few months back, had no reply. However, if someone has developed something in the meantime, pls let me know too. -- John L. Smith, Pr. Engr. Univision Technologies, Inc. 6 Fortune Dr. Billerica, MA 01821-3917 jsmith@univision.comArticle: 4867
I first posted this to a thread about FPGAs in mission critical
applications where it was inappropriate, For this I apologize.
I would appreciate comments on the following:
Fascinating!! I too have spent many hours trying to fix Xilinx loading
problems. The Xilinx help line glibly suggested that I get a high speed
scope and look at the CCLK signal for glitches. This is very difficult
to do.
If someone can point to some good info on the limits required on CCLCK
transition time I would be very grateful.
Is this a case of Xilinx refusing to own up to a known problem?
I guess that's why users have to get together every now and then
to find out about common problems.
... Garnet
In article <32b65809.5741395@news.u-net.com>, peter@nowhere.com says...
> snip <
>One little example, discussed here ad nauseum some months ago: the
>edge on CCLK needs to have its transition time within certain limits -
>for no obvious reason. Glitches (or whatever) which are not visible on
>a 350MHz scope can prevent reliable config. This is on an input which
>never sees anything remotely that fast. They could so easily have put
>a schmitt trigger in there.
>
>I know Xilinx will say 99.99999% of their customers never have config
>problems, but this is of no help to me when it happens.
>
>
>Peter.
>
>Return address is invalid to help stop junk mail.
>E-mail replies to z80@digiserve.com.
Article: 4868
Sundar Gopalan wrote:
>
> Richard Gaupsas wrote:
> >
> > I've got a CPLD I've programmed via VHDL. I've inserted a test array
> > (called test) to make sure some conditionals have been reached. Once
> > set in a conditional to '1', the test vectors should stay latched until
> > the system is reset in which case they are reset to '0':
> >
> > p2: process (rst,clk)
> > begin
> > if (rst='1') then
> > .....
> > test(2)<='0';
> > elsif (rising_edge(clk)) then
> > if(oen='0' and irq='0' and ....) then
> > ....
> > test(2)<='1';
> > end if;
> > end process p2;
> >
> > However the test vectors keep toggeling even though reset never comes on
> > again. Am I missing something with respect to how I think VHDL is describing
> > my circuit? Else can I be pushing the silicon too fast (33Mhz with a part rated
> > to 100Mhz) resulting in problems or can I have some race condition induced by
> > poor code, or any other ideas? Functional simulations does not indicate any
> > problems.
> >
> > Thanks in advance,
> > Richard Gaupsas
> > rgaupsas@cts.com
>
> I do not know why your "test" toggles. But I think you need to add
> "oen", "irq" and ... to the sensitivity list for the synthesizer to
> interpret the code right.
>
> sundar
No, the sensitivity list is correct.
You don't say what tools you are using, but the statement:
elsif (rising_edge(clk)) then
is suspect to me. Take out the function and code it directly:
elsif (clk='1' and clk'event) then
Another thing to do would be to look at whatever report files
your tool generates to see what you can see about how the design
was implemented. Is test(2) the output of a flip flop? Can
you find out what the synthesized equation/logic is for the input
to that flip flop?
Finally, look at your signals on the physical system carefully with
a good oscilloscope. Is there noise on rst? Is the CPLD in a two-sided
or (shudder) wire-wrapped proto board? Check the power/gnd pins for excess
noise.
Greg
Article: 4869
Xilinx chips do not have loading problems.
The following assumes you are (like me) working with the 1994 data book.
Xilinx documentation, while sufficient on some typical applications, is
poorly presented, has ommissions and errors, has insufficient examples,
and does nothing to address the process of selecting one mode over
another, or the system issues related to designing with high speed
components.
The documentation fails to explain the startup sequence at the end of
configuration (leading to the "I need a few more clocks to make it work"
syndrome), fails to explain how the daisy chain works, and the
interaction with the header ("My done pin doesn't go high"). The poor
description of the relationship between bitstream length, the value of the
length count in the header, the type of startup sequence, and whether you
are using a serial or parallel config mode, and daisy chain of FPGAs and
daisychain of config proms (and some little details related to serial
config prom reset pin polarity), all conspire to cause problems.
When you figure this stuff out, the devices configure fine, every time,
without any problems.
To make matters worse, designers don't read the manuals, don't check
their timing, and don't think that they need to follow good design
practice if clock rates are slow (see below). If you shoot yourself in
the foot, don't be surprised if it hurts.
I have worked on over 150 FPGA designs (in the last two years), and ALL
of them configure correctly each and every time. This is not magic, or
rocket science. The configuration logic in these chips is a state
machine. If you give it valid clock and data signals the state machine
advances from state to state the same way every time, and the end result
is a configured chip.
If you want to have similar results, may I recomend you carefully read
pages 2-25 thru 2-30 of the 1994 Xilinx data book, paying close attention
to the flow chart on page 2-27, the startup options on page 2-29, and
the startup state machine schematic on page 2-30.
In the new data book (1996) there is a better description, on pages 4-54
thru 4-63, which addresses some of the above issues with the older
documentation.
The configuration logic is built with the same high speed sub-micron
silicon gates that the rest of the chip is built of. In the faster parts,
the basic flipflops can toggle at better than 200MHz, so the actual
minimum clock low or high times that could cause a flip flop to toggle can
be only a nanosecond or two. That means you need to have clean clock
signals, both rising and falling edges. You do this the same way you do
any other high speed design clock line, appropriately terminated
transmission lines. If you fan a clock line out to multiple destinations,
with out terminations, with stubs, vias, trace width changes, and other
things that make clock signals look crappy, the destination flipflops
don't work the way you want, no matter if they are logic flipflops, CPU
chips, synch-DRAMS, EPLDs, PALs, FPGAs, or configuration logic.
In article <59fq29$40e@maggie.ionsys.com> cgbi@ionsys.com (Garnet Brace) writes:
>I first posted this to a thread about FPGAs in mission critical
>applications where it was inappropriate, For this I apologize.
>I would appreciate comments on the following:
>
>Fascinating!! I too have spent many hours trying to fix Xilinx loading
>problems. The Xilinx help line glibly suggested that I get a high speed
>scope and look at the CCLK signal for glitches. This is very difficult
>to do.
You might have thought it was glib, I think it was exactly the right thing
to recomend. If you have intermittently successful configuration, then the
quality of your clock signal is the most common cause of problems. The
fact that you have trouble finding a high speed scope hardly seems to be
Xilinx's fault :-) . As I wrote above, this is high speed logic, with
toggle rates that can exceed 200MHz. The parts are fast because end users
like you keep asking for faster parts.
>If someone can point to some good info on the limits required on CCLCK
>transition time I would be very grateful.
An excelent question and unfortunately an example of a most agregious
ommision from the data book.
First, some period stuff (from the data book):
Since the configuration data rate can be from DC to 10 MHz, I would
recomend that clock low and clock high time be no less than 45 nS.
For XC3000, 3000A, 3100, and 3100A, Clock high can be as long as you
like, but clock low has a maximum of 5 uS. This means that if you are
bit-banging the clock from a processor, don't take any interrupts while
clock is low, Or build you hardware so that the clock idle state is high.
For the XC4000, 4000A, 4000H, 4000D, and 4000E, there is no maximum time
for either clock low or high.
Now, for edge rates (not in the data book):
I would recomend that rising and falling edges be no slower than 20 nS,
and most importantly, be monotonic! . If you do have slow edges, then the
above requirement of 45nS clock high time should be from the 90% points,
and the clock low time should be between 10% points. I.E. if you have
slow clock edges, you don't get to run at the fastest clock rate.
As for fastest clock edge rates, the answer is as fast as you want, i.e.
sub 1nS, but still the critical issue is monotonicity!. This means good
distribution practices, and attention to transmission line issues.
If you dont have monotonic transitions, then the glitches can cause
additional clock edges to be seen by some (but maybe not all) of the
flipflops in the configuration logic. This can lead to configuration
failures.
>Is this a case of Xilinx refusing to own up to a known problem?
I don't think so.
>I guess that's why users have to get together every now and then
>to find out about common problems.
> ... Garnet
Or maybe just to be helpful.
>>In article <32b65809.5741395@news.u-net.com>, peter@nowhere.com says...
>>One little example, discussed here ad nauseum some months ago: the
>>edge on CCLK needs to have its transition time within certain limits -
>>for no obvious reason.
I hope the above is sufficient reason for you :-)
>>Glitches (or whatever) which are not visible on
>>a 350MHz scope can prevent reliable config. This is on an input which
>>never sees anything remotely that fast. They could so easily have put
>>a schmitt trigger in there.
Well that wouldn't work either, because the filter would make the slower
members of the product family unable to configure at 10 MHz. You can't
have it both ways.
>>I know Xilinx will say 99.99999% of their customers never have config
>>problems, but this is of no help to me when it happens.
>>Peter.
I will say 95% :-) so hopefully the above is some help when it happens
to you. If you have problems, I will certainly try and help, but you had
better have a clean clock signal :-)
Philip Freidin
fliptron@netcom.com
Article: 4870Eric Edwards wrote: > > 'Got a design, written in verilog of about 1000 lines. > For a variety of reasons, I'm trying to fit this to an Altera Flext 10K10 > FPGA. Should be easy, right? 3500 gate design, 10000 gate part. But it > doesn't fit. I could understand possibly having routing problems but I'm > running out of logic cells: 610 vs the 565 cell capacity of the 10k10. > Any ideas on what could be causing this area explosion? Better yet, > suggestions as to what to do about it? Sounds a lot like you're running without any serious optimisation. Perhaps _all_ nodes are being preserved, so each of your 3500 ASIC gates is being fitted separately. (as in Altera's WYSIWYG mode) Whose fitter are you using? A quick grovel through the output files ought to show you what's going on. Altera tech support in the UK are good, don't know about where you are, but give them a go. After years of Xilinx, I'm still amazed by how much I can wedge into an Altera part and still have it run at a sensible speed. Steve -- Steve Wiseman, Senior Systems Engineer, SJ Consulting Ltd, Cambridge, UK Desk +44 1223 578524 (Fax 578525) Group +44 1223 578518 steve@sj.co.ukArticle: 4871
In article <1996Dec23.111701@emc.com> walton@emc.com "John Walton" writes: > > >Announcement of Trianus/Hades tools for Xilinx XC6200 FPGA > >========================================================== > > Looking at the Trianus Home I see that you supporting > Win95. > > Is there a planned port to ..... (dare I say!) Linux? > Well, the poster said that it runs under Oberon, which certainly is available for a wide range of machines (I have it on my Mac), so porting it should be quite possible. -- ----------------------------------------------------------------------------- | Andrew Morley, Design & Development, Trend Communications Ltd, High Wycombe.| | email: andrew.morley@trendcomms.com Phone +44 1628-524977 Bucks, UK.| -----------------------------------------------------------------------------Article: 4872
Has anyone seen the new XLNX M-1 software for the EX family. Any comments? thanks :) ChrisArticle: 4873
In article <59614k$lh5$2@mhade.production.compuserve.com>, Simon <106072.1620@CompuServe.COM> wrote: >Xilinx FPGAs, although of an SRAM nature are in fact around 10 >times more reliable than a comparable SRAM part. Please offer data to support the above statement. Why would Xilinx SRAM parts be 10x more reliable than another SRAM part? >Also it is >possible to have a system where by in the unlikely event that the >FPGA fails to power up correctly you can detect it and >re-initialise it. If you asic develops a fault your buggered. Really a moot point, since ASICs don't configure on power up. They are hard-wired. >Also, I am aware of a number of saftey critical systems which >depend on Xilinx FPGAs. Most notably a well known ship to shore, >explosive delivery system (Made famouse in the Gulf War) which >uses Xilinx FPGAs in its guidance system. Does this have a name? WayneArticle: 4874
To add to your list you may want to check out a product offered by Rice Electronics which apparently developped a new way to do FFTs optimized for FPGAs and also the tool Atmel is offering tar- geted for their reconfigurable FPGAs. Regards, Kayvon Irani Los Angeles, Ca
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