DCRouter's driver team cannot wait for the RTL, let alone silicon. Six months before RTL freeze they receive a virtual platform: a software model of the SoC in which DCRouter is a few hundred lines of C++ that implement its registers and move packets between DMA engines and memory, with no clock at all. The OS boots on a laptop in seconds. By the time the RTL exists, the driver has already been written, run and debugged against the register specification.
How does software start before the RTL, and what does it give up?
The obvious sequence is hardware first, then software: write the RTL, build an emulator image or a prototype, then start the driver. That puts software months behind and finds hardware-software contract bugs late, when fixing the hardware is expensive. A model at the level software sees, registers and functions, can exist as soon as the specification does.
Platform | Speed | Accuracy | Available |
|---|---|---|---|
Virtual platform (transaction-level models) | Near real time | Registers and functions; approximate or no timing | From the specification |
Hybrid: virtual platform plus RTL block in simulation | Slow for the RTL part | Exact for the RTL block | When the block's RTL exists |
Hybrid: virtual platform plus RTL on an emulator | Fast | Exact for the emulated part | When the RTL compiles for emulation |
Full emulation or prototype | Fast | Exact RTL | When the whole RTL exists |
Timing: races, latencies and back-pressure that depend on cycles are absent or approximate.
Faithfulness: the model implements the specification as its author read it; it can share the driver team's misreadings (lesson 8.4).
Corner behaviour: what a model does not implement (an error response, a reset quirk), the driver never meets.
So: virtual platforms are for early software and register-contract checks; the driver must also run against the RTL (lesson 8.6).
Practice | Purpose |
|---|---|
Virtual platforms from the architecture specification | Software development starts months earlier |
Register models generated from the same source as the RTL | The model's registers match the hardware's (lesson 2.4) |
Hybrids for new blocks | Real software against real RTL for the risky block, fast models for the rest |
Driver test suites run on every platform in turn | Each platform catches what the faster one cannot |
A team (illustrative) developed a driver entirely on a virtual platform whose DMA model completed transfers instantly. On the emulator, real transfers took thousands of cycles, and the driver, which read the completion status immediately after starting a transfer, read "busy" and gave up. The virtual platform had no timing to expose the assumption. Running the driver's critical sequences on a hybrid with the RTL DMA would have.
The virtual DMA model completed instantly; real transfers take time, and the driver assumed completion right after starting.
Exact behaviour, including timing, for the block running as RTL, while the rest of the chip still runs fast as models.
Virtual platforms model the chip at register and function level, fast enough for software from day one.
Hybrids connect real RTL for one block to fast models for the rest.
Virtual platforms miss timing and unmodelled behaviour; run the same software on RTL later.