Scaling Safety Analysis. Reusability for FMEDA

It is common when a new type of analysis is introduced in almost any domain that it works well enough for a while. Until it begins to struggle with growing problem size, prompting refinements to the methodology to allow continued scaling. We see this routinely in analytics for SoC design, so it should not be a big surprise that safety analysis, in the form of failure modes, effects and diagnostic analysis (FMEDA), is starting to look a little creaky. Which is no small concern. FMEDAs are the contracts passed up from IP developers to SoC integrators, providing assurance that safety weaknesses have been fully analyzed and mitigated. This is not a requirement we want to short-change because the analysis problem becomes too messy.

Configurability – the root cause

Most IPs are configurable, even in-house IPs, because to be useful as reusable components, they must be able to adapt to a variety of different SoC applications. There is no IP more configurable than a network-on-chip (NoC). The whole structure of the NoC will change depending on how many components it must connect. And what quality of service goals it must meet, how it should adapt to minimize congestion and so on.

All this configurability is essential to meet SoC design goals, but it comes with a downside. FMEDA is a flat characterization based on fault simulation, run on the component as configured. There is generally no way to analyze a parametrized IP before configuration. SoC integrators must run the analysis per IP, even on commercial components. IP suppliers will provide as much help as they can in the form of templates and advice, but the burden of final and lengthy FMEDA remains with the integrator. The SoC team must repeat this analysis if the configuration changes, all adding up to a lot of extra work.

The core problem is a lack of reusability in FMEDA. If this could be restructured to support reuse, then IP suppliers could provide a means to generate not only a configured IP but also an FMEDA for that IP. Integrators could avoid most of the effort in repeating flat analyses in this case

Redesigning FMEDA for reuse

FMEDAs, as they stand, are not parametrizable, but they could be generated through a combination of low-level safety models and a compiler which could read those models together with the configured IP RTL to determine how root causes will propagate to effects. Arteris IP has written a thought leadership paper on putting these ideas into practice. Cutting out much of the unnecessary rework in rebuilding FMEDAs. Conceptually this makes sense to me. Failure modes don’t change on configuration. There may be more or less of a certain type in some cases, added or subtracted in predictable ways. How these can propagate to effects also won’t change much except as perhaps you could analyze through interpolation between a few carefully selected configurations. Allowing a tool to compute the influence on the likelihood of failure. The concept seems very reasonable.

You could extend automated generation not only to generating IP FMEDAs but also to generating the SoC FMEDA. Apparently, leading semis in the automotive space already do something like this internally. The SoC generator must aggregate FMEDAs from the IPs. Applying in-context requirements and assumptions of use to abstract failure modes to those relevant to system behavior. Adding this functionality with IP FMEDA generation could take a lot of the pain out of safety analysis for SoC integrators.

You can learn more about this topic in this Arteris IP presentation HERE.

Also Read:

Why Traceability Now? Blame Custom SoC Demand

Assembly Automation. Repair or Replace?

Experimenting for Better Floorplans