Why evidence is harder at the analog and digital boundary

Mixed-signal verification joins two styles of engineering evidence. Digital verification often emphasizes repeatable transactions, assertions, functional coverage, and deterministic regressions. Analog verification emphasizes operating points, tolerances, waveforms, settling behavior, noise, distortion, and measurements taken from continuous signals. Neither style is sufficient by itself at the boundary. A passing digital transaction does not prove that an analog receiver met its limit, while a clean waveform does not prove that the surrounding control logic handled every legal sequence. The practical problem is not a lack of data. It is the lack of a shared explanation for what each result proves. A useful evidence trail links a requirement to a test intent, the configuration used to exercise it, the observations collected, and the decision made by the reviewer. That link should survive reruns and should remain understandable when the original author is not available. Treating evidence as a designed artifact makes the handoff more reliable than collecting screenshots at the end of a project.

Start with requirements and observable boundaries

Begin by translating each mixed-signal requirement into an observable boundary. For an interface, identify the legal input range, timing relationship, threshold, response window, and expected digital outcome. For a converter or sensor path, identify the stimulus, measurement method, tolerance, and conditions under which the result is valid. Avoid vague goals such as verify the interface. Replace them with statements that define what can be measured and what constitutes an acceptable result. A requirement record should identify its owner, source, verification method, and status. It should also point to the test or measurement that supplies evidence. This structure exposes gaps early. If a requirement has no observable result, the team can decide whether the specification needs clarification or whether a new monitor is needed. If several requirements depend on the same boundary, shared monitors and reusable setup data can reduce duplicated work without hiding which requirement each result addresses.

Make operating conditions part of every result

An analog result has little meaning without its conditions. Record supply settings, temperature assumptions, process or model selection, clock relationships, initial state, load, stimulus shape, and relevant tolerances alongside the measured value. Digital context matters too: protocol state, reset sequence, configuration fields, transaction ordering, and the model versions used by the testbench can change the interpretation of a waveform. Use structured run metadata rather than relying on directory names or informal notes. A result should be reproducible from a bounded set of inputs. Include the test identifier, revision, simulator or environment identity where the flow provides it, and the measurement definitions. When a result is regenerated, the comparison should distinguish a real design change from a changed setup. This discipline also prevents a nominal-case pass from being reused as evidence for conditions that were never exercised.

Connect analog measurements to digital checks

The strongest mixed-signal evidence connects a continuous measurement to a discrete assertion or decision. For example, a threshold crossing can be measured in the analog domain and then checked against the expected digital transition, including the permitted response interval. A calibration sequence can record the analog settling result while a digital monitor checks the returned code, status bit, and error handling. Define the boundary contract explicitly. Name the signal or transaction, state the units, specify edge and sampling rules, and document how unknown, missing, or out-of-range values are handled. Keep the measurement algorithm versioned and reviewable. If a checker reduces a waveform to one Boolean result, retain enough supporting data to diagnose a failure. A concise summary is useful for regressions, but a summary without traceable inputs can turn a passing run into an unreviewable claim.

Design regressions for diagnosis, not only volume

A regression should answer which requirements were exercised and what evidence was produced. Group tests by intent, operating condition, and interface behavior so that a failure has a meaningful location in the verification plan. Separate setup failures, model failures, checker failures, and design failures instead of treating every non-pass outcome as the same kind of defect. Store logs and measurements with stable identifiers and clear retention rules. Summaries should report pass, fail, blocked, and not-run distinctly. Unknown coverage is not zero coverage, and a missing measurement is not a passing measurement. When a test is quarantined or waived, preserve the reason, scope, approver, and expiration or review condition. This makes the regression honest and gives the team a prioritized queue rather than an attractive but incomplete dashboard.

Review and package evidence for signoff

At signoff, package evidence around decisions rather than around tools. For every requirement, show the selected test or measurement, the relevant conditions, the result, and the review state. Link failures to their disposition and link waivers to their boundaries. Include the environment and artifact identifiers needed to reproduce or inspect the result. A reviewer should be able to determine what was tested, what was not tested, and what assumptions remain. A compact evidence index can point to detailed logs, plots, and machine-readable summaries without copying every artifact into a report. Review the index for stale links, inconsistent units, missing conditions, and ambiguous status labels. The goal is not to claim that every behavior is exhaustively simulated. The goal is to make the confidence boundary explicit and defensible. Before approval, perform a final consistency review across the evidence set. Check that the requirement wording, test intent, measurement units, and status vocabulary agree. Confirm that the reported result was generated from the named configuration and that any manual interpretation is recorded separately from machine-produced measurements. If an artifact is unavailable, mark it unavailable and identify the recovery owner rather than inferring a result from neighboring runs. This final review turns a collection of technical outputs into a signoff package that another engineer can audit, reproduce, and maintain.