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 <3B144CCA.D9CF761F@aracnet.com>, eteam@aracnet.com says... > Chris, > > Could you elaborate on the problem? Was this a layout program > issue, a netlister issue, etc. etc. ? What I did was a fairly large design for a multipath channel simulator which was to be realised using Xilinx XV series devices. I did all the VHDL/simulation/place&route, no problem at all. Happy with that. Then I tried to use the Generate Part function in Orcad on the EDIF file (which I think is what you were suggesting) but of course there's nothing in that file which describes any of the power, ground or dedicated pins on the device. So you can use the generated part to draw up a schematic but when you generate a netlist from it and try to tie this to a PCB footprint you find you have a whole load of pins on the footprint which do not have matching entries in the netlist. At this point I decided it would be easier to just generate the part I wanted by hand including all the pins which weren't used explicitly in the EDIF. I hope this explains the problem I found. Maybe there is a way round it or it has been fixed in version 9.2 but seeing as they junked Express in this release and I rather liked it I stuck at 9.1. Chris -- Chris Eilbeck mailto:chris@yordas.demon.co.ukArticle: 31551
Austin, Thanks for the reponse and advice. Please see my comments below. Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3B13175A.519EF536@xilinx.com>... > The DLL requires the next clock input rising edge to be exactly where it is > supposed to be, +/- 350 ps (LF mode). If it isn't, it stops. If the clocks > are switched ahead of a PLL, then the PLL's output will change in frequency > slowly enough for the DLL to track it. This technique is used by many > customers (PLL ahead of DLL for clock discontinuity smoothing). A DLL can > track incredibly fast, ~60ps per clock edge! That adds up pretty fast for say > 100 edges = +/-6 ns total period change. There are some setting s that need > to be optimized (jitter filters). So if I switch clocks ahead of a DLL, I am not going to get a smooth transition from the one clock to the other clock. (The two clocks are nominally the same frequency +/- 100ppm). But if I switch clocks ahead of a PLL, I *will* get a smooth transition from the old clock to the new clock? So it looks as though I'm better to not use the FPGA's DLL at all in this case. > > 2. How well do the simulation models of the DLLs in the unisim library > > model the real DLLs? > > The logic funtion is there, but the timing relationships are fixed, and not > really useful for what you have in mind. I was afraid of that. > > 3. If I use the same device in the same package with the same place & > > route for the FPGA on all line cards, what can I expect my worst case > > device-to-device clock skew to be? > > In Virtex E, the error in the DLL to the global clock bus is a fixed amount, > and is less than 100 ps. There is some error from the global clock bus to any > CLB and IOB on chip as well. Consult the timing report for details. I > believe is is another 100 ps. I think I will try the following: Use the FPGA as a simple switch, two clock inputs and a select signal into an LUT-3, with one output to a output pin, and then feed that to a PLL. When I switch from one clock source to the other, the PLL should shift gently, right? If I have a spartan-II on each card, and have the same circuit in each spartan-II (with the same IOB, and the CLB in the same spot, close to the 4 pins involved), what would you expect the Device-to-device skew to be? I'm not concerned about the delay through the FPGA, since all cards will have the same FPGA. The data sheets & timing reports have the worst case delay, but don't include the error, as far as I can see. If they are in the datasheet/timing report, please direct me to where. Thanks! -KentArticle: 31552
Peter Alfke <palfke@earthlink.net> writes: > Anders is basically right. That's not what this circuit was intended to do. > It was meant to switch between two free-running clocks, or to > enable/disable a clock. No problem with "disabling" it: You just don't > connect the second input and don't use the select input. > > If I remember right ( I am at home without access to documentation ) you > can switch away from a dead clock if it is parked at one of its two levels, > but not at the other. > I maintain, it's a nice circuit when you switch between two free running > clock frequencies, e.g. to save power. Beats our classical recommendation > of using CE and always running the clock full-speed everywhere. > > Tack för hjälpen, Anders. > > Peter Alfke, Xilinx Applications Peter, With this circuit of yours, you can switch between clock nicely, but you can not the feed the results into a DLL, can you? if I understand correctly, the input to a DLL must come from a Clock input pin, or another clock? Thanks. -KentArticle: 31553
"Greg Cary" <gcary@multifeeder.com> writes: > I am designing a multi-function peripheral for a microcontroller using a > Xilinx Spartan II. I have created an initial design that uses the read and > write signals from the microcontroller in an asynchronous fashion. The VHDL > compiler warns about using these signals as clocks, so I'm wondering if this > is the best design approach. Hi, Greg. This is a topc that has been discussed at length here. I might suggest you look at www.fpga-faq.com. I suggest looking at the thread "Searching the Archive" started by Philip Freiden. > I was thinking I would use the write signal to > clock the data into the Xilinx, and then run it through some logic to > synchronize it with the Xilinx clock (which will be the same as the > processor's clock). The microcontroller has a clock output signal, but I'm > not sure if the write or read strobes are synced with the clock. I would > think the latter would be the preferred approach if the microcontroller's > read and write strobes are derived from the microcontroller's clock. I would be very suprised if the read and write strobes were not derived from the CPU's clock. If you have a clock from the CPU that you can connect to the FPGA, it makes your job really easy . . . you simply sample the control signals on a clock edge (rising or falling, depending on the CPU timing.) The following can detect a risaing edge: You can extend it to falling edges if required. if (WriteStrobe = '1') and (WriteStrobe_delayed = '0') then I very much suggest sitting down with the CPU's timing diagram, and figuring out how everything relates to the CPU's clock before trying to design your interface. Regards, -KentArticle: 31554
Chris, I understand your frustration. At the same time I cringe at the thought of entering 100s of pin numbers and names by hand. I can't speak for version 9.1, but Capture 9.2 certainly solves the problem you describe. by selecting the .PIN or the .LCA file (you get to choose from a variety of design file options), the complete pin list is available for merging into the schematic symbol; including power, dedicated special purpose, and unconnected pins. it works well. Bob Elkind eteam@aracnet.com Chris Eilbeck wrote: > In article <3B144CCA.D9CF761F@aracnet.com>, eteam@aracnet.com says... > > Chris, > > > > Could you elaborate on the problem? Was this a layout program > > issue, a netlister issue, etc. etc. ? > > What I did was a fairly large design for a multipath channel simulator > which was to be realised using Xilinx XV series devices. I did all the > VHDL/simulation/place&route, no problem at all. Happy with that. Then I > tried to use the Generate Part function in Orcad on the EDIF file (which > I think is what you were suggesting) but of course there's nothing in > that file which describes any of the power, ground or dedicated pins on > the device. So you can use the generated part to draw up a schematic but > when you generate a netlist from it and try to tie this to a PCB > footprint you find you have a whole load of pins on the footprint which > do not have matching entries in the netlist. > > At this point I decided it would be easier to just generate the part I > wanted by hand including all the pins which weren't used explicitly in > the EDIF. > > I hope this explains the problem I found. Maybe there is a way round it > or it has been fixed in version 9.2 but seeing as they junked Express in > this release and I rather liked it I stuck at 9.1. > > Chris > -- > Chris Eilbeck mailto:chris@yordas.demon.co.ukArticle: 31555
Kent Orthner wrote: > Peter, > > With this circuit of yours, you can switch between clock nicely, but you can not > the feed the results into a DLL, can you? if I understand correctly, the input > to a DLL must come from a Clock input pin, or another clock? Kent, I don't think that is a problem, the problem is elsewhere: You should never feed a sudden jump in frequency into a DLL. It goes crazy and loses lock. I talked with Austin, and we agreed that you must put two DLLs, one for each clock, in front of the mux. And you will get a glitch-free output, but of course one with a gap whenever you switch. The gap is less than one clock period. I have lost track of what you really want to achieve... Peter > > > Thanks. > -KentArticle: 31556
"Austin Franklin" <austin@dar54kroom.com> wrote in message news:9eutmp$e97$1@slb6.atl.mindspring.net... > > > The legal strategy seems to be mostly about spreading confusion amongst > the > > jury. I gather the trial was something like this: "Look at the Xilinx. > It > > has lookup tables. Look at the Altera. What do we see? Lookup tables! > > A-ha!" > > That is, of course, completely ridiculous. The "strategy" is to explain > things to the jury in such a way that they understand it, and can reach a > fair decision. I take it you have no first hand knowledge of how cases like > this work, or I don't believe you'd be saying this. > > So you are saying that lawyers attempt to present juries unbiased statistical facts so that they can come to a just, fair, conclusion. I had the notion they used subterfuge and emotion to win at all costs. I must be very naive about the legal system.Article: 31557
Mario, Etwas ist nicht klar. Warum brauchen sie ein FPGA? Der 9052 hat Lokal-Bus fuer Lokal-Speicher. Koennen Sie nicht direkt die SRAM mit dem 9052 anbinden? Das waere einfacher. Man braucht viellecht noch eine Processor, der 9052 zu programmieren. -Kevin "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message news:3B109F88.356B08B7@t-online.de... > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen. > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten. > > Danke > > Mario Giffel > >Article: 31558
> Kent Orthner wrote: > > With this circuit of yours, you can switch between clock nicely, but you can not > > the feed the results into a DLL, can you? if I understand correctly, the input > > to a DLL must come from a Clock input pin, or another clock? Peter Alfke <palfke@earthlink.net> writes: > Kent, I don't think that is a problem, the problem is elsewhere: You should never > feed a sudden jump in frequency into a DLL. It goes crazy and loses lock. > I talked with Austin, and we agreed that you must put two DLLs, one for each clock, > in front of the mux. And you will get a glitch-free output, but of course one with > a gap whenever you switch. The gap is less than one clock period. Okay. I think I understand all the issues now. What I guess I need is a PLL after the switch, not a DLL. (I'm not sure how a DLL works, so I didn't know if it would go crazy with a sudden clock switch or not.) > I have lost track of what you really want to achieve... My fault! I'm primarily interested in clock synchronizing for a redundant system, in which case the circuit described in your XCell article is not appropriate. But once I look at the article, I wanted to know the question above, even though it isn't applicable to my redundancy problem. Thanks for the advice! -KentArticle: 31559
I don't know if there is a general rule for your problem; it's very microcontroller dependent. In general, It's not a good idea to use read/write signals as a clock. You could, however, use the read/write as a latch enable signals. I've actually done both ways, i.e., asyn and sync. As an example, one of the processors I used, The TI 5402 DSP, has read/write signals that has a timing relationship to the clock from -2ns to +3 ns. If you program the peripheral access as zero-wait, the processor will clock in the data on the rising edge of the read/write, which has only one clock cycle duration. Because the DSP was operated at a very slow clock frequency(20MHz), I was able to use the neg clock edge to sample the RDB/WRB signals, and present the data(or clock in) the data at the clock rising edge. It's very typical synchronous design, and the process is very straighforward. The tradeoff is you cannot scale the circuit to a higher speed, whereas an asyn design usually has more margin in that regard. However, you need to pay much more attention to the signal glitches. Just my 0.02. Wei "Greg Cary" <gcary@multifeeder.com> wrote in message news:UxSQ6.2712$YC5.200296@news.uswest.net... > I am designing a multi-function peripheral for a microcontroller using a > Xilinx Spartan II. I have created an initial design that uses the read and > write signals from the microcontroller in an asynchronous fashion. The VHDL > compiler warns about using these signals as clocks, so I'm wondering if this > is the best design approach. I was thinking I would use the write signal to > clock the data into the Xilinx, and then run it through some logic to > synchronize it with the Xilinx clock (which will be the same as the > processor's clock). The microcontroller has a clock output signal, but I'm > not sure if the write or read strobes are synced with the clock. I would > think the latter would be the preferred approach if the microcontroller's > read and write strobes are derived from the microcontroller's clock. > > What is the preferred design approach when interfacing with the read and > write signals of a microcontroller? > > Thank you very much, > > Greg Cary > > > >Article: 31560
Danke für ihr Interesse ! An dem FPGA ist ein Lasersensorkopf angeschlossen der daten liefert. Diese Daten werden über das FPGA in das SRAM geschrieben. Dort möchte ich diese Daten mit den beschriebenen Bausteinen auslesen. Dabei geht es nicht um die Software die den PCI-Bus ansteuert, sondern nur um das FPGA-Design. Mario Kevin Neilson schrieb: > Mario, > Etwas ist nicht klar. Warum brauchen sie ein FPGA? Der 9052 hat Lokal-Bus > fuer Lokal-Speicher. Koennen Sie nicht direkt die SRAM mit dem 9052 > anbinden? Das waere einfacher. Man braucht viellecht noch eine Processor, > der 9052 zu programmieren. > -Kevin > > "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message > news:3B109F88.356B08B7@t-online.de... > > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an > > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte > > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen. > > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses > > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten. > > > > Danke > > > > Mario Giffel > > > >Article: 31561
Hello, I have many files .vhd that I downloaded on the net. But when I compile them, I can't specifiy in project manager to see all the files in the same time (cause warning and error). How to use 5 files in vhdl for one chip (a serial port RS232) if someone have a prog for this please help me. Thanks Fred (excuse my english i am a poor french)Article: 31562
Shane Tow wrote: > > I am trying to install Xilinx Alliance 3.x Software on a Pentium 4 system. > During installation I receive a message that states "java.exe has caused > errors and has been closed ..." According to the Xilinx website this is due > to the fact that the Pentium 4 isn't compatible with the Java Runtime > Environment and that the latest version needs to be downloaded form the Sun > website. I did this, and I still get the same error. Has anyone ran into > this problem and been able to solve it? Or does Xilinx have a patch for > their software? > > Thanks, > > Shane I done it, as far as I remember it goes something like this; -download the new java runtime and install it, -copy the entire alliance install CD to the HD -replace the java runtime in the alliance installation (on the HD) with the new one -run the alliance installation from the HD -Lasse -- Lasse Langwadt Christensen, -- PHX,AZArticle: 31563
I use the following technique to generate Orcad symbols for large FPGAs . 1) download the device pinout table from http://www.xilinx.com/products/virtex/ vepackages.htm or v2packages.htm. Alternatively you can use: > partgen -v YOURDEVICE Don't count on the printed data sheet it sometimes contains errors (for example I found an error on 405ebg560 data sheet pinout table ). 2) Read the pinout text file into your favorite spreadsheet SW (I use Microsoft excel). You now have to decide how do you want your symbol to look like. For parts with more than 100 I/Os I suggest to use "heterogeneous symbols" ( It means that you have more than one symbol for the SAME device). I usually use 6 symbols: one for power , one for configuration and one for every two I/O banks (including the GCLK and the VCCO ). You need to arrange the spreadsheet in groups correlated to the number of symbols you need ( I use "Sort By" -> "bank number" and than by "pin type"). 3) here is the trick: In Capture select "New Part", Place -> "Pin Array" and draw as many pins as you need. Now, select all the pins and than press Ctrl+E. You get a little spreadsheet with the pins names and numbers. select all the spreadsheet and press Ctrl+Insert. Switch to the Excel and paste the data in an empty sheet. Copy the real pin names from the Original sheet you created and paste them instead of the automatic pin names. Mark the new data , switch back to Capture and press Shift+Insert. Repeat step (3) for each of the heterogeneous symbols. I used that technique many times on Windows , I don't know if it can be done in other OS. It takes no more than 30 min. to create a new Symbol for a > 400 I/O FPGA . ----------------------------------------------------------------------- Rotem Gazit *** MystiCom Ltd. *** mailto:rotemg@mysticom.com http://www.mysticom.com -----------------------------------------------------------------------Article: 31564
Hi all, I just got a design document from system architect, and found something unusual: A BLOCK of RAM is cleared in one clock cycle. Can anyone tell me how to implement RAM in FPGA that can be cleared in this way? ThanksArticle: 31565
In article <3B145ACB.BA2D780B@aracnet.com>, eteam@aracnet.com says... > Chris, > > I understand your frustration. At the same time I cringe at the > thought of entering 100s of pin numbers and names by hand. > > I can't speak for version 9.1, but Capture 9.2 certainly solves the problem > you describe. by selecting the .PIN or the .LCA file (you get to choose > from a variety of design file options), the complete pin > list is available for merging into the schematic symbol; including power, > dedicated special purpose, and unconnected pins. it works well. Thanks for that. It sounds like I'll need to do some cludge to give me Capture and Layout v9.2 and stick with Express v9.1 Chris -- Chris Eilbeck mailto:chris@yordas.demon.co.ukArticle: 31566
Hi, Frederic. It sounds to me like you are missing a top level file. You should have a top-level file somewhere that 'instantiates' all the other blocks. That top level will have one set of input & output pins that you can connect to the sub-blocks input & outputs any way you feel like. Hope this helps. -Kent "Frederic Darre" <darre@irit.fr> writes: > Hello, I have many files .vhd that I downloaded on the net. > But when I compile them, I can't specifiy in project manager to see all the > files in the same time (cause warning and error). > How to use 5 files in vhdl for one chip (a serial port RS232) if someone > have a prog for this please help me. > Thanks Fred > (excuse my english i am a poor french)Article: 31567
Kent Orthner wrote: > > I'm perhaps doing something really dumb, and trying to use an FPGA > for something it's not meant to do. But to a guy with a hammer, > everything looks like a nail, right? > > I'm implementing a redundant system. On each card, (There's about 6 > cards in a chassis) there will be two nominally 52MHz clock inputs. > The system controller will select which of the two clocks to use. > > I'm thinking of using an FPGA on each card to perform the clock > switching. If I feed the switched clock into a DLL, then I imagine > that the transition from one clock to the other has to be pretty smooth. > > I imagine the setup as follows (Using Spartan-II): > > Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives > ClkSelected. I can not connect this to a DLL, so I drive it off-chip, and > then back on-chip, to *then* connect it to a DLL. The output of the DLL > then goes outside to the real world where it drives a 'zero delay clock > buffer', which drives all of the devices on that card. > > I have a couple of questions that hopefully someone can help me with: > > 1. Is this a really stupid way of doing it? Should I simply forget > about using a FPGA for this? > > 2. How well do the simulation models of the DLLs in the unisim library > model the real DLLs? > > 3. If I use the same device in the same package with the same place & > route for the FPGA on all line cards, what can I expect my worst case > device-to-device clock skew to be? > > 4. Any other comments or suggestions would be greatly appreciated. > > Thanks in advance. Hi Kent, Is that "nominally 52MHz" clock really 51.840MHz? If it's being used for SONET/SDH timing, there are all sorts of restrictions regarding the rate of change of frequency, and the size of phase hits, etc. Implementing SONET/SDH clock switching is non-trivial. There are several commercial SETS (umm, Sonet Equipment Timing Source?) chips that will manage your clock switching for you, e.g. http://www.semtech.com/products/sets.html (I know that it is definitely possible to do one in an FPGA with an external VCXO.) The requirements (for SDH, at least) are in ITU-T G.707, G.810, 811, 812, etc. OTOH, if this is not related to network clock switching, my apologies. Regards, Allan.Article: 31568
This is just a question. Is anybody using FPGAs to execute scientific programs? Is it possible to find small cores in the programs that can be mapped onto a FPGA and obtain good speed-up? Which is the main problem, computing or IO bandwidth? If you are doing that, which are the results? Which kind of programs are you focused in: optimization, genetics, matrix computation, simulation, weather forecast...? regardsArticle: 31569
Thanks for the help. I found the same answer on the Xilinx website and gave it a try and it worked. Now, hopefully my place and route times will be much faster. What has your experience with par times been with the Pentium 4? Thanks, ShaneArticle: 31570
Allan, I second that. I worked for a company that build BITS clocks for SONET, and the switchover was not a pretty spec. You could move less than X ns in y ms, which led to PLL's with poles at > 0.1 Hz. This led to really bad short term stability problems from the PLL having such a terrible and slow response time. If I had it to do over again, I would use a synthesizer running at 300 MHz to synthesize the 51.84 MHz (a digital locked loop with the A or B 51.85 as a reference input to be tracked), and then digitally slew the DDFS synthesizer from one frequency to the other. I would then remove the synthesis jitter with a PLL following. Austin Allan Herriman wrote: > Kent Orthner wrote: > > > > I'm perhaps doing something really dumb, and trying to use an FPGA > > for something it's not meant to do. But to a guy with a hammer, > > everything looks like a nail, right? > > > > I'm implementing a redundant system. On each card, (There's about 6 > > cards in a chassis) there will be two nominally 52MHz clock inputs. > > The system controller will select which of the two clocks to use. > > > > I'm thinking of using an FPGA on each card to perform the clock > > switching. If I feed the switched clock into a DLL, then I imagine > > that the transition from one clock to the other has to be pretty smooth. > > > > I imagine the setup as follows (Using Spartan-II): > > > > Clk0 an Clk1 and Select are input pins, all going to a LUT3, which drives > > ClkSelected. I can not connect this to a DLL, so I drive it off-chip, and > > then back on-chip, to *then* connect it to a DLL. The output of the DLL > > then goes outside to the real world where it drives a 'zero delay clock > > buffer', which drives all of the devices on that card. > > > > I have a couple of questions that hopefully someone can help me with: > > > > 1. Is this a really stupid way of doing it? Should I simply forget > > about using a FPGA for this? > > > > 2. How well do the simulation models of the DLLs in the unisim library > > model the real DLLs? > > > > 3. If I use the same device in the same package with the same place & > > route for the FPGA on all line cards, what can I expect my worst case > > device-to-device clock skew to be? > > > > 4. Any other comments or suggestions would be greatly appreciated. > > > > Thanks in advance. > > Hi Kent, > > Is that "nominally 52MHz" clock really 51.840MHz? If it's being used > for SONET/SDH timing, there are all sorts of restrictions regarding the > rate of change of frequency, and the size of phase hits, etc. > > Implementing SONET/SDH clock switching is non-trivial. > > There are several commercial SETS (umm, Sonet Equipment Timing Source?) > chips that will manage your clock switching for you, e.g. > http://www.semtech.com/products/sets.html > (I know that it is definitely possible to do one in an FPGA with an > external VCXO.) > > The requirements (for SDH, at least) are in ITU-T G.707, G.810, 811, > 812, etc. > > OTOH, if this is not related to network clock switching, my apologies. > > Regards, > Allan.Article: 31571
> We do this in our FPGA board. As you seem to be german, you can look it > up: > http://www.em.informatik.uni-frankfurt.de/~prak/platine/index.html Two questions: - Are you using your own PCI core or a Xilinx core? - Is this board for sale or is it possible to get better readable files of the schematics and PCB (gerber would be nice) so that I can make my own? It seems to be exactly what I am looking for in order to develop a W2K driver for the Spartan II PCI core. ClemensArticle: 31572
I hope it is a small block. You'll have to implement the RAM as an array of flip-flops to get the single cycle clear. The block RAMs and CLB RAMs do not have a clear input, so they cannot be cleared in a single cycle. If the access is in a known pattern however, you can fake it by gating the read data until the RAM has been re-written. Huang wrote: > > Hi all, > > I just got a design document from system architect, and found something > unusual: A BLOCK of RAM is cleared in one clock cycle. > > Can anyone tell me how to implement RAM in FPGA that can be cleared in this > way? > > Thanks -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 31573
> Is anybody using FPGAs to execute scientific programs? Yes > Is it possible to find small cores in the programs that can > be mapped onto a FPGA and obtain good speed-up? > Which is the main problem, computing or IO bandwidth? The EXTERNAL bandwidth of an FPGA is not much higher than that of a processor. Therefore, you will only see very large performance gains for algorithms that have a rather low IO requirement. On the otherhand, the internal bandwidth of an FPGA can be extreme. For example in my diploma thesis I used a shallow stack that could accept 3000 Bits in a single clock cycle. The main problem is tools. Many applications can be implemented with very high performance in an FPGA if you have a good engineer. The difference between a good and a bad design are bigger in hardware than in software. Also, with bad designers you are more likely to fail completely in hardware design than in software. > If you are doing that, which are the results? Which kind > of programs are you focused in: optimization, genetics, > matrix computation, simulation, weather forecast...? You would like to have algorithms that parallelize well into so called systolic structures, this means that each computing element only comunicates with a constant amount of neighbours. This is often the case for dynamic programming algorithms. Compared to a processor, you are going to look better for tasks that do not map well to the large word width of processors. (DNA Matching for example works on 4-Bit data, fault simulation on 2-Bit data) Also, bit oriented operations that do not map well to the CPUs instruction set will do fine. (cryptography) Also SIMD algorithms are good, but there is other hardware for this (vector computers, thinking machines, ...) Andre Dehon did a quantitative analysis of this in his PhD thesis: http://www.cs.caltech.edu/~andre/ You actually can buy FPGA based computers that are more than a factor of 1000 faster than CPU implementations for the following tasks: - DNA sequence matching (Smith-Waterman-Algorithm) - fault simulation (test pattern generation) - network packet switching - decryption/encryption of DES, Rijndal, ... - computer vision For everything that involves large data words or floating point computations, the results will not be as extreme. Some pointers are in Andre's thesis. A list of hardware used for this is here: http://www.io.com/~guccione/HW_list.html Kolja SulimmaArticle: 31574
Alles klar. Am einfachsten is ein dual-port SRAM zu benutzen. An dieser Weise darf die FPGA die Daten an einer Seite (Port) das dual-port SRAM liefern. Die andere Seite (Port) des SRAMs waere direkt mit 9052 angeschlossen. Es ist also nicht noetig, ein kompliziert Anschluss zwischen FPGA und 9052 machen. Diese dual-port SRAM darf ausserlich sein, oder besser, wenn sie nicht so viel SRAM brauchen, durfen Sie z.B. Xilinx blockRAM benutzen. -Kevin "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message news:3B1490F8.8E645D42@t-online.de... > Danke für ihr Interesse ! > An dem FPGA ist ein Lasersensorkopf angeschlossen der daten liefert. Diese > Daten werden über das FPGA in das SRAM geschrieben. Dort möchte ich diese Daten > mit den beschriebenen Bausteinen auslesen. Dabei geht es nicht um die Software > die den PCI-Bus ansteuert, sondern nur um das FPGA-Design. > > Mario > > Kevin Neilson schrieb: > > > Mario, > > Etwas ist nicht klar. Warum brauchen sie ein FPGA? Der 9052 hat Lokal-Bus > > fuer Lokal-Speicher. Koennen Sie nicht direkt die SRAM mit dem 9052 > > anbinden? Das waere einfacher. Man braucht viellecht noch eine Processor, > > der 9052 zu programmieren. > > -Kevin > > > > "T-Online" <Mario.Heike.Niklas@t-online.de> wrote in message > > news:3B109F88.356B08B7@t-online.de... > > > Wer hat Erfahrung mit der Anbindung eines FPGA auf einem PCI - Board an > > > den PCI - Bus. Dazu benutze ich den PLX Baustein PCI 9052. Ich möchte > > > einen SRAM, das mit dem FPGA verbunden ist über den PCI -Bus auslesen. > > > Wer hat Tipps oder auch Beispielprogramme in VHDL die dieses > > > bewerkstelligen. Worauf muss ich beim programmieren des FPGA achten. > > > > > > Danke > > > > > > Mario Giffel > > > > > > > >
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