UVM-based CAN controller stimulus sequence generation method, device and verification platform

Abstract

The present invention provides a UVM-based CAN controller stimulus sequence generation method, device, and verification platform, wherein the method includes the steps of: creating a TLM interface data class and a frame parameter data class and instantiating them into objects, and then encapsulating them into functions and tasks for CAN controller verification, so that the frame parameter data objects can be combined with the function to be verified of the CAN controller, randomizing the frame parameter data objects, conveniently calling functions and tasks, constraining and timing-controlling the TLM interface data objects, generating a desired stimulus sequence, and further generating a community of desired stimulus sequences to implement CAN controller application scenario simulation verification. When the stimulus sequence generation device performs CAN controller verification, the stimulus sequence generation device does not need to be modified for different CAN controller interfaces, thereby achieving reuse of the stimulus sequence generation device and improving the efficiency of CAN controller verification.

Description

Technical Field

[0001] The present invention belongs to the field of chip verification platform structure, and in particular relates to a UVM-based CAN controller excitation sequence generation method, device and verification platform. Background Art

[0002] Functional verification is a crucial process in the development cycle of specialized chips today. With the increasing complexity of chips and the constant pressure on project schedules, the research and exploration of cutting-edge functional verification technologies has become a hot topic in the field of specialized chip R&D.

[0003] Traditional functional verification technology relies on targeted testing written in Verilog. Test stimulus sequences are constructed for each characteristic of the design under test and applied to the design. Waveform and trace file observations are used to determine whether the target design achieves the intended functionality. Traditional Verilog verification technology is limited by static instantiation and cannot dynamically adapt to simulation conditions. The constructed test stimulus sequences have a low level of abstraction, and excessive test stimulus sequences are detrimental to project reuse and maintenance. The difficulty and workload of verification also increase exponentially with the scale and complexity of the design, resulting in a lack of efficiency in the verification process.

[0004] To meet the needs of efficient verification, UVM (Universal Verification Methodology), based on the SystemVerilog language, was officially launched by Accellera in February 2011 as a next-generation verification methodology. It draws on the strengths of different methodologies, including ERM, AVM, VMM, and OVM, integrating the best of many. Currently, the UVM standard has been developed to UVM1.2 and was officially declared a standard by the IEEE in 2017. The UVM methodology has been widely used in the chip development industry. It provides a basic class library and basic development framework based on the verification language. UVM's customized framework construction and test classes can help verifiers reduce the burden of environment construction, allowing them to focus more on developing verification plans and creating stimulus sequences.

[0005] The CAN bus is a type of fieldbus. Its numerous advantages, such as efficiency, flexibility, reliability, and cost-effectiveness, have led to its widespread use in industrial fields, vehicles, ships, and other fields. The CAN controller implements the sending and receiving of messages compliant with the CAN bus protocol. The CAN controller is compatible with both BasicCAN and PeliCAN operating modes. Its physical interface is primarily divided into a configuration interface (cfg_interface) and a bus interface (bus_interface). The configuration interface supports both Intel and Motorola modes of reading and writing, while the bus interface supports the CAN bus 2.0 protocol.

[0006] With the expansion of CAN bus applications and the rapid development of my country's process technology and chip design capabilities, CAN controllers have not only been developed as dedicated chips but are also widely integrated into large-scale chips such as SOCs. This results in different interfaces and control methods for CAN controllers used in different chips. CAN controllers are inherently characterized by a large number of internal registers, requiring flexible configuration at the application layer and numerous constraints. Therefore, the verification process for different CAN controllers places high demands on the commonality and reusability of the test scenarios constructed. Summary of the Invention

[0007] To address the above problems, the present invention provides a UVM-based CAN controller stimulus sequence generation method, device and verification platform, which can be applied to the simultaneous verification of multiple CAN controllers and can improve the verification efficiency of CAN controllers.

[0008] A UVM-based CAN controller excitation sequence generation method of the present invention comprises:

[0009] Create TLM interface data class and frame parameter data class;

[0010] Instantiating the TLM interface data class into a TLM interface data object and encapsulating it into a register operation task, instantiating the frame parameter data class into a frame parameter data object and encapsulating a parameter format conversion function;

[0011] According to the function to be verified of the CAN controller, randomizing the frame parameter data object, constraining and timing controlling the TLM interface data object, and generating an expected stimulus sequence corresponding to the function to be verified;

[0012] Organizing and coordinating a plurality of the expected excitation sequences to generate an expected excitation sequence community.

[0013] Furthermore, the frame parameter data class is a new class defined according to the message description of the CAN bus 2.0 protocol.

[0014] Furthermore, the frame parameter data class includes:

[0015] A data portion, wherein the data portion includes a dynamic array, a frame format, a frame type, a frame data length, and dynamic array frame data;

[0016] A basic constraint part, wherein the basic constraint part includes a feature description of the data part.

[0017] Furthermore, the TLM interface data class inherits the UVM Sequence Item class, including random type read / write data, address and read / write command parameters.

[0018] Furthermore, the register operation task includes:

[0019] Write operation tasks, read operation tasks and bit operation tasks on a single register.

[0020] Furthermore,

[0021] The parameter format conversion function is used to convert the internal variables of the frame parameter data object into constraint parameters that comply with the format of the internal send buffer register of the CAN controller.

[0022] Furthermore, when encapsulating the register operation task, an interface variable for transmitting the constraint parameter to the TLM interface data object is reserved.

[0023] Furthermore, after the step of encapsulating the TLM interface data object into a register operation task, the method further includes the following steps:

[0024] According to the function to be verified of the CAN controller, the register operation task is logically encapsulated into a verification task, and the verification task includes:

[0025] CAN controller initialization task, CAN send / receive task and CAN interrupt clearing task.

[0026] Furthermore, the method of generating an expected stimulus sequence corresponding to the function to be verified includes the following steps:

[0027] Randomizing the frame parameter data object according to a verification function of the CAN controller;

[0028] Passing the randomization result to the parameter format conversion function to obtain the output constraint parameters;

[0029] Passing the constraint parameters to the interface variables reserved by the register operation task;

[0030] The register operation task constrains the TLM interface data object, and organizes and controls the timing of a plurality of the TLM interface data objects to obtain an expected stimulus sequence corresponding to the function to be verified.

[0031] The present invention also provides a UVM-based CAN controller excitation sequence generation device, comprising:

[0032] A creation unit, used to create a TLM interface data class and a frame parameter data class;

[0033] An encapsulation unit, configured to instantiate the TLM interface data class into a TLM interface data object and encapsulate the object into a register operation task, instantiate the frame parameter data class into a frame parameter data object and encapsulate a parameter format conversion function;

[0034] A first generating unit is configured to randomize the frame parameter data object according to the to-be-verified function of the CAN controller, perform constraints and timing control on the TLM interface data object, and generate an expected stimulus sequence;

[0035] The second generating unit is configured to organize and coordinate a plurality of the expected stimulus sequences to generate the CAN controller expected stimulus sequence community.

[0036] Furthermore, the frame parameter data class is a new class defined according to the message description of the CAN bus 2.0 protocol.

[0037] Furthermore,

[0038] A data portion, wherein the data portion includes a dynamic array, a frame format, a frame type, a frame data length, and dynamic array frame data;

[0039] A basic constraint part, wherein the basic constraint part includes a feature description of the data part.

[0040] Furthermore, the first generating unit performs the following operation steps when generating the expected excitation sequence:

[0041] Randomizing the frame parameter data object according to a verification function of the CAN controller;

[0042] Passing the randomization result to the parameter format conversion function to obtain the output constraint parameters;

[0043] Passing the constraint parameters to the interface variables reserved by the register operation task;

[0044] The register operation task constrains the TLM interface data object, and organizes and controls the timing of a plurality of the TLM interface data objects to obtain an expected stimulus sequence corresponding to the function to be verified.

[0045] The present invention also provides a UVM-based CAN controller verification platform, comprising the aforementioned excitation sequence generating device of the present invention.

[0046] A UVM-based CAN controller stimulus sequence generation method of the present invention creates a TLM interface data class and a frame parameter data class and instantiates them into objects, which are then encapsulated into functions and tasks for CAN controller verification. This method enables the CAN controller to be combined with the function to be verified, randomizes the frame parameter data object, conveniently calls pre-packaged functions and tasks, constrains and performs timing control on the TLM interface data object, generates a desired stimulus sequence, and further generates a community of desired stimulus sequences to implement CAN controller application scenario simulation verification. Creating a TLM interface data class and a frame parameter data class and instantiating them into objects, which are then encapsulated into functions and tasks for CAN controller verification, can effectively improve the efficiency of stimulus sequence generation during CAN controller verification and reduce the risk of errors.

[0047] The stimulus sequence generation device and verification platform of the present invention implement the stimulus sequence generation method of the present invention for CAN controllers. When verifying a CAN controller, the underlying driver components can be modified according to the corresponding physical interface protocol for different CAN controller interfaces, without changing the structure of the stimulus sequence generation device. The second generation unit of the stimulus sequence generation device of the present invention can organize and coordinate multiple expected stimulus sequences and generate a community of expected stimulus sequences, enabling simultaneous verification of multiple CAN controllers. When applied to the CAN controller verification process, it can generate constrained random stimulus sequences that can ensure the correct driving of the CAN controller under test while achieving full coverage of functional points, thereby improving verification efficiency.

[0048] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are 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.

[0050] Figure 1 A UVM-based CAN controller excitation sequence generation method flow chart of the present invention is shown;

[0051] Figure 2 Shown is a schematic structural diagram of a CAN controller excitation sequence generating device based on UVM according to the present invention;

[0052] Figure 3 A schematic diagram of data call / transmission of a CAN controller verification platform based on UVM according to the present invention is shown;

[0053] Figure 4 Shown is the inheritance relationship between various classes in the CAN controller excitation sequence generating device based on UVM according to the present invention;

[0054] Figure 5 Shown is a schematic diagram of the structure of a CAN controller verification platform based on UVM according to the present invention;

[0055] Figure 6 One of the verification process flow charts of the UVM-based CAN controller verification platform according to the present invention is shown;

[0056] Figure 7 A schematic diagram of the message structure sent and received by the CAN controller in an embodiment of the present invention is shown;

[0057] Figure 8 The second flow chart of the verification process of the UVM-based CAN controller verification platform according to the present invention is shown. DETAILED DESCRIPTION

[0058] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0059] The SystemVerilog verification language, with its language features such as constraints, multi-threaded communication, and object-oriented programming, enables the construction of higher-level structures and the generation of constrained random stimuli. The SystemVerilog-based UVM verification methodology provides a foundational class library and basic development framework centered around the verification language. UVM's customizable framework construction and test classes help verifyers reduce the burden of environment construction, allowing them to focus more on developing verification plans and creating stimulus sequences.

[0060] The present invention adopts the excitation sequence structure constructed by the above technology, which can drive different CAN controller physical interfaces without modifying the excitation sequence generation device. The hierarchical structure of the excitation sequence generation device is relatively high, and each hierarchical structure has a reasonable granularity, which meets the horizontal multiplexing and vertical multiplexing of the test scenario. The constrained random excitation sequence generated by the verification process can meet the requirements of correctly driving the CAN controller to be tested while achieving full coverage of functional points, thereby improving the verification efficiency. It overcomes the shortcomings of the traditional verification technology that the directional excitation sequence written in Verilog language is limited to static instantiation, cannot be dynamically transformed according to the simulation situation, and has poor maintainability and reusability. In addition, the verification platform of the present invention can instantiate multiple CAN controllers at the same time, greatly improving the efficiency of verification.

[0061] Explanation of related terms: UVM Sequence class and UVM Sequence Item class are the basic classes in UVM methodology.

[0062] See also Figure 1 A specific implementation process of a CAN controller excitation sequence generation method based on UVM of the present invention is:

[0063] Create TLM interface data class and frame parameter data class;

[0064] Instantiate the TLM interface data class and the frame parameter data class into objects; and encapsulate the TLM interface data object into a register operation task and the frame parameter data object into a parameter format conversion function;

[0065] Then, according to the function to be verified of the CAN controller, the frame parameter data object is randomized, and the register operation task and parameter format conversion function are called to constrain and control the timing of the TLM interface data object, generating the expected stimulus sequence corresponding to the function to be verified;

[0066] Finally, based on the specific verification content, multiple expected incentive sequences are organized and coordinated to generate an expected incentive sequence community.

[0067] See also Figure 2 The present invention also provides a UVM-based CAN controller excitation sequence generation device, comprising:

[0068] A creation unit, used to create a TLM interface data class and a frame parameter data class;

[0069] The encapsulation unit is used to instantiate the TLM interface data into a TLM interface data object and encapsulate it into a register operation task, instantiate the frame parameter data into a frame parameter data object and encapsulate the parameter format conversion function;

[0070] The first generation unit is used to randomize the frame parameter data object according to the function to be verified of the CAN controller, and call the register operation task and the parameter format conversion function to constrain and control the timing of the TLM interface data object, so as to generate an expected stimulus sequence corresponding to the function to be verified;

[0071] The second generating unit is used to organize and coordinate multiple expected excitation sequences to generate an expected excitation sequence community.

[0072] The present invention also provides a UVM-based CAN controller verification platform, which includes the excitation sequence generating device of the present invention.

[0073] The UVM-based CAN controller excitation sequence generation device of the present invention and the connection transmission structure of the verification platform component and the design to be tested are as follows: Figure 3 shown.

[0074] See also Figure 3 In a specific embodiment of the present invention, the stimulus sequence generation device is divided into four levels: basic data, unit sequence, constraint sequence and virtualization sequence. The inheritance relationship of each level is as follows: Figure 4 As shown. The relationship between each layer in the stimulus sequence generation device is a data call relationship, and the relationship between the verification components is a data transmission relationship. The verification component refers to the general term for the modules in the verification platform used to realize the simulation verification of the design to be tested. Figure 3 Different forms of arrows are used to distinguish and represent.

[0075] like Figure 3 As shown, the TLM interface data class and frame parameter data class are composed as follows Figure 3 The basic data hierarchy shown in ; register operation tasks and parameter format conversion functions are composed of Figure 3 The unit sequence hierarchy shown in .

[0076] For the simulation verification of CAN controller, the three common operations to be performed in the verification process of CAN controller, namely initialization configuration, data sending and data receiving, are given. The three expected stimulus sequences, namely initialization configuration sequence, data sending sequence and data receiving sequence, are generated accordingly. Figure 3 Each desired excitation sequence in the constraint sequence hierarchy can be called a constraint sequence.

[0077] It should be understood that the three expected stimulus sequences given in this embodiment are commonly used in the CAN controller verification process, and can be supplemented in the constraint sequence level according to the actual verification process.

[0078] For the specific verification content of the CAN controller, organize and coordinate multiple expected stimulus sequences to generate expected stimulus sequence communities. For example, when verifying the normal transmission and reception of the CAN controller, call the initialization configuration sequence, data transmission sequence, and data reception sequence in the constraint sequence hierarchy to organize and generate normal transmission and reception sequences (communities), such as Figure 3 As shown in , error sequences (communities) and arbitration sequences (communities) are also listed as examples. These expected incentive sequence communities constitute Figure 3 The virtualization sequence hierarchy shown in , each sequence (desired stimulus sequence community) in the virtualization sequence hierarchy can be called a virtualization sequence.

[0079] In one embodiment of the present invention, register operation tasks and parameter format conversion functions are tasks and functions that are used more frequently during the CAN controller verification process. In the process of verifying a large number of CAN controllers, the pre-packaged target functions and task operation steps can greatly improve the efficiency of CAN controller verification.

[0080] See also Figure 4 , which is an illustration of the inheritance relationship between various levels in a specific embodiment of the stimulus sequence generation device of the present invention. The unit sequence inherits the UVM Sequence class, the constraint sequence inherits the unit sequence, and the virtualization sequence inherits the UVMSequence class.

[0081] The data in the basic data layer is the lowest granularity at the bottom layer. In the present invention, the TLM interface data class and the frame parameter data class are created to constitute the basic data layer. This is in consideration of the transmission characteristics of the verification component and the characteristics of the CAN bus protocol. In the process of generating the CAN controller excitation sequence, the appropriate lowest granularity at the bottom layer can improve the efficiency of the excitation sequence generation.

[0082] The CAN controller is mainly driven through the configuration register. Based on this, the TLM interface data class inherits the UVMSequenceItem class, including random type read / write data, address and read / write command parameters, which can be used to verify that various verification components in the platform communicate through the TLM interface.

[0083] The frame parameter data class is a new class defined according to the message description of the CAN bus 2.0 protocol. It does not inherit the UVM basic library class. It is a targeted design made according to the scene of the actual application of the present invention to the CAN controller verification. The structure of the specific frame is as follows Figure 7 As shown in , the frame parameter data class includes:

[0084] The data part includes the dynamic array ID, frame format FF, frame type RTR, frame data length DLC and dynamic array frame data;

[0085] The basic constraint part includes a feature description of the data part; for example, the value range of DLC is 0 to 8 bytes, which is a clear feature description of DLC.

[0086] The frame parameter data class is mainly used to configure or randomize the data part of the frame parameter data object and then construct the (expected) stimulus sequence. The following example uses the generation of a data transmission sequence to illustrate:

[0087] According to a function to be verified (data sending function) of the CAN controller, the frame parameter data object is randomized;

[0088] After the randomization result is passed to the parameter format conversion function for processing, the constraint parameters are output, and then the CAN sending task is called to construct the data sending sequence according to the constraint parameters.

[0089] See also Figure 3 Finally, the data transmission sequence is organized by the sequences in the virtualization sequence layer (such as normal transmission and reception sequences, arbitration sequences, etc.) and driven to the CAN controller by the cfg_agent (configuration agent container) in the verification component. If the data transmission function of the CAN controller is normal, the CAN controller bus end will send the corresponding message that complies with the CAN bus 2.0 protocol after receiving the data transmission sequence, thereby realizing the verification of the data transmission function of the CAN controller.

[0090] See also Figure 3 When declaring register operation tasks and parameter format conversion functions, interface variables are reserved for external randomization. The register operation task interface variables control the randomization of TLM interface data objects through the constraint parameters passed from the previous level, and realize the single function of the stimulus sequence by organizing and timing the register operation tasks.

[0091] Specifically, the process steps for generating a desired stimulus sequence are:

[0092] Randomize the frame parameter data object according to a function to be verified by the CAN controller;

[0093] Pass the randomized result to the parameter format conversion function to obtain the output constraint parameters;

[0094] Pass the constraint parameters to the interface variables reserved for the register operation task;

[0095] The register operation task constrains the TLM interface data objects and organizes and controls the timing between multiple TLM interface data objects to generate a stimulus sequence.

[0096] Specifically, register operation tasks include single register write operations, read operations, and bit operations. By encapsulating single register write and read operations, a single register bit operation task can be implemented. This task first reads the current register value, then modifies the specified bit of the read value according to the configuration requirements, and finally writes the modified value back to the register.

[0097] Furthermore, the external interface variables reserved for the register operation task are address variables and data variables. The `uvm_do_with macro in the UVMsequence mechanism is used to assign specific values to the address and read / write command parameters of the TLM interface data object. In the register read operation task, the get_response task must be called to obtain the valid read data passed by the driver in the verification component.

[0098] To facilitate repeated calls, the above register operations can be further packaged as basic tasks, and more tasks can be constructed according to the actual configuration of the CAN controller. For example, according to the function to be verified of the CAN controller, the register operation task can be logically packaged again to form a verification task that can realize relatively complex tasks, such as Figure 3 As shown in , the verification tasks in this embodiment include: CAN controller initialization task, CAN send / receive task and CAN interrupt clearing task. Figure 3 Reuse in the vertical direction (functions and tasks) as shown in .

[0099] Specifically, in this embodiment, the CAN controller initialization task includes: performing corresponding register bit operations and register write operations on the mode register, clock frequency division register, acceptance filter, bus timing register and output filter respectively.

[0100] The CAN controller sends / receives data by continuously reading the status and monitoring the registers. When the status is met, the corresponding register address is cyclically called for a write or read operation to send or receive frame data.

[0101] The interface variable input reserved by the parameter format conversion function is the frame parameter data object of the basic data level, and the output is an array of formats that conform to the internal transmit buffer of the CAN controller, thereby converting the frame parameters into the specified format data through the parameter format conversion function.

[0102] Specific as Figure 3As shown, in this embodiment, the initialization configuration sequence in the constraint sequence level specifically needs to first preset parameters such as single / dual filters, baud rate, acceptance code register and acceptance mask register, and then call the CAN controller initialization task in the parent unit sequence level, and finally call the register bit operation task to enable the interrupt register and mode switching according to the needs of the CAN controller test scenario.

[0103] like Figure 3 As shown, the data transmission sequence at the constraint sequence level specifically constrains and randomizes the frame parameter data object using the randomize() with statement. It then calls the parent function (the parameter format conversion function at the unit sequence level) to convert the parameter format and pass the output constraint parameters to the CAN send task. The CAN send task, based on the constraint parameters, writes the message content to the CAN controller's internal transmit buffer. Using the same structure, simply changing the constraint configuration for the data portion of the frame parameter data object can generate data transmission sequences with different message types and formats, thereby enabling the CAN controller to transmit different types of messages from the bus. Constraint configuration is based on the characteristics described in the basic constraint section and does not exceed the scope of the basic constraint section.

[0104] The data receiving sequence in the constraint sequence level is relatively simple, calling the CAN receiving task to wait for a frame of message data to be received, and then calling the read register task to receive and clear the interrupt.

[0105] Virtualization sequence inherits UVM Sequence class;

[0106] The virtualized sequence carries and coordinates multiple constraint sequences, generating a community of expected stimulus sequences to enable simultaneous verification of multiple CAN controllers. Specifically, it includes:

[0107] Use the macro `uvm_declare_p_sequencer to create the p_sequencer variable;

[0108] Index into each sequencer handle declared in can_virtual_sequencer through p_sequencer;

[0109] Use the `uvm_do_on macro to mount each constraint sequence to the corresponding sequencer of the corresponding CAN controller.

[0110] `uvm_declare_p_sequencer and `uvm_do_on are both macros in the UVM verification methodology.

[0111] like Figure 3As shown in the figure, the virtualized sequence serves as the top-level stimulus sequence, carrying and coordinating the constraint sequence of each CAN controller (corresponding to the function to be verified of each CAN controller), thereby realizing a complete test scenario.

[0112] The excitation sequence generating device of the present invention enables the four-level structure of the excitation sequence to have reasonable granularity and nesting, improves the efficiency of excitation sequence generation through reasonable division, and realizes horizontal multiplexing.

[0113] For different test scenarios, that is, when verifying different functions of the CAN controller, it is only necessary to change the restriction conditions of the constraint sequence and the coordination order of the virtualization sequence to achieve different test purposes and realize vertical multiplexing.

[0114] In the present invention, horizontal multiplexing refers to how to use existing resources to complete efficient excitation sequence creation; vertical multiplexing includes the ability to complete both structural multiplexing and excitation sequence multiplexing.

[0115] according to Figure 3 , the cfg_agent (configuration agent container) in the verification component communicates with the DUT (Device Under Test) through the cfg_interface (configuration interface);

[0116] Each CAN controller corresponds to a verification component, cfg_agent. The can_virtual_sequencer (virtual sequencer) bridges the UVM stimulus sequence community and multiple cfg_agents. The can_virtual_sequencer contains handles to each sequencer (sequencer generator) and connects them one-to-one with the underlying sequencer component objects of the cfg_agent. Virtualized sequences carry constrained sequence communities for different target sequencers, and can be routed to the corresponding sequencer components using the can_virtual_sequencer router.

[0117] cfg_agent includes a sequencer and a driver. The sequencer and driver in cfg_agent use a bidirectional interface to communicate with each other. The sequencer starts the register operation tasks in the unit sequence one by one according to the setting order and constraint conditions of the assigned constraint sequence. The register operation tasks generate a target number of randomized TLM interface data objects, which flow to the driver through the TLM interface.

[0118] The driver parses the randomized TLM interface data objects and drives them to the interface according to the CAN controller's physical interface protocol, effectively stimulating the design under test. The stimulus sequence generated by the stimulus sequence generator is passed to the driver via the sequencer, which then drives the DUT.

[0119] Furthermore, in order to read the value of a register in the CAN controller in the unit sequence, the driver can write the status and data information in the design under test back to the unit sequence object through the sequencer, so that the unit sequence can obtain the status of the interaction between the driver and the DUT.

[0120] The CAN controller verification platform of the present invention adopts the stimulus sequence generation device of the present invention. For different CAN controller interfaces, it is only necessary to modify the underlying driver component according to the corresponding physical interface protocol, and the stimulus sequence generation device does not need to be modified, thereby improving the efficiency of stimulus sequence generation and improving the verification efficiency of the CAN controller.

[0121] The CAN controller verification platform based on UVM of the present invention is as follows Figure 5 As shown, according to a specific embodiment of the present invention, the verification platform test top layer (testbench) instantiates multiple designs under test DUT (corresponding to Figure 5 CAN_n in ), configuration interface cfg_interface, bus interface bus_interface and a CAN transceiver model (CAN transceivermodel), and enter the test layer configuration verification component and call the stimulus sequence by calling run_test(stimulus sequence name) in the process statement.

[0122] The design under test is a CAN controller, cfg_interface contains the address, data and control signals related to the DUT configuration, and bus_interface contains the DUT bus input and output signals.

[0123] In the present invention, the main functions of the CAN transceiver model include: simulating the CAN Bus physical layer and converting the bus logic signals of multiple controllers into differential transmission mode;

[0124] During the verification process, bus_interface can be used to force a value to a specific bit on the bus to insert a bus error.

[0125] like Figure 5 As shown, in one embodiment of the present invention, uvm_test (test layer) is used to configure the verification environment and connection relationship and to decide which test stimulus sequence to call, such as Figure 5As shown, uvm_test includes uvm sequence, can_virtual_sequencer and env.

[0126] The UVM sequence is the stimulus sequence generation device of the present invention, used to generate stimulus sequences. The generated stimulus sequences are processed by the virtual sequence management module (can_virtual_sequencer) and then passed to the verification environment (env). The env, as a container package, mainly contains the agent, coverage collection module (coverage), and scoreboard. The various components communicate with each other based on the TLM (Transaction Level Modeling) communication mechanism.

[0127] Among them, the agent includes cfg_agent and bus_agent, both of which inherit the uvm_agent class. cfg_agent includes sequencer and driver, which mainly drives and monitors cfg_interface and transmits signals with DUT through cfg_interface; bus_agent is a bus agent encapsulated with bus_monitor (bus monitor), which mainly monitors the bus interface.

[0128] The Monitor in cfg_agent is responsible for monitoring the configuration signals and interrupt signals of the DUT. When the DUT is interrupted, the monitor restarts a stimulus sequence and passes it to the driver through the sequencer. The driver drives the DUT. The monitor converts the sampled configuration signals into TLM interface data objects and passes them to the coverage and scoreboard components respectively. The bus_agent is not used to drive the DUT but to monitor the bus signals. Therefore, it only instantiates the bus_monitor component inside. The output signal of the CANtransceiver model is collected through the bus interface bus_interface (corresponding to Figure 5 RX in, Figure 5 TX in the code is used to send a signal to the CAN transceiver model. The bus signal is analyzed according to the frame format in the CAN bus protocol, converted into a TLM interface data object, and then passed to the scoreboard.

[0129] The Scoreboard is used to compare and analyze the actual data collected with the reference data to obtain the verification results. In this invention, the scoreboard data sources are mainly divided into three types: the sending end DUTTLM interface data object transmitted by cfg_agent, the receiving end DUT TLM interface data object transmitted by cfg_agent, and the bus TLM interface data object transmitted by bus_agent. The data from multiple sources is compared, and the comparison results are obtained and reported. When used for functional verification of the CAN controller, a report on whether the verification is successful is obtained based on the comparison results. See Figure 6 Flowchart in .

[0130] The coverage collection module Coverage is used to collect the coverage of TLM interface data objects at the DUT transmitter and the DUT receiver.

[0131] like Figure 6 As shown in FIG, a specific flow chart of simulating and verifying a CAN controller based on the verification platform of the present invention is given.

[0132] The simulation verification principle is as follows: First, instantiate each module of the verification platform and start the UVM stimulus sequence generator configured in the virtual sequencer. Then, according to the stimulus sequence settings, the randomly generated unit sequence TLM interface data objects are distributed to the sequencer of each cfg_agent. The sequencer passes it to the driver, which then sends the signal to the internal register of each DUT through the cfg_interface. The monitor in the cfg_agent also collects valid data through the cfg_interface and converts the signal into TLM interface data objects, which are sent to the scoreboard and coverage respectively.

[0133] See also Figure 6 At the beginning of verification, each DUT and verification component is first instantiated, and then each hierarchical sequence in the stimulus sequence generation device of the present invention is instantiated to generate a stimulus sequence; the generated stimulus sequence is passed to the driver through the sequencer, and then the driver sends the signal to the internal register of each DUT through the cfg_interface. Figure 6As shown in the figure, taking two CAN controllers to be tested (CAN_1, CAN_2) as an example, a verification example of sending and receiving messages is performed: in normal working mode, CAN_1 sends a message to the bus. When CAN_2 detects that there is a message on the bus, it will identify and filter it. After the data is filtered, it will receive the message and then read the data back through cfg_interface. Finally, the sender data of cfg_interface (corresponding to Figure 6 Monitor sampling CAN_1 configuration interface), receiving end data (corresponding to Figure 6 Monitor sampling CAN_2 configuration interface) and bus_interface (bus interface) bus data (corresponding to Figure 6 The data is compared with the Bus_monitor sampled message data in the CAN_1 controller. If the comparison is successful, coverage statistics are calculated. If the comparison fails, the cause is investigated and modified. After the modification is completed, re-verification is performed. If the data comparison result is consistent, the comparison is judged to be successful; otherwise, the comparison is judged to be unsuccessful. In this embodiment, the message sending function of the CAN_1 controller is verified, and the message receiving function of the CAN_2 controller is verified. In other words, both CAN controllers are verified.

[0134] The design to be tested in the present invention is a CAN controller, which is compatible with BasicCAN and PeliCAN working modes. The physical interface is mainly divided into a configuration interface and a bus interface. The configuration interface supports reading and writing in Intel and Motorola modes, and the bus interface supports CAN bus 2.0 protocol.

[0135] According to the CAN bus 2.0 protocol standard, the CAN controller can send and receive four types of messages: data frames, remote frames, error frames, and overload frames. Data frames and remote frames have two formats, standard frame format and extended frame format. The structure of message type and message format is as follows: Figure 7 shown.

[0136] See also Figure 7 , the remote frame does not contain the data field, and the rest is the same as the data frame structure.

[0137] On the CAN bus, a frame interval of consecutive recessive bits is inserted between two frames, and the beginning of a frame consists of a dominant bit;

[0138] The arbitration field consists of an ID code and some flag bits, among which the remote frame flag (RTR) is used to indicate whether the frame type is a data frame or a remote frame. The main difference between the standard frame format and the extended frame format lies in the IDE flag bit of the arbitration field and the ID code length. The standard frame format has no IDE bit in the arbitration field and the ID code has 11 bits. The extended frame format has an IDE bit value of 1 and a 29-bit ID code.

[0139] The control fields of the standard frame format and the extended frame format both include a 4-bit data length multi-code (DLC). The control field of the standard frame format has an IDE (value is 0) bit and a reserved bit r0, and the control field of the extended frame format has two reserved bits r0 and r1.

[0140] In both standard and extended frame formats, the data field can only transmit 0 to 8 bytes of data per frame. The CRC field contains a 15-bit CRC sequence and a 1-bit recessive CRC delimiter. The ACK field contains an ACK time slot and an ACK delimiter, followed by 7 recessive bits forming the end of frame, indicating the end of a frame.

[0141] The frame parameter data class in the basic data layer is a new class defined based on the message description of the above protocol.

[0142] Among them, the data part of this class is parameter data designed for the code bits and flag bits of each field in the above message format, including dynamic array ID, frame format FF, frame type RTR, frame data length DLC and dynamic array frame data.

[0143] The basic constraints of this class describe the parameter data defined above based on the message type. The data field can only transmit 0 to 8 characters per frame, so the DLC value ranges from 0 to 8 bytes. The DLC determines the width of the dynamic array of frame data. Similarly, the width of the dynamic array ID depends on the frame format (FF). When FF is the extended frame format, the ID array width is 4, and when FF is the standard frame format, the ID array width is 2. This randomization of frame parameter data objects within the constraint sequence generates parameter data that conforms to the protocol description.

[0144] The frame parameter data class of the present invention is defined as a new class directly according to the message description of the CAN bus 2.0 protocol, which greatly improves the efficiency of generating the stimulus sequence during the CAN controller verification process and increases the reuse rate of the verification component.

[0145] See also Figure 3 Different from the existing CAN verification method, the verification method of the present invention simulates a real communication scenario and connects at least two CAN controllers to be tested (corresponding to Figure 3 can_n in) through the CAN transceiver model ( Figure 3 (not shown) are connected to the same CAN bus (CAN BUS).

[0146] For example, if two CAN controller nodes are connected to the same bus, the specific CAN controller verification process is as follows: one CAN controller acts as the transmitter, and the remaining CAN controllers act as receivers, performing both transmission and reception verification simultaneously. The advantage of this design is that it eliminates the need to develop a complex CAN verification model to verify transmission and reception for multiple CAN controllers.

[0147] Further, see Figure 8 ,like Figure 3 The stimulus sequence generation process for the normal transceiver sequence in the virtualized sequence starts with instantiating the various levels of the stimulus sequence generation device, then enters the reset mode and calls the constraint sequence to initialize the configuration of CAN_1 and CAN_2 respectively, and configures the acceptance filter IDs for CAN_1 and CAN_2 for subsequent data transmission and reception.

[0148] After entering the working mode (verifying the transmission and reception of the CAN controller), CAN_1 is configured to send data. When there is data transmission on the bus, CAN_2 analyzes the bus data and extracts the ID, which is compared with the ID in the acceptance filter configured by the initialization. If it is a valid frame, CAN_2 receives the data and reads the message from the receive buffer; otherwise, it is discarded.

[0149] The above process completes the sending and receiving process of a frame message. This process can configure the effective number of cycles in the virtualization sequence to perform multiple transmissions and receptions between CAN controllers.

[0150] For different test scenarios such as Figure 3 The arbitration sequence listed in the virtualized sequence tests the CAN controller bus arbitration by simply changing the coordination order and configuring CAN1 and CAN2 as transmitters, allowing both DUTs to send data simultaneously. The error sequence listed in the virtualized sequence inserts bus errors using the CAN transceiver model based on the normal transmit and receive sequence, allowing testing of CAN controller error types such as bit errors and format errors.

[0151] Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A UVM-based CAN controller stimulus sequence generation method, characterized in that, include: Create TLM interface data class and frame parameter data class; Instantiating the TLM interface data class into a TLM interface data object and encapsulating it into a register operation task, instantiating the frame parameter data class into a frame parameter data object and encapsulating a parameter format conversion function; According to the function to be verified of the CAN controller, randomizing the frame parameter data object, constraining and timing controlling the TLM interface data object, and generating an expected stimulus sequence corresponding to the function to be verified; Organizing and coordinating a plurality of the desired incentive sequences to generate a desired incentive sequence community; The frame parameter data class is a new class defined according to the message description of the CAN bus 2.0 protocol; The frame parameter data class includes: A data portion, wherein the data portion includes a dynamic array, a frame format, a frame type, a frame data length, and dynamic array frame data; A basic constraint part, wherein the basic constraint part includes a feature description of the data part.

2. the CAN controller excitation sequence generation method based on UVM according to claim 1, is characterized in that, The TLM interface data class inherits the UVMSequenceItem class and includes random type read / write data, address and read / write command parameters.

3. the CAN controller excitation sequence generation method based on UVM according to claim 1, is characterized in that, The register operation tasks include: Write operation tasks, read operation tasks and bit operation tasks on a single register.

4. The CAN controller stimulus sequence generation method based on UVM according to any one of claims 1 to 3, wherein The parameter format conversion function is used to convert the internal variables of the frame parameter data object into constraint parameters that comply with the format of the internal send buffer register of the CAN controller.

5. the CAN controller excitation sequence generation method based on UVM according to claim 4, is characterized in that, When encapsulating the register operation task, an interface variable is reserved for transferring the constraint parameters to the TLM interface data object.

6. the CAN controller excitation sequence generation method based on UVM according to claim 5, is characterized in that, After the step of encapsulating the TLM interface data object into a register operation task, the method further includes the following steps: According to the function to be verified of the CAN controller, the register operation task is logically encapsulated into a verification task, and the verification task includes: CAN controller initialization task, CAN send / receive task and CAN interrupt clearing task.

7. The CAN controller excitation sequence generation method based on UVM according to claim 5 or 6, wherein The method of generating an expected stimulus sequence corresponding to the function to be verified comprises the following steps: Randomizing the frame parameter data object according to a verification function of the CAN controller; Passing the randomization result to the parameter format conversion function to obtain the output constraint parameters; Passing the constraint parameters to the interface variables reserved by the register operation task; The register operation task constrains the TLM interface data object, and organizes and controls the timing of a plurality of the TLM interface data objects to obtain an expected stimulus sequence corresponding to the function to be verified.

8. A CAN controller excitation sequence generation device based on UVM, characterized in that, include: A creation unit, used to create a TLM interface data class and a frame parameter data class; An encapsulation unit, configured to instantiate the TLM interface data class into a TLM interface data object and encapsulate the object into a register operation task, instantiate the frame parameter data class into a frame parameter data object and encapsulate a parameter format conversion function; A first generating unit is configured to randomize the frame parameter data object according to the to-be-verified function of the CAN controller, perform constraints and timing control on the TLM interface data object, and generate an expected stimulus sequence; A second generating unit is configured to organize and coordinate a plurality of the expected stimulus sequences to generate the CAN controller expected stimulus sequence community; The frame parameter data class is a new class defined according to the message description of the CAN bus 2.0 protocol; The frame parameter data class includes: A data portion, wherein the data portion includes a dynamic array, a frame format, a frame type, a frame data length, and dynamic array frame data; A basic constraint part, wherein the basic constraint part includes a feature description of the data part.

9. The CAN controller excitation sequence generation device based on UVM according to claim 8, wherein The first generating unit performs the following steps when generating the expected excitation sequence: Randomizing the frame parameter data object according to a verification function of the CAN controller; Passing the randomization result to the parameter format conversion function to obtain the output constraint parameters; Passing the constraint parameters to the interface variables reserved by the register operation task; The register operation task constrains the TLM interface data object, and organizes and controls the timing of a plurality of the TLM interface data objects to obtain an expected stimulus sequence corresponding to the function to be verified.

10. A CAN controller verification platform based on UVM, characterized in that: The invention comprises the excitation sequence generating device as described in any one of claims 8 or 9.

Images