Shift Left Is Becoming A System-Level Problem
Key Takeaways:
- Shift left is pushing beyond verification to system-level validation.
- Fragmented workflows with disconnected tools and models are allowing bugs to escape even though individual components have been verified.
- AgenticAI may improve coordination across disciplines, identify bottlenecks, and optimizetool usage, but it cannot replace fundamental processes such as simulation and emulation.
Semiconductor Engineering sat down to discuss why shift left is pushing beyond verification to system-level validation, and where AI can and cannot help, 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. To view part one of this discussion, click here.
L-R: Silvaco’s Berg; Synopsys’ Schirrmeister; Axiomise’s Darbari; Hiveware’s Laviv.
SE: The focus of shift left in design has largely been about verification. But increasingly it’s also about validation, right?
Darbari: Yes, and it’s influencing huge decisions that could make small companies go bankrupt if they get it wrong. We’ve seen meetings with architects, designers, UVM leads, emulation leads, FPGA and software leads, and VPs, where they’re all looking at bug escapes and asking, ‘Why did this happen?’ The architect is saying, ‘It’s supposed to be this.’ The designer is saying, ‘We didn’t know that.’ The software team says, ‘It’s supposed to be this.’ And we’re sitting there as formal verification people thinking about communication and the model not being accurate, and I don’t know how well we’ll be able to solve this unless we bring the software into the development cycle.
Schirrmeister: It’s not only software. It’s all the other aspects, like multi-physics. EM, thermal, and mechanical, which all have to be integrated. To look at this differently, there are hurdles that I cannot fix in this project. But perhaps I can fix it in the next one. It’s a labyrinth. We have models that are digital twins that are irrefutable, because we’ve measured them against the real thing. We can’t overcome those. We are dependent on the application. It may be more vertical, it may be more horizontally stacked to fit into a certain form factor, like a phone or a data center. But it’s like a video game where you have these things popping up. I want to package it this way, but the packaging guy says we can’t do that, at least not today. Maybe a year from now. All of this needs to be taken into consideration as part of your model.
Dabari: Absolutely correct.
Laviv: Shrinking times for packaging or power estimation or simulation, or even emulation — isn’t that something we could look at? We’re shifting left using AI in order to do stuff earlier.
Berg: Verification traditionally has been the longest and most expensive part of doing a design, and it would be nice to say we can take everything and shift it all left. There are chunks that are being shifted left and verified, and that’s good. But how to shift everything left is something we’re still learning.
Darbari: If we pick up historical data from packaging and thermal, why can’t we start building models to say, ‘This happened last time. This time it could be done better.’
Berg: You can do that based on inference.
Darbari: But we don’t have a tool that ties everything together in one frame. ‘This is the model of functional safety, security, power, packaging, thermals. Go build it.’
Berg: We have different aspects of that, and we, as an industry, are working slowly but surely to integrate all of those. But we don’t have a single workflow that does that. And it really is a workflow, not just a single tool.
Laviv: Nowadays, with AI knowing everything with its skills and touching everything, there is kind of a common database for verification and emulation and all the physical stuff. It might benefit customers if they have access to everything is there to be used, potentially even cross-companies.
Schirrmeister: There are certain things you can shift left, and others you have to wait for. Certain things are irrefutable. Yes, you can make them faster, but you can’t bypass them. You can be smarter about how you use them. You can figure out which things should be done in emulation, which should be done in simulation, and which should be done with FPGA-based prototyping. We have customers telling us that if they find something in simulation that should have been found in formal, or simulation beforehand, they’ll review why that happened.
Laviv: Why not look at bottlenecks in formal, in verification, in emulation, and see if you can handle those bottlenecks in a way that would open the flow for faster AI?
Schirrmeister: There are two views here on this whole AI stack. I’m a firm believer that the underlying portions of the stack will still be required. They will be used in different ways by the AI objects, but you don’t take away the characterization, the simulation, the emulation. You get smarter about how to use them. But at the end of the day, you need to build the emulator. That takes some time. You need to get the design into it. And there is a certain number of things which you cannot overcome. You can make the tool flow more productive, but the underlying engines still need to execute, and there are limits to how fast they can become.
Darbari: We need to put all of these things in a singular context because if the manufacturing, or the physics, the heat, or the functional, are all sitting in separate context windows, and the software is sitting somewhere else, then you don’t have a complete picture of what this whole device will look like. I was coding for one project and I remember asking a designer, ‘What would happen to this processor if there was more than one outstanding transaction? Could you discard the later ones?’ And he said, ‘We’ll just discard them.’ Everything was exhaustively proved, and while I was taping, the software teams were running their own stuff. But a bug got missed. The software team had a completely different understanding of how they were going to drive the SoC. So they found a trace, and they said, ‘We are losing transactions.’ There was a complete misalignment between what the architect and the designer thought they were building, so they had to patch it at the end of the day. That’s what worries me now, because things are getting so much more complex. We’re putting all of this in the hands of an agent, but who is the master at the top level? Is there a master agent?
Schirrmeister: But there’s also a counter-example. It’s true that there might be a communication mismatch, but there also may be complexity issues that are hard to observe by one person, and then your context applies. I have an example from a previous life, when there were software developers and hardware developers, and you had an emulator. The software developers were writing their software, and everything was correct. They talked to each other for days, but then they started pointing fingers. Suddenly, the emulator vendor was at fault. There must be something wrong in the tool. Then we figured out that in the global setting, the code was powered down at that particular state in the system context, and the software developer didn’t see the register programming as being correct. The hardware developer saw it as correct, but didn’t know that it switched off because the clock was gated and that area was shut down. From a context standpoint, all that information needs to be communicated. That’s one issue. But then it also needs to be available in the context of the agentic AI.
Darbari: Unless we stitch the agents in ways so that we can handle all of these challenges, there will still be bugs creeping through the seams. People will be investing in agents and doing all the stuff you’re talking about, but there is still no single context where you could look at all of this together. AI could be used for this, and it’s really what AI should be used for, because it’s humanly not feasible to know and derive all of this information that should go into a single arrangement.
Laviv: With chips like [Intel’s] Broadwell, with 200 billion transistors, we’ll need much more verification. Today, the tools have challenges running such designs without emulation. We need to see if some things can get shifted left and prepare the simulation environment to pull in the emulation earlier. But if you have such a huge chip, it’s a challenge. With AI, we’ve heard how you can interact with the simulation or the API. So if you let AI have some internal insights to formal, to simulation, now you don’t have to wait two days for a test to end. In the AI era, for each of the tools, we can find hooks that AI can use in order to make better judgments and clean stuff faster.
Darbari: We’ve been looking at the power/performance/area estimate, and there are some very interesting insights we’ve received. We can look at the entire chip, analyze it to figure out if the unused area is burning power. What surprised us most, because we knew we were looking at results where synthesis isn’t going to remove it, is that we didn’t have that data. But some of this stuff would be sitting in the die, not getting used. Synthesis isn’t removing it. Lint isn’t telling you it’s bad. Coverage is not telling you it’s bad. In order for us to be efficient with the end goal, we need to start thinking about the artifacts very early on. So, for example, picking up redundant logic should not be a synthesis problem. This should be a designer’s problem or an architect’s problem. If I want to remove a register or retime it, I want to make sure the design is built correctly up front. But whether it is built for the right reason is a separate problem. Maybe that’s a validation problem. But bringing what used to be a verification or layout problem in as a design or architecture problem is what needs to happen.
The post Shift Left Is Becoming A System-Level Problem appeared first on Semiconductor Engineering.