AI Agents Push Chip Design Earlier, but Verification Still Sets the Pace

AI agents and digital twins are making it possible to examine more chip design choices before implementation is far along. That could help teams compare architectures, materials and transistor structures earlier, when changes are less costly. But the move upstream depends on a difficult question: can engineers trust the models and AI-generated designs enough to act on their results?

That tension framed 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 change in what “shift left” means. The goal is no longer simply to finish more tasks at the start of a fixed sequence. Teams are beginning to use earlier models to explore alternatives, then revise plans as they learn more.

L-R: Silvaco’s Berg; Synopsys’ Schirrmeister; Axiomise’s Darbari; Hiveware’s Laviv.

More design choices become testable upstream

The new reach comes partly from more computing capacity and the use of AI agents, Schirrmeister said. Digital twins and surrogate models can represent aspects of a design or process so teams can explore options without running every detailed analysis from scratch. Berg pointed to multi-physics models, which connect behavior across areas such as materials and device structures. As designers work with new materials and transistor approaches, he said, they need input from materials science and physics solvers to build models that are useful for design. The approach is reaching areas such as complementary field-effect transistors, or CFETs.

These models can support a broader search space. A team might assess architectural alternatives, ask an agent to explore implementation options, or examine whether a proposed design meets a collection of constraints. In principle, that puts questions about performance, power and functionality closer to the point where architectural choices are made.

There’s a catch: an agent can produce an answer without establishing that its model reflects the hardware accurately. Schirrmeister said engineers have traditionally relied on a human owner to confirm that a virtual prototype is a sound representation of the system. AI does not remove that responsibility. If a model makes predictions that diverge from the eventual implementation, decisions made on its basis can lead to expensive redesign or another silicon spin.

Darbari sees a similar issue in AI-assisted design. Some teams are asking agents to rewrite existing designs to improve power, performance and area, or PPA. That raises a verification question: how can a team show that the changed design still behaves like the original where it must? Formal verification can help establish equivalence through mathematical proofs. Darbari said early use of formal methods is one way organizations are addressing uncertainty about AI-generated results.

Verification capacity can become the next bottleneck

Moving analysis earlier doesn’t automatically shorten the full schedule. It can shift pressure onto review and verification, while creating new flows that need their own integration work. Laviv described shift left as identifying constraints in the design and verification process, then bringing as much work forward as teams can. Agents may help with that effort, but each improvement can expose another bottleneck.

Formal verification, simulation, virtual prototyping, emulation and FPGA testing all have a role in the digital design flow, Laviv said. When a design is stable enough to enter one stage sooner, later work can begin earlier too. For example, earlier formal results may let simulation, emulation or FPGA work start sooner. But that depends on the flow connecting those methods effectively and on teams resolving capacity limits at each stage.

Debug adds another complication. Agents can process large volumes of information from an analysis and help investigate failures, but engineers still have to decide whether the findings are useful and correct. If every result requires extensive manual review, that review can slow adoption. Darbari said it remains an open question whether using agents earlier will consistently produce better designs with fewer defects escaping into later stages. He cautioned that moving work earlier, by itself, won’t solve the problem.

The productivity gain, then, depends on more than the agent’s speed. Teams need ways to assess model quality, verify proposed changes and understand what the analysis has found. Tool integration matters too: Darbari said the practical obstacle is often whether tools can connect into the wider system, rather than a lack of verification knowledge.

Specifications may need to evolve with the design

Traditional shift left suggests that teams can define requirements early and carry them through a largely sequential process. Schirrmeister questioned whether that assumption fits products whose workloads and implementation needs can change during development. A team may begin with a broad product direction, use new information to refine an architecture, then adjust implementation choices as the design takes shape.

That approach is less like a one-time specification handoff and more like iterative refinement. A team might compare processor options, for example, and revise its specification after learning which choice best fits the use case. Schirrmeister described this as a more circular process: teams can draw on new data throughout development instead of waiting until deployment to discover that an early decision missed the mark.

Darbari agreed that many implementation details aren’t known at the start, particularly choices involving power, functionality, training and inference. Still, he argued that design work usually begins with some useful reference point. A team developing a CPU, GPU or machine learning chip can draw on previous designs and established architectural goals. Agents may help explore the choices that remain, but teams still need to reconcile the results and establish that they’re trustworthy.

Berg framed the role of an agent as closer to that of a junior engineer whose work needs an experienced reviewer. Agents can help generate and examine designs, but they don’t take responsibility for engineering decisions. He also raised the possibility of using inverse design: give a model a set of desired properties and ask it to propose a transistor, chip or RTL implementation. If the constraints conflict, the result may be that no valid option exists. Teams then need to revisit what they asked for and decide which requirements can change.

Workloads complicate architecture decisions

The uncertainty reaches beyond hardware. Darbari said chip teams must consider the software that will run on a product and how its use may change. Training and inference can affect requirements from the architecture stage onward, alongside power and functional needs. Teams developing platforms that might support different kinds of workloads have to check whether their architecture covers those intended uses. That validation becomes harder when the software environment differs from assumptions based on older products.

For engineers, the practical promise is more opportunities to test assumptions before they harden into expensive implementation decisions. Digital twins, surrogate models and agents could help teams compare options earlier and bring verification stages forward. The tradeoff is a greater need to validate the models themselves, prove important design changes and review agent output. The useful measure of progress won’t be how early a task appears in the flow; it will be whether earlier results are predictive enough to support decisions, and whether teams can keep revising the design as real evidence arrives.

The central question for the next phase is whether tool makers and chip teams can make that loop dependable. Earlier exploration has value when it leads to decisions engineers can defend—and when verification capacity keeps pace with the number of alternatives agents can generate.

The post Rethinking Shift Left In Chip Design appeared first on Semiconductor Engineering.