Using the VMM Performance Analyzer in a UVM Environment
Posted by Amit Sharma on August 23rd, 2011
As a generic VMM package, the Performance Analyzer (PAN) is not based on nor requires specific shared resources, transactions or hardware structures. It can be used to collect statistical coverage metrics relating to the utilization of a specific shared resource. This package helps to measure and analyze many different performance aspects of a design. UVM doesn’t have a performance analyzer as a part of the base class library as of now. Given that the collection/tracking and analysis of performance metrics of a design has become a key checkpoint in today’s verification, there is a lot of value in integrating the VMM Performance Analyzer in an UVM testbench. To demonstrate the same, we will use both VMM and UVM base classes in the same simulation.
Performance is analyzed based on user-defined atomic resource utilization called ‘tenures’. A tenure refers to any activity on a shared resource with a well-defined starting and ending point. A tenure is uniquely identified by an automatically-assigned identifier. We take the XBUS example in $VCS_HOME/doc/examples/uvm_1.0/simple/xbus as a demo vehicle for the UVM environment.
Step 1: Defining data collection
Data is collected for each resource in a separate instance of the “vmm_perf_analyzer” class. These instances should be allocated in the build phase of the top level environment.
For example, in xbus_demo_tb.sv:
Step 2: Defining the tenure, and enable data collection
There must be one instance of the “vmm_perf_tenure” class for each operation that is performed on the sharing resource. Tenures are associated with the instance of the “vmm_perf_analyzer” class that corresponds to the resource operated. In this case of the Xbus example, lets say we want to measure transcation throughput performance (i.e for the XBUS transfers).. This is how we will associate a tenure with the Xbus transaction. To denote the starting and ending of the tenure, we define two additional events in the XBUS Master Driver (started, ended). ‘started’ is triggered when the Driver obtains a transaction from the Sequencer, and ‘ended’ once the transaction is driven on the bus and the driver is about to indicate seq_item_port.item_done(rsp); At the same time, ‘started’ is triggered, a callback is invoked to get the PAN to starting collecting statistics. Here is the relevant code.
Now, the Performance Analyzer works on classes extended from vmm_data and uses the base class functionality for starting/stopping these tenures. Hence, the callback task which gets triggered at the appropriate points would have to have the functionality for converting the UVM transactions to a corresponding VMM one. This is how it is done.
Step 2.a: Creating the VMM counterpart of the XBUS Transfer Class
Step 2.b: Using the UVM Callback for starting/stopping data collection and calling the UVM -> VMM conversion routines appropriately.
The callback class needs to be associated with the driver as follows in the Top testbecnh (xbus_demo_tb)
Step 3: Generating the Reports..
In the report_ph of xbus_demo_tb, save, and write out the appropriate databases
Step 4. Run simulation , and analyze the reports for possible inefficiencies etc
Use -ntb_opts uvm-1.0+rvm +define+UVM_ON_TOP with VCS
Include vmm_perf.sv along with the new files in the included file list. The following table shows the text report at the end of the simulation.
You can generate the SQL databases as well and typically you would be doing this across multiple simulations.. Once, you have done that, you can create your custom queries to the get the desired information out of the SQL database across your regression runs. You can also analyze the results and generate the required graphs in Excel. Please see the following post : Analyzing results of the Performance Analyzer with Excel
So there you go, the VMM Performance Performance Analyzer can fit in any verification environment you have.. So make sure that you leverage this package to make the RTL-level performance measurements that are needed to validate micro-architectural and architectural assumptions, as well as to tune the RTL for optimal performance.