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

Moving chip checks earlier can expose problems sooner, but it won’t prevent failures that arise when teams work from different assumptions about the same system. That is the larger challenge in shift left: connecting design, software, verification, packaging and physical constraints early enough to validate how the whole device will behave.

In a discussion with Semiconductor Engineering, Frank Schirrmeister of Synopsys, Ronen Laviv of Hiveware, Jack Berg of Silvaco and Ashish Darbari of Axiomise described an industry still learning how to coordinate that work. Their shared concern is that a component can pass its own checks and still fail in the system around it. AI could help surface mismatches and direct work across tools, but it doesn’t remove the need to run the underlying verification engines.

Passing component checks can still leave system failures

Darbari said bug escapes can reflect a breakdown in communication among architects, designers, verification teams and software developers. Each group may have a reasonable understanding of what it is building, yet those understandings can diverge. In one example he recalled, a processor design had been exhaustively proved, while the software team tested the system using a different assumption about how transactions would be handled. A trace revealed lost transactions, and the design had to be patched late in the process.

The issue was not simply whether the hardware met its specification. The teams had not aligned on the behavior the software would expect from the system. Darbari’s point is that bringing software into the development cycle can help expose this kind of mismatch before the design is complete.

Schirrmeister broadened the problem beyond software. A chip’s behavior and feasibility depend on factors such as electromagnetic effects, heat, mechanical constraints and packaging. Application requirements matter, too: a design intended for a particular form factor or a vertically stacked configuration faces constraints that may shape what can be built. Some of those limits may change as packaging capabilities develop, but teams need to account for them in their models and plans.

That makes system validation a workflow problem. A model of functional behavior cannot provide a complete picture if power, thermal, packaging and software assumptions sit in separate tools or contexts. Teams need ways to connect those views and understand how a decision in one area affects the others.

Earlier insight needs a connected workflow

There are opportunities to shift specific checks earlier. Laviv pointed to packaging, power estimation, simulation and emulation as areas where earlier analysis could shorten iteration. Historical data from packaging and thermal work could also inform models that help teams spot recurring issues and consider better approaches on a new design.

Berg said the industry can already shift some verification work earlier, but moving the whole process left remains a work in progress. The distinction matters: having individual tools or checks available early does not mean teams have a joined workflow for applying them across the design.

Darbari described the gap as the absence of one shared framework that brings together functional safety, security, power, packaging and thermal considerations. Berg agreed that the industry has tools addressing different parts of the problem, while stressing that integration requires more than a single product. The work has to connect processes and information across the flow.

Laviv sees AI as a possible way to make more of that information accessible. If AI systems can draw on data from verification, emulation and physical design, they may help teams use findings across disciplines and tools. But access to more information is only useful if the underlying context is accurate and connected. Putting the data in reach does not, by itself, resolve conflicting assumptions.

AI can guide the work, but cannot skip it

Schirrmeister drew a line between making verification more efficient and eliminating the work that establishes confidence. Simulation, emulation, FPGA-based prototyping and formal methods each have roles. Teams can get smarter about which method to use for a given problem, and findings from a later stage can prompt a review of why an earlier stage did not catch the issue. But the engines still need to run, and some steps impose limits on how quickly a design can be evaluated.

Building an emulator takes time, as does preparing a design for it. AI can help select tests, prioritize bottlenecks or make better use of tool interfaces, but it can’t bypass the need to characterize behavior and execute the relevant analysis. The practical opportunity is to direct expensive work more effectively and find problems sooner.

Laviv suggested examining bottlenecks in formal verification, emulation and other parts of the flow to identify where AI could help work move faster. For very large designs, he argued, AI could interact with simulation or tool APIs and use information from formal analysis to make decisions before a lengthy test finishes. The specific benefit will depend on what insight each tool can expose and how reliably an AI system can act on it.

Scale raises the stakes. Laviv cited Intel’s Broadwell and its 200 billion transistors as an example of a design that puts heavy demands on verification tools. Designs of that size can be difficult to handle without emulation, so the goal is to prepare simulation and emulation earlier and make the overall process more efficient. That’s a coordination challenge as much as a compute challenge.

Validation starts with design intent

Darbari also described power, performance and area analysis that can reveal unused logic consuming power. In the example he discussed, synthesis did not remove the logic, and standard checks such as lint and coverage did not flag it. Finding such a problem late can mean revisiting decisions that could have been examined during architecture or design.

That observation shifts the timing and ownership of some checks. Redundant logic, registers and decisions about retiming may deserve attention while the design is being shaped, rather than being treated solely as later synthesis or layout concerns. A design can be implemented correctly and still include logic that serves no useful purpose. Checking whether a design is built as intended and whether it is built for the right reasons are related, but distinct, questions.

The next step is to connect the evidence behind those questions. Schirrmeister recalled a case in which software and hardware teams both believed their work was correct, but the system’s clock gating powered down a region in a state the software developer had not accounted for. The disagreement only made sense once the teams shared the system-level context: register programming, clock behavior and power state.

Agentic AI could help assemble that context across specialized tools, but only if its agents can exchange the information needed to reason about the whole device. Without that connection, bugs can still slip through the seams between teams and models. For chipmakers, the near-term test is whether AI can improve the timing and coordination of established checks while keeping their assumptions aligned with actual software, packaging and operating conditions.