FPGA application field

tenteric schrieb:

You can apply FPGAs to just about any field that you care to mention, there are plenty of companies who are activly seeking engineers with skills in designing with FPGAs.Personaly ive worked on and developed designs for telecoms systems,cryptographic systems,soft processor cores.AS you mention cryptograhic applications I wrote a pipelined AES core a couple of years ago and got my present job of the basis of the knowledge gained during the development of that core.

I need to be more precise - my passion is just very fast computation - I'm very interesting in implementing any math algorithm thus it will work as fast as it can.

tenteric schrieb:

A FPGA is nothing more than a prototyping platform. Anything you can build as digital hardware you can map to an FPGA. You just don't need to manufacture wafers with your chips, bond and house them.

Ralf

Ralf Hildebrandt schrieb:

I dont agree that an FPGA is nothing more than a prototyping platform,it can form the basis of a very powerful configureable computing system,although i am a little lost as to the point of the original post because any algorithm can be implmented in hardware as well as it can be in software ,in hardware it will obviously benifit from the inherent parrelelism.How you implement the algorithm is upto you it can be in a Hardware description language or schematic capture .The mistake is oftem made of comparing a algorithm running on a microprocessor and implemented in a programmable logic device, the microprocessor implementation is clearly going to perform less well because of its inherently serial nature.

I know that. But I'm interesting, is there any real-world cases when FPGA design was successfull in heavy scientific computation, where outcome compensating FPGA cost + design cost, etc.

jez-smith,

As for the FPGA solution aways being faster, that is not necessarily the case: if the application requires data to the algorithm, and then data returned from the algorithm, the speed of the algorithm itself may be infinitely fast (ie take 0 time), and the microprocessor will still "win" because the data has to be sent to the FPGA from the microprocessor, and then sent back to the microprocessor from the FPGA.

Thus, the system architecture as well as the algorithm may result in a slower solution when the algorithm is ported to the FPGA, rather than a faster solution (the time spent sending and receiving data may be the limiting factor).

In the Cray system, with the 64 bit AMD uC and two Virtex II Pro FPGAs per compute node (>2,000 nodes), Cray points out that some choices of algorithm will result in a longer time if ported to the FPGA.

Algorithms with less data exchange (a whole block is sent to the FPGA to be "crunched") may offer a significant speedup, however.

So, the choice of how data is moved about the system becomes the limiting factor in the improvement offered by the FPGA. A system that has a custom architecture to solve just the problem at hand may not only take advantage of parallelism that a microprocessor solution can not, but it will also derive benefit by having its input/output architecture also optimized for the problem at hand.

A good example of the latter, is a cellular base station which does all processing at the IF frequency using FPGAs. The use of the FPGA for modulation/demodulation allows for much less power, and far fewer chips, than using microprocessor based DSP engines. The baseband (voice channel) processing is then performed by conventional DSP uC chips, as at the lower rates they become the optimal solution. The architecture of the base station is optimized for just this one task, and does not get in the way of the optimal solution. Since all elements are programmable, the basestation remains flexible (able to deal with various standards, upgrades, and changes).

Austin

"A FPGA is nothing more than a prototyping platform"

This an easily falsifiable statement. I've actually never knowlingly met anyone who has transferred an FPGA design to an ASIC. I'm not saying it doesn't happen a lot, just that there's obviously a whole community of FPGA users of whom you're not aware.

Resources for those interested in reconfigurable supercomputing:

Sign up to the openfpga mailing list:

check out the presentations from RSSI from the past two years:

Come to Manchester in March:

Reconfigurable HPC, it's all about programming... The fabric is capable enough (though double-precision FPUs instead of 18x25 mults would be nice)

Cheers,

Rob> tenteric schrieb:

Anything you can

Robin,

I have to laugh. Yes, some designs do get migrated to ASICs.

As a FPGA designer/supplier, and someone who talks to customers (I created the customer escalation procedures here 6 years ago), I got to hear all the bad experiences which customers have had in trying to create an ASIC from a working FPGA.

Timing closure almost always causes a mask revision, and IO problems rate as the second highest cause of mask re-spins. It doesn't even matter whose FPGA they are trying to convert, or even if they are trying to go a "guaranteed" route: they all fail more often than not.

[Advertisement: And now with EasyPath(tm), there is even less reason to torture yourself. Just freeze your design, and pay less.]

But, there are those who realize that an ASIC will cost less (their volume turns out to be much larger than they ever anticipated), and for them, they will/must continue to do the conversions.

They will continue to inform us that their business will "go away" as of a certain date, and we will continue to see them buying their significant quantities well after the date they gave us (indicating they are waiting for their mask revisions to actually work).

Austin

Robin Bruce schrieb:

Ok - I knew that this generalisation is like stepping into a nest of hornets, but it is one of the shortest answers you can give to describe what a FPGA is good for - especially if one does not know how much knowledge has the OP.

Ralf

then you probably should also track this - a FPGA variant called a FPOA

-jg

Fair enough Ralf,

I didn't mean to come crashing in so hard on your statement, so hope I didn't offend.

I tend to prefer the term "blank canvas" for describing FPGAs to the uninitiated myself. It makes the whole process sound much more creative :-)

Rob> Robin Bruce schrieb:

Robin Bruce schrieb:

No, you did not - in no way.

So you are similar to these medieval-age monks, that paint pictures over pictures. ;-)

Ralf

tenteric wrote: (snip)

There are some I know for searching DNA sequences. I believe they were reasonably successful at overcoming costs, etc.

Systolic array is my favorite for such processors.

-- glen

(snip)

My favorite architecture for such specialized processors is the systolic array. The ones I have seen used are for algorithms using 16 bit fixed point, which is easy. If you want 64 bit floating point it takes a lot more cells, but may be just about reasonable. If you can do it in 64 bit fixed point that would be somewhat easier (that is, more computation per device).

-- glen