Any type of Testbench typically requires following two sections to verify a targeted DUT:
- Stimulus Generation
- Analysis of the Design Response
It is equally true for traditional directed Testbenches as well as latest UVM based constraint random Verification Environments. But the type of components are different for both type of Testbenches.
Stimulus generation side puts the DUT in a known state and stimulate the DUT inputs with certain values and then Analysis side actually performs the verification. Analysis side of a Testbench is made of components those observe behavior & make a judgement weather or not the DUT meets the specification goals. Specific behavior could be functional correctness, performance & power utilization.
In this post, I’ll introduce & discuss these UVM Analysis Side Components along with their primary characteristics.
Lets first see the overall picture of a standard Analysis side of an UVM Testbench in the Diagram 1 below. Different Analysis components are also shown in the diagram.
Diagram 1: UVM Analysis Side Structure
As per the goal of this post, we’ll go through each of the above shown Analysis components and describe their roles and functions in introductory form.
The Analysis process fundamentally starts with observing response activity within the DUT. The component which captures these signal level response activities on the DUT through virtual interface is called “Monitor“. The Monitor transforms these signal activity into the Transactions, and these Transactions are broadcasted to the other integrated Analysis components using Analysis Ports which are connected to the Subscriber. These Subscriber capture these Transactions and perform the analysis.
This Analysis component collects the Transactions sent by the Monitor & perform specific analysis activities on the collected Transactions. The Scoreboard components helps to determine if the DUT is functionally operating properly or not?
The best way to architect a Scoreboard effectively is to define with two tasks i.e. Prediction & Evaluation. The Predictor Model is also called the “Golden Reference Model” which takes the same input stream as DUT and produces the known good (expected) response transaction stream. Scoreboard then evaluates the expected response stream with the DUT response activity generated transaction stream (actual transaction stream).
When there is one expected transaction stream and one actual transaction stream, a very common evaluation techniques is the use of comparator, which compares the transactions coming in-order or coming out-of-order.
3) Coverage Collector:
Another Analysis component is Coverage Collector. It helps to find out the answers to some critical verification completion questions like:
- Are we done with the testing?
- Have we done the adequate testing??
Usually, the Coverage Collector component is subscribed to the Analysis Port of the Monitor and samples the observed activity into SystemVerilog Functional Coverage Construct.
The data from each Test being executed is entered into the common coverage database, which is used to generate report & in return helps to determine the overall verification progress.
4) Metric Analyzer:
These Analysis components watch & record non-functional behaviors such as timing or performance, and power utilization. Depending on the number of Transaction streams, these are implemented using uvm_subscriber or with UVM Analysis Exports.
These analysis components can perform on-going calculations during the run_phase and/or during the post-run phases.
After introducing about all the Analysis Components, lets understand how the Analysis reporting process happens –
All the reporting data is collected during simulation. Most of the analysis take places dynamically as the simulation runs, but some analysis can be done after the run phase ends.
UVM supports three phases for report analysis purpose:
These UVM phases allows to extract relevant data during the run, perform checks on the extracted data & and then finally generate the report about all the analysis performed on the extracted data.
With all that information, I would like to conclude this post regarding UVM Testbench Analysis Structure. We discussed in brief about all the Analysis Components and lately about Reporting process. I hope it will help to give a big picture of the Analysis side of the UVM Testbench. I’ll cover these analysis components in the detail with examples in my upcoming posts.
Please feel free to share your comments & suggestions, I would love to have those. Again, Thank you for your time in going through this post. I believe it helps! Till next time..Take care Bye!