Breakfast Bytes Blogs

At DVCon last week, there was an update on the Accellera Functional Safety Standard that is in development. The working group (WG) is chaired by my Cadence colleague Allessandra Nardi. Also on the presentation were:

• Vatsa Prahailada, who is Technical Director at NXP San Diego (and previously was at Intel and Qualcomm)
• Darren Galpin, who is Principal Digital Verification Engineer at Renesas UK, working automotive power devices (and previously at Infineon Bristol and ST Microelectronics)

Darren is also Secretary of IEEE Functional Safety Standards Committee. The expectation for the Accellera standard is that, like other earlier standards, it will be developed in Accellera, go through a period of shakeout for a year or two, and then be submitted to become an IEEE standard. Which, I guess, means it will land on Darren's desk in, say, 2025. There is already an IEEE standard number, IEEE P2851 (the P means provisional, so in progress and not a standard yet).

If you need to get up to speed on functional safety (FS or sometimes FuSa), then I've written plenty of Breakfast Bytes posts about it. Work your way through:

• Make Sure Your Car Doesn't Break Too Often...When It Does, Make Sure You Catch It
• "The Safest Train Is One that Never Leaves the Station"
• History of ISO 26262
• ISO 26262...Chapter 11
• Accellera Functional Safety
• Announcing Cadence Safety Solution and the Midas Platform...Turn Your Automotive Products into Gold

Alessandra opened by saying that the presentation would be an update on the Accellera standard that the working group is developing. The group was formed two years ago. Last May, it published a white paper with the very vanilla name of Functional Safety Working Group: White Paper. The WG is working on a second white paper on the data model, originally scheduled for literally right now, but is slipping out into Q2.

The mission of the WG is:

• Define an FS data format/language to capture and propagate the functional safety data through the flow/supply chain
• Enable interoperability, traceability, and automation

Double-clicking to go down a level, the 5 arrows on the left in the above diagram are:

1. Exchange of same FS data across different automation tools
2. Connection between FS data and the design information
3. Sharing of FS data between different operations/work-product in the same layer
4. Exchange of FS data between suppliers and integrators
5. Traceability of information across the distributed development environment

Functional safety is not just something that affects EDA tools, it needs to link into requirements, and all the documentation that is required by automotive manufacturers to make everything traceable.

It seems to me that there are two primary aspects to the work to be done. One is to work out what functional safety concepts need to be captured. And the second is to define a format to capture them. It reminds me a lot of the CPF/UPF power formats, where the first step was to define what power measures should be supported (power down, DVFS, etc.), and then define a format to capture the power intent.

The above diagram shows some of this. But you need a secret decoder ring if you are not totally immersed in the jargon:

• FMEDA is Failure Modes, Effects, and Diagnostic Analysis
• DFA is Dependent Failure Analysis
• FTA is Fault Tree Analysis
• FMEA is Failure Modes and Effects Analysis
• AoU is Assumptions of Use

In the center of the diagram is the "FS Data", a representation of the FS Data in the format that the WG is defining, using the concepts of the FS Data Model, which will be in the white paper published next quarter.

The design, for FS use, can be represented as either functional (on the left) or structural (on the right). Or both, since they can be two different ways of looking at the same thing. On the left, the failure modes are purely functional, on the right they can be more specific. One important point is that the FS hierarchy does not have to match the design hierarchy, and one of the things for which the FS format will need to provide a mechanism is how to map them.

For example, here is an example, with the FS hierarchy on the left, and the design hierarchy on the right. The mapping is:

• TOP to top
• MAC to top.cpu.mult_mac
• MMU to top. dmmu_top and top.immu_top
• DCACHE_RAM to top.dc_top.dc_ram

Based on some of the intuitive guidelines and rationale consensus, the WG is proposing the following data model with the given set of guidelines:

• Start with the simplest model and add complexity only if there are specific cases which are not supported. 
• In general, the more complex(/flexible?) the model, the more rules are then needed to ensure consistent/exchangeable models.
• Select attributes to allow the smallest granularity needed

Darren then took a deep dive into the conceptual data model. It is too much detail for a blog post like this. You should have attended the presentation or, presumably, it will all be in the Q2 white paper. He also went over some of the issues that the WG is wrestling with, such as whether parts can have sub-parts.

Alessandra wrapped up the meeting by going into some of the future work. One of the key things is that the WG does not want to change/reinvent verification methodology, so things like fault simulation and formal are all taken as given. The issue for the WG is how the data model should support these different verification methods.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.