Hacker News new | ask | show | jobs
by kbeckmann 3873 days ago
How come? I guess it would be quite fun if you could write your algorithm with well-defined input/output in a high level language and generate HDL out of it. Let's say you just want to crunch numbers. Today you can use CUDA for that task, but what if you just use a subset of the CUDA features, maybe the compiler might use the gates in the FPGA more efficiently compared with the already defined GPU.
4 comments

Computational model. C/CUDA have an imperative view of the world which is really hard to boil into hardware. Functional approaches are a much better idea.

The compilation from the imperative world to digital logic is typically pretty opaque. What ends up happening is that the compiler ends up generating shitty hardware, and either you do or don't have a mental model of the hardware you actually want. If you have the mental model, you end up jiggling the C/CUDA compiler into generating the logic you want in lieu of just being able to tell it up front. If you don't have a mental model, making decent hardware is going to suck, and you're probably better off learning an HDL anyway.

A high level functional approach that still recognizes that you're writing hardware is a nice abstraction.

I've only done a little bit with Xilinx's HLS which allows you to write "C/C++" which gets synthesized to hardware. I put C/C++ in quotes because it relies on lots of pragma directives to tell the complier enough that it can synthesize the hardware that you want, to the point of it almost being its own language entirely, There may be a few applications where this is particularly well suited, but at least for what I was doing, it was easier (and fit my mental model better... ymmv) to do it in HDL.

Edit: System Generator is pretty awesome though!

The easiest way to put it is probably to say that C is just not the right language for a system in which everything happens at once. You use a programming language to tell a CPU what to do, and you use an HDL to tell an FPGA what to be. An ensemble of explicit state machines is a better way to picture it.

If anything, a pure functional or declarative model might be a better starting point for high-level synthesis than a C-like imperative language. But most of the R&D seems to be going in the opposite direction.

In a high level language? Absolutely. In C? No, thanks. There is a huge semantic mismatch with the highly parallel nature of FPGAs.

A high level language suitable for HDL generation must expose much better abstractions for parallelism. CUDA is just the same thing as C, too bound to the underlying architecture.

I think a high level HDL would be great. C really isn't a good starting point because as you said it doesn't really fit the parallel hardware paradigm. The existing tools that do this feel like they're trying to shoehorn C into this application and it doesn't work too well, because of all the extra information you need to synthesize hardware, e.g. should every iteration of this loop happen simultaneously, or are you making a shift register?

Something that started with a Verilog/VHDL paradigm but provided higher level abstrations would be nice, a good analogy would be something like how Python is to C.

I've been a really big fan of chisel so far. I was very skeptical initially. But the more I got into it, the more I realized that the code=data benefits you get from some functional languages like the Lisps (where Lisp code is also s-expressions and can be parsed and manipulated like any other data) really works well for manipulating your RTL graph.
This is actually something I am currently working on. An extensible HDL which allows to gradually add abstraction layers (and operate solely on any chosen level), while keeping an ability to express anything down to gates.
I'd definitely be interested in checking that out if you have a link
I have not published the language yet, have to produce some nice looking examples first. But you can take a look at my approach to extensibility in general (the HDL language is using exactly the same thing) and some of the earlier mixing Verilog with C experiments here: https://github.com/combinatorylogic