A Generic PCI Based FPGA Coprocessor?

graveyhead asks: "Inspired by a recent Slashdot article, I came across this fantastic package from the fine students in the Configurable Computing Laboratory at BYU: JHDL, which is a set of open source FPGA CAD tools. I am writing a proposal for a prototype system and I have a requirement for a 32 or 64 bit PCI card compatible with JHDL. I do not require any IP cores (which Xilinx seems to want to sell me hundreds of 'em), since our project uses its own custom cores. Also, I will not be building additional hardware around the FPGA processor, so the package needs to be fully self-contained. I simply need the ability to use JHDL to program the FPGA device over PCI under Linux, execute my circuit with parameterized values, and return the result. I found these boards, but I'm not sure which is appropriate or compatible, or if there are better alternatives that I am not finding in a similar price range (up to USD2000). Preferably, I want a chip with lots (1-10M+) of programmable gates."

Comments

A bit overkill

[brejc8]

1-10 mil gates is a very large number.
Take a look at my MIPS on an FPGA. That used less than 100k vertex gates including MMU and other things youprobably dont need.

Also why PCI? Why not talk to it via serial/usb/network? And why not make your own? We made these for just over £100 ($150) each (plus virtex). having the board outside the PC allows you to have more freedom and external connections to do things like this. Also it allows you to write a simpler download software routine to program the thing (serial vs PCI).

Re:A bit overkill

[Jamie Lokier]

How do you get a PCB like that made with all those components and connectors for just £100? Is it just a 2 layer board?

Also, you didn't mention how much the Virtex cost. Last time I looked, which was about a year ago, they were many hundreds of pounds from RS. I've been told that with FPGAs the real price depends on where you buy them and your relationship with the supplier. How much did you get yours for?

Thanks,
-- Jamie

Re:A bit overkill

[chriss]

Also why PCI? Why not talk to it via serial/usb/network? And why not make your own?

I'm coming from the software side, so for me an FPGA has always been kind of an hardware accelerator for my software. My prefered idea is to plug one of these into my machine, learn to program it to do a specific part in e.g. my webserver and never bother with the fact that it is really hardware. So I need the bandwidth of PCI to do something usefull and do not want to touch a soldering iron. I'm aware that there are many more possibilities, but asume that in total numbers more programmers are actualy interested in FPGA than hardware engineers, since there are many more programmers than hardware engineers.

Chriss

Re:A bit overkill

[megabeck42]

Well, why constrain yourself at the PCI level? If you recall the prilchard is exactly what you suggest: It's a Virtex FPGA attached to the PC133 bus. You interface with the board using regular push/mov/movsw instructions. The author was able to demonstrate almost a gigabyte/second DES, much faster than any other PCI accelerator. Furthermore, you could do fancy off-loading using DMA. E.G. DMA from the ethernet card into a ring buffer maintained by the FPGA, and have the FPGA preprocess.

For a real general approach, you would need another card in the system, probably PCI to be able to program the fpga, and it would allow the FPGA to raise an interrupt if necessary. Personally, I would be extremely interested in one of these because of the phenomenal possibilities it allows.

For example, it would make the gnuradio project much easier by building an FPGA with all the requisite, processor intensive FIR/IIR filters, FFTs, and Viterbi decoders.

Furthermore, you could buckle the FPGA to a high-speed A/D converter, and use the FPGA to do do the initial signal processing. That would really make a difference for very low-latency sound processing for example.

You could implement custom cache functions in hardware for databases, you could accelerate SSL like mad. With open cores, you could patch libmad, etc. to use the FPGA when its available, accelerating MPEG encoding, for example.

For some reason, I can't access his webpage, but, his work is at, http://www.cse.cuhk.edu.hk/~phwl/

If you're interested in this route, and want some help, shout.

Generic FPGA coprocessor with standard IO

[graveyhead]

The experience of looking for this card got me to thinking:

Does anyone else remember back in the day, OrangeMicro used to sell a card, now discontinued :( for Macintoshes that put a fully working PC on a PCI card on your Mac. In fact, I think I still have that laying around here somewhere! You could switch between Windows95 and MacOS, both running in native hardware by hitting Command-Enter. It was very neat, like VirtualPC except in an actual Pentium instead of a virtual one.

Anyhow the inspiring part of the old OrangePC in this case is the multi-functional cable attached to the back. It was a truly monsterous wonder. One side was a huge hundreds-of-pins cable which plugged into the PCI card, and the other side split off into VGA video (which could pass-through the Mac signal, or interrupt it and output the PC signal), audio IO, 2 serial ports, a parallel port and a game port! It was truly an engineering masterpiece :)

So, why doesn't someone build a generic PCI device with such an awesome cable attached? It would give a whole new meaning to opencores.org. Software could be written that could drop in an arbitrary core and turn your card into any device that you desired that minute. Remember what Homer says: "Aww, I want it now!". With such a device, you could have it, or build it yourself right from your desktop if you were so inclined ;) For example, if the bass is rattling on my friends new album and we want to try cutting off frequencies below 10hz:

• install open extensible DSP core
• install custom logic: if (f < 10) v = 0
• Play/record through card

You could even do what OrangePC did and drop a whole processor/OS combination (or develop one) on the board and seamlessly switch between it and the host OS. If the card had multiple FPGAs, it could even drive multiple custom devices simultaneously.

Bye bye PCI hardware vendors (except ones to make the general purpose boards). Next, let's build an AGP8x version (with a stable on-board backup VGA core, just in case ;) and set our sights on NVidia and ATI! Now, any volunteers to build an open-source OpenGL accelerated VGA core? All it is is a couple of multipliers, right? ;)

The problem may be that no PCI/AGP vendor in their right minds would ever build such a thing, because it would replace all their products. Still, it's fun to dream about such a useful piece of hardware.

Re:Hey...heads up!

[graveyhead]

Well, first off, thanks. That list is great.

What are you trying to do, physically model a barrel of quarters?

As fun as that sounds, no. Actually I am interested in genetic programming and a huge bottleneck is the time that it takes to test a generated program or circuit. Substantial time savings could be made if some of the calculations during that step could be offloaded to a coprocessor that was dynamically tuned for each generated program. This means that genetic runs with much larger populations that can be processed over more generations become possible. One of the points Dr. John Koza makes in his research papers is that in conjunction with Moores' law, more and more complex problems may be addressed alongside an exponential increase in computing power. The more gates I have, the more calculations I can make simultaneously, and the system runs faster (in thoery).

I want to experiment with such a card to find out if any of this is feasable.

Re:Coprocessor designed for libc

[Hast]

I doubt you'll see anything like this is real systems. First off, the big bonus with FPGAs is that they can crunch a /lot/ of data very fast. They can also do a lot of parallel computations at once. Using one to communicate with a modem would (IMHO) be an almost criminal misuse of hardware.

A better alternative is to put algorithms or parts of them on a FPGA. Typically for simulations, intensive mathematical processes and similar. It's noteworthy that floating point is very expensive in hardware, so you probably want to stay away from algorithms which require that.

Doing place and route also take a lot of time (several hours/days on larger chips) so you'd probably want to define a couple of functions and place and route those together. (You could have several of the "bundles" pre-made. But only run one at a time.)

And regarding JIT, since the second CPU would be limited by the first there's not much benefit in doing that neither. You can just as well do what you do today, ie do the JITting as you start executing and then doing optimizations as the program runs.

CPUs are very fast today. So doing serial things which they excel at is not much use to put in a FPGA coprocessor.