Chip Design’s Shift Left Now Depends on System-Level Validation

Moving verification earlier in chip design can catch defects sooner, but it won’t close the gaps between teams working from different assumptions. The harder problem is system-level validation: bringing software behavior, hardware design, packaging, power, thermal limits and other constraints into a shared view before they collide late in development.

That was the central tension in a discussion among Frank Schirrmeister of Synopsys, Ronen Laviv of Hiveware, Jack Berg of Silvaco and Ashish Darbari of Axiomise. Their accounts point to a practical limit of “shift left”: moving individual checks earlier helps, but it doesn’t automatically make the design assumptions behind those checks consistent.

From left: Jack Berg of Silvaco, Frank Schirrmeister of Synopsys, Ashish Darbari of Axiomise and Ronen Laviv of Hiveware.

Early checks need a shared system context

A component can pass its assigned verification and still fail when the complete system behaves differently from what its teams expected. Darbari described a chip project in which the architect, designer and software team had different assumptions about how a processor should handle multiple outstanding transactions. The design had been exhaustively proved, while software teams ran their own work in parallel. Later, software testing exposed lost transactions, and the design needed a patch.

The problem, in his telling, wasn’t simply a missed test. The teams had built and checked against conflicting interpretations of the intended behavior. Formal verification could establish that a model was internally correct, but it could not resolve a mismatch between that model and the way software would drive the system.

Schirrmeister offered a related example involving an emulator and software developers who believed their code and register programming were correct. The behavior made sense when viewed locally, but not in the system’s global state: a clock-gated, powered-down area had made the relevant register unavailable. Hardware and software teams each had a partial explanation. The missing piece was shared context about what the system was doing at that moment.

These examples make the case for bringing software into the development cycle, as well as connecting the assumptions used across hardware and physical design. Schirrmeister pointed to electromagnetic, thermal and mechanical factors, alongside packaging constraints. A design’s intended form may not be possible with current packaging options, even if a different arrangement could become feasible later. Those dependencies belong in the model used to assess the design.

Shift left means more than moving a test earlier

Earlier estimates and simulations could help teams identify trouble before a design reaches later stages. Laviv raised the possibility of shortening packaging, power-estimation, simulation and emulation cycles, using AI to move some work earlier. Darbari suggested that historical packaging and thermal data could inform models that help teams judge whether a new design choice is likely to work better than a previous one.

But the panelists didn’t describe a single workflow that already connects those disciplines. Berg said the industry has made progress shifting parts of verification earlier, while the broader task remains unfinished. Packaging, thermal, functional safety, security and power each have their own methods and data. Connecting them into a useful workflow is a larger task than adding one more tool.

That distinction matters. A collection of accurate models doesn’t by itself create a complete system view. If physical behavior sits in one context, software assumptions in another and functional behavior in a third, teams may still miss interactions that only appear when those pieces meet.

AI can guide the tools, but it can’t skip their work

The panel’s discussion of agentic AI centered on coordination and tool use. Laviv proposed that AI could help identify bottlenecks in formal verification, simulation and emulation, then direct work toward the parts of the process that need attention. If AI systems can interact with tool APIs and gain useful insight into their state, they may help teams assess results sooner and clean up inefficient work.

Schirrmeister drew a boundary around that possibility: the underlying engineering engines remain necessary. Characterization, simulation and emulation still have to run; an emulator still has to be built, and a design still has to be loaded into it. AI may help determine which tasks belong in simulation, formal methods, emulation or FPGA-based prototyping, and it may improve how those tools are used. It can’t remove the execution time or physical work inherent in those methods.

That’s a useful distinction for teams weighing AI against existing verification infrastructure. The likely value lies in better coordination, faster triage and more informed choices about where to spend compute and engineering time. The panel offered no evidence that AI eliminates the need for established checks, and Schirrmeister noted that some customers review why a problem surfaced in simulation if they believe formal verification should have caught it earlier.

Laviv also suggested that a shared database spanning verification, emulation and physical design could give AI more material to work with, potentially across company boundaries. That idea raises a practical question the discussion didn’t resolve: how teams would make different models and data accessible in a form agents can interpret consistently. Shared access alone would not guarantee shared definitions or agreement about what a result means.

Design quality starts before synthesis

Darbari described another reason to move system questions earlier: unwanted logic can survive checks that focus on different problems. In one analysis of power, performance and area, his team found unused chip area that could still consume power. Synthesis wasn’t removing it, lint wasn’t flagging it and coverage wasn’t exposing it.

His point is that some issues should be treated as design or architecture questions, rather than left for synthesis or layout to reveal. If a register is redundant or should be retimed, teams need to understand whether it belongs in the design before late-stage optimization. Whether a block is built correctly and whether it is needed for the intended system behavior are separate questions; validation needs to address both.

Laviv pointed to the scale of chips such as Intel’s Broadwell, which he described as having 200 billion transistors. At that scale, he said, tools face challenges running designs without emulation. The discussion suggests a role for AI interfaces into simulation and formal tools: helping teams inspect internal signals, judge what to run next and shorten the wait for useful feedback. It doesn’t establish how much time those approaches save or how well they scale across real projects.

The open problem is coordination

Shift left is already changing when some verification work happens. The next step is making the assumptions behind that work visible across disciplines. That means accounting for software behavior, system state, physical constraints and design intent in connected workflows, while retaining the simulation, emulation and formal methods that test specific properties.

AI could help assemble that context, surface bottlenecks and route questions to the right tools. Yet the examples in the discussion show why agents need more than access to data: they need the relationships between models and the system conditions that make a result meaningful. For chip teams, the measure of progress will be whether those connections prevent bugs from slipping through the seams.

To read the first part of the discussion, visit the earlier conversation.