Covergroup Inheritance

Hi All ,

I remember reading that covergroup(s) have a limitation that’s part of SystemVerilog Open item list . I believed it was about inheritance .

So I was tried an example with covergroup inheritance :: edalink

However I observe that 8 automatic bins are inherited for coverpoint a_auto .

There are total of 12 bins generated , 4 bins for b_auto and 8 bins for a_auto .

If covergroup are inherited then what is the limitation ?

In reply to Have_A_Doubt:

Your example extends a class type with a second covergroup type; both must be constructed and sampled independently. The original covergroup gc1 was never extended.

The new feature coming in the next revision of the sv LRM allows you to extend the covergroup type as part of the extended class type. Construction and sampling behave virtually similar to the randomize methods so you only have to construct and sample a single covergroup object.

class  Base ;
    bit [2:0]  a ;
    covergroup  gc1 ;
      auto_a: coverpoint a;
    endgroup
    function  new();
        gc1 = new();
    endfunction

 endclass

 class  Ext  extends  Base ;
   bit [1:0] b ; 
   covergroup extends gc1 ;       
     auto_b: coverpoint b ;
     cross auto_a, auto_b;
   endgroup
   function  new();
       super.new();
   endfunction
 endclass

 module  Covergroup_Inheritance_L3 ;

   Ext  ext1 ;
   initial  begin
     ext1 = new() ;
     #2; ext1.b = 1 ;  ext1.gc1.sample();
     #2; ext1.a = 3 ;  ext1.gc1.sample();
   end
 endmodule

This means you can now create a cross between a coverpoint in the base covergroup with a coverpoint in the extended covergroup. You are also allowed to override an existing coverpoint with a new expression or bin structure.

In reply to dave_59:
Hi Dave ,

What if user wants to implement the following as per existing LRM ::

create a cross between a coverpoint in the base covergroup with a coverpoint in the extended covergroup

I tried the following code :


class  Ext  extends  Base ;
   bit [1:0] b ; 
   covergroup ext_cg ;       
     auto_a: coverpoint a;
     auto_b: coverpoint b ;
     cross auto_a, auto_b;
   endgroup
   function  new();
       super.new();
       gc1 = null ;    //  Although Legal syntax, coverage  report  not  as  per intention 
       ext_cg = new();
   endfunction
endclass

bins of covergroup gc1 are still inherited although I call null on it explicitly .

Does the LRM have a provision to revert an initialized covergroup to uninitialized / default state ( similar to class objects ) ?

In reply to MICRO_91:

Once you construct a covergroup instance, there is no way to remove or modify the bins associated with that instances.

In reply to dave_59:

Thanks Dave .

So the workaround would be to conditionally ignore the bins within base class , right ? ( edalink )

Following warning message is observed at runtime , which I believe is as per intent :=
The number of coverpoint bins is zero for the coverpoint ‘a_auto’ of covergroup instance ’ Base::gc1 '.All the user defined bins in the coverpoint are empty bins and hence it would not contribute towards the overall coverage result.

Any suggestions if there exists a better alternative ?