Application-based Empirical Modeling of Semiconductor Circuit Reliability (2026-US-30MP-2921)

Hello, everyone. My name is Mehul Shroff. I'm with NXP Semiconductors in Austin, Texas. Today, I'm going to talk about work we've done to look at application-based empirical modeling for semiconductor circuit reliability using JMP. The outline of my talk is roughly this, I'll start with a little bit of background, then state the problem, and then dive right into reliability modeling, which includes some demonstrations using JMP, and then show the results after we redesign the circuit to address the issue at hand.

I'll start with a little bit of an introduction. When we look at aging or wear-out of CMOS transistors, there are two fundamental mechanisms we focus on. The first one is hot carrier injection, which is when energetic channel carriers that are part of the current flow getting injected into the gate dielectric, because they have sufficient energy to jump the barrier.

The second one is BTI, or Bias-Temperature Instability, where the silicon-hydrogen bonds at the interface break due to the vertical field across the gate dielectric, and we have some recovery when the field is removed. There is also a third mechanism called time-dependent dielectric breakdown, but that's not considered an aging mechanism per se in terms of how we approach it in managing it, so I'm not going to speak to that here.

Both of these mechanisms generate fixed charges, denoted by Qf, and interface traps, denoted by Dit, which degrade transistor performance over time. In a very simple way in terms of how they play a role, this is a very simplified schematic of a CMOS inverter, where the input essentially gets flipped into an output, so, if the input is high, the output is low, and vice versa. This is a PMOS transistor, this is an NMOS transistor. This is where we have the supply, and this is the ground.

If I just look at the output waveform, which again is the inverse of the input waveform, then what we see on the down slope, on the falling edge, is the NMOS HCI. On the up slope, or the rising edge, we have the PMOS HCI. At the peak, we have PMOS NBTI, and NBTI is simply Negative-Bias Temperature Instability based on the voltage of polarities. We have wear-out and NMOS PBTI, which is the Positive-Bias Temperature Instability, we see some recovery at the peak. Then at the valley, we see the opposite. We see PMOS NBTI recovery and NMOS PBTI wear. In a very conceptual sense, as the circuit is operating, these are the different parts of the waveform where the different aging mechanisms are in play.

A little bit more on hot carrier injection, since that is the focus of this work. Again, as the current is flowing through the transistor, and this is a very simple cartoon showing the transistor, you have a gate terminal, which is a conductive material, then you have the oxide or a dielectric, which is the insulator, and this is what acts as the switch, then you have the source-drain, which are heavily doped regions, and then you have the well. As the device is biased, and as the current flows through the channel, the electrons or the holes, as the case may be depending on the polarity applied, gain energy on moving from source to drain.

As they gain energy, some carriers can become highly energetic, and they can jump across the barrier into the gate dielectric, and that can damage the interface, or the dielectric itself. As a result of the trapped charges or the interface traps, they can affect the parameters of the transistor, for example, the threshold voltage. Over time, the voltage increases, and that can result in either increased leakage, or reduced drive current, effectively degrading the performance of the transistor.

The overall effect is the reduction of the mobility, also known as conductance, of the transistor when on, increase in threshold voltage, and this can occur in both NMOS and PMOS devices. Historically, it's been a stronger effect in NMOS than PMOS, but as we scale technologies, this is starting to change, and both are now significant factors in terms of circuit design and wear-out.

Next, we have to think about I/O. The input/output circuits on a semiconductor chip are essentially elements that help the circuit talk to other ICs on the board, and they can either receive data, so that would be the input mode, or they can send data, which would be the output mode. The general-purpose I/Os that we have often need to support higher voltages, either 1.8 V or even higher, for example, 3.3 V, to be able to talk with peripheral ICs that may be built on older technology nodes. But as we scale to new geometries such as FinFET and Gate-All-Around, as a result of scaling, it is difficult to form the thicker gate dielectric in the devices in what's known as the high-k metal gate integration.

Therefore, to achieve these higher voltages, we have to stack transistors, which results in a more complex circuit. Coming to the simplified block diagram, here we have a 1.8 V I/O using native 1.8 V transistors. It's a pretty straightforward circuit, relatively speaking. But now, when we try to use this in a 3.3 V operation, the transistor itself cannot support the higher voltage. So, what we have to do is stack here. In this case, it's a two-high stack, or a two-transistor stack, where the idea is to split the voltage using some voltage-dividing circuitry so that it's roughly equal between the two transistors, and therefore, while each transistor is safe because it's at or below its specified voltage, the circuit itself can operate at a higher voltage. You can even conceive of this going to a three-high stack if you have an even lower-voltage transistor, but you still need to support something like this. Of course, that would increase the size and the footprint of the I/O cells, so there are trade-offs with that.

If we don't get the voltage divider right, then we can have significant differences in voltages between the transistors, and that can lead to differential aging on the individual devices. That can pretty quickly lead to problems, as we'll see. Additionally, such I/Os are also more susceptible to extrinsic reliability issues, which we are not going to cover in this talk, but just for awareness.

That brings us to our problem statement. In one of our recent technologies, we had to build 3.3 V I/Os using stacked 1.8 V transistors, as I showed on the previous slide. Due to a timing marginality in our design, we ended up with a very high voltage across the source-drain, represented here as VDS, across the top NMOS device in the output driver, which I showed in the previous block diagram, which resulted in HCI-related wear-out, an extremely accelerated wear-out.

When the same circuit was used at 1.8 V operation, we had no issues with that, and these waveforms show that. These were the voltages across the key inputs to the devices in the output driver. As a result of the timing marginality, we see that we had a 2.87 V spike across the source-drain of the top device. Again, this was a 1.8 V transistor, so this was pretty severe. Each time we had an output falling edge, we were seeing this spike, although here we only just show one of them.

A little bit more on this, again, this is the same thing just shown on a larger timescale. We see here, again, the VDS spike going up to about 2.8 V or thereabouts. This is the gate potential that seems to be holding within our technology numbers, and this is across the body of the device, which isn't relevant for this discussion. Now, when we go to the bottom device in the stack, because of the way the circuit operates, the VDS was relatively low, and the VGS, while higher, is still in the 1.8 V range, so this was in the safe regime. The bottom device had no issues, so all the wear-out because of the differential voltages was occurring across the top device of the stack.

What the symptom of the problem was, if you look at this as an output waveform, and these are screenshots from an oscilloscope, this is the initial waveform. As it wears out, you can see that the falling edge is getting flatter, and getting more and more degraded. Eventually, this leads to timing issues and loss of functionality, and eventually failures in the circuit.

Here is some electrical FA that we did at the device level, and here's a reference circuit where everything looks fine. Then these are two different circuits that aged as a result of exercising them. You can see that the initial waveforms or Id:Vg curves are pretty solid and as expected. But after wear-out, we see that the threshold voltage is shifted quite significantly for the top device, and that results in a degraded performance. Because of the top device ending up being so degraded, and effectively it becomes a resistor, we also see that the bottom device drive current reduces, even though its threshold voltage has not shifted as much, because it's not as susceptible to aging given its waveform. But it picks up an indirect effect of the degradation of the top device.

All of this, the circuit simulations, and the electrical FA, and what we see at the board or the application level, all tied together nicely and told us what was going on. Then the next step for us was to determine how can we model this better, and use that to understand the behavior across a range of applications while we were exploring how to redesign the circuit and figure out what our boundary conditions were, and what our safe operating area was. The goal of the modeling was to use circuit inputs to model the IOL, which is the output low current, and that's shown here in this schematic, where it's the current from the pad through the NMOS side of the driver as it's operating in the output mode. It was measured at a VOL of 0.5 V.

We started with the use case specifications. We built this IOL degradation model with a bunch of experimentation, and this was purely an empirical model. Then looking at the loading and the protocol, there are various protocols in terms of how the I/O is expected to operate, we built a circuit model, and then we converted that to an application parameter from a circuit parameter, and that was using fall time, which I'll come back to later. The basic idea was the IOL was a circuit parameter, and the fall time was an application parameter. We had to build an initial model using IOL, and then translate it to fall time, and ultimately use that to assess the impact on protocol functionality at the end of life.

I'm sure everyone knows this in this audience, but just to reiterate, all models are approximations. There's a famous quote by George Box that all models are wrong, but some models are useful, and that assumptions, whether implied or clearly stated, are never exactly true. When we embark on a modeling exercise, the question we need to ask ourselves is not, "Is the model true?" because it never is, but "Is the model good enough for this particular application?" Another way to think about this is, don't let the perfect be the enemy of the good.

What does that mean in practical terms? Well, we need to think about a model in terms of parsimony, which is, within reason, simpler models are better, and we want to avoid overly complex models, and selective worrying, which is knowing the errors and limitations of our models. Then we use AICc and BIC as metrics to judge our models and look at their predictability for future data.

For the IOL degradation model, we set up the model as a function of the IO VDD. We had various different voltages that we included. We knew from work we did that below 2.4 V, we just don't see any degradation. We stayed above that and stayed in the 2.7 to 3.8 V range. The temperature, this is the operating temperature of our product and application, or the range of operating temperature range rather, so -40 to 125 C. Because this is accelerated testing, we obviously can't test for years, which is what we expect to do in the field. So for reliability testing, it's pretty typical to do accelerated testing. We looked at… We had read points ranging from anywhere from 24 hours to about 2 months, not necessarily for every condition. As much as we would have liked to do a full factorial, we just couldn't do that. I'll show you how we approach that. Then we can always extrapolate this to field use durations.

The frequency of the I/O, which we varied from 1 to 100 MHz, this was the upper limit. The toggle rate, which is the fraction of stress time for which the I/O is toggled. These were all our continuous variables, and then we had two discrete variables, which were drive strength, so there were two levels, zero for low, and one for high, and slew rate, which is how quickly the waveform rises or falls. Zero was normal slew rate, and one was slow slew rate. Drive strength is simply how hard the I/O drives stuff, and it's just measured in terms of the current available, and how many devices in parallel are operating. That's controlled by a switch within the circuit. Actually, both of these are controlled by switches within the circuit. In the interest of time, I don't plan to go into details of the circuit architecture.

The other thing was we also recognized that we had some externalities related to the board or the system, for example, the capacitance load, pull-down resistors. These were not included in the IOL model because it was not possible to vary these on our boards that we were using for our stress experiments. These were handled separately. We also had multiple pads on our circuits that had this issue, and we noticed in some testing that there was some variation. We didn't look at all of that because we could only look at a couple of pads at a time.

We did include control pads and other I/O architecture circuits that were on our chip that were not affected by this mechanism as a control or reference. Here's just a high-level variability gauge of all the data we collected across a bunch of different conditions.

Overall, we looked at 300 parts, 200 conditions, one or two pads per part, multiple parts per condition. In each case, the measurements were averaged over 5 to 10 repeats to reduce measurement noise, although we didn't completely eliminate it, but just some of the measurement noise we were trying to remove by averaging the measurements. As mentioned earlier, we did have control pins, and these included pins that were not being toggled, so they wouldn't degrade, and then other I/O circuits that were not affected by this mechanism, and these are not shown in this plot.

Overall, we saw a range in the shift in the degradation anywhere from 0.1% to more than 80%, and this is a log scale. Just through trial and error, we noticed that for shifts that were roughly below 1.4%, we were seeing a lot of variability. By excluding the data, we improved our AICc and BIC, and so we decided to exclude those from modeling. Then we know from reliability physics that these distributions tend to be lognormals, so we forced that onto the data in terms of how we did the modeling.

Now I'm going to switch to a JMP demo and just spend a few minutes talking about that. I don't know why I have two files, but okay. This is a JMP project, and this is all my raw data. These were just distributions, I'll skip this. You've seen the variability gauge, nothing new here, pretty basic. Now, one of the interesting challenges I had with JMP is that to do all the things I wanted to do, I had to jump, pardon the pun, across three platforms, or at least a couple of different personalities, and then a different platform. I started with just the basic Fit Model platform, and I transformed the data. Let me show you how that works. I'm going to just relaunch this.

Because I had to do this as a lognormal, I took my absolute shift value and just transformed it to a log. With JMP, I'm sure most of you know this, but you can do some of these transformations on the fly as a virtual transformation, so you don't have to create additional columns. I'll just show this as a real quick example, just as a random one. For the VDD IO, I went with the reciprocal voltage. It's an exponential 1/V model, which is one of the modeling techniques used for this mechanism. Again, this is just based on knowledge of the physics of the mechanism.

Here you can go into transform, and you can do… If you go into specialty, or actually in this case, it would just be a reciprocal, so it comes right here. You can obviously do logarithms, which is what I did for the absolute shift, or you can do specialty, which is Arrhenius, for example, which is something I had to do for temperature, and simply run it. This is mainly for two reasons, which I'll show, so, let me run it again.

The first thing I need to do is set my local data filter. Here's my absolute shift, and I need to reduce it to 1.4%. So, I get my plot, and I won't blow this up, see that all the parameters I selected are significant. Again, this is what we varied, and this came from our knowledge of the circuits and the physics of the mechanism.

I mentioned earlier that we were not able to do a full factorial for practical reasons, but what I was monitoring… My first reason for using this platform was to get this plot, the actual versus predicted plot, because I can't do that with the fit parametric survival, which is my bread and butter platform for reliability analysis. Then I was tracking VIF, and my goal was staying below 1.5, because I couldn't get to 1. So, 1.5 is fairly normal. In fact, internally, we allow a higher VIF, but in this case, I wanted to be a little stricter. That's what I did with Fit Model. These were the two things I needed to get. Let's see. Then I went to the bread and butter…

Actually, let me just say one other thing here. The one thing I noticed here as I did my actual versus predicted, and these are both in log scale, what I noticed is that, as my shift decreased, so as I go down this way, there was more spread in the data. What I did then with parametric survival, and I get… The first order, nominally, I get the same parameters, which is good because that's what I expect it to be, but here I don't get the plot, and I don't get VIF, so I just go back and forth between them. But because of the fact that the spread of the data is a function of the shift, what parametric survival allows me to do is, and I won't demo this because it's not worth it, I can also model the scale as a function of the input parameters.

Let me show that now. I'm going to redo, relaunch analysis. I have my effects, and here I don't have to transform the absolute shift because I can select the distribution as lognormal. Or I guess alternatively, I could have selected it as normal and then modeled it, but I didn't need to do that. These are the same parameters. Then in the scale, I added the same parameters. Now, this is purely mathematical. If I run this, I get this. Once again, I'll do my local data filter, go to absolute shift. I'm going to change this back to 1.4%. I get this. Again, if I look at the AICc, BIC here, compared to not doing the scale, I get a better fit.

Now, I do notice here that the scale for the slew rate parameter was not significant, so I simply remodeled this and just removed that parameter. Then run it. Then I'll go… Sorry, local data filter again, unfortunately. I'm not sure what's taking this long, but… Yeah, this now… Again, my alpha is 0.05, so this is 0.01, it's showing up as orange. It's not as significant as everything else, but it's pretty significant, so I'm good with this. This is now the model I used. Then the other thing I've done is, going back to my data file, I did create a validation column just randomly distributing to test the model versus… Train the model on a subset of the data, and then refine it using validation, and then test it on a chunk of the unseen data.

I can do that with the standard least-squares personality in Fit Model, but I could not do that with parametric survival. For that, I ended up using generalized regression. I think in the interest of time, I won't demonstrate this, but I did it both ways. I'll show the dialog, but I won't actually run it. It's the same thing. Again, in GenReg, I can't do the scale factor or model the scale, so I just had to do it nominally.

Then I did it both ways, one without the validation column and then one with the validation column. I think I had roughly 70% for training, 5% for validation, and 25% for test. I see that my generalized R-squared for all three partitions was pretty high at 0.9, and that was comparable to the case where I did none. When I go back to my slides, I'll show that the parameter estimates that I got were pretty comparable. That gave me a rough idea that my model was relatively robust.

With this, let me go back to my slides. This is all that I showed. I won't spend a lot of time for this. Again, with parametric survival, I was able to use the scale, which gave me a better fit, and allowed me to model some of this noise a little better. This is, again, after excluding the shifts below 1.4%, which I determined were most likely due to measurement noise. I should mention this, this is consistent with the test of specs we have that we were expecting noisy data below approximately this threshold, not exactly, but close enough. It wasn't a surprise or anything unexpected.

This is now just showing the spread model. This is my model without modeling the spread, where the spread is fixed. This is with the spread being mathematically modeled. This is obviously not physical, just purely mathematical. You can see that I have better AICc and BIC values, giving me a bit more confidence in the model. This is despite the fact that by modeling the scale, I do have more parameters, which should add to the penalty for AICc and BIC. But my log-likelihood was much better, which we can see the numbers right here, which even despite the penalty, I ended up with a better model.

These are the equations. Just because of the lognormal shift, I won't go through all the details, but this is what the final equation looked like. For the IOL shift, and then the sigma term, which is listed here, and that is then modeled this way. Now, the purpose of modeling the sigma, and really focusing on this is in reliability, we don't really rely on the median model. We actually need to project it to some low PPM, like 1,000 PPM or 10 PPM. 1,000 PPM is like 0.1%. We need to project failure rates at this low PPM. That's why we need to model the scale, and we need to try to get a little bit better at that. That was the whole thinking behind doing this. The scale is simply the total sum of squared errors divided by the sample size, and the square root of that. This is also the pure error versus the systematic error, or the modeled error.

Then I mentioned the GenReg. Again, I showed the R-squared values here, but here is without validation and with validation. If you compare the parameter estimates, they're close to each other. Obviously not identical, but they're close to each other.

The one thing, though, is because of the partitioning and the smaller sample size used for the validation, I do see higher AICc and BIC values, which is not unexpected. But because the parameter value estimates were similar, I was comfortable that I was on the right track. Then the generalized R-squares were for all three partitions were very close, and they were comparable to what I have without any validation.

I also tried additional modeling approaches, such as looking at quadratic and interaction effects, like both full factorial and response surface, and pruning for non-significant terms. Here, there were concerns about overfitting and explainability, like, what does it mean if these two parameters are combined? How can I explain it in terms of circuit behavior and reliability physics? We also looked at various predictive modeling approaches and machine learning approaches, so neural networks, ensemble models, bootstrapping.

These also led to concerns with explainability, like how do I explain a neural network model? But more importantly, or equally importantly, the other concern was, I did not find a good way of taking the model, which was a median model, and extrapolating it to my PPM or my failure rate target, for example, 1,000 PPM.

Next, the time frequency, and toggle rate are essentially related parameters of the activity of the chip, and I tried to combine them to reduce the number of parameters. But because the parameter estimates were slightly, but significantly different, or statistically significantly different, combining them actually made the model worse, despite the fact that I had fewer parameters. Ultimately, we decided to leave them separate. This also helped us in terms of how we were projecting circuit behavior. Then the other thing, we looked at ambient and junction temperature. Junction temperature accounts for the heating, and that is something we typically use for reliability. But it was easier to model with ambient temperature, and our temperature sensors, for whatever reason, were showing a lot of variability.

When I tried to model with the junction temperature, it led to some inconsistent results and high variability. Furthermore, for this particular mechanism, we know from the physics that it's actually worse case at cold. It actually made sense to model it as an ambient temperature as opposed to junction, and that gave us a more conservative estimate.

Now switching, all of that was obtaining the circuit parameter, and now we had to convert it to the application parameter. This we didn't measure because we didn't have a good way of measuring it on a stress board, so we ended up simulating that. Essentially, by adding a load, a capacitor, what we did was, using the idea of capacitance discharge, we converted that to a fall time parameter. The fall time was defined as the time it took us to get from say roughly 10% or 20% of the max voltage to 10% or 20% above the min voltage. This will be 3.3 in our case, and this will essentially be zero. We have to just define a line somewhere that this is our fall time.

It turns out, if we use the capacitance discharge approach, it's basically an inverse linear relationship. Knowing the use case, we can then take the result of this conversion or translation and compare it to the margins that we have at the end of life. This essentially shows what I just mentioned on the previous slide, and this is the equation for the capacitance discharge. Combining both of them resulted in… We built a calculator combining both of these. The idea then was that what's our fall time budget, and that's effectively based on half the clock period. Theoretically, the actual budget might be lower depending on other sources of variation or other limitations.

Finally, what we would conclude is that the allowable degradation depends on which edge is used for data sampling. If you have a single data rate type memory, it only uses the rising edge, whereas a dual data rate memory uses both rising and falling edge. Depending on that, there may be different amounts of margin available. Obviously, this is not something we wanted to live with before we launched our product, so we ended up having to redesign our circuit.

Without getting into too many details on the redesign, this is a simulation of the original I/O, and this again shows the degraded falling edge over time. Then after we redesigned and addressed the fundamental issues and the voltage division and everything, we ended up getting a much cleaner signal. Even after time or aging, the falling edge wasn't degrading in any significant way.

Looking at the data, so then we ran stress studies comparing the old I/O to the new I/O, and we can see the red points represent the old I/O. Again, we looked at a variety of conditions, and you can see different amounts of aging over time. But once we looked at the new I/O, no matter what we did, we weren't seeing any shift, so this was consistent with our simulations.

Then we also did some very long-term stresses looking at the redesigned I/O. This is just now not looking at the old I/O, but just extremely long-term stresses for several months at a time. This is a little less than 6 months. This is maybe, I don't know, 7, 8 months at these conditions, and we were seeing very little degradation. In fact, we were even coming in lower than the control, so this is all something we attributed to measurement noise, so no meaningful degradation, which is consistent with the previous slide.

In conclusion, we used JMP successfully to build a predictive circuit degradation model to explore degradation of an I/O, and the model combined… The elements of the model used came from both transistor physics of our understanding of this mechanism, and the circuit parameters. We did have to use multiple JMP platforms in parallel to build our story. Maybe this is something that JMP can look into as a future opportunity for streamlining, and I think I've made some requests in the past to JMP through the wish list and through other conversations. That concludes my presentation. Thank you for your time.