Slashdot Mirror
Low-cost Reconfigurable Computing (FPGA's)
Anonymous Coward writes: "People at the at Chinese University of Hong Kong have developed a reconfigurable computing card which uses the SDRAM memory slot instead of the PCI bus. Measurements in the paper show greatly improved bandwidth and latency - why aren't more people using this idea?"
Catalina Research offers a card line called the "Chameleon" based on Virtix-E series FPGAs. This allows the card to provide millions of reconfigurable system gates that the use can apply. Connected to the FPGAs are independent blocks of ZBT static RAM which can support a single read or write operation per cycle. The Chameleon products have three high-speed IO daughtercard sites compatible with the industry PMC standard.
Chameleon VME Block Diagram
the byproduct of years of oppression by the white man
http://danisaacs.com/temp/fccm01_pilchard.pdf
Be gentle. And mirror and post mirrors, please. Bandwith costs, and I'm poor.
- Dan I.
This may help a little, but in general, people haven't figured out how to make FPGA-based computing sufficiently useful, cheap, and easy in order for it to catch on. Programming an FPGA is still rather hard and the architecture limits severely what you can do. And there is the chicken-and-egg problem with the boards: if you write software for them, few people can run it, and few people are motivated to buy a board because there is no software that uses it. Right now, you are probably a lot better off buying a dual processor board or a cluster than an FPGA add-on.
Here is a PDF version
Top Most Bizarre/Disturbing Error Messages
Here is a PDF version Download all you want - I'm not metered (but its also only 384kbps :) )
Top Most Bizarre/Disturbing Error Messages
I have also wondered why more people aren't using the memory bus for peripherals....Seriously, the PCI buss can only offer so much (132 MB/S) which is certainly going to be a problem with anything faster than gigabit ethernet
Because the memory bus is a memory bus, and NOT a peripheral bus! Peripheral busses have things like interrupts, address space configuration, buffering, bridging, hot-plugging, and long-term stability that memory busses are simply not designed for.
How would you like it if you couldn't use the latest whizz bang 8.4GB/s memory technology because some peripheral you bought a year earlier needs to be on a 4.8GB/s memory interface?
Anyway, PCI v2.2 (?) offers 512MB/s in 64 bit 66MHz mode. And then there's PCI-X...
And show me a game that is PCI/AGP bandwidth limited once textures are uploaded to the GXF card anyway. Memory is cheap, use it...
Meanwhile, modern memory busses are upwards of 4.8Gb/s. Imagine multiple machines strung together with that kind of bandwidth between them!
Unfortunately, those pesky laws of physics (like the speed of light) come in and put paid to schemes like this. While it may be possible to get that bandwidth between machines, the latency becomes a problem. Certainly not feasable as a memory bus.
The mpeg audio layer uses different transforms than the video layer. Even the mpeg decoder cards often have software audio decode (which usually isn't mpeg audio anyway, but AC-3).
I believe that some cards from Phillips claimed MP3 acceleration, and there is no reason why the Soundblaster Live chipset couldn't be programmed to do the same. (Phillips, iirc, doesn't support linux, btw)
On FPGAs as PC Coprocessors, redux:
http://www.fpgacpu.org/log/aug01.html#010811
On FPGAs as PC Coprocessors (1996):s sors.html
http://www.fpgacpu.org/usenet/fpgas_as_pc_coproce
> modern processors are well-adapted to general computing tasks.
Rather, "modern processors are well-adapted to general *serial* computing tasks." If you have a computation with an embarrassing amount of low-level parallelism (e.g. applying a filter to an image), you can either hope that streaming SIMD will come to your rescue, or you can burn an FPGA with an embarrassing number of parallel computation paths that implements the desired function. The FPGA would already win in many real-world computations, were it not for the fact that it's limited by the cost of getting the data on and off the chip over a slow data bus.
Been there, done that. Most PCs prior to the 386 models used the ISA bus for both peripherals and memory. The buses where separated out in modern PCs for a reason: the laws of physics. At today's speeds, a memory bus can't be more than an inch or two in length. If you use your one free memory slot for I/O, you have no more memory expansion capability.
"Chinese" in the name "Chinese University of
Hong Kong" refers to "Chinese language" (which
is obvious from the Chinese name of the
university), so politics are irrelevant.
A DSP is just a very specialized CPU, primarily focusing on math intesive stuff, but less on branching and conditionals.
As any CPU they are sequential devices. The load a instruction, decode it and execute it and repeat. Though modern DSP can paralellize many intructions it's resources are still statically allocated at the time of design. A DSP with two multipliers may at most perform two multiplications at any one time.
Using a fpga on the other hand allows you to design the circuit from the ground up. now if your algorithm needs to do 20 multiplications at a time, you can do so simply by building them on the device.
Using a fpga is fundamentally different from using a DSP or microcontroller/processor. The latter is a finished circuit with an assorment of operators selectable by an instruction opcode. The former can be configured into any circuit.
Comment 1 RE:Linked directly to Postscript?
Try using ghostscript/GSView which will display the postscript file directly. (A quick search on Google gave the following link which should be useful
GhostScript
Comment 2: I don't think this is ever really likely to be part of 'consumer' system. FPGA's are great for
1) prototyping circuits that will later be implemented as an ASIC where the cost of "respinning" a chip is extremely high or
2) Situations where the system is only produced in very small numbers.
The main problems with FPGAs are that they are
1)Expensive!.
2) Relatively small in terms of the gates they can implement and
3) The clock speed that can be achieved is probably about an order of magnitude lower than an equivalent ASIC.
For many situations a multi-CPU system may be a much better option, and I certainly think that they'd be impractical for a mass produced system.
Simon