DCRouter's sleep mode saves power by stopping traffic after 8 idle cycles. In the SoC, the power team wants more: switch off DCRouter's power domain entirely when the DMA engines are idle. Now the questions change. Are DCRouter's outputs clamped to safe values while it is off, so the memory controllers do not see garbage? Which registers keep their values, and which must software restore? Does the wake sequence leave enough time for the supply to settle before traffic starts? None of these is visible in plain RTL simulation, where power is always on.
How do you verify performance and power, not just function?
The obvious approach treats performance and power as implementation concerns, measured late on the netlist or the silicon. By then, an architectural bottleneck or a missing isolation cell costs a redesign. Both have verifiable specifications early: performance as bounds and targets (lesson 5.9), power as a separate description of the design's power intent. Both need their own checks, at the levels where they can be seen.
Level | What it can verify | DCRouter example |
|---|---|---|
Block | Latency bounds, fairness, throughput at saturation under synthetic traffic | Head-of-line wait at most 16 cycles; 1 flit per cycle per output |
Subsystem | Throughput with real neighbours and their back-pressure | Bandwidth with real memory controllers' credit behaviour |
Chip and emulation | End-to-end performance on real workloads and software | Copy bandwidth seen by the driver under a real traffic mix |
Architecture model | Expected numbers to compare against | A performance model predicting the bandwidth each workload should reach |
Power intent is described separately from the RTL, in IEEE 1801 (UPF): power domains, supplies, switches, isolation, retention and level shifters (fact V10). Verifying it means checking that the design behaves correctly as domains switch off and on.
What can go wrong | How it is verified |
|---|---|
Outputs of a powered-off domain float or carry garbage into live domains | Power-aware simulation corrupts the off domain's signals; isolation must clamp them |
State that should be retained is lost | Retention checks: saved before power-down, restored after |
Wake sequence too fast: traffic before the supply or reset settles | Sequencing tests driven by the power controller model |
Missing isolation or level shifter on a crossing | Static or formal checks of the power intent against the design |
Software power-management sequence wrong | Chip-level software-driven tests with power-aware simulation |
DCRouter's sleep mode is functional low power: it is verified by ordinary simulation (R13), as Parts 4 to 6 did; formal covers part of it too: lesson 7.9's credit property caught BUG_22 (credits lost while asleep), though no property there checks sleep entry or wake.
Switching off its domain is structural low power: only power-aware tools model the corruption that isolation and retention must handle.
Its three low-power bugs (BUG_20, 21, 22) are functional, which is why ordinary testbenches could find them; a missing isolation cell would not be.
Practice | Purpose |
|---|---|
Performance targets and bounds in the verification plan, with checkers | Slow designs fail tests, not product reviews |
Performance models from architecture as references | Expected numbers for each workload (lesson 5.9) |
Power-aware simulation and static power-intent checks | Isolation, retention and sequencing verified before implementation |
Power-management software in chip-level tests | The real sequences exercised against power-aware RTL |
A team (illustrative) verified a block's retention registers by checking that their values survived a power cycle in power-aware simulation. They did. The block's state machine, which was not retained, woke in its reset state while the retained registers held mid-transaction values, a combination the block's own tests had never seen, and the block hung after its first power cycle in the lab. A test exercising wake from a domain switched off mid-transaction would have shown it.
The three bugs are in DCRouter's functional sleep logic, which ordinary simulation models; isolation only matters when a power domain is switched off, which only power-aware simulation models.
Chip level or emulation: the workload needs real DMA engines, memory controllers and software; block level only shows bandwidth under synthetic traffic.
Performance and power need their own specifications and checks, not just functional correctness.
Verify performance as numbers at the level where the workload is realistic.
Verify power intent (UPF) with power-aware simulation and static checks; functional sleep modes are ordinary logic.