Design rules for functional safety are explored at DAC

The Accellera Functional Safety Working Group was created in December in 2019 and is dedicated to standardise across system, module, component and IP levels to define an efficient data model that engineers can use with confidence for best practices across the design cycle, explained Alessandra Nardi, chair of the Accellera Functional Safety Working Group.

“Functional safety adds complexity to product development,” observed Ghani Kanawati, technical director of functional safety at Arm. This can bring conflicts between safety and other functional features, for example security.

“There are always conflicts, you will be designing for performance but find out that you are affecting security. The same features to enhance safety performance will open flaws or security,” he said. He advises planning and says that designers need to make judgements about what feature is a priority and resolve these early to avoid problems later in the design cycle.

He advises considering the design process, whether front-end or back-end and to have the design process in place. This will allow the design to be sanitised before a test run before adding functional safety. “Adding functional safety like sprinkles on a completed design does not work,” he said, because this approach could result in 12 months of fixing or patching the design. It is essential to have this complexity solved from day one, he added, reiterating the need to have a process – or design phases – in place.

Part of this process means using the correct tools, whether for verification or analysis. Trying to solve these processes without them adds another level of complexity, he warned.

His advice can be summed up in the following steps:

Begin with technical safety concept then initiate produce develop at the hardware level, including non-safety steps;

Designing for functional safety introduces a new element or process – the specification of hardware safety requirements. Evidence of meeting these will be required by the customer;

Only now, can the hardware design begin, although a new process for functional safety is to prove the hardware architecture metric;

An evaluation of the hardware safety goals due to random hardware failures will be required. This is unique to functional safety, said Kanawati. The designer is expected to find holes and ways to design around them;

Next will be conventional design steps as for non-safety designs, such as hardware integration and testing, then item integration and testing.

Functional safety adds a level of complexity to a familiar process insomuch as designers will be required to manage safety requirements and assess what will need to change is the safety requirement changes. Designers will also have to factor in configuration management, change management, verification and documentation.

Another new consideration will be confidence in the use of software tools, said Kanawati. It may take months to ensure a tool can be used in a safety environment and evidence of its suitability will be required.

Finally, a new element to the design process will be safety analysis and dependent failure. This has never been done before, Kanawati noted. Dependent failure analysis identifies failures that may interfere with hardware, software or firmware elements and which may violate safety requirements.