<DIV>Mark, John, and Val,  Thank you all for your perspectives. I couldnt have asked for any thing better. I am sure one day (soon enough) there will be a happy family of EEs, CSs and Bioinformatics all on the same page. Compared to you guys, I am a novice both in Hardware design and the Bio side. It was just great to get all these persepctives from insiders. And I thank you all for it. But for what it is worth, here is my take on it.</DIV>
<DIV> </DIV>
<DIV>Clusters seems to be the buzz word in the Bioinformatics world these days. They want to build bigger and better clusters. And I dont blame them. There is a huge loads of data that need to be processed in these massive parallel implementations. Here is probably the cost involved in these clusters:</DIV>
<DIV> </DIV>
<DIV>1) Each Node ~ $600 </DIV>
<DIV>2) Bottlenecks, Overhead relating to the parallel implementation</DIV>
<DIV> </DIV>
<DIV>This almost is analogous to using Brute force using multi purpose processors, and parallel implementations and all this with huge cost. I am sure there can be a better solution to all this. John mentioned Biochips, that sure would be nice but it certainly wont be a reality until a decade from now ( ignorant guess, please pardon me). With the current status quo sticking to computational processors, one of the alternatives could be Taaddaaa FPGA!!!!</DIV>
<DIV> </DIV>
<DIV>FPGAs as Hardware Accelerators:</DIV>
<DIV>1) Run Time Reconfigurable(RTR)</DIV>
<DIV>2) High Density Devices that can implement highly parallel implemenations</DIV>
<DIV> </DIV>
<DIV>There will be a huge cost/performance difference between clusters and array of FPGAs.</DIV>
<DIV>Computatations like Viterbi Decoding, Forward & Backward algorithms, and Log odd scores all of these can be very efficiently implemeted on FPGA because of the Look up Table architecture of FPGAs. Thats just the beginning. And these devices are run time reconfigurable. So I can have the Processing Engines ( PEs) which I call fixed logic which work on the data ( HMM profiles) which I call the Reconfigurable Logic(RC). These PEs will be working on the RC data, and I can independently re configure just the RC to load new data ( next HMM profile ) using RTR and ofcourse this is just one PE and RC. and depending on the size of the FPGA device used I can have more than one PE and RC all working in parallel. </DIV>
<DIV> </DIV>
<DIV>Having said that, the trick is to make sure that the PEs are always busy, and the reconfiguration delay, and the computing cost involved in the host processor, all justfy the Cost/Performance parameter. And since everything is generated on the fly, there has to be an optimal way of scheduling reconfiguration. And that can be hard as well.</DIV>
<DIV>And ofcourse this eliminates the need for dedicated memory ON/OFF chip, at the cost of the reconfiguration delay. Key to all this is Cost/Performance factor. </DIV>
<DIV> </DIV>
<DIV>Please feel free to throw in your comments,suggestions & questions. I sure would like to know if there any issues that you see with the route I am taking. I hope to have a website soon where I can post my progress. </DIV>
<DIV><STRONG><EM></EM></STRONG> </DIV>
<DIV><STRONG><EM>Thanks again ,</EM></STRONG></DIV>
<DIV><STRONG><EM>Venu</EM></STRONG></DIV>
<DIV><B><I>val <val@vtek.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi John/All:<BR>Thanx John for an interesting and refreshing post.<BR>Your points sound very reasonable to me, although this is a<BR>CS/cpu side of the story. What about other side, biochip side,<BR>a direction which might be taken more comfortable than<BR>HW accelerators. In other words, a computational acceleration<BR>seems to be a good thing, but this is just a fragment of the<BR>whole cell analysis *pipeline*.<BR>Indeed, a final goal of bioinformatics and generally in-silico<BR>cell analysis is to understand cell mechanisms/processes<BR>and then based on that proceeed to drug design/discovery activities.<BR>From that perspective, further evolution and advancements in biochip<BR>design and functionality would be a step in right direction.<BR>And i mean silicon functionality, when talking about biochips,<BR>and related data. Silicon designed for (floating point)<BR>computing
 ,
 including multiprocessor and cluster options, is still<BR>very much silicon designed ~50 years ago and having little to do<BR>with cell mechanisms analysis, understanding its result and then<BR>using it for biomedical applications.<BR>So when designing silicon functionality, why don't start right<BR>from using silicon to implement a whole cell analysis pipeline?<BR>Silicon - but not just a computational one, rather a *biotechnology*<BR>(bt) silicon. That is, silicon directly interfaced electrically<BR>with cells (in culture, 'a real sample'). The interface would<BR>include an *input plane" (sensor plane) and an "output plane"<BR>(driving plane). And a recognition and storage logic in-between.<BR>This is indeed a quite known "system/lab-on-the-chip" approach, with<BR>the lab directly interfaced with a sample, including<BR>(on the following phases) electrical driving facilities designed<BR>to move and/or immobilize cells, perform transfection,<BR>electroporation and other cell
 modification operations.<BR>Of course, such an active biochip would be a massively<BR>parallel processor, and can be called a biotechnology (bt)processor<BR>(vs. computational processor) since it directly implements<BR>a programmable cell analysis technology pipeline - input, processing<BR>and modification. Optical fluorescent binding patterns can also<BR>be measured with such a chip. Its obvious advantage is that dynamic<BR>analysis in time can be performed on the same chip, say, yeast life cycle<BR>dynamics with a fine time resolution (say, seconds and less instead of<BR>minutes).<BR>What seems to be a really good news is that such a silicon can and needs<BR>to be designed as an *array*, a massively parallel, fine-grain architecture<BR>with a relatively simple microcell (vs. spagetti-like x86s). If the total<BR>number of transistors on<BR>the "lab-on-the-chip" is ~10B (which is what possible now), a grain<BR>(microprocessor) in the mega-array (1000x1000 microprocessors) ma
 y have
 up<BR>to<BR>10K transistors which is quite enough to implement the basic input/output<BR>and<BR>processing functionality at a grain level. For a ~1 sq.in. chip, a grain<BR>would be of 250 um size. The input plane of a grain might have up to 32x32<BR>sensors, so that linear spatial resolution for cell analysis would be ~8 um<BR>which is Ok for mid-size and large cells (on average, an animal cell size is<BR>~10um).<BR>So, i guess my point is that it does not make a lot of sense to<BR>accelerate,<BR>optimize, etc a fragment of the pipeline without looking at an integrated<BR>cell/tissue analysis pipeline - how/where silicon functionality can be<BR>applied.<BR>cheers,<BR>val<BR><BR>----- Original Message -----<BR>From: John Jakson<BR>To: bio_bulletin_board@bioinformatics.org<BR>Sent: Sunday, September 14, 2003 3:00 AM<BR>Subject: Re: [BiO BB] Implementing HMM models in Hardware (FPGA)<BR><BR><BR>Hi Venu<BR>Interesting to see others interested in applying FPGAs to
 Bioinformatics.<BR>FPGAs don't get much mention here.<BR>I am not convinced the Bio industry really cares for EE solutions it doesn't<BR>understand. Linux clusters are bad enough but what the hell are FPGAs. As an<BR>EE VLSI/FPGA hardhat visitor at the BioWorld show, held here in Boston not<BR>that long ago all I saw was disinterest and plenty of tower server racks.<BR>Not one HW company showed up with anything but Linux clusters or the<BR>SGI/IBM/HP/... equivalent. TimeLogic & the 1 or 2 other (defunct ?)<BR>accelerator companies were noshow. On talking with the floor folks I found<BR>no interest or basic understanding of possible HW alternatives.<BR>The issue comes down to how the problem is stated and how it can be<BR>implemented in a solution that most Bio SW types can understand. That means<BR>whatever the engine is, it must just run C code, simple as that, preferably<BR>the free stuff from NCBI. That always leads to the same solution, clusters<BR>of ever faster &am
 p; ever
 hotter farms of todays x86. Any rational computer<BR>scientist knows this is crazy, and that dedicated HW should be built.<BR>TimeLogic says it very well on their web site. In crypto, video or DSP<BR>processing, it is relatively easy to turn C code into HW since they are all<BR>math intensive and are likely created by the same EEs.<BR>It may come as a surprise to SW types but HW is routinely modeled in C, but<BR>that code is used only to double check the design written in a decent HW<BR>description languages like Verilog or VHDL both of which are implicitly<BR>parallel languages. There is usually some formal mathematical model often<BR>written in Matlab for the real heavy stuff. Its also interesting that the<BR>Matlab code usually floating point intensive & the final ASIC/FPGA solutions<BR>are not expected to produce identical results since HW is best built integer<BR>fashion. One might regard the current Bio C codes as just simulations of HW<BR>that hasn't been built ye
 t since
 few know how to recode them in HW language.<BR>TimeLogic did a few but not in a way that can be easily duplicated across<BR>the industry.<BR>To turn C code into really fast HW requires understanding what the C code is<BR>really doing and having permission to make subtle but harmless changes to it<BR>to allow the really big speed ups. That means eliminating floating point. If<BR>the Bio author of such SW is also a HW expert (of which there are probably<BR>only a handfull or even 0 in the whole world) then equivalent algorithms<BR>could be used that are relatively simply to map onto HW structures. I don't<BR>see the Bio world hiring too many HW EEs either, we are far too different<BR>culturally and we usually don't have Phds, esp not from the right schools.<BR>There are other ways to turn C code into HW, maybe use a C based HW language<BR>such as HandelC which is based on Occam & CSP. And there's the clue. If the<BR>SW is broken up into the constituent parallel processes t
 hat are
 naturally<BR>there but impossible to describe in plain C, then it becomes almost trivial<BR>to map those parallel processes onto FPGA fabric or even something like a<BR>Transputer farm. The only difference is the granularity. FPGAs are hot today<BR>but can only readily be engineered by HW types because their most efficient<BR>use requires detailed understanding of pipelines and combinatorial logic and<BR>basic cpu design. Transputers if they still existed would be the natural way<BR>to go because they are ameniable to both SW & HW engineers but they still<BR>worked best when SW & HW were both understood. Occam was just a way to<BR>describe parallel processes that decribed HW in a funny syntax. Transputers<BR>only died out because the implementation fell far behind x86 performa nce<BR>and was single sourced & underfunded. Most Transputer projects & users<BR>ultimately switched to standard DSPs & FPGA leaving the SW user base behind.<BR>Another approach wou
 ld be to
 use one of the cpu farms on a chip such as<BR>Clearspeed or PicoChip or BOPs (RIP) who have developed risc cpus that can<BR>be upto 420 instances on a chip running at 100MHz plus. Interesting to see<BR>if those devices can escape cell phone basestations.<BR>So I have taken my passive interest in this subject back to the drawing<BR>board to recreate a modern FPGA hosted Transputer that would naturally<BR>execute sequential C code, or parallel Occam code & even Verilog code. That<BR>means that if code can be partially migrated from seq C to par Occam style C<BR>(ie HandelC) then to Verilog ( a C'ish like HW language), the same code<BR>still runs on the same cpu (but a little slower perhaps). Extra process<BR>scheduling HW is needed to support very fine grained concurrency in a modern<BR>Transputer and also a logic simulator. The big pay off is that properly<BR>parallized code once in Verilog form still runs either as compiled source<BR>code on a farm of cpus using message 
 passing
 and links, or it can be<BR>synthesized with industry standard HW tools back onto the FPGA fabric for<BR>the desired speed ups. In effect, sequential procedures in C code can be<BR>morphed into on chip HW coproceesors using the reconfigurable features of<BR>many FPGAs. Stable FPGA coproc essor engines can then be turned into much<BR>faster and cheaper ASICs in return for nasty upfront NRE. Such solutions<BR>could go much farther than current TimeLogics products for many industries<BR>beside Bio.<BR>Xilinx & Intel can give us a clue here. A cluster cpu node based on a P4 at<BR>say 3GHz might run to $2K per node depending on whats there even though the<BR>fastest P4 chip is always say $600. An FPGA RISC cpu node based on<BR>MicroBlaze runs at maybe only 125MHz but will cost about $1.40 per node in<BR>volume plus extra support. Now if the cpu can be farmed by adding those<BR>Transputer extensions, the 24x clock difference doesn't looks so bad<BR>compared to the est 400+ fold
  cpu
 cost difference. Also a lot of slower cpus<BR>each with local RLDRAM don't have the memory latency that P4s suffer from ie<BR>1 DRAM cycle is a few cpu cycle instead of hundreds, and distributed<BR>bandwidth is much easier to manage.<BR>Its also interesting to see the changes at TimeLogic, the departure of Jim<BR>and the merger with a company that I see has no obvious HW background.<BR>Regards<BR>John Jakson<BR>sorry for long rant<BR><BR><BR>Do you Yahoo!?<BR>Yahoo! SiteBuilder - Free, easy-to-use web site design software<BR><BR>_______________________________________________<BR>BiO_Bulletin_Board maillist - BiO_Bulletin_Board@bioinformatics.org<BR>https://bioinformatics.org/mailman/listinfo/bio_bulletin_board</BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/evt=10469/*http://sitebuilder.yahoo.com">Yahoo! SiteBuilder</a> - Free, easy-to-use web site design software