Verilator and a C or C++ CPU model are your friend when you are verifying a core like this. Verilator also lets you use C and C++ verification tools (which are extensive for good reason) to check for Verilog bugs and find corner cases.
Companies still using UVM (most of them) instead of models in software languages are going to have a terrible time trying to check that a CPU core is bug-free.
I 100% agree on verilator. It’s by far the most efficient tool for many simulation and verification needs. Hands down. Even more so if you are building CPUs
UVM definitely has its place still in verification flows. It for something as complex and flexible as a CPU for sure, it’s hard to beat the amount of cycles and coverage you get from verilator. (EDA license fees are a big part of that, but also the fact that verilator generates just C++ code you can integrate with the rest of your s/w flow is invaluable).
But: What is also important for CPU is good validation and compliance test, (random or replayed or directed) instruction stream generators, ISS to validate agains etc. There are so much more scenarios to check because a CPU needs to handle any sequence of any instructions flawlessly.
Those tools are also crucial. And they are being built or sold for RISC-V now too. And also: I much prefer combining those with verilator than with commercial eda tools. And don’t forget: before you start building a lot of RTL, you’ll typically will also build C based higher level performance models of the micro architecture, eg https://github.com/riscv-software-src/riscv-perf-model
I do worry the somewhat unconstrained nature of the RISC-V specification is going to lead to trouble down the line. Already some hints of that from this article:
> Take, for instance, the vector extensions. Every vendor that I’ve spoken to, and work with, has their own compiler, their own LLVM implementation in support of their vector extension. And none of them is compatible with the others
It doesn't help that development of an official compliance test suite seems to be moving very slowly (in part because it has to deal with this very issue of many possible options for what constitutes compliant behaviour). Shipping commercial implementations are running ahead of what the compliance suite can test and proprietary and in-house solutions are stepping in to fill the gap (supplied by someone like Imperas or built by the same company that builds the CPU).
We may end up with a bunch of RISC-V implementations with many subtle incompatibilities around architectural edge cases, it certainly won't make system level software work easy.
I think fragmentation is grossly exaggerated. Or at least, its effects are. It’s not like there’s a single universal ARM binary you can build and run on every SoC. At the very least the memory map will be different, the specifics of how peripherals behave is different, and often there are very vendor specific tool chains you need. x86 is different of course but there are two major x86 chip vendors after all.
We can take some lessons from Linux fragmentation - real and imagined - to see where all this will end up. Some things are still distribution specific but a lot of things like the FHS are indeed quite standardised. I think that’s where we will end up with RISC-V.
Vector is a very obvious place for fragmentation for two reasons; it’s only been a short time since it was ratified, so many of the implementations will be pure ratification, and since it constitutes many players’ competitive advantage they will tend to make it closed and proprietary.
>It’s not like there’s a single universal ARM binary you can build and run on every SoC.
That depends how widely you define SoC and what level of "binary" you mean.
For example a Linux userspace binary compiled for arm-linux-eabihf will run on most 32 bit ARM systems out there today and there is another one for 64 bit aarch64. So yes, it's not a universal ARM binary but its a long long way from being SoC specificic.
Vendor specific toolchains on ARM are pretty uncommon in my experience (they used to be a thing on old 8 bit MCUs).
Sure the memory map and peripherals do differ between SoCs but, under Linux at any rate, that is only a problem for the kernel and you can actually build a kernel that will run on multiple SoCs as long as they have the same ISA (by building the different drivers as module and suppling the appropriate DT.)
I regularly run the same userspace root filesystem (and in fact the same kernel except for DT) on multiple ARM v7 SoCs.
Fragmentation is often cited as a fundamental cause of Android’s shortfalls, which doesn’t seem like a minor impact.
Fragmentation turns out OK when there are strong convergent forces pruning unsuccessful branches or pulling them back into the fold. This can even be good, because you can experiment & evolve. However, when various implementations are comparable yet different in a hundred little ways, neither is selected against and the problem sprawls.
It remains to be seen whether there are any strong reconvergent forces acting on RISC-V.
