Hacker News new | ask | show | jobs
by ohazi 1996 days ago
For decades, the FPGA vendors have had this fever dream of "an FPGA in every PC" -- either as an add-on card, or as part of the chipset on a motherboard -- that would enable a compiler or operating system to seamlessly accelerate arbitrary tasks on demand.

In my opinion, the problem has always been their software: the FPGA vendor tools are slow, bloated monstrosities. The core of these tools are written by the big three EDA vendors (Cadence, Synopsys, and Mentor Graphics) rather than the FPGA vendors themselves. The licenses include ridiculous, paranoid restrictions [1] and force the FPGA vendors to keep their bitstream formats and timing databases secret [2] in order to prevent competition from other tool vendors. Most FPGA vendors didn't see this as a problem, but even the ones that did didn't have much of a choice, because the tool market is a cartel.

Thankfully, we now have an open source toolchain [3] with support for a growing number of FPGA architectures [4], and using it vs. the vendor tools is like using gcc or llvm vs. a '90s era, non-compliant C++ compiler. It even has a real IR that isn't Verilog, which has made it easier to design new HDLs [5].

I don't see how a dynamic FPGA accelerator platform can be even remotely viable without this. It's the difference between a developer getting to choose between one of a few dozen pre-baked designs that lock up the entire FPGA (and needing to learn how to shovel data into it), vs. a compiler flag that can give you the option of unrolling any loop directly into any inactive region of FPGA fabric.

It would be quite the cherry on top to see AMD build something interesting in this space. But unless they're willing to fully unencumber at least this one design, I think the effort is likely to fail. The open source guys are chomping at the bit to make this work, and have been making real progress lately. Meanwhile, the EDA vendors have been making promises, failing, and throwing tantrums for the last 20 years. It's time to write them off.

[1] https://twitter.com/OlofKindgren/status/1052822081652617221?...

[2] Imagine trying to write an assembler without being allowed to see the manual that tells you how instructions are encoded. It's like that, but the state-space is hundreds to thousands of bytes in multiple configurations rather than a few dozen bits.

[3] https://github.com/YosysHQ/yosys

[4] https://symbiflow.github.io/

[5] https://github.com/m-labs/nmigen

2 comments

I would love to hack on FPGAs but always run into the issue of closed toolchains. The recent open source work is a breath of fresh air, but we need to see an FPGA vender that embraces and sponsors this work.
I think/hope it's an unstable equilibrium -- if either Altera/Intel or Xilinx/AMD give a nod to the open source tools, the others will follow.

Lattice is seemingly at "wink wink, nudge nudge" levels of support -- their lawyers won't allow them to say anything because they're afraid of pissing off Synopsys, but they also know that they're currently the best supported platform, and don't seem interested in deliberately making things difficult.

On paper at least it could be good idea for a company in lattice's position, at very least academics would probably switch.

I would like to see a FAANG try and support some open tools - it doesn't have to be anything legally sketchy like reverse engineering bitstreams - for example, Yosys only has limited SystemVerilog support

Going to plug my work on this here: https://github.com/MikePopoloski/slang

At some point I'd like to see it integrated as the frontend to tools like Yosys to get best-in-class SystemVerilog support in open tools.

Good luck
Symbiflow is still a long long way off replacing Vendor tools at scale, right?

I'm really liking Clash and Bluespec (Bluespec is completely open source now) but I don't want to write any conventional languages.

What does Bluespec compile to? All the way to a bitstream (surely not) or to Verilog or an intermediate language?
Firstly, (for the uninitiated) Bluspec is both a Haskell DSL (Bluespec Classic) and a Verilog-like language (Bluespec SystemVerilog)

It compiles to Verilog, but the stack is much more integrated than other similar compile-to-verilog HDLs - the simulator is similar to verilator and much easier to get started with.

I'm kind of beginning to feel that Haskell isn't a good medium for HDL code - Verilog already encourages unreadable names like "mem_chk_sig_state" and Haskell code is almost unstructured to my eye (I like functional programming but it seems hard to keep it readable because of the style it imposes - the flow is there but the names are usually way too short for my taste)

I'm pretty sure Bluespec and SpinalHDL compile to Verilog. Chisel uses it's own IR (FIRRTL). I think Migen used to target Verilog, but now targets (one of?) the IR(s) that Yosys supports (RTLIL?).