How Far Left Can We Really Shift Verification?

“Shift left” has been in the engineering lexicon for so long that it risks becoming wallpaper. We nod at it, we put it on slides, and we move on. But the goalposts keep moving. Things that used to live comfortably at the tail end of the design flow — software bring-up, power and performance characterization, thermal analysis — are being dragged earlier and earlier into the schedule, driven by the need to not only meet schedules, but meeting them with the right design characteristics. Today, in 2026, the interesting question is no longer whether to shift left. It is how far left you can realistically go, and what is suddenly making territory accessible that was off-limits only a few years ago.

I talked this through with Ed Sperling recently, whiteboard and all, and the honest answer is that the line keeps extending further than most of us would have dared to draw it at the start of our careers.

Where verification never ends

Let’s start with an uncomfortable truth: verification doesn’t really stop. It continues through tape-out, and it continues after silicon comes back. What changes along the way is not whether you are still verifying the design, but whether you can still do anything about what you find.

Somewhere in the flow, you cross into an engineering-change-order-only phase. The design has been handed to an ASIC house or pushed through your own custom tooling, the implementation is locked, and functional changes are simply off the table. That hard boundary is the whole reason shift-left matters. Everything that needs to influence the design — every workload that should shape an architectural decision, every power number that should drive a packaging choice — has to land before that wall. After it, you are living with what you committed to.

And the amount of issues that need to land before the wall keeps growing.

It is no longer just RTL. You have the full software stack to bring up: low-level drivers, an operating system, middleware, and eventually the applications themselves. In an AI-driven software-defined world, those applications — the workloads — are precisely the things you most need to run early, because they determine whether your silicon plus software actually hits its targets. Pulling that entire stack forward, ahead of the point of no return, is the real work of shifting left.

From virtual prototypes to emulation and FPGA-based prototyping

So how do you actually do it? The toolchain has matured into a continuum that lets you start almost absurdly early and hand off cleanly as the design firms up.

At the earliest phase, before RTL is even complete, virtual prototypes let teams run real software and feed actual data into early power analysis. AI workloads — and the high-speed interfaces like PCI Express that feed them — can be exercised here long before there is anything resembling a netlist. As the design matures, that same effort moves onto emulation and then onto FPGA-based prototypes, where you get into the tens of megahertz and can run serious software, compliance, and certification work well ahead of committing to silicon.

The leverage multiplies when you stop building everything from scratch. A good example is the work around pre-integrated subsystems. Take an Arm compute subsystem, pair it with proven interface IP — PCI Express, DDR, UCIe for chiplet-based systems, USB — and you have a platform that customers can stand up on a virtual prototype or in emulation without reinventing the plumbing. AMI has publicly described bringing up its BIOS on exactly this kind of environment, validating firmware against the integrated subsystem in emulation long before real silicon existed. Those are reuse items that pay off across many designs for AMI/Arm/Synopsys mutual customers.

Chip developers are increasingly precise about where they spend their differentiation budget. Rebellions, for instance, has run its AI accelerator chips in emulation with the surrounding compute subsystem virtualized around them, optimizing how cycles move between the subsystem and the accelerator before the design is corrected and committed. They differentiate on the accelerator and the software wrapped around it, and they lean on proven components for everything else. Given the complexity and the time pressure, that is simply rational. Nobody has the schedule to make every block special.

Beyond function: Power, thermal, and the first-silicon question

Here is where it gets genuinely new. For years, the headline metric for a project was first-time silicon: did the chip come up and work? Hey, I have literally written about this here 12 years ago in “The Great Shift To The Left.” By that measure, the numbers have actually gotten worse as functional verification is the leading cause of re-spins. But that statistic deserves a closer reading. A growing share of “failures” are not chips that don’t function — they are chips that function but miss expectations on power, performance, or thermal behavior. The chip works. It just isn’t the chip the team thought they were building.

That reframing is what pushes shift left into multiphysics, for instance. The activity data that emulation generates as workloads run can now feed directly into power analysis that eventually informs the thermal aspects. You can see where on the die a given workload concentrates activity, hones in on that region in emulation, and pours those cycles into the computationally expensive thermal models to find out where the real hotspots sit and where you’ll see IR drop. Knowing the genuine maximum thermal envelope for your actual workloads — rather than a worst-case guess — lets teams design more aggressively and choose a more optimal package. And it goes further still, into structural and warpage effects that used to surface only after the package was built.

None of this was on the whiteboard a decade ago. Power analysis fed by emulation, connected through architecture analysis into thermal models, all before tape-out — that is new far-left territory, and it is where a lot of value now lives.

Figure 1 illustrates several ways to shift left, from (1) architecture analysis through (2) pre-integrated IP as we at Synopsys enable with our partner Arm, through (3) early software development on virtual prototypes, (4) early VIP/IP integration through (5) pre-silicon power and performance analysis, (6) software development on high-fidelity hardware representations in emulation and FPGA-based prototyping, QuickStart implementation Kits (QIKs) — customizable, pre-packaged reference flows and methodologies — and Silicon Lifecycle Management (SLM) aspects integrated and used pre-silicon.

Fig. 1: Several shift-lefts add up to significant time & effort savings.

Pushing further still

Two forces are extending the line even more. The first is agentic AI. We are starting to talk about “agent engineers” — agents that run and optimize the verification and bring-up process itself, getting workloads onto emulation and virtual prototypes earlier and verifying IP together with the system around it. The second is spec engineering: using AI to take a design specification and reflect it into implementation as accurately and completely as possible. Compress that translation from intent to implementation, and you compress the whole schedule. Both are early, but both point the same direction — more of the design’s destiny is decided sooner.

And then there are levels of simulation function and defining requirements independently of hardware/software decisions at the system-level. I remember discussing “UML for SoC Design” more towards the beginning of my career with Grant Martin, and this year — two decades later — MBSE connections from SysML to chip design will be front and center in the aerospace/defense sections of the upcoming DAC, as I outlined in Where Chips Meet Missions: Why Aerospace & Defense Engineers Should Attend DAC 2026 in Long Beach).

The engineer is still in the loop

If I am honest, at the beginning of my career I never dreamed of shifting this far left. When developing multimedia chips in the 90s, the idea that you could integrate multiphysics — power, performance, thermal, structural — and reason about all of it before silicon would have seemed like wishful thinking. Even the best architects in the world struggled to hold that much complexity in their heads at once.

What changed is not just the tools but the partner. With design flows from architecture through software enablement, HW/SW verification using emulation and FPGA-based prototyping, all tied to multiphysics and agentic AI getting more and more in the loop, engineers can now actually manage that level of complexity and bring it all together, rather than choosing which dimensions to ignore.

The line that runs across the whiteboard keeps extending to the left — and that is really a challenge worth tackling!