Find It in RTL or Pay in Silicon: The Real Cost of Late Bug Discovery

Welcome to espresso and electronics quick sips of video wisdom. I am your host Anekas Sunda and joining me today is Ahmed Dwa, senior group director at Cadence Design Systems. Ahmed brings over three decades of experience and he brings a lot of skills to the table right from product development to product engineering. Ahmed is leading the worldwide product engineering team at Cadence. Welcome to the show Amit. — Thank you Ana. Thanks for having me. So today's topic is very special because I think a lot of DV engineers will connect to this. The topic that we're going to discuss today with Amit is how to achieve first pass silicon success with confidence. So Amit let's start with something I want everyone to sit with for a moment. In 2024 we saw the lowest first silicon success rate in two decades. And this has happened even when we have more verification tools, we have more compute, we have more AI assistance than at any point in history. But I believe that the number is moving in the wrong direction. So Amit, can you share one of the key reason why many chips are not working correctly at the first time when they come back from FAB? — Uh, sure. Yeah, it's a very good question Anika. Uh as we all know uh it's a well-known fact that as designs

grow in sizes the verification complexity increases exponentially. Um with larger designs what happens is there are more states to be verified more interactions between them and as a result doing the exhaustive coverage with simulation becomes a very hard problem. Now yes you you're right you know there's more compute now and with AI coming in it becomes much faster and better but still the biggest challenge today in the chip design is how to do the verification closure without risk of a functional bug in it. So and more recently the stakes are even higher because at these advanced nodes the respins can cost a delay of 6 to9 months which can potentially be a cost of uh tens of millions of dollars. Yeah. — So that's the challenge and uh since you asked about a key reason I

would say one key reason for lesser first silicon success is that RTL simulations cannot cover certain verification cases especially related to timing. Now we know there are STA tools which work on the basis of some constraints assumptions but those still needs to be verified at gate level simulations with full timing and now we know that these are extremely slow they come very late in the design process — pain I'm sure — and yes and then and on top of that when uh there's a failure they are very hard to debug at that level of abstraction so doing GLS timing is becoming is still it still happens but it is very expensive very late and it is very hard to debug. So the challenge and this results in some of the cases of a bug slipping it into silicon. — The challenge is not what to verify but

how can we verify them sooner at RTL rather than doing later at GLS timing which introduces the risk that you talked about. — So are you saying this is like the entire shift left? You're moving everything from the expensive side to the inexpensive side. — Yes, that's the need. The sooner you can in the earlier you can find the bug or you can find your functional issues at ideally at an RTL level — then you are more confident and you have more time to put the fix. So that's exactly uh is one of the things we want to do — of course. Okay. So this is good introduction Amit. Now, let's get down into the details of this class of bugs, right? Because they are probably the ones that look completely innocent in the RTL domain, — but they absolutely ruin your day at the gate level and they're very expensive. I mean, imagine getting a bug closer to your tape out or, you know, your silicon is ready. So, help me understand why these are so hard to catch early.

— Sure. Um as I said you know STA tools in are there to ensure that the timing is met based on the given clock frequencies of the design. Now STA relies on assumptions uh that the design constraints files are correct like the constraints specified are are honored by the SDA tools. — So uh any wrong assumptions there could lead to a silicon bug. There are some specific examples like there's a multicycle path delay uh that is not accurate uh which means it reaches in the real silicon not in the same number of cycles as they are specified as MCP delays or there are certain timing parts that are marked false but are exercised or there are clock groups that are marked incorrectly. So SJ tools is going to relax or completely ignore these uh these con uh these these things specified in the constraint file. So essentially nothing is checked. Now for those specific reasons — GLST has to be done. Uh they have to confirm that there are no timing issues. These constraints since they may not be accurate. So they have to run very long gate level timing simulations. Uh there's another issue which is with glitches. What happens is that there are combo combinational logic in the MCPS and these parts can produce glitches. U these cannot show up in RDL — of course — uh as there is no delay. uh only GLS is when there are differences in IO part delays uh that's when the glitches will come in but as we said you know these could be fatal issues because if the glitches are in for example asynchronous resets or in some gated clocks or in CDC paths then these could lead to a very you know the silicon failure uh kind of bugs so finding the right bug this is this is what is typically called as we find the right bug but find it at the wrong time. — Yes. Exactly. — Right. So the crit critical issue is is it's very hard to catch them early and for those reasons it's very difficult to you know find them at an ideal stage. — Correct. I think we have tools but then maybe people are not using it at the correct time. It's like when hammer when the iron is hot right so you have to use the correct thing at the correct point. Right. — Yes. That's where we what we are trying to solve uh in the EDA industry. We're trying to give them the uh so that we can do this shift left as you said so that we can find these issues at RTL level rather than waiting for a much later and more expensive gate level simulations — of course. Okay. So Amit since you've worn a lot of hats, you bring a lot of skills to the table. If a team recognizes the these problems on their project, right? What is your recommendation or how do you think they can overcome them, right? Are there any solutions that you know you can tell the audience how to address this challenging problem? — Uh yes. So since I I'll focus on the timing things that uh that we want to verify. uh as I said you know multicycle path and false path these are actually architectural features which means they must be specified along with the functional intent and should be verified sooner at an RTL level. Now this is what we call as shift left which means you verify early at RTL rather than waiting for your gate level. Now

Excelium simulator has added this capability native into its simulator recently. So what we do is in Excelium you can we support the design constraint aware simulation natively at RTL. What it means is that the timing constraints like the MCPS the false path these are read directly into RTL SIMs uh into the Excelium simulator. Imagine now this is happening before synthesis. So you can find these kind of issues at your RTL level. Uh so uh what we do for example now in each of these cases is in MCP the tool checks if the timing is already taken care of an RTL and else if not then you can annotate some delay — uh the delay so that it matches the gate level behavior at an RTL level. So you are trying to mimic what you would have seen with delays at those cycles you are we are trying to introduce the delay for that many cycles uh in the multicycle paths at an RTL level. Likewise in false path if the map if you want to verify whether a path is false uh there is there are if they get traversed in the simulation dynamically in a simulation then the tool can inject corruption when it injects corruption the purpose is basically to find out if RTL can handle meta stability or non-critical timing paths — so having said this there's so much complexity do you think the simulator takes a hit on performance or do you think it's it is — so yes there there is an extra instrumentation both at the build time and at runtime But usually the cost if you imagine what you have to do at doing at the gate level and the amount of shift lift that is happening yes if you compare it with your regular RTL SIMs there will be an overhead but the productivity and the benefit that you are going to get with uh with this is going to be extremely high and as I said you're finding it months before you would have otherwise found — so it means it is in the limit that somebody can digest so within the — Yes definitely got it. uh and then there are other things like you know CDC uh where tools can inject in inject metastability on the on the first synchronizer so you know those kind of issues these can be done now at RDL level — so that's on uh what you see in your uh constraint sides uh then as I

talked about glitch — right — what what we can also do is uh for doing your glitch verification at RTL level we can for a given target we can identify a combo logic in the fan and cone of that target and then we can inject the glitches uh if there are multiple inputs that are changing uh in the in the fan and con. So that helps you to give you uh glitches also to simulate with glitches at an RTL level which otherwise as I said would only happen when you have IO part delays coming in later in the gate level simulations and uh if you're wondering now how we are doing this uh this is — my next question was which app are you

asking us to use for these? — Sure. So we have uh Excelium simulator has uh provides any specific verification task through through Excelium apps. So we have uh for the timing constraint violation timing constraint verification app or the TCV app uh in Excelium and for glitch we is we simply call it a glitch verification app. — Okay. And uh the good part is uh this is as you talked about the performance uh we have a patented active path

tracing algorithm which makes it accurate and uh unlike traditional simulator which only had the concepts of events and nodes uh because of this technology we are able to have the notion of path in simulation. So which makes it very powerful and makes it very accurate to find these issues at RDL. So yeah, overall it's much faster uh it's much earlier and it's uh easier to debug as well. Um — yeah of course so I think yeah the debug and the simulation go hand in hand right so I'm sure pretty sure okay — thank you Amit it was a pleasure having you on the show — thank you listeners for tuning in keep your circuits connected and your ideas flowing until we meet next on Espresso and electronics