AMS Verification Challenges: Why Mixed-Signal Programmes Still Fail Late

Modern semiconductor programmes rarely fail because a single block is difficult in isolation. They fail when analogue behaviour, digital control, embedded software, power intent, timing assumptions and product-level use cases do not come together early enough.

This is why AMS verification challenges remain a major source of late programme risk. Analogue mixed-signal functionality is now deeply embedded inside SoCs, chiplets, sensors, automotive systems, communications devices, AI accelerators and connected products. PLLs, ADCs, DACs, power-management units, SerDes interfaces, sensor front-ends, calibration loops, and control firmware often sit at the boundary between continuous-time analogue behaviour and discrete digital decision-making.

That boundary is where many verification problems become expensive.

5 Key Learning Points

A mixed-signal design can pass block-level checks, meet local specifications and still fail during system integration. The root cause may be a model assumption, a missing operating mode, an incomplete calibration sequence, a power-state transition, a PVT corner, or an interaction between analogue response and digital control logic. By the time these issues appear at the SoC level, debug is slower, ownership is less clear, and schedule pressure is higher.

For engineering teams, the question is no longer whether AMS verification is needed. The question is whether AMS verification is being treated as a system-level discipline early enough.

Figure 1: AMS verification challenges in mixed-signal SoC programmes.Source: Cadence

Figure 1 shows the mixed-signal verification methodology across analogue and digital domains. AMS verification requires coordinated modelling, assertions, planning and system-level interaction analysis.

Why is AMS verification becoming a bigger programme risk

SoCs are carrying more analogue and mixed-signal functionality than many programme plans openly recognise. Even highly digital products depend on analogue behaviour for clocking, sensing, power conversion, data conversion, high-speed interfaces, voltage monitoring, thermal control and physical-world interaction.

This creates a verification challenge that is broader than analogue design alone. The analogue block may behave correctly under its local assumptions, but the product can still fail if the digital controller configures it incorrectly, firmware enters an unexpected sequence, power domains transition in the wrong order, or system software assumes a response time that the analogue circuit cannot meet across corners.

Digital-only verification methods are strong when behaviour can be represented by discrete states, transactions, assertions, and coverage models. AMS verification must also consider continuous-time response, real-world tolerances, analogue settling, noise, jitter, mismatch, non-linearity and environmental variation.

The result is a larger verification problem than the block diagram suggests. This is why AMS verification should be considered part of a wider system-scale programme risk in verification, rather than a narrow analogue design concern.

Where AMS development breaks down

Many AMS programmes lose time before verification execution even begins. The issue is often not poor engineering effort. It is unclear what the verification intent is.

Specifications may describe nominal behaviour but leave gaps around start-up, shut-down, calibration, fault handling, power modes, degraded operation or interaction with firmware. Analogue and digital teams may interpret the same requirement differently. A timing assumption that is obvious to the analogue designer may not be visible to the digital verification team. A firmware sequence may be valid in the software plan, but untested against analogue settling behaviour.

These gaps become more serious when model availability is late. If behavioural models arrive after digital verification environments are already built, mixed-signal checks are added as a patch rather than designed into the verification architecture. If transistor-level simulations remain the only trusted source of truth, system-level verification becomes too slow. If simplified models are used without validation evidence, the team may gain simulation throughput while losing confidence in the results.

The breakdown usually appears in four areas: requirements, models, ownership and evidence.

Why mixed-signal SoC verification is harder than digital-only verification

Mixed-signal SoC verification is difficult because it combines different engineering domains with different assumptions.

Digital verification usually benefits from structured stimulus, checkers, assertions, functional coverage and regression automation. AMS verification must also address behaviours that are continuous, corner-dependent, and often difficult to observe directly.

A PLL may lock under one operating condition but fail under another. An ADC may meet resolution expectations in a clean testbench but behave differently under noise, supply variation or temperature. A power-management unit may work correctly in a local simulation but fail during a system-level transition. A calibration loop may converge in normal conditions but take too long in a rare product state.

These are not simply analogue issues. They are system interaction issues.

The challenge becomes harder when firmware is involved. Many AMS blocks are configured, calibrated or supervised by embedded software. If verification does not include realistic firmware sequences or software-facing scenarios, the team may miss the conditions that matter most in the product.

The modelling problem: accuracy versus simulation speed

The central modelling challenge in AMS verification is choosing the right abstraction at the right point in the programme.

Transistor-level simulation provides high accuracy, but it is too slow for broad SoC-level regression. Behavioural models and real-number models can improve speed, but they must be validated against the circuit behaviour they represent. A model that is fast but inaccurate can create false confidence. A model that is accurate but too slow may be used too narrowly to expose integration issues.

This creates a trade-off between accuracy, coverage and throughput.

A mature AMS verification strategy typically requires multiple model levels. Detailed SPICE-level analysis is needed for circuit-level confidence. Behavioural models are needed for system-level exploration. Real-number modelling can help digital-centric environments exercise mixed-signal behaviour at scale. Cadence has described real-number modelling as a way to support high-performance, digital-centric mixed-signal SoC verification, while still requiring disciplined modelling and validation choices. [3]

The important point is not to choose one modelling approach as the answer. The important point is to define what each model is trusted to prove.

Without this discipline, teams end up debating whether a failure is a design bug, a model bug, a testbench limitation or a false expectation.

Why UVM-MS matters for AMS verification

UVM-MS matters because it recognises that mixed-signal verification needs a more consistent methodology.

Accellera describes UVM-MS 1.0 as a UVM-based mixed-signal methodology intended to improve AMS and DMS verification of integrated circuits and systems. It extends digital-centric UVM concepts, enabling teams to build mixed-signal verification components and testbenches more consistently. [1]

This is important because many verification teams already use UVM for digital verification. UVM-MS helps bring mixed-signal awareness into a familiar verification methodology, rather than treating AMS verification as a separate, manual, or late-stage activity. Siemens has also described UVM-MS 1.0 as a framework that integrates digital-centric UVM classes with analogue and mixed-signal verification techniques. [2]

However, UVM-MS should not be presented as a complete solution on its own. It does not remove the need for strong verification planning, model validation, requirements traceability, abstraction strategy, analogue design judgement or sign-off evidence. It provides a stronger methodological foundation, but the engineering team still needs to decide what to verify, where to verify it, which models to trust and what evidence is sufficient.

That distinction is important for credibility.

The five places where AMS programmes lose time

1. Specification ambiguity

Late AMS failures often start with unclear requirements. A specification may define nominal performance but omit behaviour across power states, temperatures, process variations, calibration sequences, or fault conditions. If these expectations are not captured early, verification teams cannot build meaningful checks.

2. Model mismatch

A behavioural model may not accurately reflect the real circuit. A transistor-level model may be too slow for system-level use. A real-number model may support regression speed but miss important analogue behaviour. Without a model validation plan, teams may not know which result to trust.

3. Late integration

AMS blocks are often verified locally for too long before they are exercised in the wider SoC context. When analogue, digital, firmware and power behaviour finally come together, failures are harder to isolate and more expensive to fix.

4. Poor observability

Mixed-signal bugs are often difficult to observe. The failure may appear as a digital symptom, but the cause may be analogue settling, jitter, noise, calibration drift, supply behaviour or timing interaction. If observability is not planned, debugging becomes slow and uncertain.

5. Unclear sign-off evidence

AMS sign-off cannot depend only on passing simulations. Teams need to know which requirements have been verified, which models were used, which corners were covered, which assumptions remain open and which results are traceable to product-level risks.

What engineering teams should do earlier

The strongest AMS verification improvements happen before the first major regression.

Teams should define verification intent at the requirements stage. This means identifying the behaviours that must be proven, the assumptions that must be challenged and the product-level risks that must be represented in the test plan.

They should also define a model strategy early. Each model should have a purpose, a validation path and a known limitation. The team should be clear about which model supports block-level accuracy, which supports system-level throughput, and which is suitable for regression.

Ownership also needs to be explicit. AMS verification sits between analogue design, digital verification, firmware, system architecture and product engineering. If ownership is vague, issues move between teams without resolution. A clear review structure helps ensure that requirements, models, checks, coverage and sign-off evidence are owned throughout the programme.

This is closely connected to verification planning to coverage closure, because AMS confidence depends on linking requirements, scenarios, models, checks and evidence rather than relying on disconnected simulation activity.

Finally, AMS verification should include review gates. These gates should check whether models are ready, whether critical scenarios are represented, whether analogue-digital interactions are observable and whether sign-off evidence is building throughout the project.

Alpinum view: AMS verification is a system-level discipline

AMS verification should not be treated as a late specialist activity added only after digital verification has matured. It should be treated as a system-level discipline that connects requirements, modelling, verification planning, debug strategy and sign-off confidence.

The teams that reduce late AMS risk are usually not the teams that run the most simulations. They are the teams that clearly define verification intent, carefully select abstraction levels, validate models, create observable checks, and continuously review evidence.

This is where Alpinum’s engineering-led design verification capability is valuable. AMS verification needs more than tool knowledge. It needs a strategy that connects mixed-signal behaviour to programme risk, product behaviour, and measurable confidence in verification.

Where teams are also exploring automation, triage or regression support, AI in Design Verification should be applied with the same discipline: reviewable evidence, clear ownership, traceability and human engineering judgement.

For semiconductor teams working on complex SoCs, chiplets, automotive electronics, AI hardware, sensors, or connected systems, the goal should be clear: identify mixed-signal integration risks before they become a late-stage programme failure.

Need stronger AMS verification planning before integration risk becomes expensive?

Alpinum helps engineering teams improve verification strategy, model planning, evidence review and sign-off confidence for complex semiconductor programmes.

Speak to Alpinum about design verification support

https://alpinumconsulting.com/contact-us/