4 ms·
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
by ohazi 6y 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?s=20 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 https://github.com/YosysHQ/yosys
[4] https://symbiflow.github.io/ https://symbiflow.github.io/
[5] https://github.com/m-labs/nmigen https://github.com/m-labs/nmigen
- travis729 6y agoI 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.
- ohazi 6y agoI 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.
- mhh__ 6y agoOn 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
- mhh__ 6y agoSymbiflow 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.