[Beowulf] [landman at scalableinformatics.com: Re: [Bioclusters] FPGA in bioinformatics clusters (again?)]

[Roderick Sprattling]

Jim Lux wrote:
> At 08:52 AM 1/14/2006, Eugen Leitl wrote:
> 
> 
> <snip>
> 
>> '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:
> 
> <deletia/>
> 
> 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 
programmability.

> 
> (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 
> problems.)

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 
> "patching".

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.

Rod
-- 
Roderick Sprattling
Solentas, LLC
roderick at solentas.com
skype: rsprattling
M: (518) 879-9096
F: (432) 206-6412