5 ms·
Is there a possibility to use just-in-time compilers to port software to FPGAs? I can see how that could be used to accelerate applications written on bytecode
by TuringTest 12y ago
Is there a possibility to use just-in-time compilers to port software to FPGAs? I can see how that could be used to accelerate applications written on bytecode languages (i.e. mostly everything in your mobile phone) to near-assembly speeds.
- jbangert 12y agoporting regular software to FPGA's is certainly an interesting idea and many people have worked on it (google C to FPGA). Unfortunately, these solutions aren't quite what you would think, because the programming model of a microprocessor (serial execution of instructions) is very different from that of an FPGA (parallel evaluation of gates, non-uniform state access/routing -- you cannot just access any variable in Verilog anywhere, you have to make sure it is possible to efficiently lay out your algorithm on a 2D structure of gates). As for JIT-ing, compilation times for FPGAs are often in the hours, and the software involved is unfortunately proprietary (and not easily integrated with). There are some field-reconfiguration libraries, but I am not sure to what extent real-world applications compile new Verilog on the fly..
- diamondman 12y agoJust wanted to add that many FPGAs physically support updating parts of their configuration without turning off or stopping the rest of the chip. This is just very hard to do without the docs we need of the chips, and almost no one does it.
- kyboren 12y ago> ... almost no one does it. I've heard an anecdote that Altera kept getting pestered by customers asking why they don't have it--"but why not? Xilinx has it!". So they implemented it just so they could say, "We have it too!". It shut them up, and since no non-academics actually use PR (that I'm aware of; I'd love to hear counterexamples), they've promptly ignored it again :).
- kyboren 12y agoWhat jbangert said is the crux of the JITing problem: "compilation" for FPGAs is not really at all like compiling software, and can be hugely computationally expensive. On top of that, pretty much the entire synthesis, mapping, and place and route flow is usually proprietary. That said, there have been some efforts in this direction. Search the literature for "warp processing".
- diamondman 12y agoAs kyboren says fpga compiling is crazy intensive. This is because we are mapping physical resources and things have to physically fit instead of just being able to arbitrarily jump somewhere else in the program. It becomes a huge constraint satisfaction problem, there is no 'correct' answer, and many times FPGA compilers will produce different results when run multiple times because they often use randomness to start the process if there are too many options.
- TuringTest 12y agoBack in the day I learned about using VHDL to design circuits, is that the kind of compilation also used for FPGAs? That language paradigm is close to modern dataflow oriented programming languages. It should be theoretically possible to compile an application program written in that style and have the logical circuits in the FPGA be a direct mapping of the business logic in the application.
- kyboren 12y ago> Back in the day I learned about using VHDL to design circuits, is that the kind of compilation also used for FPGAs? FPGAs can implement any digital circuit which fits, with some caveats. So yes, VHDL is commonly used to describe designs for FPGAs. I'm not sure what you mean by '[that] kind of compilation', though, as you never specify what kind of compilation you mean. Implementing a circuit on an FPGA involves many of the same, or similar, steps and processes as implementing it on an ASIC (and obviously, does not involve all the physical design stuff). If that's what you're asking. > That language paradigm is close to modern dataflow oriented programming languages. It should be theoretically possible to compile an application program written in that style and have the logical circuits in the FPGA be a direct mapping of the business logic in the application. Sure, of course it's theoretically possible; there's nothing you can do in digital logic you cannot do on a UTM (space/memory constraints aside), and vice-versa. This field is known as "High-Level Synthesis", and it's been around for decades. It's only now becoming sort-of widely used for real-world stuff. But it's nothing like "directly translating" to logic for the FPGA ;). It's probably easier for most programmers to design in such a language vs. an HDL, but AFAIK that's not even close to the biggest challenge with doing HLS. I think timing and resource allocation are much bigger problems (but I'm not very informed about HLS!). Look through the HLS literature if you're interested in what's involved--I'm not an expert by any means. Also, if you're interested in alternative programming languages for hardware design, check out BlueSpec and Chisel.