Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XLS: Accelerated HW Synthesis

google.github.io

Post reply on HN
Print view View original

31–40 of 55 posts

Re: XLS: Accelerated HW Synthesis

#31

Post by 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.

Re: XLS: Accelerated HW Synthesis

#32

Post by Traster »

typon wrote: post #15
jeffreyrogers wrote: post #10

This is interesting. Overall I'm bearish on high-level synthesis for anything requiring high performance, since you typically need to think about how your code will be mapped to hardware if you want it to perform well, and adding abstractions interferes with that. I would like to know more about how Google uses this, since it doesn't seem like a good fit for the type of stuff I work on.

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 team of hundreds of engineers working on HLS, Xilinx probably has almost as many, there are lots of smaller companies working on their own things like Maxeler. They haven't take off because it's an unsolved problem to automate some of the things you do in Verilog efficiently.

Take this language for example - it cannot express any control flow. It's feed forward only. Which essentially means, it is impossible to express most of the difficult parts of the problems people solve in hardware. I hate Verilog, I would love a better solution, but this language is like designing a software programming language that has no concept of run-time conditionals.

Re: XLS: Accelerated HW Synthesis

#33

Post by Traster »

Connect12A22 wrote: post #12

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_s...

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, opcode as u7)
  }
here's the systemverilog solution

  {im_11_0,rs1,funct3,rd,opcode}
Obviously, in software, you can't slice data in the same way since as far as I can tell, it's assuming all variables are a certain size and so there's no naturally way of bit slicing.

Re: XLS: Accelerated HW Synthesis

#34

Post by FullyFunctional »

zelly wrote: post #20
jashmenn wrote: post #2

I've been programming for 20 years and yet I have no idea what this does. Can someone ELI5?

Verilog for codemonkeys

That's a complete mischaracterization. The point of any and all HLSes is to raise the level of abstraction so you can be more productive. Even for highly skilled Verilog "monkies", writing in an HLS is a great deal faster and less error prone (assuming comparable mastery of the language) simply because you do not need to deal with a lot of low level details.

The $1M question however how this experience pans out as you try to squeeze out the last bit of timing margin. I don't know, but I'm eager to find out.

ADD: this parallels the situation with CUDA where writing a first working implementation is usually easy, but by the time you have an heavily optimized version ...

Re: XLS: Accelerated HW Synthesis

#35

Post by nickysielicki »

zelly wrote: post #20
jashmenn wrote: post #2

I've been programming for 20 years and yet I have no idea what this does. Can someone ELI5?

Verilog for codemonkeys

HLS is going to improve, and you can either disregard it and be left behind or you can try to understand where it fits into a design. Your choice.

Re: XLS: Accelerated HW Synthesis

#36

Post by learyg »

Traster wrote: 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 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!

Re: XLS: Accelerated HW Synthesis

#37

Post by learyg »

Traster wrote: post #33
Connect12A22 wrote: post #12

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_s...

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 there's no conceptual reason it can't be done, I think that'd be an interesting thing to prioritize if there's good bang for the buck. [Github issue to track!](https://github.com/google/xls/issues/131) Let me know if I missed out on details or rationale, thanks!

Re: XLS: Accelerated HW Synthesis

#39

Post by FullyFunctional »

Traster wrote: post #33
Connect12A22 wrote: post #12

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_s...

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…

That's untrue. You need to include the declarations of im_11_0, etc. for the above to work and then you end up with just as much code. There's no reason they couldn't extend match to operate on bit slices also which would make this identical.

Frankly, combinatorics is not where I expect the most interesting differences. Sequential logic is surely more interesting.

Re: XLS: Accelerated HW Synthesis

#40

Post by learyg »

jeffreyrogers wrote: post #10

This is interesting. Overall I'm bearish on high-level synthesis for anything requiring high performance, since you typically need to think about how your code will be mapped to hardware if you want it to perform well, and adding abstractions interferes with that. I would like to know more about how Google uses this, since it doesn't seem like a good fit for the type of stuff I work on.

Hi, one of the collaborators here! One question to consider, and one that I consider pretty frequently, is what the hard difference really is between HLS and RTL. It seems up to interpretation, but I think of it more as a spectrum than anything that truly schisms the space. I think I personally associate the term HLS with "trying to uplevel the design process where we can".

Even with modern RTL, we have a synthesizing compiler optimizing our design within a cycle boundary, trying to manage fanouts and close timing by duplicating paths and optimize redundant boolean formulas. Some will even do some forms of cross stage optimization.

If you think of XLS's starting point as "mostly structural" akin to RTL (instead of "loops where you push a button and produce a whole chip") it's really an up-leveling process, where there's a compiler layer underneath you that can assist you in exploring the design space, ideally more quickly and effectively, and trying to give you a flexible substrate to make that happen (by describing bits of functionality as much as possible in latency insensitive ways).

I like to think of it like [Advanced Chess](https://en.wikipedia.org/wiki/Advanced_chess) -- keep the human intuition but permit the use of lots of cycles for design process assist. It appears from what we've seen so far that when you have a "lifted" representation of your design such that tools can work with it well, composition and exploration becomes more possible, fun, and fruitful! I expect over time we'll have a mode where you still require everything closes timing in a single cycle when you explicitly want all the control you had / don't care so much for the assist, then you just get the benefits of the tooling / fast simulation infrastructure that works with the same program representation. It's a great space to be working in as somebody who loves compilers, tools, and systems: there's so much you could do, there's incredible opportunity!

Post reply on HN