WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 529
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 529
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)
            
14173 SemiWiki Banner 800x1001
WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 529
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 529
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)

Functional Safety for Automotive IP

Functional Safety for Automotive IP
by Daniel Payne on 12-15-2022 at 10:00 am

Automotive engineers are familiar with the ISO 26262 standard, as it defines a process for developing functional safety in electronic systems, where human safety is preserved as all of the electronic components are operating correctly and reliably.  Automotive electronics have now grown to cover dozens of applications, and George Wall of Cadence presented on this topic at the recent IP SoC event. I learned that ISO 26262 came from the parent standard IEC 61508, first released in 1998. Functional safety is defined as the, “Absence of unreasonable risk due to hazards caused by malfunctioning behavior of Electrical/Electronic systems.

functional safety in automotive electronics
Automotive Electronics

A systematic failure would be a design bug in the hardware, causing something unintended in the system, while a random hardware fault would be a silicon defect in a chip causing a stuck bit or even an alpha particle causing a memory bit to flip. The goal for SoC designers is to make their design resilient to faults, ensuring safety.

The Automotive Safety Integrity Level (ASIL) defines the highest level of protection from systematic and random faults, called ASIL-D, which requires >99% coverage against single-point faults, and >90% coverage against latent faults. For automotive electronics that control braking and air-bags you need ASIL-D level compliance.

To reach the safety goals, then any faults need to be blocked, avoided, designed out, or mitigated. Four commonly used hardware safety mechanisms found in processor-based SOCs include the following:

  • ECC protection of memories
  • Watchdog Timer
  • Software Self-Test
  • Dual-Core Lockstep

These safety mechanisms are specific to processors, and the list is not exhaustive.

It was 9 years ago in 2013 that Cadence acquired Tensilica for their IP cores, and that investment has grown over time to supply IP for automotive in several categories:

The Tensilica processor IP has been certified to be ASIL-D compliant for systematic faults, where a single processor is ASIL-B compliant against random faults and two processors operating in lockstep are ASIL-D compliant against random faults. Even the Tensilica C/C++ compiler toolchain is certified to ASIL-D. The IP has both fault reporting and fault protection mechanisms built in.

Memory ECC

Error Correcting Code (ECC) is available for memory interfaces like: instruction local SRAM or cache, data local SRAM or cache, and the cache tag store. At the system level you can monitor the ECC error information. A 7-bit ECC syndrome is calculated on 32-bit words, and single bit memory data errors are automatically corrected, while for multi-bit errors an exception is signaled.

Windowed Watchdog Timer (WWDT)

To ensure normal execution of software a WWDT acts as a system supervisor, where inside the normal operation window the software restarts the WWDT, however if the WWDT counts down too early or too late it will cause a reset request to the SoC. The ISO 26262 standard defines Program Sequence Monitoring (PSM) as a way to ensure correct code execution, so the WWDT is the safety mechanism used.

WWDT min
WWDT

Logic BIST, Software Self-test

Using  logic Built-In Self Test (BIST) the hardware tests a portion of logic, detecting static faults , while adding about 5% overhead in the silicon and running in only milliseconds of time, typically producing 90% fault coverage. Logic BIST can be run at startup time and then report any detected faults.

With software self-test there’s no hardware overhead, because it’s just software to test logic at different times, like for periodic runtime checking. ISO 26262 lists software self-test as a safety mechanism from random faults, with a medium diagnostic coverage, and it’s included in the Tensilica qualitative FMEDA. The Xtensa Software Test Library (XT-STL) provides tests to confirm the basic processor operation, non-intrusively. You would combine XT-STL functions along with your own tests, like during power-on testing, or mission mode tests.

Hardware Redundancy

Higher fault tolerance can be achieved through hardware redundancy, either with time-based redundancy or hardware redundancy. ECC for memory is an example, and you can add triple-redundancy voting flip-flops, parity protection of Critical State Registers (CSRs), or for processors use a Dual-Core Lockstep (DCLS).

Tensilica supports DCLS with a technology called FlexLock, where two cores run the same code in lockstep with each other, and a comparator finds any differences, supporting ASIL-D requirements.

DCLS min
DCLS

There’s even a dual memory lockstep, adding redundancy on core logic and memories.

Dual Memory Lockstep min
Dual Memory Lockstep

Security

There’s a cybersecurity standard for road vehicles, dubbed ISO 21434, adding a security lifecycle for automotive. Four commonly used threat protection mechanisms used in SoCs include:

  • Hardware root of trust – secure boot, authentication of boot
  • Cryptography – protecting data
  • Hardware isolation – divide trusted and non-trusted regions in memory
  • Anomaly detection – alert suspicious activity

Tensilica has Xtensa LX processors that support hardware isolation using a secure mode for running authenticated code, then a non-secure mode for running untrusted code.

Anomaly detection can be implemented with WWDT, alerting about unexpected program execution. With the dual memory lockstep approach any divergent execution causes a safety fault.

Summary

A traditional car today has at least 40 kinds of chips, while the total number of chips in a car can reach 500, so designing for safety requires the disciplines of following ISO 26262 standards. Meeting safety goals means that processor IP used in cars be ASIL certified to the appropriate level. Cadence has a good track record in their Tensilica IP of using safety and security measures to meet automotive requirements.

Review the 33 slide presentation from IP SoC 2022 here.

Related Blogs

 

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.