UVM-based verification system and verification platform for verifying CANFD protocol

Abstract

The embodiment of the invention discloses a verification system and a verification platform for verifying a CANFD protocol based on a UVM, and relates to the field of verification. Compared with a traditional encryption type tool manufacturer product, the UVM has the advantages that the user friendliness and the debugging efficiency are remarkably improved, and the learning threshold and the debugging difficulty are reduced by opening core drive logic and random constraints. The method is characterized in that the abnormal and error scene test is highly flexible, frame bits are allowed to be accurately controlled to simulate illegal flow, and the test coverage rate and accuracy are enhanced. Meanwhile, the multi-mode filtering support and the out-of-frame information marking function provide abundant debugging means and deep insight for design verification, and particularly, great convenience and high efficiency are shown when the BUG is positioned and solved.

Description

Technical Field

[0001] The present application relates to the field of verification, and in particular to a UVM-based verification system and verification platform for verifying the CANFD protocol. Background Art

[0002] The CANFD bus protocol is an extension and upgrade of the CAN2.0 protocol. It has the characteristics of high fault tolerance and is a commonly used communication interface protocol in industrial-grade and automotive-grade SOC (system on chip), MCU (microcontroller), DSP (digital signal processor) and other chips. Chip verification is one of the important links in chip research and development. Due to the widespread use of the CANFD bus in industrial-grade and automotive-grade chips, many verification scenarios require the CANFD bus protocol to send and receive data. At this time, the device that can abstract and simplify the CANFD protocol at the behavioral level and accurately simulate the CANFD protocol to send and receive data information at the signal level is called CANFD VIP (Verification Intellectual Property).

[0003] All major EDA vendors have their own CANFD-VIP, which has been widely used. The CANFDVIP of tool vendors usually only provides a brief introduction to the members and methods of UVM (Universal Verification Methodology) components such as Sequence and Component, and only opens the underlying callback functions of each transmission stage (usually cycle level), while the internal core driver logic and internal random constraints are encrypted. Users can only use the callback functions provided to configure and debug the behavior and status of the VIP. When complex scenarios and timing need to be tested, the restrictions on the use of constraints and callback functions will require multiple attempts to debug before it can run correctly, which seriously reduces the verification efficiency. This also requires users to be very familiar with the CANFD protocol, and also requires users to be very familiar with the architecture of the VIP and the transmission stages corresponding to the VIP callback functions, which brings a high learning curve to users. Summary of the invention

[0004] The embodiment of the present application provides a verification system and verification platform for verifying the CANFD protocol based on UVM, which can solve the verification problem of the existing CANFD protocol. The technical solution is as follows:

[0005] In a first aspect, an embodiment of the present application provides a UVM-based verification system for verifying a CAN protocol, wherein the UVM model includes: a protocol driver, a monitor, a sequence generator, a sequence library, a scoreboard, and a configuration component;

[0006] The protocol driver and the scoreboard use analysis_fifo to send and receive transmission transactions, and the monitor and the scoreboard use analysis_fifo to send and receive transmission transactions; the protocol driver is connected to the RTL to be tested, the monitor is connected to the RTL to be tested, the sequence library communicates with the sequence generator, and the sequence generator communicates with the protocol driver;

[0007] The configuration component is used to configure the CAN protocol type, baud rate parameters and filter parameters;

[0008] The sequence generator is used to generate a transmission transaction according to the sequence in the sequence library, and send the transmission transaction to the protocol driver;

[0009] The protocol driver generates a timing signal based on the baud rate parameters of the configuration component, drives the bit stream, bit stream flag, and various debug flag signals in the transmission transaction to the virtual interface, detects errors on the virtual interface and sends error frames, and switches the fast and slow baud rates at specified positions. When the transmission transaction enables the transmission of error bit streams, the normal bit stream is driven after the error bit streams are driven for a specified number of times;

[0010] The monitor is used to receive frames on the bus and switch between fast and slow baud rates at specified positions, and can also detect errors on the bus and send error frames;

[0011] The transmission transaction is used to generate a correct or abnormal bit stream of the frame, a flag bit of the bit stream, and additional marking information. The CRC sequence is calculated according to the frame information and the protocol type, the frame is converted into an initial bit stream, and the initial bit stream is filled with stuffing bits and STUFF_COUNT according to different protocols to obtain a normal bit stream; if the abnormal bit stream is enabled, the specified bit is modified based on the normal bit stream according to the selected abnormal mode to obtain an abnormal bit stream.

[0012] The scoreboard is used to compare the transmission transactions received and sent, support multiple frame ID filtering modes and frame type filtering modes, support inverse calculation of filter numbers, detect whether the bit stream transmitted on the bus is an expected frame, and whether other marking information meets expectations.

[0013] The virtual interface is used to connect the VIP environment and the module to be tested.

[0014] In a second aspect, an embodiment of the present application provides a verification platform, including the above-mentioned verification system.

[0015] The beneficial effects brought about by the technical solutions provided by some embodiments of the present application include at least:

[0016] Compared with similar products provided by traditional tool manufacturers, the UVM model of this application shows significant technical advantages and innovations in user experience. The full opening of its core drive logic and internal random constraint mechanism not only abandons the limitations of traditional encryption processing, but also greatly simplifies the verification process, reducing the learning threshold and debugging costs of users. Users can directly understand and manipulate the internal operating mechanism of VIP, thereby achieving more efficient and intuitive problem location and solution, significantly shortening the product verification cycle. The verification system of this application shows unprecedented flexibility and accuracy when testing abnormal and error scenarios. By implementing the bit stream of the frame in the transmission transaction, the driver no longer parses the frame and fills the padding bit, focusing on driving the bit stream and detecting errors. Compared with some similar products that implement the parsing of the frame and the filling of the padding bit in the driver, the code of this application is more concise and less complex. By allowing users to directly modify any bit in any legal frame to simulate illegal or abnormal bit stream transmission, this innovative function provides verification engineers with powerful tools, enabling them to accurately construct complex and diverse test cases, comprehensively cover and verify the responsiveness of the system under different extreme conditions, and ensure the robustness and reliability of the design. The verification system of this application also integrates diversified filtering modes, which not only supports the calculation of filter numbers based on the original frame ID. This application also introduces support for extra marking information outside the frame and debug marking signals, especially the introduction of bitstream flags, which makes the information of the frame bitstream more intuitive during simulation, greatly improving the verification efficiency. These advanced features greatly enrich the verification methods, allowing engineers to accurately locate design defects based on detailed information flows when debugging. At the same time, through flexible filtering configuration, irrelevant information can be effectively filtered out, focusing on key problem areas, and significantly improving debugging efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 It is a schematic diagram of the architecture of the UVM model provided in the embodiment of the present application;

[0019] Figure 2 is a schematic diagram of the principle of TLM connection provided in an embodiment of the present application;

[0020] Figure 3 It is a schematic diagram of pointer transfer of the configuration component in the UVM model provided by the embodiment of the present application;

[0021] Figure 4 It is a schematic diagram of the execution flow of the tx_drv task in the protocol driver provided by this application;

[0022] Figure 5 It is a schematic diagram of the execution of the state machine of the tx_drv task provided by this application;

[0023] Figure 6 It is a schematic diagram of the state machine execution flow of the receive_channel task in the monitor provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the objectives, technical solutions and advantages of the present application more clear, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0025] See also Figure 1 , a UVM-based verification system for verifying the CANFD protocol is provided for the embodiment of the present application. A UVM model is deployed in the verification system, and the UVM model is Figure 1 The CANFD-VIP (ENV) in the UVM model includes: configuration component (Config), protocol driver (Driver), monitor (Monitor), transmission transaction (Transaction), scoreboard (Scoreboard), sequencer (sequencer), sequence library (sequence) and virtual interface (Interface).

[0026] Among them, the protocol driver communicates with the sequencer, the scoreboard and the RTL to be tested respectively, the monitor communicates with the RTL to be tested and the scoreboard respectively, the UVM model and the RTL to be tested communicate through a virtual interface, and the monitor and the RTL to be tested communicate through a virtual interface.

[0027] In the embodiment of the present application, the UVM model is used as a conventional container to encapsulate and contain other components and implement the TLM mechanism connection of the UVM model.

[0028] See also Figure 2 As shown, the TLM connection in the UVM model is realized by analysis_fifo, and the protocol driver and monitor actively send transmission transactions (Transaction) to analysis_fifo, and the scoreboard actively obtains transmission transactions from analysis_fifo. Compared with using the IMP interface to realize TLM connection, the UVM model of the present application uses a method that enables the scoreboard to also have the initiative of control, and when the scoreboard realizes the function, there is no need to consider the working state of other components.

[0029] In the embodiment of the present application, the configuration component is one of the cores of the UVM model and is used to configure the parameters of the UVM model.

[0030] Configure the following parameters:

[0031] 1. Communication protocol type: the CANFD protocol of this application can be the BOSCH CANFD protocol, i.e., the non-ISOCANFD protocol, and the optional ISO2015 CANFD protocol. Both options are compatible with the CAN2.0 protocol by default.

[0032] 2. Baud rate parameters, including all parameters of slow baud rate and all parameters of fast baud rate: synchronization width, transmission width, phase 1, phase 2, synchronization jump width.

[0033] 3. Filter parameters, including: filter enable, filter encoding, filter mask, filter mode selection, standard frame filter selection, extended frame filter selection, and FD frame filter selection.

[0034] In the embodiment of the present application, the UVM model can support the synchronous modification of configuration components in all components at any time.

[0035] The implementation is as follows:

[0036] 1. The configuration component has only one instance in the UVM model (CANFD_VIP) in the entire simulation environment, and all other sub-modules are handles (i.e. pointers).

[0037] 2. Configuration component pointer transfer in the simulation environment, see Figure 3 As shown:

[0038] In a test sequence of simulation, the pointer of the virtual sequencer can be obtained through the p_sequencer of the UVM model. The virtual sequencer contains a pointer to the CANFD_VIP sequencer.

[0039] 3. At any time in the simulation, in a test sequence, the configuration component of CANFD_VIP can be modified in the following way: Take the modification of slow baud rate phase 1 as an example: p_sequencer.can_vip_sequencer.Config.s_seg1 = 'h5;

[0040] In an embodiment of the present application, a transmission transaction refers to a data packet transmitted between each component of the UVM model, mainly comprising frame information and some frame processing functions. Constrained in the sequence library, a sequencer is generated and sent to a protocol driver, and the protocol driver sends the transmission transaction key bit stream to the bus.

[0041] The frame information is as follows:

[0042] 1. Configuration component pointer. During randomization, an instance of the configuration component is obtained from the sequencer.

[0043] 2. Frame type: data frame, FD data frame, remote frame, extended data frame, FD extended data frame, extended remote frame;

[0044] 3. Communication protocol type, during randomization, is constrained by the communication protocol type of the configured component.

[0045] 4. Bit field information of the frame, for example:

[0046] sof, id, rtr, ifr, edl, srr, esi, brs, r0, r1, crc, crcd, ack, ackd, sof, dlc, data, stuff_count, etc.

[0047] 5. Other debugging information related to the frame, such as: message, timestamp, etc.

[0048] 6. Frame-related bitstream and bitstream flag.

[0049] 7. Illegal frame mode, illegal frame error bit, and illegal frame repetition times.

[0050] Among them, the frame processing function is as follows:

[0051] 1. post_randomize: A function that runs automatically after randomization. In this function, the following functions are called sequentially: crc calculation function, bitstream conversion function, and illegal frame bitstream conversion function.

[0052] 2. calculate_crc: CRC calculation function. The CRC value cannot be generated using random constraints and must be calculated based on the bit stream. First, convert the bit field before the frame CRC field into a bit stream, then insert stuffing bits into the bit stream. If it is the ISOCANFD protocol, insert stuff_count. Finally, use different CRC formulas and initial vectors to calculate the CRC value based on the protocol type, frame type, and data length.

[0053] 3. gen_frame_bit_q: Bitstream conversion function. When executing this function, the CRC value has been obtained, and the entire frame can be completely converted into a bitstream. When converting the bitstream of the CRC field, fill bits should be inserted according to different protocol types. The bitstream is stored in a queue. While converting the bitstream, a flag stream queue of the bitstream flag is generated.

[0054] 4. gen_frame_inject_err_q: A bitstream conversion function that inserts an error bit. If the transmission transaction allows the generation of an illegal frame, this function will be executed after the execution of gen_frame_bit_q (bitstream conversion function). This function will invert the bitstream of the normal frame at the bit specified by the variable "error bit of illegal frame" to obtain a bitstream of an illegal frame.

[0055] 5. r_item_fun: When the simulation environment reads out frame-related information from the RTL register and needs to restore the relevant information to the format of the transmission transaction, this function is executed. For example, when the RTR\IDE\EDL bit information is read out, the frame type can be restored through this information.

[0056] In an embodiment of the present application, a protocol driver is used to drive the bit stream in a transmission transaction to a bus. During this process, the bus needs to be monitored simultaneously. If an error is detected, an error frame needs to be sent. In addition, if it is a CANFD protocol (including ISO and non-ISO), the baud rate needs to be switched at a specified position.

[0057] The core of the protocol driver is main_phase and the tasks called by main_phase. The following tasks run in parallel in main_phase:

[0058] 1. get_transaction_channel: It is mainly used to handshake with the sequencer and receive the transaction sent by the sequencer, and store the transaction in the transaction queue. At the same time, the transaction is sent to the scoreboard through the TLM mechanism.

[0059] 2. slow_tq: slow baud rate processing task, obtains slow baud rate information through configuration component (Config), executes slow bit timing cyclically according to baud rate information, and drives corresponding flags on virtual interface at each stage of bit timing (synchronization stage sync, transmission stage prop, phase 1seg1, phase 2seg2), and drives a pulse signal at sample point.

[0060] 3. fast_tq: fast baud rate processing task, obtains fast baud rate information through configuration component (Config), executes fast bit timing cyclically according to baud rate information, and drives corresponding flags on virtual interface at each stage of bit timing (synchronization stage sync, transmission stage prop, phase 1seg1, phase 2seg2), and drives a pulse signal at sample point.

[0061] 4. rx_sample: monitors the rx line on the bus, selects slow_tq or fast_tq according to the switching baud rate signal on the virtual interface to select the sampling pulse signal for sampling. For the sampled value, the protocol filling rule will be detected for detection. If the filling rule is violated, an error signal will be driven to the virtual interface. There are two filling rules required by the protocol, one is "5 consecutive identical 1s are reversed", and the other is "fixed every 4 bits are reversed". The specific selection is determined by the switching signal on the virtual interface. For the sampled value, the eof status will also be detected. When the eof is detected, the filling bit detection will stop.

[0062] 5. tx_drv: tx_drv is the core driver task of the protocol driver. For the execution process of the tx_drv task, see Figure 4 As shown in the flowchart, it can be seen that in each cycle, the transaction queue is first checked to see if there is a transaction, and if there is a transaction, the transaction is taken out. If illegal frame transmission is enabled in the transmission transaction, the bit stream of the illegal frame is sent a certain number of times, and then the correct legal frame bit stream is sent.

[0063] When driving normal bit stream and illegal frame bit stream, a state machine is executed. The state machine has four states: TX_IDLE, TX_ERROR, TX_WAIT_EOF, TX_DEIVE. The state machine jumps on the sampling pulse signal of slow_tq or fast_tq. For the operation process of the state machine, see Figure 5 shown.

[0064] TX_IDLE: If there are frames to be sent, a 2-cycle interframe interval is performed to test the limit interval required by the protocol. If there are no frames to be sent, it will remain idle.

[0065] TX_ERROR: If any other state detects an error signal on the virtual interface, it will jump to the TX_ERROR state. This state will send an active error frame, but not a passive error frame, because sending a passive error frame is meaningless to the test object. After sending the error flag of the active error frame, it will detect how many "1"s there are on the rx line while sending the error delimiter. It will not end the error frame until 8 consecutive 1s (i.e., error delimiters) are detected, and jump to the TX_IDLE or TX_DRIVE state.

[0066] TX_DRIVE: At the sampling pulse signal of slow_tq or fast_tq, the bits in the bit stream sequence are sent in order, and the bits in the flag stream queue of the bit stream flag are sent to the virtual interface to locate the problem when checking the waveform. Each time it is sent, the error signal on the virtual interface is detected. If there is an error, it jumps to TX_ERROR. If there is no error, it jumps to TX_IDLE after sending EOF. If the arbitration is lost during the sending of the arbitration domain, the transmission will stop and jump to the TX_WAIT_EOF state.

[0067] TX_WAIT_EOF: After losing arbitration when sending a frame, jump to this state until EOF is detected on the bus and then jump to TX_IDLE.

[0068] 6) Drv_tmr_cnt: drives timestamps and transmits information to the virtual interface for debugging

[0069] In an embodiment of the present application, the monitor is used to receive frames on the bus. If it is a CANFD protocol (including ISO and non-ISO), it is also necessary to switch the fast and slow baud rates at a specified position.

[0070] The core of the monitor is the main_phase and the tasks called by the main_phase. The following tasks are run in parallel in the main_phase:

[0071] 1. slow_tq: slow baud rate processing task, obtains slow baud rate information through configuration component (Config), executes slow bit timing cyclically according to baud rate information, and drives corresponding flags on virtual interface at each stage of bit timing (synchronization stage sync, parameter stage prop, phase 1seg1, phase 2seg2), and drives a pulse signal at sample point.

[0072] 2. fast_tq: fast baud rate processing task, obtains fast baud rate information through configuration component (Config), executes fast bit timing cyclically according to baud rate information, and drives corresponding flags on virtual interface at each stage of bit timing (synchronization stage sync, parameter stage prop, phase 1seg1, phase 2seg2), and drives a pulse signal at sample point.

[0073] 3. rx_sample: monitors the rx line on the bus, selects slow_tq or fast_tq according to the switching baud rate signal on the virtual interface to select the sampling pulse signal for sampling. For the sampled value, the protocol filling rule will be detected for detection. If the filling rule is violated, an error signal will be driven to the virtual interface. There are two filling rules required by the protocol, one is "5 consecutive identical 1s are reversed", and the other is "fixed every 4 bits are reversed". The specific selection is determined by the switching signal on the virtual interface. For the sampled value, the eof status will also be detected. When the eof is detected, the filling bit detection will stop.

[0074] 4. receive_channel: It is the core driver task of the monitor. For the operation process of the state machine of the receive_channel task, see Figure 6 As shown. The state machine will make state jumps at the sample point pulse provided by slow_tq or fast_tq. Stuffing detection is performed while receiving the bit stream. Once a stuffing error is detected, the R_ERROR state is executed. In addition, in the R_CRC state, it will decide whether to detect the value of STUFF_COUNT according to the protocol type specified by the configuration component (Config). If the detection error occurs, the R_ERROR state will also be executed. In all states, if a format error occurs, the R_ERROR state will also be executed. The R_ERROR state will not send error frames, but only detect error frames. After detecting an error frame or receiving a frame, it will jump to R_IDLE. R_IDLE will continuously detect the level on the bus. Once a low level (ie SOF) is detected, it will jump to SOF and start the bit stream. In the process of receiving the bit stream, as shown in the state machine, different logical branches will be executed according to the value of the bit stream, and the bit stream will be identified as frames of different formats (data frame, extended data frame, FD data frame, extended FD data frame, remote frame, extended remote frame). In the R_EOF state, after receiving a complete frame of bit stream, the bit stream is converted into a transmission transaction and the transmission transaction is sent to the scoreboard through the TLM mechanism.

[0075] In an embodiment of the present application, the scoreboard compares whether the bit stream transmitted on the bus is an expected frame by comparing the transmitted and received transmission transactions.

[0076] The core of the scoreboard is main_phase and the tasks called by main_phase. The following tasks are called in main_phase:

[0077] 1. get_tx_transaction: Actively obtain the transmission transaction sent from drv through the TLM mechanism. If drv_to_scb_fifo is empty, it will block until the transmission transaction is obtained. After obtaining the parameter transaction of drv, it will be stored in the queue of tx_transaction_q for comparison.

[0078] 2. get_rx_transaction: Actively obtain the transmission transaction sent from mon through the TLM mechanism. If mon_to_scb_fifo is empty, it will block until the transmission transaction is obtained. After obtaining the parameter transaction of mon, it will be stored in the queue of rx_transaction_q for comparison.

[0079] 3. acf: filter function, which implements multiple filter modes and supports multiple filter modes, including:

[0080] a. The encoding mask matches and passes the filtering: that is, (mask[x]==0)?(id[x]==code[x]?pass:not_pass):pass.

[0081] b. Range filtering: code0<=id<=code1? pass: not_pass.

[0082] c. Standard frame filtering, that is, checking whether it is a standard frame, and then deciding whether to pass or not based on the standard frame filtering selection parameters of the configuration component.

[0083] d. Extended frame filtering, that is, checking whether it is an extended frame, and then deciding whether to pass or not based on the extended frame filtering selection parameters of the configuration component.

[0084] e. FD frame filtering, that is, checking whether it is an FD frame, and then deciding whether to pass or not based on the FD frame filtering selection parameters of the configuration component.

[0085] f. All pass, no filtering.

[0086] The filter number that will be passed after filtering and the ID record after filtering are used for comparison by the cmp function.

[0087] 4. cmp: comparison function, input two transmission transactions, compare the frame type, frame ID or filtered ID and filter number of the two, and if it is a data frame, compare the data in the data field.

[0088] Among them, it is usually the default to convert the frame read from the RTL to be tested into a CANFD_VIP transmission transaction, then pass it to the scoreboard, and then compare it with the transmission transaction obtained by the Driver or Monitor.

[0089] In an embodiment of the present application, a virtual interface is used to connect the UVM model and the RTL to be tested, and to provide a debugging signal.

[0090] The signal types between the UVM model and the RTL to be tested are as follows:

[0091] 1. Clock signal.

[0092] 2. reset signal.

[0093] 3. tx sends signal.

[0094] 4. rx receives signal.

[0095] For the sending node, the following debug signals are provided:

[0096] 1. Timing signals of slow baud rate: s_sync, s_prop, s_seg1, s_seg2, s_sjw, s_smp.

[0097] 2. Fast baud rate timing signals: f_sync, f_prop, f_seg1, f_seg2, f_sjw, f_smp.

[0098] 3. Protocol driver status bit signal: tx_station.

[0099] 4. Send all bit field identifiers of the bit stream: t_sof_flg, t_id2818_flg, t_id1700_flg, t_rtr_flg, t_srr_flg, t_dlc_flg, t_stuff_flg, etc.

[0100] For receiving nodes, the following debug signals are provided:

[0101] 1. Timing signals of slow baud rate: s_sync, s_prop, s_seg1, s_seg2, s_sjw, s_smp.

[0102] 2. Fast baud rate timing signals: f_sync, f_prop, f_seg1, f_seg2, f_sjw, f_smp.

[0103] 3. Protocol driver status bit signal: rx_station.

[0104] 4. Send all bit field identifiers of the bit stream: r_sof_flg, r_id2818_flg, r_id1700_flg, r_rtr_flg, r_srr_flg, r_dlc_flg, r_stuff_flg, etc.

[0105] The embodiments of the present application specifically include the following beneficial effects:

[0106] Optimize cross-language compilation and simulation process: By using SystemVerilog (SV) and UVM (Universal Verification Methodology) framework to build VIP (Verification IP) core, the complexity of cross-language compilation is greatly reduced, while keeping the code unencrypted to ensure unimpeded simulation process. This design allows users to quickly locate and solve fault points in a "compile-simulation" cycle, significantly improving verification efficiency.

[0107] Enhanced user-friendliness and optimized code architecture: pre-package basic methods and simplify parameter configuration to provide ordinary users with an intuitive and easy-to-use interface so that they can focus on high-level design abstractions rather than tedious details. Through training, ordinary users can quickly get started. At the same time, a highly cohesive and low-coupled code architecture is built for senior users to achieve highly integrated and unified functions, greatly reducing the cost of learning. In the transmission transaction, the bit stream of the frame is implemented, and the driver no longer parses the frame and fills the padding bits, but focuses on driving the bit stream and flag bits, and detecting errors. Compared with the way some similar products implement frame parsing and padding bits in the driver, the code of this application is simpler, less complex, and easier to debug and locate errors when used.

[0108] Real-time configuration and stimulus flexibility: Allowing real-time modification of backdoor access and VIP configuration during stimulus sequence, this feature provides unprecedented convenience and flexibility for experienced users, enabling them to easily cope with various complex verification scenarios.

[0109] Flexible simulation configuration and deconstraint process: Provides a wealth of configuration options to support multiple functions of simulated sending and receiving nodes. Keeps the code public and shows the deconstraint process in detail, making it efficient and intuitive to write extreme timing test stimuli, and promoting the comprehensiveness and depth of verification.

[0110] Multi-protocol support: VIP can be configured to support multiple CAN protocol communications such as CAN2.0, ISO2015-CANFD and non-ISO-CANFD to meet diverse testing needs.

[0111] Comprehensive frame processing and error simulation capabilities: Supports sending nodes to send all types of frames and has the ability to create erroneous communication scenarios, including modifying any bit of a legal frame to generate an illegal bit stream. The receiving node can receive all types of frames and return an error frame when encountering an illegal frame. It also detects and responds to all error types of the CAN protocol to ensure comprehensive coverage of verification.

[0112] Powerful error detection and filtering functions: It not only supports detection and response to various CAN protocol errors, but also provides flexibly configurable filtering functions, including encoding mask matching, range filtering, multiple frame type filtering, etc., to meet different verification requirements.

[0113] Accurate CRC verification and customization capabilities: Supports all CRC algorithms of CAN2.0, ISO2015-CANFD and non-ISO-CANFD protocols, and can customize the CRC initial sequence to simulate specific CRC errors, further enhancing the accuracy and flexibility of verification.

[0114] Support for additional frame marking information: Allows you to add additional information such as timestamps and custom tags outside the frame, providing more dimensional data support for the verification process.

[0115] CANFD baud rate switching function: supports dynamic baud rate switching of the CANFD protocol, simulating communication changes in real scenarios to ensure the comprehensiveness of verification.

[0116] Debug-friendly: The integrated debug marker signal and bitstream flag make it easier for users to quickly locate problems during the verification process and optimize the debugging experience.

[0117] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only storage memory, or a random access memory, etc.

[0118] The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A UVM-based verification system for verifying the CANFD protocol, characterized in that: The UVM model includes: protocol driver, monitor, transfer transaction, sequencer, sequence library, scoreboard, configuration component, and virtual interface; The protocol driver and the scoreboard use analysis_fifo to send and receive transmission transactions, and the monitor and the scoreboard use analysis_fifo to send and receive transmission transactions; the protocol driver is connected to the RTL to be tested, the monitor is connected to the RTL to be tested, the sequence library communicates with the sequence generator, and the sequence generator communicates with the protocol driver; The configuration component is used to configure the CAN protocol type, baud rate parameters and filter parameters; The sequence generator is used to generate a transmission transaction according to the sequence in the sequence library, and send the transmission transaction to the protocol driver; the protocol driver generates a timing signal based on the baud rate parameters of the configuration component, drives the bit stream, bit stream flag, and various debug mark signals in the transmission transaction to the virtual interface, detects errors on the virtual interface and sends error frames, and switches the fast and slow baud rates at the specified positions. When the transmission transaction enables the transmission of the error bit stream, the normal bit stream is driven after the error bit stream is driven for a specified number of times; The monitor is used to receive frames on the bus and switch between fast and slow baud rates at specified positions, and can also detect errors on the bus and send error frames; The transmission transaction is used to generate a correct or abnormal bit stream of the frame, a flag bit of the bit stream, and additional marking information. The CRC sequence of the frame is calculated according to the frame information and the protocol type, the frame is converted into an initial bit stream, and the initial bit stream is filled with stuffing bits and STUFF_COUNT according to different protocols to obtain a normal bit stream; if the abnormal bit stream is enabled, the bit position is modified based on the normal bit stream according to the selected abnormal mode to obtain an abnormal bit stream. The scoreboard is used to compare the transmission transactions received and sent, support multiple frame ID filtering modes and frame type filtering modes, support inverse calculation of filter numbers, detect whether the bit stream transmitted on the bus is an expected frame, and whether other marking information meets expectations. The virtual interface is used to connect the VIP environment and the module to be tested.

2. The method according to claim 1, characterized in that The protocol driver, sequencer, monitor and scoreboard are provided with handles of the configuration components.

3. The method according to claim 1, characterized in that The transmission transaction includes: configuration component pointer, frame type, communication protocol type, frame bit field information, normal bit stream converted from the frame, injected error bit, abnormal bit stream injected with error, bit stream flag bit, and number of times the abnormal bit stream is repeatedly sent; The frame processing function includes: a post_randomize function, a calculate_crc function, a gen_frame_bit_q function, a gen_frame_inject_err_q function, and an r_item_fun function.

4. The method according to claim 1, characterized in that The protocol driver runs multiple tasks in parallel: get_transaction_channel task, slow_tq task, fast_tq task, rx_sample task, and tx_drv task.

5. The method according to claim 1, characterized in that The monitor runs multiple tasks in parallel: slow_tq task, fast_tq task, rx_sample task, and receive_channel task.

6. The method according to claim 1, characterized in that The scoreboard runs multiple tasks in parallel: get_tx_transaction task, get_rx_transaction task, acf task, and cmp function.

7. The method according to claim 1, characterized in that The signals transmitted in the virtual interface include: a clock signal, a reset signal, a sending signal and a receiving signal, a bit stream flag signal, and various debug mark signals.

8. A verification platform, characterized in that: include: A verification system as claimed in any one of claims 1 to 7.

Images