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