Comment by preview | Hacker News Reader

Comment by preview | Hacker News Reader

I don't think having a standard processor coupled with programmable gates is a new idea. The key is in making it simple to use. A basic adder or multiplier is a well known piece of logic and would be included in a standard FPGA component library. Will arbitrary custom instructions require an engineer to develop the FPGA macro? Having a software and a hardware engineer working together to optimize execution time does not seem new to me. Is the simplification in the interface between the processor and FPGA gates?

They must have done some research into min and max gates required to implement logic for custom instructions across the targeted problem domains. An important question is the time required to reconfigure the FPGA gates. Multiple FPGA tiles will be needed since it'd take longer to reconfigure the FPGA gates then to jump to a new branch of code that had its own custom instruction. This may require a customization to the compiler as time to reconfigure FPGA gates may need to be taken into account in the order of execution (not a new problem; just another variable to take into account).

It could be very interesting, but more technical details are needed.

It doesn't seem like FPGA reprogramming time will be an issue. Presumably, they will work on one problem at a time. They will have a custom instruction to calculate Pi and let the machine run for a few months and then switch to crunching data from seismic oil well probes.

Modern FPGAs can be reprogrammed in a few milliseconds, which seems like a long time in the computer world. In essence megabytes of SRAM need to be written to in order to configure an FPGA.

Also, FPGAs have the ability to do partial reconfiguration, but the support is spotty. In the ideal world, parts of an FPGA would be reconfigured while the other parts were still in operation.

The issue I was thinking of is if you needed multiple "custom instructions" within a loop. Another related issue, if multiple tiles are considered, is the interconnect between the processor core and the tiles. Interconnect is expensive, so there's a trade off to be made. Profiling data showing a curve of unique accelerator functions for the targeted problem domains and their temporal relationship (e.g. there may be ten accelerator functions but they are executed several milliseconds apart or functions A and B tend to appear in an inner loop together) would help make the trade off.

http://www.copacobana.org/gallery.html

...and all other areas of data processing, where stuff needs to be done fast [and within a pure R&D environment, where the only constant thing is change].

Reply on news.ycombinator.com