Live data from Hacker News

XLS: Accelerated HW Synthesis

google.github.io

41–50 of 55 posts

Re: XLS: Accelerated HW Synthesis

#41
post #37
post #33

Earlier quoted context omitted.

It's kind of a good demonstration of the problem with software versus hardware, here's xls solution (just for one function): fn decode_i_instruction(ins: u32) -> (u12, u5, u3, u5, u7) { let imm_11_0 = (ins >> u32:20); let rs1 = (ins >> u32:15) & u32:0x1F; let funct3 = (ins >> u32:12) & u32:0x07; let rd = (ins >> u32:7) & u32:0x1F; let opcode = ins & u32:0x7F; (imm_11_0 as u12, rs1 as u5, funct3 as u3, rd as u5, opcod…

Thanks again for the detailed thought! We actually [developed more advanced bit slicing syntax]( https://github.com/google/xls/blob/1b6859dc384fe8fa39fb901af... ) since that example was written, you can do things like a standard slice `x[5:8]` or a Verilog-style "width slice" that has explicit signedness `x[i +: u8]`. There's currently no facility for "destructuring" structs as bitfields like pattern matches, but the…

Hey, thanks for replying, the project looks like it has a lot of potential. You're right, bit slicing gets you like 99% of the way there (the rest is just syntax sugar). It's interesting because from what I remember there were some non-trivial issues for the people using LLVM for their IR because of fundamental assumptions in the representation, but bit-slicing is the core functionality. Is there a reason you guys decided on your own IR?

Re: XLS: Accelerated HW Synthesis

#42
post #31

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

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.

Re: XLS: Accelerated HW Synthesis

#43
post #36
post #31

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

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 th…

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?

Re: XLS: Accelerated HW Synthesis

#44
post #43
post #36

Earlier quoted context omitted.

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 th…

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?

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.

Re: XLS: Accelerated HW Synthesis

#45
post #11

Earlier quoted context omitted.

It looks really quite similar to Rust: https://github.com/google/xls/blob/main/xls/examples/dslx_in... Note that there are differences though: Seems no type inferrence, for .. in, different array syntax, match arms delimitered by ";" instead of ",". But it has a lot of the cool stuff from Rust: pattern matching, expression orientedness (let ... = match { ... }), etc. Also other syntax is similar: fn foo() -> Type syn…

Looks like the match arm difference is going away: https://github.com/google/xls/pull/127

Very cool. TBH, Rust's match arm delimiter story is a bit weird. Sometimes you need to put a ",", sometimes you don't. And macro rules macros have ";" instead of ",".

Re: XLS: Accelerated HW Synthesis

#46
post #32
post #15

Earlier quoted context omitted.

This doesn't seem like HLS, more like a new HDL that's based on Rust. This has been done many times before with other functional languages (Clash, Chisel, Spinal, hardcaml and others). These projects never take off because hardware designers are inherently conservative and they won't let go of their horrible language (Verilog or SystemVeriog) no matter what. I'm sure Google will use XLS for their internal digital des…

> These projects never take off because hardware designers are inherently conservative and they won't let go of their horrible language (Verilog or SystemVeriog) no matter what. This is categorically not true. There have been repeated projects to re-invent hardware description languages. They don't fail because hardware engineers are conservative, they fail because they don't produce good enough results. Intel has a…

I mean, languages like Bluespec are very close to actual SystemVerilog semantically, and others like Clash are essentially structural by design, not behavioral (I can't speak for other alt-RTLs). You are in full control of using DFFs, the language perfectly reflects where combinatorial logic is done, the mappings of DFFs or IP to underlying RTL and device primitives can easily be done so there's no synthesis ambiguity, etc. In the hands of an experienced RTL engineer you can more or less exactly understand/infer their logic footprint just from reading the code, just like Verilog. You can do Verilog annotations that get persisted in the compiler output to help the synthesizer and all that stuff. Despite that, you still hear all the exact same complaints ("not good enough" because it used a few extra LUTs due to the synthesizer being needy, despite the fact RTL people already admit to spending stupid amounts of time on pleasing synthesizers already.) Died-in-the-wool RTL engineers are certainly a conservative bunch, and cagey about this stuff no matter what, it's undeniable.

I think a bigger problem is things like tooling which is deeply invested in existing RTLs. High-end verification tools are more important than just the languages, but they're also very difficult to replicate and extend and acquire. That includes simulation, debuggers, formal tools, etc. Verification is where all the actual effort goes, anyway. You make that problem simpler, and you'll have a winner regardless of what anyone says.

You mention the Intel and Xilinx's software groups, but frankly I believe it's a good example of the bigger culture/market problem in the FPGA world. FPGA companies desperately want to own every single part of the toolchain in a bid for vertical integration; in theory it seems nice, but it actually sucks. This is the root of why everyone says Quartus/Vivado are shitware, despite being technically impressive engineering feats. Intel PSG and Xilinx just aren't software companies, even if they employ a lot of programmers who are smart. They aren't going to be the ones to encourage or support alternative RTLs, deliver integrated tools for verification, etc. It also creates perverse incentives where they can fuel device sales through the software. (Xilinx IP uses too much space? Guess you gotta buy a bigger device!) Oh sure, Xilinx wants you to believe that they're uniquely capable of delivering P&R tools nobody else can — the way RTL engineers talk about the mythical P&R algorithms, you'd think Xilinx programmers were godly superhumans, or they were getting paid by Xilinx themselves — that revealing chip details would immediately mean their designs would be copied by Other Electronics Companies and they would crumble overnight despite the literal billions you would need up-front to establish profitability and a market position, and so on. The ASIC world figured out a long time ago that controlling the software just meant the software was substandard.

Re: XLS: Accelerated HW Synthesis

#47
I've got a Kahn-process-network based "simulation" framework, intended to provide a smooth conveyor belt of product maturation from prototypes written in high level scripting languages like Python or MATLAB through to production code written in C or Ada. (Sort of like Simulink, but with a different set of warts). Having some hardware synthesis capability is very much on the roadmap, and this looks like it's going to be worth investigating for that. Very excited to dive into it!

Re: XLS: Accelerated HW Synthesis

#48
post #36
post #31

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

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 th…

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

Re: XLS: Accelerated HW Synthesis

#49
post #36

Earlier quoted context omitted.

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 th…

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

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
Post reply on HN