Using IP in a SoC Compliant with ISO 26262

The automotive segment is being well served by semiconductor suppliers of all sizes because of the unit volumes, and the constant push to automate more of the driving decisions to silicon and software can raise lots of questions about safety, reliability and trust. Fortunately the ISO standards body has already put in place a functional safety compliance specification known as ISO 26262, so engineers working at automotive companies have a clear idea how to document their processes to ensure that you and I as consumers are going to be safe while driving the old fashioned way with our hands on the wheel, or more towards the goal of autonomous driving which will be hands-free. Semiconductor designers can use dozens to hundreds of IP blocks in their automotive chips, so one challenge is how to be compliant with iSO 26262 while managing so many blocks.

Design companies have teams with various Functional Safety (FuSa) roles, like:

• Functional Safety Manger (FSM) – creates a series of surveys
• Design Engineers – uses the surveys and completes a response for each IP being used

By the end of a project the FSM has read all of the survey responses and can decide if the automotive system meets functional safety readiness or not. Methodicsis an EDA company offering their Percipienttool for IP Life Cycle Management (IPLM), and the good news is that using Percipient will help both the FSM and design engineers document and manage their ISO 26262 process.

Change is constant, so what happens if one of your semiconductor IP blocks has been updated since it’s last release? Well, with a tool like Percipient you’ll be notified that a new IP version is available, then make the decision to either keep the old one or go with the new one, all while having an audit trail of the decision, no more manual tracking because it’s a built-in feature. Even if your IP is hierarchical and has dependencies, you will always be in the loop if some lower-level IP block has changed and then decide how that change affects your compliance status. Using a design flow with Percipient lets your team manage compliance with little engineering effort while keeping the context and version awareness.

You can now achieve IP reuse by using an approach which separates the IP hierarchy and dependencies from the IP data, because Percipient is maintaining the usage and dependencies outside of the IP itself. This methodology then provides a scalable workflow while re-using IP blocks.

I introduced the concept of an FSM creating surveys based on FuSa needs, and you can have surveys used at each level of the SoC design hierarchy while re-using soft IP, hard IP, external IP. Collections of surveys to cover a specific use case are called Survey Lists. Soft IP and Hard IP can each have their own surveys and FuSa requirements:

In your team the FSM or IP owners have the flexibility to attach a specific survey to an IP. Like the above example, your team could decide that all Soft IPs should have Survey 1 attached, while all Hard IPs should have Survey 3 attached.

Even at the SoC level you will have a survey list attached, so that when you want to look at a particular survey it will filter to show only what you requested and is relevant in that context:

If FuSa compliance was not a requirement, then at the SoC level you would see none of the surveys and their results.

Let’s say that in the middle of your design project you decide to swap out the Bluetooth sub-system from one vendor to another vendor. As your team is using Percipient that tool automatically loads the surveys and results from the IPs in the new Bluetooth sub-system, while the designers keep going along their daily tasks with little impact. Version control in Percipient shows the complete history of making changes to the hierarchy, and so you can see compliance results over time. Change is constant, but your engineers aren’t paying any penalties when it comes to compliance.

Each survey result is attached to an IP block and at a specific time, so when you create or accept a new version of an IP then you get to decide if the survey results stay the same as before or are now changing. If the IP is changing enough, then it calls for a retake of the survey. With Percipient you’re going to see a traceable history of changes on survey results for each IP, while not causing extra work for designers.

Compliance reporting can be complex because there are four levels to ASIL A-D, which in turn will affect who will create the surveys and look at the reported responses. Using an IPLM software package is the way to go, because it can handle all of the permissions and restrictions tied to the different ASIL levels.

Summary
Automotive design is a growing opportunity for electronics companies and the challenges of being ISO 26262 compliant can be met more rapildy by using the appropriate software tools from vendors like Methodics. The Percipient tool is an IPLM approach that will help your team meet ISO 26262 compliance.

Read the complete White Paper online.

Related Blogs

• ISO 26262 Traceability Requirements for Automotive Electronics Design
• Combing IP and Product Lifecycle Tools