Simulation Performance & TB Memory

Overview

A regression that takes 14 hours instead of 4 is not a tooling problem — it is usually a testbench problem . Polling loops, $sformatf in hot paths, unbounded scoreboard queues, and full-hierarchy wave dumps quietly multiply runtime and memory. This topic teaches you to find where time and memory actually go, fix the classic testbench sins, and run a deliberate speed-vs-debug strategy instead of paying for full visibility on every run.

The skills here separate engineers who guess at performance from engineers who measure it. Every sub-lesson follows the same discipline: profile first, fix the biggest cost, re-measure.

Sub-topics

1. Where Simulation Time Goes — RTL vs TB vs assertions vs coverage vs waves; profiling before optimizing.

2. Testbench Hotspots — polling loops, string building, transaction copying, sample storms, solver abuse.

3. TB Memory Discipline — unbounded queues, retained handles, associative arrays, leak hunting.

4. Waves, Logs & Visibility Cost — scoped dumping, verbosity control, rerun-with-waves flow.

5. A Speed-vs-Debug Strategy — regression vs debug profiles, plusarg switching, the two-pass workflow.

SIMULATION PERFORMANCE & MEMORY — TOPIC MAP

  Where does the time go?            Where does the memory go?
  ────────────────────────           ─────────────────────────
  [1] Cost breakdown &               [3] Queues, handles,
      profiling                          assoc arrays, leaks
        │                                   │
        ▼                                   │
  [2] TB hotspots                           │
      (polling, strings,                    │
       copies, sampling,                    │
       solver)                              │
        │                                   │
        └───────────┬───────────────────────┘
                    ▼
  [4] Waves & logs — the visibility tax
                    │
                    ▼
  [5] Strategy — fast regression profile,
      full debug profile, two-pass rerun flow

Key takeaways

• Measure before optimizing — the bottleneck is rarely where you assume.

• The testbench, not the RTL, is the usual culprit in slow class-based environments.

• Visibility (waves, logs, coverage) is a tax — pay it deliberately, not on every run.