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
Hi everyone: When I started this question a couple of weeks ago I had no idea I'd get so many responses! Thanks for all the comments. Having read all the comments, it was interesting to find out that only one person thought that ASICs would be significantly safer than FPGAs ( I guess assuming you'd test either one throughly before shipping your board). Most of the discussions were centered around Anti-fuse/Fuse technology Vs. SRAM based technology. Does any one care to comment on the use of flash or EEPROM/EPROM technology for safety critical applications? Would a minimum guaranted data retention of 10 years (in most cases) persuade you not to use these parts? What about the reliablity of flash/EEPROMs used to store your SRAM FPGA data? Regards, Kayvon Irani Los Angeles, CaArticle: 4876
>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. A Schmitt trigger (not the same thing as a "filter") can easily run with a say 50MHz clock, and it would prevent the problem on which I have wasted many hours, namely that even a 300MHz scope may not show the tiny non-monotonic waveform artefacts which are enough for these devices to misconfigure. It would also make it nice and easy to route a clock all over a board full of these devices - all you would need to do is drive that clock from something slow, e.g. a HC gate, or from a RC filter. Presently, one often cannot do that because a loaded HC output can easily take >30ns to switch, and that I found is the upper limit for XC3000 reliable loading. I am not saying that one cannot make these devices load reliably. Of course one can. It is just that Xilinx have made it unnecessarily difficult. Peter. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4877
Announcement of Trianus/Hades tools for Xilinx XC6200 FPGA ========================================================== The Institute for Computer Systems of ETH Zurich is proud to announce the first publicly available CAD tool suite for the new Xilinx XC6200 FPGA architecture. The Trianus/Hades package was developed using the Oberon System over the past three years by two graduate students, Stephan Gehring and Stefan Ludwig. It uses and runs under the Oberon System V4 from the Institute for Computer Systems, ETH Zurich, Switzerland and the Institute for System Software, University of Linz, Austria. See the text below for a detailed description of the capabilities of the CAD software. Go to http://www-cs.inf.ethz.ch/Wirth/CADTools.html#Trianus for more information and for downloading instructions or use anonymous ftp to ftp-cs.inf.ethz.ch and go to directory /pub/Trianus The development of this software was possible due to the open architecture of the XC6200. It was not developed by Xilinx, Inc. and is different from their Camelot software for the XC6200. We would like to thank Xilinx Scotland and Xilinx San Jose for their continuing support over the past years, without which the development of this software would not have been possible. Comments and criticism is welcomed. Have a nice holiday! Stefan Ludwig, Stephan Gehring ------------------------------------------------------------------------ Stefan H-M Ludwig Institute for Computer Systems mailto:ludwig@inf.ethz.ch ETH Zentrum http://www.inf.ethz.ch/personal/ludwig CH-8092 Zurich, Switzerland Phone: +41-1-632 7301 Fax: +41-1-632 1307 Trianus/Hades by Stephan Gehring/Stefan Ludwig The Trianus/Hades software system consists of a suite of tightly integrated tools for the efficient design and implementation of algorithms for a custom computing machine. The software is built upon a generic framework for FPGA circuit design and comprises a compiler for the Lola hardware description language, a layout editor, a circuit checker, a technology mapper, a placer, a router, and a bit-stream generator and loader for the Xilinx XC6200 architecture. We argue that a tight coupling of design tools provides a base for fast iterative and interactive circuit design, a feature which current systems provide only in a very limited form. Hardware Description Language Lola by Niklaus Wirth Lola was designed as a simple, easily learned hardware description language for describing synchronous, digital circuits. In addition to its use in a digital design course for second year computer science students at ETH Zurich, the Institute for Computer Systems uses it as a hardware description language for describing hardware designs in general and coprocessor applications in particular. The purpose of Lola is to statically describe the structure and functionality of hardware components and of the connections between them. A Lola text is composed of declarations and statements. It describes the hardware on the gate level in the form of signal assignments. Signals are combined using operators and assigned to other signals. Signals and the respective assignments can be grouped together into types. An instance of a type is a hardware component. Types can be composed of instances of other types, thereby supporting a hierarchical design style and they can be generic (e.g. parametrizable with the word-width of a circuit).Article: 4878
>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? Thanks JohnArticle: 4879
I have a H/W design that requires an unsigned integer divider (20-bit divided by 10-bit integer) running at 13.5MHz. Does anyone know off-the-shelf IC that can satisfy such requirement? Only other option I have, if there is no such IC available, is to implement non-restoring divide algorithm in FPGA and use many in parallel. Thank you in advance. J ChoArticle: 4880
In article <32BA3F27.1FDE@churchill.columbiasc.ncr.com> Joe Hinrichs <jhinrich@churchill.columbiasc.ncr.com> writes: >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: >>..... >>.... >>... .... ... .. >>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. ..... I don't agree the same fate applies to all. Especially in auto crashes, not all die in a crash fatal to one. In air crashes, fatality ratios vary greatly - though the 100% ones make the most press. I would argue that a disproportionate percentage of airline passengers are fatalities with respect to automobile passengers, and that makes the human cost of system critical failures higher - when measured in deaths per people-miles. Arnold Frisch Tektronix Laboratories -------------------------------------------------------- Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer. --------------------------------------------------------Article: 4881
How about an SA110 (StrongARM processor from DEC), or R4650 or R4640 MIPS processor from IDT. In article <59mc7o$2r0@news.service.uci.edu> cho@newport.ece.uci.edu (Jae Cho) writes: >I have a H/W design that requires an unsigned integer divider >(20-bit divided by 10-bit integer) running at 13.5MHz. Does >anyone know off-the-shelf IC that can satisfy such requirement? >Only other option I have, if there is no such IC available, is >to implement non-restoring divide algorithm in FPGA and use >many in parallel. > >Thank you in advance. > >J Cho >Article: 4882
Gerhard Hoffmann 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 i don't follow the argument. ignoring fact that you need a higher Qcrit for FPGA memory cell, i would guess that an FPGA would have a higher rate of failure than an asic which implements the same function. the fpga has at least the same number of memory locations, but has the additional configuration bits... -- ben Ben Mathew http://reality.sgi.com/mathew/mathew.html (url) Silicon Graphics, Inc., MS 10U-552 mathew@sgi.com (email) 2011 North Shoreline Blvd. 415-933-4241 (voice) Mountain View, CA 94043 415-390-6176 (fax)Article: 4883
In article <59edl7$bpa@news.goodnet.com> waynet@goodnet.com (Wayne Turner) writes: >>It is worth noting that the OTP devices (especially the eprom and eeprom >>types) are also susceptible to upset by high energy particles/radiation... > >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. Note that some of the more complex OTP devices are now reportedly using SRAM cells internally, with the SRAM loaded from EPROM at powerup. Just because it's nonvolatile doesn't mean that no SRAM is involved... -- "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: 4884
Not released yet (that I know of...) Austin Franklin ..darkroom@ix.netcom.com. CMJsemi <cmjsemi@aol.com> wrote in article <19961223000800.TAA29566@ladder01.news.aol.com>... > Has anyone seen the new XLNX M-1 software for the EX family. Any comments? > thanks :) > > Chris >Article: 4885
I have done four PCI designs of my own. Three target/master, and one burst target. Three have been in a Xilinx 4ke, and one in a 4k. PCI is tough to implement in an FPGA because of the 33MHz speed requirement. This necessitates a lot of manual placement and logic mapping. It is very easy to underestimate what it takes to implement a PCI design in an FPGA.... The PCI interface it self is only about %25 of the work. The back end interface is the other %75. Given this, just buying a canned PCI interface may end up being more work than doing it from scratch. Austin Franklin ..darkroom@ix.netcom.com. Sundar Gopalan <sundar@com21.com> wrote in article <32BABA56.2781E494@com21.com>... > 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 >Article: 4886
If you are using or going to use 68HC16 microcontroller, you may be interested to look at HC16BGND, an advanced programmer’s interface that helps you to develop, test, and refine your assembly language programs for MOTOROLA’s 68HC16 microcontrollers. The key features include: - Run under MS Windows - Interface through PC’s parallel port - Motorola suggested 10 pin target connector - Download and debug HC16 assembly language program in S19 or HEX format - trace through your code by step through or step over - set up to 100 breakpoints - On-screen editing of register and data memory - On-fly assembly of instruction using mnemonics in program memory - Open infinite Register, Program, and Data windows - Watch window so that you can watch important variables - Exchange data through Windows clipboard - File I/O which can be used to automatically read a hex input file into the file and write the result to an output file. - Easy to use. Just click on the menu with left mouse or click on the windows’ area. Everything is self-explained - Convenient and easy to install due to its parallel port interface. You can use laptop to do an on-site demonstration of you products - Low cost - 30 day money back guarantee and one year product warranty For more information or need a demo program, see http://users.why.net/wctech/hc16bgnd.htm, or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, or send email to WCTECH@WHY.NET Larry Chen WC TechnologyArticle: 4887
Perhaps this begs the issue, perhaps not. Let's pose these questions: Who amongst us (in the listening audience) has *experienced* an unsatisfactory level of reliability in a [fuse-programmed | SRAM-based] FPGA ? Of these experiences, which are *unresolved* (i.e. not "fixed") issues ? [Let's not cloud the issues with problems appropriately attributable to the designer's "learning curve" in the use of the devices.] Are these reliability problems, if identified, attributable to the FPGA's [SRAM | fuse-programmed] architecture ? I *have* experienced unreliability problems in an FPGA design, but the issues were completely unrelated to SRAM vs. fuse issues. I *expect* that reliability simply has not been an issue in practice with *either* type of FPGAs, and the reliability issue is a question primarily in the eyes of designers who have not yet gained practical experience (mileage) with the type of FPGA that they are regarding as "suspect". Dealing with an issue on a basis of supposition is OK if the real-world experience is lacking. As a designer, I *prefer* dealing with issues based on real-world practical experience, when possible. If there *are* real-world experiences of reliability problems that are fundamental to a given FPGA architecture or technology, those sorts of issues are proper and interesting subjects for this newsgroup. -- Bob Elkind **************************************************************** Bob Elkind mailto:eteam@aracnet.com 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ****** Video processing, R&D, ASIC, FPGA design consulting *****Article: 4888
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: 4889
I assume when you say 13.5MHz you mean you want to get the result in 74ns. This is not easy, since ordinary division will take (at least) 20 clocks, and even a Newton-Raphson division will need maybe 5-10 clocks to do it. And I am not sure of N/R division is worth doing for such short numbers; certainly for 80-bit stuff it makes a big difference. Should be possible in a fast FPGA though. I suggest you look up division using successive approximation, and other clever ways of doing it. What will certainly help a lot with regard to parallelism is if you can generate multiple clocks, slightly skewed relative to each other. This will probably have to be done externally. In things like micros these are done using gate delays but you obviously don't want to do that in an FPGA. >I have a H/W design that requires an unsigned integer divider >(20-bit divided by 10-bit integer) running at 13.5MHz. Does >anyone know off-the-shelf IC that can satisfy such requirement? >Only other option I have, if there is no such IC available, is >to implement non-restoring divide algorithm in FPGA and use >many in parallel. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 4890
If you are using or going to use 68HC16 microcontroller, you may be interested to look at HC16BGND, an advanced programmer’s interface that helps you to develop, test, and refine your assembly language programs for MOTOROLA’s 68HC16 microcontrollers. The key features include: - Run under MS Windows - Interface through PC’s parallel port - Motorola suggested 10 pin target connector - Download and debug HC16 assembly language program in S19 or HEX format - trace through your code by step through or step over - set up to 100 breakpoints - On-screen editing of register and data memory - On-fly assembly of instruction using mnemonics in program memory - Open infinite Register, Program, and Data windows - Watch window so that you can watch important variables - Exchange data through Windows clipboard - File I/O which can be used to automatically read a hex input file into the file and write the result to an output file. - Easy to use. Just click on the menu with left mouse or click on the windows’ area. Everything is self-explained - Convenient and easy to install due to its parallel port interface. You can use laptop to do an on-site demonstration of you products - Low cost - 30 day money back guarantee and one year product warranty For more information or need a demo program, see http://users.why.net/wctech/hc16bgnd.htm, or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, or send email to WCTECH@WHY.NET Larry Chen WC TechnologyArticle: 4891
If you are using or going to use 68HC16 microcontroller, you may be interested to look at HC16BGND, an advanced programmer’s interface that helps you to develop, test, and refine your assembly language programs for MOTOROLA’s 68HC16 microcontrollers. The key features include: - Run under MS Windows - Interface through PC’s parallel port - Motorola suggested 10 pin target connector - Download and debug HC16 assembly language program in S19 or HEX format - trace through your code by step through or step over - set up to 100 breakpoints - On-screen editing of register and data memory - On-fly assembly of instruction using mnemonics in program memory - Open infinite Register, Program, and Data windows - Watch window so that you can watch important variables - Exchange data through Windows clipboard - File I/O which can be used to automatically read a hex input file into the file and write the result to an output file. - Easy to use. Just click on the menu with left mouse or click on the windows’ area. Everything is self-explained - Convenient and easy to install due to its parallel port interface. You can use laptop to do an on-site demonstration of you products - Low cost - 30 day money back guarantee and one year product warranty For more information or need a demo program, see http://users.why.net/wctech/hc16bgnd.htm, or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, or send email to WCTECH@WHY.NET Larry Chen WC TechnologyArticle: 4892
If you are using or going to use 68HC16 microcontroller, you may be interested to look at HC16BGND, an advanced programmer’s interface that helps you to develop, test, and refine your assembly language programs for MOTOROLA’s 68HC16 microcontrollers. The key features include: - Run under MS Windows - Interface through PC’s parallel port - Motorola suggested 10 pin target connector - Download and debug HC16 assembly language program in S19 or HEX format - trace through your code by step through or step over - set up to 100 breakpoints - On-screen editing of register and data memory - On-fly assembly of instruction using mnemonics in program memory - Open infinite Register, Program, and Data windows - Watch window so that you can watch important variables - Exchange data through Windows clipboard - File I/O which can be used to automatically read a hex input file into the file and write the result to an output file. - Easy to use. Just click on the menu with left mouse or click on the windows’ area. Everything is self-explained - Convenient and easy to install due to its parallel port interface. You can use laptop to do an on-site demonstration of you products - Low cost - 30 day money back guarantee and one year product warranty For more information or need a demo program, see http://users.why.net/wctech/hc16bgnd.htm, or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, or send email to WCTECH@WHY.NET Larry Chen WC TechnologyArticle: 4893
APS now sells the XILINX Foundation series software with its FPGA development boards. The kits are ideal for new users wanting to get into XILINX FPGAs. http://www.erols.com/aaps/x84.htmlArticle: 4894
In article <MPG.d2aa8f5b35bf5b9897c1@nntp.aracnet.com>, eteam@aracnet.com (bob elkind) wrote: >Perhaps this begs the issue, perhaps not. Let's pose these >questions: > >Who amongst us (in the listening audience) has *experienced* >an unsatisfactory level of reliability in a >[fuse-programmed | SRAM-based] FPGA ? > >Of these experiences, which are *unresolved* (i.e. not "fixed") >issues ? [Let's not cloud the issues with problems >appropriately attributable to the designer's "learning curve" >in the use of the devices.] > >Are these reliability problems, if identified, attributable >to the FPGA's [SRAM | fuse-programmed] architecture ? > >I *have* experienced unreliability problems in an FPGA design, >but the issues were completely unrelated to SRAM vs. fuse >issues. > >I *expect* that reliability simply has not been an issue in >practice with *either* type of FPGAs, and the reliability >issue is a question primarily in the eyes of designers who >have not yet gained practical experience (mileage) with the >type of FPGA that they are regarding as "suspect". > >Dealing with an issue on a basis of supposition is OK if the >real-world experience is lacking. As a designer, I *prefer* >dealing with issues based on real-world practical experience, >when possible. > >If there *are* real-world experiences of reliability problems >that are fundamental to a given FPGA architecture or technology, >those sorts of issues are proper and interesting subjects for >this newsgroup. > >-- Bob Elkind It's a matter of specification. Perhaps you/ve never done a design where MTBF is specified and calculated to see if this spec is met. As we were discussing here, in safety critical applications (such as commercial flight equipment that *I* designed), the *probability* of failure is what is measured, even if you never have seen such a failure in your life. WayneArticle: 4895
Hi All and Good Doing In 1997
. Is it possible to write C++ program to genetare BitStream file
for Xilinx XC6200 borad. I mean depending on users requirements
that C++ program will genetare Bitstream for FPGA configuring
according the requirements.
Is it possible?
.... Thanks All
Mr. Khalid Alotaibi
Queen's Unvirsity of Belfast
K.Alotaibi@qub.ac.uk
Article: 4896Wayne Turner wrote: > 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.What I said. The cells are deliberately made this way to reduce the probability of upset. > > > 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. The CRC alone obviously will not detect or prevent upsets to a loaded device. It is there to permit you to verify the device got the program you thought you sent. As I've said before, if the function of the device is in a safety critical application, then the design must have additional safeguards to ensure any failure will not cause "loss of life or limb". This would be true whether your design is implemented in an FPGA or in something else. The advantage the SRAM FPGA has over OTP and ASIC solutions is the ability to test the physical hardware (which consists of an array of similar logic cells and an interconnection network) exhaustively. Actual hardware failures can therefore be detected. In the case of the OTP or ASIC, the test vectors may or may not be able to detect any failure of the physical hardware. In both cases, additional logic is usually required to permit monitoring when the circuit is performing its intended function. > > 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. Yes, It does take (in your words) enormously more energy to upset a properly programmed EPROM or antifuse cell. HOwever when that happens, the only recovery is reprogramming the device, which may be impossible while it is in-system! In the case of the SRAM part, the upset can be cleared by reloading the configuration. Obviuosly the configuration logic is already present in the design. > > 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! 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 that may not show up in device test due to poorly designed test vectors or test circuits. My point is that SRAMs are easily reprogrammed when required, are capable of 100% testing, and provide more flexibility for upgrades or repairs than the ASIC and OTP approaches. -Ray Andraka, P.E. (via remote) Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 email:randraka@ids.net http://www.ids.net/~randrakaArticle: 4897
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). > > >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.I think the point here is that if a failure occurs in an SRAM FPGA, it is often possible to correct or work-around the fault by reprogramming. In the case of the ASIC, there are typically no options. This can be advantageous in a system (such as a space probe) where there is no physical access to the system, but an ability to load new programming remotely exists. -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: 4898
I am pretty sure that this can be implemented in an XC3190A or XC3195A. It might be advisable to use a few non-globally clocked FFs to demultiplex the 200 MHz data stream to a more convenient 100 MHz. Or you can go one step further and demultiplex by four and stuff the data into the dual-port RAMs inside XC4000E CLBs. If you really need to store 1024 bits, there are no CPLDs that can do that. Even the biggest have not enough FFs. Send me more design details, and I'll take it as a challenging applications effort.I am quite confident that it can be done without violating the worst-case timing requirements of either XC3100A or XC4000E. But you have to be willing to use some logic tricks. That's what makes design engineering exciting :-). Peter Alfke, Xilinx ApplicationsArticle: 4899
You did not mention whether you can tolerate a pipeline delay. With pipelining, it is obviously much easier to have high throughput rates, and - dare I say - FPGAs are ideally suited for pipelined designs, since they have all these flip-flops... Peter Alfke, Xilinx Applications.
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