Home > Community > Blogs > Functional Verification > new specman coverage engine part ii using instance based coverage options for coverage parameterization
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

New Specman Coverage Engine (Part II) - Using Instance-based Coverage Options for Coverage Parameterization

Comments(0)Filed under: Incisive Enterprise Simulator (IES), Specman, Funcional Verification, e language, coverage, AF, extensions under subtypes, covergroups, instance-based coverage, subtypes, coverage parameterization

In the last coverage blog, we showed how the extensions of covergroups under when subtypes can help us write a reusable per-instance coverage.

We described a test case where a packet generator unit can create packets of different sizes. The packet generator unit has a field that describes the maximum size of any packet that can be generated by the packet_generator instance:

type packet_size_t: [SMALL, MEDIUM,LARGE,HUGE];

unit packet_generator{

    max_packet_size: packet_size_t;

    event packet_generated;

    cur_packet: packet;

    generate_packet() is{

        gen cur_packet keeping {it.size.as_a(int) <= max_packet_size.as_a(int)};

        emit packet_generated;




We defined a covergroup that is collected per each instance of packet_generator, to ensure that each packet generator creates packets of all relevant sizes:


extend  packet_generator{

     cover packet_generated using per_unit_instance is{

        item p_size: packet_size_t = cur_packet.size;




Then we refined the group's instances according to their actual subtypes, so that irrelevant packet sizes are ignored. This solution included setting a different fixed ignore condition for each subtype:


extend packet_generator{

    when SMALL'max_packet_size packet_generator{

        cover packet_generated is also{

            item p_size using also ignore = p_size.as_a(int) >




    when MEDIUM'max_packet_size packet_generator{

        cover packet_generated is also{

            item p_size using also ignore = p_size.as_a(int) >




    // ... Same for other max_packet_size values



However, if we take a close look at the extensions under the subtypes, we can identify a uniform pattern for all the extensions:


item p_size using also ignore = p_size.as_a(int) >

                                         <max_packet_size field value of this subtype>


This pattern indicates that defining ignored values in a parameterized manner (that is, ignore all size values that are bigger than the value of the max_packet_size field of the instance) is more suitable here.

And as of Specman version 12.2, we have the appropriate syntax for doing exactly that:


extend packet_generator{

   cover packet_generated is also{

       item p_size using also instance_ignore = p_size.as_a(int) >





The above code illustrates two new concepts: First, the use of the instance_ignore item option instead of the ignore option; second, the use of a special field named "inst" in the instance_ignore option.

Parameterized Instance-Based Coverage Options

In previous versions, Specman had four coverage options that defined what would be included in the coverage model:

-          no_collect group option – could be used to exclude groups / covergroup instances from the model.

-          no_collect item option –  could be used to exclude items from the model.

-          ignore / illegal items options – could be used to exclude specific buckets (bin) values from the model


In Specman 12.2, we added instance-based versions for these four coverage options:

-          instance_no_collect group option – for selectively refining which instance of the covergroup will be disabled.

-          instance_no_collect item option – for selectively refining from which group instance the item will be excluded.

-          instance_ignore /instance_ illegal items options – for selectively refining which item’s bucket will be under each coverage instance.


When using these instance based options, the user can use a special field, named ‘inst’, to reference the relevant unit instance of each coverage instance, and get the values of the configuration fields of the instance.

Specman assigns the value of the ‘inst’ field to the relevant unit instance, and then computes the expressions separately for each coverage instance.

As the above description indicates, the four instance-based options can be used to apply different behaviors to different instances of the same covergroup. But if there is a need to apply a common behavior for all instances of the covergroup, then the original “type based” options are more appropriate. For example, use the no_collect item option, not the instance_no_collect option, to remove base items of a cross item from the model.

Team Specman


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.