Posted by paragg on 25th June 2011
Parag Goel, Senior Corporate Application Engineer, Synopsys
In the final blog of this coverage modeling with VMM series, we focus on error coverage. Negative scenario testing is an integral part of verification. But again, we have this question – Whether I have covered all negative scenarios?
So it is important to ensure that the generic coverage model tracks all the error scenarios.
Let’s see, how a specific mechanism provided in VMM in the form of vmm_report_catcher helps to track error coverage efficiently and effectively. The VMM Log Catcher is able to identify/catch a specific string of any type any of the messages issue through the VMM reporting mechanism.
Typically, the Verification Environment issues messages to STDOUT when the DUT responds to an error scenario. These messages can be ‘caught’ by the Log Catcher to update the appropriate coverage groups. Let see how this is done in detail.
The Verification Environment would respond to each negative scenario by issuing a message with a unique text, specific to specific error messages.
In the context of the AXI in framework, we can introduce a wide-range of error scenarios and test if the DUT responds correctly or not. A few possible error scenarios in AXI are listed below for your reference.
However, all the scenarios may not be applicable always and hence configurability is required to enable only the required set of coverpoints tied to the relevant negative scenarios. Thus, we should have similar configurability for error coverage as I talked about in the earlier blogs.
Let’s see how we can catch the relevant responses and sample the appropriate covergroups.
As mentioned earlier, in the example below, we make use of the unique message issued as a result of a negative scenario.
This is how we use the VMM Log catcher.
1. The error coverage class is extended from vmm_log_catcher – VMM base class.
2. The vmm_log::caught() API is utilized as means to qualify the covergroup sampling.
In the code above, whenever a message with the text “AXI_WRITE_RESPONSE_SLVERR “ is issued from anywhere in the verification environment, the ‘caught’ method is invoked which in turn samples the appropriate covergroup. Additionally, you an specify more parameters in the caught API, to restrict what ‘scenarios’ should be caught.
string name = “”,
string inst = “”,
bit recurse = 0,
int typs = ALL_TYPS,
int severity = ALL_SEVS,
string text = “”);
The above API, installs the specified message handler to catch any message of the specified type and severity, issued by the specified message service interface instances specified by name and instance arguments, which contains the specified text. By default, this method catches all messages issued by this message service interface instance.
Hope these set of articles would be relevant and useful to you.. I have made an attempt to leverage some of the built-in capabilities of the SV languages and the VMM base classes to target some of the challenges in creating configurable coverage models.. These techniques can be improvised further to make them more efficient and scalable. I would be waiting to hear from you all any inputs that you, have in this area.