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
Leon Heller wrote in message <8bvg75$j9i$1@nnrp1.deja.com>... >Anshuman Sharma <gte600f@prism.gatech.edu> wrote: >> ... I want help with the VGA display. Basically if anyone can help me >find >> something on how I can build a VGA module that will interact with my >> datapath and the game as a whole. > >The XSOC FPGA CPU has a VGA display. You'll find details here: >www.fpgacpu.org/xsoc Thanks. First let me recommend this VGA app note by Dave Vanden Bout of XESS: www.xess.com/vga.pdf. The XSOC system-on-a-chip, including the VGA display, is described in the forthcoming May 2000 (issue #118) issue of Circuit Cellar, and the schematics (and shortly, the Verilog version) are available as part of the XSOC distribution at www.fpgacpu.org/xsoc Here is a brief description of the design of the XSOC video display controller, which produces a VGA-timing compatible bilevel 576x455 display using the XESS XS40's 32 KB of SRAM. A video signal is a series of frames, each frame a series of lines, each line a series of pixels. The video controller is responsible for fetching the video data, shifting it out (serializing it), and for asserting the horizontal and vertical sync pulses that frame the pixel stream into lines and fields. A video address counter is required to fetch each word of video data. Often the video controller shares memory with another agent (such as a processor) that writes the video data, and this usually requires an address multiplexer to select either the video address or the writing agent address. A horizontal pixel counter and vertical line counter are required to generate horizontal and vertical blanking and syncs. Each counter need four equality comparators, to determine when the counter reaches 1) start of blanking, 2) start of sync, 3) end of sync, and 4) end of line/frame. After first considering a software (interrupt handler) approach to fetching video data and generating syncs, I settled on a simple, fast, low cost, hardware approach. 1. The video address counter and the address mux are subsumed by one channel of the DMA engine in the xr16 processor core. This engine costs only 20 LUTs and 3 flip-flops. 2. The horizontal and vertical counters are 10-bit LFSR counters that use only 1-2 LUTs and 10 FFs each. (The lfsr counter design program is also provided in the LFSR distribution.) 3. The 8 comparators are 10-bit AND trees (3 LUTs each). 4. A video word DMA staging buffer, and a parallel-in serial-out pixel shift register, use a further 16 FFs and 16 LUTs+16 FFs respectively. 5. There are a further 6 LUTs and 5 FFs of control logic. Total cost, including the CPU DMA engine, is about (20 LUT, 3 FF) + 2*(2,10) + 8*(3,0) + (0,16) + (16/16) + (6,5) = (70 LUT, 60 FF) = ~35 XC4000E CLBs. But note, as described in issue #6 in http://www.fpgacpu.org/xsoc/issues.html, the design currently has a defect that causes premature blanking of the last word on each line, that we will fix one of these days. Jan Gray Gray Research LLCArticle: 21751
You may get different answers from different people, and definitely from different companies. But since there is hardly anybody else here representing the vendors, and since Xilinx at one time designed and even made antifuse devices, here is my answer: Antifuse devices use higher programming voltages and additional processing steps, which means they cannot migrate to the smallest and fastest technologies as fast as SRAM-based FPGAs can. That means anti-fuse devices really are not smaller, faster, and cheaper. Programming takes a long time ( and is rarely done by the end-user ). One-time programmability can be painful and expensive with large chips. Max chip capacity is a small fraction of what you can get in SRAM-based FPGAs. Remaining advantages: Instant-on, single-chip, and a certain degree of radiation-resistance. There are only two manufacturers: Actel ( the larger and older one ), and Quicklogic (the younger and smaller one ). I think this was a reasonably unbiased and fair explanation. Let the flames start! Peter Alfke 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.Article: 21752
HH wrote: > Hi, > > I recommend you to visit http://www.optimagic.com/ . It has a lot of > device-independent information... > I'm not an expert, but I'll try to answer you... > > > The resistance of a "shorted" gate is much lower that when a S-RAM cell is > used, thus less power. Not true: The ( lower ) series resistance of an antifuse compared to the (higher) resistance of a pass transistor has absolutely nothing to do with power consumption. But does affect speed. When you charge and discharge a capacitor, the series resistance of your switch falls out of the power equation: P = f • C • V • V Look, no R! Peter AlfkeArticle: 21753
Best bet would be to use an external deserializer and then present the data in parallel. For example, SMPTE-292M HDTV is 1.4 something Gbits/sec. AMCC has a deserializer for that application that includes a PLL which outputs the data as an unframed 20 bit parallel word. My framer/descrambler macro takes that data, descrambles it and frames it (shifts it to align properly within the 20 parallel bits) in a Xilinx 4K or Spartan part. The macro is working at 75 MHz, which is quite possible with the FPGA. Some of the newer FPGAs will handle a 622 Mbit/sec stream on LVDS I/O, but only if you are really careful about the design inside the FPGA. You won't get much beyond that with a serial stream in an FPGA without first deserializing it outside. Anoop Nannra wrote: > Hi all, > > Anyone out there know of any references, texts or otherwise, that may give > me an idea on how to take in a 10gbit/s serial data stream into an fpga or > an array of fpga's ? Also, any ideas on what I should be looking for in and > fpga to be able to accept that kind of input ? > > TIA > Anoop -- -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: 21754
Greg, I like to think that I know more than the average bear about how to make things work, and work well within an FPGA. Guess what, I don't go down to the bitstream level! I do however use the tools provided, including the floorplanner and the chip editor to learn about the chip. True, these are abstractions, but they are also close enough to the actual hardware to understand everything you need to know to take advantage of all the FPGA has to offer. I maintain that if you want to learn about the FPGA, start with what is accessible with the tools and if then if they don't meet your needs push down lower where you need to. If you learn how to design to the architecture you will be far ahead of the pack, and I think if you do it within the supplied framework, you'll get there a heckuva lot sooner than if you start at the bitstream level. Greg Alexander wrote: > As easily as you dismiss my approach to learning, people who have been > through my approach to learning completely dismiss anything learned your > way as being inadequate and cloudy. *shrug* Bias can go both ways and it > doesn't make either side right -- but if there are two sides you shouldn't > be so sure yours is the only way. I maintain that you don't know anything > if you don't know how it works -- you can't learn how FPGAs in general > work if you don't look in depth at at least one example and looking in > edpth at the Vertex chip won't make you any stupider when you see the > foobar chip -- if anything, it'll make you smarter because you'll see the > historical basis for decisions and you'll see neat innovations rather than > just an entirely new system. If you'll never learn ANY of the chips then > I continue to maintain that you know plenty to get most jobs done, but not > enough for extreme excellence, which is sometimes demanded. -- -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: 21755
Oops, sent it before I finished typing. Anyway, Greg, I heartily applaud your enthusiasm, but I think it is slightly misdirected, at least for where you are on the learning curve right now. Greg Alexander wrote: > In article <8bv4us$7st$1@nnrp1.deja.com>, rob_dickinson@my-deja.com wrote: > >In article <8btl68$kjh$1@jetsam.uits.indiana.edu>, > >galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > >> In article <8bt2io$rnp$1@nnrp1.deja.com>, rob_dickinson@my-deja.com > >wrote: > >> >Having read most of this thread I have the following global comments. > >> > > >> >1)If you just want to play then surely you can understand that > >company > >> >A or X have better things to do than to be bothered with even a few > >> >hundred people going "your" route. > >> > >> Total disagreement. As I've said before, most people competent in the > >> field learned most of what they knew going in just playing around. The > >> more hobbyists playing with it today the more companies buying hte > >things > >> tomorrow. I think Linux's commercial success proves that -- I don't > >think > >> managers picked it because htey liked it, I think managers picked it > >> because their employees said "I know and like Linux, it'll do the job > >and > >> if it doesn't we'll make it." > > > > > >Greg > >I'm about to disapoint you. > >FPGA's are inevitably designed by many people in such a manner that > >they can be maintained by other people over many years and probably > >ported easily to newer devices. The ability to "hack" at or near the > >bitstream level will not impress many people and I can assure you that > >decisions to invest 10,000 (say) man hours because "Greg played with > >bitstreams at home" will not cut it at all. If it was "Greg is bloody > >good at VHDL simulation using VITAL and does the job in half the time" > >then you probably will still not influence the decision making but you > >will get paid more than the next guy. > >Yes one guy can probably write good code for FPGA's on his own, doing > >it some strange weird way because X let him do it at the bitstream > >level, but you might go under a bus and you will almost definitely > >change companies during the lifetime of the #CODE#. You are therefore > >only usefull to a company if you are competent with the tools which the > >next guy can use. > >The more hobyists using VHDL (which is free from the right places) the > >better, the more people coming through degrees who still know what a > >counter or state machine is at the gate level, even better. A thorough > >knowledge of the routing architecture at any level is almost useless, > >Vertex will be almost completely superceeded in a frighteningly short > >time and no-one will give diddly squat that you know it litterally > >inside out. > > As easily as you dismiss my approach to learning, people who have been > through my approach to learning completely dismiss anything learned your > way as being inadequate and cloudy. *shrug* Bias can go both ways and it > doesn't make either side right -- but if there are two sides you shouldn't > be so sure yours is the only way. I maintain that you don't know anything > if you don't know how it works -- you can't learn how FPGAs in general > work if you don't look in depth at at least one example and looking in > edpth at the Vertex chip won't make you any stupider when you see the > foobar chip -- if anything, it'll make you smarter because you'll see the > historical basis for decisions and you'll see neat innovations rather than > just an entirely new system. If you'll never learn ANY of the chips then > I continue to maintain that you know plenty to get most jobs done, but not > enough for extreme excellence, which is sometimes demanded. -- -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: 21756
Peter, It would have been nice to have a faster global or high fanout distribution for non-clock signals (like clock enables) on the Virtex part. The existing 'secondary clock distribution' is next to useless for system clocks as low as 130 MHz, unless there is some trick I missed. Seems the fastest distributions you can get on these in a -4 part is about 9-10ns. Peter Alfke wrote: > No, there is no published research paper. > The decisions depend on the priorities seen at the time of family > inception: > > Generality is obviously nice, but burdens the clock tree with a lot of > extra capacitance, whether the destinations are activated or not. > > Single-mindedness reduces capacitive loading, and thus clock delay and > clock skew, which are important parameters at clock rates > 200 MHz. Also, > the improved quality of the additional interconnect allows us to restrict > the global clock lines to their original purpose. > > Clock distribution quality has a higher importance today than it had years > ago, especially since the DLL can effectively eliminate the clock delay. > Clock skew thus takes on a new significance, and clock skew is drastically > improved by using the global nets as clocks only. > > Hope this is convincing. > > Peter Alfke, Xilinx Applications > > Tim wrote: > > > As I recall the sequence was > > > > XC2000 - (I have forgotten) > > XC3000 - only drive clocks > > XC4000 - drive anything > > Virtex - only drive clocks > > > > Is there a paper on the research behind this? > > > > > Peter Alfke wrote: > > > > > > > It depends on the Xilinx family: > > > > > > > > In XC4000 and all its derivatives ( incl. Spartan and SpartanXL) you > > can > > > > use the global nets for anything you might want. > > > > > > > > In Virtex and its derivatives ( incl. Spartan-II) you can use the > > global > > > > clock nets *ONLY* as clocks. -- -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: 21757
If you want to initialize the rams (upon configuration only) with something other than zeros you'll have to instantiate the primitives rather than infer the RAM. The primitives have generics on them for the initial values (xilinx), which default to 0. David Kessner wrote: > > What Altera and Xilinx have done, however, is provide a way to > initialize the contents of RAM to any arbitrary value during the > normal FPGA programming process. In other words, the initial > contents of all RAM is included in the programming bitstream. > This allows the RAM to be initialized to a specific value and > used as a ROM (or something else). > > Unfortunately, I have no experience initializing RAM like that-- > other than I know that it can be done and have seen it done. I'll > have to learn how to soon, however, since it's recently come up > on a new core design... > > Hope that helps! > > David Kessner > davidk@free-ip.com http://www.free-ip.com/ -- -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: 21758
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? > A little lower on power, but it isn't as much as you might think. The majority of power consumption in an FPGA is the dynamic power due to nodes switching. Since the configuration registers in an SRAM FPGA are usually static once the device is configured, they contribute very little to the overall power. BTW, SRAM based FPGAs is an unfortunate selection of terms. The configuration is held in registers more akin to D flip-flops than to SRAM memory cells, and slow registers at that. What that means is the memory is more robust than one usually expects for SRAM. The performance claim is also questionable, but that goes more with the architecture than the technology. The antifuse arrays available don't have fast carry chains, so in arithmetic applications it is a little harder to keep up wiht the SRAM devices that have them. > > 2) Other than military/aerospace, what > applications are antifuse FPGAs used for? Aren't > SRAM FPGAs much better because they're many times > reprogrammable? > Depends on the application. You need off chip storage for the bitstream for the SRAM devices, plus some time on system initialization to load the bitstream. The antifuse devices don't need that and aren't brain-dead when the power comes on. > > 3) Who is the best antifuse vendor? > Depends on what the definition of best is :-). > > Thanks in advance for your help. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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: 21759
HH wrote: > I only know Actel (... but that does not make it the best ;-) > Quicklogic is also antifuse. -- -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: 21760
Anybody who is familiar with Adrian Thompson and his work with Hardware
Evolution can help. I am trying to duplicate the experiment that he did
using the Xilinx XC6216, but my problem is that Xilinx and discontinued
that particular series. I know I am not the first one to try and do that,
so if anyone has done it or know about it being done should be able to
help.
What I want to know is how can I duplicate it without using the
XC6216. That particular series had a very simple floorplan and it was a
research purposes-only version. If I have to use another chip then it is
very hard to just download random bit patterns on to a cell area without
frying the board, moreso, if you use the software provided by the regular
vendors, then it doesn't even let you do it. Is there another board that I
can use for the same, or is there another software that I can use to do
the same? Any help with this would be really appreciated.
thanks,
Anshuman
--
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live." |
|
~~Einstein |
---------------------------------------------------
Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
anshu@abraxis.com
Article: 21761In article <38E3B6BD.9858EFD1@ids.net>, Ray Andraka wrote: >Greg, > >I like to think that I know more than the average bear about how to make >things work, and work well within an FPGA. Guess what, I don't go down to >the bitstream level! I do however use the tools provided, including the Of course nobody goes down to the bitstream level, but they should understand it down to the XDL level. I only want bitstream because XDL -> bitstream is comparatively trivial and they are obviously not going to let me use their XDL software unless I run Windows or SunOS or HP-UX. I vaguely suspect that they don't support Solaris x86 but that's just a guess. >floorplanner and the chip editor to learn about the chip. True, these are >abstractions, but they are also close enough to the actual hardware to >understand everything you need to know to take advantage of all the FPGA has >to offer. I maintain that if you want to learn about the FPGA, start with >what is accessible with the tools and if then if they don't meet your needs The tools themselves aren't accessible! I'm not going to be running whatever OS some random company too dull to notice "oh yeah, that open source bandwagon!" tells me to. You think they should only write for one platform? Sure, why not. The only decent bash implementation is for Unix and I'm unwilling to give that up. So you're saying I have to chose between bash and Xilinx' tools. Or do you really expect me to shell out the ~$400 for a machine capable of barely running Win95 just so I can use Xilinx' tools? Or the ~$3000 for a commercial Unix workstation to run both? I'm using a 2 year old computer with a market value of probably $400 as my main workstation and I have been doing so for years -- if anyone thinks I'm going to break something that works just to develop FPGAs in a frustrating environment that I KNOW AHEAD OF TIME WILL FRUSTRATE ME (unavoidable with Windows software -- when there is Windows software and some homegrown Unix program competing the homegrown Unix program always wins: TeX vs. FrameMaker, vi vs. Notepad, bash vs. Windows Explorer -- by not opening themselves up to more potential chip development environments they're just removing the Unix hacked equivalent as competition, they're not actually winning against it...even if I don't write it). >push down lower where you need to. If you learn how to design to the >architecture you will be far ahead of the pack, and I think if you do it >within the supplied framework, you'll get there a heckuva lot sooner than if >you start at the bitstream level. I agree with your idea -- if those tools were as accessible for me as they are for you I wouldn't hesitate to go that route, /I'd even pay the $100/. They've made a mistake by targetting platforms I can't use. They've made a further mistake by not allowing me to target whatever platform I want. The former mistake is unavoidable -- you can't support everything. The second mistake is pure corporate dumbheadedness. From the "I have all these secrets" side of the fence, the grass looks brown on the other side, but once you get there -- once you share -- you find out that it's great. You may think that we on the other side of the fence are confused, but no amount of paradigm shifting will allow me to use their software in a satisfactory manner. >Greg Alexander wrote: > >> As easily as you dismiss my approach to learning, people who have been >> through my approach to learning completely dismiss anything learned your >> way as being inadequate and cloudy. *shrug* Bias can go both ways and it >> doesn't make either side right -- but if there are two sides you shouldn't >> be so sure yours is the only way. I maintain that you don't know anything >> if you don't know how it works -- you can't learn how FPGAs in general >> work if you don't look in depth at at least one example and looking in >> edpth at the Vertex chip won't make you any stupider when you see the >> foobar chip -- if anything, it'll make you smarter because you'll see the >> historical basis for decisions and you'll see neat innovations rather than >> just an entirely new system. If you'll never learn ANY of the chips then >> I continue to maintain that you know plenty to get most jobs done, but not >> enough for extreme excellence, which is sometimes demanded. > >-- >-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/~randraka > >Article: 21762
In article <38E3B738.FAF783F5@ids.net>, Ray Andraka wrote: >Oops, sent it before I finished typing. Anyway, Greg, I heartily applaud >your enthusiasm, but I think it is slightly misdirected, at least for where >you are on the learning curve right now. If they didn't intentionally make it difficult to learn I wouldn't be here.Article: 21763
On Thu, 30 Mar 2000 18:28:03 GMT, 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. Hi, having used Actel (antifuse), Lattice (ee reprogrammable) and Xilinx (ram) FPGAs, one striking difference is in development. Since all these parts are surface mount, and the hugely-expensive fine-pitch sockets just don't work, you pretty much have to replace an antifuse part (desolder, toss in trash, solder new one in) every time you do a design iteration or mod. This is an enormous pain, and 'discourages innovation'. I think that the Xilinx parts are the easiest to use overall. The Lattice ISP thing is OK, but those parts are actually CPLDs and don't have anywhere near the resources of a real FPGA. We're paying about $10 for pretty spiffy Spartan chips so, unless volume is high, our development cost remains a major factor overall. I wouldn't go back to Actel if they were free. Don't know how it is to work with Altera. JohnArticle: 21764
Has anyone tried this?
I need a small pld on a board I'm doing, and the Lattice ISP 22V10 should be
fine. I want ISP because I don't want sockets. And since I already have
the Xilinx software and cables, theoretically, this should work.
Or not?
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21765Contacted Altera today. They confirmed this to be a known bug and are providing a license file to bypass the dongle until it is resolved. Also, they have had several calls on the Quartus fitter giving internal applications errors. M R Wheeler <intell-a-sys@iquest.net> wrote in article <01bf99ea$b3e094a0$2a3b2bd1@speedy>... > I am evaluating MaxPlus 9.5 and am finding that often the software can not > seem to locate the dongle during the build process on larger designs. The > software give me a license error message. Also, when selecting the Quartus > fitter, I am getting internal errors (contact Altera, who never has a > clue). Both problems occur on two different computers. Just wonder if > anyone else is using this version yet. > >Article: 21766
Anshuman Sharma wrote: > > Anybody who is familiar with Adrian Thompson and his work with Hardware > Evolution can help. I am trying to duplicate the experiment that he did > using the Xilinx XC6216, but my problem is that Xilinx and discontinued > that particular series. I know I am not the first one to try and do that, > so if anyone has done it or know about it being done should be able to > help. > What I want to know is how can I duplicate it without using the > XC6216. That particular series had a very simple floorplan and it was a > research purposes-only version. If I have to use another chip then it is > very hard to just download random bit patterns on to a cell area without > frying the board, moreso, if you use the software provided by the regular > vendors, then it doesn't even let you do it. Is there another board that I > can use for the same, or is there another software that I can use to do > the same? Any help with this would be really appreciated. > > thanks, > > Anshuman > > -- > --------------------------------------------------- > "time and space are modes by which we think...... | > they are not the conditions in which we live." | > | > ~~Einstein | > --------------------------------------------------- > > Anshuman Sharma > Georgia Institute of Technology, Atlanta Georgia, 30332 > Email: gte600f@prism.gatech.edu > anshu@abraxis.com 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. -- 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: 21767
This is a multi-part message in MIME format. --------------635EE6AE738F288B60AB5AEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 || --------------635EE6AE738F288B60AB5AEF 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 --------------635EE6AE738F288B60AB5AEF--Article: 21768
I don't think anyone is making FPGAs intentionally difficult to learn. Instead, consider that modern FPGAs are very complex devices capable of holding circuits of up to more than a million logic gates. If anything, I find the literature available on the websites to be pretty good as far as discussing the architecture of the FPGAs as well as how to take advantage of it. Also, regarding your response to my earlier post, I don't even work at the XDL level. I do my designs at the other end of the xilinx tool flow where I can take the most advantage of the abstraction that I can to get a design done efficiently. You really do have enough control over the details to put together the design, including placement and to some degree even routing at whatever level of detail you are willing to persevere. You can run most of the tools, enough to do the design anyway, under DOS mode. Of course you don't get the GUIs that way, but I don't get the impression you like to use GUIs anyway (I'm running a place and route right now under a bash shell, which is why I have a moment to respond). Greg Alexander wrote: > In article <38E3B738.FAF783F5@ids.net>, Ray Andraka wrote: > >Oops, sent it before I finished typing. Anyway, Greg, I heartily applaud > >your enthusiasm, but I think it is slightly misdirected, at least for where > >you are on the learning curve right now. > > If they didn't intentionally make it difficult to learn I wouldn't be > here. -- -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: 21769
Does anyone have any citations for Thompson's original work? In article <38E4342A.4B3CD10C@xess.com>, Dave Vanden Bout wrote: >This is a multi-part message in MIME format. >--------------635EE6AE738F288B60AB5AEF >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > > > >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 || > > >--------------635EE6AE738F288B60AB5AEF >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 > >--------------635EE6AE738F288B60AB5AEF-- >Article: 21770
In article <38E43900.1F488CCC@ids.net>, Ray Andraka wrote: >I don't think anyone is making FPGAs intentionally difficult to learn. Instead, >consider that modern FPGAs are very complex devices capable of holding circuits >of up to more than a million logic gates. If anything, I find the literature >available on the websites to be pretty good as far as discussing the >architecture of the FPGAs as well as how to take advantage of it. Also, >regarding your response to my earlier post, I don't even work at the XDL level. >I do my designs at the other end of the xilinx tool flow where I can take the >most advantage of the abstraction that I can to get a design done efficiently. >You really do have enough control over the details to put together the design, >including placement and to some degree even routing at whatever level of detail >you are willing to persevere. You can run most of the tools, enough to do the >design anyway, under DOS mode. Of course you don't get the GUIs that way, but I Not quite. You can run them in console Windows, which is /NOT/ to be mistaken for DOS. DOS does not provide access to DLLs, specifically (not that this really matters to anyone but me, but DOSemu isn't a big hassle for me and Windows emulation would more or less necessitate a new HDD, bringing the total cost of ownership for what is a comparatively simple program to about $200 -- that most people buying this software want more than just the simple parts and consider $100 or even $1000 to be a very reasonable price is another red herring). That the software is capable of doing what you think I should do, even that the software is capable of doing what I want, remains a red herring. "Look, I don't have an answer to your question, but here's this red herring over here for you to look at." I appreciate it, but it's pretty useless. Thanks for trying and putting up with me and all. >don't get the impression you like to use GUIs anyway (I'm running a place and >route right now under a bash shell, which is why I have a moment to respond).Article: 21771
Hi all, I have a functional block which contains 3 components i.e. adder, XOR gate and barrel_shift. I want to sythesize this functional block and I am using Synopsys design_analyzer and Xilinx Design_manager. I am wondering about this: /* set_port_is_pad "*" */ /* insert_pads */ Should I include this two lines when I synthesize each component individually(I want to do timing simulation on the components)? I know I have to because design_manager generated error. What kind of parameter I should use so that it will work when I synthesize the functional block. What should I do when I synthesize the functional block? I know I need to use: include -f -db *.db; but, I don't know what I should do regarding "Set_port_is_pad" for the functional block. Thank you alot! Regards, Teik-MingArticle: 21772
The registers are placed so as to attempt to break the logic into equal sized chunks. So for LPM_PIPELINE = 1, the registers should be right at the center. If you think about it, this is the only way that makes sense if you really intend to increase speed. The ideal is that if it normally takes x for the signal to propagate, then with a pipeline of n the propogation delay should be x/n. However, in most cases this ideal is not reached since it is difficult to break the function up perfectly and also the delays of different routing are different.Article: 21773
Greg Alexander wrote:
>
> Does anyone have any citations for Thompson's original work?
His homepage is here with a lot of papers.
I guess the mentioned one is among them.
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee 160
D-23538 Luebeck Germany
Tel.: +49 451 500-3741, Fax: -3687
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
quiz, papers, VHDL, music
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21774Does anyone have any experience of using these parts? The ProASIC is Flash based which, to me, seems an interesting half-way house between antifuse and SRAM. Will it offer the best (or worst) of both worlds? David Miller
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