[BooneJS]

These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase.

No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog function) and you just don't have 3 weeks of runtime to go from verilog to GDSII again. Or you want to make a metal-only respin that only changes one $0.xM mask layer and requires 8 weeks of fab time instead of changing multiple metal layers including the base and needs 16 weeks and a $xM payment.

Programming language design is quite rich because they used to cross-compile to C, and now they generally generate LLVM IR. It doesn't matter what the bug is in the final binary; you're not going to hex edit the binary like you would with a single metal layer of a 300mm wafer. You're just going to recompile and it generally doesn't matter if one machine instruction changes or 1M do because unlike verilog, not even GHC needs 3w to compile a program.

source: I've been on chip design teams for 2 decades and finally gave up on fighting verilog.

[0]: Electronic Design Automation. Synopsys, Cadence, Siemens, Ansys, etc.

[ninjha]

I think Chisel's main win is that it is great from an open-source research perspective.

Taking advantage of the functional nature of Chisel enables a set of generators called Chipyard [0] for things like cores, networking peripherals, neural network accelerators, etc. If you're focusing on exploring the design space of one particular accelerator and don't care too much about the rest of the chip, you can easily get a customized version of the RTL for the rest of your chip. Chisel handles connecting up all the components of the chip. All the research projects in the lab benefit from code changes to the generators.

Chisel even enables undergraduate students (like me!) to tape out a chip on a modern-ish process node in just a semester, letting Chisel significantly reduce the RTL we have to write. Most of the remaining time is spent working on the physical design process.

[0]: https://github.com/ucb-bar/chipyard

[1]: https://classes.berkeley.edu/content/2023-Spring-ELENG-194-0...

[BooneJS]

Awesome! When I was an undergraduate all I could tape out was a small wafer of capacitors and correlate theoretical vs silicon.

Chisel is no doubt a developer velocity booster. And generating those components does help speed you along especially when they’re silicon proven.

But I’d wager that most industry silicon has a competitive edge to pay off the NRE, something bleeding edge that can’t get away from verilog interop.

[tverbeure]

I don't understand your point.

Chisel, SpinalHDL, Clash, Migen, Amaranth, and RTL variants generate synthesizable RTL Verilog in the end. From that point of view, they are compatible with any existing ASIC flow.

The only problematic aspect is that most companies use line and conditional coverage as one of their sign-off criteria. That's hard to do with automatically generated Verilog.

But here's the kicker: HLS-generated Verilog is orders of magnitude worse in terms of readability, and yet most recent ASICs with video codecs are design with HLS and derived from HLS reference implementations. And forget about doing traditional coverage metrics just on that RTL just the same.

If HLS-generated Verilog is fine for an ASIC flow, then alternatives like Chisel and friends are much less problematic.

[xw3089]

There are tons of other practical problems. The HLS generated verilog is name mangled. This makes it really hard to generate all the various control files you need to run the EDA flow, the software that assists in turning verilog into manufacturing files. If you have a super stable design, like a codec, then you can deal with it because it’s basically a waterfall development cycle. But if you have a design whose requirements are changing as you develop it, like most things. HLS doesn’t fit into the existing organizational structures and you’ll end up with a less optimal circuit.

[Dolu]

> The HLS generated verilog is name mangled

Chisel, SpinalHDL, Clash, Migen, Amaranth aren't HLS

Most of the time, if you get some verilog out of those tools with mangled names, it can be because of bad coding practice.

Here is some examples about how to preserve good names for SpinalHDL : https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/S...

[tverbeure]

This is not true for SpinalHDL and Amaranth/migen (I can’t speak about Chisel): the names of registers and IO ports are totally predictable and there’s no issues generation timing constraints, placement constraints etc.

If our backend team doesn’t complain about HLS, it most certainly won’t complain about RTL generators.

FWIW: the codecs are not super stable designs at all. They’re under constant development.

For modern ASICs, layout partitions are so large that your backend tools see hundreds of thousands of instances that are on the same clocks. The synthesis tools may have special recipes for optimization (which, again, you can still do), but the backend flow is mostly concerned with meeting timing on that clock. Except for external IOs, it’s rare to have specialty timing constraints at within partitions.

[phkahler]

Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers?

I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't good enough for general software development (can't write hello world for example) not because I worry about patching generated code.

[sweden]

The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog.

I work at a very big semiconductor company and we did some trials with implementing the exact same hardware we had in Verilog but on an high level HDL and while development could be faster, we ended up with worse PPA (Power, Performance and Area). If you try to improve this PPA, you just end up bypassing the advantages of high level HDLs.

On top of that, it raises a lot of questions on verification: are you going to do verification (testbenches) in the Chisel code or in the generated Verilog code from Chisel? If you do it in Chisel, how do you prove that Chisel didn't introduce bugs in the generated Verilog code (which is what you will end up shipping to the foundry for tape out after synthesis and place & route)? If you do it in the generated Verilog code, how do you trace the bugs back to the Chisel code?

I do think that we need a new language but not for design. Verilog/System Verilog is fine for hardware design, we don't need to reinvent the wheel here. We will always end up in Verilog in our synthesis and quite frankly, we don't spend that much time writing Verilog for hardware design. Hardware design is 5 lines of code and that's it. The real cost of hardware development is the other side of the coin, which is hardware verification.

If hardware design is 5 lines of code, hardware verification is 500 lines. Writing testbenches and developing hardware verification environments and flows is essentially normal programming and we are stuck in System Verilog for that, which is a very bad programming language. Using System Verilog as a programming language is so prone to unintended bugs in your testbenches and bad programming constructs.

This is what we should try to improve, verification not design. We spend far too much time in hardware verification and a lot of that time is spent dealing with pitfalls from System Verilog as a programming language.

I wish people would be investing more thinking here rather than trying to make hardware design friendlier for programmers.

[clhodapp]

... these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality.

It is a common misconception that Chisel is yet another high level synthesis language with these drawbacks, however it is not. It simply allows you to write your own high level abstractions on top of exact low-level synthesis primitives.

[mrmax99]

You may find ROHD to be interesting, since it takes a very serious approach to verification and even has a simulator built-in! https://intel.github.io/rohd-website/

[xw3089]

You’re preaching to the choir on improving validation. Like you mentioned, In commercial designs that’s where a majority of the man hours actually go, and coincidentally where basically none go in academia where chisel is popular.

I will mention though, not all IP needs max PPA or specific control of the netlist and there could be initial opportunities there. Especially with the cost per area on many nodes going significantly down it can be more economical, at some volumes, to save man hours with HLS even if it leads to larger areas, which in theory means more production cost but in reality might not even change the floor plan.

I think we’re going to see more HLS, not less.

[BooneJS]

I worked at a startup company that created a DSL to generate verilog. We had the designers do unit testing in the DSL but “sign-off” verification was still UVM w/generated verilog. When a hidden bug costs millions of dollars, you can’t take the risk.

[codedokode]

Cannot one write tests in Python? Python seems much nicer to use language. Sadly, I found no library that would allow to create an instance of verilog model from Python and control it (cocotb doesn't allow this).

[BooneJS]

I verified verilog using the Vera language back in the day. The largest test benches would take 5s to compile to interpreted bytecode. Verification engineers rarely change the design, so keeping that part compiled is great for productivity. It’s really too bad that monolithic compilation is so dang slow.

[duped]

Chisel isn't some toy, it's actually used in industry. IIRC SiFive's portfolio is built on it.