Infineon and Cadence have a bit of a history: they’ve been working together on functional safety mechanisms for around two and a half years now, and Infineon has been using the entire Cadence verification suite since the nineties. Functional safety is a serious hurdle for the automotive industry, and with the rise of ADAS systems, the issues that face Cadence and Infineon are about to get a lot more complicated.
Right now, the hot topic in functional safety is fault injection. It plays a huge role in functional safety, but it’s the same fault injection you need to do in usual DFT sims. For functional safety, your standard DFT simulator is typically not rigorous enough. Chips inside cars receive so many stressors over the course of their useful lifecycle that both physical breakdown and radiation based breakdown can knock them off their usual function. Therefore, in testing, faults are purposely added to the design to ensure that the chip can work properly even if things go very, very wrong. You can’t just run a conventional functional verification sim and get the data you need.
Fault models are used to decide where faults are going to be injected. There’s a few types of faults that could be tested—one is a soft error, which is caused by charged particles hitting the chip in places where they shouldn’t be. This can cause a single event upset (SEU) or a single event transfer (SET), both of which are fairly unpleasant. SEU faults cause an error that exists for a finite period of time, but a SET faults cause permanent errors that occur in the running system. Both types can trigger a whole host of problems that can be difficult to diagnose if they are not caught near the source of the error.
There’s also physical faults, which come in two main flavors: stuck-at, where the fault node is permanently 1 or 0; and bridging, where two signals connect where they shouldn’t.
In addition to that, not all faults are strictly harmful. Some are “safe faults”—which means they’re in a non-safety-dependent part of the design. Safe faults are important for DFT, but aren’t a factor for safety systems since they don’t factor into any safety-related failure modes in the system—but it’s worth noting that “acceptable faults” exist.
Fault injection ties into both qualitative and quantitative analyses. By injecting faults, you can see how a design fails, rather than just where—and that knowledge lets you design better systems in the future. You can also ensure that the safety mechanisms can detect the fault by injecting it in a known location. Quantitatively speaking, fault injection gives you various statistics, a list of faults, and information regarding types of workloads that make failure more likely, as well as other data points.
Historically, Infineon used Cadence’s Verifault software to do fault injection, which was pretty inefficient. Verifault could only do DFT, so you had to run it twice to check to the safety mechanism each time you wanted to do so.
Now, Infineon uses IFSS, or the Incisive Functional Safety Simulator and the vManager-based fs_runner environment.
Figure 1: The fs_runner environment.
This allows them to simulate to a time point, pause it, inject a fault, and let it propagate as the simulation continues. vManager allows them to run a “fault campaign”, which compiles a series of different faults that are all injected at various points. It also generates a report from the fault simulation for easy review.
For more information on this topic, check out Infineon’s presentation on this topic here.