Is it better to try to advance all tasks in the design process as much as possible, or should design be more flexible and iterative?
Key points:
- AI Agents and digital twins are enabling people to explore more design options earlier on, including choices in materials, transistor structures, and chip architectures.
- Moving the work forward earlier will not eliminate the verification bottleneck. Engineers still need to confirm whether the design and alternative models generated by AI accurately reflect the target hardware.
- "Left-shifting" is becoming less linear. Design teams may not need to lock in specifications too early, but can continuously refine the architecture and implementation choices as new information becomes available.
The "left shift" in the design-to-manufacturing process has been discussed for over a decade, but it is gaining renewed attention as new capabilities to improve reliability, yield, and accelerate wafer delivery are added. Sem Token Issuance nductor Engineering To discuss this change and the ongoing evolution of how chips are designed, used, and updated throughout the entire process, we interviewed: Synopsys Executive Director of Strategic Projects and Systems Solutions Frank Schirrmeister, Hiveware Vice President of Business Development and Strategic Partnerships Ronen Laviv, Silvaco Vice President of Business Development Jack Berg, and Axiomise Founder and CEO Ashish Darbari. The following is an excerpt from the interview.
SE: We have been discussing the "left-shift" in the design-to-manufacturing process for over a decade, but increasingly more capabilities are being incorporated to improve reliability and yield, as well as to produce silicon wafers more quickly. What changes have you observed?
Schirrmeister: We have now incorporated digital twins, which has brought the 'shift to the left' feature much more to the forefront.
Berg: That's right. The current issue is how to handle multi-physical field models. It's very important to use this data to build alternative models. As we move into more technical fields that employ different materials, we must return to material science solvers and physical solvers to obtain models that designers can use. This situation is occurring in areas that are not typically part of digital design, but as we advance to the CFET level, it also begins to be used there as well.
Schirrmeister: There are three changes. First, with the help of computing power and proxies today, we have the technical capability to advance work further than we originally imagined in our lifetime. The question is, is this kind of “forward shift” credible? Can substitute models truly reflect what actually happens? We can’t let the proxies decide that for us. In the past, when creating virtual prototypes, there would be someone responsible for ensuring that the model represented the real situation and was accurate. That’s the first point; therefore, the meaning of trust is changing. Second, you need to believe that the forward-shifted models can make predictions about what you are doing. Otherwise, you might regret advancing your work if you have to go through the process again. In a keynote speech at Qualcomm, the speaker mentioned a new “inference gap.” He said that in the past, we faced a productivity gap, but now we face an inference gap. They hope that engineers can use reasoning to improve products, but current tools are not yet capable of handling this reasoning. Third, there is a rapid increase in the number of options for forward shifting. If I have reached a point where I can trust the models, then I can try new things. At the architectural level, I can make a decision and then launch several options for testing, as long as the models are predictive enough.
Darbari: The discussion about left-shifting began at least 15 years ago. What has truly changed are AI and the proxy-based usage models. What hasn't happened yet is the issue of trust in today's AI proxies. There are now many excellent proxy usage scenarios, and both we and our clients use them to refine specifications. Nowadays, many discussions have shifted towards "from specifications to silicon chips," because people believe that requirements can be extracted from the specification documents—assuming you have those documents. But most of the time, you don't, and that's one of the problems. Another major change I've seen in formal verification work is that functional verification is now considered an issue on par with security, functional safety, and power consumption. All hardware is moving towards the AI ecosystem, which is the largest investment pool. Many companies start doing PPA analysis from day one. For example, I know some clients bring in their own designs, even older generation ones, and then say, "Let AI proxies rewrite them and optimize PPA." But how do I know if that's correct? Can I prove that it's equivalent to something else? As a result, large companies in the semiconductor industry—those with ample budgets and large teams—are adopting proxy-based AI processes and rely heavily on whether they are trustworthy or not. This gap in trust is often addressed by adopting formal proofs as early as possible. The real barrier may not necessarily be the knowledge itself, but rather whether the tools can be more seamlessly integrated into the system.
But if we look at what is driving the greater shift to the left, the answer is the time spent on debugging. When you are doing architectural analysis and encounters failures, you can hand it over to an agent. The agent will produce a large amount of data, and we need to do more work in terms of insight analysis. Are you spending your time in the most valuable areas? Even if the results are correct or incorrect, if manual review is still required in the early adoption phase, that can also become a significant obstacle. With agents being adopted earlier, will this lead to better design and a reduction in defects being missed? That remains to be seen, and I don't think that just shifting to the left will solve this problem on its own.
Laviv: Shifting left means identifying the bottlenecks in our industry and thinking about how to move as much work and scheduling as possible to earlier stages of the design and validation cycles. Nowadays, agents are stepping forward to offer help, but everything that happens will lead us to new bottlenecks, or old ones that we must still resolve.
SE: We have too much content that needs to be reviewed and verified simultaneously, which makes it difficult to move so much of it forward, and it becomes even more complicated in terms of multi-chip packaging and lifecycle management. How do all these parts need to work together and remain consistent?
Schirrmeister: Is left-shifting really the correct direction? Left-shifting assumes that I have a full understanding of what I truly want to accomplish, and it assumes that I can accurately define what I desire six months, nine months, or even a year from now. Perhaps our understanding of this issue is incorrect. Maybe what we need is a general direction, and then as we move towards making choices for implementation, we can make adjustments based on the information we obtain along the way. Left-shifting implies that you could, in some magical future world, standardize everything from the start and achieve zero deviation. But what I hear people actually doing is not that. They say, "Okay, I’m working on something, and with the help of AI, I can build a model that may represent most of the content. So I make a decision: this approach is quite straightforward, it doesn’t require much work on the Arm processor, or perhaps I can create a RISC-V processor for it." Then I reset the specifications, which is a bit messy because I didn’t have the correct hardware specifications in the first place, so now I’m making adjustments. What’s even cooler is that we’re approaching an era where left-shifting can become this new kind of refinement process. It’s almost like an agile form of left-shifting; in an agile manner, you make adjustments to small choices that will occur later on based on what you’re doing at the moment.
SE: This solves a major issue in these designs, as you never know what the workload will be like when the chip is released to the market. It's a more general approach that emphasizes adaptability, right?
Schirrmeister: That's right, and in the past we didn't dare to do that because everything was done in a sequential manner. Now it's more like a loop. Back then, it was the product manager who understood the market and would say, "I want to do this," and only 18 months later would you realize that it wasn't working. Now, you continuously receive new data, so you can maintain this agility as you refine your work.
Darbari: I agree that agility brings many choices and also a lot of changes. It's not possible to know everything from the start, and that's the reality of building anything. However, I don't think things are that vague. If you're working on a new machine learning chip, or GPU, CPU, you will generally have some concepts about the previous derivative designs. What is the overall architecture you're aiming to create? What you don't know are the power consumption, functions, and the implementation choices for training or inference that AI will bring. These are all quite new. Therefore, you need to make multiple choices at every step, whether with agents or not. It's just that agents can help you complete these tasks more efficiently. What I'm not sure about is whether the results of these agile agents can be coordinated quickly and trusted.
Schirrmeister: You wouldn't really let AI make decisions for you, nor would you trust AI. And then you still need to enter a verified model.
Berg: This is a very important point. AI Agents will not replace humans. In fact, they are equivalent to junior engineers and their work needs to be reviewed by professionals in the field. The concept of becoming more and more agile is indeed real. There is also a view that processes can be designed in reverse. But what if this reverse design can be based on multi-physical field solvers? You combine alternative models and digital twins, and then say, "Okay, give me a transistor, or give me a chip—even at this stage, give me a chip that has passed RTL; it should be able to function under these constraints and given what is currently happening." But suddenly you find that there is no feasible solution due to too many constraints. What do you do then? This is why it makes so much sense to "must remain agile."
Laviv: Taking digital processes as an example, there are now virtual platforms, formalization methods, software simulators, simulation accelerators, FPGA, as well as engineers and AI engines. You need to make adjustments accordingly. If you are designing CPU, or some tangible product, and if you can use formalization methods to create a better and more stable design earlier, then simulation accelerators and FPGA can be involved in the verification process sooner, as well. If you have already overcome bottlenecks in formalization, simulation, virtual prototyping, or even in the process itself, that will help to move things forward faster and allow you to make better decisions earlier. In this way, if changes are needed, you can make them promptly.
Darbari: The verification issues are very serious. I've seen real evidence in some clients who are actually starting from scratch to build an architecture that can meet the needs of chips at different stages of use. Therefore, they might undertake CPU, GPU, and develop machine learning chips. It's really necessary to clarify whether what they plan to build can cover all usage scenarios. This is not easy, especially when you incorporate software into the equation, and that software is no longer the same as it was 20 years ago. Training, inference, power consumption—all these factors need to be considered at the architectural level, and then you still have to make those choices.
Ed Sperling
