Siemens EDA and the Wilson Research Group recently jointly released the *2026 Functional Verification Study*. 

One of the most notable findings is that among the surveyed IC/ASIC projects, only 5% of teams achieved "First Silicon" success on the first attempt—down from 14.4% in 2024.

At the same time, surveys indicate that the vast majority of projects undergo multiple tape-out iterations before reaching mass production, and achieving success on the first attempt is becoming increasingly difficult.

Reasons for the decrease in success rate

Many people tend to attribute this phenomenon to a single factor—such as a shortage of verification engineers, inadequate verification methodologies, schedule pressures, ever-increasing design scale, or insufficient automation. However, this 2026 study does not support such a simplistic conclusion. A key insight from the report is that the nature of complexity itself has changed.

The study notes that today's verification environments increasingly deal with processor-rich, accelerated computing systems. These systems not only incorporate embedded software but must also meet requirements for safety, reliability, and other assurances. They are no longer merely scaled-up versions of traditional RTL designs; instead, they are a new breed of system—software-driven, heterogeneous, and highly interconnected—characterized by extensive system-level interactions that transcend traditional functional boundaries.

Consequently, the challenges facing verification are also evolving.

The report indicates that logic and functional errors remain the primary drivers of ASIC redesigns; however, firmware, security, power, clocking, timing, and other system-level issues have also emerged as significant sources of tape-out failure. FPGA survey results corroborate this trend: while traditional logic and functional defects remain prominent, they represent only a fraction of the factors that can lead to production-stage failures.

Consequently, the study suggests that caution is warranted when interpreting "first-pass success" rates for chips. The critical question may no longer be simply whether traditional functional verification has been completed, but rather whether the scope of required verification is expanding more rapidly than the boundaries defined by traditional verification methods.

The study conveys several interconnected signals indicating the rapid convergence of previously distinct engineering domains. For instance, Design for Test (DFT) is becoming tightly integrated with broader functional verification environments; the link between security and safety is strengthening; and AI and machine learning are transforming verification workflows—impacting areas such as test generation, coverage analysis, debugging, regression optimization, and formal verification.

The study emphasizes that these changes reflect not merely the continued growth in design scale, but a fundamental shift in the nature of verification challenges themselves.

Notably, the report does not attribute the decline in first-pass success rates to any single factor—such as increased processor counts, AI acceleration, heightened security requirements, or DFT integration. Instead, it reveals that multiple characteristics of the verification landscape are evolving simultaneously, collectively shaping a new set of verification challenges.

Verification has become a top priority

I have no doubt about the figure itself. What I am unsure of is how much of that represents genuine verification versus other tasks masquerading as verification.

Sometimes, technical issues are the true bottleneck. But more often, the bottleneck lies in the workflow.

There are many reasons for bottlenecks in the chip delivery process, yet one category of causes remains consistently hidden. They stay hidden because we don't actively look for them, nor do we eliminate them the way we fix circuit designs or code bugs. We only address them when the impact becomes significant, yet they rarely become a priority for chip development teams. We are not alone in this; such challenges are pervasive across industries. Neither MBA nor engineering curricula cover this, and there is scant literature on how to eliminate these types of issues from the design process.

Workflow flaws are invisible bottlenecks. They delay product launch dates and waste engineers' time. A workflow flaw refers to any error that arises during the work process. For instance, you need data on Tuesday but don't receive it until Thursday; an upstream team sends incorrect data to a downstream team, stalling work until the issue is resolved; tools are updated, but no one knows how to use them correctly; or bug reports lack clarity, halting debugging efforts until the problem is explained. The list goes on.

Workflow flaws arise from change, increasing process complexity, and oversight. Although we constantly encounter these flaws, they are rarely fixed in a way that prevents them from recurring. We treat our products differently than our workflows. When designing development processes, we focus on stages, milestones, and integration points. We think like architects: once the framework is in place, we start building the product. Ready, fire, aim.

At the time, I was leading a post-silicon design team responsible for a new type of NAND flash memory chip. Representatives from various functional departments were ready, and everyone eagerly awaited the arrival of the first wafer at the lab. We had plans in place to launch testing immediately upon the wafer's arrival—day or night, seven days a week.

When the chips arrived, we got to work right away. We held daily morning meetings to discuss priorities, because no matter how thorough the plan, the production of the first chip is always full of variables. Everything proceeded smoothly. The chip was operating correctly, and its functions were working as intended; we could read, write, and erase flash memory cells. We began implementing features that had been deferred until the post-silicon phase and enabled additional tests for product engineering. The goal of the post-silicon design phase is to transition product engineering and wafer fabrication into the critical path, having already fully realized the design's intended functionality. Now, we had to address yield and production ramp-up issues.

Ultimately, we had to stop making modifications. The plan was to complete wafer-level data collection, verify and confirm the changes, finalize the layout adjustments, run back-end processes (such as ERC and DRC), and send the database to the mask shop.

The plan fell apart. Eventually, the project manager came to my cubicle to demand why we had missed our first progress report deadline. We had been working overtime—sometimes even through the weekends—yet I couldn't provide a satisfactory answer. I didn't know exactly what had caused such a significant delay.

I reintroduced a tool I had used at the factory during my time as the New Product Introduction (NPI) lead—the very tool that had helped us achieve a 22-day delivery cycle, down from our previous best of 35 days. We mapped out our design workflow just as we would a factory process flow, trying to pinpoint why we were three weeks behind schedule on a five-week plan. Being the leader in this situation was far from easy; I could feel the eyes of the entire company fixed on our team and me.

The analysis revealed that our pre-silicon verification process was too slow for the post-silicon phase. In the pre-silicon stage, milestones were spaced months apart, so a seven-day cycle for a full data iteration was acceptable. Ultimately, we ran three verification cycles to refine the design, taking a total of 21 days.

To get back on track, we redesigned our workflow. I challenged the team to cut the verification cycle to three days—the timeframe my calculations showed was necessary to meet the five-week overall schedule. I still remember the looks on their faces when I announced this goal; I think they thought I was crazy. But we persevered. First: automation, automation, automation. We had to eliminate manual reviews of simulation and chip data. We negotiated with our pre-silicon partners to secure the fastest servers for simulation and borrowed the majority of their software licenses for the final verification sprint. We made a dozen other adjustments and ultimately finalized a workflow with a 3.5-day verification cycle. We continued to optimize through the subsequent phases, consistently hitting our five-week cycle target for the next ten stages.

On the surface, this might look like a typical silicon engineering problem. But consider what was actually happening. We knew how to handle circuit checks, analog and logic design, datapath design, physical layout, and database fracturing for the mask shop. What we hadn't done was design the workflow itself to ensure all these tasks could be completed within five weeks. Dozens of workflow flaws were hindering us relative to that five-week target; once we eliminated them, our verification cycle was cut in half.

Later in my career, eliminating flaws in development processes became a primary focus—a key way I helped scale the company's SSD business. Since then, I've worked with hundreds of similar process maps across diverse fields: PCB, QA, ASIC and firmware design, packaging, product lifecycles, customer engineering, marketing, finance, and supply chain. Silicon product development is incredibly complex and constantly evolving.

Workflow flaws act as invisible bottlenecks that impede chip delivery and the scaling of product development operations. In a complex, ever-changing world, the work itself—and the products we create—are becoming increasingly difficult. Rising complexity and constant change are seeping into our workflows, slowing down teams and draining already scarce resources.

My advice: Design your work just as engineers design products. Ensure clear objectives, practical functionality, alignment, and a tight cadence. Don't let invisible bottlenecks waste time you can never get back.

Source: Semiconductor Industry Watch

View more at EASELINK