You can execute some nix commands to fire up an emulator for this CPU design? That's pretty cool, I wonder how hard it'd be to reduce it to a docker command?
Also, I'd never heard of Chisel but it looks amazing - software defines hardware via a Python-esque DSL to Verilog compiler.
Chisel is just a Scala library to generate SV. I haven't actually used it but I've used similar systems and a really big problem with them is debugging. The generated SV tends to be unreadable and you will spend a lot of time debugging it.
Chisel has a similar competitor called SpinalHDL that is apparently a bit better.
IMO using general purpose languages as SV generators is not the right approach. The most interesting HDL I've seen is Filament. They're trying to do for hardware what Rust has done for software. (It's kind of insane that nobody has done that yet, given how much effort we put into verifying shitty SV.) Haven't tried it yet though.
The real reason to use those languages is because they often lend themselves to using the meta-language for other purposes, like writing flexible open ended test suites, or using some forms of code generation/metaprogramming to generate parts of the design from other things. That's very useful and one of the attractive properties of systems like Amaranth or Clash, and one of the downsides (IMO) of approaches like Filament or Bluespec. That said, the most important bits about Filament and Bluespec are their high-level concepts (like guarded actions and timeline types), which could be adopted into other RTLs as well.
At the end of the day though, sometimes you just have to debug a netlist, and that probably will remain true of Filament too. (Any language with higher-order applicative concepts will eventually run into some issues with wire names, etc, that's just unavoidable.) I think the SystemVerilog or whatever is just a red herring at that point; the tools for doing netlist debugging all feel like the equivalent of having to debug compiler assembly output with no debug symbols. Making sure you need to reach for the debugger much less is a good first step, but I'm not sure how to improve this part.
Yeah I agree that debugging generated SV is like debugging assembly and you rarely have to do that when writing normal programs. I think the difference is tooling. I can fire up an IDE debugger and have full access to all the relevant information and controls without seeing any assembly.
I don't know of any compile-to-SV tools that have a debugger anywhere near as capable as that. They definitely should! But they don't right now, so we're stuck at debugging RTL.
It’s not that hard to debug— your signal names and register names all carry through. Sure, lots of temp wires get generated but that’s never where your bug is.
Maybe. I haven't used it. But with the compile-to-SV language I do use you're right it generates a lot of temporary wires and the bugs are never there, but they make it extremely tedious to trace drivers from the point of failure back to the cause.
You can execute some nix commands to fire up an emulator for this CPU design? That's pretty cool, I wonder how hard it'd be to reduce it to a docker command?
Also, I'd never heard of Chisel but it looks amazing - software defines hardware via a Python-esque DSL to Verilog compiler.
https://github.com/chipsalliance/chisel