For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use of verilog style guides and decent linting tools solves most of the problem. You do still get bugs caused by missed typing issues but they're usually quickly caught by simple tests. It's certainly annoying to have to deal with all of this but fundamentally if it's all made easier it's not significantly improving your development time or final design quality.
Another typical improvement you'll find in an alternative HDL is vastly improved parameterization and generics. Again this is great to have but mostly makes tedious and annoying tasks simpler but doesn't produce major impact. The reason for this is writing good HDL that works across a huge parameterisation space is very hard. You have to verify every part of the parameter space you're using and you need to ensure you get good power/performance/area results out of it too. To do this can require very different micro architectural decisions (e.g. single, dual and triple issue CPUs will all need to be built differently improved parameterization doesn't save you from this). Ultimately you often only want to use a small portion of the parameter space anyway so just doing it in system verilog possibly with some auto generated code using python works well enough even if it's tedious.
So if the practical benefits turn out to be minor why not take all the nice quality of life improvements anyway? There's a large impact on the hard things. From a strictly design perspective these are things like clock domain crossing, power, area and frequency optimization. Here you generally need a good understanding of what the actual circuit is doing and to be able to connect tool output (e.g. the gates your synthesis tool has produced) and your HDL. Here the typical flow of HDL -> SystemVerilog -> tool output can become a big problem. The HDL to SystemVerilog step can produce very hard to read code that's hard to connect to your input HDL. This adds a new and tricky mental step when you're working with the design, first understand the circuit issue then map that to the hard to read SystemVerilog then map that to your HDL and work out what you need to change.
Outside of design alone a major cost of building silicon is verification. Alternative HDLs generally don't address this at all and again can make it harder. Either you entirely simulate the HDL itself which can be fine but then you're banking on minimal bugs in that simulator and there's no bugs in the HDL -> SystemVerilog step. Alternatively you simulate the SystemVerilog directly with an existing simulator but then you've got the HDL to SystemVerilog mapping problem all over again.
I think my ideal HDL at this point is a stripped down SystemVerilog with a good type system, better generative capability that crucially produces plain system verilog that's human readable (maintaining comments, signal and module names and module hierarchy as much as possible).
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.
[3] https://circt.llvm.org/docs/Dialects/Debug/
[4] https://sifive.zoom.us/rec/share/MhHtXPg_7iZk-QWw0A66CaBJDGs...
> good PPA with popular backend tools
Getting good PPA for any given thing you can express in the language is only part of the problem. The other aspect is how easy does the language make it to express the thing you need to get the best PPA (discussed in example below)?
> Think of it like a source map that allows you to jump back and forth between the final System Verilog and the source HDL.
This definitely sounds useful (I wish synthesis tools did something similar!) but again it's only part of the puzzle here. It's all very well to identify the part of the HDL that relates to some physical part of the circuit but how easy is it to go from that to working out how to manipulate the HDL such that you get the physical circuit you want?
As a small illustrative example here's a commit for a timing fix I did recently: https://github.com/lowRISC/opentitan/commit/1fc57d2c550f2027.... It's for a specialised CPU for asymmetric crypto. It has a call stack that's accessible via a register (actually a general stack but typical used for return addresses for function calls). The register file looks to see if you're accessing the stack register, in which case it redirects your access to an internal stack structure and when reading returns the top of the stack. If you're not accessing the stack it just reads directly from the register file as usual.
The problem comes (as it often does in CPU design) in error handling. When an error occurs you want to stop the stack push/pop from happening (there's multiple error categories and one instruction could trigger several of them, see the documentation: https://opentitan.org/book/hw/ip/otbn/index.html for details). Whether you observed an error or not was factored into the are you doing a stack push or pop calculation and in turn factored into the mux that chose between data from the top of the stack and data from the register file. The error calculation is complex and comes later on in the cycle, so factoring it into the mux was not good as it made the register file data turn up too late. The solution, once the issue was identified, was simple, separate the logic deciding whether action itself should occur (effectively the flop enables for the logic making up the stack) from the logic calculating whether or not we had a stack or register access (which is based purely on the register index being accessed). The read mux then uses the stack or register access calculation without the 'action actually occurs' logic and the timing problem is fixed.
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. Simply having a mapping saying this gate relates to this source line only gets you so far, especially if you've got abstractions in your language such that a single source line can generate complex structures. You need to be able to easily understand how all those source lines relate to one another to create the path to choose where to optimise something.
Then there's the optimization itself, pretty trivial in this case as it was isolated to the register file which already had separate logic to determine whether we were actually going to take the action vs determine if we were accessing the stack register or a normal register. 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. How about where the issue isn't isolated to a single module and spread around (e.g. see another fix I did https://github.com/lowRISC/opentitan/commit/f6913b422c0fb82d... which again boils down to separating the 'this action is happening' from the 'this action could happen' logic and using it appropriately in different places).
I haven't spend much time looking at Chisel so it may be there's answers to this but if it gives you powerful abstractions you end up having to think harder to connect those abstractions to the physical circuit result. A tool telling you gate X was ultimately produced by source line Y is useful but doesn't give you everything you need.
> 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 > 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.
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. Sure if you need to generate IP-XACT for literally thousands of variations of some piece of IP this kind of things is essential but practically you have far fewer variations you actually want to work with and the manual work required is annoying busy work that will generate some issues but you can deal with it. Then for the thousand of variations case the good old pile o' python doing auto-generation can work.
Certainly having a solution based upon a well designed language with a sound type system sounds great and I'll happily have it but not if this means things like timing fixes and ECOs become a whole lot harder.
Thanks for the link to the video I'll check it out.
Maybe I should make one of my new year's resolution to finally get around to looking at Chisel and CIRCT more deeply! 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...
> 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