Software Built-In Self-Test Controller (SBISTC)

Introduction

The Software Built-In Self-Test (SBIST) Controller implements the interface between the Software Test Library (STL), hardware and the processor. The SBIST Controller contains information about the progress of the STL, which can be used to infer the current state of the STL. The SBIST Controller is a synthesizable Arm IP equipped with a watchdog counter and memory-mapped registers. This helps the STL in trapping faults that cause the following effects:

Divergent program flows in the processor
System level lockups which cause the processor to stall
Any undue performance impacts which can potentially impact safety goals

Hardware

Registers

The SBISTC exposes the following set of memory-mapped registers per core, which facilitate control, status monitoring, and fault reporting for the STL.

Register	Description
`FCTLR<n>` (Fault Control Register)	Controls and communicates the current test status for core n.
`FPIR<n>` (Fault Partition Identifier Register)	Records the currently running partition for core n.
`FFMIR<n>` (Fault Failure Mode Identification Register)	Identifies the nature of the fault for core n.
`SIDR<n>` (SBISTC Identification Register)	Identifies the revision of the SBIST Controller for core n.
`SOR<n>` (SBISTC Observation Register)	Signals some of the errors and events that occurred during operation.

Note

In the register names above, <n> refers to a specific chunk of the SBISTC, corresponding to a physical core in the cluster.

Watchdog

The SBISTC implements a watchdog timeout counter that triggers when STL defined in FCTLR<n>.FREQ times 32 cycles have elapsed. The counter decrements only when STL updates FCTLR<n>.STATUS to a proper state. Each SBISTC chunk has its own watchdog; therefore, each core running STLs can use its own separate watchdog. The watchdog mechanism is used to detect DEADLOCK faults. These faults occur in the following scenarios:

STL code deadlocks due to hardware faults in the core.

Hardware faults in the core cause a performance drop, resulting in STL diagnostic functions executing longer than the watchdog timer has been set to.

The DEADLOCK<n> output pin will be asserted if the watchdog times out.

SBISTC chunk and Integration in Cluster

There is one SBISTC associated with each cluster in the application processor. The number of the SBISTC chunks is equal to the number of physical cores in the cluster. When the STL executes on Core N, it accesses memory-mapped registers in SBISTC chunk N. This allows programming watchdog N for a particular core. If the watchdog expires, it updates registers and therefore allows the STL to observe the faults.

Fig. 37 SBISTC Integration in AP Cluster

Test Status and Fault Reporting

The SBIST Controller outputs test status signals that represent its internal state, as listed below.

Signal	Size	Description
`DEADLOCK<n>`	1	Indicates watchdog timeout (deadlock detected) for core n.
`TESTSTATUS<n>`	4	Content of the FCTLR<n>.STATUS register field

The routing of these test status signals to the FMU (Fault Management Unit) is configured such that it asserts fault on FMU when a deadlock is detected (deadlock failure) or when a test status indicates test failure (execution failure).

Design and Framework

The SBISTC module in SCP-firmware provides support for configuring and handling of faults reported by SBISTC. This module is designed for:

Initializing the module with predefined fault configuration.
Enabling and disabling SBISTC faults.
Subscribing to notifications from the FMU module.
Handling notifications from the FMU module to confirm if an SBISTC fault is raised.
Logging the event and invoking the registered callback if an SBISTC fault is confirmed.
Providing APIs to consumers of SBISTC modules.

The SBISTC module is implemented under the automotive-specific directory hierarchy within product/automotive-rd/module/sbistc/. It follows the standard SCP-firmware module structure.

Configuration

The SBISTC module is configured with fault data specific to the platform. The fault configuration parameters include:

Field	Description
`fault_string`	Unique string identifier for the fault. It is added in debug log when the fault is confirmed.
`fmu_device_id`	Device ID of the FMU to which the fault is reported.
`fmu_node_id`	Node ID of the FMU to which the fault is reported.
`handler`	Default callback function to be invoked when the fault is confirmed.

The configuration example:

/* List of SBISTC faults */
enum {
    /* Cluster 0 SBISTC FLTS */
    FLT_SBISTC_EQ_FAIL_CORE0,
    FLT_SBISTC_DEADLCK_CORE0,
    FLT_SBISTC_EQ_FAIL_CORE1,
    FLT_SBISTC_DEADLCK_CORE1,
    FLT_SBISTC_EQ_FAIL_CORE2,
    FLT_SBISTC_DEADLCK_CORE2,
    FLT_SBISTC_EQ_FAIL_CORE3,
    FLT_SBISTC_DEADLCK_CORE3,

    /* Cluster 1 SBISTC FLTS */
    FLT_SBISTC_EQ_FAIL_CORE4,
    FLT_SBISTC_DEADLCK_CORE4,
    FLT_SBISTC_EQ_FAIL_CORE5,
    FLT_SBISTC_DEADLCK_CORE5,
    FLT_SBISTC_EQ_FAIL_CORE6,
    FLT_SBISTC_DEADLCK_CORE6,
    FLT_SBISTC_EQ_FAIL_CORE7,
    FLT_SBISTC_DEADLCK_CORE7,
    ...
    FLT_SBISTC_CNT
};

struct sbistc_fault_config {
    /*! SBISTC fault name string */
    const char *flt_name;
    /*! FMU device ID for this SBISTC fault */
    const uint16_t fmu_device_id;
    /*! FMU node ID for this SBISTC fault */
    const uint16_t fmu_node_id;
    /*! Pointer to handler function for this fault */
    void (*handler)(void);
};

struct sbistc_fault_config sbistc_faults[FLT_SBISTC_CNT + 1] = {
  [FLT_SBISTC_EQ_FAIL_CORE0] = { "SBISTC_EQ_FAIL_CORE0", FMU1, FMUNODE_4, NULL },
  [FLT_SBISTC_DEADLCK_CORE0] = { "SBISTC_DEADLCK_CORE0", FMU1, FMUNODE_5, NULL },
  [FLT_SBISTC_EQ_FAIL_CORE1] = { "SBISTC_EQ_FAIL_CORE1", FMU1, FMUNODE_6, NULL },
  [FLT_SBISTC_DEADLCK_CORE1] = { "SBISTC_DEADLCK_CORE1", FMU1, FMUNODE_7, NULL },
  [FLT_SBISTC_EQ_FAIL_CORE2] = { "SBISTC_EQ_FAIL_CORE2", FMU1, FMUNODE_8, NULL },
  ....
  [FLT_SBISTC_EQ_FAIL_CORE15] = { "SBISTC_EQ_FAIL_CORE15", FMU1, FMUNODE_46, NULL },
  [FLT_SBISTC_DEADLCK_CORE15] = { "SBISTC_DEADLCK_CORE15", FMU1, FMUNODE_47, NULL },
  [FLT_SBISTC_CNT] = { NULL, 0, 0, NULL }
};

The fault_string uniquely identifies each fault in debug logs. When an SBISTC fault is detected, this string appears in the debug output, as shown in the example below:

[SBISTC] SBISTC_EQ_FAIL_CORE0 detected (FMU dev 1, node 4)

Exported APIs

Consumers of the SBISTC module can use the following APIs to interact with SBISTC faults.

API	Description
`set_enabled()`	Enable or disable the SBISTC fault reporting.
`get_count()`	Retrieves the total count of occurrences for the specified SBISTC fault.
`set_handler()`	Sets a callback function to be invoked when the SBISTC fault is confirmed.

Testing and Validation

Unit Testing: The SBISTC module is tested on the host using the Unity framework. Refer to System Control Processor (SCP) Unit Test for more information.

Integration Testing: Integration with FMU and SSU is validated using the SCP-firmware debugger CLI. See Reproduce for details.

OEQA Automation: Automated end-to-end validation is performed using the SCP-firmware debugger CLI. See Validation for more information.