RISCV Verfication Interface (RVVI) port - addition

[mikaelsky]

As part of the core verification we are performing I've added an RVVI trace port to connect the NEORV32 core to an external ISA model that is used to validate that the NEORV32 performs correctly and adheres the RISCV specification.
This method allows us to do things like throw random instruction sequences at the core and determine correct execution etc.

I already have an internal branch of the core with the RVVI trace port added. This includes a enable/disable parameter as the RVVI logic does incur some area overhead. When RVVI trace is disabled the port turns undefined and all logic and signal assignments get removed.

There are already some tools that function with RVVI trace ports like OVPSim.

If there is interest in this debug feature I can push into the main line with some additional documentation for the NEORV32 on the RVVI interface and what all the signals do and how they are to be used. This as it the RVVI documentation is somewhat lacking.

RVVI home: https://github.com/riscv-verification/RVVI

[stnolting]

Hey @mikaelsky!

f there is interest in this debug feature [...]

Absolutely! Thank you very much for sharing!

Could you give some additional information about your implementation of the RVVI interface? Or is there a repository where I could have a look at the sources?

[mikaelsky]

Fundamentally the RVVI trace system is tapping into various internal signals from the cpu_control, regfile, pmp and FPU blocks and performing a "re-alignment" operation to get all the various state changes that happen during a given instructions multi-cycle execution to a common clock cycle where we can assert the valid indicator (for neorv32 this is pc_we) towards the RVVI trace target.
One example is the CSR one-hot write back vector, all 4096 bits of it, that needs to be shifted from whenever a cluster of CSRs get written to forward to when we issue a valid. This ends up as a 4096 bit set of registers as we need to capture on hold.
Because of this I added the "enable" piece to ensure that any implementation outside just plain debugging doesn't need to carry all these extra registers.

I'm currently working on getting the latest version of the core (1.9.3) working with the RVVI testing system. Patience is advised :)
Let me send you a ping when I push the change up to my fork here: https://github.com/mikaelsky/neorv32

[stnolting]

Fundamentally the RVVI trace system is tapping into various internal signals [...]

I was expecting that. Do you use this trace system in simulation only or also for deployment within FPGAs?

Because of this I added the "enable" piece to ensure that any implementation outside just plain debugging doesn't need to carry all these extra registers.

Good point! I would like to keep the impact on the "actual" implementation as small as possible (zero) while also keeping the readability of the code at an "acceptable" level (whatever that means... 😅).

Could we use VHDL 2008's hierarchical names to move most of the trace port logic into a unique module that we can simple ignore for "real" hardware implementations?

I'm currently working on getting the latest version of the core (1.9.3) working with the RVVI testing system. Patience is advised :)
Let me send you a ping when I push the change up to my fork here: https://github.com/mikaelsky/neorv32

Can't wait to see that 😉

[mikaelsky]

For now if you disable the RVVI everything disappears except the extra module ports and some signal definitions. It should, if not I'll get "smacked" by our chip team for an area increase :)

Let me take a gander for the hierarchical names. It might work. For now most of the RVVI function is wrapped in a generate statement in cpu_control with threads into the regfile, pmp and fpu.

Well its mostly working at this point. I would want to do some documentation on the signals and what sources we use to make it easier to understand the motivation for e.g. grabbing pc.we for valid.

Right now I'm prioritizing higher to located a few more potential bugs that are popping up as part of the 1.9.3.x hpmcounter change and find the source of the fflags failures.

As I side note. I am exploring if I can share some of our verification results as we are putting the core through the "wringer" so to speak. Could help build more confidence in the core?

[mikaelsky]

@stnolting
Its taken a while, had to up-prioritize the FPU and decompressor fixes :)

This should be the branch where I've ported the RVVI trace system into a module using aliasing.
https://github.com/mikaelsky/neorv32/tree/rvvi_trace

I've had to create packages for the modules that we grab trace information from as the struct types need to be the same and we can't just re-declare them. In general one could argue that it is beneficial to have per module packages as it allows the use of structs across boundaries, e.g. between the controller and the FPU

I add the generic and defaulted it to false, so if nothing else is done the RVVI trace module isn't instantiated.

Because aliasing isn't supported by a lot of synthesis tools there is an rvvi package file that only contains a component declaration of the rvvi trace entity. This allows the code to be built with the RVVI disabled without having to read in the neorv32_cpu_rvvi.vhd file as that will cause synth tools to.. have a bad time.

I've tested the setup internally with our trace compare an everything still works fine, so yeah :) I've also synthesized the code base with genus and as long as the neorv32_cpu_rvvi.vhd file isn't read in the core synthesizes with no issues. Its also been tested with RTL based MBIST insertion and that also passed as long as the neorv32_cpu_rvvi.vhd isn't read in.

I haven't tested it with the github setup and GHDL as my internal "branch" is somewhat feature wise out of data with the current main.

Note: I haven't tested PMP CSRs with RVVI, so for now its only wired up and might work.

[stnolting]

Wow, this is... a lot 😅 I did not expect the RVVI trace system to be so complex. Anyway, thanks for sharing!

As far as I can see the impact on the actual CPU logic is quite minimal or even zero. That's a good thing! However, the impact on the code base is rather heavy. So I'm not sure how to integrate this - although I'd really like to ;D

Maybe we can source-out this to an individual repo like https://github.com/stnolting/neorv32-formal?! 🤔

I am absolutely no expert in (formal) verification... Maybe this is a naive question: how far is RVVI trace port compatible with Yosys' RISC-V Formal Interface (RVFI)?

[mikaelsky]

It looks complex :) mostly its finding the right probe points and then doing a ton of realignment. It is Very core implementation specific though.

I have no opinions on individual repo or not. From our side we use RVVI extensively to validate core function vs a simulator. Ideally if I had all the time in the world, then one could imagine adding that feature using a combo of cocotb, ghdl and spike. This would be especially useful when extending the core with new functions and/or refactoring code.

I took a brief glance at the RVFI. Beyond a few small difference its fairly compliant. The "big" difference is the CSR reporting where RVVI generates this giant one-hot vector where RVFI generates a N * {r/w mask + r/w data) for each CSR in the core.. so a Lot of signals. The masks do seem to be static per CSR though.

RVVI doesn't provide a memory model either, but that is more simple to add.

What isn't super clear with the RVFI is the timing around the signals. Thats the big challenge with RVVI - realignment of internal state. The core is a multi-cycle core but the formal model/simulator are all single cycle assumptions. So any information that changes during the multi-cycle execution has be to captured and held until the valid indicator is asserted... with some exceptions like trap.

Let me think about the RVFI and maybe extend the RVVI with some RVFI features and/or add a neorv32_cpu_rvfi module in the same vein as the RVVI module.