Xilinx Opens Up Vitis HLS Tool for FPGAs | Hacker News Reader

Xilinx Opens Up Vitis HLS Tool for FPGAs

eetimes.com

86 pointsUncleOxidant31 comments

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.

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!

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.

Yeah, the final output is just LLVM IR, so this is about useless for anything.

I'm not even sure this is the correct abstraction layer for an HLS tool (even though it seems 2 out of the 3 mayor players use it, albeit it is precisely the leader who doesnt use LLVM).

For anyone wondering:

"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...

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.

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.

For DSPish type dataflowy applications HLS can help boost productivity. But if you were, say, designing a processor it would only get in your way.

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.

Totally agree. Certain signal processing pipelines that FPGAs are often targeted at map very well to HLS, often with 10x or more code reduction. Production SoCs sometimes use similar tech for less power/performance critical blocks. Mentor graphics catapult HLS marketing material contains some note that NVENC on the maxwell generation of Nvidia GPUS was coded in HLS.

I know it's replaced some vhdl I wrote a few years back for shuffling for data onto an ftdi usb chip.

Same performance but the HLS made a smaller footprint

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.

I do not agree, that FPGAs are cheap. Nothing really efficient under 100€ unless you are Subaru buying millions of them. One can get lots of assembled interesting SoC modules for 100€.

I've seen decent FPGAs for 500€. That's "cheap" when the competitors are 1000€/month GPUs.

See somewhat recent thread on xls:

https://news.ycombinator.com/item?id=24354083

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.

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?

I've kind of always felt that synthesizable Verilog/SystemVerilog was good, but the verification side was just too complex and had too much bloat. Testing hardware with Python (like Cocotb) feels more on the right track as a high level UI.

But easily pluggable APIs for foreign SW languages are key as well. Hardware software co-design is only becoming more important.

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.

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.

Seems like this introduction to Vitis would be a good partner page to go with this announcement:

https://xilinx.github.io/xup_compute_acceleration/

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.

How does open source interact with export restrictions? I'd imagine ITAR being the biggest blocker

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?

> 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?

Could it be https://symbiflow.github.io/? Symbiflow aims to be "gcc for FPGAs".

QuickLogic perhaps; 100% open source FPGA+MCU platform. This is probably the video you're thinking of: https://www.youtube.com/watch?v=Q5GIZUsXb3I

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

Investigate yosys and nextpnr.

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.

there's the Fipsy Fpga project https://www.mocomakers.com/fipsy-fpga/ which started as a kickstarter in 2018

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?

Reply on news.ycombinator.com