Comment by Traster | Hacker News Reader

Comment by Traster | Hacker News Reader

Parent Full thread

What I find interesting about people who pick fights with FPGA programming is that they entirely focus on the things that FPGA doesn't do. If you can solve your problem on a CPU then it will practically never be better to do it on an FPGA. If you want to make FPGAs better, you need to figure out how to make what we already do on an FPGA easier.

I think part of the problem here for example is

>That is, Verilog is to an FPGA as an ISA is to a CPU.

No! Not at all! For a start I can literally write verilog that won't work on any FPGA ever

always @ (rising edge multiplier_result[8]) begin $print("This is nuts!") end

Verilog is not an FPGA language, Verilog is a hardware language that Vendors implement a subset of on any given FPGA.

Here would be my advice to someone who wants a better abstraction for FPGAs: stop relating them to other things that behave very differently. Timing is important, placement is important, mapping is important. If your abstraction doesn't include these elements it is fundamentally flawed.

I agree with the first part of your comment but you lost me there:

>Timing is important, placement is important, mapping is important.

It's true, but Verilog doesn't usually expose that. You let the tool figure out the placement, routing and do the timing analysis. If you want to mess with that by yourself you usually have to use tool-specific methods to partition your design and do partial routings for instance. I don't think you're arguing otherwise but then I'm not sure what you're getting at.

I don't directly do FPGA development myself but I do work with FPGA/ASIC developers (I do the software side of things) and boy I do not envy them. It makes me realize how lucky we are in the software world for GCC/LLVM and all the other open source tools we get to use. You don't have to use unstable, buggy, obscure programs that are effectively unusable for anything remotely advanced if you don't have a support contract with the vendor to help you figure out what to do when something is not working as intended.

The toolchain is indeed rubbish. One of the ironies of the world- while Software engineers tend not to understand how FPGAs actually work and which bits are important, the tools to compile for FPGAs are generally written by hardware engineers who don't know how to write good software tools.

You say that because you're not enlightened enough to find the abstract beauty behind 10k lines of spaghetti TCL script.

The part you quoted is a part of a thought experiment. The author is explicitly saying that Verilog is _not_ an ISA:

> By way of contradiction, let’s imagine what it would look like if RTL were playing each of these roles well.

The point of this section was to point out that the set of people who use FPGAs as accelerators (a la MSFT catapult) use it with the ISA abstraction: they don’t want to care about he timing, they just want to get the dataflow graph to accelerate the computation.

Disclaimer: I work with the author of the article on acceleration architectures and languages.

Regarding the end of the article:

A new category of hardware that beats FPGAs at their own game could bring with it a fresh abstraction hierarchy. The new software stack should dispense with FPGAs’ circuit emulation legacy and, with it, their RTL abstraction

Are you or the author working on something along these lines and if so can you give an example? I'll tell you the truth I was expecting a proposition and I felt kind of "robbed" when I reached the end and no alternative was given

Right but people who use FPGAs as accelerators a la MSFT catapult went to Altera and asked them specifically to write and ship RTL to enable them to do so. They use it with an ISA abstraction because they bought so many chips that Altera did a big chunk of the design work for them. That's a valid approach but I wouldn't say that's really doing FPGA design.

Reply on news.ycombinator.com