3 ms·

Yeah, I have worked with FPGAs a while ago and still casually follow the space. There have been many attempts of mapping general purpose/GPU programming langua

Yeah, I have worked with FPGAs a while ago and still casually follow the space. There have been many attempts of mapping general purpose/GPU programming languages to FPGA and none of them worked out. The first leading claim they make - that this is a general purpose CPU, capable of executing anything - I suspect is false. CPUs are hard because they have to interact with memory, basically 95% of CPU design complexity comes from having to interact with memory, and handling other data hazards. If this was reducible complexity, they'd have done so already.

actionfromafar 1y ago
Then I have a thought experiment. Replace the execution cores on a state of the art GPU and CPU with FPGAs.
- santaboom 1y ago
  See amdahls law Edit: [0] https://en.m.wikipedia.org/wiki/Amdahl%27s_law https://en.m.wikipedia.org/wiki/Amdahl%27s_law
  - actionfromafar 1y ago
    Yes but we are also talking about energy efficiency
    - santaboom 1y ago
      See figure 1 in [0] operation execution is just 0.1pj of 70pj required for a 32 bit int addition… how do you think I was applying amdahls law? Edit: I was using amdahls law as it applies to parallel processors. However in terms of energy usage … See amdahls laws and use your imagination [0] https://semiengineering.com/more-data-drives-focus-on-ic-energy-efficiency/ https://semiengineering.com/more-data-drives-focus-on-ic-ene...
  - LargoLasskhyfv 1y ago
    See 'Apple-Core', Microgrids, SVP, UTLEON3 In theory, in practice this seems to have failed, but still... Also related: https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/
VonTum 1y ago
In academia people use general purpose languages (Notably C++ dialects) for FPGA design quite a lot. And there's definitely a glut of papers published on the development of such "High Level Synthesis" tools. In order to use the FPGA efficiently you need to first pipeline the logic deeply, but then also be able to fill that pipeline. But in my opinion there is just too much of an impedance mismatch between the "do one thing and then the next" style of imperative code, and the "everything everywhere all at once" way in which FPGAs actually work. And well, here's my plug for my language that gets close to HLS in terms of syntactic ease, while still retaining full control over the generated hardware: https://github.com/pc2/sus-compiler https://github.com/pc2/sus-compiler By explicitly keeping track of pipelining in submodules the compiler automatically balances the pipelines your create, and in addition, you can write modules that respond to the pipeline distance between their ports, and infer their parameters based on that. That fixes one of the most error-prone activities when designing hardware in SV or other languages.
- torginus 1y ago
  I worked in industry, trying to fit video processing algorithms and filter banks to FPGAs, about a decade ago, so my memories are a bit fuzzy. The thing about FPGAs is that they are wildly expensive, getting exponentially more so the more you move up the product pallette. They also have a ton of special function blocks (DPRAM, multipliers, shift registers etc), that work differently from vendor to vendor, and even between generations. Even with HDLs you had to options - either read all the datasheet, the layout and mix of components, and plan your design to fit the hardware - or just wing it and write down what you wanted, and hope for the best - in the latter scenario, the synthesis tool had to figure out how to fit your design best to the hardware, which even if you were mindful of how the chip worked, was still a hit and miss. When you work in industry and either every cent counts, or you have to design for a fixed target, and somehow you're in the good graces of tooling, finding that changing a small thing suddenly makes your design 3x as big and half as fast is not acceptable. HLS was this, but on steroids - you never knew what you were going to get, sometimes it worked well, sometimes not at all. I'm sure tooling has evolved back then but I'd still guess spending the extra engineering effort is often well worth it when your chips cost five figures.

actionfromafar 1y ago

Then I have a thought experiment. Replace the execution cores on a state of the art GPU and CPU with FPGAs.

santaboom 1y ago
See amdahls law Edit: [0] https://en.m.wikipedia.org/wiki/Amdahl%27s_law https://en.m.wikipedia.org/wiki/Amdahl%27s_law
- actionfromafar 1y ago
  Yes but we are also talking about energy efficiency
  - santaboom 1y ago
    See figure 1 in [0] operation execution is just 0.1pj of 70pj required for a 32 bit int addition… how do you think I was applying amdahls law? Edit: I was using amdahls law as it applies to parallel processors. However in terms of energy usage … See amdahls laws and use your imagination [0] https://semiengineering.com/more-data-drives-focus-on-ic-energy-efficiency/ https://semiengineering.com/more-data-drives-focus-on-ic-ene...
- LargoLasskhyfv 1y ago
  See 'Apple-Core', Microgrids, SVP, UTLEON3 In theory, in practice this seems to have failed, but still... Also related: https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/

VonTum 1y ago

In academia people use general purpose languages (Notably C++ dialects) for FPGA design quite a lot. And there's definitely a glut of papers published on the development of such "High Level Synthesis" tools. In order to use the FPGA efficiently you need to first pipeline the logic deeply, but then also be able to fill that pipeline. But in my opinion there is just too much of an impedance mismatch between the "do one thing and then the next" style of imperative code, and the "everything everywhere all at once" way in which FPGAs actually work. And well, here's my plug for my language that gets close to HLS in terms of syntactic ease, while still retaining full control over the generated hardware: https://github.com/pc2/sus-compiler https://github.com/pc2/sus-compiler By explicitly keeping track of pipelining in submodules the compiler automatically balances the pipelines your create, and in addition, you can write modules that respond to the pipeline distance between their ports, and infer their parameters based on that. That fixes one of the most error-prone activities when designing hardware in SV or other languages.

torginus 1y ago
I worked in industry, trying to fit video processing algorithms and filter banks to FPGAs, about a decade ago, so my memories are a bit fuzzy. The thing about FPGAs is that they are wildly expensive, getting exponentially more so the more you move up the product pallette. They also have a ton of special function blocks (DPRAM, multipliers, shift registers etc), that work differently from vendor to vendor, and even between generations. Even with HDLs you had to options - either read all the datasheet, the layout and mix of components, and plan your design to fit the hardware - or just wing it and write down what you wanted, and hope for the best - in the latter scenario, the synthesis tool had to figure out how to fit your design best to the hardware, which even if you were mindful of how the chip worked, was still a hit and miss. When you work in industry and either every cent counts, or you have to design for a fixed target, and somehow you're in the good graces of tooling, finding that changing a small thing suddenly makes your design 3x as big and half as fast is not acceptable. HLS was this, but on steroids - you never knew what you were going to get, sometimes it worked well, sometimes not at all. I'm sure tooling has evolved back then but I'd still guess spending the extra engineering effort is often well worth it when your chips cost five figures.