A method, apparatus, device, and storage medium for error injection verification.

Abstract

This invention discloses a method, apparatus, device, and storage medium for error injection verification. It is applied to the verification of distributed reliability, availability, and serviceability (RAS) architectures. Verification is performed through a verification platform including a concurrent error injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine. The concurrent error injection engine generates error injection stimuli, allowing for flexible customization of fault types and injection rules to adapt to diverse testing scenarios. The distributed detector collects and uploads real-time response data from various functional modules locally, ensuring comprehensive and accurate collection of abnormal behaviors. The behavior prediction engine generates expected responses, performs data comparison, and outputs reports, quickly identifying RAS response anomalies. The consistency verification and reporting engine, based on the operating mode, performs result aggregation or hardware control as needed, adapting to a layered verification architecture, perfecting the entire closed-loop verification process, and effectively improving the comprehensiveness and controllability of verification.

Description

Technical Field

[0001] This invention relates to the field of chip verification, and in particular to a method, apparatus, device, and storage medium for error injection verification. Background Technology

[0002] With the rapid development of large-scale integrated circuits such as server chips, artificial intelligence accelerators, and automotive-grade system-on-a-chip, chip functional architectures are becoming increasingly complex. Reliability, availability, and serviceability (RAS) functions are gradually adopting a distributed design approach. Error detection, anomaly handling, and fault reporting logic are distributed and deployed within various functional modules and IP units. This places higher verification requirements on the functional integrity and anomaly response coordination of the distributed RAS architecture, and urgently requires supporting and comprehensive error injection verification methods to ensure stable chip operation.

[0003] Current mainstream RAS verification mostly adopts the traditional single-point error injection method, relying on fixed stimuli to complete simple signal acquisition and shallow comparison. It only supports single-module and isolated fault scenario testing, and the overall verification architecture is flat, which is not adapted to the characteristics of distributed hardware deployment. Traditional solutions cannot achieve cross-module concurrent error injection, are difficult to reproduce real-world conditions such as multiple fault superposition and continuous anomalies, lack behavior prediction and hierarchical closed-loop verification mechanisms, and cannot comprehensively assess the collaborative processing and fault recovery capabilities of distributed RAS. The verification coverage is insufficient and the adaptability is poor. Summary of the Invention

[0004] This invention provides an error injection verification method, apparatus, device, and storage medium, which solves the technical problems of traditional verification schemes being unable to adapt to multi-module, cross-IP distributed reliability, availability, and serviceability (RAS) mechanisms, unable to simulate concurrent faults, and lacking hierarchical closed-loop verification and boundary scenario verification.

[0005] According to one aspect of the present invention, a fault injection verification method is provided, applied to the verification of distributed reliability, availability, and serviceability (RAS) architectures. The verification is performed through a verification platform including a concurrent fault injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine. The method includes: The test configuration information is obtained through a concurrent error injection engine, and error injection stimuli are generated based on the test configuration information. The distributed detector collects the actual response data of the device under test after error injection and sends the actual response data to the behavior prediction engine. The behavior prediction engine makes predictions based on error injection stimuli, generates predicted response data, compares the actual response data with the predicted response data, generates a structured comparison result report, and sends the comparison result report to the consistency verification and reporting engine. The consistency verification and reporting engine receives comparison result reports, determines the operating mode, and performs verification control according to the operating mode.

[0006] Optionally, the error injection stimulus includes an error trigger signal, injection description information, and injection synchronization information.

[0007] Optionally, the method also includes: sending error trigger signals concurrently to multiple functional modules of the device under test through a concurrent error injection engine, sending injection description information to a behavior prediction engine, and sending injection synchronization information to a consistency verification and reporting engine.

[0008] Optionally, an error triggering engine can be used to send error triggering signals concurrently to multiple functional modules of the device under test. This includes: during the execution of normal functional business flow by the device under test, multiple types of error triggering signals can be injected synchronously or asynchronously into multiple physically distributed functional modules through the concurrent error injection engine to construct a cross-functional concurrent error verification scenario.

[0009] Optionally, the actual response data of the device under test after the error injection is collected, including: collecting the hardware response signal of the device under test after the error injection; and packaging the hardware response signal into actual response data in a specified format.

[0010] Optionally, prediction is performed based on error injection stimuli to generate prediction response data, including: obtaining prediction-related information, wherein the prediction-related information includes at least one of static RAS design rules, dynamic scenario context, system global and local states, and historical and boundary conditions; performing comprehensive prediction based on injection description information and prediction-related information to deduce the global standard behavior sequence that the device under test should generate in the current error scenario, and using the global standard behavior sequence as prediction response data, wherein the global standard behavior sequence includes expected error reporting signals, interrupt types and priorities, and log recording content.

[0011] Optionally, the actual response data and the predicted response data are compared to generate a structured comparison result report, including: determining whether the actual response data and the predicted response data are consistent; if so, determining the verification result as successful and generating a successful comparison result report; otherwise, determining the verification result as unsuccessful, obtaining the difference data between the actual response data and the predicted response data, generating a difference diagnosis result based on the difference data, and generating a structured comparison result report based on the verification result and the difference diagnosis result.

[0012] Optionally, verification control is performed according to the operating mode, including: when the operating mode is active mode, the execution timing is controlled in combination with the injected synchronization information, control signals for interrupt clearing and register reset are generated and verification control is performed; when the operating mode is passive mode, the comparison result report is directly forwarded to the target location.

[0013] Optionally, the method is executed through a layered deployment verification platform, including: at the module level, configuring the consistency verification and reporting engine in active mode to verify the RAS logic within a single functional module; at the IP level, configuring the consistency verification and reporting engine in active mode to verify the distributed RAS mechanism within an IP that integrates multiple functional modules; at the system level, configuring a top-level consistency verification and reporting engine in active mode and configuring multiple lower-level consistency verification and reporting engines in passive mode, with the lower-level engines aggregating the verification results to the top-level engine to verify the system-level RAS strategy across multiple IPs.

[0014] According to another aspect of the present invention, an error injection verification apparatus is provided, the apparatus comprising: a device under test and a verification platform, the verification platform comprising a concurrent error injection engine, a distributed detector, a behavior prediction engine and a consistency verification and reporting engine; A concurrent error injection engine is used to obtain test configuration information and generate error injection stimuli based on the test configuration information. A distributed detector is used to collect the actual response data of the device under test after error injection and send the actual response data to the behavior prediction engine. The behavior prediction engine is used to make predictions based on error injection stimuli, generate predicted response data, compare the actual response data with the predicted response data, generate a structured comparison result report, and send the comparison result report to the consistency verification and reporting engine. The consistency verification and reporting engine is used to receive comparison result reports, determine the operating mode, and perform verification control according to the operating mode.

[0015] The technical solution of this invention reads the test configuration and generates corresponding error stimuli through a concurrent error injection engine, enabling flexible customization of fault types and injection rules to adapt to diverse testing scenarios. By collecting and uploading real-time response data from each functional module using a distributed detector, comprehensive and accurate collection of abnormal behavior is ensured. A behavior prediction engine generates expected responses based on error stimuli, automatically comparing measured and predicted data and outputting reports to quickly identify RAS response anomalies. A consistency verification and reporting engine switches between active and passive operating modes, performing result aggregation or hardware control as needed, adapting to a layered verification architecture, perfecting the entire closed-loop verification process, and effectively improving the comprehensiveness and controllability of verification.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of an error injection verification method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a layered deployment verification platform provided according to Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of a module-level verification scenario architecture provided according to Embodiment 2 of the present invention; Figure 4 This is a schematic diagram of an IP-level verification scenario architecture provided according to Embodiment 2 of the present invention; Figure 5 This is a schematic diagram of a system-level verification scenario architecture provided according to Embodiment 2 of the present invention; Figure 6 This is a schematic diagram of the structure of an error injection verification device according to Embodiment 4 of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device that implements an error injection verification method according to an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] Example 1 Figure 1 This document provides a flowchart of an error injection verification method according to Embodiment 1 of the present invention. This method is applied to the verification of a distributed reliability, availability, and serviceability (RAS) architecture. The verification is performed through a verification platform that includes a concurrent error injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine. Figure 1 As shown, the method includes: S110. Obtain test configuration information through the concurrent error injection engine, and generate error injection incentives based on the test configuration information.

[0022] The Reliability, Availability, and Serviceability (RAS) architecture refers to a system architecture in large-scale integrated circuits, such as server CPUs, AI accelerators, and automotive-grade Systems on a Chip (SoC), where RAS functions are physically distributed across multiple sub-modules, error detection logic is dispersed across different functional units, and collaborative processing of abnormal events is required. The verification platform is a verification environment comprised of a concurrent error injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine. It is responsible for error injection, collection, prediction, comparison, and reporting, completing automated end-to-end verification of the distributed RAS. The Concurrent Error Injection Engine (CEIE) is the core of the verification platform's stimulus generation. It can dynamically generate multi-source, cross-module, high-concurrency RAS error injection stimuli based on test configuration, injecting errors synchronously / asynchronously in normal business flows to simulate real high-pressure fault scenarios. Test configuration information refers to parameters defined by the test scenario, including the specific type, quantity, timing constraints, and weights of error injection, used to configure the concurrent error injection engine to generate error injection stimuli. Error injection stimulus refers to the specific error signal generated by the concurrent error injection engine based on the test configuration information, which can be injected into the data path of the device under test to simulate concurrent failures in a real environment.

[0023] First, the concurrent error injection engine obtains the corresponding test configuration information from the test scenario. The test configuration information is used to specify the specific type of error injection, such as error correcting code (ECC) verification failure, page fault triggered by a polluted memory line, bus transmission exception, etc.; the number of errors to be injected; and key information such as the timing constraints of error injection.

[0024] For example, the test configuration information defines the specific content used in the simulation phase, such as the type, quantity, and timing constraints of error injection. Among them, the configuration parameter Config is used to specify the specific rules of error injection, the error injection weight Weight is used to adjust the injection probability of different types of errors, and the timing constraint Constraint is used to specify the time conditions for error injection.

[0025] Specifically, the concurrent error injection engine parses the test configuration information and dynamically generates multi-source, cross-module, high-concurrency error injection stimuli according to the configuration while the system's normal business flow is running. As the driver of the verification scenario, the concurrent error injection engine can dynamically and concurrently embed multiple types and combinations of error injection stimuli into the system's normal business flow and functional operations without relying on preset isolated error scenarios. For example, in the data path of normal functional operations such as load / store, context switching, and Direct Memory Access (DMA) transfer, it synchronously or asynchronously injects RAS error events from multiple physically distributed sub-modules to simulate complex fault environments under real pressure.

[0026] Optionally, the error injection stimulus includes an error trigger signal, injection description information, and injection synchronization information.

[0027] Optionally, the method also includes: sending error trigger signals concurrently to multiple functional modules of the device under test through a concurrent error injection engine, sending injection description information to a behavior prediction engine, and sending injection synchronization information to a consistency verification and reporting engine.

[0028] The error trigger signal is a signal directly output by the CEIE to the device under test (DUT), used to actually trigger RAS error events in the DUT's data path. The injection description information is a data packet output by the CEIE to the behavior prediction engine, containing information such as the error type, error message, and target module. This injection description information serves as the baseline input for the behavior prediction engine, allowing it to deduce the correct RAS response based on the injected error scenario, system design specifications, and RAS strategy. The injection description information can be shared and transmitted via a Transaction Level Modeling (TLM) interface or a data pool. The injection synchronization information is output by the CEIE to the consistency verification and reporting engine. Using this information, the consistency verification and reporting engine can determine the precise timing and content of the error injection, enabling it to initiate interruption and cleanup operations at specific periods, such as in transient anomaly scenarios, in active mode, achieving precise coordination with the error injection.

[0029] Optionally, an error triggering engine can be used to send error triggering signals concurrently to multiple functional modules of the device under test. This includes: during the execution of normal functional business flow by the device under test, multiple types of error triggering signals can be injected synchronously or asynchronously into multiple physically distributed functional modules through the concurrent error injection engine to construct a cross-functional concurrent error verification scenario.

[0030] The device under test (DUT) refers to a distributed architecture system undergoing RAS (Reliability, Automation, and Security) functional verification, comprising multiple physically distributed functional modules. These include, for example, caches, memory controllers, interconnect networks, and CPU cores. These modules interact with each other via a bus and arbitrator. A functional module is a sub-unit within the DUT with independent functionality, such as a Master module, a Slave module, an ECC verification unit, and a state machine module. Each module integrates distributed RAS detection and response logic. The normal functional business flow is the standard operating procedure of the DUT under no-error-injection conditions, forming the foundational environment for verification. Cross-functional concurrent error verification scenarios involve simultaneously injecting different types of errors into multiple functional modules to simulate complex scenarios where multiple faults occur simultaneously in a real-world environment. For example, injecting an ECC error into the cache module while simultaneously injecting a bus transmission error into the memory controller module verifies the collaborative processing capabilities of the distributed RAS architecture.

[0031] Specifically, the concurrent error injection engine pre-parses the preset configuration parameters (Config), error injection weight (Weight), and timing constraints (Constraint) in the test scenario, and randomly generates multiple types of error trigger signals based on these parameters. For example, it generates different types of error trigger signals, such as ECC check failure signals and bus abnormal signals, and assigns them to the corresponding functional modules. The timing of error injection is determined by the configured timing constraints and is executed in parallel with the normal functional business flow of the device under test. It randomly embeds multi-source, cross-module concurrent error stimuli into the normal business flow, without needing to monitor the current business operations being performed by the system in real time, such as load / store operations, DMA transfers, context switching, etc. The error injection action is completed entirely according to the preset configuration.

[0032] Synchronous injection involves simultaneously injecting error trigger signals into multiple physically distributed functional modules during the same clock cycle of the device under test (DUT) performing normal functional operations. For example, while the CPU core is performing a load operation, an ECC error signal is injected into the cache module, and an address error signal is injected into the memory controller module, simulating a scenario where multiple faults occur concurrently at the same time. Asynchronous injection involves injecting error trigger signals into multiple physically distributed functional modules sequentially during different clock cycles of the DUT performing normal functional operations, simulating a scenario where faults occur sequentially but have cumulative effects. For example, a transmission error signal is first injected into the interconnect network module, and after several clock cycles, an ECC error signal is injected into the cache module, verifying the system's RAS (Responsive Ability Response) capability under continuous faults.

[0033] Finally, by injecting different types of error triggering signals into different types of functional modules in a synchronous or asynchronous manner, a cross-functional concurrent error verification scenario is constructed. For example, an instruction error signal is injected into the CPU core, a transmission timeout signal is injected into the DMA controller, and an interrupt loss signal is injected into the interrupt controller at the same time. This verifies the collaborative processing capability, error reporting priority, and resource allocation strategy of the distributed RAS architecture when multiple modules fail concurrently.

[0034] S120. Collect the actual response data of the device under test after error injection through a distributed detector, and send the actual response data to the behavior prediction engine.

[0035] The Distributed Error Observer (DEO), also known as the Distributed RAS Monitor, is a non-intrusive data collection unit deployed on key nodes of each module of the Device Under Test (DUT). It can collect actual response data such as error states, interrupt requests, and register values ​​in real time, and send it to the behavior prediction engine after timestamp alignment. Actual response data refers to the real behavioral data generated by the DUT after error injection, collected by the distributed detector, including error states, interrupt requests, register values, and log records.

[0036] Optionally, the actual response data of the device under test after the error injection is collected, including: collecting the hardware response signal of the device under test after the error injection; and packaging the hardware response signal into actual response data in a specified format.

[0037] Specifically, after the CEIE concurrently injects error trigger signals into multiple functional modules of the device under test (DUT), the distributed detector collects the hardware response signals generated by the DUT in real time through the acquisition interfaces deployed at key nodes of each functional module. These hardware response signals include error detection signals output by the ECC verification unit, interrupt request signals issued by the interrupt controller, state transition signals output by the state machine module, and error flag signals generated by the bus interface. Then, the distributed detector packages the collected hardware response signals according to a preset protocol format, adding metadata such as timestamps, module identifiers, and signal types, integrating the scattered hardware response signals into structured actual response data to ensure data integrity and traceability. Finally, the packaged actual response data is sent to the behavior prediction engine as input for subsequent comparison and verification.

[0038] S130. Using the behavior prediction engine, prediction is made based on the error injection stimulus, predictive response data is generated, and the actual response data and the predicted response data are compared to generate a structured comparison result report. The comparison result report is then sent to the consistency verification and reporting engine.

[0039] The Behavior Predict Engine (BPE) is the verification platform's expected generation and comparison unit. Based on error injection information and RAS specifications, it predicts the correct response the system should provide and compares the prediction results with the actual data collected by the distributed detector, generating a structured comparison report. Predicted response data refers to the expected behavior data derived by the BPE based on error injection stimuli and the system's RAS specifications, including the error signals the system should report, interruption types, and log content. The comparison report is a structured report generated by the BPE. This report is not a list of raw data but rather a verification conclusion after processing. For example, it may explicitly state "Module X_Error Y: Expected interruption A, actual no interruption, judgment failed" or "RAS check disabled, but interruption A was reported, judgment failed," and includes optional differential diagnostic information.

[0040] Optionally, prediction is performed based on error injection stimuli to generate prediction response data, including: obtaining prediction-related information, wherein the prediction-related information includes at least one of static RAS design rules, dynamic scenario context, system global and local states, and historical and boundary conditions; performing comprehensive prediction based on injection description information and prediction-related information to deduce the global standard behavior sequence that the device under test should generate in the current error scenario, and using the global standard behavior sequence as prediction response data, wherein the global standard behavior sequence includes expected error reporting signals, interrupt types and priorities, and log recording content.

[0041] The prediction-related information serves as the reference for the behavior prediction engine, including at least one of the following: static RAS design rules, dynamic scenario context, system global and local states, and historical and boundary conditions. Static RAS design rules are predefined system RAS strategies, such as error reporting priorities, interrupt handling procedures, and log recording specifications. Dynamic scenario context is the business flow information being executed by the system at the time of error injection, such as ongoing load / store operations and DMA (Direct Memory Access) transfers, used to analyze the potential impact range of the error. System global and local states are the key operating parameters of each module in the current system, such as interrupt mask status and the current value of the error counter, used to determine whether error reporting is allowed in the current state. Historical and boundary conditions are the system's previous operating records and extreme operating conditions, such as whether previous errors have been cleared and the system's maximum load threshold, used to comprehensively deduce the complete global standard behavior sequence. Predicted response data is the correct RAS response that the system should have, derived by the behavior prediction engine, presented in the form of a global standard behavior sequence. The global standard behavior sequence includes the expected error reporting signal, interrupt type and priority, and log recording content.

[0042] Specifically, the behavior prediction engine combines the injection description information and prediction-related information obtained from the concurrent error injection engine to make comprehensive predictions. Based on the system design specifications and RAS strategy, it derives the global standard behavior sequence that the device under test should generate in the current error scenario, such as which module is expected to report error signals, what the reported interrupt type and priority are, and what information the log should contain. Finally, the global standard behavior sequence is used as the predicted response data for subsequent comparison and verification with the actual response data collected by the distributed detector.

[0043] In an alternative implementation, the predicted response data can also be generated by means of reference model comparison, formal verification deduction, state machine traversal, machine learning model prediction, and pre-computed expectation table.

[0044] Optionally, the actual response data and the predicted response data are compared to generate a structured comparison result report, including: determining whether the actual response data and the predicted response data are consistent; if so, determining the verification result as successful and generating a successful comparison result report; otherwise, determining the verification result as unsuccessful, obtaining the difference data between the actual response data and the predicted response data, generating a difference diagnosis result based on the difference data, and generating a structured comparison result report based on the verification result and the difference diagnosis result.

[0045] Specifically, the behavior prediction engine receives the actual response data collected by the distributed detector and the predicted response data generated by the engine. It then compares the two data field-by-field and time-series to determine if they match. If they match perfectly, the RAS response of the device under test (DUT) in the current error scenario meets design expectations, the verification result is considered successful, and a comparison report containing only successful verification information is generated. However, if there are differences, the DUT's RAS response is abnormal, and the verification result is considered a failure. In this case, the behavior prediction engine further analyzes the differences between the actual and predicted response data, obtaining discrepancy data such as delays in error reporting signals, interrupt type errors, and missing log records. Then, the behavior prediction engine performs root cause analysis based on the discrepancy data, generating a differential diagnosis result, such as identifying a RAS logic error in a module, a timing problem in bus transmission, or an incorrect priority configuration for interrupt handling. Finally, the verification failure result and the differential diagnosis result are integrated to generate a detailed comparison report, providing clear direction for subsequent system optimization and problem remediation.

[0046] In an optional implementation, actual response data and predicted response data can also be compared using transaction-level comparison, event-level comparison, full log comparison, state snapshot comparison, and post-processing offline comparison.

[0047] S140. Receive the comparison result report through the consistency verification and reporting engine, determine the operating mode, and perform verification control according to the operating mode.

[0048] The Consistency Check & Reporting Engine (CCR) is the global control and decision-making center of the verification platform. It receives comparison result reports from the behavior prediction engine and executes verification control according to preset operating modes. Operating modes refer to the working modes of the Consistency Check & Reporting Engine, which are divided into active and passive modes to achieve different levels of closed-loop verification control. In active mode, it can proactively initiate control signals such as interrupt clearing and register reset, and collaborate with the CEIE to construct extreme scenarios, such as transient anomalies and recurring anomalies. In passive mode, it can summarize comparison results, generate a system-level structured verification summary report, or forward it to the superior test management system.

[0049] Optionally, verification control is performed according to the operating mode, including: when the operating mode is active mode, the execution timing is controlled in combination with the injected synchronization information, control signals for interrupt clearing and register reset are generated and verification control is performed; when the operating mode is passive mode, the comparison result report is directly forwarded to the target location.

[0050] Specifically, after receiving the comparison result report from the behavior prediction engine, the consistency verification and reporting engine first determines its current operating mode and then executes the corresponding verification control operations according to the mode. When the operating mode is set to active mode, the consistency verification and reporting engine combines the injection synchronization information obtained from the concurrent error injection engine to precisely control the execution timing of the control operations, ensuring that the control signals and error injection behavior are precisely coordinated at the clock cycle level. On this basis, it generates interrupt clearing signals and register reset signals for the device under test and applies these control signals to the device under test to complete the verification control of the interrupt handling process and state recovery logic. This achieves a complete closed-loop verification from error detection, reporting, response to clearing and reset, which is especially suitable for complex boundary scenario verification that requires precise timing coordination, such as instantaneous exception handling and recurring exception handling. When the operating mode is set to passive mode, the consistency verification and reporting engine does not actively generate and send control signals such as interrupt clearing and register reset, nor does it directly intervene in the operating status of the device under test. It only summarizes and formats the received comparison result reports, and then directly forwards the comparison result reports to the pre-set target location. The target location can be the upper-level consistency verification and reporting engine or the external test management system, where the upper-level unit completes further global judgment and result processing.

[0051] In addition, after completing control operations such as interrupt clearing and register reset, the device under test will simultaneously complete the abnormal state removal, error flag clearing, and fault path restoration. The verification platform will simultaneously collect the restored system operation data to confirm that the service flow has returned to the normal transmission state, forming a complete closed-loop link of error injection, abnormal reporting, fault judgment, control intervention, and state restoration. This not only verifies the error detection and reporting logic but also comprehensively assesses the system's fault self-healing and service recovery capabilities.

[0052] The technical solution of this invention reads the test configuration and generates corresponding error stimuli through a concurrent error injection engine, enabling flexible customization of fault types and injection rules to adapt to diverse testing scenarios. By collecting and uploading real-time response data from each functional module using a distributed detector, comprehensive and accurate collection of abnormal behavior is ensured. A behavior prediction engine generates expected responses based on error stimuli, automatically comparing measured and predicted data and outputting reports to quickly identify RAS response anomalies. A consistency verification and reporting engine switches between active and passive operating modes, performing result aggregation or hardware control as needed, adapting to a layered verification architecture, perfecting the entire closed-loop verification process, and effectively improving the comprehensiveness and controllability of verification.

[0053] Example 2 Figure 2This is a flowchart of a layered deployment verification platform provided in Embodiment 2 of the present invention. This embodiment adds specific procedures for the method to be executed through the layered deployment verification platform, based on Embodiment 1 described above. For example... Figure 2 As shown, the method includes: S210. At the module level, configure the consistency verification and reporting engine to active mode to verify the RAS logic within a single functional module.

[0054] It is understood that the error injection verification method in this embodiment is implemented using a layered deployment verification platform, which can adapt to the verification requirements of the full-level distributed RAS architecture, from single functional modules to complete chip systems.

[0055] Specifically, in module-level verification scenarios, the verification platform can be configured for individual functional modules, setting the consistency verification and reporting engine to active mode, and deploying corresponding concurrent error injection engines, distributed detectors, and behavior prediction engines for the module. The concurrent error injection engine injects errors into the module, the distributed detector collects RAS response information within the module, the behavior prediction engine completes prediction and comparison, and the consistency verification and reporting engine in active mode can directly initiate control operations such as interrupt clearing and register reset, thereby verifying the correctness of the RAS logic within a single functional module and the recovery capability of the state machine.

[0056] For example, Figure 3 This is a schematic diagram of a module-level verification scenario architecture provided in Embodiment 2 of the present invention. The module-level unit includes three major components: a distributed detector (DEO), a behavior prediction engine (BPE), and a consistency verification and reporting engine (CCR). The three components work together to independently complete the error injection response collection, behavior prediction comparison, and result verification of a single functional module, thereby realizing closed-loop verification of the module-level distributed RAS logic.

[0057] S220, at the IP level, configure the consistency verification and reporting engine to active mode to verify the distributed RAS mechanism within the IP that integrates multiple functional modules.

[0058] Specifically, during the IP-level verification phase, the consistency check and reporting engine is also configured in active mode. At this point, the verification object is upgraded to an IP integrating multiple functional modules, focusing on verifying the distributed RAS mechanism between these modules. For example, when both the cache module and memory controller module within the IP experience errors simultaneously, the engine simulates complex multi-module concurrent error scenarios in active mode to verify whether the error coordination, interrupt priority allocation, and resource scheduling between modules conform to preset strategies, and verifies the overall RAS response capability of the IP.

[0059] For example, Figure 4This is a schematic diagram of an IP-level verification scenario architecture provided in Embodiment 2 of the present invention. The IP-level unit internally includes two types of test units: a multi-module test unit (Multi TBU) integrating multiple distributed detectors (DEOs) and behavior prediction engines (BPEs) to adapt to concurrent verification scenarios of multiple modules within the IP; and a single-module test unit (Single TCU) configured with one DEO and BPE for single-module verification within the IP; the bottom-level consistency verification and reporting engine (CCR) summarizes the comparison results of all test units, completing cross-module collaborative verification and closed-loop control of the IP-level distributed RAS mechanism.

[0060] S230. At the system level, configure a top-level consistency verification and reporting engine in active mode and configure multiple lower-level consistency verification and reporting engines in passive mode. The lower-level engines will aggregate the verification results to the top-level engine to verify the system-level RAS policy across multiple IPs.

[0061] Specifically, during the system-level verification phase, the verification platform adopts a top-level proactive architecture combined with lower-level passive architecture. A top-level consistency verification and reporting engine is configured in proactive mode, responsible for global control and decision-making, while multiple lower-level consistency verification and reporting engines are configured in passive mode. Each lower-level engine corresponds to a specific IP in the system, and they aggregate the verification results of their respective IPs to the top-level engine. The top-level engine then verifies the system-level RAS policy across multiple IPs based on the aggregated data. For example, when different IPs simultaneously experience errors, it verifies whether the system's global error reporting mechanism, resource isolation strategy, and fault recovery process can guarantee the system's reliability and availability. The proactive top-level engine also initiates verification of extreme error scenarios across IPs, such as instantaneous multi-IP concurrent errors and repeated error injection, to ensure the effectiveness of the system-level RAS policy.

[0062] For example, Figure 5 This is a schematic diagram of a system-level verification scenario architecture provided in Embodiment 2 of the present invention. The System Unit, or system-level unit, is the highest level of the entire verification platform, containing multiple module-level units (BlockUnits), IP-level units (IP Units), and a top-level consistency verification and reporting engine (CCR). Within the module-level and IP-level units, the Distributed Detector (DEO) is responsible for collecting hardware response data, the Behavior Prediction Engine (BPE) generates theoretically expected responses and performs comparisons, and the locally configured Passive CCR only summarizes and reports the verification results of its own level. The top-level Active CCR, after receiving the results from all lower-level Passive CCRs, sends control commands to the device under test (DUT) (Chip) via a drive signal and collects the DUT's response status via a sample signal.

[0063] It is known that in the overall layered architecture, the consistency verification and reporting engine has strict hierarchical permission division. The passive mode engines configured at the module level and IP level only have the ability to receive results, summarize data and forward reports. They do not have hardware control permissions for the device under test and cannot actively issue reset or interrupt clearing commands. The active mode engine, which is the only one configured at the system level, has the highest global control permissions and manages the verification control operations of the entire chip. Through this hierarchical isolation design of active and passive modes, it is possible to achieve independent statistics on local problems and ensure the uniformity of system-level fault management, which is suitable for the hierarchical management requirements of distributed RAS architecture.

[0064] It should be noted that the hierarchical verification platform built in this embodiment has a clear hierarchical topology and fixed data interaction links. The module level, IP level, and system level form a hierarchical architecture that aggregates from top to bottom. Each level is equipped with a distributed detector, behavior prediction engine, and consistency verification and reporting engine. Each level engine undertakes corresponding verification responsibilities according to its deployment location. All verification data and comparison results generated by the lower-level verification unit are orderly aggregated and forwarded to the next higher level unit according to the preset transmission path, and finally converge to the top-level control unit of the system level. This realizes the end-to-end collaborative verification from local modules to global chips, and ensures the traceability and linkage verification of distributed RAS abnormal events across multiple levels.

[0065] It is worth noting that the Distributed Detector (DEO) and Behavior Prediction Engine (BPE) typically have a one-to-one correspondence, meaning that each DEO deployed on a critical node is connected to a dedicated BPE. This design ensures that the data collected at each error monitoring point can be independently and in real-time for behavior prediction and verification, greatly improving the parallel processing capability and response speed of verification.

[0066] The technical solution of this invention, through the layered deployment of the verification platform, sets the consistency verification and reporting engine to active mode at the module level, which can accurately and independently verify the RAS logic and fault recovery capability of a single module; at the IP level, an active verification mode is adopted, which can effectively verify the distributed RAS linkage mechanism under the collaborative work of multiple modules; at the system level, a combination architecture of top-level active engine and lower-level passive engine can be used to summarize verification data at each level, realize unified management and complete verification of cross-IP global RAS strategy, adapt to the verification requirements of different levels in a layered manner, and improve the systematicness and adaptability of the overall verification of distributed RAS.

[0067] Example 3 This embodiment verifies a RAS interrupt management scenario with complex boundaries, aiming to validate the system's ability to handle extreme timing contention scenarios. The consistency verification and reporting engine, through precise timing coordination with the cross-functional concurrent error injection engine, can dynamically configure the spatiotemporal relationship between error injection and interrupt response. Scenario 1: Handling transient anomalies (overlapping triggering and clearing).

[0068] Scenario Definition: Scenario 1 aims to verify whether the system can correctly handle the extreme timing race where the error trigger signal and the interrupt clear signal are active simultaneously within the same clock cycle. In this case, the RAS logic must be able to correctly handle the instantaneous overlap of "detection-reporting-clearing" to avoid error state loss, false alarms, or logic confusion.

[0069] The specific steps include: 1. Test Preparation: Configure the Consistency Check and Reporting Engine (CCR) test scenario, setting the error type to "Bus Parity Error" and the interrupt type to "Fatal Interrupt". Configure the core timing constraints as follows: the error trigger signal and the interrupt clear signal take effect within the same clock cycle to simulate the most extreme timing race conditions.

[0070] 2. Error Injection: The Cross-Functional Concurrent Error Injection Engine (CEIE) generates an error trigger signal according to the configuration and injects a "bus parity error" trigger signal into the system bus data path at a specified clock cycle T, and sends the injection synchronization information (including the precise injection time T) to the CCR.

[0071] 3. Timing Race Construction: Based on the injection synchronization information received from CEIE, CCR knows the precise error injection time is T. To construct the extreme scenario where triggering and clearing overlap, CCR simultaneously initiates interrupt clearing signals within the same clock cycle T. In this case, the system needs to process both the "new error detected" and "clearing instruction received" competing events simultaneously within the same clock cycle.

[0072] 4. Result Verification: The Behavior Prediction Engine (BPE) generates the expected global standard behavior sequence based on static RAS design rules, dynamic scene context, system global and local states, and historical and boundary conditions (e.g., the system is expected to correctly identify and process the clear signal within clock cycle T, correctly record newly triggered errors, and trigger interrupts normally in subsequent cycles). The Distributed Detector (DEO) collects the actual response data of the system and sends it to the BPE for field-by-field and time-series comparison.

[0073] 5. Report Generation: If the actual response data matches the predicted response data (e.g., the interrupt signal is correctly triggered in the expected period and the error information is not lost), it indicates that the system can correctly handle extreme timing races where triggering and clearing overlap, and the state is not lost. Otherwise, CCR generates a structured comparison result report, clearly pointing out specific defects such as "error state was mistakenly cleared," "interrupt signal was not triggered," or "false alarm."

[0074] Scenario 2: Handling repeated exceptions.

[0075] Scenario Definition: Scenario 2 aims to verify whether the system's error counter, state machine, and interrupt control logic can be correctly reset to their initial state after each cycle of multiple consecutive "trigger-report-clear" cycles of the same type of error, thus preparing to deal with subsequent new errors and avoiding missed reports or functional errors due to state residue.

[0076] The specific steps include: 1. Test Preparation: Configure the Consistency Verification and Reporting Engine (CCR) test scenario, setting the error type to "Bus Parity Error" and the interrupt type to "Fatal Interrupt". Configure the core verification logic as follows: the error must occur three times consecutively, and an interrupt should be triggered and cleared immediately after each error to simulate the real-world condition of continuous anomalies.

[0077] 2. Error Injection: The Cross-Functional Concurrent Error Injection Engine (CEIE) injects three "bus parity error" trigger signals into the system bus data path consecutively at specified clock cycles T1, T2, and T3, according to the configuration, and sends the injection synchronization information (including the precise time of each injection) to the CCR. To ensure that the test is on state recovery capability rather than timing race, the interval between T1, T2, and T3 can be set to be long enough (e.g., 10 clock cycles) so that the system can complete a full "trigger-report-clear-reset" process before receiving the next error.

[0078] 3. Repeated interruption and clearing: The system detected an error at T1, triggered a fatal interrupt, and logged the error information.

[0079] The system detected a second error at T2, triggered a fatal interrupt again, and logged the error information.

[0080] The system detected the third error at T3, triggered a fatal interrupt again, and logged the error information.

[0081] Based on the injection synchronization information received from CEIE, the CCR knows the precise injection time of each error. To ensure that the clearing occurs immediately after the reporting, interrupt clearing signals are initiated at T1+1, T2+1, and T3+1 respectively in the next clock cycle after each interrupt is successfully triggered. The system clears the interrupt and resets its internal state (including the error counter and status register) each time, completing all three error injections and clearings.

[0082] 4. Result Validation: The Behavior Prediction Engine (BPE) generates the expected global behavior sequence based on static RAS design rules, dynamic scene context, system global and local states, and historical and boundary conditions. The most important prediction points in this sequence include: Error Count: It is expected that after each error occurs, the corresponding error counter should increment to 1, and then reset to zero after clearing. If the count accumulates (e.g., becomes 2 or 3), the error is considered a failure.

[0083] Interrupt timing: It is expected that the interrupt signal will be triggered in the next correct clock cycle after each error occurs; the interrupt signal will be canceled in the next clock cycle after each clear.

[0084] State machine reset: It is expected that the critical state registers will return to their initial values ​​after each clear.

[0085] The Distributed Detector (DEO) collects the actual response data of the system and compares it with the BPE field by field and time by time.

[0086] 5. Report Generation: If the actual response data matches the predicted response data (e.g., the error counts all return to zero after being cleared, and the interrupt signals are cleared as expected at T1+1, T2+1, and T3+1), it indicates that the system can correctly reset and handle recurring exceptions without any residual state. Otherwise, CCR generates a structured comparison result report, clearly pointing out specific problems such as "the error counter residual value is 2", "the interrupt state was not reset in the expected clock cycle", "the critical register value was not zeroed", or "subsequent errors were missed".

[0087] The technical solution of this invention, by verifying two extreme timing competition scenarios—transient anomalies and recurring anomalies—can fully expose the potential risks of RAS interrupt management under extreme boundary conditions. It can verify the correctness of the RAS information recording and interrupt control logic in handling timing competition when error triggering and interrupt clearing occur in the same cycle, avoiding state loss or false alarms. It can also verify the system's error counting, state machine, and interrupt logic reset and response capabilities under continuous triggering of the same type of error, preventing missed alarms or functional failures due to state residue, thus providing a comprehensive and in-depth verification basis for the robustness of the system's RAS design.

[0088] Example 4 Figure 6 This is a schematic diagram of the structure of an error injection verification device provided in Embodiment 4 of the present invention. Figure 6 As shown, the device includes: a device under test 310 and a verification platform 320. The verification platform includes a concurrent error injection engine 321, a distributed detector 322, a behavior prediction engine 323, and a consistency verification and reporting engine 324. Concurrent error injection engine 321 is used to obtain test configuration information and generate error injection stimuli based on the test configuration information; The distributed detector 322 is used to collect the actual response data of the device under test after error injection and send the actual response data to the behavior prediction engine. The behavior prediction engine 323 is used to make predictions based on error injection stimuli, generate predicted response data, compare the actual response data with the predicted response data, generate a structured comparison result report, and send the comparison result report to the consistency verification and reporting engine. The consistency verification and reporting engine 324 is used to receive comparison result reports, determine the operating mode, and perform verification control according to the operating mode.

[0089] Optionally, the concurrent error injection engine 321 is also used to: concurrently send error trigger signals to multiple functional modules of the device under test, send injection description information to the behavior prediction engine, and send injection synchronization information to the consistency verification and reporting engine.

[0090] Optionally, the concurrent error injection engine 321 is specifically used to: inject multiple types of error trigger signals synchronously or asynchronously into multiple physically distributed functional modules during the normal functional business flow of the device under test, so as to construct a cross-functional concurrent error verification scenario.

[0091] Optionally, the distributed detector 322 is specifically used to: collect the hardware response signal of the device under test after error injection; and package the hardware response signal into actual response data in a specified format.

[0092] Optionally, the behavior prediction engine 323 is specifically used to: obtain prediction-related information, wherein the prediction-related information includes at least one of static RAS design rules, dynamic scenario context, system global and local states, and historical and boundary conditions; perform comprehensive prediction based on injected description information and prediction-related information to deduce the global standard behavior sequence that the device under test should generate in the current error scenario, and use the global standard behavior sequence as prediction response data, wherein the global standard behavior sequence includes expected error reporting signals, interrupt types and priorities, and log recording content.

[0093] Optionally, the behavior prediction engine 323 is specifically used to: determine whether the actual response data and the predicted response data are consistent; if so, determine that the verification result is successful and generate a comparison result report of successful verification; otherwise, determine that the verification result is unsuccessful, obtain the difference data between the actual response data and the predicted response data, generate the difference diagnosis result based on the difference data, and generate a structured comparison result report based on the verification result and the difference diagnosis result.

[0094] Optionally, the consistency verification and reporting engine 324 is specifically used to: when the running mode is active mode, combine the injected synchronization information to control the execution timing, generate control signals for interrupt clearing and register reset, and perform verification control; when the running mode is passive mode, directly forward the comparison result report to the target location.

[0095] The technical solution of this invention reads the test configuration and generates corresponding error stimuli through a concurrent error injection engine, enabling flexible customization of fault types and injection rules to adapt to diverse testing scenarios. By collecting and uploading real-time response data from each functional module using a distributed detector, comprehensive and accurate collection of abnormal behavior is ensured. A behavior prediction engine generates expected responses based on error stimuli, automatically comparing measured and predicted data and outputting reports to quickly identify RAS response anomalies. A consistency verification and reporting engine switches between active and passive operating modes, performing result aggregation or hardware control as needed, adapting to a layered verification architecture, perfecting the entire closed-loop verification process, and effectively improving the comprehensiveness and controllability of verification.

[0096] The error injection verification device provided in this embodiment of the invention can execute an error injection verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0097] Example 5 Figure 7 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0098] like Figure 7As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) or random access memory (RAM), communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. Input / output (I / O) interfaces are also connected to the bus 14.

[0099] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0100] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a fault injection verification apparatus method.

[0101] In some embodiments, a fault injection verification apparatus method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the fault injection verification apparatus method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a fault injection verification apparatus method by any other suitable means (e.g., by means of firmware).

[0102] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0103] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0104] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0105] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0106] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0107] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0108] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0109] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for verifying error injection, characterized in that, Verification applied to distributed reliability, availability, and serviceability (RAS) architectures is performed through a verification platform comprising a concurrent error injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine. The method includes: The test configuration information is obtained through the concurrent error injection engine, and error injection stimuli are generated based on the test configuration information. The actual response data of the device under test after error injection is collected by a distributed detector, and the actual response data is sent to the behavior prediction engine. The behavior prediction engine makes predictions based on the error injection stimulus, generates predicted response data, compares the actual response data with the predicted response data, generates a structured comparison result report, and sends the comparison result report to the consistency verification and reporting engine. The consistency verification and reporting engine receives the comparison result report, determines the operating mode, and performs verification control according to the operating mode.

2. The method according to claim 1, characterized in that, The error injection stimulus includes an error trigger signal, injection description information, and injection synchronization information.

3. The method according to claim 2, characterized in that, The method further includes: concurrently sending the error trigger signal to multiple functional modules of the device under test through a concurrent error injection engine, sending the injection description information to the behavior prediction engine, and sending the injection synchronization information to the consistency verification and reporting engine.

4. The method according to claim 3, characterized in that, The method of sending the error trigger signal concurrently to multiple functional modules of the device under test through the concurrent error injection engine includes: during the execution of normal functional business flow by the device under test, injecting multiple types of error trigger signals synchronously or asynchronously into multiple physically distributed functional modules through the concurrent error injection engine to construct a cross-functional concurrent error verification scenario.

5. The method according to claim 1, characterized in that, The actual response data of the device under test after the error injection is collected includes: Collect the hardware response signal of the device under test after error injection; The hardware response signals are packaged into actual response data in a specified format.

6. The method according to claim 2, characterized in that, The step of predicting based on the error injection stimulus and generating prediction response data includes: Obtain prediction-related information, wherein the prediction-related information includes at least one of static RAS design rules, dynamic scene context, system global and local states, and historical and boundary conditions; Based on the injected description information and the prediction-related information, a comprehensive prediction is made to deduce the global standard behavior sequence that the device under test should generate in the current error scenario. The global standard behavior sequence is used as the prediction response data. The global standard behavior sequence includes the expected error reporting signal, interrupt type and priority, and log recording content.

7. The method according to claim 6, characterized in that, The step of comparing the actual response data and the predicted response data to generate a structured comparison result report includes: Determine whether the actual response data and the predicted response data are consistent. If they are, determine that the verification result is successful and generate a comparison result report of successful verification. Otherwise, if the verification result is determined to be a verification failure, the difference data between the actual response data and the predicted response data is obtained, a difference diagnosis result is generated based on the difference data, and a structured comparison result report is generated based on the verification result and the difference diagnosis result.

8. The method according to claim 2, characterized in that, The execution of verification control according to the operating mode includes: When the operating mode is active mode, the execution timing is controlled by combining the injected synchronization information, generating control signals for interrupt clearing and register reset, and performing verification control. When the operating mode is passive mode, the comparison result report is directly forwarded to the target location.

9. The method according to any one of claims 1-8, characterized in that, The method is executed through a layered deployment verification platform, including: At the module level, the consistency verification and reporting engine is configured to active mode to verify the RAS logic within a single functional module. At the IP level, the consistency verification and reporting engine is configured to active mode to verify the distributed RAS mechanism within the IP, which integrates multiple functional modules. At the system level, a top-level consistency verification and reporting engine is configured in active mode, and multiple lower-level consistency verification and reporting engines are configured in passive mode. The lower-level engines aggregate the verification results to the top-level engine to verify the system-level RAS policy across multiple IPs.

10. A fault injection verification device, characterized in that, include: The device under test and the verification platform, which includes a concurrent error injection engine, a distributed detector, a behavior prediction engine, and a consistency verification and reporting engine; A concurrent error injection engine is used to obtain test configuration information and generate error injection stimuli based on the test configuration information. A distributed detector is used to collect the actual response data of the device under test after error injection, and send the actual response data to the behavior prediction engine; A behavior prediction engine is used to make predictions based on the error injection stimulus, generate predicted response data, compare the actual response data with the predicted response data, generate a structured comparison result report, and send the comparison result report to the consistency verification and reporting engine. The consistency verification and reporting engine is used to receive the comparison result report, determine the operating mode, and perform verification control according to the operating mode.

Images