The Design Verification Repo Captures my work from basic understanding and projects I have worked on.
The UVM Class Library provides the building blocks needed to quickly develop well-constructed and reusable verification components and test environments in SystemVerilog. We divide the UVM classes and utilities into categories pertaining to their role or function.
- Base : This basic building block for all environments are components, which do the actual work, transactions, which convey information between components and ports, which provide the interfaces used to convey the information.
- Components : The components for the foundation of UVM. They encapsulate behaviour of drivers, monitors, scoreboards, environments, agents, test and other objects in Testbench.
- Reporting : The reportin classes provide the facility for issuing messages with consistent formatting and configurable side effects like logging a file or exiting simulation.
- Factory : The factory method is used to register the uvm_object or uvm_component classes. Users can configure the factory to produce an object of a given type on a global or instance basis.
- Phases : It describes the phasing capability providing by UVM.
- TLM : The UVM TLM library defines several abstract, transaction-level interfaces and the ports and exports that facilitate their use. Each TLM interface consists of one or more methods used to transport data, typically whole transactions (objects) at a time.
- Sequencers : The sequencer controls the flow of uvm_sequence_item-based transactions generated by one or more uvm_sequence #(REQ,RSP)-based sequences.
- Sequences : The sequences can be reused, extended, randomized, and combined sequentially and hierarchically in interesting ways to produce realistic stimulus to your DUT.
- Macros : A complete list of macros for Reporting, Components, Objects, Sequences, Callbacks, TLM and Registers.
- Register Layer : The Register abstraction classes, when properly extended, abstract the read/write operations to registers and memories.
- Command Line Processor : A general interface to the command line arguments that were provided for the given simulation.
For reference of understanidng the Syntax or Usage I refer following links :
- Link1 : https://www.accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf
- Link2 : https://www.accellera.org/images//downloads/standards/uvm/uvm_users_guide_1.2.pdf
- Link3 : Once we download the UVM library. We get index.html page from UVM-18002-2017-11tar/uvm-1.2/uvm-1.2/docs/html/index.html.
Base Class
- uvm_object: Dynamic Class
- uvm_transaction
- uvm_sequence_item
- uvm_sequence
- uvm_component : Static Class
- uvm_driver
- uvm_monitor
- uvm_agent
- uvm_scoreboard
- uvm_env
- uvm_test
uvm_top (root)
|
|
|
|
|
Test (root)
|
|
|
|
Environment (subtree)
|
| |
| |
| |
Scoreboard(subtree) Agent(subtree)
|
| | |
| | |
Monitor Driver Sequencer
The UVM Testbench Architecture composes of :
- Transaction :
- The Transaction class in general composes of the signals of the DUT.
- The signals can be Constrainted and Randomized on certain conditions.
- These transaction class is used by Sequencer, Driver and Monitor.
- Sequencer :
- The Sequencer in general is used to generate the Sequences for the DUT. The sequences are sent to driver using TLM seq_item_export port.
- In general there can different sequences/testcases for given DUT.
- Driver :
- The Driver in general is used to drive the transactions/sequences to DUT through Interfaces.
- Monitor :
- The Monitor is used to collect the trasnactions/responses from the DUT through Interfaces. The collected responses are sent to Scoreboard through TLM port.
- Agent :
- The Agent class that encapsulates the Driver, Sequencer and Monitor. The reason for doing this is we can have Multiple agents and reconfigurability or reuse nature for different DUTs.
- In this class we generally connect the TLM port of Driver and Sequencer.
- Scoreboard :
- The Scoreboard is used to cross veirfy or compare the transactions between the Golden data and Collected responses from the TLM port.
- Environment :
- The Environment class encapsulates the Agent and Scoreboard.
- The reason for doing this is we can reconfigure or reuse nature for different DUTs.
- In this class we generally connect the TLM port of Monitor and Scoreboard.
- Test :
- The Test class encapsulates the Sequencer and Environment.
- In the run_phase of the test class we drive or start the sequences/testcases for the DUT.
- Interface :
- The Interface is used to connect between Dynamic class and Module (Static in nature).
- The Interface provides modports and clocking blocks with it.
- In general the Interface blocks can be reused for multiple Testbench top.
- DUT :
- In general the RTL block or Design code is used as DUT.
- A Block implementing the Design Specification if the RTL/Design code is not ready. Used to verify the intended testcase.
- TB_Top :
- The Encapsulation of Test, Interface and DUT.
The common phases are the set of function and task phases that all uvm_components execute together. All uvm_components are always synchronized with respect to the common phases.
UVM Phases
a. Consume time : task
- run_phase.
b. Do not consume time : function
- function and super to override the specific method.
- configuring the envirnoment.
- creating object of class.
- applying stimulus to DUT on valid clock edge.
- Construction phase.
- Cleanup phase.
Phases : Total = 20
a. Construction Phase (4 phases)
(Override the specific function method according to our needs)
- build_phase : Create and configure the testbench architecture. Create an object of a class. Instantiate sub-components. Get configuration values for the component being built. Set configuration values for sub-components.
- connect_phase : Connection of TLM ports and exports, adapters and sockets for data flow. Establish cross-component connections.
- end_of_elaboartion_phase : Fine-tune testbench. Display environment topology. Open files.
- start_of_simulation : Configure an environment before applying the stimulus. Set the debug breakpoints and configurations. The verification environment has been completely configured and is ready to start.
b. run_phase (12 phases) : Task based and consume time. Drive the DUT with stimuli and managed with objections.
- reset_phase : System reset - Bring the system/block or anything to known state. Then start working.
- pre_reset_phase : Before reset is asserted. Wait for power good. There should not have been any active clock edges before entry into this phase.
- reset_phase : Reset is asserted. The components must drive their outputs to their specified reset or idle value. Initialize their state variables.
- post_reset_phase : Reset is deasserted. Components should start behavior appropriate for reset being inactive. After this, the testbench and the DUT are in a known, active state.
The testbench and the DUT are in a known, active state
- configure_phase : Memory/Variables/Arrays : Initialize them to specific value before start of generating stimulus.
- pre_configure_phase : Before the DUT is configured by the SW. Indicates that the DUT has been completed reset and is ready to be configured.
- configure_phase : The SW configures the DUT. Components required for DUT configuration execute transactions normally. Set signals and program the DUT and memories (e.g. read/write operations and sequences) to match the desired configuration for the test and environment.
- post_configure_phase : After the SW has configured the DUT. Indicates that the configuration information has been fully uploaded. Wait for configuration information to fully propagate and take effect. Enable the DUT. Sample DUT configuration coverage.
The DUT has been fully configured and enabled and is ready to start operating normally.
- main_phase : Generating stimulus + collecting responses.
- pre_main_phase : Before the primary test stimulus starts. Wait for components to complete training and rate negotiation.
- main_phase : Primary test stimulus. Components execute transactions normally. Data stimulus sequences are started. Wait for a time-out or certain amount of time, or completion of stimulus sequences.
- post_main_phase : After enough of the primary test stimulus. The primary stimulus objective of the test has been met.
- shutdown_phase : All the stimuli generated are applied correctly to DUT.
- pre_shutdown_phase : Before things settle down.
- shutdown_phase : Letting things settle down. Wait for all data to be drained out of the DUT. Extract data still buffered in the DUT, usually through read/write operations or sequences.
- post_shutdown_phase : After things have settled down. No more “data” stimulus is applied to the DUT.
All run-time checks have been satisfied. The uvm_run_phase phase is ready to end.
c. cleanup_phase : collect and report data. coverage goals are achieved. (4 phases)
- extract phase : Extract data from different points of the verification environment.
- check phase : Check for any unexpected conditions in the verification environment.
- report phase : Report the results of the test. End of the test.
- final phase : Summarize test results and write logs. All test-related activity has completed. Close files. Terminate co-simulation engines.
The flow/sequence of execution of phase :
- Build Phase executed.
- Connect Phase executed.
- End of Elaboration Phase executed.
- Start of Simulation Phase executed.
- Run Phase.
- Extract Phase.
- Check Phase.
- Report Phase.
- Final Phase.
In order to explain above concepts a simple project Links :
- Code Link : https://github.com/ssbagi/Design-Verification/blob/main/UVM_ADDER/uvm_adder.svh
- Directory Link : https://github.com/ssbagi/Design-Verification/tree/main/UVM_ADDER
In order to explain above concepts a complex project Links :