Three RISC-V cores, one boot, one fabric

A SoC with different cores is easy to draw and hard to prove. Three cores on a block diagram tells you nothing about whether they boot, whether the 64-bit core is 64-bit in more than name, or whether the safety core would notice if its partner went wrong. This chapter boots all three at once and reads the receipts each one leaves. No simulator is set up on the user side; the boot and its checks ship with the package.

One boot, three instruction streams

The multicore system runs three RISC-V profiles side by side. One command boots them together:

$ bin/socvp boot multicore

[hart2] mcore: safety lockstep match
[hart0] mcore: hart0 saw application DONE
[hart0] mcore: hart0 saw safety lockstep OK

[VP] hart0 Control core     : PASS  insns=2312  tohost=0x1
[VP] hart1 Application core : PASS  insns=1795  tohost=0x1
[VP] hart2 Safety core      : PASS  insns=1605  tohost=0x1

Three programs, three separate instruction counts, three independent PASS results. hart0 is the rv32im controller, hart1 is the rv64gc application core and hart2 is the rv32imc safety core. Each ran its own image and reported its own retirement count. This is one platform with three harts, not three runs stitched into one log.

The cores are actually different

It is cheap to label a core 64-bit. It is not cheap to make it execute 64-bit work that a 32-bit core cannot. The application core's firmware is written to force exactly that:

• 64-bit loads and stores against a 64-bit checksum;
• an LR/SC atomic sequence;
• a double-precision floating-point result checked against a build-time oracle;
• four checked kernel results before it reports DONE.

Studio labels hart1 as rv64gc, and its register file is 64 bits wide on screen. It is not presented as a second RV32 core with a relabelled header. The controller and safety cores, by contrast, will reject a 64-bit or floating-point instruction as illegal, the same rule the whole platform enforces: an instruction outside a core's ISA fails the boot rather than passing silently.

Safety by disagreement

The safety core exists to catch a wrong answer, so the interesting test is not that it agrees on a good run. It is whether it would disagree on a bad one. On the normal boot it reports a lockstep match:

[hart2] mcore: safety lockstep match

A checker that can only ever say match is not a checker. So qualification does not stop at the green run. It injects a mismatch into the paired execution and requires the safety comparison to reject it. A checker that passes both the good run and the tampered run is broken, and this one is held to failing the tampered one. That negative control is what makes the match on the normal run mean something.

One fabric, not three simulations

The three cores share one memory-mapped system and coordinate over it. The controller does not simply start and exit; it waits on results the other two produce, exchanged through the shared address map and a mailbox handshake. The two lines from the boot,

[hart0] mcore: hart0 saw application DONE
[hart0] mcore: hart0 saw safety lockstep OK

are the controller confirming it observed both downstream completions before finishing. Pull either core and hart0 would wait, not pass. That ordering is the proof the harts are on one interconnect rather than running in three isolated sandboxes.

What it does not measure

This run shows functional execution across three ISAs, shared-memory coordination, RV64GC operations and a safety comparison with a firing negative control. It does not measure cache coherency, multicore throughput, clock-cycle alignment or physical lockstep timing. Those are timing properties, and socvp is a functional model, not a cycle-accurate one. What it proves is behavioural: the cores boot together, do work only their own ISA allows, and reach agreement the platform can check.

Download socvp

socvp is available now. It ships as a Docker bundle from the WIOWIZ website — download it, build the image, and run the boots in this article.

Download socvp on wiowiz.ai →