Re: FPGA-based hardware accelerator for PC


Jeremy Ralph wrote:
If one wanted to develop an FPGA-based hardware accelerator that could
attach to the average PC to process data stored in PC memory what
options are there available.

Decision factors are:
+ ease of use (dev kit, user's guide, examples)
+ ability to move data with minimal load on the host PC
+ cost
+ scalability (i.e. ability to upsize RAM and FPGA gates)
+ ability to instantiate a 32 bit RISC (or equiv)

Someone recommended the TI & Altera Cyclone II PCIe dev board, which is
said to be available soon. Any other recommendations?

Also, what is the best way to move data between PC mem to FPGA? DMA?
What transfer rates should one realistically expect?

Thanks,
Jeremy

FPGAs and standard cpus are bit like oil & water, don't mix very well,
very parallel or very sequential.

What exactly does your PC workload include.

Most PCs that are fast enough to run Windows and the web software like
Flash are idle what 99% of the time, and even under normal use still
idle 90% of the time, maybe 50% idle while playing DVDs.

Even if you have compute jobs like encoding video, it is now close
enough to real time or a couple of PCs can be tied together to get it
done.

Even if FPGAs were infinitely fast and cheap, they still don't have a
way to get to the data unless you bring it to them directly, in a PC
accelerator form, they are bandwidth starved compared to the cache &
memory bandwidth the PC cpu has.

There have been several DIMM based modules, one even funded by Xilinx
VC a few years back, I suspect Xilinx probably scraped up the remains
and any patents?

That PCI bus is way to slow to be of much use except for problems that
do a lot of compute on relatively little data, but then you could use
distributed computing instead. PCIe will be better but then again you
have to deal with new PCIe interfaces or using a bridge chip if you are
building one.

And that leaves the potential of HT connections for multi socket (940 &
other) Opteron systems as a promising route, lots of bandwidth to the
caches, probably some patent walls already, but in reality, very few
users have multi socket server boards.

It is best to limit the scope of use of FPGAs to what they are actually
good at and therefore economical to use, that means bringing the
problem right to the pins, real time continuous video, radar, imaging,
audio, packet, signal processing, whatever with some logging to a PC.

If a processor can be in the FPGA, then you can have much more
throughput to that since it is in the fabric rather than if you go
through an external skinny pipe to a relatively infinitely faster
serial cpu. Further, if your application is parallel, the you can
possibly replicate blocks each with a specialized processor possibly
with custom instructions or coprocessor till you run out of fabric or
FPGAs. Eventually though input & output will become limiting factors
again, do you have acquisition of live signals and or results that need
to be saved.

It really all depends on what you are processing and the rate it can be
managed.

John Jakson
transputer guy

.

Relevant Pages