A communication module verification method and system based on UVM

Abstract

The application discloses a communication module verification method and system based on UVM, and belongs to the technical field of track signals, and the method comprises the following steps: calling a pre-defined test excitation sequence, and synchronously applying the test excitation sequence to multiple devices under test and a reference model; the reference model is based on a preset communication protocol specification and cross-checking logic, simulates and processes the received test excitation sequence, and generates expected response data; the multiple devices under test are based on respective communication modules and cross-checking logic, perform parallel processing on the received test excitation sequence, and respectively generate actual response data; the expected response data and the actual response data of each device under test are subjected to multiple comparison and analysis, and it is determined whether verification is passed according to a comparison result. Through a master-slave overlapping environment and a mixed test strategy, especially directional coverage of an abnormal path of a state machine, 100% of code lines and branch coverage is realized, which is crucial for a safety-critical system.

Description

Technical Field

[0001] This invention belongs to the field of track signal technology, and specifically relates to a UVM-based communication module verification method and system. Background Technology

[0002] The train operation control system is the core of ensuring railway transportation safety. Its main control board is responsible for executing key logic functions. The main control board communicates data internally through SBP (Serial Bus Protocol). The correctness of this communication module is directly related to the safety of the entire system.

[0003] As functional complexity increases, traditional FPGA (Field-Programmable Gate Array) verification methods, such as direct test vectors and manual inspection, become inefficient when dealing with complex communication protocols, and struggle to cover vast state spaces and complex interaction scenarios. Existing verification methods are also inadequate for effectively verifying systems with redundant architectures and security mechanisms, especially in abnormal scenarios such as simulating concurrent operations, instantaneous signal differences, and permanent faults. Conventional random testing cannot reliably and repeatedly cover abnormal transition paths and specific safety-critical paths in state machines, resulting in insufficient verification completeness and posing risks to safety-critical systems. Furthermore, verification platforms have low reusability and automation, cannot quickly respond to design iterations, and have long verification cycles.

[0004] As an industry standard, UVM (Universal Verification Methodology) provides a reusable, coverage-driven verification framework. However, how to efficiently apply it to the verification of the unique redundant architecture and safety mechanisms of train operation control systems remains an urgent problem to be solved. Summary of the Invention

[0005] To address the above problems, this invention provides a UVM-based communication module verification method, the method comprising: A predefined test stimulus sequence is invoked and synchronously applied to multiple devices under test and a reference model. The reference model, based on a preset communication protocol specification and cross-validation logic, simulates the received test stimulus sequence to generate expected response data. The multiple devices under test (DUTs) process the received test stimulus sequences in parallel based on their respective communication modules and cross-validation logic, and generate actual response data respectively. The expected response data is compared and analyzed with the actual response data of each device under test, and the verification is determined based on the comparison results.

[0006] Furthermore, the plurality of devices under test (DUTs) includes at least a master DUT and a slave DUT, and the verification environment configured for the master DUT and the slave DUTs includes: The configuration includes a verification environment for both master and slave devices; Establish a first communication link between the master terminal of the communication protocol of the master device under test and the slave terminal of the communication protocol of the slave device, and a second communication link between the master terminal of the communication protocol of the slave device under test and the slave terminal of the communication protocol of the master and slave devices. A test stimulus sequence is applied to the master-slave device and the slave device; Verify whether the responses of the master and slave devices under test to the test stimulus meet expectations.

[0007] Furthermore, the reference model simulates the received test stimulus sequence based on a preset communication protocol specification to generate expected response data, including: Determine the type of the received test stimulus sequence and execute the corresponding protocol processing operation; If the test stimulus sequence is determined to be a data write request, a virtual memory update operation is performed to store the write data at a specified address in the virtual memory and generate expected communication response data containing write confirmation. If the test stimulus sequence is determined to be a data read request, a virtual memory read operation is performed to retrieve the read data from the specified address of the virtual memory and generate expected communication response data containing the read data.

[0008] Furthermore, the reference model simulates the received test stimulus sequence based on cross-validation logic to generate expected response data, including: Virtual data of another device under test is generated based on the test scenario configuration parameters; The received test stimulus sequence is compared with the virtual data, and the expected security status data is generated based on the comparison results.

[0009] Furthermore, the method also includes a verification step for the erroneous injection signal, wherein the verification of the erroneous injection signal includes: Construct a directional test sequence that includes information on error injection time and error injection point, and inject a preset error signal into the error injection point at the error injection time; The reference model is based on a preset communication protocol specification and cross-validation logic, and generates expected response data according to the error signal instruction; The device under test associated with the error injection point generates actual response data based on the error signal instruction using a communication module and cross-validation logic. Compare the expected response data with the actual response data, and determine whether the error injection verification passes based on the comparison results.

[0010] Furthermore, the predefined test stimulus sequence includes a random test stimulus sequence, which includes a communication address field, a data length field, a baud rate field, and an error enable field. Whether the random test verification is passed is determined based on the random test stimulus sequence.

[0011] Furthermore, the random test verification also includes: During the random test verification process, test coverage data is collected in real time. The generation strategy for random test stimulus sequences is dynamically adjusted based on the coverage data. Continue performing random test verification using the adjusted random test stimulus sequence.

[0012] Furthermore, the predefined test stimulus sequence includes a test stimulus sequence containing a callback object, wherein the callback object includes a callback function and a callback point; The callback function is invoked based on the callback point, and an exception verification is performed based on the exception signal injected into the callback function.

[0013] Furthermore, the method also includes: Identify and locate the target position of the stub code to be inserted in the source code of the device under test; Generate stub code snippets for modifying internal signals or variables based on test requirements; The stub code snippet is inserted into the target position to generate the modified simulation code; Run the simulation code after inserting the stub code to create test conditions and perform simulation verification.

[0014] The present invention also provides a UVM-based communication module verification system, the system comprising a reference model, a master agent, slave agents, multiple devices under test, and a scoring board; The main agent is configured to synchronously apply the invoked test stimulus sequence to multiple devices under test and reference models; The reference model is configured to simulate the received test stimulus sequence based on a preset communication protocol specification and cross-validation logic to generate expected response data. Multiple devices under test are configured to process the received test stimulus sequence in parallel based on their respective communication modules and cross-validation logic, and generate actual response data respectively. The agent is configured to receive actual response data from the plurality of devices under test. The scoring board is configured to receive actual response data sent from the agent and expected response data sent from the reference model, and to perform multiple comparison analyses between the expected response data and the actual response data of each device under test, and determine whether the verification passes based on the comparison results.

[0015] Compared with the prior art, the present invention has the following advantages: The UVM-based communication module verification method and system of this invention achieves 100% code line and branch coverage through a master-slave overlapping environment and hybrid testing strategies, particularly targeted coverage of abnormal state machine paths. This is difficult to achieve with traditional methods and is crucial for safety-critical systems. Conventional platforms struggle to effectively simulate the interaction and faults of dual FPGAs. The master-slave overlapping environment of this invention can realistically simulate concurrent scenarios and supports precise error injection, thereby deeply verifying security mechanisms such as "cross-selecting two" and providing stronger verification capabilities for redundant architectures and security mechanisms. The random testing in the hybrid strategy is highly automated and explores a wide state space, while the targeted testing directly addresses key issues, avoiding the inefficiency of blind random testing. Combined with automated processes, the verification cycle is significantly shortened. The UVM-based platform architecture itself has good reusability. The design concept of the master-slave overlapping environment can be easily migrated to the verification of other complex systems with multi-node communication, offering good reusability and scalability.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are 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 A schematic diagram of the UVM-based communication module verification method according to an embodiment of the present invention is shown; Figure 2 A schematic diagram of the UVM simulation test structure in an embodiment of the present invention is shown; Figure 3 A schematic diagram of an FPGA master-slave communication test connection in an embodiment of the present invention is shown. Detailed Implementation

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

[0020] This invention provides a UVM-based verification system and method for the SBP communication module of a train control main board. Its core lies in a hierarchical verification platform and a hybrid verification strategy, particularly innovative designs for redundant architectures and full state machine coverage. The aim is to provide a highly automated and comprehensive communication module verification method. By constructing a hierarchical UVM verification platform and combining it with a hybrid verification strategy, efficient and automated verification of the SBP communication module is achieved. It should be noted that this invention simultaneously instantiates multiple FPGAs and their communication counterparts on the main control board, and simulates the structure of a real communication link through signal interconnection. This enables realistic simulation of concurrent scenarios and supports precise error injection, thereby deeply verifying security mechanisms such as "cross-cutting". Through UVM callback and code stubbing techniques, 100% coverage of all paths in the state machine (including normally unreachable abnormal jump paths) is achieved, greatly improving the depth and robustness of verification. Finally, 100% code line coverage and branch coverage are achieved in a simulation environment, comprehensively verifying the preset functional points and significantly improving verification efficiency and completeness.

[0021] Figure 1 This diagram illustrates a flow chart of a UVM-based communication module verification method according to an embodiment of the present invention. Figure 1 The method includes: invoking a predefined test stimulus sequence and synchronously applying the test stimulus sequence to multiple devices under test (DUTs) and a reference model; the reference model, based on a preset communication protocol specification and cross-validation logic, simulating the received test stimulus sequence to generate expected response data; the multiple DUTs, based on their respective communication modules and cross-validation logic, processing the received test stimulus sequence in parallel to generate actual response data respectively; and performing multiple comparison analyses between the expected response data and the actual response data of each DUT, determining whether the verification passes based on the comparison results.

[0022] In this embodiment of the invention, the verification of the communication module not only instantiates multiple devices under test (DUTs) but also instantiates the counterpart models that communicate with them. Specifically, it includes configuring a verification environment that includes multiple slave devices; establishing communication links between the multiple DUTs and the multiple slave devices; applying a test stimulus sequence to the multiple slave devices; and verifying whether the responses of the multiple DUTs to the test stimuli meet expectations.

[0023] In this embodiment of the invention, the reference model simulates the received test stimulus sequence based on a preset communication protocol specification to generate expected response data, including: determining the type of the received test stimulus sequence and performing the corresponding protocol processing operation; if the test stimulus sequence is determined to be a data write request, then a virtual memory update operation is performed to store the write data in a specified address of the virtual memory, generating expected communication response data containing write confirmation; if the test stimulus sequence is determined to be a data read request, then a virtual memory read operation is performed to retrieve the read data from the specified address of the virtual memory, generating expected communication response data containing the read data.

[0024] The reference model, acting as an ideal communication peer, parses input transactions according to the SBP protocol: if the transaction is a data write, the model updates its internal virtual memory; if it is a read, it retrieves the data from the virtual memory. Subsequently, strictly following the protocol format, it generates the corresponding expected communication response data (such as acknowledgment frames or readback data). In this embodiment of the invention, the correctness of the function is verified through the SBP-based protocol specification.

[0025] In this embodiment of the invention, the reference model simulates the received test stimulus sequence based on cross-validation logic to generate expected response data, including: generating virtual data of another device under test according to test scenario configuration parameters; comparing the received test stimulus sequence with the virtual data; and generating expected safety status data based on the comparison result.

[0026] Specifically, the reference model uses a "cross-validation" logic algorithm to process the received test stimulus sequence. To verify the security mechanism, the reference model also simulates the cross-validation process of a dual FPGA redundancy architecture, which is processed through data synchronization simulation and security state prediction.

[0027] Data synchronization simulation: The reference model generates a virtual Mate data representing data from another FPGA system for comparison, based on the current test scenario (normal or preset fault). Security status prediction: Within the reference model, the received input transactions (representing the local data) are compared for consistency with the generated virtual Mate data.

[0028] If they match, the prediction system should be in a safe state (SAFE).

[0029] If there is a discrepancy (simulating a "take two" fault), the system is predicted to enter a fault state (FAULT) and trigger the corresponding error flag.

[0030] In this embodiment of the invention, the expected security status data is output through "cross-tabulation" and, after simulation processing, the reference model sends the calculated expected communication response data and the expected security status data together to the scoring board as the sole correct benchmark for comparison with the actual output of the DUT. By integrating the protocol stack and security logic through data synchronization simulation and security status prediction, it can simultaneously predict the functional output and security status of the DUT, which is the core of achieving comprehensive and automated verification of complex security-critical systems.

[0031] Optionally, this embodiment of the invention also shows a schematic diagram of a master-slave communication test connection taking a dual-system FPGA redundancy system as an example. Figure 3 This diagram illustrates a test connection diagram for FPGA master-slave communication in an embodiment of the present invention. Figure 3 In this context, a dual-system FPGA redundancy system is used as an example. Figure 1 In this environment, the DUT (Device Under Test) is simultaneously and coordinately applied to the corresponding input ports of FPGA M and FPGA N by the driver generated by the master agent. The signals captured by the slave agent's monitor originate from the complex output networks of FPGA M and FPGA N, including external communication outputs and mutual status signals. This environment not only instantiates the DUTs of the master FPGA (M) and slave FPGA (N) included in the master, but also instantiates the peer / slave models (M_slave, N_slave) that communicate with them. The configuration includes a verification environment with master, slave, and slave devices; the establishment of a first communication link between the master communication protocol of the master DUT and the slave communication protocol of the slave device, and a second communication link between the master communication protocol of the slave DUT and the slave communication protocol of the master and slave devices; the application of test stimulus sequences to the master, slave, and slave devices; and the verification of whether the responses of the master and slave DUTs to the test stimuli meet expectations.

[0032] Specifically, in this embodiment of the invention, the SBP master terminal of FPGA M is connected to the SBP slave terminal of FPGA N_slave, and the SBP master terminal of FPGA N is connected to the SBP slave terminal of FPGA M_slave, simulating a real inter-board communication link. In this environment, a concurrent scenario where two FPGAs work simultaneously can be simulated. Through virtual sequence coordination, M and N can initiate communication simultaneously, verifying the system's behavior under real load. Figure 3 In this context, SELF_MO indicates sending data to the slave end, SELF_SCK generates and outputs a clock signal, SELF_SO indicates receiving data, MATE_MO indicates inputting the MO signal of the SBP link, MATE_SCK indicates inputting the clock signal of the SBP link, and MATE_SO indicates inputting the SI signal (signal integrity) of the SBP link.

[0033] Figure 2 A schematic diagram of the UVM simulation test structure in an embodiment of the present invention is shown. Figure 2 In this invention, the UVM simulation test structure includes a reference model, an in-agent, an out-agent, multiple devices under test (DUTs), and a scoreboard. In this embodiment, the in-agent is communicatively connected to the reference model and the multiple DUTs, and the out-agents are communicatively connected to the multiple DUTs and the scoreboard. The communication connection between the reference model and the scoreboard forms a closed loop. It should be noted that in this embodiment, the in-agent includes a driver and a monitor, and the out-agent includes an omonitor.

[0034] In this embodiment, the configuration functions of each subsystem in the UVM simulation test structure are also described. A test stimulus sequence is invoked to generate coordinated, concurrent test scenarios and control the behavior of multiple agents. The master agent is configured to synchronously apply the invoked test stimulus sequence to the input interfaces of multiple devices under test (DUTs) and the reference model, and monitor the input signals of these DUTs and the reference model through a monitor. The slave agent is configured to receive the actual response data of the multiple DUTs; specifically, the slave agent monitors the output signals of the multiple DUTs through a monitor. The reference model is a software model consistent with the DUT design specifications, receiving the same inputs as the DUT, predicting the correct output of the DUT through an algorithm, and is configured based on a preset communication protocol specification and... The cross-validation logic simulates the received test stimulus sequence to generate expected response data. Multiple devices under test (DUTs) are configured to process the received test stimulus sequence in parallel based on their respective communication modules and cross-validation logic, generating actual response data respectively. The scoring board is configured to receive the actual response data sent from the agent and the expected response data sent from the reference model, and perform multiple comparison analyses between the expected response data and the actual response data of each DUT. Based on the comparison results, it determines whether the verification passes. Specifically, the scoring board compares and verifies the expected output from the reference model and the actual output of the DUT captured from the agent to achieve automated result determination. The comparison content includes data content, packet order, and timing attributes. In this embodiment of the invention, the content of the comparison is not limited.

[0035] In this embodiment of the invention, the workflow of the hierarchical UVM verification platform includes: At the start of verification, a specific stimulus sequence is invoked by the test case. The stimulus sequence applies formatted transactions (such as SBP packets) to the DUT through the main agent's driver. Simultaneously, the reference model receives the same input transactions and calculates the expected output data based on the SBP protocol specification and "cross-tabulation" logic. The actual output generated by the DUT is captured by the agent's monitor and sent to the scoring board. The scoring board simultaneously receives the expected output from the reference model and performs real-time or subsequent comparison. If they match, the test passes; otherwise, an error is reported.

[0036] In this embodiment of the invention, a specific example is used to illustrate the working process of the hierarchical UVM verification platform. In this example, a specific SBP communication verification is taken on a dual-system FPGA redundancy system, and combined with a specific "single SBP data write" test case, the flow process of data, algorithms and verification in each component of the UVM platform is explained in detail: S11: Create specific test scenarios At the start of the test, a test case named test_single_write is launched. The test case creates and runs an stimulus sequence named sbp_write_seq. The sequence is configured to generate a data transaction that conforms to the SBP protocol. In this embodiment of the invention, the data transaction includes a data object containing all communication parameters.

[0037] In this embodiment of the invention, a specific data example is used for illustration. `sbp_write_seq` generates a specific transaction object `tr` through built-in random constraints. The transaction object `tr` includes: tr.addr = 32'h0000_1000; / / Address of the target register to be written tr.data = 32'hA55A_F00F; / / 4 bytes of data to be written tr.crc_type=CRC16; / / Use CRC16 checksum tr.is_safe_operation=1; / / Indicates that this is a safety-critical operation. It should be noted that in this embodiment, the transaction object tr is abstract data in the step of creating a specific test scenario, and is not an actual circuit signal.

[0038] S12: Drive and Input In this step, sbp_write_seq hands the transaction tr to the main agent's driver, and through the driver's protocol conversion and timing-driven core algorithms, the called test stimulus sequence is synchronously applied to multiple devices under test and reference models.

[0039] The core algorithm of the driver is configured as follows: 1. Transaction parsing: Read fields such as addr, data, and crc_type from tr; 2. Frame assembly calculation: According to the SBP protocol specification, calculate the frame header, address segment, and data segment, and call the CRC (Cyclic Redundancy Check) calculation function according to crc_type to generate a check code, and assemble them into a complete byte stream byte_stream[]. 3. Signal-driven: Within one analog clock cycle, the driver decomposes each byte in byte_stream[] into bit signals according to the physical layer timing of SBP (e.g., start bit, 8-bit data, stop bit), and drives them to the input pins of the DUT (e.g., the sbp_tx signal line). At the same time, it generates corresponding control signals (e.g., sbp_tx_en).

[0040] The driver is also configured to synchronously input the excitation sequence into the reference model. Specifically, while the driver converts tr into a physical signal, it also sends a copy of tr to the reference model through the analysis port (analysis_port), so that the reference model obtains an input information source that is completely consistent with the DUT.

[0041] S13: Calculation of Expected Output After receiving the input transaction tr, the reference model begins executing its core algorithm to predict the expected behavior of the DUT. In this embodiment of the invention, the reference model predicts the expected behavior of the DUT through protocol response simulation and "cross-tabulation" simulation algorithms. In this step, the reference model predicts the expected behavior of the DUT through protocol response simulation and "cross-tabulation" simulation.

[0042] 1. Protocol Response Simulation: As the counterparty in communication, the reference model simulates a normal SBP slave. Upon receiving a write request, it updates its internally maintained address mapping memory (simulated register), writing data = A55A_F00F to address addr = 0000_1000, generating a "write successful" response transaction exp_rsp_tr.

[0043] 2. "Cross-checking" simulation: The reference model maintains virtual states for two FPGAs (M-system and N-system). Upon receiving the test stimulus sequence, the reference model performs the following judgment: If the M-system sends tr, and the N-system should also send the same data simultaneously (in the ideal case of dual-system synchronization), then the "cross-checking modules" of both systems compare these two data streams. If the comparison result is consistent, the reference model predicts that the safety status register exp_safety_status is equal to SAFE (safe).

[0044] After the prediction is completed, the reference model sends the predicted response transaction exp_rsp_tr and the predicted safety status exp_safety_status to the scoreboard.

[0045] S14: Actual Output Capture After receiving the physical signal applied by the driver, the DUT's internal SBP module and cross-checking logic begin to operate, ultimately generating an actual response signal on the output pin. The agent's monitor continuously listens to the DUT's output pins (such as sbp_rx, safety_status).

[0046] The monitor parses and restores the monitored signal waveforms into transaction-level data according to the SBP protocol, forming a response transaction act_rsp_tr representing the actual output of the DUT and the actual safety status act_safety_status, and sends it to the scoring board.

[0047] S15: Automated Comparison and Verification In this embodiment of the invention, the scoreboard receives the expected results from the reference model and the actual results from the monitor, and performs automatic comparison. The comparison logic includes data content comparison, protocol correctness comparison, and security mechanism verification.

[0048] Optionally, data content comparison includes checking whether act_rsp_tr.data is equal to exp_rsp_tr.data. For example, checking whether the read-back data is A55A_F00F; protocol correctness comparison checks whether act_rsp_tr.status is "successful" (OK), consistent with expectations; security mechanism verification includes strictly comparing whether act_safety_status is equal to exp_safety_status to determine whether the actual security status generated by the DUT is SAFE.

[0049] If all the above comparison items match, the scoreboard records the test as passed. If any item does not match (for example, the actual safety status is FAULT), the scoreboard will immediately report a detailed error (UVM ERROR), indicating which signal, when, what the expected value was, and what the actual value was, thereby achieving accurate fault location.

[0050] Through a specific SBP communication verification example, the UVM platform of this invention decomposes a complex communication verification into a closed-loop automated process of "generating abstract data > converting it into a specific signal > DUT processing > capturing the output and converting it back to abstract data > performing multi-dimensional automatic comparison with the model prediction results". Among them, the simulation of the "cross-two" security algorithm by the reference model and the automated verification of the security status by the scoreboard jointly ensure the testability and verification completeness of the security-critical logic.

[0051] In this embodiment of the invention, a specific example is provided for a detailed description of a concurrent scenario simulating the simultaneous operation of two FPGAs: S21: Design a "Concurrent Operation Instruction Set" The invention formulates collaborative instructions to simultaneously generate and coordinate test actions for FPGA M and FPGA N. An example of generating concurrent instructions in this embodiment is as follows: Instruction A (to FPGA M): "At the 1st microsecond, send data packet X to channel 1." Instruction B (to FPGA N): "Also in the 1st microsecond, send data packet Y to channel 2." Instruction C (to FPGA M): "At the 5th microsecond, read the data that FPGA N just sent from channel 2." By generating precise timestamps on instructions A, B, and C, it is ensured that the actions of FPGA M and FPGA N occur precisely "simultaneously" or "sequentially" on the simulation timeline.

[0052] S22: Execute instructions to drive the actual hardware. The main agent's driver receives the instruction sent by S21 and translates it into a series of specific, timed high and low level changes on the FPGA pins that conform to the SBP communication protocol.

[0053] The driver synchronously applies the translated signals to FPGA M and FPGA N, driving the signals of FPGA M to their input ports and the signals of FPGA N to their input ports. FPGA M_slave and FPGA N_slave receive signals from each other's real FPGAs and provide actual responses conforming to the protocol, thus constructing a closed, bidirectional communication loop.

[0054] S23: Monitoring and Judgment The reference model, based on the same instruction set, SBP protocol, and system design specifications, calculates the state of the dual FPGA redundancy architecture under concurrent operation.

[0055] The states under concurrent operations can include: Bus load status when FPGA M and FPGA N send data simultaneously; When FPGA M reads the data just sent by FPGA N, is the reading correct? Under concurrent operation, the cross-verification signal status between FPGA M and FPGA N is checked to determine whether it is in a safe state.

[0056] The monitor captures and records every output signal of FPGA M and FPGA N while they are running; the scoreboard performs a rigorous automatic comparison between the expected response data and the actual response data, which can verify whether there will be problems if the two FPGAs access a shared resource at the same time; whether the system functions correctly under full load or overload concurrent communication; and whether the "cross-tabulation" mechanism can still work accurately and in real time in complex concurrent data streams.

[0057] In this embodiment of the invention, the UVM-based communication module verification method further includes a verification step for error injection signals. The verification of the error injection signals includes: constructing a directional test sequence containing information on the error injection time and error injection point; injecting a preset error signal into the error injection point at the error injection time; the reference model generating expected response data based on a preset communication protocol specification and cross-validation logic according to the error signal instruction; the device under test associated with the error injection point generating actual response data based on the communication module and cross-validation logic according to the error signal instruction; comparing the expected response data and the actual response data, and determining whether the error injection verification has passed based on the comparison result.

[0058] In this embodiment of the invention, errors are injected into the interconnect signals in a targeted manner, for example, simulating "inconsistency between two values" (i.e., a momentary difference in the cross-validation signals generated by M and N). The robustness of the security mechanism is verified by observing whether the DUT can correctly detect the difference and trigger a preset security response (such as an alarm or entering a secure state). A specific embodiment is also provided to illustrate the specific process of error injection verification: S31: Configure test scenarios Create a targeted test sequence, test_mate_mismatch, in which the following parameters are precisely controlled: Injection time: Simulation time t = 1000ns.

[0059] Injection point: signal Mate_M_to_N ( Figure 2 (The cross-check data line from FPGA M to FPGA N).

[0060] Error type: The signal value was changed from the correct value 32'hA55A_5AA5 to the error value 32'hA55A_5AA4 (only the least significant bit is flipped).

[0061] Duration: The error value is held for 2 clock cycles (simulating a transient fault).

[0062] Meanwhile, the sequence control FPGAs M and N perform normal SBP communication tasks as background load.

[0063] S32: Execution Simulation and Signal Driving Simulation begins, and the test_mate_mismatch sequence drives normal SBP communication transactions to the ports of FPGA M and FPGA N through the main agent's driver; When the simulation time reaches t = 1000ns, the driver performs the following key operations according to the sequence configuration: Continue to maintain normal operation of all other signals; Force a change in the drive value connected to the Mate_M_to_N signal line from 32'hA55A_5AA5 to 32'hA55A_5AA4.

[0064] The cross-tab comparator inside FPGA N samples two values ​​simultaneously on the first clock edge after t=1000ns: a local value (32'hA55A_5AA5) generated by FPGA N's own logic and a Mate value (32'hA55A_5AA4) injected with an error, received from the Mate_M_to_N line. The comparator immediately detects this sampling inconsistency.

[0065] S33: Calculate the expected security response Simultaneously with the driver injection error, the reference model receives the same "injection error" instruction and performs safety logic calculations according to the design specifications: Fault detection: The reference model indicates that a data inconsistency occurred at t=1000ns; Fault Classification: Based on the error duration of 2 cycles, the reference model classifies it as a "transient fault"; Expected behavior: The "transient fault counter" inside FPGA N is expected to increment by 1; the "take-two inconsistency flag" in the status register of FPGA N is expected to be set to 1; the global system security state is expected to remain "safe".

[0066] The reference model sends these expected register changes and signal states to the scoreboard.

[0067] S34: Capturing the Actual Response and Automated Judgment Upon detecting an inconsistency, the actual internal security logic of FPGA N begins to operate. The monitor continuously captures the following signals: the value of the FPGA N's "transient fault counter"; the level of the "fetch-two inconsistency flag" in the FPGA N status register; and system-level security status signals.

[0068] The scoreboard receives a list of expected behaviors from the reference model and a list of actual signals from the monitor, performing a rigorous comparison in terms of timing and numerical values. Comparison 1: In the Nth period after t=1000ns, is the actual value of the "Take Two Inconsistency Flag" 1? Does it match the expected time? Comparison 2: Does the actual value of the "instantaneous fault counter" increase by 1 accurately at the expected time point? Comparison 3: Did the system security status not jump to "fault" as expected? If all comparison items match perfectly, the error injection test is recorded as passed, proving that the security mechanism's handling of such transient inconsistencies conforms to the design. If any item does not match (e.g., a flag is not set, or a counter is not incremented), the scoring board automatically generates an error report, precisely indicating at which point in time, on which signal, what the expected value was, and what the actual value was. This directly pinpoints the design flaws or implementation errors in the security logic.

[0069] In this embodiment of the invention, repeatable, observable and quantifiable active verification of the security mechanism is achieved. By systematically traversing various failure modes (such as permanent failure, data errors of different bit lengths, etc.) through programming, it ensures that every security design path is executed and verified, providing key support for "100% code and branch coverage", and ultimately proving that the system's behavior under failure is deterministic and safe.

[0070] In this embodiment, the predefined test stimulus sequence includes a random test stimulus sequence, which includes a communication address field, a data length field, a baud rate field, and an error enable field; the random test verification is determined based on the random test stimulus sequence.

[0071] The random test verification includes: invoking a predefined random test stimulus sequence, which includes a communication address field, a data length field, a baud rate field, and an error enable field; the reference model, based on a preset communication protocol specification and cross-validation logic, generates expected response data according to the random test stimulus sequence; the master device under test (DUT) and slave device under test (DUT), based on a communication module and cross-validation logic, respectively generate master actual response data and slave actual response data according to the random test stimulus sequence; comparing the expected response data, master actual response data, and slave actual response data, and determining whether the random test verification passes based on the comparison result.

[0072] Optionally, the random test verification further includes: collecting test coverage data in real time during the random test verification process; dynamically adjusting the generation strategy of the random test stimulus sequence based on the coverage data; and continuing to execute the random test verification using the adjusted random test stimulus sequence.

[0073] In this embodiment of the invention, constrained randomization of UVM is used to generate a massive number of normal and abnormal communication scenarios covering different data lengths, addresses, and baud rates for broad coverage and stress testing. A specific embodiment is also provided to illustrate the detailed process of random testing and verification. S41: Establishing Randomization Rules and Starting the Test In this embodiment of the invention, a random sequence class is written in the UVM testing platform, defining a set of randomized constraint rules.

[0074] Optionally, the randomized constraint rules can be expressed as: class random_sbp_seq extends uvm_sequence; rand bit [31:0] addr; / / Random address rand bit [7:0]data[]; / / A data array of random length rand int baud_div; / / Random baud rate divider (4, 8, 16...) rand biterror_en; / / Randomly enable / disable protocol error injection / / Constraints: Ensure that the random values ​​fall within a reasonable and meaningful range. constraint valid_c { data.size() inside {[1:256]}; / / Data packet length 1 to 256 bytes addr inside {[32'h0000_0000 : 32'h0000_FFFF]}; / / Address in valid memory space baud_div inside {4, 8, 16}; / / The baud rate can only be one of the preset values. error_en dist {1: / 10, 0: / 90}; / / 10% probability of injecting protocol errors. } } After writing the random sequence, run the random regression test, for example, vcs -R test_random_regression, to instantiate the written random sequence based on the random regression test and start the simulation.

[0075] S42: Generate concurrent random transactions and drive Generating random transaction packets: During simulation runtime, the random_sbp_seq sequence begins working, generating hundreds or thousands of random transaction packets in a loop according to the constraints in step S41. Each transaction packet contains a set of independent random values ​​(addr_X, data_X, baud_div_X, error_en_X).

[0076] Coordinated Concurrent Stimulus: Concurrent stimulation is used as a virtual sequence to simultaneously generate two independent random transaction flows: Stream A: used to drive FPGA M; Stream B: used to drive FPGA N. In this example, the two streams are randomly interleaved in time, and may occur simultaneously or sequentially, in order to simulate real concurrent load.

[0077] Signal-level drive: Figure 2 The two primary agent drivers in the system receive these two random transaction streams respectively. Each driver performs the same operation: Set the clock division based on the baud_div value in the transaction.

[0078] The addr and data arrays are encapsulated into frames according to the SBP protocol format.

[0079] If error_en is 1, an error is inserted at a random location in the frame (such as the CRC field).

[0080] Finally, the packaged bitstream with random timing (determined by the baud rate) is driven to the corresponding physical input pins of the FPGA.

[0081] Building a system-level stochastic environment: FPGA M and FPGA N continuously receive these random, concurrent stimuli.

[0082] Meanwhile, the two models, FPGA M_ and FPGA N_slave, are also receiving random data streams from each other's FPGAs in real time, and generating valid response data randomly according to the protocol, and sending it back to each other.

[0083] At this time, the four SBP links (M->N_slave, N->M_slave, M_slave->N, N_slave->M) are simultaneously filled with random, bidirectional data communication, creating an extremely high system-level load and pressure scenario.

[0084] S43: Automated Prediction, Capture, and Comparison The reference model makes random predictions: For every generated random transaction, a copy is sent to the reference model along with the transaction itself. The reference model, for each random transaction: It executes the same protocol processing logic as the DUT.

[0085] Key action: Simulate "cross-checking" and calculate in real time whether the cross-check result should be "consistent" or "inconsistent" under the current random concurrency scenario based on the random input stream of the dual FPGAs, and predict the correct security state accordingly.

[0086] Output the expected response data and the expected security status.

[0087] The monitor captures the actual output: Figure 3 In this process, all actual output signals (data responses, security flags, etc.) generated by FPGA M and FPGA N under random excitation are captured and converted from the agent monitor.

[0088] The scoreboard performs massive automated comparisons: The scoreboard continuously receives expected result streams from the reference model and actual result streams from the monitor, and performs real-time comparisons on each pair of results. Functionality comparison: Is the data content correct? Is the response timely? Security mechanism comparison: When random stimulation happens to cause inconsistency between the two FPGA data (e.g., M sends data A, N sends data B, and A≠B), is the actual security state (such as alarm) generated by the DUT completely consistent with the security state predicted by the reference model? S44: Coverage Collection and Feedback Optimization Coverage collection: During the entire random test run, simulation tools (such as VCS) automatically collect code coverage data, including: line coverage: which lines of code were executed; branch coverage: whether all branches of if-else and case statements were executed (e.g., fault handling branches).

[0089] Generate a report: After the test is completed, a coverage report will be generated.

[0090] Analysis and Optimization: The analysis report identifies low coverage in certain code regions (e.g., logic branches handling rare errors). The random constraints from the first step are then adjusted. For example, the probability of `error_en` causing the rare error might be increased, or the weight of the specific address range that triggers that branch might be increased. Random tests are then run again to achieve a coverage-driven verification loop.

[0091] The random test in this embodiment of the invention is a highly efficient verification engine driven by constraint rules, executed in a system-level concurrent environment, judged by automated comparison, and self-optimized by coverage feedback.

[0092] In this embodiment of the invention, for specific scenarios that are difficult to cover by random testing, especially abnormal paths of the state machine, UVM callback / code stubling is used for targeted testing. By targeted intervention, it is ensured that every branch of the state machine, including branches designed for fault tolerance but never triggered under normal circumstances, is activated and executed, thereby achieving 100% branch coverage.

[0093] In this embodiment, the UVM callback method for targeted testing includes: predefining a test stimulus sequence, wherein the predefined test stimulus sequence includes a test stimulus sequence containing a callback object, wherein the callback object includes a callback function and a callback point; calling the callback function according to the callback point, and injecting an exception signal based on the callback function to perform exception verification.

[0094] In this embodiment, the directional testing method using code stubs includes: identifying and locating the target position of the stub code to be inserted in the source code of the device under test; generating stub code fragments for modifying internal signals or variables according to test requirements; inserting the stub code fragments into the target position to generate modified simulation code; and running the simulation code after inserting the stub code to create test conditions and perform simulation verification.

[0095] For example, UVM callbacks are a mechanism for dynamically inserting custom behaviors during simulation runtime, allowing fault injection or behavior checks to be inserted at specific nodes without modifying the main body of the test sequence.

[0096] Specifically, UVM callbacks are implemented by pre-setting callback points in the test sequence. When the simulation reaches a specific point (such as when the state machine is in the READY state), an exception signal (such as a hardware error signal) is automatically injected through the callback function, forcing the state machine to jump to a state that is normally unreachable. A specific example is provided to illustrate the specific process of UVM callback verification: S51: Define callback classes and callback points Create a class that inherits from uvm_callback and define the exception behaviors that need to be injected in it.

[0097] class error_inject_callback extends uvm_callback; / / Define the error type to be injected, such as Mate signal error bit inject_mate_error; bit [31:0] error_value; / / Callback function: The specific operation performed when it is called virtual task inject_error(input string phase); if (inject_mate_error) begin / / Forced modification Figure 2 Value of the Mate signal line force top_tb.mate_m_to_n = error_value; #2ns; / / Keep the error value for a period of time release top_tb.mate_m_to_n; end endtask endclass Register callback points: Define callback points in the driver. Callback points are typically set during critical phases when the driver sends transactions to the DUT (such as pre_body, mid_phase, post_body).

[0098] class sbp_driver extends uvm_driver; / / Declare callback point `uvm_register_cb(sbp_driver, error_inject_callback) task run_phase(uvm_phase phase); forever begin / / Key point: Callback point before driving the transaction `uvm_do_callbacks(sbp_driver, error_inject_callback, inject_error("pre_drive")) / / Code that drives transactions normally seq_item_port.get_next_item(req); drive_transaction(req); seq_item_port.item_done(); end endtask endclass S52: Configure tests and associate callbacks Create a test case: Write a targeted test case test_mate_error_via_callback.

[0099] Configure callback instance: In the build_phase of the test case, create a callback object and set its parameters.

[0100] class test_mate_error_via_callback extends base_test; error_inject_callback err_cb; function void build_phase(uvm_phase phase); super.build_phase(phase); / / Create a callback instance err_cb = error_inject_callback::type_id::create("err_cb"); / / Configure callback: Inject Mate error on the next transaction-driven event err_cb.inject_mate_error = 1; err_cb.error_value = 32'hFFFF_0000; / / Error value / / Add the callback object to the driver's callback queue uvm_callbacks#(sbp_driver, error_inject_callback)::add(env.in_agent.driver, err_cb); endfunction endclass Define trigger conditions (optional advanced control): More precise triggering can be achieved by adding conditional checks in the callback class. For example, an error can be injected only when the DUT state machine is in the READY state.

[0101] virtual task inject_error(input string phase); if (inject_mate_error&&top_tb.dut_fpga_m.fsm_state == READY) begin force top_tb.mate_m_to_n = error_value; #2ns; release top_tb.mate_m_to_n; end endtask S53: Simulation Execution and Callback Triggering Start the simulation: Run the test case test_mate_error_via_callback.

[0102] Normal sequence execution: The test sequence begins by sending normal SBP communication transactions through the driver.

[0103] Automatic callback triggering: When the driver executes the uvm_do_callbacks statement, the UVM framework automatically checks all callback objects associated with that driver.

[0104] Because err_cb was added to the test case and its inject_mate_error=1, the callback function inject_error() was automatically called.

[0105] The callback function performs its predefined operation: in Figure 2 In the physical connection, the value of the mate_m_to_n signal line is forcibly changed to 32'hFFFF_0000.

[0106] DUT Response: At this time, the cross-validation module of FPGA N samples the mate_m_to_n signal and finds its value to be abnormal (not matching the locally calculated value). According to the "cross-validation take two" logic, FPGA N immediately detects the inconsistency and triggers the internal fault handling process. The state machine may jump from the current state to the error handling state.

[0107] S54: Automated Verification Reference model synchronous response: To ensure complete verification, the test sequence will also synchronously notify the reference model when configuring the callback: "A Mate error will be injected in the next transaction-driven event, with an expected value of 32'hFFFF_0000". The reference model will then calculate the expected system behavior based on this.

[0108] Monitoring and Comparison: The monitor captures the actual output and security state changes of FPGA N after fault injection. The scoreboard compares the actual behavior with the predictions of the reference model to verify: Was the error correctly detected? Were the state transitions correct? Were the security flags correctly set? In this embodiment of the invention, UVM callback exception testing allows for the addition of complex behaviors without modifying the core code of the test sequence or driver; callbacks can be inserted at any stage of protocol processing (transaction start, transmission, transaction end); the same test sequence can generate multiple error scenarios by configuring different callback instances; well-defined callback classes can be reused in multiple test cases; and callbacks can be enabled with a certain probability in random testing to achieve random but controllable error injection.

[0109] It should be noted that UVM callbacks typically operate at the signal interface layer or transaction layer, indirectly affecting the DUT by modifying external signal or transaction attributes; code stubs, by temporarily inserting "stub" code into the DUT code, are used to directly modify internal signals or variables during simulation, creating specific test conditions that directly affect the internal signals or variables of the DUT, bypassing the normal logic path. In this embodiment of the invention, the two are used together to form a complete error injection system from external pins to the internal core, which is a key technology combination to ensure 100% coverage of abnormal paths in the state machine.

[0110] The UVM-based communication module verification method and system of this invention achieves 100% code line and branch coverage through a master-slave overlapping environment and hybrid testing strategies, particularly targeted coverage of abnormal state machine paths. This is difficult to achieve with traditional methods and is crucial for safety-critical systems. Conventional platforms struggle to effectively simulate the interaction and faults of dual FPGAs. The master-slave overlapping environment of this invention can realistically simulate concurrent scenarios and supports precise error injection, thereby deeply verifying security mechanisms such as "cross-selecting two" and providing stronger verification capabilities for redundant architectures and security mechanisms. The random testing in the hybrid strategy is highly automated and explores a wide state space, while the targeted testing directly addresses key issues, avoiding the inefficiency of blind random testing. Combined with automated processes, the verification cycle is significantly shortened. The UVM-based platform architecture itself has good reusability. The design concept of the master-slave overlapping environment can be easily migrated to the verification of other complex systems with multi-node communication, offering good reusability and scalability.

[0111] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A UVM-based communication module verification method, characterized in that, The method includes: A predefined test stimulus sequence is invoked and synchronously applied to multiple devices under test and a reference model. The reference model, based on a preset communication protocol specification and cross-validation logic, simulates the received test stimulus sequence to generate expected response data. The multiple devices under test (DUTs) process the received test stimulus sequences in parallel based on their respective communication modules and cross-validation logic, and generate actual response data respectively. The expected response data is compared and analyzed with the actual response data of each device under test, and the verification is determined based on the comparison results.

2. The UVM-based communication module verification method according to claim 1, characterized in that, The plurality of devices under test (DUTs) includes at least master DUTs and slave DUTs, and the verification environment configured with master DUTs and slave DUTs includes: The configuration includes a verification environment for both master and slave devices; Establish a first communication link between the master terminal of the communication protocol of the master device under test and the slave terminal of the communication protocol of the slave device, and a second communication link between the master terminal of the communication protocol of the slave device under test and the slave terminal of the communication protocol of the master and slave devices. A test stimulus sequence is applied to the master-slave device and the slave device; Verify whether the responses of the master and slave devices under test to the test stimulus meet expectations.

3. The UVM-based communication module verification method according to claim 1 or 2, characterized in that, The reference model simulates the received test stimulus sequence based on a preset communication protocol specification to generate expected response data, including: Determine the type of the received test stimulus sequence and execute the corresponding protocol processing operation; If the test stimulus sequence is determined to be a data write request, a virtual memory update operation is performed to store the write data at a specified address in the virtual memory and generate expected communication response data containing write confirmation. If the test stimulus sequence is determined to be a data read request, a virtual memory read operation is performed to retrieve the read data from the specified address of the virtual memory and generate expected communication response data containing the read data.

4. The UVM-based communication module verification method according to claim 1 or 2, characterized in that, The reference model simulates the received test stimulus sequence based on cross-validation logic to generate expected response data, including: Virtual data of another device under test is generated based on the test scenario configuration parameters; The received test stimulus sequence is compared with the virtual data, and the expected security status data is generated based on the comparison results.

5. The UVM-based communication module verification method according to claim 2, characterized in that, The method further includes a verification step for the erroneous injection signal, wherein the verification of the erroneous injection signal includes: Construct a directional test sequence that includes information on error injection time and error injection point, and inject a preset error signal into the error injection point at the error injection time; The reference model is based on a preset communication protocol specification and cross-validation logic, and generates expected response data according to the error signal instruction; The device under test associated with the error injection point generates actual response data based on the error signal instruction using a communication module and cross-validation logic. Compare the expected response data with the actual response data, and determine whether the error injection verification passes based on the comparison results.

6. The UVM-based communication module verification method according to claim 2, characterized in that, The predefined test stimulus sequence includes a random test stimulus sequence, which includes a communication address field, a data length field, a baud rate field, and an error enable field. Whether the random test verification is passed is determined based on the random test stimulus sequence.

7. The UVM-based communication module verification method according to claim 6, characterized in that, The random test verification also includes: During the random test verification process, test coverage data is collected in real time. The generation strategy for random test stimulus sequences is dynamically adjusted based on the coverage data. Continue performing random test verification using the adjusted random test stimulus sequence.

8. The UVM-based communication module verification method according to claim 2, characterized in that, The predefined test stimulus sequence includes a test stimulus sequence containing callback objects, wherein the callback objects include callback functions and callback points; The callback function is invoked based on the callback point, and an exception verification is performed based on the exception signal injected into the callback function.

9. The UVM-based communication module verification method according to claim 1 or 2, characterized in that, The method further includes: Identify and locate the target position of the stub code to be inserted in the source code of the device under test; Generate stub code snippets for modifying internal signals or variables based on test requirements; The stub code snippet is inserted into the target position to generate the modified simulation code; Run the simulation code after inserting the stub code to create test conditions and perform simulation verification.

10. A UVM-based communication module verification system, characterized in that, The system includes a reference model, a master agent, slave agents, multiple devices under test, and a scoring board; The main agent is configured to synchronously apply the invoked test stimulus sequence to multiple devices under test and reference models; The reference model is configured to simulate the received test stimulus sequence based on a preset communication protocol specification and cross-validation logic to generate expected response data. Multiple devices under test are configured to process the received test stimulus sequence in parallel based on their respective communication modules and cross-validation logic, and generate actual response data respectively. The agent is configured to receive actual response data from the plurality of devices under test. The scoring board is configured to receive actual response data sent from the agent and expected response data sent from the reference model, and to perform multiple comparison analyses between the expected response data and the actual response data of each device under test, and determine whether the verification passes based on the comparison results.

Images