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 <8c1n4a$1qh$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote: >This thread is becomming a waste of my time, you very childishly insist >that X and A should give you exactly what you want, with the OS of YOUR First off, I don't. I asked if they did and people told me I didn't want them to, and I rebutted those claims. Other people (i.e. Peter Alfke) were blatantly rude and I unfortunately responded in kind. Some people told me of solutions to different problems and I've thanked them but pointed out that those were not solutions to my problems.Article: 21801
There have been some very interesting milestones regarding Evolvable Hardware here at Xilinx. Evolving on 4KX and Virtex - Despite the claims that EH could only be done on XC6200 devices because that was the only chip that you could download "random" bitstreams to, we have figured out how to do it on 4KX and Virtex type devices using JBits. You can still randomly create circuits on these devices, you just have to be careful about how you randomize the circuit. Instead of doing mutations directly on the bitstream, you do it on the chromosome. By carefully mapping the information on the chromosome to the bitstream you can guarantee that you never run into contention. Parasitic Analog Effects - Adrian Thompson did some ground breaking work to show that you could evolve a bitstream. However, because his mutation changed almost everything, the circuits generated where *highly* asynchronous. By carefully mapping the chromosome to the bitstream so that only synchronous circuits are generated, again by construction, we are able to generate circuits that display none of the parasitic-analog-temperature sensitive effects. Even though the circuit is evolved, it displays all of the characteristics of a standard FPGA circuit, which is what you would expect from synchronous design. 100X Faster Convergence - We have also developed a new evolutionary algorithm that combines Genetic Algorithms and Simulated Annealing to give upto 100X faster convergence over a Genetic Algorithm and upto 10X over Simulated Annealing. If you'd like to get a copy of the paper published at the 1st NASA/DoD Workshop on Evolvable Hardware describing the first two milestones plus some other goodies, send and email to JBits@xilinx.com. The algorithmic improvement is described in a paper submitted to the 2nd NASA/DoD Workshop on Evolvable Hardware. All of this technology is packaged up into a Java API called GeneticFPGA (Virtex only). We will be releasing this toolset in the June 2000 release of JBits. If you are interested in getting the software send email to JBits@xilinx.com. Patents Pending. Delon Levi XilinxArticle: 21802
Does anybody know how much does an FPGA chip price vary with the size -i.e. number of CLBs- (within the same series)? Is there an approximate dependence say Linearly? Cheers. PS. As you probably have already noticed, I am particularely intereseted in Xilinx devices (XC4000 and Virtex).Article: 21803
Hi! Thanks for the responses!!! I'm using a state machine to differentiate & ctrl between read & write to RAM. & use async for data output. The code is much neat as there are much less flag lying ard :-) Rgds MK Jonas Rangell <jonas.rangell@emw.ericsson.se> wrote in message news:38E354CC.2A035D69@emw.ericsson.se... > MK Yap wrote: > > > > > > [snip] > > > I have been struggling with this for quite some time. Is there a good way > > for coding bidirection signals so that there is no logic contention? When to > > drive the signal & when to tristate it? > > > > ELSIF (MClk'event AND MClk='0') THEN > > RdDone <= '0'; > > WrtHold <= '0'; > > RAM_Data <= (OTHERS=>'Z'); --- (1) > > > You have Z-assignments inside a clocked process. > That is not good. These should be placed in an > asyncronus process. > > Create a clocked process, containing the data to RAM > and one asyncronus process which will do the data output, > and handling the tristate. > > > > Something like this.... > > > Process(cp) -- Clocked Output to port > Begin > if rising_edge(cp) then > data_int <= data_to_RAM; > end if; > End Process; > > Process(data_int, direction_to_RAM) -- Tristate control > Begin > If direction_to_RAM = '1' Then > data_iob <= data_int; > Else > data_iob <= 'Z'; > End If; > End Process; > > Process(data_iob) -- Read data from port > Begin > data_in <= data_iob; > End Process; > > process(cp) -- return zero during write, else RAM data > begin > if rising_edge(cp) then > if direction_to_RAM='1' then > data_from_RAM<='0'; > else > data_from_RAM<=data_in; > end if; > end if; > end process; > > > > > Well, I have not really checked the code but it looks OK. > Hope it helps > > > /JonasArticle: 21804
Dave Vanden Bout wrote: > > Rickman wrote: > > > I am not at all familiar with the work of Adrian Thompson or much > > familiar with Hardware Evolution, but why can't you do the same thing in > > a simulation rather than to have to work directly with a bitstream and > > load a part for test? > > > > EDIF files can be "randomly" connected and simulated to test the > > functionality. Your software may crash once in awhile, but it is > > unlikely to fry the computer. > > > > Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population. Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge. These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked. > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || I don't know that I have read about Thompson's work in particular, but I do remember reading about some efforts in genetic programming. The circuit produced did what it was required, but produced some glitches in the output and as you say, it used circuitry in very unusual ways. The end result was that the circuit was not stable over normal variations such as temp, voltage and process. So in the end depending on "unique" design features and parasitic effects was a very bad thing. Maybe if the simulators had been used, then the circuit produced would have been more stable. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21805
For a mature, high-yielding product family, the die cost is essentially proportional to die area. Therefore, the price will, to the first approximation, be proportional to area, i.e. number of CLBs. But don't forget the BlockRAM on the newer parts. One 4k-bit BlockRAM occupies the area of six CLBs in Virtex-E. There are two important additional modifiers: At the low end, the relatively higher package cost often results in a disproportionally higher price. At the high end, especially with a young family, the lower yield of the biggest chips ( suffering most from the defect density on the wafer) makes them overproportionally expensive. So you will see a linear line with an upward excursion both at the low end and at the high end. But there may always be special marketing considerations that require a deviation from this simple model. These are no Xilinx secrets, every chip manufacturer faces the same issues. Peter Alfke =================================== "J.R." wrote: > Does anybody know how much does an FPGA chip price vary with the size -i.e. > number of CLBs- (within the same series)? > Is there an approximate dependence say Linearly? > > Cheers. > > PS. As you probably have already noticed, I am particularely intereseted in > Xilinx devices (XC4000 and Virtex).Article: 21806
Zoltan Kocsi <root@127.0.0.1> wrote in message news:m3snxb25wd.fsf@tade.bendor.com.au... > Ray Andraka <randraka@ids.net> writes: > > > Rickman wrote: > > > > > But I think my point is still valid. I doubt that anyone would expect > > > Xilinx to provide such support. It would be a far reach of the mind for > > > a user to expect anyone to support the operation of tools that they did > > > not provide. Again, the analogy would be like asking Intel to support > > > the GNU tools. > > > > > > > Not really, there's a fundamental difference. When you buy an intel processor, you > > know exactly what it's function is and you know the chip works. With an FPGA, you > > have a hardware design in there too, which from what I have seen is more often than > > not a poor fit to the FPGA. That invariably generates the "you say the chips run at > > XX MHz, but I can't get my design to run even at XX/10 or 20" calls. > > When I buy a microcontroller, its function is not determined. It can be > turned to a washing machine controller or a television remote control > or a talking Barbie doll or a pocket calculator or whatever. It depends > on the exact bit pattern stored in its program memory. Very much like > an FPGA chip, which can be turned into all sorts of things by varying > the bit pattern in its program memory. I was reading through the Xilinx documentation last night, and they make the comment that the bitstream format "is a closely guarded secret". The only reason mentioned for this is to make it harder for people to copy your bitstream and get away with it. They suggest copyrighting your bitstream (and putting a notice of this on the silkscreen on the board) so that if you find a competitor is using the same FPGA in a similar way, and with a logic analyzer you find him using the same bitstream, you can sue his butt off. If Xilinx published the bitstream format, it would be pretty easy for the competitor to swap some pins around (for example, rotate the design 180 degrees, or swap every third pin pair) and maybe invert a signal or two, in an attempt to get around the copyright claim. At a glance, the bitstream would not appear to be a copy and one might not suspect a theft had taken place. The Xilinx docs don't say it, but on smaller parts it would be very straightforward to take knowledge of the config bits and produce a schematic. On larger parts, I imagine that a skilled FPGA designer who has designed similar parts would be able to reverse-engineer, for example, a three port PCI bridge design to see how the designer has managed to save a couple of clock cycles. Parts with wide data paths and relatively small control sections would be the easiest to figure out, I reckon. So now that I've looked into it, I don't have such a problem with Xilinx keeping the bitstream format confidential, and it's good to see that they have a logical reason for it (I never believed that it had to do with product support calls, to be quite honest, no offense to the guy from Xilinx). In the same section they talk about an interesting security technique -- load the bitstream during manufacturing, and use a little lithium battery to keep the configuration loaded when power is off. This would make reverse-engineering the chip nearly impossible (cheaper to hire thugs to break into the competitor and take the design at gunpoint, in fact). Have any of you tried this battery backup technique? -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21807
This is a multi-part message in MIME format. --------------DA6EFAEDCB6E798B82EB9C20 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population. Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge. These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked. > > > > -- > > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || > > I don't know that I have read about Thompson's work in particular, but I > do remember reading about some efforts in genetic programming. The > circuit produced did what it was required, but produced some glitches in > the output and as you say, it used circuitry in very unusual ways. The > end result was that the circuit was not stable over normal variations > such as temp, voltage and process. So in the end depending on "unique" > design features and parasitic effects was a very bad thing. Maybe if the > simulators had been used, then the circuit produced would have been more > stable. I agree, but that's not the point. The original poster explicitly said they wanted to duplicate Thompson's experiment. I was pointing out why using a simulator would not work for that purpose. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || --------------DA6EFAEDCB6E798B82EB9C20 Content-Type: text/x-vcard; charset=us-ascii; name="devb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave Vanden Bout Content-Disposition: attachment; filename="devb.vcf" begin:vcard n:Vanden Bout;Dave tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;-16464 fn:Dave Vanden Bout end:vcard --------------DA6EFAEDCB6E798B82EB9C20--Article: 21808
galexand@sietch.bloomington.in.us (Greg Alexander) writes: > First off, I don't. I asked if they did and people told me I didn't want > them to, and I rebutted those claims. Other people (i.e. Peter Alfke) were > blatantly rude and I unfortunately responded in kind. Some people told me > of solutions to different problems and I've thanked them but pointed out > that those were not solutions to my problems. I think that was quite a nice summary of the thread. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 21809
"Gary Watson" <gary@nexsan.sex> writes: > They suggest copyrighting your bitstream > (and putting a notice of this on the silkscreen on the board) Can you do that ? I mean copyright an arbitrary sequence of bits, with all the DMCA protection, 70 years after author's death and all ? What is the minimum length ? Thanks, Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 21810
Dave Vanden Bout wrote: > > > > Thompson's results were heavily dependent upon parasitic effects in the FPGA chip that affected the selection of fit individuals in the population. Software simulations could be used in the genetic algorithm feedback loop, but a lot of the interesting circuits evolved during Thompson's experiments would never emerge. These evolved circuits often used LUTs and routing resources in ways that any logic or timing simulator (or human) would consider completely whacked. > > > > > > -- > > > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > > > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > > > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || > > > > I don't know that I have read about Thompson's work in particular, but I > > do remember reading about some efforts in genetic programming. The > > circuit produced did what it was required, but produced some glitches in > > the output and as you say, it used circuitry in very unusual ways. The > > end result was that the circuit was not stable over normal variations > > such as temp, voltage and process. So in the end depending on "unique" > > design features and parasitic effects was a very bad thing. Maybe if the > > simulators had been used, then the circuit produced would have been more > > stable. > > I agree, but that's not the point. The original poster explicitly said they wanted to duplicate Thompson's experiment. I was pointing out why using a simulator would not work for that purpose. > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || I understand what the poster was asking. I am asking why anyone would want to design circuits that can not be used in applications due to their extreme sensitivity to uncontrolled parameters. So what is the value of research that is finding better ways to design lousey circuits? Is there some reason that this type of circuit is good? Or are they just a stepping stone to being able to design good circuits? If so, I would think that they would want to consider finding techniques to directly design good circuits. One thought; if you are using evolution in the literal sense, then couldn't you do your conditioning (testing) in an environment that varies voltage, temperature and process? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21811
Gary Watson wrote: > So now that I've looked into it, I don't have such a problem with Xilinx > keeping the bitstream format confidential, and it's good to see that they > have a logical reason for it (I never believed that it had to do with > product support calls, to be quite honest, no offense to the guy from > Xilinx). > > In the same section they talk about an interesting security technique -- > load the bitstream during manufacturing, and use a little lithium battery to > keep the configuration loaded when power is off. This would make > reverse-engineering the chip nearly impossible (cheaper to hire thugs to > break into the competitor and take the design at gunpoint, in fact). Have > any of you tried this battery backup technique? Gary, what you read has been in the Xilinx data book for more than five years, and I wrote it. I always assumed that people would read our data book ( it has an index !), so I elaborated here on the secondary aspect. And yes, games and set-top box designs have used the battery method. It was a bit easier with the older and smaller parts, like XC3000L that had very low Powerdown current, but that has now also come back with the SpartanXL. Hope this thread is over, soon. Greetings Peter Alfke ( "the guy from Xilinx")Article: 21812
Yup, it works. Most commercial customers find it unacceptable however, as the product is then life limited to the shelf life of the battery. Gary Watson wrote: > In the same section they talk about an interesting security technique -- > load the bitstream during manufacturing, and use a little lithium battery to > keep the configuration loaded when power is off. This would make > reverse-engineering the chip nearly impossible (cheaper to hire thugs to > break into the competitor and take the design at gunpoint, in fact). Have > any of you tried this battery backup technique? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21813
Peter Alfke <palfke@earthlink.net> wrote in message news:38E627A1.39526DF4@earthlink.net... > > Gary Watson wrote: > > > So now that I've looked into it, I don't have such a problem with Xilinx > > keeping the bitstream format confidential, and it's good to see that they > > have a logical reason for it (I never believed that it had to do with > > product support calls, to be quite honest, no offense to the guy from > > Xilinx). > > > > In the same section they talk about an interesting security technique -- > > load the bitstream during manufacturing, and use a little lithium battery to > > keep the configuration loaded when power is off. This would make > > reverse-engineering the chip nearly impossible (cheaper to hire thugs to > > break into the competitor and take the design at gunpoint, in fact). Have > > any of you tried this battery backup technique? > > Gary, what you read has been in the Xilinx data book for more than five years, > and I wrote it. > I always assumed that people would read our data book ( it has an index !), so > I elaborated here on the secondary aspect. Did you get the impression from the postings to this thread that everybody had read this part of the data book? Didn't seem that way to me. Besides, I've been boycotting you guys for 12 years so I haven't read the docs in the interim. The boycott ended two weeks ago, and I'm working on a couple of new FPGA designs, one based on the 4000 series, and the other will be a mid-range Virtex-E most likely. Personally, I haven't the slightest interest in the bitstream format and as I say, it makes sense that it is proprietary. As a matter of fact, you ought to consider some kind of OTP key for an embedded cipher, so that our bitstreams will not work unless the key is programmed into the chip. A less-attractive alternative would be an embedded serial number which forms a key. -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21814
Ha ha, April Fool! ((Greetings to Peter Alfke!)) -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21815
I'm using the of the Xilinx Foundation student edition 1.5 and I can't seem to complete the first example in "The Practical Xilinx Designer Lab Book" (tripg_40). I have entered the design using schematic entry. I have assigned the I/O pins using the .UCF file. The target device is an 4005XLPC84. The program hangs during implemenation. Specifically during the Contructive Placer section of Place&Route. Lastly, I am using Windows 98. Using Deja.com, I have seen that the mapper hangs under NT, but the fixes from the Xilinx site are NT specific. My searches of the Xilinx support site seem to match just about EVERY document or none of them. Any help would be greatly appreciated. GregArticle: 21816
Take a lookm at the APS-X208 board. The ISA BUS board has a socketed 208 pin QFP which will take FPGAs from a 4005 upto a 4085XLA. The board supports 5v or 3.3v FPGAs, has SRAM sockets and full windows support code. It also has a 96 pin VME type connector out the back side of the PC. You can see the board and several others like it at : http://www.apsfpga.com Gary Watson wrote: > I'm looking for a Xilinx (will settle for Altera) demo board which plugs > into a ISA or PCI slot, but where all the remaining I/O pins are brought out > to a connector leading outside the PC chassis. The board would only need > the one chip on it, I figure, with the PC bus hooked up directly to the > FPGA. Don't think I need any RAM or other glue logic. > > If I can't find one, I'm going to make one myself. Anybody else want one? > I was going to use a part in the 20,000 to 40,000 gate region, like the 4000 > series. I'll probably include A/D inputs on all external pins since this > would improve it for my intended project. > > My purpose is twofold: (a) to learn how to use the Xilinx FPGA software, and > (b) to use this gizmo to test SCSI backplane electronics including Low > Voltage Differential terminators. (Parenthetical quesiton -- does anybody > know of the LVDS I/O pads in the Xilinx are close enough to the SCSI LVD > specification for crude testing purposes? SCSI uses an asymmetric variant > of LVDS.) > > -- > > Gary Watson > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > Nexsan Technologies Ltd. > Derby DE21 7BF ENGLAND > http://www.nexsan.comArticle: 21817
If I use the ViewSim setmap command to define an additional logic state
("setmap wh=p" so I can define external pullups), Vwaves will only display
the simulation in bus format, not as waveforms. I can make ViewTrace
display waveforms by a simple edit to the viewtrac.cfg file, but I can't
seem to find any way of getting Vwaves to do it.
Anyone know how?
--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk
Article: 21818On Sat, 1 Apr 2000 13:11:55, Zoltan Kocsi <root@127.0.0.1> wrote: > "Gary Watson" <gary@nexsan.sex> writes: > > > They suggest copyrighting your bitstream > > (and putting a notice of this on the silkscreen on the board) > > Can you do that ? I mean copyright an arbitrary sequence of bits, > with all the DMCA protection, 70 years after author's death and all ? > What is the minimum length ? Sure. The fact that you've created "art" means it's copyrighted. You can *register* a copyright and in fact you must if you wish to sue. Certainly the bitstream fed into an FPGA is no different than a microcode ROM in an embedded controller. Copyright laws certainly protect aginst such theft, if you catch the perp before they've ruined your business, have tons of money to prosecute, and hope that they have some assets to go after. Chances are that you won't find a perp stupid enough to fit all three catagories. ---- KeithArticle: 21819
I worked with an 82C54 Verilog design during a previous job. The design had been outsourced prior to me hiring on. Unfortunately, I do not have the orginal code still available, but I do have this advice: Look at costs prior to pursuing this implementaiton. We found that the FPGA implementation cost of the 82C54 was significantly higher than just buying a ~$2.00 part and placing it externally. We abandoned the development for the lower cost external hardware. Marc ------------- Tomasz Brychcy wrote: > > Hello, > > I am writing a synthesisable model of 82C54 (Intel) and I have many > questions to the circuit. Intel do not want to reply for these questions > because the circuit is not supported now for Intel. > > If somebody could help me please about reply > > I will be very thankfull; > > Tomek > > tbrychcy@sensor.ime.pz.zgora.plArticle: 21820
Does anyone know pointers for research papers/research efforts proposed for integrating conventional RISC/CISC Processors with Reconfigurable logic. --AnuragArticle: 21821
fulvs@my-deja.com wrote: > > I'm trying to understand the difference between > antifuse, SRAM and flash based FPGAs. I have 3 > questions and any comments on any of these would > be much appreciated. > > 1) Antifuse is purportedly cheaper, lower power, > higher performance. Why is this? If this is true > - how much cheaper, lower power etc? > > 2) Other than military/aerospace, what > applications are antifuse FPGAs used for? Aren't > SRAM FPGAs much better because they're many times > reprogrammable? > > 3) Who is the best antifuse vendor? > > Thanks in advance for your help. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Any FPGA must have a programmable way to connect between two wires. In every FPGA there is a very large number of these programmable connections. Antifuse devices create a physical connection by blowing a hole through a thin insulating layer between two metal layers; SRAM- and Flash-based devices use a transistor controlled by a memory bit. * Size, speed and power-consumption - see data-sheets. Every day someone releases a newer, faster, better chip. Usually the SRAM-based devices lead the size race; speed and power are very dependent on your specific design and tools. * Antifuse devices can be only programmed once; Flash devices can be usually programmed about 100 times and SRAM devices can be "programmed" (actually loaded) any number of times. * Antifuse device, AFAIK, can't be programmed on-board; this is a major manufacturing headache, especially with PQFP packages. Updating/correcting an antifuse device requires desoldering it and than soldering another chip - VERY hairy. * SRAM devices require a separate, pretty expensive, ROM chip to hold their configuration; if your system has a processor, it may be possible to let the processor program the FPGA. Of course, if the FPGA is required for system operation (e.g. memory controller or Chip-Select decoder), you have a classic egg-and-chicken problem. * Flash devices can usually be programmed on-board, by adding a small connector (usually 8-20 pins) for an external serial programmer. * Design security: antifuse devices are supposedly hardest to read-back; flash devices usually have a security bit which makes reading them harder; SRAM-based devices are pretty easy to copy - the data-stream is out there for anyone to see. In summary: I think that flash-based devices offer the best combination of programmability, security and simple, cheap board design. If your design will fit into a flash-based device (and they are not very common, cheap or large), use a flash-based FPGA. Regards Assaf SarfatiArticle: 21822
On Thu, 30 Mar 2000 16:49:46 GMT, Tim Tyler <tt@cryogen.com> wrote: >Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote: > >: And don't worry, due to the secret nature of the Xilinx bitstreams, I >: have no practical way of working out what your design does. > >Uploading it to a Virtex chip - and then treating its pins as the outputs >from a black box - could give you a practical method of determining the >function ;-) I was just about to flame this when I saw the ;-) that I'd missed earlier. I had been very careful to say that it was not practical, rather than impossible. So far only Ray Andraka has been kind enough to send anything. Come on guys, I'm sure several of you have Virtex files just sitting around, blocking the view of the TV. Send them to me! Please. Allan.Article: 21823
A I can see, I'm not the only one looking for such informations. More seriously, is there any sram based for which these infos are available ? Gary Watson wrote: > > Ha ha, April Fool! > > ((Greetings to Peter Alfke!)) > > -- > > Gary Watson > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > Nexsan Technologies Ltd. > Derby DE21 7BF ENGLAND > http://www.nexsan.comArticle: 21824
may be my page helps you http://www.geocities.com/SiliconValley/Pines/6639/fpga for more information feel free to ask Jamil Khatib OpenIP Organization Anurag Tiwari wrote: > Does anyone know pointers for research papers/research efforts proposed > for integrating conventional RISC/CISC Processors with Reconfigurable > logic. > > --Anurag
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