A method for designing an error detection architecture for a multi-core safety-critical system

Abstract

The application provides a kind of error detection architecture design method for multi-core safety critical system, with the method of software and hardware collaborative design, including configurable microarchitecture based on RCPs supporting asynchronous thread level error detection, custom RISCV instruction set architecture and control interface provided for OS scheduling algorithm, and special check thread developed for check core;Any processor core in the architecture of the application can be configured as a main core running application threads, a check core for correctness verification and a normal computing core not participating in error detection, which allows threads running on any core to be reproduced and verified on different cores, and the verification mode can be configured as one-to-one, one-to-two or more modes to match different safety critical task scenarios.

Description

Technical Field

[0001] This invention belongs to the technical field of computer science, and particularly relates to safety-critical systems. It mainly relates to an error detection architecture design method for multi-core safety-critical systems. Background Technology

[0002] In safety-critical systems such as automotive and aerospace, the processor core is a core component ensuring system reliability and efficient operation. One of the key requirements of these systems is the ability to detect and correct potential hardware failures during task execution, ensuring system reliability and stability. Simultaneously, these systems also need to complete complex task scheduling within a limited timeframe, ensuring all tasks are completed on time to meet stringent real-time requirements. However, reliability and schedulability address different dimensions of system security, and they are typically implemented at different stages and architectural levels of processor and system development. System schedulability is generally achieved through the scheduling algorithms of the operating system (OS). To ensure system reliability, hardware-level error detection mechanisms are commonly employed. For example, the LockStep technology in ARM Cortex R series processors is a common hardware redundancy error detection scheme. This technology detects potential errors within the processor by binding two or more identical processor cores together, executing the same program, and comparing the output results at each clock cycle.

[0003] However, with the current trend of integrating multiple safety-critical tasks on shared processor cores in safety-critical systems, traditional LockStep faces significant limitations. Due to its rigid hardware design with its own core tied to the core, LockStep performs the same level of error detection on all running tasks, ignoring the actual reliability requirements of the tasks. This leads to a waste of error detection capabilities, significant area and power consumption overhead, and challenges to system schedulability. To address these issues, the industry has proposed LockStep methods that support split-lock, where Hybrid Modular Redundancy (HMR) explicitly distinguishes between the criticality and performance requirements of tasks to reconfigure hardware at runtime, thereby reducing resource consumption and providing some flexibility. However, these methods still do not escape the core-tied hardware design, meaning that the checking core must perform error checking synchronously with the main core. This synchronous error checking execution cannot be interrupted by high-priority unchecked tasks, leading to limitations on system schedulability. Meanwhile, these methods only support static error detection for predefined tasks and lack the ability to selectively detect errors based on dynamic task requirements. They cannot flexibly adjust error detection strategies according to the task load and real-time requirements during system operation, which in turn affects the scheduling performance and resource utilization efficiency of the system.

[0004] In summary, existing error detection mechanisms still suffer from significant inflexibility and scheduling conflicts in multi-core processor architectures, making it difficult to fully meet the needs of efficient multi-task scheduling while ensuring system reliability. Summary of the Invention

[0005] This invention addresses the problem that existing error detection architectures have limited flexibility and cannot simultaneously and efficiently meet system reliability and schedulability requirements. This invention introduces a more flexible hardware error detection architecture to liberate the core bound by the traditional architecture, and OS support to cooperate with flexible hardware, ultimately realizing an asynchronous, selectable, and preemptible error detection mechanism that can be performed by non-checked tasks.

[0006] This architecture proposes a fault detection architecture design method for multi-core safety-critical systems. The asynchronous detection architecture is based on register checkpoints (RCPs) and memory access fault detection. Application threads running on the main core are divided into several small check segments. These check segments can be re-executed on one or more check cores on the main core to verify the correctness of the main thread. Each check segment contains start register checkpoints (SCPs), end register checkpoints (ECPs), and instructions that need to be re-executed. Before running a check segment, the check core initializes its own architectural state to SCPs and compares its architectural state with ECPs after the check segment ends. During execution, relevant data for memory access operations, such as the addresses and data of memory access instructions like Load / Store, are recorded and forwarded in the main core for the check cores to re-execute and verify the correctness of memory accesses at runtime. If all ECPs and memory access operation data match the original execution, the main thread is proven to be correct. The basic idea behind this approach is that as long as all data related to RCPs and main thread memory access is recorded and temporarily buffered, the checking thread can be executed asynchronously on any core other than the main core. In other words, the checking core does not need to immediately start re-execution to verify the correctness of the main thread, but instead performs other tasks to improve the utilization and flexibility of the checking core.

[0007] In this architecture, any processor core can be configured as the main core for running application threads normally, a check core for correctness verification, or a normal computing core that does not participate in error detection. This allows threads running on any core to reproduce and verify on different cores. The verification mode can be configured as one-to-one, one-to-two, or more modes to match different security-critical task scenarios.

[0008] Compared to traditional pure hardware designs, the FlexStep architecture introduces an operating system (OS). All core attributes are visible to the OS, allowing it to dynamically configure core attributes and check modes based on the real-time and reliability requirements of different task loads during runtime. Furthermore, FlexStep supports preemptive execution, allowing any core to be interrupted during operation to prioritize more urgent tasks, ensuring that all tasks in the system complete before their deadlines.

[0009] To achieve the above objectives, the technical solution adopted by this invention employs a hardware-software co-design approach, including a configurable microarchitecture based on RCPs that supports asynchronous thread-level error detection, a custom RISCV instruction set architecture (ISA) and a control interface provided for the OS scheduling algorithm, as well as a dedicated inspection thread developed for the inspection core.

[0010] On the hardware side, we modified the microarchitecture of an open-source processor core called Rocket and added necessary functional units to implement asynchronous thread-level error detection. These functional units include the Checkpoint Management Unit (RCPM), the Memory Access Record Unit (MAL), and the Data Cache and Channel Unit (DBC). The RCPM manages register checkpoints and the number of instructions per check segment, providing the check core with the instruction boundaries for execution and the architectural state for updates and comparisons; the MAL tracks all memory access operations and records relevant data for correctness verification; and the DBC is used for asynchronous data buffering and establishes data channels between cores via the system interconnect bus.

[0011] On the software side, we use a customized ISA to abstract the underlying hardware and configuration methods into control flow and integrate it into the context switching function of the OS layer scheduler. This allows the OS to reconfigure the hardware at runtime to support task switching and preemption at different safety critical levels.

[0012] Beneficial effects:

[0013] 1. The FlexStep architecture proposed in this invention is a full-stack error detection architecture from the hardware layer microarchitecture to the software layer OS scheduling. Compared with traditional pure hardware design and core-bound error detection mechanisms, FlexStep achieves more flexible detection methods and more efficient system scheduling, providing a comprehensive solution for the dual requirements of reliability and real-time performance of current safety-critical systems.

[0014] 2. In terms of hardware, this architecture achieves a configurable asynchronous thread-level error detection mechanism for multi-core systems by adding additional functional units and modifying the microarchitecture, with reasonable hardware overhead. This effectively reduces the area and power consumption overhead caused by over-detection, improves hardware flexibility, and lays the foundation for flexible scheduling at the software layer.

[0015] 3. The introduction of software-layer control flow enables the system to configure hardware and schedule tasks according to different critical task requirements, significantly improving the system's schedulability compared to traditional solutions. Simultaneously, modifications to the software layer are constrained within the OS scheduler's context switching function, minimizing design intrusion into the software layer and system complexity, and providing an interface for further development of OS-layer scheduling algorithms. Attached Figure Description

[0016] Figure 1 This is a comparison chart of traditional Lockstep, HMR, and FlexStep verification methods; ((a) Traditional LockStep has a fixed configuration of main core 0 and check core 1; (b) HMR has limited flexibility in configuration and synchronous verification method; (c) FlexStep runs asynchronous, optional, and preemptive verification).

[0017] Figure 2 This is the overall diagram of the FlexStep architecture at the hardware and software levels;

[0018] Figure 3 It is a detailed execution graph of the main thread and the checking thread when broken down to the checking segment;

[0019] Figure 4 These are the modifications FlexStep makes at the OS layer: (a) integrating context switching functions for a custom ISA; (b) inspecting the core development inspection thread. Detailed Implementation

[0020] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. It should be noted that the terms "front," "rear," "left," "right," "up," and "down" used in the following description refer to directions in the accompanying drawings, and the terms "inner" and "outer" refer to directions toward or away from the geometric center of a specific component, respectively.

[0021] Figure 1This diagram compares the traditional Lockstep, HMR, and FlexStep verification methods. The Lockstep architecture requires the checking core to participate throughout the entire check process. T3 cannot be placed on core 1, which could otherwise be freed up, causing T1 to miss its deadline. Furthermore, it requires tasks that don't need to be checked to undergo checks, resulting in additional power consumption. The HMR architecture offers limited flexibility, allowing cores to execute T3 without performing T1 checks. However, its predefined fixed checks for T2 prevent the system from preempting T2 to meet T1's deadline, also causing T1 delays. The FlexStep architecture supports asynchronous, selective, and preemptive verification. During system runtime, it selects the critical segment of T2 and schedules it for asynchronous verification during the idle period of T1's execution cycle. It also allows T1 tasks that need to meet deadlines first to preempt their verification, ensuring all tasks meet real-time requirements and critical tasks are adequately checked.

[0022] a. Register Checkpoint Management (RCPM) is responsible for managing register checkpoints and instruction counts, providing execution boundaries and snapshots for verification of the core. It consists of Checkpoint Control (CPC) and Architectural State Snapshots (ASS).

[0023] Checkpoint control comprises an instruction count (Inst.Cnt) and a privilege level monitoring (Priv.Mntr) unit. For the master core, a new ECP is generated under the following conditions: a) a privilege level mode switch occurs; b) the instruction count limit (default 5000) is reached, and the instruction count for the entire segment is recorded. Throughout the checkpoint segment, the master core sequentially sends SCP, memory access information, instruction count (IC), and ECP (see...). Figure 3 (Diagram) is provided for the check core to receive. For the check core, it begins checking after applying SCP until the instruction count reaches the same as the received IC. It then uses its own architecture state to verify the ECP.

[0024] The Architecture State Snapshot (ASS) is responsible for temporarily storing register checkpoints and general architecture state to support reproducible execution and fast execution state transitions. In the main core, before sending SCPs and ECPs, the ASS temporarily stores them and organizes them into a format suitable for the checker core to receive before forwarding. In the checker core, before the check thread enters actual reproducible execution, it stores the architecture state in the ASS instead of main memory, allowing for rapid retrieval of the previously stored architecture state when the reproducible execution reaches the ECP, enabling timely return and retrieval of suspended SCPs.

[0025] b. The Memory Access Log (MAL) tracks and records memory access information for correctness checks. In the main kernel, the MAL identifies memory access instructions, records the address and data during the processor decoding phase, pipes this information to the commit phase, and packages it for delivery to the DBC upon valid commit. In the check kernel, the MAL records memory access instruction information in the same way and compares this information with that obtained from the DBC upon valid commit to check execution correctness.

[0026] c. Data Buffer and Channel (DBC) manages asynchronous data buffering and communication between cores via the system interconnect. It consists of a data buffer FIFO and the system interconnect.

[0027] The data buffer FIFO provides a place for the check core to temporarily store check segments, laying the foundation for the proposed asynchronous detection. In the master core, the data buffer can also provide space for the master core to temporarily store check segments during multi-master-single-slave access, so that only one master core accesses the slave core at a time while the other master cores temporarily store the generated check segments, thereby avoiding the conflict and arbitration issues involved when multiple master cores access a single slave core at the same time.

[0028] The system interconnect enables inter-core communication between the main core and the check cores. This is implemented as a fully interconnected MUX-DEMUX network between the data buffer FIFOs of each core. A global register exists that can be modified via custom ISA instructions to generate control signals for the MUX / DEMUX to establish connections between the main core and one or more check cores.

[0029] At the software layer (shown in the green box), FlexStep provides

[0030] d. A custom instruction set architecture (see Table 1) to support the control interface between the hardware microarchitecture and the operating system, enabling...

[0031] e. A control flow capable of performing context switching between verification and non-verification tasks and enabling more flexible scheduling.

[0032] Figure 3 This is a detailed execution graph of the main thread and the checking thread when broken down to the check segment. The legend indicates that a check segment consists of four parts: SCP (Stored Memory Access Information), recorded memory access information (including address and data), check segment instruction count, and ECP (Executable Check Pointer), arranged in the order shown in the diagram. The OS can only switch the master / slave kernel attributes, i.e., schedule the main thread and the checking thread, when entering kernel mode. The main diagram shows that the master kernel and the checking kernel enter kernel mode periodically. In the master kernel, this causes a check segment to terminate prematurely (e.g., ①); in the slave kernel, the kernel continues the checks of the previous check segment after returning to user mode until it encounters the ECP of that check segment (e.g., ②). The diagram also shows the difference in the scale of tasks and check segments, with the former composed of numerous latter segments.

[0033] Figure 4 These are modifications made by FlexStep at the OS layer, including two aspects: (a) integrating context switching functions for a custom ISA, and (b) developing an inspection thread for the inspection core.

[0034] In the FlexStep architecture, the interaction between custom software and hardware is achieved through a self-implemented RISC-V ISA extension, as detailed in Table 1. During each OS context switch—when the OS needs to schedule threads so that the main thread or a check thread is scheduled to a processor core—the modified context switch function calls custom ISA instructions to reconfigure the global registers. These global registers control the custom hardware, ensuring its behavior conforms to the core attributes required by the thread scheduled by the OS. For example, if a main thread is scheduled to a core, the function uses the `G.Configure` and `M.associate` instructions to configure the global registers, ensuring that the core's attributes are set as a master core and associated with the appropriate check core. The modified global registers control the core to behave like a master core, i.e., writing data to the interconnect instead of fetching data from the interconnect and writing it to a buffer as it would when it has slave core attributes; simultaneously, the global registers control the interconnect to establish the actual connection between the core and its associated slave core.

[0035] Table 1 contains all the custom instructions introduced for proper hardware configuration.

[0036]

[0037] Table 1

[0038] From the OS layer perspective, FlexStep abstracts the inspection process into an inspection thread, which is scheduled just like a regular thread. This requires specifically defining the content of the inspection thread. In this thread, the kernel records its original architectural state into the ASS and waits until it obtains the SCP of the first inspection segment before applying its architectural state to itself to begin the inspection.

[0039] Table 1 records all custom instructions introduced for proper hardware configuration. The first letter G indicates that the instruction applies to any attribute core, while M and C indicate that it only applies to the master core or the check core. This extended ISA is designed based on the following considerations and practical needs: knowing and configuring the attributes of each core is necessary for all cores during each context switch; the attributes of the cores may change during a context switch, so the execution of the master core and the verification of the slave cores must be paused before the switch and resumed after all core attributes are redefined; the master core needs to be associated with the corresponding check core; the slave core needs to record its own architectural state when it starts checking, apply its SCP when the check segment arrives and start execution from the PC at the beginning of the check segment, and return the comparison results during and at the end of the execution to determine the correctness of the execution.

[0040] The technical means disclosed in this invention are not limited to those disclosed in the above embodiments, but also include technical solutions composed of any combination of the above technical features.

Claims

1. A method for designing an error detection architecture for multi-core safety-critical systems, characterized in that: The approach employs a hardware-software co-design method, including a configurable microarchitecture based on RCPs supporting asynchronous thread-level error detection, a custom RISC-CV instruction set architecture and control interfaces for OS scheduling algorithms, and a dedicated inspection thread developed for the inspection core; specifically... Includes the following steps Step 1: Microarchitectural modifications were made to the open-source processor core Rocket, and necessary functional units were added to implement asynchronous thread-level error detection. These functional units include the Checkpoint Management Unit (RCPM), the Memory Access Record Unit (MAL), and the Data Cache and Channel Unit (DBC). The MAL tracks all memory access operations and records relevant data for correctness verification. The DBC is used for asynchronous data buffering and establishes data channels between cores through the system interconnect bus. Step 2: A customized ISA is used to abstract the underlying hardware and configuration methods into control flow and integrate it into the context switching function of the OS layer scheduler. This allows the OS to reconfigure the hardware at runtime to support task switching and preemption at different security critical levels. In Step 1, the Checkpoint Management Unit (RCPM) is used to manage register checkpoints and the number of instructions in each check segment, providing the check core with the instruction boundaries for operation and the architecture state for updating and comparison. It consists of Checkpoint Control CPC and Architecture State Snapshot (ASS). The Checkpoint Control CPC includes the Instruction Count Inst.Cnt and Privilege Level Monitoring Priv.Mntr units. For the main core, a new ECP is generated under the following conditions: a) a privilege level mode switch occurs; b) the instruction count limit is reached, and the number of instructions in the entire segment is recorded. Throughout the inspection phase, the main core sequentially sends SCP, memory access information, instruction counter IC, and ECP to the inspection core for reception. For the checker core, it begins checking after applying the SCP until the instruction count reaches the same as the received IC; then it uses its own architecture state to verify the ECP; the architecture state snapshot ASS is responsible for temporarily storing register checkpoints and general architecture state to support reproducible execution and fast execution state switching; in the main core, before sending the SCP and ECP, the ASS temporarily stores them and organizes them into a format suitable for the checker core to receive before forwarding; in the checker core, before the check thread enters the actual reproducible execution, it stores the architecture state in the ASS, so that when the reproducible execution reaches the ECP, the previously stored architecture state can be quickly retrieved, so as to return and retrieve the suspended SCP in time; The Memory Access Log (MAL) tracks and records memory access information for correctness checks. In the main core, the MAL identifies memory access instructions, records the address and data during the processor decoding stage, transmits it along the pipeline to the commit stage, and packages it for the DBC when the commit is valid. In the check core, the MAL records memory access instruction-related information in the same way and compares the information with that obtained from the DBC when a valid commit is made to check the correctness of the execution. The data buffer and channel DBC manages asynchronous data buffering and communication between cores through the system interconnect. It consists of a data buffer FIFO and a system interconnect; in the master core, the data buffer provides space for temporary check segments to be stored in the master core when multiple master cores access the slave core, so that only one master core can access the slave core at a time while other master cores temporarily store the generated check segments; the system interconnect realizes inter-core communication between the master core and the check core; it is implemented as a fully connected MUX-DEMUX network between the data buffer FIFOs of each core. There exists a global register that can be modified via custom ISA instructions to generate control signals for MUX / DEMUX to establish connections between the main core and one or more check cores.

2. The error detection architecture design method for a multi-core safety-critical system according to claim 1, characterized in that: Step 2 specifically includes Step 21: FlexStep provides a custom instruction set architecture to support the control interface between the hardware microarchitecture and the operating system, enabling a control flow that can perform context switching and more flexible scheduling between verification and non-verification tasks; Step 22: The modifications made by FlexStep at the OS layer include two aspects: (a) integrating the context switching function of the custom ISA, and (b) developing the inspection thread for the inspection core; the interaction between custom software and hardware in the FlexStep architecture is achieved through a self-implemented RISC-V ISA extension.

Images