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
In article <32B9E9F8.4690@aspect.com>, tjones@aspect.com says... > Alon Hazay wrote: > > > > I'm doing an overview of the FPGA market. > > Does anyone know a review which compares the FPGA's of the leader > > vendors in the market today(ALTERA,XILINX,ACTEL,ORCA etc.)? > > > > Alon Hazay > > > Please post any findings. I would be particularly interested > in objective benchmarks for all the traditional parameters > (routability, etc.) as well as non-traditional, but otherwise > equally useful metrics such as ease-of-use of tools, changeability, > etc. > > Thanks, > Tom Jones > Programmable Electronics Performance Corp. at http://www.prep.org are supposed to be an objective comparision of some of this. Their benchmarks may or may not compare everything you need and there is some controversy in the FPGA world about how well they compare the parts. It might aide your research, though. -- William Vollrath Do you want 1TByte in a 3490 cartridge at 15MBytes/sec? LOTS Technology, Inc. http://www.lasertape.comArticle: 4901
In article <32C2CDB6.2DD7@erols.com>, "Romuald K. Andraka" <randraka@erols.com> wrote: >Wayne Turner wrote: >> 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. > >I'm not sure of your reference here. Yes, a hardwired connection is >inherently more stable than a bit stored in SRAM. There is no reason the >SRAM cell itself would be any less reliable than an ASIC or OTP device! We are talking about configuration data here, which an ASIC has none of, and therefore inherently more stable. As for EEPROM or anti-fuse, as I've said, it generally requires a great deal more external energy to cause a change in state than in the equivalent design in an SRAM device. I am not talking about RAM bits in each of the devices, I am talking about the CONFIGURATION DATA for each of these. >Data (configurations) stored in EEPROM, EPROM and Antifuse based devices are >all susceptible to degradation over time and to incomplete programming. I've >seen several instances of OTP and EPROM >type devices that verify correctly on the programmer then exhibit programming >failures within a few months or years. The vendor analysis of these usually >indicate a weakly programmed bit. ASICs are hardwired, so they will not >suffer from configuration data going bad. However, they are susceptable to >process problems My discussion is relegated to failure rates (or potential failure rates) for these devices, and in a flight application where external radiation is a major factor, I still maintain that SRAM devices are not as reliable (due to being more susceptible to this radiation) than the same design in any other technology. Is this not true?Article: 4902
In article <32C2CFE8.1681@erols.com>, "Romuald K. Andraka" <randraka@erols.com> wrote: >Wayne Turner wrote: > >> Please offer data to support the above statement. Why would Xilinx SRAM >> parts be 10x more reliable than another SRAM part? >I'm not sure about the numbers, but his statement is true regarding the >integrity of the data stored in the XILINX cell relative to data stored >in SRAM used in a microprocessor. The XILINX SRAM cells are >deliberately designed as slow cells so that more energy is required to >cause an upset than a conventional SRAM memory (which is designed for >speed). Are we going to compare apples to apples here? Why would a Xilinx device be 10X more reliable than an Altera device, for example? We already went through the discussion of relative SRAM cell sizes between SRAM memory deives and SRAM -based logic devices. My point of contention was it sounded as though Xilinx were 10X more reliable than other SRAM-based PROGRAMMABLE DEVICES. WayneArticle: 4903
> > 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 > > > > Sundar > > > Altera has PCI macros available, too. Lookm at their web site. They've got free macros with limited functionality, and can connect you with 3rd parties that will sell you full-featured PCI interfaces that can synthesize into their parts. (I suppose Xilinx can refer you to 3rd parties also, but my recent experience is with Altera). -- William Vollrath Do you want 1TByte in a 3490 cartridge at 15MBytes/sec? LOTS Technology, Inc. http://www.lasertape.comArticle: 4904
I am looking for a serial-input and serial-output divider. Ideally, such divider could give the either partial quotient or partial reminder when the partial divisor and partial dividend is given serially bit by bit. If there is such algorithm (close one), I would like to get some reference for that divider. Thank you punArticle: 4905
phony@see.sig.for.real writes: > > David Emrich <emrich@exemplar.com> wrote: > > :Phil Ptkwt Kristin wrote: > :> I've heard that Exemplar will release a Linux version of their Leonardo > :> synthesis tool for Linux early next year. Has anyone else heard this? > :> It would be good if someone from Exemplar could comment on this. > : > :The port is complete for Leonardo 4.0.3. Available in January 97. > : Any other info is available ? The Exemplar webpage does not mention linux at all and if I remeber correctly, on a PC platform Win3.1, Win95 or WinNT is listed as supported OS. Search for the word linux retrieves no do documents. ZoltanArticle: 4906
Wayne Turner wrote: > > In article <32C2CDB6.2DD7@erols.com>, > We are talking about configuration data here, which an ASIC has none of, and > therefore inherently more stable. As for EEPROM or anti-fuse, as I've said, > it generally requires a great deal more external energy to cause a change in > state than in the equivalent design in an SRAM device. I am not talking about > RAM bits in each of the devices, I am talking about the CONFIGURATION DATA for > each of these. > Yes, this is true, but as I stated if the configuration does get corrupted, it can be reloaded easily with the existing configuration logic for an SRAM based device. If the OTP configuration gets upset, you're looking at a considerably more difficult recovery. My point was that *I have* seen instances of OTP device programs being corrupted some time after a successful manufacturing test. > >Data (configurations) stored in EEPROM, EPROM and Antifuse based devices are > >all susceptible to degradation over time and to incomplete programming. I've > >seen several instances of OTP and EPROM > >type devices that verify correctly on the programmer then exhibit programming > >failures within a few months or years. The vendor analysis of these usually > >indicate a weakly programmed bit. ASICs are hardwired, so they will not > >suffer from configuration data going bad. However, they are susceptable to > >process problems > > My discussion is relegated to failure rates (or potential failure rates) for > these devices, and in a flight application where external radiation is a major > factor, I still maintain that SRAM devices are not as reliable (due to being > more susceptible to this radiation) than the same design in any other > technology. Is this not true? Yes it is true. However, the recovery from a corruption of the configuration is more difficult or even impossible in some situations for the OTP devices. All in all, It really comes down to selecting the device that best fits the application, the designer's experience and proper design of fault tolerance. Based on my comfort level and experience with both OTP and SRAM devices, I would choose the SRAM device with carefully designed fault tolerant logic over the OTP for safety critical applications. -Ray Andraka P.E. via remote Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 mailto:randraka@ids.net http://www.ids.net/~randrakaArticle: 4907
Romuald K. Andraka wrote: > > Wayne Turner wrote: > > > > In article <32C2CDB6.2DD7@erols.com>, > > We are talking about configuration data here, which an ASIC has none of, and > > therefore inherently more stable. As for EEPROM or anti-fuse, as I've said, > > it generally requires a great deal more external energy to cause a change in > > state than in the equivalent design in an SRAM device. I am not talking about > > RAM bits in each of the devices, I am talking about the CONFIGURATION DATA for > > each of these. > > > > Yes, this is true, but as I stated if the configuration does get > corrupted, it can be reloaded easily with the existing configuration > logic for an SRAM based device. If the OTP configuration gets upset, > you're looking at a considerably more difficult recovery. My point was > that *I have* seen instances of OTP device programs being corrupted some > time after a successful manufacturing test. > > > >Data (configurations) stored in EEPROM, EPROM and Antifuse based devices are > > >all susceptible to degradation over time and to incomplete programming. I've > > >seen several instances of OTP and EPROM > > >type devices that verify correctly on the programmer then exhibit programming > > >failures within a few months or years. The vendor analysis of these usually > > >indicate a weakly programmed bit. ASICs are hardwired, so they will not > > >suffer from configuration data going bad. However, they are susceptable to > > >process problems > > > > My discussion is relegated to failure rates (or potential failure rates) for > > these devices, and in a flight application where external radiation is a major > > factor, I still maintain that SRAM devices are not as reliable (due to being > > more susceptible to this radiation) than the same design in any other > > technology. Is this not true? > > Yes it is true. However, the recovery from a corruption of > the configuration is more difficult or even impossible in some > situations for the OTP devices. All in all, It really comes down to > selecting the device that best fits the application, the designer's > experience and proper design of fault tolerance. Based on my comfort > level and experience with both OTP and SRAM devices, I would choose the > SRAM device with carefully designed fault tolerant logic over the OTP > for safety critical applications. I agree with Ray, especially when you consider that some(many?) of the EPROM, EEPROM and Flash based devices simply copy the configuration data into internal SRAM on powerup. This isn't always mentioned in the documentation. The end result is device that's just as susceptible to upsets as an SRAM only device, but without the inherent configuration verification. I had problems with Altera Classic (EP900) devices many years ago because short spikes on Vcc or too-slow Vcc ramp-up produced improper configuration. That was enough to send me running to Xilinx. Regards, ScottArticle: 4908
Will : I searched the philips site at www.semiconductors.philips.com for the suggested keyword -and alikes-, but did not find the mentioned information... Thanks in advance for any further detail. -- Return address is invalid to defeat junk mail. Please reply to : alse@compuserve.com. -------------------------------------------------------- Wil Taphoorn <wil@tms.hobby.nl> wrote in article <6NX7yRRJ9FB@tms.hobby.nl>... > John L. Smith wrote on 20.12.96 about "Re: I2C Bus Interface in FPGAs": > > >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. > > Not if it's from the makers of... > > > However, if someone has developed something in the meantime, pls > > let me know too. > > Yes, Aloys Schatorje (Philips The Netherlands) did... His examples for > both receiver and transmitter on a PLC42CA12 are written in SNAP > > Try www.semiconductors.philips.com, try to search for 'iic_plc4'. > > regards, > wil > -- > >Article: 4909
In article <32C49ED0.70CE@erols.com>, "Romuald K. Andraka" <randraka@erols.com> wrote: >Wayne Turner wrote: >> >> In article <32C2CDB6.2DD7@erols.com>, >> We are talking about configuration data here, which an ASIC has none of, and >> therefore inherently more stable. As for EEPROM or anti-fuse, as I've said, >> it generally requires a great deal more external energy to cause a change in >> state than in the equivalent design in an SRAM device. I am not talking about >> RAM bits in each of the devices, I am talking about the CONFIGURATION DATA for >> each of these. >> > >Yes, this is true, but as I stated if the configuration does get >corrupted, it can be reloaded easily with the existing configuration >logic for an SRAM based device. If the OTP configuration gets upset, >you're looking at a considerably more difficult recovery. My point was >that *I have* seen instances of OTP device programs being corrupted some >time after a successful manufacturing test. > >> >Data (configurations) stored in EEPROM, EPROM and Antifuse based devices are >> >all susceptible to degradation over time and to incomplete programming. I've >> >seen several instances of OTP and EPROM >> >type devices that verify correctly on the programmer then exhibit programming >> >failures within a few months or years. The vendor analysis of these usually >> >indicate a weakly programmed bit. ASICs are hardwired, so they will not >> >suffer from configuration data going bad. However, they are susceptable to >> >process problems >> >> My discussion is relegated to failure rates (or potential failure rates) for >> these devices, and in a flight application where external radiation is a major >> factor, I still maintain that SRAM devices are not as reliable (due to being >> more susceptible to this radiation) than the same design in any other >> technology. Is this not true? > >Yes it is true. However, the recovery from a corruption of >the configuration is more difficult or even impossible in some >situations for the OTP devices. All in all, It really comes down to >selecting the device that best fits the application, the designer's >experience and proper design of fault tolerance. Based on my comfort >level and experience with both OTP and SRAM devices, I would choose the >SRAM device with carefully designed fault tolerant logic over the OTP >for safety critical applications. Boeing and Honeywell (I worked at Honeywell on the 777) seem to disagree with you. If you do the NUMBERS, there is an obvious MTBF advantage of the EEPROM or anti-fuse device, or better yet, an ASIC, given equivalent flight environment conditions. BTW, I liked your web page. I happened to catch a link to it whilst surfing around on FPGA stuff... WayneArticle: 4910
In article <32C4BA75.79AF@e-field.com>, Scott Kroeger <Scott.Kroeger@e-field.com> wrote: >Romuald K. Andraka wrote: >> >> Wayne Turner wrote: >> > >> > In article <32C2CDB6.2DD7@erols.com>, >> > We are talking about configuration data here, which an ASIC has none of, and >> > therefore inherently more stable. As for EEPROM or anti-fuse, as I've said, >> > it generally requires a great deal more external energy to cause a change in >> > state than in the equivalent design in an SRAM device. I am not talking about >> > RAM bits in each of the devices, I am talking about the CONFIGURATION DATA for >> > each of these. >> > >> >> Yes, this is true, but as I stated if the configuration does get >> corrupted, it can be reloaded easily with the existing configuration >> logic for an SRAM based device. If the OTP configuration gets upset, >> you're looking at a considerably more difficult recovery. My point was >> that *I have* seen instances of OTP device programs being corrupted some >> time after a successful manufacturing test. >> >> > >Data (configurations) stored in EEPROM, EPROM and Antifuse based devices are >> > >all susceptible to degradation over time and to incomplete programming. I've >> > >seen several instances of OTP and EPROM >> > >type devices that verify correctly on the programmer then exhibit programming >> > >failures within a few months or years. The vendor analysis of these usually >> > >indicate a weakly programmed bit. ASICs are hardwired, so they will not >> > >suffer from configuration data going bad. However, they are susceptable to >> > >process problems >> > >> > My discussion is relegated to failure rates (or potential failure rates) for >> > these devices, and in a flight application where external radiation is a major >> > factor, I still maintain that SRAM devices are not as reliable (due to being >> > more susceptible to this radiation) than the same design in any other >> > technology. Is this not true? >> >> Yes it is true. However, the recovery from a corruption of >> the configuration is more difficult or even impossible in some >> situations for the OTP devices. All in all, It really comes down to >> selecting the device that best fits the application, the designer's >> experience and proper design of fault tolerance. Based on my comfort >> level and experience with both OTP and SRAM devices, I would choose the >> SRAM device with carefully designed fault tolerant logic over the OTP >> for safety critical applications. > > >I agree with Ray, especially when you consider that some(many?) of the >EPROM, EEPROM >and Flash based devices simply copy the configuration data into internal >SRAM on powerup. >This isn't always mentioned in the documentation. The end result is Other than the Altera FLEXLogic (previously named FlashLogic when Intel owned the product) devices, what devices do that? I think they are the only combination FLASH/SRAM devices I know of, and I don't know of any EEPROM devices that do that at all. Are there any? WayneArticle: 4911
waynet@indirect.com (Wayne Turner) wrote: >In article <32C2CFE8.1681@erols.com>, > "Romuald K. Andraka" <randraka@erols.com> wrote: >>Wayne Turner wrote: >> >>> Please offer data to support the above statement. Why would Xilinx SRAM >>> parts be 10x more reliable than another SRAM part? > >>I'm not sure about the numbers, but his statement is true regarding the >>integrity of the data stored in the XILINX cell relative to data stored >>in SRAM used in a microprocessor. The XILINX SRAM cells are >>deliberately designed as slow cells so that more energy is required to >>cause an upset than a conventional SRAM memory (which is designed for >>speed). > >Are we going to compare apples to apples here? Why would a Xilinx device be >10X more reliable than an Altera device, for example? We already went through >the discussion of relative SRAM cell sizes between SRAM memory deives and SRAM >-based logic devices. My point of contention was it sounded as though Xilinx >were 10X more reliable than other SRAM-based PROGRAMMABLE DEVICES. > >Wayne From my experience with high technology computing and electronics for military aircraft systems, one need to take into account the size of the susceptible portion of a chip from the point of view of cross sectional area. The most prevalent source of single event upsets (SEU) comes from high energy cosmic rays, having enough energy to upset even large SRAM cells. So, designers have to look at the cross sectional area of the cell to assess the probability of a cell getting hit. Some work one of my colleagues performed came to the conclusion that DRAM cells, although upset by lower energies, the smaller cell size make the chance of an upset much less likely. Another factor to consider in this discussion...All components have susceptibility in the form of registers, local memories, state machines, etc. ASIC's aren't immune, especially those with large on chip memory structures. Again one has to look at the overall cross sectional area involved in storage. BTW, I recall the cross sectional area is measured in units of barns (as in couldn't the broadside of one). jeffArticle: 4912
I actually think that the best solution for this argument is to point to the Xilinx GA products that they manufacture with the programming done as a metal layer in the fab process... i.e., one time programmed during fab versions of their programmable devices. You work out the design with loadable ones and then send them the program, and you get dedicated ASICs back. I think we've seen that both OTP and FPGA have failure modes which make flight-critical people nervous. I certainly am 8-) -george william herbert Retro Aerospace gherbert@crl.comArticle: 4913
Wayne Turner wrote: > > In article <32C4BA75.79AF@e-field.com>, > Scott Kroeger <Scott.Kroeger@e-field.com> wrote: > >I agree with Ray, especially when you consider that some(many?) of the > >EPROM, EEPROM > >and Flash based devices simply copy the configuration data into internal > >SRAM on powerup. > >This isn't always mentioned in the documentation. The end result is > > Other than the Altera FLEXLogic (previously named FlashLogic when > Intel owned the product) devices, what devices do that? I think they are the > only combination FLASH/SRAM devices I know of, and I don't know of any EEPROM > devices that do that at all. Are there any? > > Wayne Wayne, I think I overspoke (shame on me). Now, if I stick to what I KNOW, I should have said: ... consider that some of the EPROM and Flash based devices copy the ... I was referring to Altera's FLEXLogic and Classic EPLD families. At the time I had my problem with the EP900, Altera indicated that the EPROM storage cell couldn't be used to actually control a logic gate (at that time any such structure would have been much too slow). This is no longer the case, but you can't tell how the part works from the data sheet (you will not see any mention of the SRAM based nature of Altera Classic EPLD's in the datasheet). In some data sheets you will see reference to power on reset functions that may take microseconds to complete after Vcc stabilizes (and perhaps requirements for monotonically increasing Vcc). In the Altera Classic devices this delay (and the requirement for monotonic Vcc rise) was caused by EPROM->SRAM load. Things may have changed since then, but power-on-delays and monotonic Vcc rise specs still make me wonder. I suppose I've had my head buried in the Xilinx sand long enough to be worth ignoring for my knowledge of the physics of other devices. Regards, ScottArticle: 4914
On Fri, 27 Dec 1996, Romuald K. Andraka wrote: . . > Yes it is true. However, the recovery from a corruption of > the configuration is more difficult or even impossible in some > situations for the OTP devices. All in all, It really comes down to > selecting the device that best fits the application, the designer's > experience and proper design of fault tolerance. Based on my comfort . . > -Ray Andraka P.E. via remote > Chairman, the Andraka Consulting Group > 401/884-7930 FAX 401/884-7950 > mailto:randraka@ids.net > http://www.ids.net/~randraka > > 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). The treatment of the loading of the FPGA seems to be different in my opinion according to how you stand on the usefulness of the device. Those who deem the device less reliable seem to treat the loading of the device as part of the analysis of the reliability of the device-- it is hard to deny that having to insure almost perfect loading on every occasion is harder to justify than testing the other part just once to ensure proper programming. On the other hand, those who are more aggressive in using the device seem treat the loading of the device as part of the system function of the board. Certainly it is hard to deny here that adding a lot of possible failure modes to system operation will contribute to less system reliability. Parts-wise the board they deem at least as safe as the SRAM's which may be on the board. Function-wise the re-programming of the part may be more cost effective than simply using a bigger one time programmable part-- the decrease in system reliability is worth the savings. 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. ######################################################################## 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: 4915
I've been searching for a while for vga signal generation
implementations.
I have seen
i) IBM DAC/palette chip products (as the example)
ii) a vga hsynch, vsynch signal setup as part of a
digital oscilloscope electronics article.
iii) many video card descriptions/setups
But no general 'how to interface' information for
setting up a basic framebuffer and vga signal generator.
Article: 4916jimmiew@sprynet.com (James West) writes: > 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. Sounds familiar, I've asked the same question here too :-) No replies, so I did some dabbling on the project. Like you say, the actual interface would not have been too difficult, but the system will end up using quite a lot of registers because it involves bit counters etc. I was targeting for Lattice ispLSI 1016 and dropped the project after I realized that once the other functions and the (still vaguely sketched) I2C interface were on the chip, there wouldn't be registers left to store the data that was to be controlled via I2C. Depending on the application, this would need a larger FPGA, or you must be willing to ditch compatibility and cut some corners in the I2C protocol (like forget about real ACKs, just clock the stuff in/out). A Microwire-type clock/data/CS scheme would be much easier to implement (not much more than a shift register, with maybe double buffering). -- http://www.hut.fi/~iisakkil/ - Rebi siitArticle: 4917
George Herbert <gherbert@crl.com> wrote in article <5a6uav$4tu@crl4.crl.com>... > I actually think that the best solution for this argument is to > point to the Xilinx GA products that they manufacture with the > programming done as a metal layer in the fab process... i.e., > one time programmed during fab versions of their programmable > devices. You work out the design with loadable ones and then > send them the program, and you get dedicated ASICs back. > > I think we've seen that both OTP and FPGA have failure modes > which make flight-critical people nervous. I certainly am 8-) > > > -george william herbert > Retro Aerospace > gherbert@crl.com > > A couple questions/comments about this solution: Many of the manufacturers offer this type of conversion, primarily for economic reasons and other companies will convert designs for you. But, while the metal mask will get rid of the configuration memory problems, latchup is still a concern (primarily for space systems). Data on the Xilinx XC3090, for instance, shows latchup threshold of ~4-7 which is really low and the device failed during testing. I haven't yet seen any data on the 'hard-wired' products and don't know if they use a process and design rules similar to the regular XC3090. rkArticle: 4918
Jeff Millar <jeff@wa1hco.mv.com> wrote in article <32c7e6a0.4519776@news.mv.net>... > waynet@indirect.com (Wayne Turner) wrote: > > >In article <32C2CFE8.1681@erols.com>, > > "Romuald K. Andraka" <randraka@erols.com> wrote: > >>Wayne Turner wrote: > >> > >>> Please offer data to support the above statement. Why would Xilinx SRAM > >>> parts be 10x more reliable than another SRAM part? > > > >>I'm not sure about the numbers, but his statement is true regarding the > >>integrity of the data stored in the XILINX cell relative to data stored > >>in SRAM used in a microprocessor. The XILINX SRAM cells are > >>deliberately designed as slow cells so that more energy is required to > >>cause an upset than a conventional SRAM memory (which is designed for > >>speed). > > > >Are we going to compare apples to apples here? Why would a Xilinx device be > >10X more reliable than an Altera device, for example? We already went through > >the discussion of relative SRAM cell sizes between SRAM memory deives and SRAM > >-based logic devices. My point of contention was it sounded as though Xilinx > >were 10X more reliable than other SRAM-based PROGRAMMABLE DEVICES. > > > >Wayne > > From my experience with high technology computing and electronics for > military aircraft systems, one need to take into account the size of > the susceptible portion of a chip from the point of view of cross > sectional area. The most prevalent source of single event upsets > (SEU) comes from high energy cosmic rays, having enough energy to > upset even large SRAM cells. So, designers have to look at the cross > sectional area of the cell to assess the probability of a cell getting > hit. Some work one of my colleagues performed came to the conclusion > that DRAM cells, although upset by lower energies, the smaller cell > size make the chance of an upset much less likely. > > Another factor to consider in this discussion...All components have > susceptibility in the form of registers, local memories, state > machines, etc. ASIC's aren't immune, especially those with large on > chip memory structures. Again one has to look at the overall cross > sectional area involved in storage. > > BTW, I recall the cross sectional area is measured in units of barns > (as in couldn't the broadside of one). > > jeff while large SRAM cells may be upset by cosmic rays, making SRAM cells effectively immune to SEU is a solved problem - there are a number of techniques used to accomplish this including cross-strapped resistors, epi-layer thickness control, and the use of different processes such as SOI and SOS. The voltage the cells are run at also have a large impact on what the SEU performance will be. The threshold LET of these hardened devices is very, very high. Of course, these devices are expensive and are, at present to the best of my knowledge, limited to a 1 MBit density. relating this to ASICs, these same techniques have been applied to ASICs and are available from a number of different manufacturers while also offering hardness to total ionizing dose and latchup. the comparison of sram vs. dram memory needs to be made very carefully as it depends on the sram and dram selected. most drams have a very low let threshold - srams vary all over the place from very low to effectively immune. as mentioned above, there are techniques for hardeneing them. a lot of the high density srams don't use a 6 transistor cell which hurts seu performance. another consideration is hard errors, which many drams and some commercial srams are susceptible to. for a good comparison, the x-section vs. let curve should be used along with an environment model. i'd differ from your conclusion in general and from a design point of view, i can easily design sram memories that are immune to seu - the comparable dram design would be more complex since the dram controller is more complex than a simple sequencer for srams, takes more power, is not always available, and would need edac or some error-correcting/scrubbing mechanism to achieve the same level of seu performance. for very high density, large memory arrays the drams are worth the extra trouble with perhaps reed-solomon encoding. also, for high energy cosmic rays, latchup is also a consideration. rkArticle: 4919
> > Yes it is true. However, the recovery from a corruption of > > the configuration is more difficult or even impossible in some > > situations for the OTP devices. All in all, It really comes down to > > selecting the device that best fits the application, the designer's > > experience and proper design of fault tolerance. Based on my comfort > . > . > > -Ray Andraka P.E. via remote > > Chairman, the Andraka Consulting Group > > 401/884-7930 FAX 401/884-7950 > > mailto:randraka@ids.net > > http://www.ids.net/~randraka sram fpga's are interesting, potentially offer a lot of advantages, and here's a couple of questions: how are the effects of a reconfiguration blocked from affecting the function of the board/system? how is reconfiguration detected and how often is this done? where is the master copy stored? is this in an "evil" :-) otp device such as a PROM (pick your technology, fuse (nicrome, polysilicon), antifuse (dielectric, amorphous silicon), eprom, eeprom)? is the PROM used to store the original program that is used for reload? if it's an sram, what if the power blinks? can a configuration error result in any of the following and what are the effects: 1. turning an input cell into an output, overstressing drivers; 2. turning a tri-state driver into a driver that is always enabled, again overstress question; 3. causing two fpga drivers onto the same routing track, again overstress question; 4. complete reboot of the fpga, causing it to reload and think it's in the unprogrammed state, at a very unfortunate time, negating any redundancy designed into the fpga 5. if jtag is used (and many manufacturers do not implement the optional hard reset pin) and the tap controller is upset, can all of the pins turn to outputs, preventing reloading? 6. can a seu during the load process cause an illegal configuration to be loaded, resulting in major problems? (equivalent to getting a parity error in the parity error handling routine). 7. turn a output into an input, having floating nodes on the board, with perhaps high-speed oscillation and excessive currents generated, along with obvious system faults? 8. change the delay in an input (like the xilinx has) or output slew rate, resulting in infrequent timing problems and system glitches? this would be hard to detect if a mechanism like a system watchdog timer is used to detect system failure. 9. how does the "system" operate during a reload? do external "safing circuits" need to be added to the board design? can a vcc glitch cause the fpga to think the power went off and go into a initialization state but the system board did not? can an incorrect vcc ramp up cause the fpga to be incorrectly initialized and not load properly? rkArticle: 4920
Philips did do some PLD code for some of there older chip. Look at Application Notes AN036 , AN038 , AN039 They are in the old PROGRAMMABLE LOGIC DEVICES DataBook " IC13" 1994 Hope this helps and let me know how it goes. David Payne " microcomm.co.nz " >Bertrand wrote: > > Will : > I searched the philips site at www.semiconductors.philips.com for the > suggested > keyword -and alikes-, but did not find the mentioned information... > > Thanks in advance for any further detail. > -- > Return address is invalid to defeat junk mail. > Please reply to : alse@compuserve.com. > > -------------------------------------------------------- > Wil Taphoorn <wil@tms.hobby.nl> wrote in article > <6NX7yRRJ9FB@tms.hobby.nl>... > > John L. Smith wrote on 20.12.96 about "Re: I2C Bus Interface in FPGAs": > > > > >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. > > > > Not if it's from the makers of... > > > > > However, if someone has developed something in the meantime, pls > > > let me know too. > > > > Yes, Aloys Schatorje (Philips The Netherlands) did... His examples for > > both receiver and transmitter on a PLC42CA12 are written in SNAP > > > > Try www.semiconductors.philips.com, try to search for 'iic_plc4'. > > > > regards, > > wil > > -- > > > >Article: 4921
In article <5a6uav$4tu@crl4.crl.com>, gherbert@crl.com (George Herbert) wrote: >I actually think that the best solution for this argument is to >point to the Xilinx GA products that they manufacture with the >programming done as a metal layer in the fab process... i.e., >one time programmed during fab versions of their programmable >devices. You work out the design with loadable ones and then >send them the program, and you get dedicated ASICs back. > >I think we've seen that both OTP and FPGA have failure modes >which make flight-critical people nervous. I certainly am 8-) Altera has the same with their MPLD (mask-programmed-logic-device) that makes a masked version of your programmable device. This is for both SRAM and EEPROM devices. WayneArticle: 4922
In article <5a6uav$4tu@crl4.crl.com>, gherbert@crl.com (George Herbert) wrote: >I actually think that the best solution for this argument is to >point to the Xilinx GA products that they manufacture with the >programming done as a metal layer in the fab process... i.e., >one time programmed during fab versions of their programmable >devices. You work out the design with loadable ones and then >send them the program, and you get dedicated ASICs back. > >I think we've seen that both OTP and FPGA have failure modes >which make flight-critical people nervous. I certainly am 8-) Altera has the same with their MPLD (mask-programmed-logic-device) that makes a masked version of your programmable device. This is for both SRAM and EEPROM devices. WayneArticle: 4923
In article <Pine.BSI.3.91.961229231119.12091A-100000@malasada.lava.net>, "Alvin E. Toda" <aet@lava.net> wrote: >On Fri, 27 Dec 1996, Romuald K. Andraka wrote: >.. >.. >> Yes it is true. However, the recovery from a corruption of >> the configuration is more difficult or even impossible in some >> situations for the OTP devices. All in all, It really comes down to >> selecting the device that best fits the application, the designer's >> experience and proper design of fault tolerance. Based on my comfort >.. >.. >> -Ray Andraka P.E. via remote >> Chairman, the Andraka Consulting Group >> 401/884-7930 FAX 401/884-7950 >> mailto:randraka@ids.net >> http://www.ids.net/~randraka >> >> >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). >The treatment of the loading of the FPGA seems to be different in my >opinion according to how you stand on the usefulness of the device. >Those who deem the device less reliable seem to treat the loading of the >device as part of the analysis of the reliability of the device-- it is hard to >deny that having to insure almost perfect loading on every occasion is >harder to justify than testing the other part just once to ensure proper >programming. > >On the other hand, those who are more aggressive in using the device >seem treat the loading of the device as part of the system function of the >board. Certainly it is hard to deny here that adding a lot of possible >failure modes to system operation will contribute to less system >reliability. Parts-wise the board they deem at least as safe as the SRAM's >which may be on the board. Function-wise the re-programming of the >part may be more cost effective than simply using a bigger one time >programmable part-- the decrease in system reliability is worth the >savings. > >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. WayneArticle: 4924
Dear John & Wil (& others with interest)...
My appologies for the difficulty in finding the application note
for I2C in our 42VA12. We have recently launched a new family of
High Speed (6nS), zero power (>100uA) CPLDs, and have replaced our
most direct link to PLD information with our new CPLD web page
(www.coolpld.com). The application note for the 42VA12 I2C is still
obtainable - although via a circuitous route:
Go To www.semiconductors.philips.com
Then select 'Technical Documentation'
Then Select 'PLDs'
You are looking for AN036 "I2C Bus Expander" which is available
in Adobe Acrobat format.
Good Luck with your design, and don't hesitate to let us know if
we can help!
Mark Aaldering - Applications & Architecture Development Manager
Philips Programmable Products Group
9201 Pan American Freeway NE
M/S - 08
Albuquerque, NM, USA 87113
Phone: 505-822-7835 Fax: 505-822-7804
Email: Mark.Aaldering@abq.sc.philips.com
CoolRunner Support: coolpld@scs.philips.com
CoolRunner Web Site: www.coolpld.com
----------------------------------------------------------------------------
On Mon, 30 Dec 1996 11:46:18 -0800, David <david@microcomm.co.nz>
wrote:
>Philips did do some PLD code for some of there older chip.
>Look at Application Notes AN036 , AN038 , AN039
>
>They are in the old PROGRAMMABLE LOGIC DEVICES DataBook " IC13" 1994
>Hope this helps and let me know how it goes.
>
>David Payne " microcomm.co.nz "
>
>>Bertrand wrote:
>>
>> Will :
>> I searched the philips site at www.semiconductors.philips.com for the
>> suggested
>> keyword -and alikes-, but did not find the mentioned information...
>>
>> Thanks in advance for any further detail.
>> --
>> Return address is invalid to defeat junk mail.
>> Please reply to : alse@compuserve.com.
>>
>> --------------------------------------------------------
>> Wil Taphoorn <wil@tms.hobby.nl> wrote in article
>> <6NX7yRRJ9FB@tms.hobby.nl>...
>> > John L. Smith wrote on 20.12.96 about "Re: I2C Bus Interface in FPGAs":
>> >
>> > >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.
>> >
>> > Not if it's from the makers of...
>> >
>> > > However, if someone has developed something in the meantime, pls
>> > > let me know too.
>> >
>> > Yes, Aloys Schatorje (Philips The Netherlands) did... His examples for
>> > both receiver and transmitter on a PLC42CA12 are written in SNAP
>> >
>> > Try www.semiconductors.philips.com, try to search for 'iic_plc4'.
>> >
>> > regards,
>> > wil
>> > --
>> >
>> >
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