Overview
Verifying a design consists of two major parts: stimulus generation and an analysis of the designs response. Stimulus generation sets up the device and puts it in a particular state, then the analysis part actually performs the verification.
The analysis portion of a testbench is made up of components that observe behavior and make a judgement whether or not the device conforms to its specification. Examples of specified behavior include functional behavior, performance, and power utilization.
-
Monitoring DUT Activity
The process by which the analysis section makes its judgement starts with observing response activity in the device under test (DUT). This is done by one or more monitors that observe the signal-level activity on the DUT through a virtual interface(s). The monitor converts signal-level activity into TLM transactions, and broadcasts the transactions to interested analysis components using analysis ports which are connected to subscribers. These subscribers capture the transactions and perform their analysis.
Scoreboards
These analysis components collect the transactions sent by the monitor and perform specific analysis activities on the collection of transactions. Scoreboard components determine whether or not the device is functioning properly. The best scoreboard architecture separates its tasks into two areas of concern: prediction and evaluation.
A predictor model, sometimes referred to as a "Golden Reference Model", receives the same stimulus stream as the DUT and produces known good response transaction streams. The scoreboard evaluates the predicted activity with actual observed activity on the DUT.
A common evaluation technique when there is one expected stream and one actual stream is to use a comparator, which can either compare the transactions assuming in-order arrival of transactions or out-of-order arrival.
Coverage Collectors
Coverage information is used to answer the questions "Are we done testing yet?" and "Have we done adequate testing?".
Coverage Collectors subscribe to a monitor's analysis ports and sample observed activity into SystemVerilog functional coverage constructs. The data from each test is entered into a shared coverage database, which is used to determine overall verification progress.
Metric Analyzers
Metric Analyzers watch and record non-functional behavior such as timing/performance and power utilization. Their architecture is generally standard. Depending on the number of transaction streams they observe, they are implemented as an uvm_subscriber or with analysis exports. They can perform ongoing calculations during the run phase, and/or during the post-run phases.
Analysis Reporting
All data is collected during simulation. Most analysis takes place dynamically as the simulation runs, but some analysis can be done after the run phase ends. UVM provides three phases for this purpose: extract_phase, check_phase, and report_phase. These phases allow components to optionally extract relevant data collected during the run, perform a check, and then finally produce reports about all the analysis performed, whether during the run or post-run.
| 
