Why mixed-signal verification needs its own plan
Mixed-signal verification examines behavior that crosses analog and digital domains. Typical boundaries include comparators, data converters, clock generators, regulators, sensors, control loops, and power-management logic. A block can satisfy its isolated specification while the integrated design still fails because two domains interpret voltage, time, reset, or validity differently. The plan therefore has to describe the boundary behavior, not merely list simulations for each block.
A useful plan begins with requirements that can be observed. Instead of stating that a control loop must be robust, identify the legal commands, expected response, settling criteria, fault behavior, and operating assumptions. Every requirement should map to a test, assertion, measurement, review, or another explicit verification method. This mapping exposes requirements that are vague, duplicated, or impossible to check before they become late integration problems.
The plan should also separate functional intent from implementation detail. Functional intent covers what the interface must do. Implementation checks cover how the selected circuit and models realize that intent. Keeping the distinction visible lets fast abstract models verify broad behavior while detailed simulations address electrical effects that abstractions deliberately omit.
Define every analog-digital boundary
Create an interface inventory for signals crossing between domains. For each signal, record direction, units, nominal and legal ranges, threshold conventions, polarity, timing reference, initialization, and behavior when the value is unknown or outside its range. Include clocks, resets, supplies, references, bias controls, test modes, interrupts, and calibration buses. Power and reference signals are part of functional behavior because they can change whether a digital indication is meaningful.
Threshold definitions require particular care. A digital receiver may convert a continuous voltage into a logic value, but the transition policy must be explicit. Define high and low thresholds, hysteresis when applicable, and handling of the region between thresholds. A checker should not silently treat every intermediate value as valid logic. Likewise, a digital code driving an analog model needs a documented transfer function, update timing, saturation behavior, and response to illegal codes.
Initialization is another common source of disagreement. State whether analog outputs begin at a physical default, an unknown value, or a modeled startup trajectory. Define when monitors may begin checking and what event establishes validity. This prevents expected startup behavior from flooding regressions with false failures while still ensuring that a block reaches a usable state within its specified conditions.
Choose abstraction by verification purpose
No single model is ideal for every mixed-signal test. Transistor-level models represent circuit behavior in detail but can limit regression size and speed. Behavioral analog models can preserve continuous-time relationships while omitting internal devices. Real-number models carry numeric values through an event-driven simulation and are often effective for control-path integration. Logic-only models are suitable when a test needs protocol behavior but does not depend on analog magnitude.
Select the least detailed model that still represents the effect under test. A register-programming regression may need only legal sequencing and status behavior. A converter test may need quantization, saturation, latency, and error injection. A startup or stability investigation may require electrical detail that an event-driven abstraction cannot provide. The verification plan should state which requirements each model can support and which requirements remain outside its validity.
Model correlation is a controlled engineering activity rather than a one-time declaration. Compare model outputs against a trusted reference at selected operating points and transitions. Record the configuration, stimuli, tolerances, and known differences. When a model changes, rerun the relevant correlation checks. Version the model together with assumptions so a passing regression can be traced to the behavior it actually simulated.
Build stimulus, monitors, and checkers
Mixed-signal stimulus should cover nominal operation, boundary values, transitions, mode changes, and fault responses. Sequence digital programming with analog conditions such as supply ramps, reference changes, clock availability, and input movement. Exercise simultaneous events where ordering matters, but avoid relying on accidental simulator scheduling. Define synchronization points and sample windows so tests describe the intended timing relationship.
Use layered checking. Protocol assertions can verify register and handshake rules. Interface assertions can check that enables, resets, and validity indicators align. Numeric checkers can compare measured values with expected ranges or transfer functions. Temporal checkers can enforce response windows, pulse widths, and settling conditions. End-to-end scoreboards can connect an input condition to a later digital or analog result. Each checker should explain its tolerance and avoid hiding failures behind an overly broad acceptance band.
Analog results often need measurement windows rather than a single sample. Noise, ripple, settling, and clocked behavior can make an arbitrary instant misleading. Define when measurement begins, how long it lasts, and whether the result is a minimum, maximum, average, crossing time, or another quantity. Preserve enough diagnostic context to distinguish a design failure from a checker, model, or initialization problem.
Cover corners, faults, and configuration
A mixed-signal matrix can expand quickly across process conditions, supply values, temperatures, modes, trims, frequencies, and model choices. Do not multiply every dimension without purpose. Link each selected combination to a risk or requirement, then use representative regressions for broad checks and focused detailed runs for sensitive behavior. The plan should identify mandatory corners and explain where analysis or block-level evidence reduces the need for exhaustive integration runs.
Fault testing verifies that abnormal conditions produce controlled behavior. Candidates include missing clocks, invalid codes, out-of-range inputs, delayed references, interrupted calibration, supply sequencing errors, and status mismatches. Inject faults through supported model controls or testbench interfaces instead of modifying design behavior invisibly. Check detection, containment, reporting, recovery, and reset behavior as separate outcomes.
Configuration coverage must include more than register values. Track active model fidelity, compile options, parameter overrides, power intent, assertion settings, and enabled checkers. A passing test with a checker disabled or an unintended model selected is not equivalent to the planned result. Make the configuration visible in logs and summary artifacts so reviewers can reproduce and compare runs.
Measure coverage and close with evidence
Digital code and functional coverage remain useful, but they do not fully describe mixed-signal verification. Add requirement coverage, scenario coverage, interface transition coverage, checker activation, analog measurement coverage, corner coverage, and fault coverage. For numeric behavior, use meaningful bins tied to thresholds, ranges, and operating regions rather than arbitrary intervals. Cross coverage selectively where interaction matters, such as mode versus input range or supply condition versus startup result.
Review uncovered items before adding tests mechanically. A hole can indicate missing stimulus, an unreachable condition, an incorrect model, a disabled checker, or a requirement that needs clarification. Record the disposition. If an item is waived, retain the reason, approver, scope, and any compensating evidence. A waiver should identify a bounded exception rather than erase a category of behavior.
Closure evidence should bind results to the design, models, configuration, and requirements used. Preserve test identifiers, seeds where relevant, simulator options, corner definitions, model revisions, pass and fail summaries, measured values, assertion reports, and waiver decisions. Reproducibility matters because mixed-signal failures can depend on initialization and event ordering. A concise evidence package makes handoff more reliable and gives later changes a defensible baseline for regression impact.
The strongest plan is maintained as the design evolves. Interface changes trigger requirement and checker review. Model changes trigger correlation review. New modes trigger scenario and coverage updates. By treating boundaries, abstractions, and evidence as first-class verification objects, teams can find integration errors earlier and reach signoff with results that are both technically relevant and traceable.