[Beowulf] [firstname.lastname@example.org: Re: [Bioclusters]
FPGA in bioinformatics clusters (again?)]
roderick at solentas.com
Sat Jan 14 21:52:18 PST 2006
Jim Lux wrote:
> At 08:52 AM 1/14/2006, Eugen Leitl wrote:
>> 't see attached processing
>> replacing clusters or HPC systems, Is.
>> Joseph Landman, Ph.D
> using masses of FPGAs is fundamentally different than uses masses of
> computers in a number of ways:
> 4) There are applications for which FPGAs excel, but it's likely that a
> FPGA solution to that problem is going to be very tailored to that
> solution, and not particularly useful for other problems. The FPGA may
> be a perfectly generalized resource, but the system into which it is
> soldered is not likely to be so.
Not necessarily so. One can implement generalized algorithms. And since
an FPGA can be reprogrammed within milliseconds, one device can serve
varied computational needs.
> Joe's analogy to video coprocessors is apt. Very specialized to a
> particular need, where they achieve spectacular performances, especially
> in a operations per dollar or operations per watt sense. However, they
> are very difficult to apply in a generalized way to a variety of problems.
> Of course, the video coprocessor is actually an ASIC, and is essentially
> hardwired for a particular (set) of algorithms. You don't see many
> video cards out there with an FPGA on them, for the reason that the
> price/performance would not be very attractive.
The price/performance of FPGA devices is increasing, and FPGAs are
chewing into ASIC markets. For instance, there are a boatload of
reconfigurable devices being marketed to, and adopted by, mobile
manufacturers: They give manufacturers more design flexibility in
manufacture, and some are designed and employed to enable field
> (mind you, if you've got the resources, and a suitable small set of
> problems you're interested in, developing ASICs is the way to go.
> D.E.Shaw Research is doing just this for their computational chemistry
I think developing ASICs to support computational domains having robust
algorithm research is the worst way to go. The sunk cost of deploying an
ASIC is huge, and it's obsoleted with the very first improvement of an
algorithm or discovery of an implementation bug. ASICs make sense only
if you're selling millions of fundamental-architecture devices over a
long period of time. Microprocessors, graphics accelerators and DSPs
pass the test. Low-volume specialized processors don't. Remember Paracel?
> 5) FPGA development tools are wretchedly expensive, compared to the
> tools for "software". It's a more tedious, difficult and expensive
> development process.
FPGA vendors provide the basic tools for cheap or free. There are other
open source tools available. The EDA tools are admittedly expensive, but
they're really focused upon system-on-a-chip designs and not well
suited for developing HPC. It's definitely a more tedious, difficult and
expensive (in terms of labor) development process; there have been many
attempts to develop behavioral specification tools suited to developing
HPC FPGA configurations, and that work goes on, but right now it's
essentially hardware design.
> There's a lot more software developers than FPGA designers out there, so
> it's harder to find someone to do your FPGA. It's not really a dollar
> issue (top pros in both are both in the $100K/yr salary range) it's
> finding someone who's interested in working on YOUR project.
I agree there are a very few who focus on HPC. I can also give you my
biased opinion that those who *do* focus on HPC are probably willing to
be interested in your project. =)
> Sure, there are some basic "free-ish" tools out there for some FPGAs,
> but if you want to do the equivalent of programming in a high level
> language, you're going to be forking out $100K/yr in tools.
Those tools don't provide the equivalent of programming in an HLL, even
though they have 'C' somewhere in their names. You still have to know
hardware design. Last I looked, no FPGA card/system vendor pursuing the
HPC market was (still) teamed up with any EDA vendor to promise a
just-like-software HLL development experience. Please correct me if I'm
wrong on this.
> Resynthesizing your FPGA design is often a lot slower than recompiling
> your program. Also, because it's basically a set of logic gates, there
> typically isn't the concept of recompiling just part and relinking.
> It's resynthesize EVERYTHING, and then you have to revalidate all the
> timings, regenerate test vectors, etc. There's no equivalent of
Until the lickety-split synthesis-layout-timing cycle is invented,
people will probably play with partial reconfiguration of the device to
localize changes. But that introduces a metalevel of design
sophistication that adds to overall development time and expense.
Bottom line: It's not easy, but for many production computing
applications using the current crop of FPGA coprocessors can be a huge win.
roderick at solentas.com
M: (518) 879-9096
F: (432) 206-6412
More information about the Beowulf