Looks like it's ultimately an llvm backend that'll generate VHDL, Verilog, or SystemC, and has some optimizations it'll do for the exact family of chip you're running on. Knowing what the hard DSP blocks can do and writing code that'll use them kind of stuff (as well as a few farily generic optimization passes).
It doesn't appear to know anything about bitstreams and works at a higher level that'll be synthesized by another tool.
The article mentions its the HLS frontend that was open-sourced, not the backend. I see no evidence of any HDL codegen here at all yet. I'll keep looking though.
The full HLS tool that they ship does produce full verilog/vhdl, and doesn't go to the bitstream level. It would be a huge improvement if they would open-source the whole thing. I suspect they will not, however, as code generator likely has a fairly complex FPGA Fabric/Slice timing model used to schedule operations into clocks, and that is something they would probably consider proprietary. Hopefully they can strip out those bits out and release the rest.
"The Vitis HLS is a high-level synthesis tool that allows C, C++, and OpenCL functions to become hardwired onto the device logic fabric and RAM/DSP blocks." [1]
The link also has some code samples and timing diagrams.
Honest question: how well do HLS tools actually work in practice?
Maybe this is completely wrong, but I have this gut instinct that they must be extremely brittle. That's based on being a CPU/GPU compiler person and knowing, for example, how many difficult problems are still out there for automatic GPU code generation. I find it really hard to imagine that with all the additional challenges you get with FPGAs, that you'd be able to make this really work for anything beyond the most bare-bones examples. (But I'll admit that I don't really know what I'm talking about.)
Anyway, it's good that it's open source. Hopefully more of the magic will be open to public inspection now.
For many things I would take HLS over writing SystemVerilog. My background is software, but I've written a modest amount SystemVerilog professionally in recent years. While there are specific cases where I'd still pick SystemVerilog (building an AXI peripheral with a specific address space layout or unique semantics for that address space), I'd tend to prefer HLS for anything actually dealing with complex data processing. Think packet pipelines, sorts, database joins, index processing, etc. If you were already in the mindset of thinking about streaming data through a pipeline (as you might in SystemVerilog) you can write fairly boring looking C++ with ordinary unit tests and the HLS tooling will do a reasonable job of turning it into equivalent pipelined Verilog.
Lookup tables are the big thing that break CPU and GPU programs since at relatively small sizes you'll hit the memory wall. A lot of algorithms like media codecs (audio, video) and pretrained neural nets are trivial to design with HLS and have a major performance advantage over using a CPU or GPU.
Add in the fact that CPUs and GPUs are expensive as fuck, in short supply, demand high power, while FPGAs are pretty cheap and efficient since they don't do much you're going to find a lot of designs that call for them over a beefy and expensive chip.
That said, arm and risc V cores are dirt cheap. If your algorithm isn't hitting the memory wall it probably isn't going to be faster via HLS.
There's domains where they work pretty well (that tend to look like DSP pipelines). But they're for sure nothing like a panacea opening the world of reconfigurable hardware to software developers at the same parity as HDLs.
The company I'm working for is only using HLS since quite some time, no directly written Verilog etc. anymore. I myself am a software developer in this company.
I know it's working perfectly fine for us and even the strongest advocate of using Verilog directly was converted by now to only using HLS.
I got it explained like this:
HLS has it's own class of problems and you definitively need some time to get used to how you need to write code that is actually synthesized in a way you intended it to be. However, once you got used to it, development using HLS is way faster than writing Verilog directly and our FPGA guys basically said that we would not be where we are if it weren't for HLS because of this.
So it seems that it's actually working quite fine in practice but obviously not without it's own problems.
Higher level hardware design languages that better interop with software are desperately needed, but I don't know if C/C++ is the right UI/abstraction.
Look at Chisel. I agree that C/C++ is the wrong abstraction but that's because using a HDL is more like meta programming in a declarative markup language that needs to be embedded in a higher level language for automation and verification than to compile imperative operations into silicon.
I don't think so either. One thing that's interesting here is that this ties into LLVM - perhaps other LLVM languages like Julia or Rust could interop?
Maybe it's a start. I was wondering, hoping, things might at least have a possibility of changing after being aquired by AMD.
AMD, or some gradual infusion of new staff and culture over time, might change their stance wrt to open source tools, or at least the documentatione necessary to write them.
This isn't that, but it's not nothing either. Maybe it's just a good first step.
Or maybe it's just the age old traditional way to be sticky. Get students addicted to a front end that only works with your locked up back end.
This is pretty neat. Apache license, it looks like.
Does this actually generate bitstream, or it is a higher level tool than that? The diagram in the article suggests that proprietary software is still needed to target a specific FPGA.
No, it doesn't get down to the bitstream level. This is at the LLVM IR level. If Xilinx ever open sources tools that could create bitstreams for their FPGAs, well, that would be huge news. Not likely to ever happen, though.
Speaking of open source FPGA tools, I recently saw a video on Twitter of someone programming an FPGA (TinyFPGA, I think) using a 100% opensource toolchain. Has anyone seen that?
There's a complete open source toolchain available for ice40 and ecp5 FPGAs from Lattice, for both Verilog and VHDL. I've been using it for almost a year now and it's really good. See github.com/YosysHQ
> Speaking of open source FPGA tools, I recently saw a video on Twitter of someone programming an FPGA (TinyFPGA, I think) using a 100% opensource toolchain. Has anyone seen that?
They support several families of FPGAs, to varying extents.
iCE40 was first. Now there's also full stack support for ECP5, QuickLogic (with manufacturer's help!) and a subset of Xilinx family 7 and GW1N (cheap chinese FPGAs!), among others.
I am sorry if I didn't do my research here. What chips can use this? And does one still need to use their other IDE for the generation of bitstreams in addition to this?
[+] [-] monocasa|5 years ago|reply
It doesn't appear to know anything about bitstreams and works at a higher level that'll be synthesized by another tool.
https://github.com/Xilinx/HLS/blob/da538325ea9cb410672be6bb1...
Awesome, fairly reusable looking work being opened by them. A lot more than I expected from the title. Good work, Xilinx!
[+] [-] randrews9|5 years ago|reply
The full HLS tool that they ship does produce full verilog/vhdl, and doesn't go to the bitstream level. It would be a huge improvement if they would open-source the whole thing. I suspect they will not, however, as code generator likely has a fairly complex FPGA Fabric/Slice timing model used to schedule operations into clocks, and that is something they would probably consider proprietary. Hopefully they can strip out those bits out and release the rest.
[+] [-] rkagerer|5 years ago|reply
"The Vitis HLS is a high-level synthesis tool that allows C, C++, and OpenCL functions to become hardwired onto the device logic fabric and RAM/DSP blocks." [1]
The link also has some code samples and timing diagrams.
[1] https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/intr...
[+] [-] eslaught|5 years ago|reply
Maybe this is completely wrong, but I have this gut instinct that they must be extremely brittle. That's based on being a CPU/GPU compiler person and knowing, for example, how many difficult problems are still out there for automatic GPU code generation. I find it really hard to imagine that with all the additional challenges you get with FPGAs, that you'd be able to make this really work for anything beyond the most bare-bones examples. (But I'll admit that I don't really know what I'm talking about.)
Anyway, it's good that it's open source. Hopefully more of the magic will be open to public inspection now.
[+] [-] jsolson|5 years ago|reply
[+] [-] hctaw|5 years ago|reply
Add in the fact that CPUs and GPUs are expensive as fuck, in short supply, demand high power, while FPGAs are pretty cheap and efficient since they don't do much you're going to find a lot of designs that call for them over a beefy and expensive chip.
That said, arm and risc V cores are dirt cheap. If your algorithm isn't hitting the memory wall it probably isn't going to be faster via HLS.
[+] [-] monocasa|5 years ago|reply
[+] [-] UncleOxidant|5 years ago|reply
[+] [-] irrenhaus|5 years ago|reply
I know it's working perfectly fine for us and even the strongest advocate of using Verilog directly was converted by now to only using HLS.
I got it explained like this: HLS has it's own class of problems and you definitively need some time to get used to how you need to write code that is actually synthesized in a way you intended it to be. However, once you got used to it, development using HLS is way faster than writing Verilog directly and our FPGA guys basically said that we would not be where we are if it weren't for HLS because of this.
So it seems that it's actually working quite fine in practice but obviously not without it's own problems.
[+] [-] randrews9|5 years ago|reply
https://news.ycombinator.com/item?id=24354083
[+] [-] 8note|5 years ago|reply
Same performance but the HLS made a smaller footprint
[+] [-] ancharm|5 years ago|reply
[+] [-] hctaw|5 years ago|reply
[+] [-] UncleOxidant|5 years ago|reply
[+] [-] Brian_K_White|5 years ago|reply
AMD, or some gradual infusion of new staff and culture over time, might change their stance wrt to open source tools, or at least the documentatione necessary to write them.
This isn't that, but it's not nothing either. Maybe it's just a good first step.
Or maybe it's just the age old traditional way to be sticky. Get students addicted to a front end that only works with your locked up back end.
[+] [-] ip26|5 years ago|reply
https://xilinx.github.io/xup_compute_acceleration/
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] sneak|5 years ago|reply
Does this actually generate bitstream, or it is a higher level tool than that? The diagram in the article suggests that proprietary software is still needed to target a specific FPGA.
[+] [-] UncleOxidant|5 years ago|reply
[+] [-] Robotbeat|5 years ago|reply
[+] [-] nobodywasishere|5 years ago|reply
[+] [-] 70rd|5 years ago|reply
Could it be https://symbiflow.github.io/? Symbiflow aims to be "gcc for FPGAs".
[+] [-] topspin|5 years ago|reply
[+] [-] snvzz|5 years ago|reply
They support several families of FPGAs, to varying extents.
iCE40 was first. Now there's also full stack support for ECP5, QuickLogic (with manufacturer's help!) and a subset of Xilinx family 7 and GW1N (cheap chinese FPGAs!), among others.
[+] [-] joseluis|5 years ago|reply
[+] [-] b0tzzzzzzman|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]