mikeurbach

I gave a short talk about compiling PyTorch to Verilog at Latte '22. Back then we were just looking at a simple dot product operation, but the approach could theoretically scale up to whole models.

https://capra.cs.cornell.edu/latte22/paper/2.pdf

https://www.youtube.com/watch?v=QxwZpYfD60g

To get to this fix you have two things to deal with, first taking the identified timing path and choosing a sensible point to target for optimization and second actually being able to do the optimization.

Because of SystemVerilog's lack of powerful abstractions making a tweak to get the read mux to use the earlier signal was easy to do but how does that work when you've got more powerful abstractions that deal with all the muxing for you in cases like this and the tool is producing the mux select signal for you.

Thanks for the example and illustrating a real world change. In this specific case, Chisel provides several kinds of Mux primitives[1], which CIRCT tries to emit in the form you'd expect, and I think Chisel/CIRCT would admit a similarly simple solution.

That said, there are other pain points here where Chisel's higher-level abstractions make it hard to get the gates you want, or make a simple change when you know how you want the gates to be different. A complaint we hear from users is the lack of a direct way to express complex logic in enable signals to flops. Definitely something we can improve, and the result will probably be new primitive constructs in Chisel that are lower-level and map more directly to the System Verilog backend tools expect. This is one example of what I was alluding to in my previous reply about new primitives in Chisel.

Your example here certainly sounds useful but to me at least falls into the bucket of annoying and tedious tasks that won't radically alter how you design nor the final quality and speed of development.

I guess it depends on your goals. I spoke[2] about CIRCT and the new features in this realm at Latch-Up 2023, and after the talk people from different companies seemed very excited about this. For example, someone from a large semiconductor company was complaining about how brittle it is to maintain all their physical constraints when RTL changes.

Maybe I should make one of my new year's resolution to finally get around to looking at Chisel and CIRCT more deeply!

We'd love to hear any feedback!

Could even have a crack at toy HDL in the form of the fixed SystemVerilog with a decent type system solution I proposed above using CIRCT as an IR...

That's exactly what the CIRCT community is hoping to foster. If you're serious about diving in, I'd recommend swinging by a CIRCT open design meeting. The link is at the top of the CIRCT webpage. These can be very informal, and we love to hear from people interested in using CIRCT to push hardware description forward.

[1] https://www.chisel-lang.org/docs/explanations/muxes-and-inpu...

[2] https://www.youtube.com/watch?v=w_W0_Z3n9PA

Disclaimer: I work on Chisel and CIRCT, and these opinions are my own.

These are good points, and I think Chisel is actually improving in these areas recently. Chisel is now built on top of the CIRCT[1] compiler infrastructure, which uses MLIR[2] and allows capturing much more information than just RTL in the intermediate representations of the design. This has several benefits.

Regarding the problem of converting from HDL to System Verilog, and associating the tool outputs to your inputs: a ton of effort has gone into CIRCT to ensure its output is decently readable by humans _and_ has good PPA with popular backend tools. There is always room for improvement here, and new features are coming to Chisel in the form of intrinsics and new constructs to give designers fine grained control over the output.

On top of this, a new debug[3] intermediate representation now exists in CIRCT, which associates constructs in your source HDL with the intermediate representation of the design as it is optimized and lowered to System Verilog. Think of it like a source map that allows you to jump back and forth between the final System Verilog and the source HDL. New tooling to aid in verification and other domains is being built on top of this.

Besides this, the combination of Chisel and CIRCT offers a unique solution to a deeper problem than dealing with minor annoyances in System Verilog: capturing design intent beyond the RTL. New features have been added to Chisel to capture higher-level system descriptions, and new intermediate representations have been added to CIRCT to maintain this information and its association to the design. For example, you could add information about bus interfaces directly in Chisel, and have a single source of truth generate both the RTL and other collateral like IP-XACT. As the design evolves, the collateral stays up to date with the RTL. I gave a talk[4] at a CIRCT open design meeting that goes into more detail about what's possible here.

[1] https://circt.llvm.org/

[2] https://mlir.llvm.org/

[3] https://circt.llvm.org/docs/Dialects/Debug/

[4] https://sifive.zoom.us/rec/share/MhHtXPg_7iZk-QWw0A66CaBJDGs...

Since you brought up Sasa Juric, I will second that and also mention their book Elixir in Action. It really helped me get from toy examples to feeling confident running the BEAM in production. This is of course Elixir-centric, but the parts about OTP, inspecting running applications, etc. are really about the BEAM.

I used to go very deep on philosophical discussions about the nature of sandwiches with my friends. I’m still digesting the cube rule, but here’s what we came up with:

Every sandwich has an axis. The axis is through the filling. You can roughly divide all sandwiches based on whether you eat along the axis (what we called axially), or around it (what we called radially).

A burrito is consumed axially, while a crunchwrap supreme is consumed radially.

Hope this is interesting, we’ve found pretty much every sandwich can be classified as radial or axial, which seemed like an achievement.

We had the pleasure of hosting Dr. Manohar at a CIRCT weekly discussion session earlier this year. He presented much more recent work if anyone is interested. The talk and discussion was recorded here: https://sifive.zoom.us/rec/play/Bg99_niHh9OG_8uE_nhaz6otxvA0...

EDIT: talk begins around 7 minutes.

I contribute to CIRCT, so I feel like I should chime in here. I personally hope that it can provide exactly the kind of unifying IRs we are all hoping for in the open-source community. The fact that the tools are implemented in C++ may be a win for some, but I think the CIRCT project is compelling for much deeper reasons. The README states the ambition clearly:

By working together, we hope that we can build a new center of gravity to draw contributions from the small (but enthusiastic!) community of people who work on open hardware tooling.

There are weekly community meetings that are open to the public, and we have guest speakers from all sorts of interesting projects in the open-source community. Many of those are leading to collaborations and contributions to CIRCT.

There hasn't been much (any?) discussion of CIRCT on HN, but rather than present the reasons I think it's so great here, I'll point to a talk[1] I gave earlier this year and a much better talk[2] Chris Lattner gave shortly thereafter, both of which lead up to the "Why CIRCT?" question in the second half.

Looking back at that SymbiFlow thread, I see familiar faces that are now actively contributing to CIRCT. There are mentions of many different hardware IRs in some of the posts, but at least three have first-class support in CIRCT today: FIRRTL[3], LLHD[4], and Calyx[5]. This is all very recent and experimental, but I would say the results are already promising.

[1] https://slideslive.com/38955645/applying-circuit-ir-compiler...

[2] https://www.youtube.com/watch?v=4HgShra-KnY

[3] https://circt.llvm.org/docs/Dialects/FIRRTL/

[4] https://circt.llvm.org/docs/Dialects/LLHD/

[5] https://circt.llvm.org/docs/Dialects/Calyx/

I've been enjoying placing a drop right along the divide and seeing which way it goes. For example, up near Lenawee Mountain (aka A-basin). I've also noticed that up there, sometimes there is no route to either ocean. I guess it ends up in a high-alpine catchment and stays on the divide.

There was some interesting discussion between the LLHD[1] and MLIR[2] folks about just this topic recently[3]. My takeaway: modeling behavioral HDL semantics in the IR is a huge mess that has to account for all of the complexity in the existing HDL landscape. However, there is hope for modeling structural HDL semantics in an IR that could be the target for many languages.

You mentioned LLVM, and I think of MLIR as sort of a successor to LLVM. I'm hopeful that a low-level HDL IR is standardized as an MLIR dialect, so the compiler ecosystem and the hardware ecosystem can start to unite.

[1] https://news.ycombinator.com/item?id=22825107 [2] https://news.ycombinator.com/item?id=22429107 [3] https://drive.google.com/file/d/1x7B0IRdcJ5JBQvfHbPUBcShbTFC...

I find it fascinating this research and MLIR[1] seem to have been developed independently around the same time. Figure 1 tells the same story in both papers. The authors mention the possibility of representing their concepts in MLIR, which could be really interesting.

[1] https://arxiv.org/pdf/2002.11054.pdf

When I read the headline and saw the source, I assumed this would be about GraphQL. I know Instagram utilizes GraphQL, for example on the web client, so now I'm wondering how that fits in.

For the last year or so, I've been fascinated by this concept, and I've been exploring language oriented programming with Racket. There was some discussion on this topic and the Beautiful Racket book here a while back [1]. That book is the best introduction I've found to the idea that you can build your notation to the problem you are solving.

Re: painting yourself into a corner, it is true that you can't retreat to Stack Overflow for help debugging your DSL, but the Racket documentation is some of the best I've seen, and common problems do pop up on SO.

[1] https://news.ycombinator.com/item?id=19232068

I'm just finishing up the last tutorial, and I highly recommend this as well. I made one traditional C compiler back in college with flex and bison, which I consider an invaluable experience, but I've always wanted to tap in to the power of Scheme for developing new languages. I had some false starts on my own and with mediocre tutorials, but in the end Beautiful Racket was exactly the kind of pedagogy I needed.

I learned the most by reading and writing about great speeches in high school English. Lincoln's Gettysburg Address, Marc Antony's speech in Julius Caesar, and JFK's moon speech all come to mind. Understanding why these were effective is like drilling the fundamentals in sports or music. Once you have internalized the rhetorical devices that the greats deployed, you can start to use them in your own writing.

  Sadly, I have even less to say about OTP given my limited knowledge of it. I would really like to have another course that would focus more on it.

Some people are actively working on formal verification for Rust. The RustBelt project is the first that jumps to mind. A paper and some discussion here: https://news.ycombinator.com/item?id=16302530

I can't comment on this specific course, but I took a compilers course from Tom Cormen that completely changed how I thought about computing. After several years in industry, it's not so much the specific techniques of constructing a compilers that remain useful, but the mode of thinking I learned.

I had an AHA moment along the lines of "Wow, the compiler writer is basically God." I had taken courses in software development and hardware architecture, but after writing a compiler I saw first-hand how a program--a description of a solution to a problem in a human readable language--is converted to the same description in a hardware readable language. The meaning of the program must be preserved by the compiler, but otherwise it has the freedom to generate any one of potentially many outputs that preserve the meaning.

There is a beauty I realized in the relationship between the programmer, the programming language, the compiler, and the hardware architecture. They are all in cahoots, but the compiler is the cornerstone. That relationship doesn't directly affect my decisions as a professional software engineer, but it forms the backdrop upon which I think about the act of programming and computing in general.

Couldn't agree more. It seems like "algorithm" is starting to be used among the non-tech world to refer to the computerization of everything in a negative way. Really, an algorithm is a mathematical formulation of how to solve a problem, albeit usually ran on computers. If True & Co. want to apply a little machine learning to an old problem, fine. If people think that machines can't learn, then we're going to have these sort of issues.