High-Level Synthesis for RISC-V
semiengineering.com
semiengineering.com
In processor micro-architecture the hard problems come when you're trying to hit a frequency, power or area target. You may need to do some interesting things that can be quite circuit specific and have complex tradeoffs (e.g. perhaps you choose to handle some corner case that produces a large timing path with some kind of stall or replay when it occurs, is the corner case sufficiently infrequent that overall you get a performance increase?). Having some high level way to sweep through the design space here would be incredibly useful, but the problem is building each point of the design space can be its own complex task.
Having a high level description you can easily fiddle with in order to try different kinds of complex instructions, easily play around with structure sizing and the like sounds great. The problem is if it doesn't produce a design that's as optimal as the hand-coded RTL could be you might get the best design for your application that the tool can make but it gets outperformed by a more standard design that's normal hand-coded RTL.
It's tempting to compare to software, where high-level code is often preferred even if it's not the most efficient due to the other benefits it brings but chips have certain fixed manufacturing costs that just aren't present in software. Due to these costs it's often better to put more into the design, by more detailed low-level work, in order to get a more optimal design.
Though that said I really need to spend some more time with these higher-level tools. I'm sure there's some great stuff to be done with them.
While I'm not claiming that this is a perfect implementation, the VLSI design world is definitely ripe for newer, higher level, and more open source design languages and tools. There will always be performance critical designs that lower level languages will be useful for, similarly how there will always be performance critical code that will be written in C/C++ and assembly.
And yes, I'm aware of most of the alternative HDLs, and open source EDA tools out there, and I have varying opinions about them. I understand the limitations of building hardware and why we do things the way we do. But I think it's incredibly naive to think that we can't apply more mindsets from software engineering to hardware engineering. We just happen to be in a market where good hardware engineers can get paid more as a software engineer. I call this out because I get the push back from so many people in my industry, and they sound like (what I would imagine) Autodesk developers sound like when Blender gets brought up in a conversation.
Verilog definitely has looser numeric typing. It tripped up a friend of mine yesterday. I’ve been doing this stuff forever so I don’t think about it much, and I’m grateful for the simplified math it affords.
Disagree on IDE support because vscode support for SV at least is pretty nice. And sigasi is still doing well. But I’m old school I guess and prefer vim/nvim. I actually do a hybrid thing where I’ll use nvim in the vscode terminal to do some quick edits for something not In the workspace every now and then.
SystemVerilog smoothed over some of the ugliness of verilog, but then bolted on at least three other languages into one with the semantic inconsistencies you mention. Particularly No idea what the rational was there, if any.
But I never found it to be a significant barrier to learning. I’ve done experiments with writing an HDL in Clojure that would compile to SV, and it was fun, but it just created a new set of problems. Much better to work in a standardized language warts and all.
Yes, you can get better results with hand-coding the RTL, and indeed with hand-placing the resulting transistors and even making them different sizes depending on the fan-out required etc.
The question is: can you AFFORD to?
SiFive use Chisel to design all their CPUs.
Their original 32 bit FE310 back in late 2016 ran at 320 MHz on a 180nm process -- absolutely killing the frequencies ARM Cortex M3/M4 were available in at the time (or now .. 180 MHz is still the fastest I'm aware of)
SiFive's FU540 with quad core U54 64 bit cores ran at 1.5 GHz on a 28nm process in early 2018, as do the quad dual-issue U74 cores in their FU740 this year.
Sure, you can do better with hand design, but it costs $billions. Only Intel, AMD, and Apple have that kind of money to spend.
Combined with that will be modeling at various levels. C++ models can be used for performance exploration for instance. Cycle accurate (or close to cycle accurate) models for the CPU are useful but also hard to work with. You may well be developing the accurate model in combination with the CPU itself. In early design work you'll hack features into an older model just to see how they might work in isolation or even just stare at some spreadsheets with performance counters and make an educated guess as to how some new feature or structure will effect them and use that to calculate potential performance increases.
Roughly speaking, comparable to what's in a Pi 4, vs the roughly Pi 3+ SiFive U74 cores in the cancelled board.