Functional Coverage in Transaction Class (SV)

[Shenli]

Hi all,

When do data-oriented functional coverage, can we put the covergroup
in transaction class directly? And is there any short guideline how to
do?

For example,
I have transaction define class like:
Code:
//-----------
class video_pkg_c;
rand bit [7:0] opcode_1;
rand bit [7:0] opcode_2;
rand bit [15:0] data;
//----
// can I add covergroup here?
//----
endclass

class video_pkg_driver;
... ...
video_pkg_c video_pkg;
video_pkg = new();
rand_result = video_pkg.randomize();
... ...
endclass
//-----------


I use Cadence IUS583.

Best regards,
Davy

 

[Ajeetha (www.noveldv.com)]

On Feb 17, 7:02 am, "Shenli" <zhushe...@gmail.com> wrote:

Hi all,

When do data-oriented functional coverage, can we put the covergroup
in transaction class directly? And is there any short guideline how to
do?

I would highly recommend to avoid this. This is because, coverage is
more or less a "static" view of your verification progress and not
truly as dynamic as the transactions themselves are. I usually create
a separate coverage element and hook it up. Agreed there is some
repetition in work - especially for long transaction descriptors, but
one can automate it, write some script or use SV struct etc. to ease
the pain.

VMM also recommends some thing similar, it prefers to associate
coverage with the transactors. Another rule/guideline is "cover as
close to DUT as possible".

This is b'cos, even though a packet got generated at a high level
generator, perhaps due to the fact that particular port was in
blocking mode (a random configuration setting), the packets never went
into the DUT. This may or may not be the desired thing. By having the
transactor tell us "when to sample" we are sure that we are covering
at the correct place. Imagine creating 10K transactions, you don't
need 10K coverage objects as well - you simply need a "count" of what
kind of packets (Type, length, CRC etc.) went in and how many of them.
This is what I refer to as "pseudo-static" item in the verification
environment.

The hook up of coverage class to the transactor is an interesting
topic. In VMM one can use callbacks or vmm_channel::tee(). In AVM one
can use analysis ports to do this. Not sure of in uRM, some thing
similar exists there? If we had AOP, then that would help here as
well.

HTH
Ajeetha, CVC

For example,
I have transaction define class like:
Code:
//-----------
class video_pkg_c;
rand bit [7:0] opcode_1;
rand bit [7:0] opcode_2;
rand bit [15:0] data;
//----
// can I add covergroup here?
//----
endclass

class video_pkg_driver;
... ...
video_pkg_c video_pkg;
video_pkg = new();
rand_result = video_pkg.randomize();
... ...
endclass
//-----------

I use Cadence IUS583.

Best regards,
Davy

 

[Jonathan Bromley]

On 17 Feb 2007 23:09:54 -0800, "Ajeetha (www.noveldv.com)"
<ajeetha@gmail.com> wrote:

[snip excellent advice about coverage collection]

The hook up of coverage class to the transactor is an interesting
topic. In VMM one can use callbacks or vmm_channel::tee(). In AVM one
can use analysis ports to do this. Not sure of in uRM, some thing
similar exists there? If we had AOP, then that would help here as
well.

Ajeetha,

Those of us with delicate constitutions don't like to talk about it,
but SystemVerilog DOES have aspect-oriented extension!
It's called "bind" and, as I'm sure you know, it allows you to
inject a "parasite" instance anywhere in the hierarchy
(or, at least, anywhere it would be legal to put such an instance
in the original code) - EVEN into the DUT itself. This is an
extremely neat way to add coverage collection to existing code,
and fits beautifully with your advice of "collect coverage as
close to the DUT as possible". You can't get much closer
than "inside"

I can't be the only person who has thought that it might be
kinda neat if SV "bind" could bind not only an instance, but
absolutely any module item, to its target scope - then we
could have *real* extension. Something like this...

bind <target> wire A; // add a declaration
bind <target> assign A = B; // add a continuous assign
bind <target> always @* begin .... end // add an always block
bind <target> begin
... all sorts of stuff, just like a generate block
end
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.