[sklogic]

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.

[hamiltonkibbe]

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.

[monocasa]

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.

[sklogic]

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.

[hamiltonkibbe]

I'd definitely be interested in checking that out if you have a link

[sklogic]

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