From Future Vision To Running Hardware: Verification At DAC 2026

At last year’s DAC in San Francisco, I sat in “A Look into the Future of Verification,” an Engineering Track special session debating where our discipline is headed — multi-language flows, AI co-pilots, portable stimulus, formal methods. The discussion was energizing, and what struck me then stayed with me since: whatever that future looks like, it has to execute somewhere. And increasingly, that is where there is hardware — emulation and FPGA-based prototyping.

I recently wrote in How Far Left Can We Really Shift Verification? that shifting left only works if there is something fast enough or abstracted enough to shift onto. Last year’s session touched on many engines — formal, simulation, portable stimulus, and more — and the framing Synopsys has used for more than a decade ties them together as the verification continuum: virtual prototyping, static and formal, simulation, emulation, and FPGA prototyping arranged as one flow from most abstract to most hardware-focused, where a design trades debug visibility for fidelity as it moves toward implementation and content flows between adjacent stops as it matures.

At the upcoming DAC 2026 in Long Beach (July 26–29), the Engineering Track shows exactly what that means in practice: users running software test automation on emulators, users automating the handoff between simulation and FPGA-based prototypes, debug across engines, and a special session dedicated to the hardware itself.

Last year’s question: Where is verification going?

The DAC 2025 Engineering Track special session A Look into the Future of Verification, moderated by Dusica Glisic of Veriest Solutions, brought four speakers from four semiconductor companies onto one stage, and four themes emerged that frame this year.

The first, from Matthew Ballance of AMD, was that the future of verification is multi-language. His case rests on ecosystems: Python brings a vast, readily installable library universe and far more programmers than the community fluent in SystemVerilog. The path forward is not one universal language but reusable libraries bridging pairs — Python and SystemVerilog first — so test content, introspection, and semantics cross the boundary cleanly, ideally through a common set developed via a body like Accellera.

The second, from Jean-Christophe Glas of Arm, was AI moving from demos into production verification flows. He described agent-based systems that fetch design models, generate tests with added context, and present anonymized results with confidence scores. The efficiency estimate was carefully hedged: at least ten percent projected, while aiming much higher. Just as important was the caveat: EDA companies build the tools, but the data belongs to the companies building chips and systems — so making AI work demands far closer collaboration than tool licensing ever required.

Third, from Mike Chin of Intel: abstraction earns its keep. Portable stimulus emerged as a medium for expressing legal hardware behavior — constraints machine-generated scenarios cannot violate — paired with machine learning driving coverage closure. LLMs, meanwhile, are earning a place in test planning as co-pilots. The panel’s consensus: let the LLM give hints; let the engineer decide.

And fourth, from Shahid Ikram of Marvell, formal and AI as yin and yang — one generative, one analytical, each guarding the other’s blind spots. Formal, he argued, is where the thinking happens: it will not let you proceed without proper reasoning. His team generates test plans from English-language descriptions, compressing a week or two of work into days. But specifications are more than English — waveforms, diagrams, and traces carry meaning text never will, which is why multimodality matters.

My own question from the floor connects last year to this one. When AI generates the testbench, the interface to the execution engines — simulators, emulators, prototypes — remains a defined language like Verilog. If engineers no longer read the generated code, debug becomes a code review of a stranger’s work. Who arbitrates when the AI-generated code and the human disagree? That arbitration happens where verification actually runs. Which brings us to the hardware.

Emulation as the shift-left substrate — with an LLM in the loop

A presentation in this year’s System & Software Deployment session shows both threads converging. In Enabling Automated Software Testing in Emulation Environments via Fastboot Virtualization and On-Premises LLM-Based Failure Analysis — presented by Haemin Park of Samsung — engineers take a workflow that traditionally lives post-silicon — automated Android software testing with unattended flashing, reboot, and recovery — and move it onto emulation, pre-silicon. Fastboot virtualization provides device control without native fastboot on the emulation platform.

This is shift-left in its purest form, exactly the pattern I described in my earlier article: pulling an entire post-silicon workflow ahead of the point of no return. But the AI angle deserves attention. An on-premises LLM examines detected kernel panics and judges whether each represents a genuine software bug or a non-critical bring-up artifact — while respecting data confidentiality. That is last year’s co-pilot philosophy deployed at scale: the LLM as triage filter, not sign-off authority. Anyone who has stared at a wall of defects found in emulation at 2am knows the economics — separating real bugs from bring-up noise is exactly the judgment-heavy, repetitive work an LLM should absorb. And on-premises deployment directly answers the data-ownership concern the 2025 panel raised. Validated on a flagship SoC project, per the authors, the framework found real software bugs before silicon.

Managing the handoff between simulation and FPGA prototyping

The second presentation I want to highlight addresses a friction point every prototyping team knows intimately. In Automated System for FPGA-Based SoC Prototyping — presented by Stefano Cumia of STMicroelectronics — part of the Beyond the Block: Verifying Complex Systems in Context session, the authors tackle the transition between simulation and the FPGA domain.

The two worlds are close but not identical: when a design moves to the prototype, certain blocks — memories, PLLs, and similar — must be swapped for FPGA-appropriate equivalents. With RTL evolving daily and IP integration ongoing, handling that translation manually invites exactly the human mistakes that cost bring-up weeks. Their answer is a Python-scripted system that automates the transition from simulation to prototyping — and, notably, back again.

That bidirectionality is the interesting part. It treats simulation and FPGA prototyping not as sequential phases with a painful wall between them, but as two views of one continuum that a design crosses repeatedly as it matures. The verification future debated last year assumes this fluidity; presentations like this one show users building it themselves, today, with scripting discipline rather than waiting for it to arrive.

Debugging across the wall: Firmware and hardware together

A third presentation, Staged Snapshots for Firmware-Hardware Collaborative Debug from IBM Research, sits in the same Beyond the Block session and pushes the continuum idea into debug itself. The problem it solves is familiar to anyone who has chased a bug that lives between firmware and hardware: microcode simulators are fast but opaque, full system simulations are observable but slow, and reconstructing state by hand to move between them can burn weeks.

Their approach captures a minimal architected state — registers and selected memory — from a firmware simulator and replays it into RTL system simulation, emulation, and back, using a schema-based, profile-driven flow. The result, per the authors, lets hardware and firmware teams debug the same failure in their native environments, cutting turnaround from weeks to hours. It is the same fluidity the prototyping talk builds, aimed at the debug problem rather than bring-up.

The special session: Tool builders and tool users on one stage

On Tuesday, the Engineering Track special session Advancements in Emulation and Prototyping for Semiconductor: Hardware Tools, Challenges, and FPGA Solutions puts the hardware itself under the microscope — with a speaker lineup spanning the supply chain.

Sridhar Seshadri of Synopsys open with the challenges facing next-generation emulation and prototyping: scalability, heterogeneous integration, debug, and emerging domains like AI and automotive, along with responses such as hybrid emulation and cloud-based prototyping. Bijoy Bose of Google covers the user requirements outlining the role of hardware-based tools in the semiconductor design methodology, with real-world case studies. And Rajat Aggarwal of AMD closes with the role of FPGAs themselves — the reconfigurable silicon on which much of this industry’s emulation and prototyping capacity is built, and why reconfigurability, parallelism, and scalability make it so.

The session framing says it plainly: verification stands at the forefront of next-generation semiconductor design challenges, and hardware-based tools have become resource-intensive necessities rather than luxuries. Tool builder, tool user, silicon supplier — the whole stack on one stage, in ninety minutes.

The continuum, flexing in software

That continuum framing is not static. Synopsys’ announcement of software-defined hardware-assisted verification earlier this year is a natural evolution of it. Besides the obvious performance, capacity and use case improvements, the concept of “EP-Ready” hardware that reconfigures between emulation and prototyping is addressing another aspect of the verification continuum: it flexes in software and hardware variations — the infrastructure answer to the handoff problem the user presentations build by hand.

And finally

The 2025 session closed with honest anxiety: as AI takes over the routine work, engineers become monitors and the bar for expertise rises. I find that more encouraging than threatening. The judgment calls are moving up the stack, but they still have to be made against something real, running fast, before the silicon commits. That is what emulation and prototyping provide. Whatever the future of verification turns out to be, it will run on this hardware. Come see it at DAC 2026 in Long Beach!