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 30 Dec 1996, Wayne Turner wrote: > >It seems to be it's difficult to get something for nothing in this case. > >Because of the additional programing requirement for SRAM FPGA's, some > >decrease in system reliability should be expected. Perhaps each case > >needs to have a separate analysis. > > This still does not address the fact that while SRAM memory devices are more > susceptible to upset, they also allow for design practices that can include > real-time error detection and correction, where this is not possible with the > configuration data in a SRAM programmable device. The only option there (on > those devices that have the capability) is to constantly do a running CRC on > the config data, which may or may not catch an error before your functionality > has been compromised. > > Wayne > > I guess you may want to do what you would want to do with an SRAM fPGA what you would like to do with an SRAM-- I am suggesting that what do for a flipped bit in SRAM you also do for an FPGA. If you want to just detect an error when you read from ram, than you may just want to detect an error on every clock cycle from the FPGA (this may require a redundent FPGA). I'm not suggesting the above to be consistent. Rather, it's to avoid overkill and wasted effort. For example, it would be wasted effort to try to develop a fail operational circuit for the FPGA, when we only detect an error in SRAM. In another example (I'm reaching), we see non- parity rams now on PC's-- making it difficult to detect errors immediately, but perhaps later on writing to disk. In this case, why bother to design in circuits to detect FPGA loading errors-- why not just let the system detect functional errors and warn the operator so he or she can re-boot the PC? ######################################################################## Alvin E. Toda aet@lava.net sr. engineer Phone: 1-808-455-1331 2-Sigma WEB: http://www.lava.net/~aet/2-sigma.html 1363-A Hoowali St. Pearl City, Hawaii, USAArticle: 4926
<somebody wrote> > >I like the argument for SRAM FPGA's, such SRAM circuits are > >designed to be more stable than SRAM so they should be acceptable to > >the extent that SRAM is acceptable (if I may paraphrase this argument). i think there's a bit of over generalization here. SRAM as a technology is acceptable. But it's application depends on the SRAM selected, environment, and reliability levels (let's assume high). SRAM performance in radiation (concern brought up earlier) can vary from horrible to essentially bulletproof. architecturally, sram is easy to make relatively seu hard - this can be done with hamming codes, reed-solomon codes, TMR, memory scrubbing, etc. Configuration memories in fpga's do not permit this. also, memory elements in fpga i/o cells are troublesome too in this regard and the cells are important in many fpga's as they offer fast clock -> out performance and small setup times and zero hold times, parameters critical to high performance pipelined systems and pci interfaces, which are becoming more popular. from a system performance point of view, errors in sram memories can be detected and corrected during an access cycle; an error in an fpga configuration memory would have a larger system impact (i.e., fault needs to be blocked, system reloaded, find out what was missed and deal with it which is often complex or impossible, etc). Note that "stuck-bit" errors, thought by some to be caused by a local total dose effect from a single heavy ion, needs to be dealt with also. for sram w/ reed-solomon, this is a don't care since the error correcting power of the code is so strong. for hamming code or tmr-based systems, the system would continue to run normally but with a loss of seu protection. not so easy w/ fpga configuration memories. another effect to be concerned with in these systems in general is single event, multiple bit upset. for srams, many commercial devices are designed with the logical bits in a byte located physically next to each other; well designed military or hi-rel memories will have the bits in the same byte physically separate, permitting simple edac schemes to be very effective. rkArticle: 4927
some comments are embedded and denoted w/ '*****' rk Alvin E. Toda <aet@lava.net> wrote in article <Pine.BSI.3.91.961230231701.16021A-100000@malasada.lava.net>... > On 30 Dec 1996, Wayne Turner wrote: > > > >It seems to be it's difficult to get something for nothing in this case. > > >Because of the additional programing requirement for SRAM FPGA's, some > > >decrease in system reliability should be expected. Perhaps each case > > >needs to have a separate analysis. > > > > This still does not address the fact that while SRAM memory devices are more > > susceptible to upset, they also allow for design practices that can include > > real-time error detection and correction, where this is not possible with the > > configuration data in a SRAM programmable device. The only option there (on > > those devices that have the capability) is to constantly do a running CRC on > > the config data, which may or may not catch an error before your functionality > > has been compromised. > > > > Wayne > > > > > I guess you may want to do what you would want to do with an SRAM fPGA > what you would like to do with an SRAM-- I am suggesting that what > do for a flipped bit in SRAM you also do for an FPGA. If you want to > just detect an error when you read from ram, than you may just want to > detect an error on every clock cycle from the FPGA (this may require > a redundent FPGA). ***** i just put up a note explaining, architecturally, that you can't do the same ***** for fpga's that you do for srams for a number of different classes of errors ***** which will affect the configuration memory. for user-configured memory elements ***** there are a number of techniques which can work and have been built into space ***** flight hardware and tested in particle accelerators. these techniques are NOT ***** bulletproof but are very good but do present testability challenges, which make ***** the device inferior to a true rad-hard memory cell, as can be found in rad-hard/ ***** hi-rel asics, for example. ***** ***** a redundant fpga, used to detect an error on each clock cycle, presents some ***** issues that need to be addressed: ***** ***** 1. what circuit is responsible for the comparison? this needs to be fast and ***** compact and adds even more overhead. ***** 2. what about errors in the error checking circuitry if it's implemented in, lets ***** let's say, an fpga to be compact? this just moves the problem but we can ***** make these circuits redundant too ... ***** 3. let's say you have two fpga, voters, the whole thing, how do you test this ***** stuff to ensure that all of the modes work and all? how are errors generated? ***** this adds more circuitry and overhead and complexity. ***** 4. now, suppose we've solved 1, 2, and 3, and you get an error. what do you do ***** about it? which one is right? which fpga do we reload? do we have to restart ***** the entire system? how do we keep the system running (assume it's flying an ***** aircraft full of people, or a spacecraft in critical maneuvers, or it's doing something ***** important with nasty weapons to either get someone or keep you from getting ***** squished)? how do we get the fpga's back in sync? > > I'm not suggesting the above to be consistent. Rather, it's to avoid > overkill and wasted effort. For example, it would be wasted effort to > try to develop a fail operational circuit for the FPGA, when we only > detect an error in SRAM. In another example (I'm reaching), we see non- > parity rams now on PC's-- making it difficult to detect errors > immediately, but perhaps later on writing to disk. In this case, why > bother to design in circuits to detect FPGA loading errors-- why not > just let the system detect functional errors and warn the operator so > he or she can re-boot the PC? ***** i think this is a bit of a reach - i don't think the pc would qualify in a ***** safety critical application. and 'only an error on sram' may have ***** serious effects that need to be blocked from affecting system ***** performance. and, if it is possible to configure, based on a flipped-bit, ***** an input cell as an output, or a tri-state output as an always-on output, ***** (and there's other examples) than the h/w set may be damaged and ***** overstressed (ex., metal migration) which can shorten the electronics ***** lifetime or perhaps immediately damage them. rkArticle: 4928
In article <Pine.BSI.3.91.961230231701.16021A-100000@malasada.lava.net>, "Alvin E. Toda" <aet@lava.net> wrote: >On 30 Dec 1996, Wayne Turner wrote: > >> This still does not address the fact that while SRAM memory devices are >> more susceptible to upset, they also allow for design practices that can >> include real-time error detection and correction, where this is not >> possible with the configuration data in a SRAM programmable device. The >> only option there (on those devices that have the capability) is to >> constantly do a running CRC on the config data, which may or may not catch >> an error before your functionality has been compromised. >> >> Wayne >> >> >I guess you may want to do what you would want to do with an SRAM fPGA >what you would like to do with an SRAM-- I am suggesting that what >do for a flipped bit in SRAM you also do for an FPGA. If you want to >just detect an error when you read from ram, than you may just want to >detect an error on every clock cycle from the FPGA (this may require >a redundent FPGA). This would also work, and is similar to having redundant lock-step processors. [...] WayneArticle: 4929
CALL FOR PAPERS AND PARTICIPATION
1997 IEEE INTERNATIONAL WORKSHOP
ON MEMORY TECHNOLOGY, DESIGN AND TESTING
August 11-12, 1997
Submission deadline: January 15, 1997
Send submissions to:
TECHNICAL PROGRAM CHAIR
Thomas Wik
LSI Logic, MS E-194
1501 McCarthy Blvd
Milpitas CA 95035, USA
408/954--4471; trw@lsil.com
Address general inquiries to:
GENERAL CHAIR
Fabrizio Lombardi
Computer Science MS 3112
Texas A&M University
College Station TX 77843, USA
409/845--5464; fax 847--8578
lombardi@cs.tamu.edu
The 1997 IEEE International Workshop on Memory Technology, Design and
Testing will be held at the Hilton Hotel and Towers, 300 Almaden Blvd,
San Jose, California, USA (408/287--2100), on August 11-12, 1997.
The workshop will include all aspects of memory design, process
technologies and testability related topics. Memory circuit designs,
cell structures, fabrication processes, design architectures as
related to testing, verification and test methods for SRAM, DRAM,
Flash and Non-Volatile memories, EPROM, EEPROM, embedded memories,
logic-enhanced and FIFO memories, 3-D memories and content addressable
memories. Some representative topics are:
- Memory fault modeling and test generation
- Built-in test and testable designs for memories
- Concurrent checking and memory fault diagnosis
- Quality and reliability issues
- Space applications and radiation hardening issues
- Memory failure and yield analysis
- High-speed, innovative designs
- Fault isolation, reconfiguration and repair
- Multiported, multibuffered memories
- Logic-enhanced and programmable memories
- Application-specific and embedded memories
- Multimegabit SRAMs and DRAMs
- CMOS, BiCMOS and bipolar designs for high yield and reliability
Authors please submit five (5) copies of an extended abstract of about
1000 words of original work on any aspect of memory technology, design
and testing to the Technical Program Chair. Submissions should
include full names and affiliations of authors, contact information
and should indicate the intended presenter.
Submissions are due January 15, 1997. Authors will be notified of
acceptance on March 31, 1997. Final papers will be due May 15, 1997.
Presentations will be 30 minutes, inclusive of discussion.
Sponsored by:
IEEE Computer Society
Technical Committee on Test Technology
Technical Committee on VLSI
In cooperation with:
IEEE Solid-State Circuit Society
Article: 4930Stephan Gick wrote: > > 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 > ------------------------------------------------- I use BrookTree's video I/F chips develped some video capture cards . All of these chips have I2C bus I/F .As the I2C bus is very slowly , I always use software to control it . Use 2 bit of data bus , one for SCL and one for SDA . Shiping Cong vn5s-cng@asahi-net.or.jpArticle: 4931
I just sat down to compile a clients design I made some changes to...and WIR2XNF said everything was out of date. Symbols, wir files, schematics, everything! It thought that 1/1/97 was earlier than 12/30/96! Some programmer bumbled.... Since the new Viewdraw doesn't write out a symbol or schematic unless it's actually changed, I had to go through the entire project, symbol by symbol, schematic by schematic, and 'change' something in each of them so it would write out a new symbol/schematic/wir file. For some reason, the check program wasn't able to do this, probably cause it can't write symbols. Anyone else have this problem? Austin Franklin ..darkroom@ix.netcom.com.Article: 4932
John Cooley (jcooley@world.std.com) wrote: : simonson@skopen.dseg.ti.com (Kevin M Simonson) writes: : > I'm feeling really ignorant right now. Is there anyone who can tell : >me what ASIC stands for? Thanks. : > : > ---Kevin Simonson : Aren't "ASICs" a brand of tennis shoe? :^) Why were the shoes named ASIC's ? ------------------------------------------------------------------------------ -- Eswar Saladi email : eswar@megamed.com pager : 408-381-6316 ------------------------------------------------------------------------------ -- Home Page : http://home.aol.com/Anln ------------------------------------------------------------------------------ -- Favorite Quote : The essence of advancement is simplicity. --Dr. Zarkov ------------------------------------------------------------------------------ -- ALL VIEWS EXPRESSED ARE MINE AND MINE ALONE, NO COPYRIGHT VIOLATIONS ------------------------------------------------------------------------------Article: 4933
Subramnyeswar Saladi (eswar@mega.megamed.com) wrote: > John Cooley (jcooley@world.std.com) wrote: > : simonson@skopen.dseg.ti.com (Kevin M Simonson) writes: > : > I'm feeling really ignorant right now. Is there anyone who can tell > : >me what ASIC stands for? Thanks. > : > > : > ---Kevin Simonson I'm not a hardware guy, but I have come to understand that ASIC means "Application Specific Integrated Circuit". IOW, some electronics dedicated to a specific task. > : Aren't "ASICs" a brand of tennis shoe? :^) > Why were the shoes named ASIC's ? > ------------------------------------------------------------------------------ > -- Eswar Saladi email : eswar@megamed.com pager : 408-381-6316 > ------------------------------------------------------------------------------ > -- Home Page : http://home.aol.com/Anln > ------------------------------------------------------------------------------ > -- Favorite Quote : The essence of advancement is simplicity. --Dr. Zarkov > ------------------------------------------------------------------------------ > -- ALL VIEWS EXPRESSED ARE MINE AND MINE ALONE, NO COPYRIGHT VIOLATIONS > ------------------------------------------------------------------------------ -- Quote For The Month: "I wanna buy you some sunglasses - the kind you can see through"Article: 4934
In article <01bbf827$de5c8940$4cf65ecf@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes: >I just sat down to compile a clients design I made some changes to...and >WIR2XNF said everything was out of date. Symbols, wir files, schematics, >everything! It thought that 1/1/97 was earlier than 12/30/96! Some >programmer bumbled.... > >Since the new Viewdraw doesn't write out a symbol or schematic unless it's >actually changed, I had to go through the entire project, symbol by symbol, >schematic by schematic, and 'change' something in each of them so it would >write out a new symbol/schematic/wir file. For some reason, the check >program wasn't able to do this, probably cause it can't write symbols. > >Anyone else have this problem? Well, I didnt have the problem till I read your article, :-) > >Austin Franklin >..darkroom@ix.netcom.com. Bug confirmed, with the wir2xnf that comes with the newer sw, such as the WV0 7.2 and I assume XACT 6.0.1 or 6.0.0 The bug does not exist in the older (and much faster) wir2xnf V 5.1 ( the pre windows release of the WV tools, for DOS) My quick fix is to do some global date changing. I use XTREE, which will work unless you have long file name ( bigger than 8.3 style), but that's another story of woe. Anyway, went into the SYM directory, and changed all dates to current date and time. Then went into SCH and did the same (but a few seconds later), and finally went into the WIR directory and changed dates and times (a few seconds later than the SCH dates/times. Whole thing took me about 10 seconds. I hope you have a similar utility to do the same. Maybe there is a way to do global date change with the NT 4.0 explorer, but I don't know. Philip Freidin. P.S. I don't know how much longer I can keep out of the ASIC versus FPGA for configuration SRAM reliability fire fight :-) (it would be so much more interesting if the protagonists actually knew something about the configuration memory in these chips)Article: 4935
Does anyone know of a company that has the 6809 microprocessor in VHDL, or even schematic form.? Thanks Daniel IsacsonArticle: 4936
I want to use a 64 Bit X-Block bus. Ther are only BUS_IF Interfaces to 32 Bit, so I try to edit a BUS_IF32 symbol. There is a problem with the x-block bus, because there are no brackets. (normal bus use brackets to define bus members B[0:31]) How can I edit a X-Block symbol ? PeterArticle: 4937
In article <Pine.BSI.3.91.961230231701.16021A-100000@malasada.lava.net> "Alvin E. Toda" <aet@lava.net> writes: >...In another example (I'm reaching), we see non- >parity rams now on PC's-- making it difficult to detect errors >immediately, but perhaps later on writing to disk... Or perhaps never. Non-parity PCs are a testament to the fact that many people don't care whether their spreadsheets give correct results, so long as they run fast. -- "We don't care. We don't have to. You'll buy | Henry Spencer whatever we ship, so why bother? We're Microsoft."| henry@zoo.toronto.eduArticle: 4938
Austin Franklin (darkroom@ix.netcom.com) wrote:
: I just sat down to compile a clients design I made some changes to...and
: WIR2XNF said everything was out of date. Symbols, wir files, schematics,
: everything! It thought that 1/1/97 was earlier than 12/30/96! Some
: programmer bumbled....
: Since the new Viewdraw doesn't write out a symbol or schematic unless it's
: actually changed, I had to go through the entire project, symbol by symbol,
: schematic by schematic, and 'change' something in each of them so it would
: write out a new symbol/schematic/wir file. For some reason, the check
: program wasn't able to do this, probably cause it can't write symbols.
Hello:
This is true especially when you are transferring the
schematics and symbols from machine to another whose dates may
not be in sync. And wir2xnf will give you errors , a simple
way to get rid of this is to first go to the directory sch
and touch *.* and touch * and do the same in the sym directory
Now when you do a check appropriate wir files will be generated.
Because, the files are touched it means that the files are changed.
The program *touch* may be in the mks toolkit.
Hope this helps.
Article: 4939Application Specific Integrated Ciruit -- >>>-Geremy-->Article: 4940
Philip, Am I right in saying that if one uses the Remake All option (xmake -r IIRC) then the problem does not arise, even with XACT6? I always use remake-all, since 95% of the time is spent in APR/PPR anyway. Otherwise, one needs the little touch.exe utility which is available among the many "unix-lookalike" DOS utility kits, or used to come with DR-DOS. Peter. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4941
Peter, I don't think remake -all will do it. You need to update the symbol files first, then the schematics then the wir files. I don't believe remake -all will re-write the symbol files. Austin Franklin darkroom@ix.netcom.comArticle: 4942
<Rich Katz wrote> > > <Al Toda wrote> > >I like the argument for SRAM FPGA's, such SRAM circuits are=20 > >designed to be more stable than SRAM so they should be acceptable to=20 > >the extent that SRAM is acceptable (if I may paraphrase this argument).= =20 >i think there's a bit of over generalization here. SRAM as a technology i= s >acceptable. But it's application depends on the SRAM selected, >environment, and reliability levels (let's assume high). SRAM performance >in radiation (concern brought up earlier) can vary from horrible to >essentially bulletproof. >architecturally, sram is easy to make relatively seu hard - this can be >done with hamming codes, reed-solomon codes, TMR, memory scrubbing, etc.= =20 >Configuration memories in fpga's do not permit this. also, memory element= s >In fpga i/o cells are troublesome too in this regard and the cells are >important in many fpga's as they offer fast clock -> out performance and >small setup times.... I agree that in terms of robustness is the design, it=92s very different. But, it=92s still too early to tell-- the jury is still out. I think that when you talk of commercial over the counter type of=20 FPGA parts, you don=92t really concern your self with high rel=20 concerns. It=92s up to the persons that use these parts to address these concerns for high rel designs.=20 The goals may be the same (error detection or failing operational) but the means of getting there will certainly be up to the designers. Commercial parts certainly don't have these high rel requirements-- since it seems that consumer items which=20 have massive production volumes are pushing the technology at the present time.=20 The technology is still quite young-- if designers think that these SRAM FPGA parts have a role in high rel applications than the onus of coming up with "bulletproof"-ness is on them. It seems to me that simply using a bigger OTP part is more cost effective that adding redundancy, error detection, or=20 recovery schemes to the design.=20 But ( as has been mentioned before by someone), it may be a=20 requirement that it may necessary to fix un-expected operational=20 problems in flight with programmable h/w changes as well=20 transmitting fixes to the flight program. However it may just be=20 cheaper to do another flight for the cost of launching a system=20 with all this wazoo stuff. ######################################################################## Alvin E. Toda=09=09=09=09aet@lava.net sr. engineer=09=09=09=09Phone: 1-808-455-1331 2-Sigma=09=09=09 =09WEB: http://www.lava.net/~aet/2-sigma.html 1363-A Hoowali St. Pearl City, Hawaii, USAArticle: 4943
Hello : Do any of you know of a USB host interface (UHCI) design available for an FPGA (any vendor will do)? I'd also appreciate any information on approximate gate count implementations of the USB host interface. Also, does anybody know of a peripheral side USB controller other than Intel's 82930 and the impending Atmel part? Thanks, ManishArticle: 4944
I believe that CAE Technology has created a USB interface in Xilinx FPGA devices. See http://www.xilinx.com/products/logicore/alliance/cae/cae.htm. Mann`y <dando@phish.nether.net> wrote in article <5ahmp3$jm0@news.cic.net>... > Do any of you know of a USB host interface (UHCI) design available for > an FPGA (any vendor will do)? -- Steven K. Knapp E-mail: optmagic@ix.netcom.com Programmable Logic Jump Station: http://www.netcom.com/~optmagicArticle: 4945
In article <32d1192d.105679338@news.alt.net> peter@nowhere.com writes: >Philip, > >Am I right in saying that if one uses the Remake All option (xmake -r >IIRC) then the problem does not arise, even with XACT6? No. This problem is sepparate from the behaviour of Remake All. The intent of Remake All is to bypass the (not actually fuctional) behaviour of XMAKE to avoid rebuilding things that are already built. In the past (XC3000 and APR) this made some sense, as there were several steps that could be skipped for pieces of the sub-hierarchy that had not changed. With the current design flow, almost all the compute time occurs in PPR, and because of the way that Wir2Xnf runs, bypassing stuff can't even be done without a lot of (wasted) effort. The problem that Austin found (and I've confirmed) is a sepparate date checking system, local to wir2xnf itself, and manifested in the current, but not previous version. When wir2xnf runs, it checks the following WIR files are newer than the matching SCH file SCH files are newer than the matching SYM file All SYMs in an SCH file are older than the SCH file. Unfortunately, the date handling for 1/1/97 (versus 12/31/96) seems to be broken, and so wir2xnf thinks that there is a need for updating a whole set of things. (I have no idea of the range of dates that are misshandled. ) Whenever things get really messy, I wipe the WIR directory, and run: check -p projectname which seems to a fairly good job of getting everything back the way it should be. There are multiple touch type programs available for dos that are shareware/public-domain. Philip Freidin > >I always use remake-all, since 95% of the time is spent in APR/PPR >anyway. > >Otherwise, one needs the little touch.exe utility which is available >among the many "unix-lookalike" DOS utility kits, or used to come with >DR-DOS. > >Peter.Article: 4946
In article <32CC229E.5A3E@ee.gatech.edu>, Geremy F. <geremy@ee.gatech.edu> wrote: > Application Specific Integrated Ciruit Or: Arrgh! SPICE Isn't Converging! Mike Froggatt Thin Film Microelectronics Group Cambridge University Engineering DepartmentArticle: 4947
this is a test - please ignore.Article: 4948
Altera's PDN9625, dated 19 December 1996, announces last order and delivery dates for the FX880 and 8160 devices (30 June, 97 and 98 respectively). An excuse is offered that the flash process is at end of life. No apology (or cash) is offered for apparently causing esisting customers to re lay out their PCBs to use a different device. And what other Altera device has the flexible clocking, the ample output enables, the 10-bit blocks because you always need a bit more than eight bits for a byte, or the free and excellent development tools? And what other CPLD from anywhere offers the RAM/ROM use of blocks in the way these devices do? Logic that will go into a single look-up table in this ROM would not fit into the whole of most 84-pin PLDs. Perhaps the spec could be simplified a bit: I've not used the compare function, and only used the RAM as a look-up table, so it could be just flash or E^2, without the SRAM, as long as it's ISP. On the other hand a parity function would be nice, and the fan-in of 26 was a few short on some designs. The clocking and output enabling are superb and should be kept. And so should the pinout so we don't have to redesign the PCBs. Between now and June 98 gives Altera ample time to produce such a family of devices. Will they, or will they ditch their customers? Follow-ups from Altera (and from the old INTEL PLD group) will be most welcome. -- Paul Walker 4Links phone/fax paul@walker.demon.co.uk P O Box 816, Two Mile Ash +44 1908 http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253Article: 4949
Alvin E. Toda <aet@lava.net> wrote in article <Pine.BSI.3.91.970102150915.21847A-100000@malasada.lava.net>... >I think that when you talk of commercial over the counter type of >FPGA parts, you don’t really concern your self with high rel >concerns. It’s up to the persons that use these parts to address >these concerns for high rel designs. Note that many of the major FPGA vendors are selling their parts not as commercial devices, but as qualified military/space grade devices. And if a particular technology such as SRAM is chosen, the basic question is can the device be made to perform to the requirements of a 'critical application' without too much pain or risk. For example, pulling a Xilinx data book off of the shelf , they have a chapter on "Military Logic Cell Arrays" and process their devices to MIL-STD-883 Class B and participate in the DESC SMD (standard military drawing) program and have assigned SMD numbers for their parts. Also, Harris had a program to design/build radiation-hardened Xilinx compatibles (HS-XC3020MS) with guaranteed radiation performance. These are not being sold as commercial devices >The goals may be the same (error detection or failing >operational) but the means of getting there will certainly be up to >the designers. Commercial parts certainly don't have these >high rel requirements-- since it seems that consumer items which >have massive production volumes are pushing the technology >at the present time. That is correct - the commercial world for the most part is driving things. But designers of military and space electronics will note that there is a really, really strong push to use more modern, commercial off the shelf (cots) devices. And the original question was what technology should we use: mask programmed asics, sram, antifuse (pick your kind), lpga? and architecturally, how does SRAM-based devices fit into a system with hi-rel requirements? >The technology is still quite young-- if designers think that >these SRAM FPGA parts have a role in high rel applications >than the onus of coming up with "bulletproof"-ness is on them. >It seems to me that simply using a bigger OTP part is more >cost effective that adding redundancy, error detection, or >recovery schemes to the design. At present I agree - although others have talked about SRAM-based devices as a "solution." And is there a possible scheme for making SRAM-based FPGA's "bulletproof" for these types of applications? >But ( as has been mentioned before by someone), it may be a >requirement that it may necessary to fix un-expected operational >problems in flight with programmable h/w changes as well >transmitting fixes to the flight program. However it may just be >cheaper to do another flight for the cost of launching a system >with all this wazoo stuff. While it *may* be a requirement to fix un-expected operational problems in flight, it is a requirement that what is launched/flown/etc. is reliable, otherwise it wouldn't be a 'critical' application. And there are many architectural means of getting there with either mask programmable devices, antifuse-based one's, etc. And computers are built with many of the functions in s/w (and with back-up power supplies, error-correcting memories, parity on busses, etc., etc.) so that things can be modified later. FPGA-based designs can include programmable state machines, micro-sequencers, etc. without having to use SRAM-based devices. And user memory can easily be protected. Clearly, there are some high-performance applications where these approaches won't work. But, putting a ton of patches on SRAM-based devices may clearly be much too complicated/expensive in return for the benefits of reprogrammability. So, I am interested in designers coming up with the ways to make them "bulletproof" as you mentioned. rk ######################################################################## Alvin E. Toda aet@lava.net sr. engineer Phone: 1-808-455-1331 2-Sigma WEB: http://www.lava.net/~aet/2-sigma.html 1363-A Hoowali St. Pearl City, Hawaii, USA ----------
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