Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Arm Research
    • DesignStart
    • Education Hub
    • Graphics and Gaming
    • High Performance Computing
    • Innovation
    • Multimedia
    • Open Source Software and Platforms
    • Physical
    • Processors
    • Security
    • System
    • Software Tools
    • TrustZone for Armv8-M
    • 中文社区
  • Blog
    • Announcements
    • Artificial Intelligence
    • Automotive
    • Healthcare
    • HPC
    • Infrastructure
    • Innovation
    • Internet of Things
    • Machine Learning
    • Mobile
    • Smart Homes
    • Wearables
  • Forums
    • All developer forums
    • IP Product forums
    • Tool & Software forums
  • Support
    • Open a support case
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
System
  • Developer Community
  • IP Products
  • System
  • Jump...
  • Cancel
System
Embedded blog The Flexible Approach to Adding Functional Safety to a CPU
  • Blogs
  • Forums
  • Videos & Files
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
  • New
More blogs in System
  • Embedded blog

  • SoC Design blog

Tags
  • Software Test Libraries (STL)
  • automotive
  • Cortex-R5
  • industrial
  • Cortex-M33
  • functional safety
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

The Flexible Approach to Adding Functional Safety to a CPU

Naresh Menon
Naresh Menon
October 22, 2020

Functional safety has become both increasingly important and prevalent across a variety of markets, and this is clearly demonstrated within the automotive and industrial sectors.

Functional safety within the automotive industry was initially reserved for a number of critical functions implemented in a small number of Electronic Control Units (ECUs) within a vehicle. However, over the last few years this has changed significantly as the number of automotive applications with safety requirements have grown. This is perhaps best illustrated with the number of safety features made available in vehicles with level 2 autonomous functions such as traffic jam assistance and driver monitoring. As more driver assistance innovations and applications are integrated into the vehicle, the necessity for even wider adoption of functional safety is one of the most fundamental requirements on the journey to full autonomy.

The industrial sector’s evolving transformation towards smart manufacturing has seen the rise of automation and the growing adoption of collaborative robots (co-bots) working alongside humans on the production line. As human and machines continue to work in such close proximity, control systems must constantly monitor the integrity of the robot and react appropriately under error conditions. This in turn has driven the necessity for higher levels of functional safety. 

Human and Machine Smart Manufacturing

To learn more about functional safety in the industrial sector read our Arm blueprint blog here. 

Methods for incorporating functional safety into SoC designs

Implementing safety requirements in a structured and consistent way has been made possible by using internationally agreed standards, such as ISO 26262 for the automotive industry and IEC 61508 for industrial manufacturing. These standards have been put in place to develop a common language across the industry as well as provide a reference for what is considered best practice. To satisfy an application’s safety requirements, the creation of safety mechanisms and rigorous development processes are needed.  

One of the most recognized ways to mitigate random hardware faults to achieve the highest level of safety integrity, is through the use of redundant hardware. For a CPU, this could be through the creation of a processor with dual core lock-step implementation. This approach typically consumes a considerable amount of area and power which may not be merited for applications with lower safety integrity levels such as ASIL B or SIL 2. A combination of safety mechanisms, such as Error Correcting Codes (ECC), Built In Self Tests (BIST) and other safety mechanisms can be used to help achieve such targets. There are various forms of BISTs, including memory BIST, logic BIST and software BIST (Software Test Libraries).  

Logic BIST can be complex to implement with pseudorandom generated test patterns loaded into scan chains to test the logic which when run, can introduce high peak power demands on the system. The CPU must be taken offline to run the LBIST tests and restarted. This poses a challenge to tight requirements of fault detection during runtime. The performance level can also be negatively affected as there is time required for the processor to be reset and restarted on completion of the tests. In the case of memory BIST, the built-in testing is used for detecting predominantly stuck-at-faults within the memory and pattern testing is applied at full memory speeds. Memory BIST can be used with other safety mechanisms as this does not test the functional logic of the CPU. 

A Software Test Library (STL) lends itself to be a natural choice when used with memory protection. An STL does not require any form of hardware redundancy therefore using less silicon area and power. STLs are typically less complex to deploy as they are a simple library of software functions called by the software stack without the requirement to reset the processor. Perhaps most importantly, STLs can be deployed on devices which are already available in silicon, unlike online LBIST which needs to be planned at design time. STLs power usage is equivalent to that of an application running on the CPU and there is no additional power impact like in the case of LBIST.  

Software Test Libraries

STLs are a library of software functions which provide diagnostic capabilities. STLs test the hardware for the presence of permanent faults within the processor functional logic, such as stuck at one and stuck at zero faults. STLs can achieve ‘medium’ percentage detection rates of faults within automotive applications that is, up to ASIL B for the Single Point Fault Metric and up to SIL 2 industrial applications for the Safe Failure Fraction. In ASIL D automotive applications where the CPU utilizes dual core lock-step, STLs can be used at start-up to check the health of the CPU before the safety applications are run and can be used to run periodically to detect faults. STL source code is generally optimized so that it utilizes a minimal memory footprint. Tests are generally written in assembly to improve deterministic execution and fault coverage when compared to compiling a high-level language like C.

Arm Cortex-R5 STL and Arm Cortex-M33 STL have recently been added to the STL product portfolio. The newly released STLs can be integrated onto a new or existing SoC using either Cortex-R5 or Cortex-M33, both of which are aimed towards automotive and industrial applications.

Enabling functional safety on an existing design using STLs

To address a new market or applications with an existing chip, there may be a need to increase hardware metrics such as Single Point Fault Metric (SPFM) from the existing level as part of the functional safety requirements and STLs could be used to be help with this. When targeting an established chip at applications up to ASIL B or SIL 2, an STL is a natural choice to consider. It can be deployed without the need for additional hardware changes to the device. In addition, the STL allows users to define the individual tests to be executed and so limits the test time and memory resources used. 

When implementing an STL, it is valuable to consider where the Software Test Library fits in the overall safety concept of the CPU, how it can be integrated and how the analysis of diagnostic coverage can be performed. Arm enables licensees to do this through the documentation it provides with its STLs, adding confidence to help meet the targeted safety goals. Each STL has its own specific documentation such as a user guide, IP Failure Modes Effects and Diagnostic Analysis (FMEDA) and a Safety Manual. 

Each device has a functional safety concept which includes the safety measures and safety mechanisms implemented within the processor. When looking to deploy an STL, it is important to define the areas of the safety concept which will be addressed by the test library.  STLs not only detect faults in the functional logic of the CPU identifying stuck at one and stuck at zero faults. The Arm STL FMEDA report provides the licensee detailed information about the areas within the specific CPU that can be covered by the library. This can be used as guidance on how to apply hardware coverage for the processor to help fulfill the safety concept.  

STLs can be simply integrated into the software stack with a standard API and can be run periodically with the flexibility to define how testing is performed. The flexibility enables the licensee to either execute the complete STL with a single call or the testing can be divided into multiple discrete blocks. This either enables the depth of testing to be selected by targeting specific tests or it enables fitting the execution of tests across available time windows. This minimizes the STL’s effect on the main application’s workload and helps meet the desired Fault Tolerant Test Interval (FTTI). The operation and integration of the STL are described in the Arm STL user guide. 

The diagnostic analysis can be done in several parts, it can either be based on analysis to identify relevant areas where diagnostic coverage is needed and alternatively can be based on coverage measurement of the faults. The detectable faults of the processor can be measured through a fault injection simulation, the results of this can be used in a FMEDA to document their contribution to the overall detection of faults for the design and identify the residual fault fraction. Each STL is provided with its own processor FMEDA analysis performed by Arm which has been populated with the results of the measured STL fault simulation coverage. The analysis is based on a specific implemented configuration of the processor which can be used as guidance for populating results for the actual device netlist and configuration. To assist with this analysis, Arm also provides fault injection scripts simplifying the execution of fault simulation on the design’s netlist. 

The analysis of the product and its specific safety goals may allow areas of the design to be considered as not safety relevant. This can be used to adjust the results of the measured analysis, restricting this to only the appropriate areas of the design. In doing so, it is possible to achieve a higher percentage SPFM coverage for the device. If any gaps remain between the final coverage goal and the analysis performed, there may be added coverage provided through system level checks and safety application-related software.  

A safety assessment of the product is typically performed and although this addresses more than just the STL and processor, this will normally form a critical part of the assessment, and can be assisted by the information provided by Arm with the STL. The STL documentation can be used to provide evidence of the library’s systematic development. It also contributes to demonstrate its correct integration and the processor’s analysis to achieve the product’s safety goals. 

While the focus has been on the deployment of STLs for existing designs, the same principles also apply to a ground up development of a new device. In the case of a new device, there is the additional opportunity for the inclusion for further hardware measures to boost coverage. 

Autonomous Vehicles

Benefits of using Arm’s Software Test Libraries 

  • Code verified with fault injection - Code is verified using fault injection on the CPU which provides confidence and understanding of the hardware metrics achieved. The effort undertaken internally ranges from setting up fault injection environment to analyzing the results in order to steer the effort to attain maximum fault coverage. 
  • Highly optimized code with faster execution - Code is highly optimized, leveraging detailed knowledge from the CPU micro-architecture and not purely a form of testing the relevant Arm architecture. Tests can be selected based on the configuration of the CPU so that only the appropriate tests are run which helps reduce the memory required. This in turn leaves more resources available for the customer applications and simplifies the STL integration. Additionally, the compact code allows detection of faults faster which also reduces the time required to run STLs.  
  • Systematic development process - The STL is developed to be carried out against ASIL D guidance in compliance with ISO 26262 standard and SIL 3 guidance in compliance with IEC 61508 standard to guard against systematic errors. 

Software Test Library use cases

Automotive and Industrial applications examples

  • Reverse Camera – The execution of STLs during an interframe gap can identify potential faults within the CPU which could potentially lead to distortion or freezing of the image feed and relay incorrect information. In this instance there would be a warning message sent to the digital cockpit indicating that the reverse camera is not working as expected and inform the driver to look at the rear mirror whilst attempting to park instead of just relying on the rear camera.  
  • Factory safety doors – Safety doors within factories are particularly important in instances where caged robots are in use. When safety doors are opened, the robots should always be in a “safe state”, however, if a malfunction were to occur within the safety door control mechanism and a robot was in production mode, there is potential for a serious safety hazard for factory workers. Using STLs, diagnostics can be run periodically to check whether there are any faults within the CPU used in the safety door control mechanism. If a fault is detected by the STL, this can be displayed by a warning light and factory workers will be alerted.

Find out more 

For existing SoC designs requiring the ability to enable functional safety, Software Test Libraries provide an ideal asset. STLs offer key components to enable the safe execution of systems throughout a range of applications, particularly in the automotive and industrial segments. STLs offer a flexible and efficient solution to help address the critical functional safety requirements which are only set to increase as we move to a more automated future.  

Arm STLs are currently available across a range of CPUs including Cortex-A, Cortex-R and, Cortex-M products. If you have any questions about Software Test Libraries or functional safety for Arm-based devices, click here to talk to an Arm expert.

Discover more information about Arm Software Test Libraries visit our Arm.com webpage.

Discover More

Anonymous
Embedded blog
  • Arm and ETAS partner to optimize model-based development for Arm devices

    Guilherme Marshall
    Guilherme Marshall
    Arm and ETAS bring optimum runtime performance and simplified development flow for model-based development and automated code generation in safety applications
    • January 7, 2021
  • The Flexible Approach to Adding Functional Safety to a CPU

    Naresh Menon
    Naresh Menon
    Find out more about Functional Safety with SoC designs and Software Test Libraries.
    • October 22, 2020
  • The Future of Safety in the Digital Cockpit

    Daniel Bernal
    Daniel Bernal
    Developed with support from Arm, CoreAVI brings to market a comprehensive suite of graphics and compute drivers and libraries that will be certifiable for use in ISO 26262 ASIL D applications, for Arm…
    • September 30, 2020