重新思考芯片设计中的 Shift Left：AI 智能体与数字孪生如何改变流程

Key Takeaways:

• AI agents and digital twins are making it possible to explore more design options earlier, including choices involving materials, transistor structures, and chip architectures.
• Moving work earlier doesn’t eliminate verification bottlenecks. Engineers still need to establish whether AI-generated designs and surrogate models accurately reflect the intended hardware.
• Shift left is becoming less linear. Instead of locking down specifications early, design teams may be able to refine architectures and implementation choices as new information becomes available.

Experts at the Table: Semiconductor Engineering sat down to discuss the good and bad of shifting left amid ongoing changes in how chips are designed, used, and updated throughout the flow, with Frank Schirrmeister, executive director of strategy programs and system solutions at Synopsys; Ronen Laviv, vice president of business development and strategic partnerships at Hiveware; Jack Berg, vice president of business development at Silvaco; Ashish Darbari, founder and CEO of Axiomise. What follows are excerpts of that conversation.

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

SE: We’ve been talking about shifting left in the design-through-manufacturing flow for more than a decade, but more and more capabilities are being added to improve reliability and  yield, and produce silicon faster. What changes are you seeing?

Schirrmeister: We’re now adding digital twins, which are shifting very left.

Berg: That’s correct. And the issue now is working with multi-physics models. Using that data to assemble surrogate models is important. As we go further into different technologies with different materials, you have to go back to the materials science solvers and physics solvers to get models that designers can use. This is happening in areas that are not typically digital design, but as we get down to the CFET level, it’s starting to be used there, as well.

Schirrmeister: There are three changes. Number one, now we have the technical ability with compute, with agents, to shift much further left than we ever hoped we would get to in our lifetimes. The problem there is whether shift left is trustworthy. Is the surrogate model a reliable representation of what’s happening? You can’t have the agent decide that. In the past, for virtual prototyping, you would get a human being who is responsible for ensuring that the model represents what’s happening, and that it’s accurate. That’s number one. So the trust is changing. Number two, you need to trust the shift-left model to be predictive of what you’re doing. Otherwise, you’ll regret you’re shifting left because you’ll need another spin. In a Qualcomm keynote, the speaker talked about the new reasoning gap. He said we used to have a productivity gap, but now we have a reasoning gap. They want engineers to reason about the product and make that product better. But the tools can’t deal with reasoning yet. The third one is the rapid pace of shift-left options. If I get to the point where I can trust the models, then I have new things I can do. At the architectural level, I can decide something and kick off ‘n’ options to try it out if the models are predictive enough.

Darbari: The shift-left discourse started at least 15 years ago. What has changed is AI and the agentic use model. What has not happened yet is the trust element in today’s AI agents. There are all these excellent use models for the agents, which we use and our customers use, to go through the specifications. A lot of discussion has now moved into spec-to-silicon, because people believe you can extract requirements from specification documents — if you have them. But most of the time you don’t have them, and that is one of the problems. Another big change I’m seeing in the work we do with formal verification is that functional verification is now seen as a problem, at the same level as security, functional safety, and power, with all of the hardware feeding into the AI ecosystem, which is the largest investment pool. A lot of companies are investing in PPA analysis on the first day. For example, I know of customers that are taking their designs, even the older generation, and saying, ‘Let an AI agent rewrite it for optimized PPA.’ But how do I know it is correct? Can I prove it to be equivalent to something else? So the big 10 companies in the semiconductor space, which have big budgets and big teams of people, are adopting agentic AI flows, and they’re heavily leaning on whether they can trust it or not trust it. That trust gap is often being solved through early adoption of formal through proofs. The know-how is not necessarily the biggest blocker. It’s mostly whether tools can integrate more seamlessly into the system.

But if you look at what is enabling more shift left, it’s the time spent on debug. When you’re bringing up an architectural analysis and you have a failure, you can feed it to an agent. There’s a lot of data coming out of the agents, and we need to do more work on insights. Are you spending your time wisely? Even if it is correct or incorrect, if a manual review has to happen, that could be a massive blocker in the early phases of adoption of shift left. With agents being adopted earlier, will this lead to better designs with fewer bug escapes? That remains to be seen, and I don’t believe that shift left alone will be able to fix it.

Laviv: Shift left is identifying the bottlenecks in our industry and looking at what you can do in order to pull in work and schedule as much as you can earlier in the design and verification cycle. Nowadays, the agents are leaping forward to help, but everything that happens gets us into bottlenecks — new bottlenecks or old bottlenecks — that we have to solve.

SE: We have so much that has to be looked at and verified concurrently that it becomes a problem to shift that much stuff left, and it gets more complicated with multi-die assemblies and lifecycle management. How do all the pieces go together and stay together?

Schirrmeister: Is shift left even the right thing? Shift left assumes that I have a solid knowledge of what I’m actually going to do, and it assumes I can specify what I want six or nine months or a year from now. Maybe we’re thinking about this wrong. Perhaps what we need is a general direction, and then the ability to make adjustments based on the information we gain as we go toward implementation choices. Shift left implies that you can get to zero in some magic future world by having something spec’d, and you get all the way there. What I hear people doing is different. They say, ‘Okay, I’m building something, and with agentic AI I can now build this model that potentially represents most of it. So now I make the decision, ‘This one is fairly straightforward and it doesn’t need that much effort on an Arm processor, or I can make a RISC-V processor for it.’ Now I reset my spec, which is kind of messed up because I did not have the correct hardware spec, so now I’m making adjustments. The cool part is we are approaching a time when we can shift left to this new refinement. It’s almost like an agile shift left. In an agile way, you make adjustments to your implementation for micro choices that happen later based on what you’re doing now.

SE: That addresses a big problem with these designs, because you don’t know what the workload will be by the time this chip is deployed in the market. This is a more generic approach that focuses on adaptability, right?

Schirrmeister: Exactly, and we didn’t dare do this in the past because this was all sequential. Now it becomes more circular. So there was a product manager who knew the market and said, ‘I’m building this, and then 18 months later you found out it didn’t work.’ Right now you have new data all the time, so there can be this agility in refining what you’re doing.

Darbari: I agree that there are lots of choices in agility and lots of changes, and not everything is known up front, which is the reality in building anything. However, I do not see that things are so fuzzy. If you’re building a new machine learning chip, or a GPU or a CPU, you have some idea of what the derivative design was before. What is the general architecture you’re going to play with? What you don’t know is what the implementation choices are going to be for power, for functionality, and with AI bringing lots of challenges on training or inference. Those are quite novel. So you need to make multiple choices at every step along the way, with or without agents. But agents can help you do that more efficiently. What I don’t know is whether the outcomes of these agile agents can be reconciled very quickly and trusted.

Schirrmeister: You don’t let AI actually make the decision for you, and you don’t trust the AI. You then need to go down into a verified model.

Berg: That’s a really important point. The AI agents don’t replace humans. They are effectively junior engineers, and they need to have their work reviewed by somebody who knows it. The notion that it’s agile, and is growing agile, is very real. There’s this notion that a flow does an inverse design. But what happens if that inverse design could be based on multi-physics solvers. You put together a surrogate model, digital twins, and then you say, ‘Okay, give me a transistor or give me a chip — or even so far as a chip through RTL at this point — that works with these constraints and these things that are going on. And all of a sudden you have an empty set. It’s over-constrained. Now what do you do? This is why the notion that you have to be agile is very valid.

Laviv: If we take the example of the digital flow, you have virtual platforms today, formal, software simulation, emulation, FPGA, and you have engineers and AI engines. You will need to make adjustments. And if you’re designing a CPU, or something that’s tangible, and you can do it better with formal and bring it to the table sooner with a more stable design, then emulation and FPGA can run sooner in the pipeline of doing the verification stuff, and the same thing with simulation. If you have done something to solve the bottlenecks in formal, in simulation, virtual prototyping, or even the flow itself, this would help shift everything left and allow you to make better decisions earlier in the game. That way if you need to change stuff, you can change it.

Darbari: The validation problem is significant. I’m seeing real evidence with some customers, who literally are going back to the drawing board to build a ground-up architecture that can address different phases of their chips being used. So they could build a CPU, a GPU, a machine learning chip, and they really need to scope out whether what they intend to build would cover all kinds of use models. That’s not easy, especially when you bring software into the loop, and the software isn’t what used to run 20 years ago. There is training, inference, power coming into the chain all the way back to the architecture level, and then you’ve got to make these choices.