Slashdot Mirror
Star Bridge FPGA "HAL" More Than Just Hype
Gregus writes "Though mentioned or discussed in previous /. articles, many folks (myself included) presumed that the promises of Star Bridge Systems were hype or a hoax. Well the good folks at NASA Langley Research Center have been making significant progress with this thing. They have more info and videos on their site, beyond the press release and pictures posted here last year. So it's certainly not just hype (though $26M for the latest model is a bit beyond the $1,000 PC target)."
We started using FPGA's in our HPC designs where I work several years ago - the designs are faster, more reliable, and quicker to design. StarBridges graphical development environment is a lot like another product sold by Anapolis Micro called Corefire.
Corefire is a java based graphical (iconic)development environment for Xilinx FPGA's. It is like anything else though sometimes programming in VHDL will be a better choice, it depends on the complexity of the design and the desired end result. But all in all we probably saved at least 6 man-months of design time using Corefire.
I cannot remember the name of the project, but two years ago a Chinese group published a paper where they used a Xilinx fpga on a custom circuit plugged into a pc SDRAM slot. The idea was to limit the communication bottlenecks of other pc busses and also to present a simple way to communicate with the fpga. All in/output to/from the fpga was done with simple mmap() routines. Their test application was a DES code breaker that could run as fast as the the memory subsystem could take it. Exciting stuff. And it has to be said: I wish I had a Beowulf cluster with these.
I always get the shakes before a drop.
FPGAs are great for complex control logic in hardware. They can also be used for DSP functions. Using FPGAs for general purpose computing efficiently is difficult. You essentially start out with a 100:1 handicap against a commodity CPU (this comes from the amount of transitors per gate, using VHDL vs. custom design, and the way routing wires have to be universal). Programming such a beast becomes an exersize in finding huge amounts of parallelism that don't require memory accesses (FPGAs have limited RAM on board, but don't expect much, and you have to share accross 100s of functions). Supposedly there are C to hardware complilers out there, but I can't see Joe Software designer chugging out code that carefully checks to see how every line affects the clock rate (remember that: in software you have 10% of the code executed 90% of the time, in harware you have 100% of the code executed 100% of the time. The FPGA can only clock as fast as the slowest path). The economics are probably the worst problem. These sort of things are most likely to go into government or military instalations where the contract says hardware has to do (impossible thing), and be maintained for x years. The device gets made, the customer changes the requirements, spin repeat until it ships as an expensive system that a simple desktop could do by shipdate. If you build a beowulf to do something, with a little forsight you can turn around in two years and double the power. With an FPGA design, you may be able to buy an off-the-shelf board that has advanced (if the company is still in buisness, not guarenteed), but then you have to dig into the source and modify for the new chips. This gets expensive fast.