CANFD verification system and method based on UVM verification platform

Abstract

The invention relates to a CANFD verification system and a CANFD verification method based on a UVM verification platform, which can comprehensively verify the function and performance of a CANFD module by supporting test means such as accurate control of sending opportunity, simulation of a resynchronization function, error injection test, multi-protocol component separation design and flexible bit time sequence configuration through the designed verification system. For example, a UVM verification system is utilized to support verification of CANFD modules with different frequencies and sampling rates through configuration parameters, performance and reliability of the CANFD modules under different conditions are ensured, boundary conditions of frame intervals and frame idle are concerned, it is ensured that the verification system can fully cover all scenes possibly causing synchronization problems, and the verification efficiency of the CANFD modules is improved. Therefore, the verification process fully covers the boundary condition, and the stability and reliability of the tested CANFD module under extreme conditions are ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of communication verification, and relates to a CANFD verification system and method based on a UVM verification platform. Background Art

[0002] In CANFD (Controller Area Network Flexible Data-Rate), a half-duplex, asynchronous communication protocol, the transmission status of nodes A and B may differ. This involves the determination of interframe intervals and idle frames. The protocol stipulates that when CANFD detects 11 consecutive high levels on the bus, the bus is considered idle, and the node may then begin transmitting data. However, because CANFD is asynchronous communication, nodes A and B may differ in their determination of interframe intervals and idle frames. For example, node A may determine that the bus is idle at a certain moment and prepare to transmit data, while node B may believe that the bus is still at the last bit of the interframe interval and has not yet entered the idle frame state. If node B is ready to transmit data at this moment, but improperly handles the interframe interval, such as waiting for the idle frame state after detecting data in the interframe interval before transmitting, this may result in misaligned transmission, affecting data sampling accuracy.

[0003] Furthermore, if sending node A sends data later than sending node B, and this delay falls within the SEG2 interval (beyond this range, the sampling point will not be able to sample the information for that bit), this can also cause problems. Theoretically, to ensure correct sampling at the sampling point, the acceptable delay range is the SEG2 duration. If node A sends data during this period, sending node B can normally successfully complete bus data sampling through resynchronization. Therefore, verifying the module's resynchronization functionality and whether the deviation tolerated by the module under test falls within the SEG2 interval is crucial to ensuring the reliability of CAN FD communication. Functional verification needs to cover scenarios related to frame intervals and frame idle periods to ensure accurate and stable communication. Summary of the Invention

[0004] In response to the problems existing in the above-mentioned traditional methods, the present invention proposes a CANFD verification system based on the UVM verification platform 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 tested module can tolerate is between SEG2.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, a CANFD verification system based on a UVM verification platform is provided, including a register sequence, a register sequencer, a register driver, a register interface, a transmit sequencer, a transmit driver, a transmit interface, a scoreboard, a receive monitor, a receive interface, and a CANFD data sequence / CAN data sequence; The register sequencer, register driver and register interface constitute the configuration sending component, which is used to process the CAFND data sequence or CAN data sequence generated by 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 to be sent; The data transmission component consists of a transmission sequencer, a transmission driver, and a transmission interface. It is used to process the CAFND data sequence or CAN data sequence generated by the CANFD data sequence / CAN data sequence to obtain the data required to be sent by the CANFD module, and then send it from the bus to the scoreboard through the TLM mechanism. The data required to be sent by the CANFD module includes error-injected data. The receiving monitor and receiving interface form the receiving component, which is used to give an 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 then send it to the scoreboard 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 scoreboard is used to perform consistency comparison between the data that the CANFD module needs to send and the data received by the receiving component. After determining the correctness of the data, the verification result of the tested CANFD module is obtained.

[0006] On the other hand, a CANFD verification method based on a UVM verification platform is also provided, which 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 sending sequencer, a sending driver, a sending interface, a scoreboard, a receiving monitor, a receiving interface, and a CANFD data sequence / CAN data sequence, wherein the register sequencer, the register driver, and the register interface constitute a configuration sending component, the sending sequencer, the sending driver, and the sending interface constitute a data sending component, and the receiving monitor and the receiving interface constitute a receiving component; The CANFD verification method based on the UVM verification platform includes the following steps: The register configuration information is obtained by processing the CAFND data sequence or CAN data sequence generated by the configuration sending component according to the CANFD data sequence / CAN data sequence, and the register configuration information is sent 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 to be sent; After the data transmission component processes the CAFND data sequence or CAN data sequence generated by the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to send, it is sent from the bus to the scoreboard through the TLM mechanism; the data that the CANFD module needs to send includes the error-injected data; 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 scoreboard 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 scoreboard is used to compare the consistency of the data that the CANFD module needs to send and the data received by the receiving component. After judging the correctness of the data, the verification result of the tested CANFD module is obtained.

[0007] One of the above technical solutions has the following advantages and beneficial effects: The CANFD verification system and method based on the UVM verification platform, through the designed verification system supporting precise control of transmission timing, simulated resynchronization functions, error injection testing, multi-protocol component separation design, and flexible bit timing configuration, can fully verify the functions and performance of the CANFD module. For example, the UVM verification system supports the verification of CANFD modules with different frequencies and sampling rates through configuration parameters, ensuring the performance and reliability of the CANFD module under different conditions. It also pays attention to the boundary conditions of frame intervals and frame idles, ensuring that the verification system can fully cover all scenarios that may cause synchronization problems. The verification process fully covers boundary conditions and ensures the stability and reliability of the tested CANFD module under extreme conditions. At the same time, the verification system can change the sent value at any position in the transmitted frame, thereby introducing CRC errors or format errors, etc., and the data transmission component will not send error frames, thereby verifying the error mechanism of the tested CANFD module and comprehensively testing the error handling capability and robustness of the tested CANFD module. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the conventional technology, the following briefly introduces the drawings required for use in the embodiments or the conventional technology descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0009] Figure 1 This is a diagram of the structure of a bit of CANFD; Figure 2 This is a schematic diagram of CANFD hard synchronization; Figure 3 This is a schematic diagram of CANFD resynchronization in the following situation; Figure 4 This is a schematic diagram of CANFD after resynchronization in case 2; Figure 5 This is a schematic diagram of the frame format of the CANFD extended frame; Figure 6 Schematic diagram of the platform architecture of a CANFD verification system based on the UVM verification platform in one embodiment; Figure 7 1 is a state diagram of the tx_bus task (CANFD ISO extended frame) in one embodiment; Figure 8 1 is a state diagram of the rx_bus task (CANFD ISO extended frame) in one embodiment; Figure 9 The figure is a flow chart of a CAN FD verification method based on a UVM verification platform in one embodiment. DETAILED DESCRIPTION

[0010] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the description of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0011] It should be noted that, when referred to in this document as an "embodiment", it means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The presentation of this phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It will be understood by those skilled in the art that the embodiments described herein may be combined with other embodiments. The term "and / or" used in this document refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0012] The following describes the implementation of the present invention in detail with reference to the accompanying drawings in the embodiments of the present invention.

[0013] CANFD is widely used in automotive electronics, industrial control, and other fields. Its characteristics include high data rates and reliable performance. It utilizes wired-AND logic during transmission, allowing low-level signals to override high-level signals. Data transmission can start and end at different times, eliminating the need for strict timing synchronization. Traditional verification methods struggle to fully cover the complex scenarios encountered in CANFD communication, particularly at the boundary between interframe intervals and idle frames, where synchronization issues are common. Discrepancies in bus state assessments by different nodes can cause misaligned data transmission timing, leading to inaccurate sampling, data loss, or errors. Existing platforms lack flexible configuration options for CANFD bit timing verification, making it difficult to adapt to CANFD modules with varying frequencies and sampling rates. Regarding data reception, existing verification platforms lack robust resynchronization capabilities, making them unable to address bit field variations caused by timing deviations. Furthermore, existing methods for verifying error handling mechanisms are unable to effectively introduce errors into arbitrary segments of a data frame, preventing comprehensive testing of the error handling capabilities and robustness of CANFD modules.

[0014] Regarding the composition of a bit time of CANFD and the setting of sampling points: a bit time is composed of multiple Tq times, such as Figure 1 The total length is (SS+SEG1+SEG2). The SS (Synchronization Segment) is fixed at one Tq, SEG1 is SEG1 Tq, and SEG2 (Phase Segment 2) is SEG2 Tq. When (SS+SEG1) Tq is reached, the communication node acquires data from the bus. SEG1 is Segment 1, consisting of the Propagation Segment and Phase Buffer Segment 1.

[0015] In the hard synchronization of CANFD, the bus is at a high level in the idle state. When there is data, the start bit SOF is at a low level, so a falling edge will appear on the bus. Because the bus is in an asynchronous state, when the transmitter sends the SOF bit, the receiver will detect the falling edge, and at this time the receiver will adjust its own counting state. This is because CANFD is asynchronous. The transmitter counts to SS at this time, while the receiver may count to SEG1 or SEG2 in the receiving stage. If there is no hard synchronization, the received sampling point will be offset, which will eventually lead to inconsistent sampled data. Figure 2 As shown in the figure, hard synchronization occurs at the SOF bit (i.e., the start bit of CAN), so the receiving end adjusts the current bit and the width so that the falling edge of the transmitted SOF falls within the SS segment of the receiving end.

[0016] About resynchronization: Figure 3 and Figure 4 As shown in the figure, resynchronization is similar to hard synchronization. Hard synchronization is at the beginning of a frame. If a falling edge is detected, the receiver's count will return to the SS segment. Resynchronization occurs during the transmission of a frame. There are two situations: One is that during the transmission of a bit, if a falling edge is detected and the receiver is in the SEG1 segment of a bit (indicating that the previous bit has become longer for some reason), the length of the SJW (Synchronization Jump Width) is increased for this bit to achieve correct sampling. Specifically, if a 2Tq delay is detected between the recessive level (representing a logic 1) and the dominant level (representing a logic 0), the length of the SJW is inserted after SEG1 to adjust synchronization.

[0017] Secondly, during the transmission of a bit, if a falling edge is detected and the receiver is in the SEG2 segment of a bit (indicating that the bit has become shorter for some reason), the bit will not be counted further, but the length of the SJW will be shortened to achieve correct sampling. Specifically, if the edge from recessive level to dominant level is detected to be 2Tq ahead, the length of the SJW will be shortened in SEG2 to adjust synchronization.

[0018] Regarding frame interval and frame idle: Figure 5As shown in the figure, a complete frame sent by a CAN FD node ends with the ACK bit, DEL bit, end of frame, and interframe interval, totaling 12 bits. The ACK is sent high during transmission. However, when multiple nodes are communicating, other receivers will respond with ACKs to the sender. The sender sends a high level, and the receiver responds with a low level. This bit on the bus actually appears low. Excluding the ACK bit, the remaining bits total 11, and these 11 bits are 11 consecutive high levels. When the sender finishes sending these tail bits, the frame ends. When other communication nodes detect 11 consecutive high levels on the bus, it indicates that the bus is in the frame idle state, and they can then begin sending data.

[0019] The impact of different sending timings of frame intervals and frame idles on the CANFD module and the possible situations that may arise are shown in the background technology section. The functional verification of the CANFD module needs to cover the relevant scenarios of frame intervals and frame idles to ensure the accuracy and stability of communication.

[0020] In addition, it should be briefly explained that one of the key features of the UVM verification methodology is the reusable components and standardized hierarchical structure. The structure of its UVM workbench includes three parts from top to bottom: the top-level (simulation) file testbench, the interface layer interface and the part to be tested DUT. Among them, 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 the present invention.

[0021] In one embodiment, Figure 6 As shown, a CANFD verification system based on a 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 transmit sequencer (tx_sequencer), a transmit driver (Tx_driver), a transmit interface (tx_vif), a scoreboard (scoreboard), a receive monitor (rx_monitor), a receive interface (rx_vif), and a CANFD data sequence / CAN data sequence. The register sequencer, register driver, and register interface constitute a configuration and transmission component, which processes a CAFND data sequence or a CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain register configuration information and sends this register configuration information to the CANFD module under test. The register configuration information is used to configure register read and write information of the CANFD module and control the CANFD module to send required data.

[0022] The data transmission component, consisting of a transmit sequencer, transmit driver, and transmit interface, processes the CAFND data sequence or CAN data sequence generated from the CANFD data sequence / CAN data sequence to obtain the data required to be transmitted by the CANFD module. This data is then sent from the bus to the scoreboard via the TLM mechanism. This data required to be transmitted by the CANFD module includes error-injected data. The receive monitor and receive interface comprise the receive component, which issues an ACK response based on the ACK bit of the bus data frame. This data is then placed into the CAFND data sequence or CAN data sequence and sent to the scoreboard via the TLM mechanism. The data received by the receive component represents the data actually transmitted by the CANFD module and features the same resynchronization functionality as the CANFD module. The scoreboard compares the data required to be transmitted by the CANFD module with the data received by the receive component, determining the data's correctness and providing the verification result for the tested CANFD module.

[0023] It can be understood that in order to verify that the CANFD module function is abnormal due to the different sending timings of the frame interval and the frame idle, the following UVM (Universal Verification Methodology) verification system is proposed. The platform architecture of the UVM verification system can be as follows: Figure 6 As shown in the figure, the platform architecture verifies the CANFD module, eliminating the need for integrated full-chip design under test. "env" represents the system environment, "reg_agent" represents the register agent component, and "rx_agent" represents the receive agent component. The UVM verification system includes a register sequencer, register sequencer, register driver, register interface, transmit sequencer, transmit driver, transmit interface, scoreboard, receive monitor, receive interface, and CANFD / CAN data sequence. The CANFD / CAN data sequence, also known as the "canfd_sequence" / "can_sequence" (transaction sequence), is responsible for generating CANFD / CAN protocol transactions (such as the start of frame (SOF), data segment, and bit timing operations).

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

[0025] The sending sequencer, sending driver and sending interface together constitute the data sending component that can send data frames. The CAFND data sequence or CAN data sequence sent by it contains the data frame information that the CANFD module needs to send. This information is sent to the sending driver through the sending sequencer. The sending driver extracts the data frame information and then forms a bus through the sending interface and the DUT's sending line according to the frame information in the sequence and sends it to the DUT's receiving line.

[0026] The receive monitor and receive interface form a receiving component capable of receiving data frames on the bus and providing ACK responses. The receive monitor can extract data frames from the bus and provide ACK responses to the ACK bits of the bus data frames through the receive interface. The received data frames are then placed into the CAFND data sequence or CAN data sequence and sent to the scoreboard through the TLM (Transaction-Level Modeling) mechanism of the UVM verification system.

[0027] That is to say, in addition to the data frames successfully sent by the data sending component being sent to the scoreboard 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 scoreboard. The scoreboard will compare the data frames successfully sent by the data sending component and the data frames successfully received from the DUT, and judge based on the competition situation whether the data that the CAFND module needs to send is sent to the bus after competition, and whether it is consistent with the data frame received by the receiving component, thereby judging the correctness of the data frame content under competition and the correctness of the competition mechanism of the CAFND module under test.

[0028] Specifically, the data sending component will transfer the data that needs to be sent by the DUT to the ideal sending data cache (exp_tx_fifo) through the ideal sending data analysis import port (uvm_analysis_imp_exp_tx_ch) of the TLM mechanism of the UVM verification system, and the receiving component will transfer the received data to the actual receiving data cache (act_rx_fifo) through the actual receiving data analysis import port (uvm_analysis_imp_act_rx_ch) of the TLM mechanism of the UVM verification system. The scoreboard will extract the sent data and the received data through these two caches for consistency comparison, thereby judging the correctness of the data to verify whether the function of the CANFD module under test is normal.

[0029] The CANFD verification system based on the UVM verification platform mentioned above can fully verify the functions and performance of the CANFD module through the designed verification system supporting test methods such as precise control of transmission timing, simulated resynchronization function, error injection testing, multi-protocol component separation design, and flexible bit timing configuration. For example, the UVM verification system supports the verification of CANFD modules with different frequencies and sampling rates through configuration parameters, ensuring the performance and reliability of the CANFD module under different conditions. It also pays attention to the boundary conditions of frame intervals and frame idles, ensuring that the verification system can fully cover all scenarios that may cause synchronization problems. The verification process fully covers boundary conditions and ensures the stability and reliability of the tested CANFD module under extreme conditions. At the same time, the verification system can change the sent value at any position in the transmitted frame, thereby introducing CRC errors or format errors, etc., and the data transmission component will not send error frames, thereby verifying the error mechanism of the tested CANFD module and comprehensively testing the error handling capability and robustness of the tested CANFD module.

[0030] The functions of the tasks and signals in this manual are shown in Table 1: Table 1

[0031] In one embodiment, during the transmission of the CAN FD ISO extended frame, the sending driver includes the following processes in the wait_free task of the running phase: The first process: detects that the CANFD module is at the last bit of the frame interval, triggering the state machine of the data sending component to enter the data sending state; Second process: Randomly pull up the CAN_BUS_FREE signal within two bit times to start sending data frames; The third process monitors bus level changes. If a falling edge occurs on the bus, the CAN_BUS_FREE signal is randomly raised for a specific duration. If either the second or third process starts, the other immediately stops. After the tx_bus task in the main phase is initiated, the state machine enters the frame start state and begins counting different time segments. After each segment is counted, the corresponding operation is performed. These operations include transmitting data bits and updating status, performing bit stuffing during transmission, and waiting for the bus to idle and retransmitting the data frame if arbitration failure is detected in the arbitration phase.

[0032] Specifically, the transmit driver plays a key role in transmitting CAN FD ISO extended frames. Its wait_free task during the run phase (run_phase) includes the following three main processes. The first process involves the transmit driver detecting whether the CAN FD module under test is in the last bit of the frame interval. Upon detecting this state, the data transmission component's state machine is triggered, entering the data transmission state. At this point, two other processes are initiated: the second process randomly pulls the CAN_BUS_FREE signal high within two bit times to initiate data frame transmission. The third process monitors bus level changes. If a falling edge occurs on the bus (indicating data transmission and a frame start marker), the CAN_BUS_FREE signal is randomly pulled high for a specific duration. Once any of the other two processes is initiated, the other process immediately stops. The specific duration can be determined by an acceptable delay range to ensure accurate sampling. For example, if the acceptable delay range is SEG2 duration as described in the background, the specific duration can be set to SEG2 duration. Alternatively, if transmission and reception delays are not considered, the specific duration can also be set to SEG2 duration.

[0033] like Figure 7 As shown in the figure, after the tx_bus task in the main phase (main_phase) is initiated, the state machine performs a series of operations in sequence: the state machine first enters the Start of Frame (SOF) state and begins counting different time segments (such as SS, SEG1, and SEG2). After counting each time segment, the corresponding operation is performed, such as transmitting data bits and updating the status. Bit stuffing is also performed during the transmission process to ensure data integrity and correctness. If arbitration failure is detected in the arbitration phase, the state machine re-enters the Wait for Bus Idle state and resends the data frame.

[0034] Figure 7 In the figure, ID is the identifier, IDE is the identifier extension bit, SRR is the substitute remote request bit, RO and RRS are the receive status flags, Data is the data segment, FDF is the flexible data rate bit, BRS is the bit rate switch, and ESI is the error status indication.

[0035] In one embodiment, the calculation and verification operations performed by the sending driver in different communication stages include: calculating the CRC value and filling it in the CRC stage; checking whether the ACK response is received in the ACK stage, and if not, entering the error state; continuously monitoring the bus status during the sending process, and if a data error is detected, recording the abnormal information and performing corresponding error correction.

[0036] Specifically, the transmit driver also performs calculations and verifications during various communication phases, such as the DLC, STC, CRC, and ACK phases. For example, during the CRC phase, the transmit driver calculates and pads the CRC value. During the ACK phase, the transmit driver checks whether an ACK response has been received. If not, an error state is entered. Furthermore, during the transmission process, the transmit driver continuously monitors the bus status to ensure consistency between transmitted and received data. If a data error is detected, the transmit driver records the anomaly and takes appropriate corrective measures, such as stopping transmission and attempting to resend the data frame.

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

[0038] It is understandable that Figure 8 As shown in the figure, the receive monitor is responsible for monitoring bus signals and receiving data frames. During the run phase (rx_wait_free), the receive monitor continuously monitors the bus status. When the receive monitor detects a continuous high level on the bus, indicating the last bit of the interframe interval, it triggers the corresponding signal to start the rx_bus task. The receive monitor then waits for a low level on the bus (signaling the start of data transmission) and initiates the Tq counting process, sequentially counting different time segments.

[0039] Specifically, during the counting process, if a falling edge is detected on the bus in SEG1, it indicates that the previous data bit was delayed. At this point, the count value is reset and the count restarts from the SS segment. Similarly, if a falling edge is detected in SEG2, it indicates that the transmitted bit ended prematurely, the count stops, and the next bit sampling begins immediately. This mechanism ensures accurate and synchronized data reception.

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

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

[0042] During the reception process, the receive monitor also performs bit stuffing checks to ensure data correctness. Once the entire data frame is received, the received data is stored in the CAN FD data sequence and passed to the scoreboard via the UVM verification system's TLM mechanism for further processing and verification. Through these functions, the receive monitor effectively ensures the accuracy and reliability of data reception while also effectively managing and handling errors during the reception process.

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

[0044] The aforementioned verification system can be built using the existing SystemVerilog language and adhere to the UVM verification methodology. It can be configured using components within the UVM verification platform based on the verification interaction functionality required. For example, the 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 that occur during a test, such as inputs, outputs, and timing relationships. The verification sequence library provides a structured way to organize and call these verification sequences. When used to manage verification sequences, the verification sequence library provides a central location for users to register, store, and retrieve customized verification sequences. Users can register their verification sequences with the verification sequence library to make them accessible and executable during testing. This registration is typically completed during the initialization phase of the test environment. Once a verification sequence is registered, other components (such as tests and other verification sequences) can call these sequences through the verification sequence library. This allows test scenarios to organically combine different sequences to create complex test cases. The verification sequence library can support hierarchical structures, 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 during runtime. Therefore, when performing verification tests, users can use the verification sequence library to randomly configure verification sequences according to the verification needs of the CANFD module, thereby supporting more complete verification tests.

[0045] Each module in the CANFD verification system based on the UVM verification platform can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a device with data processing capabilities in hardware form, or can be stored in the memory of the aforementioned device in software form, 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 devices already available in the art.

[0046] In some embodiments, in the field of integrated circuit (IC) design and verification, the CAN FD bus controller (specifically, the CAN FD module) is a key component of the chip, and its performance and reliability directly impact the quality and stability of the entire chip. The verification system of the present invention focuses on verifying the CAN FD bus controller in the IC. During the chip design phase, the verification system rigorously verifies the CAN FD bus controller, enabling early detection of potential design flaws and issues. For example, during simulating CAN FD bus communication, the verification system can precisely control transmission timing to simulate various complex scenarios, such as varying transmission timings for interframe intervals and idle frames, as well as bit field deviations, to verify the proper functioning of the CAN FD bus controller's synchronization mechanism under these conditions. Furthermore, the verification system includes a simulated resynchronization function, enabling verification of the sampling accuracy of the receiving unit when the bit field varies. Furthermore, by introducing errors into any segment of a data frame, the CAN FD bus controller's error handling mechanism can be comprehensively tested to ensure its correct response to error frames.

[0047] During the chip verification phase, the aforementioned verification system can verify CAN FD modules with different frequencies and sampling rates, supporting a variety of CAN FD frame formats to meet the needs of different IC designs. These verification efforts can effectively improve the quality and reliability of the CAN FD bus controller in the IC, reduce the risk of chip failure in actual applications, and provide strong support for the successful development and mass production of the IC.

[0048] In general, the use of the above-mentioned verification system can effectively optimize the CANFD verification process, save time and resources, and improve development efficiency, thereby laying a technical foundation for the development of higher quality and more reliable CANFD products and enhancing its technological competitiveness in fields such as automotive electronics and industrial control.

[0049] In one embodiment, 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 the UVM verification platform. The method includes a register sequence, a register sequencer, a register driver, a register interface, a sending sequencer, a sending driver, a sending interface, a scoreboard, a receiving monitor, a receiving interface, and a CANFD data sequence / CAN data sequence. The register sequencer, the register driver, and the register interface constitute a configuration sending component, the sending sequencer, the sending driver, and the sending interface constitute a data sending component, and the receiving monitor and the receiving interface constitute a receiving component.

[0050] The CAN FD verification method based on the UVM verification platform may include the following processing steps S10 to S16: Step S10, processing the CAFND data sequence or CAN data sequence generated by the configuration sending component according to the CAN FD data sequence / CAN data sequence to obtain register configuration information, and sending the register configuration information to the CAN FD module under test; the register configuration information is used to configure the register read and write information of the CAN FD module and control the CAN FD module to send the data to be sent; Step S12: After the data sending component processes the CAFND data sequence or CAN data sequence generated according to the CANFD data sequence / CAN data sequence to obtain the data required to be sent by the CANFD module, the data is sent from the bus to the scoreboard through the TLM mechanism; the data required to be sent by the CANFD module includes the error-injected data; 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 the CAN data sequence, and sends it to the scoreboard 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; Step S16: perform consistency comparison between the data to be sent by the CANFD module and the data received by the receiving component through the scoreboard, and obtain the verification result of the tested CANFD module after judging the correctness of the data.

[0051] The CANFD verification method based on the UVM verification platform described above, through 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. It can fully verify the function and performance of the CANFD module. For example, the UVM verification system supports the verification of CANFD modules with different frequencies and sampling rates through configuration parameters, ensuring the performance and reliability of the CANFD module under different conditions. It also pays attention to the boundary conditions of frame intervals and frame idles, ensuring that the verification system can fully cover all scenarios that may cause synchronization problems. The verification process fully covers boundary conditions and ensures the stability and reliability of the tested CANFD module under extreme conditions. At the same time, the verification system can change the sent value at any position in the transmitted frame, thereby introducing CRC errors or format errors, etc., and the data transmission component will not send error frames, thereby verifying the error mechanism of the tested CANFD module and comprehensively testing the error handling capability and robustness of the tested CANFD module.

[0052] In one embodiment, during the transmission of the CAN FD ISO extended frame, the sending driver includes the following processes in the wait_free task of the running phase: The first process: detects that the CANFD module is at the last bit of the frame interval, triggering the state machine of the data sending component to enter the data sending state; Second process: Randomly pull up the CAN_BUS_FREE signal within two bit times to start sending data frames; The third process monitors the bus level changes. If a falling edge appears on the bus, the CAN_BUS_FREE signal is randomly pulled high within a specific time length. When any one of the second and third processes starts, the other process stops immediately.

[0053] After the tx_bus task in the main phase is started, the state machine first enters the frame start state and begins counting different timing segments. After counting each timing segment, the corresponding operation is performed; the corresponding operations include sending data bits and updating the status, performing bit stuffing operations during the sending process, and waiting for the bus to be idle again and resending the data frame when arbitration failure is detected in the arbitration segment.

[0054] In one embodiment, the calculation and verification operations performed by the sending driver in different communication stages include: calculating the CRC value and filling it in the CRC stage; checking whether the ACK response is received in the ACK stage, and if not, entering the error state; continuously monitoring the bus status during the sending process, and if a data error is detected, recording the abnormal information and performing corresponding error correction.

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

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

[0057] It can be understood that for the specific limitations of the CAN FD verification method based on the UVM verification platform, please refer to the corresponding limitations of the CAN FD verification system based on the UVM verification platform above, which will not be repeated here.

[0058] It should be understood that although Figure 9 The steps in the diagram are shown in the order 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 restriction for the execution of these steps, and these steps can be executed in other orders. Figure 9At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0059] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. 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 above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may 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), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus DRAM (RDRAM), and DDR DRAM.

[0060] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, 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.

[0061] The above embodiments merely illustrate several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of the present invention.

Claims

1. A CANFD verification system based on UVM verification platform, characterized in that: Including register sequence, register sequencer, register driver, register interface, transmit sequencer, transmit driver, transmit interface, scoreboard, receive monitor, receive interface and CANFD data sequence / CAN data sequence; The register sequencer, register driver and register interface constitute the configuration sending component, which is used to process the CAFND data sequence or CAN data sequence generated according to the CANFD data sequence / CAN data sequence to obtain 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 and write information of the CANFD module and control the CANFD module to send the data to be sent; The data transmission component consists of a transmission sequencer, a transmission driver, and a transmission interface. It is used to process the CAFND data sequence or CAN data sequence generated by the CANFD data sequence / CAN data sequence to obtain the data required to be sent by the CANFD module, and then send it from the bus to the scoreboard through the TLM mechanism. The data required to be sent by the CANFD module includes error-injected data. The receiving monitor and receiving interface form the receiving component, which is used to give an 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 then send it to the scoreboard 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 scoreboard is used to perform consistency comparison between the data that the CANFD module needs to send and the data received by the receiving component. After determining the correctness of the data, the verification result of the tested CANFD module is obtained.

2. The CANFD verification system based on the UVM verification platform according to claim 1, wherein During the transmission of the CANFD ISO extended frame, the sending driver includes the following processes in the wait_free task in the running phase: The first process: detects that the CANFD module is at the last bit of the frame interval, triggering the state machine of the data sending component to enter the data sending state; Second process: Randomly pull up the CAN_BUS_FREE signal within two bit times to start sending data frames; The third process monitors the bus level changes. If a falling edge appears on the bus, the CAN_BUS_FREE signal is randomly pulled high within a specific time period. When either the second or third process starts, the other process stops immediately. After the tx_bus task in the main phase is started, the state machine first enters the frame start state and begins counting different timing segments. After counting each timing segment, the corresponding operation is performed; the corresponding operations include sending data bits and updating the status, performing bit stuffing operations during the sending process, and waiting for the bus to be idle again and resending the data frame when arbitration failure is detected in the arbitration segment.

3. The CANFD verification system based on UVM verification platform according to claim 1 or 2, wherein The calculations and verification operations performed by the sending driver at different communication stages include: Calculate the CRC value and fill it in the CRC stage; In the ACK phase, check whether the ACK response is received. If not, it will enter the error state; The bus status is continuously monitored during the transmission process. If a data error is detected, the abnormal information is recorded and the corresponding error correction is performed.

4. The CANFD verification system based on the UVM verification platform according to claim 1, wherein When the receive monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level on the bus and starts the Tq counting process.

5. The CANFD verification system based on the UVM verification platform according to claim 4, wherein After receiving the DLC segment, the receiving monitor determines the number of bits in the subsequent data segment based on the received DLC value; After the STC segment is received, the receiving monitor compares the ideal STC value with the actual received value. If an error is found, an error report is generated; During reception, the receive monitor calculates and verifies the CRC and performs error handling if an error is detected.

6. A CANFD verification method based on UVM verification platform, characterized in that, The invention 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 transmission sequencer, a transmission driver, a transmission interface, a scoreboard, a reception monitor, a reception 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 transmission sequencer, the transmission driver and the transmission interface constitute a data transmission component, and the reception monitor and the reception interface constitute a reception component. The CANFD verification method based on the UVM verification platform includes the following steps: The CAFND data sequence or CAN data sequence generated by the configuration sending component is processed according to the CANFD data sequence / CAN data sequence to obtain register configuration information, and the register configuration information is sent to the CANFD module under test; 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 to be sent; After the data transmission component processes the CAFND data sequence or CAN data sequence generated by the CANFD data sequence / CAN data sequence to obtain the data that the CANFD module needs to send, it is sent from the bus to the scoreboard through the TLM mechanism; the data that the CANFD module needs to send includes the error-injected data; 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 scoreboard 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 scoreboard is used to compare the consistency of the data that the CANFD module needs to send and the data received by the receiving component. After judging the correctness of the data, the verification result of the tested CANFD module is obtained.

7. the CANFD verification method based on UVM verification platform according to claim 6, is characterized in that, During the transmission of the CANFD ISO extended frame, the sending driver includes the following processes in the wait_free task in the running phase: The first process: detects that the CANFD module is at the last bit of the frame interval, triggering the state machine of the data sending component to enter the data sending state; Second process: Randomly pull up the CAN_BUS_FREE signal within two bit times to start sending data frames; The third process monitors the bus level changes. If a falling edge appears on the bus, the CAN_BUS_FREE signal is randomly pulled high within a specific time period. When either the second or third process starts, the other process stops immediately. After the tx_bus task in the main phase is started, the state machine first enters the frame start state and begins counting different timing segments. After counting each timing segment, the corresponding operation is performed; the corresponding operations include sending data bits and updating the status, performing bit stuffing operations during the sending process, and waiting for the bus to be idle again and resending the data frame when arbitration failure is detected in the arbitration segment.

8. The CANFD verification method based on UVM verification platform according to claim 6 or 7, wherein The calculations and verification operations performed by the sending driver at different communication stages include: Calculate the CRC value and fill it in the CRC stage; In the ACK phase, check whether the ACK response is received. If not, it will enter the error state; The bus status is continuously monitored during the transmission process. If a data error is detected, the abnormal information is recorded and the corresponding error correction is performed.

9. The CANFD verification method based on UVM verification platform according to claim 6, wherein When the receive monitor detects a continuous high level on the bus, it starts the rx_bus task, waits for a low level on the bus and starts the Tq counting process.

10. The CANFD verification method based on the UVM verification platform according to claim 9, wherein After receiving the DLC segment, the receiving monitor determines the number of bits in the subsequent data segment based on the received DLC value; After the STC segment is received, the receiving monitor compares the ideal STC value with the actual received value. If an error is found, an error report is generated; During reception, the receive monitor calculates and verifies the CRC and performs error handling if an error is detected.

Images