Live data from Hacker News

The History, Status, and Future of FPGAs

queue.acm.org

101–110 of 161 posts

Re: The History, Status, and Future of FPGAs

#101
post #88

Earlier quoted context omitted.

> cannot take a bitstream compiled for one FPGA and program it to any other FPGA. Like considering dumping memory content on a PC and reinject it on another with different RAM layout and devices and complaining the OS and programs can't continue running? Is that a sane expectation? There are upstream formats targeting FPGAs that can be shared, although yes redoing place and route is slow. Should manufacturers provide…

> Like considering dumping memory content on a PC and reinject it on another with different RAM layout and devices and complaining the OS and programs can't continue running? Is that a sane expectation? Even worse; it's more like that plus extracting the raw microarchitectural state of a CPU, serializing it in a somewhat arbitrary way, trying to shove that blob into a different CPU and still expecting everything to c…

> Can you show me an example? I'd like to see this. You do not mean FPGA overlays, correct?

Some of the coolest work to come out of the Chisel project is their intermediate representation FIRRTL.

Re: The History, Status, and Future of FPGAs

#102
post #30

Earlier quoted context omitted.

GPUs work great for accelerating many applications, and it's true that that reduces interest in FPGAs. For applications that map well to GPUs, you're absolutely correct that the higher clock speeds (and greater effective logic area) make GPUs superior as accelerators. However, some applications do not map well to GPUs. Particularly those applications with a great deal of bit-level parallelism can achieve enormous spe…

Very much this. (Also, in general, FPGA tools are just some of the lowest quality garbage out there... and that is saying something. They're that bad . This is a completely unnecessary speedbump.) The rebuttal to your objection is always tools like "HLS" (High-Level Synthesis), or in English it's "C to HDL" (FPGAs are 'programmed' in the two Hardware Definition Languages VHDL (bad) or Verilog (worse, but manageable i…

The biggest problem with HLS is that the HLS vendors still want to pretend it's "C++ / OpenCL / whatever to gates". What you get is pretending that there is no such concept of a clock even though you know it is always there and you care about it, and the language you are really writing consists mostly of all the crazy pragmas that you have to sprinkle over everything. It ends up failing on both counts: it isn't C++ to gates, and it is an exceedingly difficult HDL to use because it tries to hide the clock from you always even when you really need to do something with it (e.g., a handshake).

A weak spot of high-end commercial HLS tools (Catapult, Stratus) is in interfacing with the rest of the hardware world, and how the clock is handled (SystemC, you handle it yourself) or kind of vaguely (Catapult's ac_channel). Getting HLS to deal with pipeline scheduling is great, but sometimes you want to break through and do something with the clock. Want to write a memory DMA in HLS? Talk AXI? Build a NoC in HLS? Build even something like a CPU in HLS? Interface with "legacy" RTL blocks, whether combinational or straight pipeline or with ready/valid interfaces or whatever? These things are sort of/just feasible at present with these commercial HLS tools, but very very hard (I've tried it).

If they want to stick with it, I think C++11 could provide a superior type-safe metaprogramming facility for building hardware (compared to the extremely primitive metaprogramming and lack of type safety notions in SystemVerilog) or generators such as Chisel or the hand-written Perl/Python/TCL/whatever ones in use at most companies, but sometimes you need to break down and do something with the clock or interface with things that care about a clock, much in the same way that one would put inline asm statements in code. I want to do that, but not have to deal with the clock 95% of the time when I don't really need to, which is where the generators fail (let the tool determine the schedule most of the time). HLS needs to sit between the two: not a generator (glorified RTL), but not "pretend you write untimed C++ all the time" (not hardware at all).

Re: The History, Status, and Future of FPGAs

#103
post #89

Earlier quoted context omitted.

I mean, the problem is that in the FPGA world the tooling and synthesis languages are inextricably linked. HLS is an approach that, IMO, is also the completely wrong direction since a general purpose programming language like C/C++ won't map nicely to the constructs you need in FPGA design. What we really need is a lightweight, open source toolchain for FPGAs and one or more "higher level" synthesis languages. I've a…

> I've always wondered if a DSL using a higher language like Python isn't a better way to do this Like this? http://www.myhdl.org/

nMigen for python is where it's at these days.

https://github.com/m-labs/nmigen

Re: The History, Status, and Future of FPGAs

#104

Earlier quoted context omitted.

> You ever work with an FPGA? The programming model and the tooling are a huge part of the problem. I'd argue FPGAs aren't programmed and don't have a programming model. Complaints that the programming model of FPGAs holds their adoption back are thus conceptually ill-founded. (The tooling still sucks).

I mean, the problem is that in the FPGA world the tooling and synthesis languages are inextricably linked. HLS is an approach that, IMO, is also the completely wrong direction since a general purpose programming language like C/C++ won't map nicely to the constructs you need in FPGA design. What we really need is a lightweight, open source toolchain for FPGAs and one or more "higher level" synthesis languages. I've a…

> What we really need is a lightweight, open source toolchain for FPGAs and one or more "higher level" synthesis languages.

nMigen: python based DSL to verilog translator

LiteX: Open source gateware

SymbiFlow: Open source verilog compiler + PnR tooling.

There a linux kernel running on liteX and a Risc V core running on an ECP5 running out on the internets.

A micropython version running on a risc V core and migen (earlier version of nMigen) can also be found here: https://fupy.github.io/

Re: The History, Status, and Future of FPGAs

#105
The thing with FPGA is that companies when faced with cash and time crunch will opt to use a FPGA instead of designing ASICs. The tools suck but companies will hire someone that will do it. FPGA fit a very particular constraint and still solves very specific problems efficiently

Re: The History, Status, and Future of FPGAs

#106

Earlier quoted context omitted.

See it's funny, I (software guy) have recently started doing a bunch of FPGA stuff on the side for "fun" and I find the programming model to not be the biggest challenge. The tools, yes, because it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs with half the features that us software developers have, and with a crapload of vendor lock-in... but I digress. I find working…

I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't: > it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In partic…

Please then explain why is still no standardized synthesizable subset for verilog yet? Even C/C++ at its worst was never this absurd.

Re: The History, Status, and Future of FPGAs

#108

Earlier quoted context omitted.

See it's funny, I (software guy) have recently started doing a bunch of FPGA stuff on the side for "fun" and I find the programming model to not be the biggest challenge. The tools, yes, because it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs with half the features that us software developers have, and with a crapload of vendor lock-in... but I digress. I find working…

I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't: > it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In partic…

Vivado ships all kinds of "IP" for those things, yes. And once you get past the GUI wizards, drag and drop boxes and lines, and Tcl scripts you find in the end it's just a library of Verilog, all mangled to the point of illegibility.

I wasn't talking about open sourcing. I accept we won't have open source DRAM controllers and the like from them. I understand the licensing restrictions. I just don't like how they force all this stuff to be gatewayed through their baroque and over complicated GUI tools.

I prefer tools that are scriptable, that can work with the build system of my choice, that work properly with source control (imagine that!), where you have your choice of editor rather than having their garbage one rammed down your throat, where there's wizbang features like reformatting and auto-indentation... Hell, even refactoring.

Vivado and Quartus just get in the way. There's no reason to tie all the stuff you're talking about into an integrated tool. They could just ship libraries.

Fusesoc does in fact try to make them behave this way. But you can tell it's a bit of a war to make it happen.

Re: The History, Status, and Future of FPGAs

#109
post #51

Earlier quoted context omitted.

Are these mature already? It took some time for KiCad to get to current usable state and I don’t want to be early adopter. In fact, I want to have my private hardware MVP next year with current tools. On the other hand I can’t imagine my slacker colleagues using anything else than Vivado. Learning Vivado for them was already mission impossible.

I wouldn't say KiCad is usable yet. I've made multiple attempts to use it and it just is fundamentally user hostile. Unfortunately the devs see any attempt to improve user friendliness as "dumbing down". Fortunately there is (finally!) an open source PCB design program that doesn't suck: Horizon EDA. I've only made one PCB with it but honestly it was pretty great and the author fixed every usability bug I reported in…

What have you found wrong with KiCad?

I've only recently starting designing PCBs and I started with KiCad, but I've found it to be very easy to use after watching one video of someone going through a simple board design.

Re: The History, Status, and Future of FPGAs

#110
post #34

Earlier quoted context omitted.

There is another traditional FPGA use case where you need real time data capture or signal generation. That seems to be getting eaten from the bottom now that there are really high speed MCUs that are easier to program. It's less efficient, but easier to develop for.

The other problem with using an FPGA here is that microcontrollers are cheap and have great cheap dev boards. FPGAs, not so much. I've wanted to just "drop in" a small FPGA in several designs, the way you can drop in a microcontroller, but there's no available FPGA that's not a massive headache in that use case. Trust me, I've looked. The iCE40 series is almost there but not quite. It's a bit pricey (this is sometime…

In my last project, I just big-banged a port to load up the configuration bits in a 4K iCE40, something like 131KBytes; this was just a .h file that was included in the bit-banger; the static array ended up in Flash (the ST MPU had 2 MB flash, so no problem), and it only took a second or so to load the FPGA bits before it was ready-to-go. So, from my perspective, what you describe is already here. If even that's too much trouble, there's always TinyFPGA BX https://tinyfpga.com/ You can use the open source yosys or you can use Synplify and the Lattice dev system, which is free w/free license.
Post reply on HN