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

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.

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!

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!

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!

Did you see the "using tfcompile" section of the docs? https://www.tensorflow.org/versions/master/experimental/xla/...

If you're looking for more detailed information that's missing from the docs, please do file a Github issue about it. Thanks!

It's gpucc, so it builds from LLVM when you enable XLA in the TF configure step.

Trying to understand: you don't want to ship a compiler library on principle, or is it some kind of product requirement, or ? There's lots of cool work to be done in the compiler space so use cases help to prioritize. :-) Thanks!

AOT for GPUs is doable. Do you have a killer use case?

For CPU, mobile code footprint reduction was the driving force.

The XLA and vanilla TF variants appear to be the same here:

https://github.com/tensorflow/tensorflow/blob/2c8d0dca978a24...

https://github.com/tensorflow/tensorflow/blob/2c8d0dca978a24...

Chalk it up to poetic license? ;-)