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…
XLS: Accelerated HW Synthesis
41–50 of 55 posts
Re: XLS: Accelerated HW Synthesis
#42>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…
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>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…
Re: XLS: Accelerated HW Synthesis
#44Earlier 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?
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
#45Earlier 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
Re: XLS: Accelerated HW Synthesis
#46Earlier 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 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
#47Re: XLS: Accelerated HW Synthesis
#48>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…
Re: XLS: Accelerated HW Synthesis
#49Earlier 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?
Re: XLS: Accelerated HW Synthesis
#50Reminds me of the old reconfigure.io which used the ideas and syntax of Go's CSP and transformed them into async HDL code. Unfortunately the startup has been shuttered. http://docs.reconfigure.io/