Three teams queue for the same emulator. The DCRouter team wants to rerun block-level random tests faster. The software team wants to boot the OS nightly. The performance team wants a benchmark run. Only one of these needs the emulator: block tests run better in block simulation, and the benchmark might be better on an FPGA prototype. Platform choice is a planning decision, made question by question.
Which platform should answer which question?
The obvious rule is "the fastest platform available". Fast platforms are slower to set up, less visible and less flexible, and they arrive later in the project. Running a question on a platform faster than it needs wastes scarce hardware; running it on one too slow means it never finishes. The right platform is the cheapest one that answers the question in time.
Need | Formal | Simulation | Virtual platform | Emulation | FPGA prototype | Silicon |
|---|---|---|---|---|---|---|
Cycles per run | Short (bounded) | Thousands to millions | Billions | Billions | Trillions | Unlimited |
Accuracy | Exact, for properties | Exact RTL | Functional | Exact RTL | RTL, prototype clocks | Real |
Visibility | Full counterexample | Full | Software-level | High, with planning | Low | Very low |
Turnaround after a change | Minutes | Minutes | Minutes | Hours | Hours to a day | Months |
Available from | RTL | RTL | Specification | RTL compiles | Stable RTL | Tape-out |
Question | Best platform | Why |
|---|---|---|
Does DCRouter's arbiter grant the right winner, always? | Formal | Exhaustive, short reach (lesson 7.9) |
Do DCRouter's 13 rules hold under random traffic? | Block simulation | Full control and visibility, fast turnaround |
Does the driver program DCRouter correctly? | Virtual platform, then hybrid | Early; then real RTL for timing |
Does the OS boot with DCRouter carrying network traffic? | Emulation | Billions of cycles with debug visibility |
Does the network stack run stably for hours? | FPGA prototype | Trillions of cycles, real cables |
What bandwidth does a real workload get? | Emulation or prototype, against a performance model | Billions of cycles of real software |
Does it work at temperature and voltage limits? | Silicon | Physical effects (Part 11) |
Specification stage: virtual platform for software; formal and simulation as RTL appears.
RTL development: block simulation and formal dominate; hybrids for early software on new blocks.
Integration: chip simulation for short flows, emulation for boot and long runs.
Late RTL: FPGA prototypes for software teams and long stability runs.
After tape-out: the same tests prepared for silicon validation (Part 11).
Practice | Purpose |
|---|---|
A platform column in the verification plan | Each question assigned to the cheapest adequate platform |
Emulator and prototype capacity planned like any resource | Queues sized to the questions that need them |
Tests portable across platforms | The same scenario moves from simulation to emulation to silicon (fact V11) |
A team (illustrative) used its emulator mostly to run block-level regressions faster, because it was available and fast. When the OS boot was ready to run, the emulator queue was full of block tests that a simulation farm could have handled, and boot testing slipped by three weeks. Assigning platforms by question, not by availability, would have kept the emulator for the questions only it could answer.
Block tests need only thousands to millions of cycles, full visibility and minutes of turnaround; emulation adds hours of rebuild for speed they do not need.
The virtual platform, available from the specification: early software development and register-contract checks.
Choose the cheapest platform that answers each question in time.
Cycles, accuracy, visibility, turnaround and availability decide.
Plan platform capacity by question and keep tests portable across platforms.