What happens when an RV32 controller, an RV64GC application core, and an RV32 safety core must boot—and agree—inside one system?
A heterogeneous SoC looks straightforward in a block diagram:
- Add multiple processor cores
- Connect them through a common bus
- Assign each core a different responsibility
- Call it a multicore architecture
But a diagram proves nothing.
The real challenge begins when all the cores must boot together, execute different firmware, communicate through a shared address map, and complete only when the expected results agree.
The setup
We brought together three different RISC-V profiles:
- RV32IM
- RV64GC
- RV32IMC
Each profile runs its own firmware and produces its own execution result.
This is one coordinated platform—not three isolated simulations combined into a single log.
One command. Three instruction streams.
- bin/socvp
- boot
- multicore
The boot must demonstrate that:
✅ All three processors execute independently
✅ The RV64GC core performs genuine 64-bit work
✅ The cores exchange status through shared memory
✅ The controller waits for the other processors
✅ The safety core verifies the result
✅ An injected mismatch is rejected
A safety checker that always returns MATCH is meaningless. To validate correctness, we intentionally inject a mismatch—the system must detect and reject it.
Correct result → ACCEPT
Corrupted result → REJECT
This is essential for safety-critical systems like lockstep CPUs, watchdogs, and fault-tolerant designs.
What the platform proves
- Multi-core RISC-V execution (RV32 + RV64GC)
- Independent firmware per hart
- Shared-memory coordination
- Inter-core boot synchronization
- Safety check with mismatch detection
This is a functional virtual platform, not a cycle-accurate model.
The takeaway
A diagram shows architecture. A working system proves behavior.
Read the complete technical story and see the execution results:
👉 WIOWIZ SOCVP - Three RISC-V Cores, One Boot, One Fabric
Top comments (0)