Hacker News new | past | comments | ask | show | jobs | submit login
Reticle: Virtual Machine for Programming Modern FPGAs [pdf] (washington.edu)
56 points by ingve 43 days ago | hide | past | favorite | 8 comments

Does this avoid the vendor lock-in and proprietary tool nightmare?

No — there's no way to avoid the place and route phase for an FPGA, which is responsible for choosing where the components on the device that collectively implement your desired design are placed, and ensures they're wired together. Performing that task requires detailed knowledge of the silicon, and for high-end FPGAs that only can only be done by the proprietary tools the vendor provides. There are also many other tasks (e.g. timing analysis) that a tool like this wouldn't perform, which would also need the proprietary tools and silicon info anyway.

The goal of this project is to provide a better source language that various HDLs can target their compilers at. Currently, every toolchain de facto targets some subset of Verilog as its output language, and expects another tool (the synthesizer, also often proprietary) to map Verilog constructs directly onto silicon features, like multipliers — and those multipliers get fed to the place & route tools. This approach works, but it's generally brittle, because no two Verilog compilers behave exactly the same (among other reasons) so the contortions needed to map constructs reliably tends to require a lot of trial and error and weird rituals.

Hopefully some day SymbiFlow will become usable for most FPGAs:


For the most part, it looks like it. I don't see how you're being more productive though.

Is this a better way to transition from GPU to FPGA than the OpenCL tool chains available for FPGA?

Avoid OpenCL. If you're going to the trouble to use an FPGA, it means you really want performance. In that case, there's no avoiding the rewrite in VHDL/Verilog and specifically targeting the resources that your FPGA hardware offers and rewriting your algorithms accordingly. The platforms are not the same.

e.g. 32-bit floating point is what GPUs are made for, while FPGAs really only handle integers unless you've purchased an expensive one with specialized arithmetic units on chip (e.g. DSP48 slice for Xilinx).

How much like an FPGA would it be to use DRAM for the lookup tables, and very basic CPU for routing?

If you are fabricating that inside the FPGA then there is no mythical creature to stop you doing it but the power usage and achievable clock speeds might not be very impressive.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact