3 ms·

I think one issue here is that to achieve the great gains in performance FPGAs can provide you do need to treat it like a proper HW design. C to RTL exists but

I think one issue here is that to achieve the great gains in performance FPGAs can provide you do need to treat it like a proper HW design. C to RTL exists but to get the best out of it you're basically using C as a syntactic sugar for verilog/VHDL. So the overhead for programmability is higher than a DSP/GPU if you want to gain over and above them. I do wonder if there's a sweet spot in here somewhere that's basically a sea of DSP or GPU (maybe better to call them stream processing units) with programmable wiring and some specialised ALUs/FP units mixed in that can also use the wiring allowing you to create special one-cycle fixed function ops?

TorKlingberg 12y ago
As a C programmer, I don't think C is suitable for such a fundamentally parallel architecture as an FPGA. I would prefer a higher level language, maybe declarative, where it is up to the compiler to lay out the parallel operations. Unfortunately the engineering culture gap from HDL to a high level language is much wider than to C.
- sklogic 12y ago
  Actually it's easier and more natural to translate a (domain-specific) high level language into RTL than trying to fit an alien but so-called "general-purpose" C. I'm using a language which translates into Verilog, but features native support for expressing things like FSMs, pipelines, buses, FIFOs - and something as simple as this makes HDL coding much simpler and much less error-prone than a conventional low-level RTL.
  - azeirah 12y ago
    This is because C, as I understand it, is a language that best described the fundamental workings of processors, and let you work with a thin-abstraction layer over the cpu/memory architecture. FPGA don't have this traditional cpu/memory architecture, and as a result, C fits them poorly.
    - sklogic 12y ago
      Exactly. C assumes too much about the hardware semantics, it's got a peculiar memory model, sequential execution and all that. There are tricks, of course, allowing to get out of the C box a little bit - e.g., using multiple address spaces to simulate distinct memory and memory-like blocks, but it's still unnatural and do not make hardware description any simpler than doing it manually in RTL level.

TorKlingberg 12y ago

As a C programmer, I don't think C is suitable for such a fundamentally parallel architecture as an FPGA. I would prefer a higher level language, maybe declarative, where it is up to the compiler to lay out the parallel operations. Unfortunately the engineering culture gap from HDL to a high level language is much wider than to C.

sklogic 12y ago
Actually it's easier and more natural to translate a (domain-specific) high level language into RTL than trying to fit an alien but so-called "general-purpose" C. I'm using a language which translates into Verilog, but features native support for expressing things like FSMs, pipelines, buses, FIFOs - and something as simple as this makes HDL coding much simpler and much less error-prone than a conventional low-level RTL.
- azeirah 12y ago
  This is because C, as I understand it, is a language that best described the fundamental workings of processors, and let you work with a thin-abstraction layer over the cpu/memory architecture. FPGA don't have this traditional cpu/memory architecture, and as a result, C fits them poorly.
  - sklogic 12y ago
    Exactly. C assumes too much about the hardware semantics, it's got a peculiar memory model, sequential execution and all that. There are tricks, of course, allowing to get out of the C box a little bit - e.g., using multiple address spaces to simulate distinct memory and memory-like blocks, but it's still unnatural and do not make hardware description any simpler than doing it manually in RTL level.