Harry Foster’s September 2026 analysis of the Siemens EDA and Wilson Research Group Functional Verification Study reports that only 5% of responding IC/ASIC projects achieved first-silicon success, compared with 14.4% in the 2024 study. First-silicon success does not directly measure escaped functional defects, but the findings concern teams approaching ASIC tape-out. Logic and functional errors remain major contributors to silicon respins, even though functional verification already accounts for approximately half of reported IC/ASIC project time. The study does not establish a single cause for the decline, but it raises important questions about the effectiveness of existing verification strategies. [1, 2]
Figure 1: IC/ASIC first-silicon success across the Siemens EDA / Wilson Research Group studies. The 2024 and 2026 results use a changed recruitment approach. Sources: [1], [2], [3], [4].
At SoC level, the risk often lies in assumptions that have never been checked together. A DMA controller might pass every local protocol test, yet the system still reports an accelerator job complete before software can see all its output writes. The failure may depend on a firmware power-state request arriving during memory contention, conditions outside the original IP testbench. Verification must establish what the architecture permits at that point, account for outstanding transactions and check the result the driver sees.
What the 2026 study establishes
The study includes 604 qualified participants: 320 working on IC/ASIC projects and 284 on FPGA projects. Respondents reported that functional verification took an average of 49% of IC/ASIC project time, and that 97% of IC/ASIC projects included at least one embedded processor. Logic and functional errors remain significant contributors to ASIC respins. The research also reports contributions involving firmware, power, clocking, timing, safety and security. [2, 5, 6]
The 5% first-silicon success rate needs careful interpretation. It represents the proportion of responding projects reporting success on their first implementation, not the number of defects found in silicon. A project may require another spin because of an RTL functional error, an integration problem, timing or another cause. Foster’s research identifies reported contributors to respins, but it does not trace individual defects back to their origin. The results therefore cannot establish that SoC architectural complexity accounts for most of the decline.
The FPGA responses show clearer evidence of production escapes. In the 2026 survey, 98% of responding FPGA projects reported at least one non-trivial bug escaping into production; the 2024 FPGA report put that proportion at 87%. These are FPGA production-escape results, not counts of ASIC silicon bugs. They indicate escape prevalence among surveyed FPGA projects, not defects per project. [6, 7]
The study’s methodology also matters. Participant recruitment changed in 2024. The 2024 and 2026 studies share a more comparable recruitment approach, but direct comparisons with the 2007–2022 series require greater caution. Foster’s methodology reference explains this break in the historical series. [3]
The survey does not identify a single dominant cause of declining first-silicon success. However, Foster’s analysis highlights the growing verification challenges associated with interconnected hardware, embedded software and complex system operating conditions. [1, 5] In commentary on the results, Foster points to coherency problems in accelerator and CPU-cluster designs that are hard to expose before silicon, tighter coupling between hardware and software, and growing firmware, safety and security contributors to respins. These are interactions between components at SoC level, not defects confined to a single block. [5, 8] For SoC teams, the practical concern is whether existing verification plans adequately exercise these interactions, rather than assuming that independently verified components will function correctly once integrated.
Where SoC integration can defeat IP-level verification checks
Take a DMA engine. At block level, a UVM environment can exercise address calculation, burst formation, backpressure, register access and error responses. The scoreboard checks transferred data; assertions track the protocol and outstanding requests. All of those checks may be correct for the specified local interface.
Integration changes the conditions. Firmware may regard a DMA completion interrupt as permission to consume a buffer. The power controller may regard a quiesce acknowledgement as permission to switch off a clock or power domain. The interconnect may track accepted writes separately from those that have actually reached the completion and visibility point the architecture requires. If these interpretations are not aligned, each block can satisfy its local contract while the software-visible result is incorrect.
The ownership problem is easy to miss. The DMA team checks its completion indication. The power team checks its handshake. The firmware team checks its driver sequence. Unless a system-level requirement states exactly when data is safe to consume and when power-down is permitted, the gap between those checks can remain untested. The existing Alpinum article on IP, subsystem, and SoC verification examines how the roles of stimulus and checking change across integration levels; here, the concern is escaped behaviour at their boundary.
SoC use case: accelerator completion during a power transition
An accelerator job is close to completion when firmware requests a lower power state. Another CPU generates memory traffic, and several DMA writes still move through the interconnect. The driver eventually receives its completion interrupt, but the output buffer contains stale data. Nothing obvious has failed at the accelerator’s local interface.
Take a hypothetical SoC with an application CPU, an AI accelerator, an IOMMU and shared memory. The driver prepares the buffers, programs the job descriptor and starts execution. Under normal conditions, the result is correct. The architecture also allows power-state changes during accelerator activity, subject to a quiesce procedure that must complete before the affected domain can be powered down.
The failure could originate in how that handshake is interpreted. The DMA engine has stopped issuing requests and reports idle, but some writes the interconnect previously accepted have not yet completed. If the power controller uses the idle indication without accounting for those outstanding transfers, quiesce may be acknowledged prematurely. Completion signalling has a similar dependency: the driver must not be told the output data is ready until the architecture’s memory-visibility requirements are met. Figure 2 shows one illustrative sequence; the permitted ordering is defined by the specification.
Figure 2: SoC integration risk during accelerator power management. Writes accepted before the DMA engine reports idle remain in flight while quiesce and completion are signalled.
The testbench has to check the completed operation, not just the interrupt. For this workload, that means comparing the output buffer against a result calculated independently of the hardware implementation. The completion status, interrupt and quiesce handshake must be checked against the specification’s ordering rules, rather than an assumed universal sequence of events.
Cache behaviour also needs consideration. If software accesses the output through a non-coherent path, the driver must perform the required cache maintenance and ordering operations before reading it. Otherwise, the driver can observe a data mismatch even when the hardware has behaved correctly, which makes the failure easy to misdiagnose.
The power management specification dictates what constitutes a valid result. It may require the current job to complete before quiesce, or it may allow for cancellation with some defined error status. In the latter case, the test should verify that the system handles the outstanding traffic as required and reaches a valid recovery state. Waiting indefinitely for normal completion would test a requirement the architecture never made.
During debug, the useful evidence is the point at which the observed sequence departs from the specified one. Interconnect monitors provide the accepted requests and their responses. A control assertion can check whether quiesce is acknowledged with work still outstanding, provided the property tracks the relevant transactions and its assumptions hold at integration. Firmware traces identify when the job was submitted, when the power request occurred and which status the driver received. Linking those records by job and transaction identifiers makes it possible to work back from the incorrect output to the responsible transfer or state change.
Turn the use case into a sign-off obligation
Start by defining the software-visible contract. What is a completed accelerator job? At what point is the output of a job valid? What power transitions are permitted when a job is active, and what does the system guarantee in the case of a transition or error that necessitates an abort? Until those questions are answered precisely, additional stimulus increases activity, not verification.
The next task is to target the combinations that could invalidate the contract. For this example, those are: quiesce requested with outstanding writes; completion under sustained memory contention; interrupt/status ordering near a power transition; and recovery from an injected error. Coverage must distinguish a quiesce request issued while the path is idle from one issued while an accepted write has not yet completed. Only the latter exercises the integration risk.
No single execution environment provides all the evidence. A focused formal analysis may be able to establish a control invariant (e.g. no quiesce acknowledgement while tracked work remains), provided the assumptions and scope of that analysis are made explicit. RTL simulation provides strong visibility into interconnects and protocols. Emulation may be the right environment for longer, firmware-driven sequences. A post-silicon test can then be used to exercise the implementation under real operating conditions that pre-silicon models cannot capture.
The sign-off review should link each requirement to the exact scenarios run, their permitted configurations, the independent checks used, the observed outcomes, and any untested cases. Code coverage and a passing regression total help measure progress toward coverage closure, but neither indicates whether the customer-visible operation has been verified. Alpinum’s risk-based verification planning approach offers a practical way to prioritise such high-consequence integration conditions.
AI can help identify the missing cases; it cannot approve them
AI enters this discussion in two different ways. Accelerator-based products introduce new software-controlled data paths and more concurrent system behaviour. Separately, AI-assisted tools can help verification engineers analyse requirements, review coverage and debug regressions. The first changes the product being verified; the second may help engineers work through its verification plan.
Foster’s 2026 AI analysis reports that 82.8% of 604 survey participants used AI/ML beyond evaluation or pilot stages, while only 9.0% described it as broadly integrated across their verification flow. The study covers AI/ML methods, not generative AI alone. Reported uses include debug and root-cause analysis, test or testbench generation, and coverage analysis. [6, 9]
For the power-down case, an AI-assisted workflow could review the approved requirement, regression history and functional coverage, then suggest that the untested condition is quiesce overlapping accepted writes. It might propose additional legal timing relationships or group failures that share the same handshake state. Engineers still have to confirm the preconditions, constrain the stimulus correctly and specify the expected outcome from a trusted source.
Test and checker independence is particularly important. If one model misreads the same requirement while generating both a sequence and its expected answer, a passing result may only demonstrate a shared mistake. Keeping requirement interpretation, test generation and checking under separate review is more valuable than counting the extra tests. This is the control principle behind Alpinum’s AI in Design Verification services, which integrate automation into established engineering workflows.
Verification needs an owner for the complete operation
A sensible starting point is not another full-chip random regression. Choose a small set of customer-visible operations with expensive failure consequences: boot, firmware hand-off, coherent data sharing, power-state changes, accelerator work submission, privilege changes or recovery after an error. For each operation, identify which team owns the expected result and which lower-level assumptions it depends upon.
Harry Foster’s 2026 findings highlight the difficulty of achieving first-silicon success, although they do not establish a single cause for the decline. For SoC verification teams, particular attention is needed where IP blocks share resources, interact with firmware or respond to changes in system operating state. These conditions require explicit requirements, executable system-level tests and checks against the expected behaviour. The objective is to identify integration defects before tape-out, when failures can still be reproduced, diagnosed and corrected without the cost of another silicon revision.
Alpinum Consulting supports ASIC and SoC design verification across verification planning, IP integration, testbench development, system-level checking and verification closure.
References
Written by : Mike Bartley
Mike started in software testing in 1988 after completing a PhD in Math, moving to semiconductor Design Verification (DV) in 1994, verifying designs (on Silicon and FPGA) going into commercial and safety-related sectors such as mobile phones, automotive, comms, cloud/data servers, and Artificial Intelligence. Mike built and managed state-of-the-art DV teams inside several companies, specialising in CPU verification.
Mike founded and grew a DV services company to 450+ engineers globally, successfully delivering services and solutions to over 50+ clients.
Mike started Alpinum in April 2016 to deliver a range of start-of-the art industry solutions:
Alpinum AI provides tools and automations using Artificial Intelligence to help companies reduce development costs (by up to 90%!) Alpinum Services provides RTL to GDS VLSI services from nearshore and offshore centres in Vietnam, India, Egypt, Eastern Europe, Mexico and Costa Rica. Alpinum Consulting also provides strategic board level consultancy services, helping companies to grow. Alpinum training department provides self-paced, fully online training in System Verilog, UVM Introduction and Advanced, Formal Verification, DV methodologies for SV, UVM, VHDL and OSVVM and CPU/RISC-V. Alpinum Events organises a number of free-to-attend industry events
You can contact Mike (mike@alpinumconsulting.com or +44 7796 307958) or book a meeting with Mike using Calendly (https://calendly.com/mike-alpinum-consulting).
Stay Informed and Stay Ahead
Latest Articles, Guides and News
Explore related insights from Alpinum that dive deeper into design verification challenges, practical solutions, and expert perspectives from across the global engineering landscape.
