A verification device of a FIFO buffer module based on UVM

Abstract

The application discloses a kind of verification device of FIFO buffer module based on UVM.Therein, the device includes: top module, for instantiating design unit verification DUV and interface;Interface module, for defining the format of input and output signal;Component class module, for initializing the infrastructure of the verification device;Component class agent module, for proxy creation each module of UVM;Data class module, for simulating the basic item of test sequence;Data class sequence module, data class sequence is defined by the method in data class module;Component class driver module, for stimulating DUV;Component class monitor module, for sensing DUV signal by the task provided by BFM.Compared with prior art, the application can improve verification efficiency and strengthen the flexibility of test environment, when verifying complex modules such as asynchronous FIFO, UVM can better manage test complexity, and provide rich functions and methods to realize comprehensive verification.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of testing and verification technology, and in particular to a verification device for a UVM-based FIFO buffer module. Background Technology

[0002] In traditional verification methodologies, verification engineers typically need to manually write test environments, generate test data, set timing sequences, and handle exceptions. This approach can lead to inefficiency, insufficient test coverage, and a tendency to miss test cases. Common traditional verification methodologies include:

[0003] Test vector-based approach: This is one of the earliest verification methods. In this approach, verification engineers manually write test vectors (test input data) and apply them to the design under test. The verification engineer then observes the output and compares it to the expected results to determine the correctness of the design. The drawback of this method is that it requires a large number of manually written test vectors and cannot effectively handle complex design and verification needs.

[0004] Directed testing: In this approach, verification engineers, based on their understanding and experience of the design, write targeted test cases to verify specific functionalities of the design. Test cases are typically written manually or generated via scripts to verify different paths and conditions in the design. The drawback of this approach is limited test coverage, failing to comprehensively verify the design. Summary of the Invention

[0005] This invention provides a verification device for a UVM-based FIFO buffer module to improve verification efficiency and reliability, thereby providing strong support for hardware design verification.

[0006] This invention provides a verification device for a UVM-based FIFO buffer module, characterized in that it includes:

[0007] The top-level module is used to instantiate design units to verify DUVs and interfaces, connect DUVs and interfaces, and define clock signals.

[0008] An interface module, which defines the format of input and output signals and implements the Bus Function Model (BFM);

[0009] Component class modules, which are used to initialize the basic architecture of the verification device:

[0010] A component class proxy module is used to proxy the creation of various modules of UVM during the UVM build phase, based on the configuration objects stored in the UVM configuration database.

[0011] A data module, which is used to simulate the basic items of a test sequence;

[0012] The data class sequence module contains high-level test vectors, defined through methods within the data class module.

[0013] A component class driver module is used to execute a loop during the runtime phase, iteratively retrieve an item from the sequencer, and call the corresponding interface BFM task to generate an appropriate signal level vector.

[0014] A component class monitor module, wherein the component class monitor is used to sense DUV signals provided by BFM for a task.

[0015] Optionally, the top-level module is also used to import UVM packages and provide access to the UVM configuration database, allowing class-based verification devices to connect to DUV by registering the interface to the UVM configuration database.

[0016] Optionally, when reading and writing interface signals, SV clock blocks can be used to construct and implement signal-level timing control.

[0017] Optionally, the component class module is specifically used for:

[0018] The component class module sets up a configuration object during the UVM construction phase. The configuration object is used to parameterize the verification device and store the configuration parameters in the UVM configuration database so that other components can access and automatically configure it.

[0019] Optionally, the data class module is also used to define items in the basic items as no operation, write, read, read-write or reset operations.

[0020] Optionally, when the component class monitor detects an operation on the interface, it creates an item and, according to the timing specification of DUV, sends the captured result data to the predictor and coverage collector in the scoreboard after waiting for one clock cycle.

[0021] The beneficial effects of this invention are:

[0022] This invention constructs a complete testbench for a FIFO buffer module using a UVM-based test platform method. The testbench includes basic UVM components such as a sequencer, driver, monitor, coverage collector, and scoreboard, as well as a reference model for verifying functional correctness. By analyzing the test output and evaluating the coverage, the pass / fail status of the test can be determined, verifying the correctness and functionality of the design to be verified. Compared to traditional verification methodologies, UVM offers higher reusability, a better level of abstraction, and simulation control capabilities, thus improving verification efficiency and enhancing the flexibility of the test environment. When verifying complex modules such as asynchronous FIFOs, UVM can better manage test complexity and provides rich functionality and methods to achieve comprehensive verification, providing strong support for hardware design verification. Attached Figure Description

[0023] Figure 1 A structural block diagram of a verification device for a UVM-based FIFO buffer module provided by the present invention;

[0024] Figure 2 This is a schematic diagram of the timing specifications of the DUV provided by the present invention. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0026] This invention provides a verification device for a UVM-based FIFO buffer module. In UVM, an asynchronous FIFO module can be verified by establishing a reusable FIFO verification environment. First, FIFO parameters, such as depth and data width, can be configured using configuration objects and factory patterns provided by UVM. Next, transaction-level modeling methods provided by UVM can be used to generate and manage random test data and inject it into the FIFO. Verification engineers can use various constraints and randomization techniques provided by UVM to improve test coverage and check the correctness of the FIFO under different load and timing conditions. Furthermore, UVM provides rich error injection and handling mechanisms to simulate various abnormal situations, such as data loss, overflow, and underflow. These mechanisms allow for a more comprehensive verification of the asynchronous FIFO's functionality and performance. Compared to traditional verification methodologies, UVM offers higher reusability, a better level of abstraction, and simulation control capabilities, improving verification efficiency and enhancing the flexibility of the test environment. When verifying complex modules such as asynchronous FIFOs, UVM can better manage test complexity and provides rich functionality and methods to achieve comprehensive verification.

[0027] UVM is a System Verilog-based verification methodology for building reusable verification environments. It is widely used in hardware design verification and plays a crucial role in verification environment development. By using UVM, engineers can follow a standardized structure and conventions to build verification environments using System Verilog classes, thereby improving development efficiency and portability.

[0028] At the heart of UVM are Validation Components (VCs), which are encapsulated, configurable validation environments used to validate interface protocols, design submodules, or entire systems. Each VC follows a consistent architecture, including elements such as stimuli, checks, and functional coverage information gathering. This consistency allows VCs to be reused horizontally across different projects and vertically from block-level validation to integration or system-level validation.

[0029] UVM provides a comprehensive base class library for building and deploying testbeds composed of reusable VCs. It supports coverage-driven restricted stochastic verification and can be combined with methods such as assertion-based verification, hardware acceleration, or simulation. UVM also provides reference best practice verification methodologies, supported by major tool vendors and maintained by Accellera.

[0030] UVM's class library comprises two main categories: components and data. The component class hierarchy, derived from UVM components, is used to model the structural parts of the verification environment, such as monitors and drivers. The data classes, derived from UVM sequence items, are used for modeling and transactions. In addition, UVM provides fundamental functionalities, including various utilities such as phased and execution controls, configuration methods, factory convenience methods, and reporting controls, to simplify the development and management of verification environments.

[0031] In a UVM (Universal Verification Methodology) environment, all infrastructure components derive from the uvm_component class, forming a hierarchy that includes the following: Sequencers, Drivers, Monitors, Coverage Collectors, Scoreboards, Environments, and Tests.

[0032] 1. Sequencer, Driver, and Monitor

[0033] Sequencers are entities that run stimulus generation code and send sequence items to the driver. They are responsible for generating and managing sequences of transactions to be verified and passing these sequence items to the driver.

[0034] Drivers communicate with the Design to be Verified (DUV) through an interface, sending it stimulus signals. The drivers are downstream of the sequencer, pulling transaction sequence items from the sequencer and mapping these sequence items to the signal-level format required by the DUV interface via a standard communication port.

[0035] Monitors scan the signal-level traffic flowing to the DUV, assemble sequence items from it, and distribute them to other parts of the verification environment via one or more standard communication ports. Monitors are responsible for capturing the DUV's responses and providing the information needed by the verification environment.

[0036] 2. Coverage Collector and Scoreboard

[0037] Coverage collectors are used to measure the progress of the verification process by collecting coverage information by registering test types and results in the functional coverage model. They can track the coverage of tested functions or code, helping verification engineers evaluate the comprehensiveness and effectiveness of the test suite.

[0038] Scoreboards are used to analyze the functional correctness of test outputs and compare them to a reference model. Scoreboards can verify whether the behavior of DUVs is consistent with expectations and help to discover errors or anomalies.

[0039] 3. Agent

[0040] A proxy is an abstract container that typically encapsulates a driver, sequencer, and monitor. A proxy can be configured to operate in active or passive mode.

[0041] In active mode, the agent simulates the device and drives transactions according to test instructions. It actively sends stimulus signals to the DUV and processes the DUV's response.

[0042] In passive mode, the agent is only used to monitor the activities of the design to be verified. It is only responsible for capturing DUV responses and providing them to the verification environment.

[0043] 4. Environment

[0044] An environment is an entity that assembles the test bench structure. It instantiates one or more agents, a global scoreboard, and other components, and can contain other components, such as bus-level monitors, for performing system-level coverage measurements and checks. Environments have configuration parameters that allow them to be refactored and reused to adapt to different verification scenarios.

[0045] 5. Test

[0046] Tests are the highest level in the component hierarchy. They are used to control the generation of the environment and configure the behavior of its verification components. Tests can control the generation of the verification environment and configure the behavior of individual components within it. They can determine the dynamic behavior of the verification process by initiating sequences in a specific sequencer. Furthermore, tests can extend and adapt the testbench by covering component structures, data items, and sequences. Each test only needs to contain a few specific modifications to differentiate it from user tests and default settings, and to control the behavior of the verification environment.

[0047] In a validation environment, the dynamic data domain is represented as follows:

[0048] 1) Sequence items: These are the basic data objects passed between components. Unlike VHDL signals and Verilog wires, sequence items represent communication at an abstract level.

[0049] 2) Sequences: Assembled from sequence items, used to construct a realistic set of stimuli. A sequence can generate a specific, predetermined set of transactions, a randomly generated set of transactions, or anything in between. Sequences can run other sequences and can be layered, allowing higher-level sequences to send transactions to lower-level sequences in the protocol stack.

[0050] Example

[0051] This invention employs UVM to develop a reusable FIFO buffer module cell-level verification testbench. It is implemented and debugged using Synopsys VCS and DVE version H-2013.06, along with its pre-compiled UVM-1.1d library. See also... Figure 1 The device (i.e., the test platform) specifically includes:

[0052] DUV is an internally designed synchronous FIFO buffer module where data items are stored in RAM. The module's operation is controlled by the rst, wren, and rden signals, while empty and full define its state. The ports din and dot, along with wren and rden, are used to add data to the back of the queue and retrieve data from the front. Simultaneous write and read operations are allowed. Figure 2 The timing specifications for this module are displayed.

[0053] I. Top-level module

[0054] The main entity of the SV (System Verilog) verification program is the top-level module, a static SV module that instantiates DUV (Design Unit Verification) and interfaces, connects them, and defines clock signals. To use UVM, it must also import the UVM package, which provides the basic functionality and resources for this framework. The UVM package provides the `run test` method to initiate the execution of the selected UVM testbench. It also provides access to the UVM configuration database, which provides a shared memory location for storing configurations and shared resources. The top-level module registers interfaces to this database to allow class-based testbench connections to DUV.

[0055] II. Interface FIFO IF Module

[0056] The interface in this embodiment facilitates communication between SV-based test bench components and the DUV, typically implemented in a FIFO buffer module like VHDL. Besides defining the format of input and output signals, it can also be used to implement the Bus Function Model (BFM).

[0057] BFM provides an application programming interface (API) that maps the signal-level behavior of a bus or I / O port to tasks at a higher level of abstraction. The BFM implemented in the interface provides operation-free, write, read, read-write, reset, and monitor operations. This approach has proven to enable clear interaction with DUV, hiding low-level communication, synchronization, and timing details. When reading and writing interface signals, a clocking block (SV) construct is used to implement signal-level timing control to avoid race conditions.

[0058] III. Component Class FIFO Test Module

[0059] The FIFO test component initializes the testbench infrastructure. Specifically, during its UVM build phase, it sets up a configuration object that parameterizes the entire testbench structure and stores it in the UVM configuration database, allowing other components to access it and automatically configure themselves. These configurations include enabling or disabling debug messages for each component, setting the agent's active or passive mode, and enabling scoreboard creation and coverage collection. During this phase, the test also instantiates the environment component, which in turn instantiates the agent. During its UVM run phase, the test selects and starts a test sequence on the agent's sequencer. List1 corresponding to the test run phase is shown below:

[0060] task run_phase(uvm_phase phase); fifo_sequence seq;

[0061] phase.raise_objection(this,"Start base_fifo_sequence"); seq=fifo_sequence::type_id::create("seq");

[0062] / / Randomize the sequence.assert(seq.randomize());

[0063] / / Start the sequence on the agent's sequencer.seq.start(env.agent1.sequencer); phase.drop_objection(this, "Finished base_fifo_sequence");

[0064] endtask

[0065] IV. Component-based FIFO proxy module

[0066] During its UVM build phase (see List 2), the agent creates its individual modules—sequencer, driver, monitor, scoreboard, and coverage collector—based on configuration objects stored in the UVM configuration database. If the agent is proactive, it should create the sequencer and driver; otherwise, if it is reactive, it will only instantiate the monitor. In the UVM connection phase, the agent binds the ports of its components according to its structure; for example, it connects the driver to the sequencer. List 2 of the agent's build phases is as follows:

[0067] function void build_phase(uvm_phase phase); if(settings.active==UVM_ACTIVE)begin

[0068] driver=fifo_driver::type_id::create("driver",this);

[0069] sequencer=fifo_sequencer::type_id::create("sequencer",

[0070] this);

[0071] end

[0072] if(settings.has_functional_coverage==1)begin

[0073] coverage=fifo_coverage::type_id::create("coverage",this );

[0075] end monitor=fifo_monitor::type_id::create("monitor",this); if(settings.has_checker==1)begin

[0076] scoreboard=fifo_scoreboard::type_id::create("scoreboard",this);

[0077] end; endfunction

[0078] V. Data-related FIFO item module

[0079] This class simulates the basic items of the test sequence. Each item contains a set of attributes that record FIFO buffer operations, related data, and its state, as defined in the DUV specification. Randomization is enabled for each attribute simulating the command or input data. Item attributes are listed in list3, as follows:

[0080] / / Commands:

[0081] rand logic read; rand logic write; logic reset;

[0082] / / State:

[0083] Logic full; logic empty;

[0084] / / Data

[0085] rand logic[dw-1:0]data_in; logic[dw-1:0]data_out;

[0086] List 3. Item attributes.

[0087] This class implements a set of methods for directly defining items as no operation, write, read, read-write, or reset operations, so that they can be used to create targeted tests. An example of setting a write operation is shown in List4 below:

[0088] function void set_write(logic[dw-1:0]data_in); this.write=1;

[0089] this.read = 0;

[0090] this.reset=0;this.data_in=data_in;

[0091] endfunction

[0092] List 4.Set method for configuring the item as a write operation.

[0093] VI. Data-type FIFO sequence module

[0094] Sequences are high-level test vectors. Targeted sequences are defined using methods in the FIFO item class; this organization simplifies sequence creation, improves readability, and simplifies modification, although randomized tests can also be easily defined. List 5 demonstrates a simple reset, write (din), read targeted test sequence, as shown below:

[0095] task body();

[0096] fifo_item i_rst1,i_wr1,i_rd1;

[0097] / / Reset

[0098] i_rst1=fifo_item::type_id::create("i_rst1"); start_item(i_rst1);

[0099] i_rst1.set_reset();finish_item(i_rst1);

[0100] / / Write

[0101] i_wr1=fifo_item::type_id::create("i_wr1"); start_item(i_wr1);

[0102] i_wr1.set_write(din);finish_item(i_wr1);

[0103] / / Read

[0104] i_rd1=fifo_item::type_id::create("i_rd1"); start_item(i_rd1);

[0105] i_rd1.set_read();finish_item(i_rd1);

[0106] endtask

[0107] List 5.Basic directed test sequence(reset,write(din),read)

[0108] VII. Component-based FIFO driver module

[0109] The driver component is responsible for ultimately stimulating the DUV. Its main task during the runtime phase (see List 6) is to execute a loop that iteratively retrieves an item from the sequencer and calls the corresponding interface BFM task to generate the appropriate signal level vector. List 6 is shown below:

[0110] task run_phase(uvm_phase phase); fifo_item item;

[0111] forever begin

[0112] / / Gets the next item from the sequencer.seq_item_port.get_next_item(item);

[0113] case(item.get_item_type())"RESET":bfm.reset();

[0114] "READ":bfm.read();

[0115] "WRITE":bfm.write(item.data_in); "WRITE_AND_READ":bfm.read_and_write(item.data_in); "NO_OP": bfm.no_op();

[0116] endcase seq_item_port.item_done();

[0117] end endtask

[0118] List 6. Driver's main task.

[0119] 8. Component-based FIFO monitor module

[0120] The monitor senses the DUV signal via a special task provided by BFM. When the monitor detects an operation (read, write, read-write, reset) on the interface, it creates an entry. According to the DUV timing specifications, it must wait one clock cycle to be able to observe the result. In this way, the entry is assembled from the operation captured in cycle n and the result captured in cycle n+1. Finally, it sends the entry to the predictor and coverage collector in the scoreboard.

[0121] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A verification device for a UVM-based FIFO buffer module, characterized in that, include: The top-level module is used to instantiate design units to verify DUVs and interfaces, connect DUVs and interfaces, and define clock signals. An interface module, which defines the format of input and output signals and implements the Bus Function Model (BFM); Component class modules, which are used to initialize the basic architecture of the verification device: A component class proxy module is used to proxy the creation of various modules of UVM during the UVM build phase, based on the configuration objects stored in the UVM configuration database. A data module, which is used to simulate the basic items of a test sequence; The data class sequence module contains high-level test vectors, defined through methods within the data class module. A component class driver module is used to execute a loop during the runtime phase, iteratively retrieve an item from the sequencer, and call the corresponding interface BFM task to generate an appropriate signal level vector. A component class monitor module, wherein the component class monitor is used to sense DUV signals via BFM for task sensing; When the component class monitor detects an operation on the interface, it creates an item and, according to the timing specification of DUV, sends the captured result data to the predictor and coverage collector in the scoreboard after waiting for one clock cycle.

2. The verification device according to claim 1, characterized in that, The top-level module is also used to import UVM packages and provide access to the UVM configuration database, allowing class-based verification devices to connect to DUV by registering the interface to the UVM configuration database.

3. The verification device according to claim 1, characterized in that, When reading and writing interface signals, SV clock blocks are used to construct and implement signal-level timing control.

4. The verification device according to claim 1, characterized in that, The component class module is specifically used for: The component class module sets up a configuration object during the UVM construction phase. The configuration object is used to parameterize the verification device and store the configuration parameters in the UVM configuration database so that other components can access and automatically configure it.

5. The verification device according to claim 1, characterized in that, The data class module is also used to define items in the basic items as no operation, write, read, read-write or reset operations.

Images