Tuesday, March 30, 2010

Don't rely on illegal_bins for checking perpose....

Dear Readers,

Do not rely on illegal_bins for checking perpose. If you rely on covergroup where you have written illegal_bins, what happens when you turn off the coverage??

That is where Assertions coming in picture...! If you really want to ignore values then use ignore_bins. If you really want to throw errors then use an assertions checkers.

While illegal_bins removes values from coverage calculations, it also throws errors.
Philosophically, you need to ask yourself the questions,

(1) “Should a passive component like a covergroup be actively throwing errors?” and
(2) “If you rely on the covergroup for checking, then what happens when you turn coverage off?”

From the example given above, you can see 3'b100 is an illegal opcode and as per protocol if that value occurs then its an error.So here instead of writting and illegal_bins you can have a assert property with coverage to check specifically this scenarion.

So usually I would prefer to have an assertions (with cover property) where strong protocol check requires instead of writting illegal_bins.

Happy Reading,
ASIC with Ankit

Sunday, March 28, 2010

VCD dumping from VCS command line?

Dear Readers,

Dumping of signal value changes in VCD format can be enabled
in verilog by including the $dumpvars system task.

In addition to this method, VCS provides a way to enable
VCD dumping at compile time.

This can be achieved by including the following switch
at compile time: "+vcs+dumpvars[+filename]"

For example, consider the following case:

% cat test.v
module test;
reg clk;

initial begin
clk = 1'b0;
forever #5 clk = ~clk;
end

initial begin
#100 $finish;
end
endmodule

% vcs test.v -V -l logfile -R +vcs+dumpvars+test.vcd

The $dumpvars system task is not specified in the verilog code above. Instead,
VCD dumping is enabled with the addition of the compile time switch "+vcs+dumpvars+test.vpd".

The result is equivalent to calling the following system tasks:

$dumpvars;
$dumpfile("test.vpd");

If the filename is not specified (ie. only +vcs+dumpvars is used), then the
filename defaults to "verilog.dump".

If both the system task ($dumpvars) and the compile-time switch (+vcs+dumpvars)
are specified, then the compile-time switch takes precedence.

No additional verilog code is needed when enabling VCD dumping using the compile
time switch.

Having compile time switch reduces little bit of code and makes life easy :-)

Enjoy....
ASIC With Ankit

Sunday, March 21, 2010

Is it really possible to develop relatively complex functional coverage model using SVA (System Verilog Assertions)??

Dear Readers,

Is it really possible to develop relatively complex functional coverage model using SVA (System Verilog Assertions)??

Yes, SystemVerilog Assertions (SVA) can be used to implement relatively complex functional coverage models under appropriate circumstances:

I would say using strong construct of SVA we can develop a functional coverage model too. The point here is using SVA construct you need to do some work around while in functional coverage there are some constructs using which we can simply write a cover points to cover the functionality.

Let me take an example and try to explain:

Let say we have a verification scenario where we have to cover state transitions.

It should cover

1. states transition A-B and
2. State transition B-C

This can be covered using functional coverage construct “=>” like A=>B and B=>C so basically code would be given below in functional coverage model:

covergroup state_trans_cg @ (posedge clk);
   coverpoint state_trans_cov
{
   bins A_to_B = (A => B);
   bins B_to_C = (B => C);
}
endgroup

Same functionality we can cover using SVA constructs as well:

If we try to cover the same functionality using SVA then code would be:

sequence seq_A_B;

@(posedge clk)

`A ##1`B;

endsequence : seq_A_B

sequence seq_B_C;

@(posedge clk)

`B ##1`C;

endsequence : seq_B_C

trans_A_B : cover property (seq_A_B);

trans_B_C : cover property (seq_B_C);

In this case cover property will cover state transitions which we are covering using transition bin in functional coverage.

Like these there are lot many constructs are there in System Verilog Assertions using which we can cover functionality.

As per my knowledge and experience if you use SVA for your functional coverage then you need to play a little bit with SVA constructs while things would be easy if you use functional coverage instead.

Big Advantage to use SVA Coverage model is, Engineer does not required object oriented programming language knowledge :-)

Happy Reading,
ASIC with Ankit