Hacker News Reader

Comment by jashmenn | Hacker News Reader

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

As far as I can tell, it is a high-level synthesis tool for developing FPGA/ASIC applications. You write your circuit functions in a Rust-like DSL and it generates optimized Verilog/System Verilog code, which can then be synthesized into hardware. But you can also take the output of the DSL and simulate it first, which presumably is quicker than simulating Verilog.

You feed in Rust (a flavor called DSLX) or C++ and it generates code for your FPGA (in Verilog). You then upload this compiled "bitstream" to your FPGA and now you have something akin to a custom microprocessor, but running just your program.

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 syntax, although something similar to that can be achieved in C++ as well.

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

> Sometimes you need to put a ",", sometimes you don't

The rule is pretty simple: if you have curly braces you don't need a comma (and rustfmt will drop it), if you don't have curly braces you need a comma.

It is a project aimed at making the design of electronic logical easier.

Often, such hardware is written using hardware description languages [1] like Verilog or VHDL. These languages are very low level and, in the opinion of some, a little clumsy to use.

XLS aims to provide a system for High-level synthesis [2]. The benefit of such systems is that you can more easily map interesting algorithms to hardware without being super low level.

[1] https://en.wikipedia.org/wiki/Hardware_description_language

[2] https://en.wikipedia.org/wiki/High-level_synthesis

I remember years ago reading about Handel-C. A lot like Go with channels and threads and function calls. The way it synthesized the hardware was pretty simple conceptually. You could easily understand how the program flow was converted into a state machine in the hardware.

Not sure what happened it it. Maybe it did not optimize things enough.

https://en.wikipedia.org/wiki/Handel-C

https://babbage.cs.qc.cuny.edu/courses/cs345/Manuals/HandelC...

I worked on the Handel-C compiler :-) Then later used the language for a few years.

Its approach was intentionally simple conceptually. You could tell at a glance how many synchronous clock cycles each step would take, and roughly what logic would be produced, so it worked quite well for deterministic I/O and simple logic.

I found it a bit of a pain for high-throughput pipelining though, and personally prefer a compiler that has more freedom to auto-balance pipelines and retime logic.

I think Handel-C occupied a middle ground between other HLS, and Verilog/VHDL. It had the concise, C-like syntax of the former, with the predictability of the latter.

What happened to it was it transitioned from university to spin-out company Celoxica, and then was eventualy bought by Agility; then Mentor Graphics bought Handel-C while Agility folded, and Mentor seemed to mothball it.

For a while in the middle there was a decent business with great customers and a decent market cap, and something I'm not privy to resulted in the business folding. I don't think it failed due to insufficient code optimisation :-)

Not like you're 5 and I'm definitely not an expert on this project but here's my best shot...

Most programs are loaded into memory and parts of those programs are moved to registers and are used to load data into other registers. That data is, in turn, sent to logic units like adders that add two registers together or comparators that compare to register's values. The generality comes at a cost in terms of power and time but offers flexibility in return.

That is very different from something like a light switch where you flip the switch and the result continuously reflects that input within the limits of the speed of light.

If you are willing to sacrifice flexibility, translating your code into hardware gives you a device that runs the same processing on its inputs continuously at the speed of light subject to your information processing constraints (e.g. derivations of the original input still need to be calculated prior to use).

Traditionally, separate languages and greater hardware knowledge requirements made custom circuits less accessible. This project brings more standard, higher level languages into the set of valid specifications for custom electronics.

I think it turns a c-ish language (from the looks, not sure about semantics) into a hardware language like HDL.

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

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.

ditto

Thank god I'm not alone.

Reply on news.ycombinator.com