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

AI agents and digital twins are giving chip teams more ways to test design choices before implementation hardens. They can help explore architecture, transistor structures, materials and power, performance and area (PPA) trade-offs earlier in the flow. But that extra reach comes with a familiar constraint: teams must establish that the models and AI-generated designs represent hardware that will work. Moving tasks earlier doesn’t remove verification work; it changes where the questions arise and how quickly new bottlenecks appear.

That tension emerged in a discussion among Frank Schirrmeister of Synopsys, Ronen Laviv of Hiveware, Jack Berg of Silvaco, and Ashish Darbari of Axiomise. Their shared point: AI expands the set of decisions designers can examine, but it doesn’t make those decisions dependable by itself.

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

Earlier exploration depends on models people can trust

Digital twins and AI agents are pushing analysis closer to the start of chip development. The technical ingredients include more computing capacity and models that capture interactions beyond digital logic. Berg pointed to multi-physics modeling: as designs use different materials and transistor structures, teams need results from materials science and physics solvers that can be turned into usable models. He said that approach is reaching areas such as complementary field-effect transistors (CFETs), too.

Those detailed simulations can be costly to run across every design option. A surrogate model approximates the behavior of a more complex solver, making it practical to evaluate choices more quickly. A digital twin can represent a system or design in a virtual environment for analysis. Together, these methods could let teams explore more alternatives before committing to a hardware implementation. Their usefulness, however, rests on whether the simplified model predicts the behavior of the real design closely enough.

Schirrmeister described trust as a central obstacle. An AI agent can propose an option or run an analysis, but it can’t establish on its own that a surrogate model accurately represents the underlying physics or hardware. That responsibility still belongs to engineers who understand the model and can judge where it applies. If teams rely on an inaccurate prediction, they could make decisions that lead to another design iteration later.

The same concern applies when an agent rewrites existing hardware for better PPA. Darbari said some customers are asking agents to optimize older designs, then asking whether the new version can be proven equivalent to the original. Formal verification can help check whether two designs have the same behavior under defined conditions. For Darbari, early use of formal methods is one way teams are trying to close the trust gap, though he also identified tool integration as a practical obstacle.

More options can mean more review work

AI-assisted design also changes the amount of material engineers must inspect. An agent may generate alternatives, produce analysis, or help investigate a failure. That can reduce time spent on some tasks, but it may create a queue of results that still require human judgment. Darbari warned that manual review could slow early adoption, even when an agent’s output is useful. Teams need to understand which findings matter and where engineering attention will have the greatest effect.

That makes debug time part of the shift-left discussion. When an architectural analysis fails, an agent may help examine the available data, but the team still needs to determine the cause and whether the proposed fix is sound. Laviv framed the broader challenge as a recurring search for bottlenecks: pulling work earlier can expose a new constraint, or make an existing one more visible. Moving one task forward doesn’t automatically speed the rest of the flow.

It also remains an open question whether earlier agent use will consistently produce better designs with fewer bugs escaping into later stages. Darbari said shift left alone won’t answer that. The outcome depends on the quality of the models, the strength of verification, the usefulness of the agents’ output and the time engineers spend reviewing it.

Shift left may become a cycle of refinement

The phrase “shift left” often suggests a linear process: decide what the product will be, specify it early, then carry that specification through implementation. Schirrmeister questioned whether that assumption still fits. Teams may know the product’s broad direction without knowing every implementation choice months in advance. New information during development can change which architecture or processor makes sense.

He described a more iterative approach in which engineers use models to explore options, revise assumptions and adjust the specification as they learn. For example, a team might compare an Arm-based design with a RISC-V design for a particular function, then update its plan after examining the trade-offs. That approach treats early analysis as a way to inform later decisions, rather than a promise that every detail can be settled at the outset.

Schirrmeister called this a more agile form of shift left: choices made earlier create room to adjust implementation details as evidence arrives. A product’s eventual workload may also differ from what a team expects during initial planning. More frequent feedback could help teams refine a design before that uncertainty turns into a late change, though the approach depends on trustworthy models and a process for reconciling competing results.

Darbari agreed that many implementation details emerge over time, especially around power and functionality, but cautioned against treating the entire design as undefined. A team working on a CPU, GPU or machine learning chip usually has some basis in an earlier design or a known architectural direction. What remains uncertain may be how to meet new requirements for training, inference and power. Agents could help compare the available choices, but teams still need to decide whether their results can be reconciled and trusted.

Verification flows have to move with the design

The implications reach beyond a single model or tool. Digital design already uses multiple stages and methods, including virtual platforms, formal analysis, software simulation, emulation and FPGA prototypes. Laviv argued that improvements to bottlenecks in any of these areas could let the next stage begin sooner. For example, a design that becomes stable earlier through formal analysis may be ready for simulation, emulation or FPGA work sooner as well.

That coordination matters more as systems combine multiple dies and must be managed through their lifecycles. Design decisions affect software, workloads and implementation constraints at the same time. A team may need to evaluate whether an architecture can serve several use cases, or whether a change in one part of the system creates problems elsewhere. Darbari described customers revisiting architecture from the ground up to assess how a chip might serve different uses, including CPU, GPU and machine learning workloads. Software behavior, training, inference and power all feed into those decisions.

There is also a limit to what AI can resolve when design constraints conflict. Berg described an inverse-design flow that could use multi-physics solvers and surrogate models to produce a transistor or chip meeting specified conditions. If the conditions are mutually incompatible, the flow may return no feasible design. Engineers then have to revisit the assumptions and decide which constraints can change.

For chip teams, the useful measure of progress will be whether earlier exploration leads to decisions they can validate, and whether the surrounding flow can absorb those decisions without creating a new review or integration bottleneck. Agents can expand the number of options worth considering. The next step is making sure teams can test those options, understand the results and revise their plans while change is still manageable.