Pre-Silicon Software: Virtual Platforms and SystemC TLM in CI

Firmware and drivers ready on the first day of silicon

Design the virtual platforms for an SoC that tapes out in 12 months: models at each abstraction level, SystemC TLM-2.0 and QEMU, one register source for RTL, models and drivers, and CI that boots firmware on thousands of instances.

Overview

A new system on chip (SoC) tapes out in 12 months. The day the first chips come back, the boot ROM, the firmware for each microcontroller, the Linux or RTOS drivers and the bring-up tests must already work, because every week the chip waits for software is a week the product is late. Software cannot wait for silicon, and it cannot run on the RTL simulator either: booting an operating system there takes weeks.

The answer is a virtual platform (VP): a software model of the chip that runs real, unmodified binaries. Its CPU models execute the target instruction set; its peripheral models expose the same registers, interrupts and memory map the RTL will have. Most VPs are written in SystemC, a C++ class library standardized as IEEE 1666, using its TLM-2.0 (transaction-level modeling) interfaces, often with QEMU or Renode supplying the fast CPU models.

The interview question is not only 'what is a virtual platform?'. It is 'how do 300 software engineers use one every day, in CI, while the hardware design changes under them, and how do you know a green test means the code will work on silicon?' That has three parts: choosing the right model for each job, keeping models in step with the RTL, and running and trusting thousands of VP runs a day.

Scope it first

What runs on the chip? — An application CPU cluster running Linux, a real-time core running an RTOS, a security core with boot ROM and firmware, and about 60 IP blocks
Which software must be ready on day one? — Boot ROM, first-stage firmware, RTOS and Linux drivers for every block, bring-up and production tests
What exists today? — RTL in progress for most blocks, licensed CPU models, a register description per block
How many software engineers, how many changes? — 300 engineers, about 600 merge requests a day
How much timing accuracy does software need? — Functional correctness everywhere; cycle-level timing only for drivers with tight deadlines and performance work
What happens after tape-out? — The same tests run on silicon; differences must be explained

The interviewer listens for four things. Do you match the abstraction level to the job (a loosely-timed VP for software bring-up, RTL or emulation for timing and hardware truth) instead of asking for one perfect model? Can you explain TLM-2.0 well enough to say why loosely-timed models with temporal decoupling are fast and what they give up? Do you keep the register map in one source so models, RTL, drivers and documentation cannot drift? And do you treat the VP as a product with releases, deterministic runs, golden outputs and a correlation plan, rather than a simulator someone set up once?

Key concepts

Virtual platform
Abstraction levels
SystemC TLM-2.0
Loosely-timed vs approximately-timed
Temporal decoupling and the quantum
Direct memory interface (DMI)
QEMU and SystemC co-simulation
Register single source (SystemRDL, IP-XACT)
Golden outputs and determinism
Model-to-RTL and silicon correlation

Functional requirements

Software teams boot and debug unmodified firmware, bootloaders and operating systems on a model of the whole SoC, on a laptop or in CI
Every IP block has a model with the same registers, reset values, interrupts and memory map as its RTL, generated from one register source
A merge request runs a presubmit set of VP tests and gets a verdict in minutes; a nightly run covers the full test matrix
Each VP release names the RTL release and register-map version it models; tests record which release they ran on
Selected RTL blocks can run inside the VP (co-simulation) when software needs the real design
Test outputs are compared against approved golden outputs, and a difference is reported with the first diverging line
After tape-out, the same tests run on silicon boards and results are compared with the VP's, test by test

Non-functional requirements

Fast: a Linux boot on the VP in about a minute (our target), so a presubmit fits in minutes
Deterministic: the same VP release, binary, configuration and seed give the same output, every run, on any host
In sync: a register change reaches the RTL, the models, the driver headers and the documentation from the same commit, or the build fails
Scalable: tens of thousands of runs a day on a shared farm, with presubmit never waiting behind nightly work
Trustworthy: every model release passes conformance tests against RTL before software is asked to use it
Debuggable: any failing run can be reproduced locally from its recorded inputs, with a debugger attached

Interview questions

Why not just run software on RTL simulation or an emulator?
Explain loosely-timed and approximately-timed TLM, and when you use each.
What is the quantum, and how do you choose it?
How do you keep the models, the RTL, the drivers and the documentation in sync?
How do QEMU and SystemC work together in a VP?
Design the CI. How many machines do you need?
What makes a golden output trustworthy, and what do you do with a flaky VP test?
Silicon is back. How do you know the VP was right, and what happens to it now?