Never miss a story from Breakfast Bytes. Subscribe for in-depth analysis and articles.
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:
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:
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:
Double-clicking to go down a level, the 5 arrows on the left in the above diagram are:
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:
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:
Based on some of the intuitive guidelines and rationale consensus, the WG is proposing the following data model with the given set of guidelines:
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.