Hi Tirath: Tirath Ramdas wrote: > Hi all, > > On 12/02/2006, at 12:39 AM, Amar Shan wrote: > >> <...> > >> Joe Landman's comment about the complexity of programming FPGAs is >> fair, but >> there are a lot of good tools coming on the market which simplify the >> task. > > Furthermore, comparing the development of an FPGA-based processing > solution to *installation and configuration* of software solutions may > not be very fair. Developing scientific software tools is generally > hard too. I think possibly people have misinterpreted my comments on FPGAs and accelerators in general. I/we strongly support their use. Not as replacements for clusters, but as tools to significantly augment desktop and cluster level supercomputing in Life sciences and related fields. I hope this clarifies things :) On to the rest. > But my thinking is this: if the FPGAs (and support hardware like RAM) > are already there and the interconnects are there, then it stands to > reason that off-the-shelf cores would proliferate in strategic > application domains -- and the bioinformatics community would be the > first to benefit from the emergence of such a development and > distribution model... well, maybe second after the "black helicopter > brigade's" crypto departments ;-). Sort of ... > > These cores could then be downloaded and installed with minimal end- > user mucking around, and certainly almost NO hardware design. Take this > for example: > > http://wiki.ittc.ku.edu/rcblast/Download The issue is that you have some design work to do to interface the core to the rest of the board. Now if the boards were somehow standardized (cough cough) this would be a "good thing". [anyone want to talk about standard boards?] > Of course there's compatibility sludge to wade through right now... but > that's sortable. Actually it can be a bear. The Cray systems are really interesting (RapidArray). But how many folks out there have a system to plug a RapidArray board into? So if you do a core design for the units there, are you out of luck in migrating to a different board? At the moment, it looks like you can take the core portion out and move it about (VHDL). But the interface logic and the synthesis can be ... a challenge ... Especially if your code depends upon huge memory bandwidths, and you get that subtly wrong. > > Hypothesis: FPGA core == "a different kind of software, for a different > kind of computer". Yes!!! (e.g. we strongly agree with this concept). It is a bit file in binary form, and VHDL/Verilog in source form. Its the hooks into the rest of the system that is the challenge. > Comments? [Should probably be sent off-list since this is stretching > the mandate of Bioclusters.] I would argue the opposite, that bioclusters is all about providing scalable platforms for bio-computing tasks, and that acceleration systems, as people need them require a platform to host them. What better platform for a bio-accelerator than a bio-cluster ? (note: Cray folks might suggest that the XD1 is the appropriate platform, though we are trying to be marketing neutral). Seems to be a natural extension to me. Especially if the user-facing software is made to work well with the FPGA facing bit file (bit-ware? FPGA-ware?). If you don't need high performance, you probably aren't interested in bioclusters anyway, or are focused upon more narrow stretches of the HPC computing universe. A caveat is that open-sourcing a commercially developed system may be hard given the inherent lack of ability to recover the cost of market entry: the tools, the boards are not cheap by any stretch of the imagination. Academic shops with agreement from the relevant tech transfer folks (at least in the US) may be able to release VHDL/Verilog and bitfiles, though end users need to be prepared for a somewhat different market than the pure open source they may be used to with other tools. Just a caution... pure software cost of entry is cheap, anyone with a cheap PC can develop apps. FPGAs are a different beast (at the moment). The cost of tools/parts/boards are high, and worse, there is no "standard" board design. There are lots of designs. This is good and bad, but that discussion is best left off-list. Joe > > -tirath > > >> We have a few bioinformatics customers that are building FPGA >> implementations of their own algorithms with good success. >> >> Cheers, >> >> Amar >> >> --------------- >> Amar Shan >> >> t. 604-484-2253 >> f. 604-484-2221 >> >> -----Original Message----- >> From: bioclusters-bounces+shan=octigabay.com at bioinformatics.org >> [mailto:bioclusters-bounces+shan=octigabay.com at bioinformatics.org] On >> Behalf >> Of George Magklaras >> Sent: Saturday, February 11, 2006 3:31 AM >> To: Clustering, compute farming & distributed computing in life science >> informatics >> Subject: Re: [Bioclusters] FPGA in bioinformatics clusters (again?) >> >> The Linux Journal issue 142 (February 2006) talks about FPGA's in an >> article with title 'Heterogeneous Processing: a Strategy for Augmenting >> Moore's Law', written by a chap from Cray. Apart from the ehmm indirect >> XD1 product marketing, the article makes the case for FPGA's outlining >> alternative approaches to traditional commodity HPC clusters, as well as >> the obstacles of turning scalar proc code to FPGA code. >> >> Best Regards, >> GM >> >> -- >> -- >> George B. Magklaras >> >> Senior Computer Systems Engineer/UNIX Systems Administrator >> The Biotechnology Centre of Oslo, >> University of Oslo >> http://www.biotek.uio.no/ >> >> EMBnet Norway: http://www.biotek.uio.no/EMBNET/ >> >> >> >> >> Farul Mohd. Ghazali wrote: >>> Some years back when Timelogic and Paracel were popular there were >>> some discussions on FPGA based computing for Linux clusters. I can't >>> recall if there was a general conclusion but one of the limitations >>> was that you're stuck with the algorithms the manufacturer provided. >>> >>> SGI approached me recently to talk about their reconfigurable FPGA >>> systems and I was intrigued. The new RASC allows a user to remap the >>> FPGA according to your own algorithms instead of being limited to one >>> set of libraries. They also link it with GNU tools for debugging etc. >>> >>> Has anyone looked at the SGI RASC or any other equivalent system out >>> there? Any ideas if it makes sense in today's clusters? The workload >>> I'm supporting has very few custom written algorithms and is mostly >>> BLAST, phred/phrap, hmmer with some heavy Amber and Gromacs thrown in >>> as well. >>> >>> TIA. >>> _______________________________________________ >>> Bioclusters maillist - Bioclusters at bioinformatics.org >>> https://bioinformatics.org/mailman/listinfo/bioclusters >>> >> >> _______________________________________________ >> Bioclusters maillist - Bioclusters at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/bioclusters >> >> _______________________________________________ >> Bioclusters maillist - Bioclusters at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/bioclusters > > _______________________________________________ > Bioclusters maillist - Bioclusters at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/bioclusters -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics LLC, email: landman at scalableinformatics.com web : http://www.scalableinformatics.com phone: +1 734 786 8423 fax : +1 734 786 8452 or +1 866 888 3112 cell : +1 734 612 4615