[HN Gopher] Do Necessary Tools Exist for RISC-V Verification?
___________________________________________________________________
Do Necessary Tools Exist for RISC-V Verification?
Author : rbanffy
Score : 67 points
Date : 2023-03-31 13:26 UTC (2 days ago)
(HTM) web link (semiengineering.com)
(TXT) w3m dump (semiengineering.com)
| hobo_mark wrote:
| And not a single mention of https://github.com/YosysHQ/riscv-
| formal?
| pclmulqdq wrote:
| 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.
| bippingchip wrote:
| 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
| [deleted]
| farseer wrote:
| Here is a list of some mostly vendor specific tools for RISC-V
| verification: https://www.riscfive.com/risc-v-compliance/
| gchadwick wrote:
| 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.
| shash wrote:
| 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.
| mfuzzey wrote:
| >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.
| ip26 wrote:
| 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.
| snvzz wrote:
| >However, when various implementations are comparable yet
| different in a hundred little ways, neither is selected
| against and the problem sprawls.
|
| Only RISC-V can ratify specs.
|
| And yet, hardware implementations are desirable for testing
| specs before ratification.
|
| Chips that have non-standard extensions will run code built
| for the standard specs that they implement just fine.
___________________________________________________________________
(page generated 2023-04-02 23:02 UTC)