5 ms·

darn, not quite the HLS the headline suggested.

by yababa_y 4y ago

zdimension 4y ago
I'm sorry, what does HLS mean?
- fuklief 4y ago
  I believe it means High Level Synthesis in this context.
  - zdimension 4y ago
    Ah. Indeed, I don't have an FPGA on hand to synthesize all this to real silicon, but it would totally be possible (Digital has support for FPGA synthesis)
    - yababa_y 4y ago
      an HLS would compile rust directly to verilog or some netlist, as opposed to running the ARM core with a different technology. this is an awesome project, great writeup :)
mhh__ 4y ago
One of the interesting things you can do with LLVM is bully it into emitting a SPIR-V compute shader, supposedly for GPUs, but I think you can probably throw it into a very contrived SYCL ugly-ugly-ugly pipeline and somehow get it on an FPGA. https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native... With DCompute you can use metaprogramming to generate shaders alongside D code for GPUs, really want to try it with an FPGA. Similar things probably exist for rust as well. Getting the data back off the FPGA into the program is undefined behaviour, though.
- jcranmer 4y ago
  > but I think you can probably throw it into a very contrived SYCL ugly-ugly-ugly pipeline and somehow get it on an FPGA. It's not a "very contrived SYCL ugly-ugly-ugly pipeline"--Intel's oneAPI explicitly has a FPGA backend for its SYCL compiler: https://www.intel.com/content/www/us/en/develop/documentation/oneapi-programming-guide/top/programming-interface/fpga-flow.html https://www.intel.com/content/www/us/en/develop/documentatio...
  - mhh__ 4y ago
    You've still got to take that and make it do what you want. I also find oneAPI kind of ugly although it was a while since I really dug into it.
    - misnome 4y ago
      The FPGA tooling is pretty nice, once you get past the "how did this work for anyone else bugs". Albeit with limited card support and I haven't seen others jumping onto the bandwagon. As far as I can tell it's mostly just "SYCL with feature limitations" and a couple of niceties to connect kernels together. I've wondered how much work it would be to get Rust->SPIR-V->OneAPI compiling, but it sounds like an exercise in masochism so haven't gone down that route yet.
      - mhh__ 4y ago
        With work like this it becomes clear (even in GPU-land) why picking the right components and sticking with them (where sensible) is so much more important in hardware than software. In software we want nice abstractions and so on, with FPGAs if those abstractions are even possible you probably can't afford to write them. I spoke to an ASIC designer recently, the EDA industries weird. The big thing with SYCL and oneAPI and so on for me at least is that you have all this stuff bolted onto C++. C++'s ability to do generative programming is just not as good as it's competitors, that and C++ just being a bad language. If things are more language-agnostic than I realize then yippee The clever thing about the DCompute project that I linked above is that it uses a simple but powerful introspection system (provided by D, could really be any competently designed language) to pick up the right stuff and generative the compute kernels in the background for you.
sasaf5 4y ago
Yes, I was expecting a "Rust to gates" kind of project. Turns out they are compiling Rust to their homebred ARM CPU and then simulating it.
pjc50 4y ago
Unpopular opinion: trying to synthesize a language designed to run on a CPU into logic gates tends to produce terrible results, and we would be far better served by building better HDLs instead (e.g. Chisel). (The commercial ASIC design world is very conservative, with some good reasons and some bad, and tends not to use either advance, preferring the VHDL/Verilog of our ancestors)
- FullyFunctional 4y ago
  Better HDLs would be great, like actual HLS, BlueSpec, or Handel-C, not lame gatelist generators in a botched FP language crawling on top of Java.
  - ColonelPhantom 4y ago
    Both approaches have virtues. HLS is simpler for software programmers, but tends to rely more on 'magic' and is not a very clean abstraction of the hardware that's generated. That said, loops aside, most compiler IR is a sort of dataflow graph which could reasonably be synthesized into hardware. But most control flow does not map very well. Higher-level HDLs such as Chisel (although I have never used it) instead abstract directly over standard HDLs like Verilog or VHDL. These abstractions are simpler because they do not alter the fundamental design ideas; they just offer increased flexibility (for example VexRiscv, which is written in SpinalHDL and has most functionality in 'plugins' which extend CPU components, which is a very powerful form of metaprogramming that is not possible with Verilog). If your issue is with Scala, there's other HHDLs such as Clash (based on Haskell) or Migen and Amaranth which use Python.

darn, not quite the HLS the headline suggested.

zdimension 4y ago

I'm sorry, what does HLS mean?

fuklief 4y ago
I believe it means High Level Synthesis in this context.
- zdimension 4y ago
  Ah. Indeed, I don't have an FPGA on hand to synthesize all this to real silicon, but it would totally be possible (Digital has support for FPGA synthesis)
  - yababa_y 4y ago
    an HLS would compile rust directly to verilog or some netlist, as opposed to running the ARM core with a different technology. this is an awesome project, great writeup :)

mhh__ 4y ago

One of the interesting things you can do with LLVM is bully it into emitting a SPIR-V compute shader, supposedly for GPUs, but I think you can probably throw it into a very contrived SYCL ugly-ugly-ugly pipeline and somehow get it on an FPGA. https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native... With DCompute you can use metaprogramming to generate shaders alongside D code for GPUs, really want to try it with an FPGA. Similar things probably exist for rust as well. Getting the data back off the FPGA into the program is undefined behaviour, though.

jcranmer 4y ago
> but I think you can probably throw it into a very contrived SYCL ugly-ugly-ugly pipeline and somehow get it on an FPGA. It's not a "very contrived SYCL ugly-ugly-ugly pipeline"--Intel's oneAPI explicitly has a FPGA backend for its SYCL compiler: https://www.intel.com/content/www/us/en/develop/documentation/oneapi-programming-guide/top/programming-interface/fpga-flow.html https://www.intel.com/content/www/us/en/develop/documentatio...
- mhh__ 4y ago
  You've still got to take that and make it do what you want. I also find oneAPI kind of ugly although it was a while since I really dug into it.
  - misnome 4y ago
    The FPGA tooling is pretty nice, once you get past the "how did this work for anyone else bugs". Albeit with limited card support and I haven't seen others jumping onto the bandwagon. As far as I can tell it's mostly just "SYCL with feature limitations" and a couple of niceties to connect kernels together. I've wondered how much work it would be to get Rust->SPIR-V->OneAPI compiling, but it sounds like an exercise in masochism so haven't gone down that route yet.
    - mhh__ 4y ago
      With work like this it becomes clear (even in GPU-land) why picking the right components and sticking with them (where sensible) is so much more important in hardware than software. In software we want nice abstractions and so on, with FPGAs if those abstractions are even possible you probably can't afford to write them. I spoke to an ASIC designer recently, the EDA industries weird. The big thing with SYCL and oneAPI and so on for me at least is that you have all this stuff bolted onto C++. C++'s ability to do generative programming is just not as good as it's competitors, that and C++ just being a bad language. If things are more language-agnostic than I realize then yippee The clever thing about the DCompute project that I linked above is that it uses a simple but powerful introspection system (provided by D, could really be any competently designed language) to pick up the right stuff and generative the compute kernels in the background for you.

sasaf5 4y ago

Yes, I was expecting a "Rust to gates" kind of project. Turns out they are compiling Rust to their homebred ARM CPU and then simulating it.

pjc50 4y ago

Unpopular opinion: trying to synthesize a language designed to run on a CPU into logic gates tends to produce terrible results, and we would be far better served by building better HDLs instead (e.g. Chisel). (The commercial ASIC design world is very conservative, with some good reasons and some bad, and tends not to use either advance, preferring the VHDL/Verilog of our ancestors)

FullyFunctional 4y ago
Better HDLs would be great, like actual HLS, BlueSpec, or Handel-C, not lame gatelist generators in a botched FP language crawling on top of Java.
- ColonelPhantom 4y ago
  Both approaches have virtues. HLS is simpler for software programmers, but tends to rely more on 'magic' and is not a very clean abstraction of the hardware that's generated. That said, loops aside, most compiler IR is a sort of dataflow graph which could reasonably be synthesized into hardware. But most control flow does not map very well. Higher-level HDLs such as Chisel (although I have never used it) instead abstract directly over standard HDLs like Verilog or VHDL. These abstractions are simpler because they do not alter the fundamental design ideas; they just offer increased flexibility (for example VexRiscv, which is written in SpinalHDL and has most functionality in 'plugins' which extend CPU components, which is a very powerful form of metaprogramming that is not possible with Verilog). If your issue is with Scala, there's other HHDLs such as Clash (based on Haskell) or Migen and Amaranth which use Python.