A comprehensive guide to using Arm Software Test Libraries (STL) at Runtime with Codethink

Ensuring the reliability and integrity of embedded systems is a critical challenge in today’s fast-paced world. Arm, in collaboration with Codethink, has tackled a crucial part of this integration puzzle by incorporating Arm Software Test Libraries (STLs) into live Arm Cortex-A application processor software stacks. This effort specifically addresses the integration at Exception Level 3 (EL3) within Trusted Firmware-A (TF-A) for runtime utilization. By focusing on this aspect, developers can enhance the integrity and reliability of their systems, paving the way for more robust and efficient embedded systems.

Understanding STL Integration 

Arm STLs are a suite of software functions that are designed to provide diagnostic capabilities for Arm processors. These offer best-in-class diagnostic coverage, complementing Arm’s extensive CPU safety portfolio. The primary goal of Arm STLs is to detect permanent faults in the processor’s functional logic, ensuring the integrity and reliability of the system.

Optimized for Arm processor cores, STLs can be applied to various safety standards, including ISO26262 and IEC61508. They provide diagnostic coverage that is based on netlist ports and are designed to be non-destructive when used on a running system.

The Arm STLs are used at 2 different times in the life of the product:

1. During the hardware development phase

Arm STLs provide source code that produces a bare-metal executable linking the test library. This executable is used during a fault injection campaign, providing the necessary detection statistics to complete the FMEDA (Failure Modes, Effects, and Diagnostic Analysis) and calculate the SPFM (Single Point Fault Metric) metrics required by safety standards.

2. During the life for the final product

The Arm Cortex-A STL package provides a linkable static library that should be incorporated into the final software stack. The test library should then be called periodically during the product’s life to detect hardware faults on the silicon.

This white paper focuses on the second use case, detailing the integration of the Arm STLs into the final product’s software stack for ongoing hardware fault detection.

Arm STL on the Raspberry Pi 4

The Raspberry Pi 4, equipped with a quad-core Arm Cortex A72 CPU (ARM v8.0) 64-bit system-on-chip (SoC) running at 1.5 GHz, is a versatile platform that can benefit significantly from the integration of Cortex-A72 STL. Given its popularity and widespread use, the Raspberry Pi 4 serves as an excellent example of how STLs can be integrated into a widely available and versatile platform. Since TF-A support for the Raspberry Pi 4 is mainstream, detailing the TF-A integration on this platform is straightforward and highly relevant.

Integrating Arm STLs into a Software Stack

Codethink evaluated possible ways to integrate the Arm STLs into an open-source software stack, focusing on the Linux operating system (OS). The white paper analyzes the possibility of integration at different exception levels, considering both technical and legal aspects. Ultimately, two options are explored:

• Userspace dedicated application running Arm STLs at EL0: This approach involves a simple daemon periodically executing the STLs without direct interaction with Linux kernel code, thus avoiding licensing issues.
• Secure Monitor Call (SMC) service in TF-A to run Arm STLs at EL3: This approach provides the highest privilege and secure access, ensuring that STL functions have full access to the processor’s resources. Running tests at EL3 allows for the execution of all tests, providing the best diagnostic coverage.

Execution Time and Code Size Considerations

The execution time of the Arm STLs depends on the core frequency. At maximum frequency, all the STL tests can be executed in less than 260 microseconds, representing a 2.6% performance overhead with a diagnostic test time interval of 10 milliseconds. This minimal overhead ensures that the STLs can run efficiently without significantly impacting system performance.

The documentation of the STL mentions the code size requirement of individual tests. This integration example allows determining the complete requirement for both ROM and RAM for the integration of the STL. The library uses memory that is provided by the calling application (in this case, TF-A) in addition to its own memory. Adding the overhead for the TF-A integration, the memory footprint can be quantified, ensuring that developers can plan accordingly for their specific applications.

Integrating Arm STLs at runtime within Trusted Firmware-A (TF-A) provides a robust solution for ensuring the integrity and reliability of embedded systems. By focusing on EL3 integration, developers can achieve comprehensive diagnostic coverage and secure access to all processor resources. For more detailed technical insights, refer to the white paper.

If you are interested in exploring STL integration options for real-time Cortex-R and Cortex-M systems, see the following resource:

Download the white paper

If you have any questions about the content of this blog post, reach out to your Codethink or Arm partner manager.