Looking for reference simulator with API access to internal state

[iztok.jeras]

Hi,

I am slowly coding my own RISC-V SystemVerilog RTL implementation, micro-controller with I32/64/128(just for completeness) and extensions MAC, CLIC interrupt controller, floating point is not on my list yet ...

I am using Verilator to simulate my RTL and I would like to compare the internal state of the RTL CPU against the internal state of the simulator.

The idea is to compile the simulator as a library into the Verilator executable and to use the simulator API to extract the internal state of the simulator (PC, GPR, CSR).

The simulator can be slow and simple (small and few features) but should have a good coverage of the base and extensions.

I do not mind filing bug reports, if some instructions do not behave as expected.

I was looking at Spike and its Interactive Debug Mode, which could be used by piping requests and responses between Spike and Verilator through a file system FIFO.

https://github.com/riscv/riscv-isa-sim

I was also looking at the next test sets:

https://github.com/riscv/riscv-tests 

https://github.com/ucb-bar/riscv-torture

They look just what I need.

Otherwise I would be interested how you check execution correctness. For now I will probably study the pulp platform.

Regards,

Iztok Jeras

[John Leidel]

Iztok, if you examine how Spike (riscv-isa-sim) is actually
constructed, the core simulation functionality exists as a library.
Without a terrible amount of work, you should be able to pull whatever
information you need from the isa-sim "sim_t" class by exposing the
internal cpu state ("processor_t" class) upstream. The GoblinCore
simulator used named pipes to expose much of the internal state to
external simulation/tracing mechanisms and it was rather clumsy. The
SST "Stake" module utilizes the former library approach to attach
Spikes memory layer to the SST simulation infrastructure. It was much
easier to implement and has been much easier to maintain going
forward. We also do something similar in the xBGAS simulator to
construct distributed shared memory devices.

The Stake interface code is here:
https://github.com/sstsimulator/sst-elements/blob/master/src/sst/elements/miranda/generators/stake.cc

cheers
john

> --
> You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
> To post to this group, send email to hw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/e0768056-64fc-463e-937e-376d97fc2ea6%40groups.riscv.org.

[Michael Clark]

On 20/09/2018, at 8:06 AM, iztok.jeras <iztok...@gmail.com> wrote:

Hi,

I am slowly coding my own RISC-V SystemVerilog RTL implementation, micro-controller with I32/64/128(just for completeness) and extensions MAC, CLIC interrupt controller, floating point is not on my list yet ...

I am using Verilator to simulate my RTL and I would like to compare the internal state of the RTL CPU against the internal state of the simulator.

The idea is to compile the simulator as a library into the Verilator executable and to use the simulator API to extract the internal state of the simulator (PC, GPR, CSR).

Compiling spike as a library is a very good idea. It would be much faster for co-simulation with hardware in verilator.

I used a software to software co-simulation for verifying a JIT on the Base ISA (not floating point yet).

Keeping up with verilator would be trivial. i.e. would not affect simulation speed (in the error margin). Partitioning and reversing memory operations would be good. Stores ideally need to be reversible.

Doing this over debug would be possible but slow. Using the tracing standard and a trace port with deterministic IO scaffolding would also be nice. This could allow co-simulation with faster hardware targets.

The simulator can be slow and simple (small and few features) but should have a good coverage of the base and extensions.

I do not mind filing bug reports, if some instructions do not behave as expected.

I was looking at Spike and its Interactive Debug Mode, which could be used by piping requests and responses between Spike and Verilator through a file system FIFO.

https://github.com/riscv/riscv-isa-sim

I was also looking at the next test sets:

https://github.com/riscv/riscv-tests 

https://github.com/ucb-bar/riscv-torture

They look just what I need.

Otherwise I would be interested how you check execution correctness. For now I will probably study the pulp platform.

Regards,

Iztok Jeras

--

[Jamey Hicks]

Hi Iztok,

MIT Computation Structures Group uses Spike's sim_t class to implement tandem verification.

In the MIT designs, the processor emits verification packets, which contain the architectural state changed by each executed instruction. The test process receives a stream of verification packets and checks them against spike's behavior. We use a unix socket to connect verilator to the verification process (but cosimulation would be faster). When that is too slow, we run the processor on an FPGA and stream the verification packets over PCIE (or AXI) with an mmap() interface to the FPGA.

Here's the verification packet description to give an idea:

typedef struct {
	Bit#(64) skippedPackets;
	Bit#(64) pc;
	Bit#(32) instruction;
	Bit#(64) data;
	Bit#(64) addr;
	Bit#(7) dst;
	Bool exception;
	Bool interrupt;
	Bit#(4) cause;
	} VerificationPacket deriving (Bits);

https://github.mit.edu/csg/riscy-mirror/blob/xlen_reorg/procs/riscy-lib/VerificationPacket.bsv

Best regards,

Jamey

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/1AF337A3-5064-4037-81A4-273F053110F6%40mac.com.

[iztok.jeras]

Thanks for all your answers, I will check Spike and the mentioned examples.

Regards,

Iztok Jeras