CANFD Verification System and Method Based on UVM Verification Platform

Abstract

This invention relates to a CANFD verification system and method based on the UVM verification platform. The designed verification system supports precise control of transmission timing, simulated resynchronization function, error injection testing, multi-protocol component separation design, and flexible bit timing configuration, enabling comprehensive verification of the functionality and performance of CANFD modules. For example, the UVM verification system supports the verification of CANFD modules with different frequencies and sampling rates by configuring parameters, ensuring the performance and reliability of CANFD modules under different conditions. It also focuses on the boundary cases of frame interval and frame idle time, ensuring that the verification system can fully cover all scenarios that may lead to synchronization problems. This ensures that the verification process fully covers boundary cases and guarantees the stability and reliability of the CANFD module under test under extreme conditions.

Description

Technical Field

[0001] This invention belongs to the field of communication verification technology, and relates to a CANFD verification system and method based on the UVM verification platform. Background Technology

[0002] In CANFD (Controller Area Network Flexible Data-Rate, a half-duplex asynchronous communication protocol) bus communication, the transmission states of node A and node B may be inconsistent, which involves the determination of frame interval and frame idle time. The protocol stipulates that when CANFD detects 11 consecutive high levels on the bus, it considers the bus to be in an idle state, and the node can then begin transmitting data. However, because CANFD is asynchronous communication, node A and node B may differ in their determination of frame interval and frame idle time. For example, node A may determine that the bus is idle at a certain moment and prepare to transmit data, while node B may consider that it is still at the last bit of the frame interval and has not yet entered the frame idle state. If node B is ready to transmit data at this time, but due to improper handling of the frame interval, such as waiting for the frame idle state after detecting data in the frame interval before starting transmission, it may lead to transmission misalignment, thus affecting the accuracy of data sampling.

[0003] Furthermore, if sending node A transmits data later than sending node B, and this delay falls within the SEG2 timeframe (outside this range, the sampling point will not be able to capture the information for that bit), problems may also arise. Theoretically, to ensure correct sampling, the acceptable delay range is the SEG2 duration. If node A transmits data within this timeframe, under normal circumstances, sending node B can successfully complete bus data sampling through the resynchronization function. Therefore, verifying the resynchronization function of the module and whether the deviation that the module under test can tolerate is within the SEG2 timeframe is crucial for ensuring the reliability of CANFD communication. Functional verification needs to cover relevant scenarios of frame intervals and frame idle periods to ensure the accuracy and stability of communication. Summary of the Invention

[0004] To address the problems existing in the above-mentioned traditional methods, this invention proposes a CANFD verification system and a CANFD verification method based on the UVM verification platform, which can effectively verify the resynchronization function of the module and whether the deviation that the module under test can tolerate is within SEG2.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0006] On the one hand, a CANFD verification system based on the UVM verification platform is provided, including a register sequence, a register sequencer, a register driver, a register interface, a transmitter sequencer, a transmitter driver, a transmitter interface, a scoring board, a receiver monitor, a receiver interface, and a CANFD data sequence / CAN data sequence.

[0007] The register sequencer, register driver, and register interface constitute the configuration transmission component, which is used to process the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain register configuration information, and send the register configuration information to the CANFD module under test; the register configuration information is used to configure the register read and write information of the CANFD module and control the CANFD module to send the data that needs to be sent.

[0008] The data transmission component consists of a transmitter sequencer, a transmitter driver, and a transmitter interface. It is used to process the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to transmit, and then send it from the bus to the scoring board through the TLM mechanism. The data that the CANFD module needs to transmit includes data injected with errors.

[0009] The receiver monitor and the receiver interface together form the receiver component, which is used to give ACK response on the ACK bit of the data frame on the bus, put the received data into the CAFND data sequence or CAN data sequence and send it to the scoring board through the TLM mechanism; the data received by the receiver component is the data actually sent by the CANFD module, and the receiver component has the same resynchronization function as the CANFD module.

[0010] The scoring board is used to compare the data that the CANFD module needs to send with the data received by the receiving component to determine the correctness of the data and obtain the verification result of the CANFD module under test.

[0011] On the other hand, a CANFD verification method based on the UVM verification platform is also provided. It is applied to a CANFD verification system based on the UVM verification platform, including a register sequence, a register sequencer, a register driver, a register interface, a transmitter sequencer, a transmitter driver, a transmitter interface, a scoring board, a receiver monitor, a receiver interface, and a CANFD data sequence / CAN data sequence. The register sequencer, the register driver, and the register interface form a configuration transmission component, the transmitter sequencer, the transmitter driver, and the transmitter interface form a data transmission component, and the receiver monitor and the receiver interface form a receiving component.

[0012] The CANFD verification method based on the UVM verification platform includes the following steps:

[0013] The configuration sending component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain register configuration information, and sends the register configuration information to the CANFD module under test. The register configuration information is used to configure the register read and write information of the CANFD module and control the CANFD module to send the data that needs to be sent.

[0014] After the data transmission component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to send, it sends the data from the bus to the scoring board through the TLM mechanism; the data that the CANFD module needs to send includes data injected with errors.

[0015] The receiving component acknowledges the data by giving an ACK response on the ACK bit of the data frame on the bus, and then puts the received data into the CAFND data sequence or CAN data sequence and sends it to the scoring board through the TLM mechanism; the data received by the receiving component is the data actually sent by the CANFD module, and the receiving component has the same resynchronization function as the CANFD module.

[0016] The CANFD module's data transmission and reception components are compared using a scoring board to determine the data's correctness and thus obtain the verification result of the tested CANFD module.

[0017] One of the above technical solutions has the following advantages and beneficial effects:

[0018] The aforementioned CANFD verification system and method based on the UVM verification platform, through its designed verification system, supports precise control of transmission timing, simulated resynchronization functions, error injection testing, multi-protocol component separation design, and flexible bit timing configuration. This allows for comprehensive verification of the CANFD module's functionality and performance. For example, the UVM verification system supports verifying CANFD modules with different frequencies and sampling rates by configuring parameters, ensuring the CANFD module's performance and reliability under various conditions. It also focuses on the boundary conditions of frame intervals and frame idle periods, ensuring the verification system comprehensively covers all scenarios that may lead to synchronization problems. This comprehensive coverage of boundary conditions ensures the stability and reliability of the tested CANFD module under extreme conditions. Furthermore, the verification system can change the transmitted value at any position in the transmitted frame, introducing CRC errors or format errors, without the data transmission component sending error frames. This verifies the error mechanism of the tested CANFD module, comprehensively testing its error handling capabilities and robustness. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the 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.

[0020] Figure 1 A diagram showing the configuration when one bit of a CANFD is used;

[0021] Figure 2 This is a schematic diagram of hard synchronization for CANFD;

[0022] Figure 3 This is a schematic diagram of CANFD resynchronization in case 1.

[0023] Figure 4 This is a schematic diagram of CANFD after resynchronization in case two;

[0024] Figure 5 A schematic diagram of the frame format for CANFD extended frames;

[0025] Figure 6 This is a schematic diagram of the platform architecture of a CANFD verification system based on the UVM verification platform in one embodiment.

[0026] Figure 7 This is a state diagram of a tx_bus task (CANFD ISO extended frame) in one embodiment;

[0027] Figure 8 This is a state diagram of the rx_bus task (CANFD ISO extended frame) in one embodiment;

[0028] Figure 9 This is a flowchart illustrating the CANFD verification method based on the UVM verification platform in one embodiment. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0030] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0031] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0032] CANFD is widely used in automotive electronics, industrial control, and other fields. Its characteristics include high data transmission rates and reliable performance. It employs wired-AND logic during transmission, with low levels covering high levels, and data transmission can start and end at different times without strict timing synchronization. Traditional verification methods struggle to fully cover the complex scenarios in CANFD communication, especially with frequent synchronization problems at frame intervals and frame idle boundaries. Differences in bus state judgments by different nodes can cause misaligned data transmission timing, leading to inaccurate sampling, data loss, or errors. For bit timing verification of CANFD, existing platforms lack flexible configuration methods and struggle to adapt to CANFD modules with different frequencies and sampling rates. Regarding data reception, the resynchronization function of existing verification platforms is incomplete and unable to handle bit field changes caused by transmission timing deviations. Furthermore, in verifying error handling mechanisms, existing methods cannot effectively introduce errors into arbitrary segments of the data frame, failing to comprehensively test the error handling capabilities and robustness of the CANFD module.

[0033] Regarding the composition of a bit time in CANFD and the setting of sampling points: A bit time is composed of multiple Tq times, such as... Figure 1 The diagram shows a total of (SS+SEG1+SEG2), where the SS (Synchronization Segment) is fixed at one Tq time interval, the SEG1 segment consists of SEG1 Tq time intervals, and the SEG2 (Phase Segment 2) segment consists of SEG2 Tq time intervals. When the count reaches (SS+SEG1)Tq, the communication node collects data from the bus. SEG1 is time interval 1, consisting of the Propagation Segment and Phase Buffer Segment 1.

[0034] In CANFD's hard synchronization, the bus is high when idle. When data arrives, the Start of Flow (SOF) bit is low, causing a falling edge on the bus. Because the bus is asynchronous, the receiver detects the falling edge when the transmitter sends the SOF bit, and adjusts its own counting state. This is because CANFD is asynchronous; the transmitter might be counting to SS, while the receiver might be counting to SEG1 or SEG2. Without hard synchronization, the received sampling points would be offset, ultimately leading to inconsistent sampled data. Figure 2 As shown, hard synchronization occurs at the SOF bit (i.e., the start bit of CAN), so the receiving end adjusts its current bit and adjusts the width so that the falling edge of the transmitted SOF falls within the SS segment of the receiving end.

[0035] Regarding resynchronization: (e.g.) Figure 3 and Figure 4 As shown, resynchronization is similar to hard synchronization. Hard synchronization occurs at the beginning of a frame when a falling edge is detected, causing the receiver's count to return to the SS segment. Resynchronization, however, occurs during the transmission of a frame and can occur in two ways:

[0036] Firstly, during the transmission of a single bit, if a falling edge is detected and the receiver is in the SEG1 segment of a single bit (indicating that the previous bit has become longer for some reason), the length of the SJW (Synchronization Jump Width) will be increased to ensure correct sampling. Specifically, when a delay of 2Tq is detected between the recessive level (representing logic 1) and the dominant level (representing logic 0), the length of the SJW is inserted after SEG1 to adjust synchronization.

[0037] Secondly, during the transmission of a single bit, if a falling edge is detected and the receiver is in the SEG2 segment of a single bit (indicating that the bit has shortened for some reason), then this bit will not continue counting; instead, the length of SJW will be shortened to achieve correct sampling. Specifically, when a 2Tq advance is detected in the edge between the recessive and dominant levels, the length of SJW is shortened in SEG2 to adjust synchronization.

[0038] Regarding frame intervals and frame gaps: (e.g.) Figure 5As shown, a complete frame sent by a CANFD node contains 12 bits at the end: ACK bit, DEL bit, end of frame, and frame interval. The ACK bit is sent high during transmission, but when multiple nodes are communicating, other receivers will send an ACK response to the sender. The sender sends a high level, and the receiver responds with a low level; the corresponding bit on the bus is actually low. Excluding the ACK bit, there are 11 remaining bits, which are 11 consecutive high levels. When the sender finishes sending these end bits, it signifies the end of the frame. When other communicating nodes detect 11 consecutive high levels on the bus, it indicates that the bus is in a frame idle state, and they begin sending data.

[0039] As shown in the background section, the impact of different transmission timings during frame intervals and frame idle periods on the CANFD module and the possible consequences are as follows. Functional verification of the CANFD module needs to cover relevant scenarios of frame intervals and frame idle periods to ensure the accuracy and stability of communication.

[0040] In addition, it should be briefly explained that one of the key features of the UVM verification methodology is reusable components and a standardized hierarchical structure. The structure of its UVM workbench, from top to bottom, includes three parts: the top-level (simulation) file testbench, the interface layer, and the part under test (DUT). The interface is used to connect the top-level file and the DUT. The DUT can be various products that need to be tested and verified, such as the CANFD module targeted in this invention.

[0041] In one embodiment, such as Figure 6 As shown, a CANFD verification system based on the UVM verification platform is provided, including a register sequence (Reg_sequence), a register sequencer (Reg_sequencer), a register driver (Reg_driver), a register interface (Reg_vif), a transmitter sequencer (tx_sequencer), a transmitter driver (Tx_driver), a transmitter interface (tx_vif), a scoreboard, a receiver monitor (rx_monitor), a receiver interface (rx_vif), and CANFD data sequences / CAN data sequences. The register sequencer, register driver, and register interface constitute a configuration transmission component, which is used to process the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain register configuration information, and send the register configuration information to the CANFD module under test; the register configuration information is used to configure the register read and write information of the CANFD module and control the CANFD module to send the data that needs to be sent.

[0042] The data transmission component, consisting of a transmitter sequencer, transmitter driver, and transmitter interface, processes the CAFND or CAN data sequence generated from the CANFD / CAN data sequence to obtain the data to be transmitted by the CANFD module. This data is then sent from the bus to the scoring board via a TLM mechanism. The data to be transmitted by the CANFD module includes error-injected data. The receiver component, consisting of a receiver monitor and receiver interface, provides an ACK response on the ACK bit of the data frame on the bus. It places the received data into the CAFND or CAN data sequence and sends it to the scoring board via a TLM mechanism. The data received by the receiver component is the actual data transmitted by the CANFD module, and the receiver component has the same resynchronization function as the CANFD module. The scoring board compares the data to be transmitted by the CANFD module with the data received by the receiver component to determine the correctness of the data and obtain the verification result of the tested CANFD module.

[0043] Understandably, to verify that the CANFD module malfunctions due to different transmission timings between frame intervals and frame idle periods, the following UVM (General Verification Methodology) verification system is proposed. The platform architecture of the UVM verification system can be as follows: Figure 6 As shown, the verification object of this platform architecture is the CANFD module. It does not require integrating the entire chip as the design under test. `env` represents the system environment, `Reg_agent` represents the register proxy component, and `rx_agent` represents the receive proxy component. The UVM verification system includes register sequences, register sequencers, register drivers, register interfaces, transmit sequencers, transmit drivers, transmit interfaces, a scoring board, a receive monitor, a receive interface, and CANFD / CAN data sequences. The CANFD / CAN data sequences, also known as `canfd_sequence` or `can_sequence` (transaction sequences), are responsible for generating CANFD / CAN protocol transactions (such as Start of Frame (SOF), data segments, bit timing related operations, etc.).

[0044] The register sequencer, register driver, and register interface together constitute the configuration transmission component capable of sending data frames. The CAFND or CAN data sequence sent by it contains register read / write information, as well as information on the data that the DUT (i.e., the CANFD module under test) needs to send. This information is sent to the DUT's read / write registers through its register interface by the configuration transmission component, thereby controlling the DUT to send the data frames it needs to send.

[0045] The transmitter sequencer, transmitter driver, and transmitter interface together constitute a data transmission component capable of transmitting data frames. The CAFND or CAN data sequence transmitted by it contains the data frame information that the CANFD module needs to send. This information is sent to the transmitter driver through the transmitter sequencer. The transmitter driver extracts the data frame information and then, based on the frame information in the sequence, performs an AND operation with the transmit line of the DUT through the transmitter interface to form a bus and sends it to the receive line of the DUT.

[0046] The receiver monitor and receiver interface constitute a receiving component capable of receiving data frames on the bus and providing ACK responses. The receiver monitor can extract data frames on the bus and provide ACK responses on the ACK bit of the data frames on the bus through the receiver interface. It then places the received data frames into the CAFND data sequence or CAN data sequence and sends them to the scoring board through the TLM (Transaction-Level Modeling) mechanism of the UVM verification system.

[0047] In other words, in addition to the data frames successfully sent by the data transmission component being sent to the scoring board through the TLM mechanism of the UVM verification system, the receiving component will also send the data frames it receives from the DUT to the scoring board. The scoring board will compare the data frames successfully sent by the data transmission component with the data frames successfully received from the DUT, and determine whether the data that the CAFND module needs to send is consistent with the data frames received by the receiving component after being sent to the bus through contention based on the contention situation. This will help determine the correctness of the data frame content under contention and the correctness of the contention mechanism of the CAFND module under test.

[0048] Specifically, the data transmission component transmits the data to be transmitted by the DUT to the ideal transmission data buffer (exp_tx_fifo) through the ideal transmission data analysis import port (uvm_analysis_imp_exp_tx_ch) of the TLM mechanism of the UVM verification system. The receiving component transmits the received data to the actual received data buffer (act_rx_fifo) through the actual received data analysis import port (uvm_analysis_imp_act_rx_ch) of the TLM mechanism of the UVM verification system. The scoring board extracts the transmitted data and the received data from these two buffers and performs a consistency comparison to determine the correctness of the data, thereby verifying whether the CANFD module under test is functioning normally.

[0049] The aforementioned CANFD verification system based on the UVM verification platform supports precise control of transmission timing, simulated resynchronization, error injection testing, multi-protocol component separation design, and flexible bit timing configuration. This comprehensive approach verifies the functionality and performance of the CANFD module. For example, the UVM verification system allows for the verification of CANFD modules with different frequencies and sampling rates by configuring parameters, ensuring the module's performance and reliability under various conditions. It also focuses on frame intervals and frame idle boundary conditions, ensuring the verification system comprehensively covers all scenarios that may lead to synchronization problems. This comprehensive coverage of boundary conditions ensures the stability and reliability of the tested CANFD module under extreme conditions. Furthermore, the verification system can change the transmitted value at any position in the transmitted frame, introducing CRC errors or format errors without the data transmission component sending error frames. This verifies the error mechanism of the tested CANFD module, comprehensively testing its error handling capabilities and robustness.

[0050] The functions of the tasks and signals mentioned in this manual are described in Table 1:

[0051] Table 1

[0052]

[0053] In one embodiment, during the transmission of CANFD ISO extended frames, the transmitting driver includes a process in the wait_free task during the runtime phase:

[0054] First process: Detecting that the CANFD module is in the last bit of the frame interval, triggering the state machine of the data transmission component to enter the data transmission state;

[0055] Second process: Randomly pull the CAN_BUS_FREE signal high within two bit intervals to start data frame transmission;

[0056] The third process monitors bus level changes. If a falling edge appears on the bus, it randomly pulls the CAN_BUS_FREE signal high within a specific time period. When either the second or third process starts, the other process immediately stops. After the tx_bus task in the main phase starts, the state machine first enters the frame start state and begins counting different timing segments. After each timing segment is completed, the corresponding operation is performed. These operations include sending data bits and updating the status, performing bit stuffing during transmission, and waiting for the bus to become idle again and retransmitting the data frame if arbitration failure is detected in the arbitration segment.

[0057] Specifically, the transmit driver plays a crucial role in the transmission of CANFD ISO extended frames. During the run phase (run_phase), the wait_free task includes three main processes. The first process involves the transmit driver detecting whether the CANFD module under test is at the last bit of the frame interval. Upon detecting this, the data transmission component's state machine is triggered and enters the data transmission state. At this time, two other processes are started: the second process randomly pulls the CAN_BUS_FREE signal high within two bit intervals to initiate data frame transmission; the third process monitors bus level changes. If a falling edge appears on the bus (indicating data transmission and a frame start marker), it randomly pulls the CAN_BUS_FREE signal high within a specific time length. Once either of the other two processes is started, the other process immediately stops. The specific time length can be determined by an acceptable delay range to ensure correct sampling. For example, as described in the background section, the acceptable delay range is the SEG2 duration, so this specific time length can be set to the SEG2 duration. Alternatively, without considering transmit / receive delays, this time length can also be set to the SEG2 duration.

[0058] like Figure 7 As shown, after the tx_bus task starts in the main phase, the state machine will execute a series of operations sequentially: The state machine will first enter the Start of Frame (SOF) state and begin counting different timing segments (such as SS, SEG1, and SEG2). After counting each timing segment is complete, corresponding operations will be performed, such as sending data bits and updating the status; bit stuffing operations will also be performed during transmission to ensure data integrity and correctness. If arbitration failure is detected in the arbitration segment, the state machine will re-enter the wait-for-bus-idle state and retransmit the data frame.

[0059] Figure 7 In this context, ID stands for Identifier, IDE for Identifier Extension, SRR for Alternate Remote Request, RO and RRS for Receive Status Markers, Data for Data Segment, FDF for Flexible Data Rate, BRS for Bit Rate Switching, and ESI for Error Status Indicator.

[0060] In one embodiment, the calculation and verification operations performed by the transmit driver at different communication stages include: calculating and filling the CRC value in the CRC stage; checking whether an ACK response has been received in the ACK stage, and if not, entering an error state; continuously monitoring the bus status during transmission, and recording the exception information and performing corresponding error correction if a data error is detected.

[0061] Specifically, the transmit driver also performs corresponding calculations and verification operations at different communication stages (such as DLC, STC, CRC, and ACK stages). For example, in the CRC stage, the transmit driver calculates the CRC value and pads it. In the ACK stage, the transmit driver checks whether an ACK response has been received. If not, it enters an error state. Furthermore, during transmission, the transmit driver continuously monitors the bus status to ensure data consistency between transmission and reception. If a data error is detected, the transmit driver records the exception information and takes appropriate corrective measures, such as stopping transmission and attempting to retransmit the data frame.

[0062] In one embodiment, when the receiver monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level to appear on the bus, and then starts the Tq counting process.

[0063] Understandable, such as Figure 8 As shown, the receiver monitor is responsible for monitoring bus signals and receiving data frames. During the `rx_wait_free` task in the run phase, the receiver monitor continuously monitors the bus status. When the receiver monitor detects a series of high levels on the bus, indicating that the bus is at the last bit of the frame interval, it triggers the corresponding signal to start the `rx_bus` task. Subsequently, the receiver monitor waits for a low level to appear on the bus (marking the start of data transmission) and starts the `Tq` counting process, counting different timing segments sequentially.

[0064] Specifically, during the counting process, if a falling edge is detected on the bus in the SEG1 segment, it indicates a delay in the previous bit of data. The count value is then reset, and counting resumes from the SS segment. Similarly, in the SEG2 segment, if a falling edge is detected, it indicates that the transmission bit has ended prematurely, and counting stops and the sampling of the next bit begins immediately. This mechanism ensures the accuracy and synchronization of data reception.

[0065] In one embodiment, after receiving the DLC segment, the receiver monitor determines the number of bits in the subsequent data segment based on the received DLC value; after receiving the STC segment, the receiver monitor compares the ideal STC value with the actual received value, and if an error is found, an error report is generated; during the receiving process, the receiver monitor calculates and verifies the CRC, and performs error handling when an error is detected.

[0066] Specifically, after receiving the DLC segment, the receiver monitor determines the number of bits in subsequent data segments based on the received DLC value. After receiving the STC segment, the receiver monitor compares the ideal STC value with the actual received value. If an error is found, the receiver monitor generates a corresponding error report. Furthermore, during the reception process, the receiver monitor also calculates and verifies the CRC to ensure data integrity. If an error is detected, the receiver monitor will take appropriate error handling measures, such as stopping reception and re-entering a wait-for-bus-idle state.

[0067] During reception, the receiver monitor also performs bit stuffing checks to ensure data integrity. Once the entire data frame is received, the received data is stored in the CANFD data sequence and transmitted to the scoring board via the TLM mechanism of the UVM verification system for further processing and verification. Through these functions, the receiver monitor effectively ensures the accuracy and reliability of data reception, while also effectively managing and handling errors during the reception process.

[0068] In other words, the receiving component of the verification system has the same resynchronization function as the CANFD module, and can still perform correct sampling even when the two communication nodes form a bus for communication, due to bit field deviations caused by transmission timing, etc.

[0069] The aforementioned verification system can be built using the SystemVerilog language, an existing language in this field, and follows the UVM verification methodology. It can be configured using components within the UVM verification platform, tailored to the specific verification interaction functionalities required. For example, a verification sequence library is a library for storing and managing verification sequences. In the UVM verification methodology, verification sequences are objects used to generate test scenarios and interactions; they describe the sequence of events occurring during testing, such as inputs, outputs, and timing relationships. The verification sequence library provides a structured way to organize and invoke these sequences. When managing verification sequences, the library provides a central location where users can register, store, and retrieve custom verification sequences. Users can register their verification sequences with the library, making these sequences accessible and executable in tests. This registration typically occurs during the test environment initialization phase. Once a verification sequence is registered, other components (such as tests, other verification sequences, etc.) can invoke these sequences through the library. Thus, test scenarios can be created by organically combining different sequences to produce complex test cases. The verification sequence library can support a hierarchical structure, allowing users to organize and manage multiple related verification sequences. The verification sequence library also supports dynamic configuration, allowing users to dynamically select and randomly configure verification sequences as needed at runtime. Therefore, when performing verification tests, users can use the verification sequence library to randomly configure verification sequences according to the verification requirements of the CANFD module, thereby supporting more comprehensive verification tests.

[0070] Each module in the CANFD verification system based on the UVM verification platform described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of a device with data processing capabilities, or stored in software within the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of verification computer equipment already existing in the art.

[0071] In some implementations, in the field of integrated circuit (IC) design and verification, the CANFD bus controller (i.e., the specific CANFD module) is a key component of the chip, and its performance and reliability directly affect the quality and stability of the entire chip. The verification system of this invention focuses on the verification of the CANFD bus controller within the IC. During the chip design phase, rigorous verification of the CANFD bus controller using the aforementioned verification system can identify potential design flaws and problems in advance. For example, during simulated CANFD bus communication, the verification system can precisely control the transmission timing to simulate various complex scenarios, such as different transmission timings for frame intervals and frame idle periods, bit field deviations, etc., to detect whether the synchronization mechanism of the CANFD bus controller is functioning correctly under these conditions. Simultaneously, the verification system has a simulated resynchronization function, which can verify the sampling accuracy of the receiving section when the bit field changes. Furthermore, by introducing errors into arbitrary segments of the data frame, the error handling mechanism of the CANFD bus controller can be comprehensively tested to ensure that it can respond correctly to erroneous frames.

[0072] During the chip verification phase, the aforementioned verification system can verify CANFD modules with different frequencies and sampling rates, supporting multiple CANFD frame formats to meet the needs of different IC designs. Through these verification processes, the quality and reliability of the CANFD bus controller in the IC can be effectively improved, reducing the risk of chip failure in practical applications and providing strong support for the successful development and mass production of the IC.

[0073] Overall, the aforementioned verification system can effectively optimize the CANFD verification process, save time and resources, improve development efficiency, and thus lay a technical foundation for developing higher quality and more reliable CANFD products, enhancing their technical competitiveness in fields such as automotive electronics and industrial control.

[0074] In one embodiment, such as Figure 9 As shown, a CANFD verification method based on a UVM verification platform is provided, which is applied to a CANFD verification system based on a UVM verification platform. The system includes a register sequence, a register sequencer, a register driver, a register interface, a transmitter sequencer, a transmitter driver, a transmitter interface, a scoring board, a receiver monitor, a receiver interface, and a CANFD data sequence / CAN data sequence. The register sequencer, the register driver, and the register interface constitute a configuration transmission component, the transmitter sequencer, the transmitter driver, and the transmitter interface constitute a data transmission component, and the receiver monitor and the receiver interface constitute a receiving component.

[0075] The CANFD verification method based on the UVM verification platform described above may include the following processing steps S10 to S16:

[0076] Step S10: The configuration sending component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain register configuration information, and sends the register configuration information to the CANFD module under test; the register configuration information is used to configure the register read and write information of the CANFD module and control the CANFD module to send the data that needs to be sent.

[0077] Step S12: After the data transmission component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data to be transmitted by the CANFD module, it sends the data from the bus to the scoring board through the TLM mechanism; the data to be transmitted by the CANFD module includes data injected with errors.

[0078] Step S14: The receiving component gives an ACK response on the ACK bit of the data frame on the bus, puts the received data into the CAFND data sequence or CAN data sequence, and sends it to the scoring board through the TLM mechanism; the data received by the receiving component is the data actually sent by the CANFD module, and the receiving component has the same resynchronization function as the CANFD module.

[0079] Step S16: The consistency of the data to be sent by the CANFD module and the data received by the receiving component is compared by the scoring board. After determining the correctness of the data, the verification result of the CANFD module under test is obtained.

[0080] The aforementioned CANFD verification method based on the UVM verification platform, through its designed verification system, supports precise control of transmission timing, simulated resynchronization functions, error injection testing, multi-protocol component separation design, and flexible bit timing configuration. This allows for comprehensive verification of the CANFD module's functionality and performance. For example, the UVM verification system supports verifying CANFD modules with different frequencies and sampling rates by configuring parameters, ensuring the CANFD module's performance and reliability under various conditions. It also focuses on the boundary conditions of frame intervals and frame idle periods, ensuring the verification system comprehensively covers all scenarios that may lead to synchronization problems. This comprehensive coverage of boundary conditions ensures the stability and reliability of the tested CANFD module under extreme conditions. Furthermore, the verification system can change the transmitted value at any position in the transmitted frame, introducing CRC errors or format errors, without the data transmission component sending error frames. This verifies the error mechanism of the tested CANFD module, comprehensively testing its error handling capabilities and robustness.

[0081] In one embodiment, during the transmission of CANFD ISO extended frames, the transmitting driver includes a process in the wait_free task during the runtime phase:

[0082] First process: Detecting that the CANFD module is in the last bit of the frame interval, triggering the state machine of the data transmission component to enter the data transmission state;

[0083] Second process: Randomly pull the CAN_BUS_FREE signal high within two bit intervals to start data frame transmission;

[0084] The third process monitors changes in bus level. If a falling edge appears on the bus, it randomly pulls the CAN_BUS_FREE signal high within a specific time period. When either the second or third process starts, the other process immediately stops.

[0085] After the tx_bus task in the main phase of the state machine starts, it first enters the frame start state and begins counting different timing segments. After the counting of each timing segment is completed, the corresponding operation is performed. The corresponding operation includes the transmission of data bits and the update of the state. During the transmission process, bit stuffing operation is performed, and when arbitration failure is detected in the arbitration segment, the system waits for the bus to be idle again and retransmits the data frame.

[0086] In one embodiment, the calculation and verification operations performed by the transmit driver at different communication stages include: calculating and filling the CRC value in the CRC stage; checking whether an ACK response has been received in the ACK stage, and if not, entering an error state; continuously monitoring the bus status during transmission, and recording the exception information and performing corresponding error correction if a data error is detected.

[0087] In one embodiment, when the receiver monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level to appear on the bus, and then starts the Tq counting process.

[0088] In one embodiment, after receiving the DLC segment, the receiver monitor determines the number of bits in the subsequent data segment based on the received DLC value; after receiving the STC segment, the receiver monitor compares the ideal STC value with the actual received value, and if an error is found, an error report is generated; during the receiving process, the receiver monitor calculates and verifies the CRC, and performs error handling when an error is detected.

[0089] It is understandable that the specific limitations of the CANFD verification method based on the UVM verification platform can be found in the corresponding limitations of the CANFD verification system based on the UVM verification platform mentioned above, and will not be repeated here.

[0090] It should be understood that, although Figure 9The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Figure 9 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0091] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

[0092] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0093] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.

Claims

1. A CANFD verification system based on the UVM verification platform, characterized in that, This includes register sequences, register sequencers, register drivers, register interfaces, transmitter sequencers, transmitter drivers, transmitter interfaces, scoring boards, receiver monitors, receiver interfaces, and CANFD data sequences / CAN data sequences. The register sequencer, register driver, and register interface constitute the configuration transmission component, which is used to process the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the register configuration information, and send the register configuration information to the CANFD module under test. Register configuration information is used to configure the register read / write information of the CANFD module and to control the CANFD module to send the data that needs to be sent; The data transmission component consists of a transmitter sequencer, a transmitter driver, and a transmitter interface. It is used to process the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to transmit, and then send it from the bus to the scoring board through the TLM mechanism. The data that the CANFD module needs to transmit includes data injected with errors. The receiver monitor and the receiver interface together form the receiver component, which is used to give ACK response on the ACK bit of the data frame on the bus, put the received data into the CAFND data sequence or CAN data sequence and send it to the scoring board through the TLM mechanism; the data received by the receiver component is the data actually sent by the CANFD module, and the receiver component has the same resynchronization function as the CANFD module. The scoring board is used to compare the data that the CANFD module needs to send with the data received by the receiving component to determine the correctness of the data and obtain the verification result of the CANFD module under test. During the transmission of CANFD ISO extended frames, the driver includes the following processes in the wait_free task during the runtime phase: First process: Detecting that the CANFD module is in the last bit of the frame interval, triggering the state machine of the data transmission component to enter the data transmission state; Second process: Randomly pull the CAN_BUS_FREE signal high within two bit intervals to start data frame transmission; The third process monitors changes in bus level. If a falling edge appears on the bus, it randomly pulls the CAN_BUS_FREE signal high within a specific time period. When either the second or third process starts, the other process immediately stops. After the tx_bus task in the main phase of the state machine starts, it first enters the frame start state and begins counting different timing segments. After the counting of each timing segment is completed, the corresponding operation is performed. The corresponding operation includes the transmission of data bits and the update of the state. During the transmission process, bit stuffing operation is performed, and when arbitration failure is detected in the arbitration segment, the system waits for the bus to be idle again and retransmits the data frame.

2. The CANFD verification system based on the UVM verification platform according to claim 1, characterized in that, The computational and verification operations performed by the sending driver at different communication stages include: Calculate and pad the CRC value during the CRC phase; During the ACK phase, check if an ACK response has been received. If not, then enter an error state. During transmission, the bus status is continuously monitored. If a data error is detected, the exception information is recorded and the corresponding error correction is performed.

3. The CANFD verification system based on the UVM verification platform according to claim 1, characterized in that, When the receiver monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level to appear on the bus, and then starts the Tq counting process.

4. The CANFD verification system based on the UVM verification platform according to claim 3, characterized in that, After receiving the DLC segment, the receiver determines the number of bits in subsequent data segments based on the received DLC value. After the STC segment is received, the receiver monitor compares the ideal STC value with the actual received value. If an error is found, an error report is generated. During the receiving process, the receiver monitor calculates and verifies the CRC, and performs error handling when an error is detected.

5. A CANFD verification method based on a UVM verification platform, characterized in that, The system is applied to a CANFD verification system based on a UVM verification platform, including a register sequence, a register sequencer, a register driver, a register interface, a transmitter sequencer, a transmitter driver, a transmitter interface, a scoring board, a receiver monitor, a receiver interface, and a CANFD data sequence / CAN data sequence. The register sequencer, register driver, and register interface form a configuration transmission component, the transmitter sequencer, transmitter driver, and transmitter interface form a data transmission component, and the receiver monitor and receiver interface form a receiving component. The CANFD verification method based on the UVM verification platform includes the following steps: The configuration sending component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the register configuration information, and then sends the register configuration information to the CANFD module under test. Register configuration information is used to configure the register read / write information of the CANFD module and to control the CANFD module to send the data that needs to be sent; After the data transmission component processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to send, it sends the data from the bus to the scoring board through the TLM mechanism; the data that the CANFD module needs to send includes data injected with errors. The receiving component acknowledges the data by giving an ACK response on the ACK bit of the data frame on the bus, and then puts the received data into the CAFND data sequence or CAN data sequence and sends it to the scoring board through the TLM mechanism; the data received by the receiving component is the data actually sent by the CANFD module, and the receiving component has the same resynchronization function as the CANFD module. The CANFD module's data transmission and reception components are compared using a scoring board to determine the data's correctness and thus obtain the verification result of the tested CANFD module. During the transmission of CANFD ISO extended frames, the driver includes the following processes in the wait_free task during the runtime phase: First process: Detecting that the CANFD module is in the last bit of the frame interval, triggering the state machine of the data transmission component to enter the data transmission state; Second process: Randomly pull the CAN_BUS_FREE signal high within two bit intervals to start data frame transmission; The third process monitors changes in bus level. If a falling edge appears on the bus, it randomly pulls the CAN_BUS_FREE signal high within a specific time period. When either the second or third process starts, the other process immediately stops. After the tx_bus task in the main phase of the state machine starts, it first enters the frame start state and begins counting different timing segments. After the counting of each timing segment is completed, the corresponding operation is performed. The corresponding operation includes the transmission of data bits and the update of the state. During the transmission process, bit stuffing operation is performed, and when arbitration failure is detected in the arbitration segment, the system waits for the bus to be idle again and retransmits the data frame.

6. The CANFD verification method based on the UVM verification platform according to claim 5, characterized in that, The computational and verification operations performed by the sending driver at different communication stages include: Calculate and pad the CRC value during the CRC phase; During the ACK phase, check if an ACK response has been received. If not, then enter an error state. During transmission, the bus status is continuously monitored. If a data error is detected, the exception information is recorded and the corresponding error correction is performed.

7. The CANFD verification method based on the UVM verification platform according to claim 5, characterized in that, When the receiver monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level to appear on the bus, and then starts the Tq counting process.

8. The CANFD verification method based on the UVM verification platform according to claim 7, characterized in that, After receiving the DLC segment, the receiver determines the number of bits in subsequent data segments based on the received DLC value. After the STC segment is received, the receiver monitor compares the ideal STC value with the actual received value. If an error is found, an error report is generated. During the receiving process, the receiver monitor calculates and verifies the CRC, and performs error handling when an error is detected.

Images