[Traster]

>XLS is used inside of Google for generating feed-forward pipelines from "building block" routines

For those that aren't familiar, control flow - or non "Directed Acyclical graphs" are the hard part of HLS. This looks like a fairly nice syntax compared to the bastardisations of C that Intel and Xilinx pursue for HLS but I'm not sure this is bringing anything new to the table.

As for the examples, I'm kind of flumoxed that they haven't given any details on what the examples synthesize to. For example, how many logic blocks does the CRC32 use? How many clock cycles? What about the throughput? I'm going to sound like a grumpy old man now, but it's important becaues it's very difficult to get performant code as a hardware engineer. Generally it involves having a fair idea of how the code is going to synthesize. What is damn near impossible is figuring out what you want to synthesize to, and then guessing the shibboleth that the compiler wants in order to produce that code. Given that they haven't tackled the difficult problems like control flow, folding, resource sharing etc. It makes me hesitant to believe they've produced something phenomenal.

[learyg]

Hi, one of the collaborators here, thanks for the good points.

We have been targeting some Lattice FPGAs for prototyping purposes, but we've mostly been doing designs for ASIC processes, which is why details are a little sparse for FPGAs you get off the shelf, but it's a priority for us to fill those in. We have some interactive demos that show FPGA synthesis stats (cell counts, generated Verilog, let you toy with the pipeline frequency) and integrate with the [IR visualizer](https://google.github.io/xls/ir_visualization/#screenshot), we'll try to open source that as soon as possible. The OSS tools (SymbiFlow) that some of our colleagues collaborate on can do synthesis in just a few seconds, so it can feel pretty cool to see these things in near-real-time.

We fold over resources in time with a sequential generator, but we still have a ways to go, we expect a bunch of problems will map nicely onto concurrent processes, they're turing complete and nice for the compiler to reason about.

I'm a big believer that phenomenonal is really effort and solving real-world pain points integrated over time -- it's a journey! We're intending to do blog posts as we hit big milestones, so keep an eye out!

[Traster]

Do you mind me asking what applications Google uses this for internally? Is this used in a flow that's ended up in production? Also, what are your thoughts on integrating optimized RTL blocks?

[learyg]

One of the things we have on our short list is "good FFI" for instantiating existing RTL blocks (and making their timing characteristics known to the compiler) and making import flows from Verilog/SystemVerilog types. The latter may be a bit your-Verilog-flow specific, but we think there are some universal components you can provide that folks can slot in their flows as appropriate.

Being able to re-time pipelines without a rewrite is a useful capability. Although it's still experimental and we're actively building out the capabilities, we have it in real designs that have important datapaths.

[person_of_color]

Are you hiring SWEs for HW-SW co-design?

[learyg]

I am not personally a manager / hiring manager, but this is the job posting for SW/HW codesign positions in the south bay area CA -- speaking as an IC, it has been a very enjoyable area to work in as specialized designs become more important! https://g.co/kgs/xGSUXy

[person_of_color]

Thanks for the tip.

[aseipp]

The HLS tools from Xilinx and Intel (and maybe Cadence I guess) can also actually compile your models as ordinary C++ code (i++ from Intel is literally just a fork of Clang, I think, and so are tools like LegUp), leading to their greatest benefit: simulations are way, way faster and software compilers have vastly better iteration times than synthesizers.

They seem to have a simulation framework for these tools that isn't just "re-use an existing simulator", and it apparently does use LLVM for codegen but that's the easy part. Actual simulation performance numbers would be really interesting to see vs actual RTL sims.