Some Ideas on Coverage Extendability

Blog Comments
1

The biggest advantage of e regarding coverage is, in my opinion, the ability to tweak the definitions of existing coverage groups by extending them from anywhere inside the verification environment. This is particularly useful when dealing with coverage groups defined inside eVCs. For example, let's say that we have an AHB eVC that provides some very extensive coverage definitions to make sure that we rigorously verify our DUT. If that DUT is a very simple slave that can only process read transactions, we'll never reach 100% coverage unless we ignore all references to write transactions. This is easily done with just a few lines of code:

This is a companion discussion topic for the original entry at https://verificationgentleman.netlify.app/2015/06/29/some-ideas-on-coverage-extendability.html
2

Apparently the following syntax isn’t 100% LRM compliant:

"
coverpoint operation {
ignore_bins ignore[] = operation with (item inside
{ POLICY::get_operation_ignore_bins() });
}
"

This is because a static function return value isn’t considered a “constant” function (go fig, right?). To get around this, it’s possible to change it to:

"
constant operation_e operation_ignore_bins[] = POLICY::get_operation_ignore_bins();

coverpoint operation {
ignore_bins ignore[] = operation with (item inside
{ operation_ignore_bins });
}
"

Some simulators might only accept the former, while some might only accept the latter. Choose whichever one works for you.