Simulation Performance and Logging

1. Engineering intuition — pay for events, observe with logs

A simulator's work is proportional to the events it processes — every signal transition, every process wakeup, every delta. So making a simulation fast is mostly about doing less: fewer transitions, less recorded, less unnecessary modeling detail. The classic mistake is dumping every signal to a waveform database "just in case" — on a large design over a long run, that I/O dwarfs the actual computation. The companion question is how to see what happened when you cannot dump everything: the answer is logging, which scales where waveforms do not — a few targeted lines per interesting event instead of a full trace of every wire. Fast and observable is a matter of spending events wisely and logging deliberately.

2. Formal explanation — the performance levers

-- COST MODEL: simulation time ∝ number of EVENTS (signal transitions, process wakeups, deltas).
--
-- LEVERS (largest first, typically):
--  1. LIMIT THE WAVEFORM DUMP: dump only the signals/scope you need, only over the window you need.
--       Dumping the whole hierarchy for the whole run is usually the #1 slowdown.
--  2. REDUCE NEEDLESS ACTIVITY: don't toggle signals every cycle when they rarely change; avoid
--       gratuitous combinational churn and tiny time steps that create excess deltas.
--  3. OPTIMIZED / vendor-OPTIMIZED COMPILE: enable the simulator's optimization; compile once, run many.
--  4. BEHAVIORAL MODELS for non-DUT: replace surrounding RTL (memories, bus models) with abstract,
--       low-event behavioral models so only the DUT runs in detail.
--  5. DISABLE VERBOSE LOGGING / waveform dump in regression runs; enable on demand for debug.

Simulation cost scales with events, so the levers all reduce events or I/O: dump less waveform data (the biggest single lever), generate less needless activity, use optimized compilation, model non-DUT logic behaviorally, and turn off verbose output in bulk regression. Detailed waveforms and verbose logs are debug-time tools, switched on only when needed.

3. Production usage — scalable logging and reproducibility

-- LEVELED, CONDITIONAL logging scales where full waveforms do not — log KEY EVENTS, not every cycle.
constant VERBOSITY : natural := 1;          -- 0=quiet (regression), higher = more detail (debug)
 
log_proc : process begin
  wait until rising_edge(clk);
  if transaction_done = '1' then            -- log meaningful EVENTS, not every clock
    if VERBOSITY >= 1 then
      report "txn " & integer'image(txn_id) & " done, result=" & to_hstring(result) severity note;
    end if;
  end if;
end process;
 
-- LEVELS route by importance: note (info) / warning (suspicious) / error (failure) — filterable.
-- REPRODUCIBILITY: always log the seed + config so any run can be recreated (14.8).
report "run config: seed=" & integer'image(SEED) & " depth=" & integer'image(DEPTH) severity note;
 
-- WAVEFORM vs LOG trade-off:
--   • logs: compact, scale to millions of cycles, greppable, the regression default.
--   • waves: full detail but heavy — turn on for a NARROW window once a log points at the problem.

What hardware does this become? None — performance and logging are about running the simulation efficiently, not RTL. The workflow they enable is two-tier: regression runs lean (no full waveform, quiet logging, optimized compile) so thousands of cycles finish fast and are scored by leveled logs; when a log flags a failure, you re-run a narrow window with full waveforms to debug it in detail. Logging the seed/config ties the two together — the lean run's failure can be reproduced exactly under the heavy, observable one. This is how large verification stays both fast and debuggable.

4. Structural interpretation — performance levers and logging levels

5. Why this is structural, not timing

Performance and logging are tooling trade-offs — how you configure and run the simulation — so the levers-and- levels diagram above is the right picture, not a waveform. They change the cost and observability of producing traces, not the design's behavior; the same DUT behaves identically whether you dump every signal or none. The substance is structural: an event-cost model and a logging hierarchy, and the workflow decisions (lean regression vs detailed debug run) that follow from them — design-time/run-time configuration, not a signal trace.

6. Debugging example — the regression that crawled

Expected: a nightly regression of thousands of cases finishes quickly and is easy to triage. Observed: it takes hours, mostly in I/O, and failures are hard to find in the noise. Root cause: the run dumped full waveforms of the entire hierarchy for the whole simulation (huge I/O — the dominant cost) and logged every cycle verbosely, so the simulator spent its time recording rather than computing, and the signal of a real failure drowned in output. Fix: in regression, disable the full waveform dump (or scope it tightly), reduce logging to leveled key events, enable optimized compilation, and model non-DUT blocks behaviorally; when a leveled log flags a failure, re-run that case with waveforms over a narrow window. Engineering takeaway: never dump everything in bulk regression — limit the waveform scope and log key events by level; full waveforms are a targeted debug tool, switched on only after a log localizes the failure.

-- BUG: full-hierarchy waveform dump + per-cycle verbose logging on a long regression → crawls, noisy.
-- FIX: regression = no/limited dump + leveled key-event logging + optimized compile;
--      debug = re-run the failing seed with waveforms over a narrow time window.

7. Common mistakes & what to watch for

• Dumping everything. Full-hierarchy waveform dumps are usually the biggest slowdown; scope the dump to what you need, when you need it.
• Per-cycle verbose logging. Log key events by level, not every cycle; verbose output both slows and obscures.
• Skipping optimized compilation. Enable simulator optimization for long runs; compile once, run many.
• Full-detail non-DUT logic. Replace surrounding RTL with behavioral models so events concentrate in the DUT.
• Not logging seed/config. Without them a lean regression failure cannot be reproduced under a detailed run.

8. Engineering insight & continuity

Fast, observable simulation comes from spending events wisely — limit the waveform dump (the biggest lever), cut needless activity, use optimized compilation, model non-DUT logic behaviorally — and from scalable logging: leveled, conditional, key-event-oriented, with seed/config recorded for reproducibility. Regressions run lean and log-scored; failures get a narrow, waveform-detailed re-run. This completes Module 15: Debugging and Simulation — you can now understand the engine, read its output, classify and trace any bug, instrument the design, and run verification at scale. The curriculum turns next from behavior to implementation: Module 16 — Synthesis and RTL Implementation, where RTL becomes real gates, timing, and resources.