CHIP DESIGN · COURSE

Advanced SoC Verification, Formal & Emulation

Scale verification from block tests to a reviewable SoC evidence system. Decompose product claims into observable obligations; build independent monitors, temporal scoreboards, reusable sequences, reset-safe components, and explicit configuration; measure constrained-random support and distributions; write assertion and formal environments whose assumptions are reachable and nonvacuous; classify coverage holes and challenge the plan with implementation and checker mutations; combine CDC, RDC, low-power, X-aware, equivalence, gate-level, SDF, and ECO evidence; run long firmware workloads on emulation or FPGA platforms with deterministic checkpoints; separate prototype observations from ASIC timing and silicon claims; and finish by reconciling one frozen SoC across 18 evidence groups and seven independent fault classes.

Before this course: Completed RTL Design; Functional Verification; SoC Integration & Hardware Security; Static Timing, CDC & Constraints; Physical Design; DFT; Tapeout; EDA Automation; and IP Qualification. Requires SystemVerilog assertions, temporal reasoning, probability, scripting, and basic firmware literacy. Commercial simulators, formal engines, emulators, proprietary VIP, foundry libraries, and production silicon require lawful external access and are not supplied.

COURSE FACTSStage, chapters, units, prerequisite, and outcome
Chapter 1

A verification plan decomposes claims into observable obligations

Objective: For “A verification plan decomposes claims into observable obligations,” which frozen inputs determine the result, what is the first independently observable claim, and which mutation proves the check is alive?

Each requirement becomes legal stimulus, forbidden stimulus, expected state transitions, data transformations, timing bounds, error behavior, observation points, checkers, coverage, negative tests, and exit evidence. This lesson uses the route “build the smallest observable case.” Begin with a hand-checkable instance before invoking automation: name the state that enters the step, the transformation that is permitted, the observation that must change, and the evidence that would falsify the claim. Turn requirements, hazards, interfaces, modes, errors, power states, security states, and software-visible behavior into an owned verification matrix. Connect every abstraction back to the physical structure or executable evidence it represents, and state where that representation stops being reliable.

A verification plan decomposes claims into observable obligations has a reviewable contract: A requirement closes only when its exact normal, boundary, simultaneous, reset, fault, security, and recovery obligations have live checkers and reviewed evidence. Name the applicable scope, identities, units, conditions, exclusions, threshold, evidence source, owner, and change rule before using the result. Separate control-plane success from design evidence: a process can exit zero while consuming the wrong revision, skipping work, reusing stale output, suppressing a violation, or publishing an incomplete artifact. A plan maps “DMA works” to one nominal transfer and omits abort, overlap, protection, partial write, and stale response cases. The learner must identify the first divergence and repair the dependency, not merely rerun until a dashboard becomes green.

A requirement closes only when its exact normal, boundary, simultaneous, reset, fault, security, and recovery obligations have live checkers and reviewed evidence. This invariant is accepted only for the named candidate and declared environment; any changed input invalidates every dependent result until reconstruction proves otherwise.

Freeze the exact objects, conditions, units, and source evidence in the worked case “Decompose a four-beat DMA requirement into data, ordering, privilege, error, timeout, reset, and recovery obligations.” First freeze the candidate and predict the expected observation without reading a generated summary.

Apply the stated physical or engineering model, showing each transformation and preserving values that fail, are missing, or remain outside the model. Then execute the smallest transformation, retaining raw standard output, standard error, exit status, generated files, and resource use.

Compare the derived observation with “A requirement closes only when its exact normal, boundary, simultaneous, reset, fault, security, and recovery obligations have live checkers and reviewed evidence.” and identify the first downstream decision invalidated by the failure boundary. Finally reconcile the observation with the invariant, inject the named failure, and verify that the expected consumer refuses the corrupted or stale state.

Decompose a four-beat DMA requirement into data, ordering, privilege, error, timeout, reset, and recovery obligations. Before revealing the trace, predict the exact command or state transition, expected exit and artifact status, first checker that should react, and minimum safe recovery.

  1. Freeze the exact objects, conditions, units, and source evidence in the worked case “Decompose a four-beat DMA requirement into data, ordering, privilege, error, timeout, reset, and recovery obligations.”
  2. Apply the stated physical or engineering model, showing each transformation and preserving values that fail, are missing, or remain outside the model.
  3. Compare the derived observation with “A requirement closes only when its exact normal, boundary, simultaneous, reset, fault, security, and recovery obligations have live checkers and reviewed evidence.” and identify the first downstream decision invalidated by the failure boundary.

Result: The resulting matrix exposes seven distinct checkable claims; a single passing transfer cannot close them. Accept the result only after a clean second execution reproduces the decisive artifact and a targeted mutation fails at the predicted boundary.