Using spike in a lock-step hardware simulation

[Dolu1990]

Hi,

I recently developped a RISC-V OoO core and used Spike as a reference model in the verilator simulation of the hardware core. Got the simulation to keep spike and the core in exact sync while running linux/buildroot.

When i mean using spike in a lock-step manner to check the hardware core, i mean :

• Step spike by one instruction each time the hardware core commit one instruction
• For interrupts, holding spike from taking any until the hardware core take one (to keep them in sync)
• Syncronising a few specific CSR values from the hardware core to spike ones, as some have implementation specific behaviour (ex : mcycle)
• Comparing the register file writes between the two
• Comparing the PC between the two

So, most of things required to setup such lock-step are already supported in Spike excepted a few where i had to patch things as bit :

• interrupt holding
• step spike by one commit (the actual step function may not necessarly commit anything if there is a trap)
• knowing the last commited pc
• Optionaly implement WFI as a nop
• csr syncronisation (not a big deal)

So my questions are :

• Is it wishable in the future to support such lock-step usage in spike's upstream ?
• Did i miss some feature in spike already covering the above list ?

For reference, here are my dirty changes in spike : https://github.com/SpinalHDL/riscv-isa-sim/commits/master

Here is the verilator testbench's functions related to the spike integration : https://github.com/SpinalHDL/NaxRiscv/blob/703bb86106d0db87b9844d28eded3b3608e59a58/src/test/cpp/naxriscv/src/main.cpp#L1399 https://github.com/SpinalHDL/NaxRiscv/blob/703bb86106d0db87b9844d28eded3b3608e59a58/src/test/cpp/naxriscv/src/main.cpp#L1459

Thanks ^^ Charles