Skip to main content

9 min readMixed-Signal Verification

Mixed-Signal Co-Simulation Basics

How analog and digital simulators exchange data during co-simulation, what the handoff between solvers means, and how to structure mixed-signal testbenches.

  • Mixed-Signal Verification
  • Co-Simulation
  • Verilog-AMS
  • Testbench

ShareLinkedInX

Why Mixed-Signal Verification Needs Co-Simulation

Modern chips rarely live in a purely digital or purely analog world. A data converter feeds a digital filter, a phase-locked loop clocks a processor, a power regulator supplies a digital core, and sensor interfaces blend continuous-time front ends with logic decisions. Verifying these boundaries requires simulating the analog part with its continuous waveforms and the digital part with its event-driven engine at the same time.

That combined activity is mixed-signal co-simulation. Running the two domains separately is not enough, because the interesting failures usually live at the boundary: a metastable capture near a clock edge, a settle transient that violates a setup window, or a converter code that oscillates when feedback crosses the interface. Co-simulation lets one testbench observe both engines, so a stimulus applied digitally can be checked at a continuous node and vice versa. It also keeps a single source of time, which is essential when correlating events across domains.

How the Analog and Digital Solvers Interact

Under the hood, a mixed-signal simulator runs two distinct engines. The digital engine is event driven: it evaluates gates and processes only when signals change, which makes it efficient for millions of logic instances. The analog engine solves differential-algebraic equations on a discrete time grid, stepping through transient analysis and iterating to a convergence point at every step. The two engines advance through a shared timeline, and the simulator decides how often they synchronize.

At synchronization points, values cross the boundary: digital drivers present logic levels as voltages on analog nodes through connect modules, and analog voltages are translated back into logic values with configurable thresholds and logic families. Between synchronization points each engine can step independently, so the digital side is not forced to evaluate at every tiny analog time step. This discipline, often called a handoff or calibration point, is what makes co-simulation tractable while still exchanging accurate values.

Connect Modules and Signal Conversion

The bridge between domains is handled by connect modules, sometimes called interface elements. When a digital net is connected to an analog node in the netlist, the simulator automatically inserts a component that converts logic values into electrical quantities. The insertion rules matter: a digital output driving an analog load needs a driver strength, a supply reference, and a logic-to-voltage mapping, while an analog signal read digitally needs threshold voltages and, optionally, hysteresis so a noisy signal does not toggle the receiver repeatedly.

Teams should review the automatically inserted connect rules rather than assuming defaults are correct, because a wrong logic family or a missing supply reference can silently distort the interface. Undriven digital inputs crossing into the analog domain should be converted to a defined resistive state, and unknown logic values must have an explicit policy, whether that is resolving to a real voltage range or flagging an error. Getting these conversion rules right is foundational; every later check depends on them.

Choosing the Synchronization Interval

The rate at which the two engines exchange data controls both accuracy and runtime. A very fine synchronization interval forces frequent handoffs, which increases overhead but catches fast boundary events. A coarse interval lets each engine run longer between exchanges but risks missing a glitch that occurs between sync points. Many simulators choose the interval dynamically, tightening it when the analog side is active near a threshold and relaxing it during quiet periods.

Whatever the mechanism, verification teams should understand what happens to pulses shorter than the interval, since a narrow digital pulse crossing into the analog domain may be filtered, widened, or flagged depending on configuration. When a test is sensitive to boundary timing, such as a comparator deciding on a ramp or a clock crossing into a PLL model, deliberately tighten the interval and compare results. Documenting the chosen interval per testbench makes results reproducible and prevents later confusion when a waveform shifts by a fraction of a nanosecond between runs.

Structuring a Mixed-Signal Testbench

A disciplined testbench separates concerns so both engines see a coherent experiment. Keep digital stimulus, checkers, and scoreboarding in the event-driven domain, and keep analog sources, loads, and measurement probes in the continuous domain. Prefer real-valued modeling languages for analog behavioral blocks when transistor-level detail is unnecessary; a behavioral supply or converter model can cut runtime by orders of magnitude while preserving the interface behavior the test targets.

Route all cross-domain observations through named probes rather than ad hoc waveform inspection, so checks run automatically in regression. Define reset and startup sequences explicitly, because analog blocks often need time to reach an operating point before digital logic can safely interact. Finally, treat time-step control as part of the testbench: forcing an analog breakpoint at a known digital event, such as the start of a conversion, prevents the solver from straddling the event and smearing the result across two time steps. These habits make testbenches portable between simulators and reusable across projects.

Debugging Convergence and Time-Step Failures

Co-simulation introduces failure modes that pure-domain debugging never shows. The analog solver may fail to converge when a digital driver switches instantly into a stiff load, producing an error instead of a waveform. Slowly converging nodes, often caused by ideal switches or high-gain behavioral blocks, stretch the time step until the run appears hung. Discontinuous behavioral sources, such as a piecewise model with hard corners, can force the solver to reduce steps endlessly.

The first diagnostic move is to isolate the boundary: run the analog side with simple voltage drivers and the digital side with behavioral models, then recombine gradually until the failure appears. Increase iteration limits or add small conductances to ground on floating nodes to soften the equations, but treat these as directed fixes rather than global relaxation. Log the time step history near failures, since a step collapsing by orders of magnitude points directly at the offending element. Convergence debugging rewards patience and systematic bisection over trial and error.

Coverage and Regression Strategy for Co-Simulation

Because co-simulation runs are expensive, coverage must be planned rather than accumulated. Classify tests by what each proves: interface function checks confirm that connect rules and thresholds behave correctly, while corner checks explore supply voltage, temperature, and process variation near the boundary. Reserve full transistor-level simulation for the small set of tests where the analog detail changes the outcome, and use behavioral substitutes for regressions that only exercise digital logic on the other side of the interface.

Track boundary-specific coverage explicitly, such as converter codes exercised, threshold crossings observed, and handoff intervals tested, so the team knows which interface conditions remain unverified. Keep runtimes bounded with sensible abort limits, and fail tests that produce convergence warnings instead of letting them pass silently with suspicious waveforms. When regressions do flag a difference, correlate waveforms across engines at the same synchronization points before concluding anything. A deliberate mix of abstraction levels, with coverage tied to the boundary, keeps the schedule predictable without weakening the evidence.

A Practical Checklist Before Signoff

Before declaring a mixed-signal block verified, walk a short checklist. Confirm the connect rules inserted by the simulator match the intended logic family, supply, and drive strength, and that unknown-value behavior is deliberate. Verify that synchronization behavior near each boundary event was tested with a tightened interval at least once. Confirm that behavioral models used in regression were validated against the transistor-level view at least at nominal conditions, and that the differences are understood.

Check that reset, startup, and shutdown sequences cross the interface in a defined order, with no analog node left floating while digital logic is live. Ensure every cross-domain checker runs automatically and fails the test on violation rather than recording a warning. Finally, archive the simulation configuration, including solver options and time-step settings, with the results. Co-simulation results are only reproducible when the configuration that produced them is captured, and reproducibility is what turns a passing waveform into usable signoff evidence.

Frequently asked questions

What is the difference between co-simulation and simulation with behavioral models?

Co-simulation runs a continuous-time analog engine and an event-driven digital engine together on a shared timeline. Behavioral modeling is an abstraction choice inside either engine; you can co-simulate two transistor-level blocks or two behavioral blocks. Most mixed-signal regressions combine both: behavioral analog blocks co-simulated with detailed digital logic.

Why do connect modules matter so much in mixed-signal simulation?

Connect modules translate logic values into voltages and voltages back into logic values, including thresholds, hysteresis, drive strength, and supply references. If these rules do not match the real interface, every downstream check is measuring the wrong thing, so the automatically inserted conversion rules should always be reviewed.

How do I choose the analog-digital synchronization interval?

Start with the simulator default, then tighten the interval for tests whose outcome depends on boundary timing, such as comparator decisions or clock crossings. Compare results against a finer interval when accuracy matters, and document the setting per testbench so runs stay reproducible.

When should a mixed-signal regression use transistor-level simulation instead of behavioral models?

Use transistor level when the analog detail can change the pass or fail outcome, such as settling accuracy, comparator offset, or supply-sensitive thresholds. Use behavioral blocks for regressions that only exercise digital logic across the interface, and validate the behavioral models against the transistor view at nominal conditions.

More engineering notes

Working through a problem like this?

Tell us about your flow: the tools, the PDK, what is failing and when it needs to be clean.