Systemverilog bind versus PSL vunit

Systemverilog bind is used to instantiate a module into another without having to modify the original code. It is an “out of scope” instanciation. Since this creates a new instance, the bound unit has its own scope, and its internal signal names do not have to match the ones from the target module. The new module communicates with the target through its pins (or with OOMR - Out Of Module Reference).

PSL vunit in opposition, is almost like an `include statement which is added externally to the target module. Similarly the latter does not have to be edited. Like an `include, a vunit does not create its own scope. Hence, the signals inside the vunit have to match the ones of the target module.

Delayed Blocking versus Non-Blocking Assignments

​Hi,

A question that I am often asked is how to write a simple delayed buffer model in verilog, especially when considering its behavior regarding input glitches.

There are several possible coding styles: blocking versus non-block assignments, and delayed evaluation versus delayed assignment.

Here is a little testcase presenting the effect of the 4 possible combinations of code. You will see that the most "natural" behavior is obtained from the third style, using Blocking and delayed assignment.

regards

- Regis

​module tb;

reg in = 1'b0;

initial begin

  #10 in <= 1;

  #10 in <= 0;

  #10 in <= 1;

  #3  in <= 0;

  #3  in <= 1;

  #9  in <= 0;

  #10 $finish;

end

reg o1 = 1'b0;

reg o2 = 1'b0;

reg o3 = 1'b0;

reg o4 = 1'b0;

always @(in) #5 o1  = in; // Blocking,     delayed evaluation (wait 5ns, then evaluate and assign immediately)

always @(in) #5 o2 <= in; // Non-Blocking, delayed evaluation (wait 5ns, then evaluate, then 

always @(in) o3  = #5 in; // Blocking,      delayed assignment

always @(in) o4 <= #5 in; // Non-Blocking,  delayed assignment

//              10   15    20         30  33  36   41   45    50

//              +----------+          +---+   +---------+

// in __________|          |__________|   |___|         |__________

//                   +----------+                   +---------+

// o1 _______________|          |___________________|         |_____

//                   +----------+                   +---------+

// o2 _______________|          |___________________|         |_____

//                                           35

//                   +----------+            +----------------+

// o3 _______________|          |____________|                |_____

//                   +----------+          +---+   +---------+

// o4 _______________|          |__________|   |___|         |__________

endmodule

Using UVM field access policy to manage bit bashing test

Hi,

If you're using UVM Register Layer, you might be interested by the predefined Test Sequences that are provided. I'm going to talk specifically about the uvm_reg_bit_bash_seq sequence. 

It is a bit-bashing test : it sequentially writes "1" dans "0" in each bit of all the registers, checking it is appropriately set or cleared, based on the field access policy.

The UVM 1.1 User Guide explains that the following attributes can be used on a register to skip it from the bit bashing test: NO_REG_BIT_BASH_TEST, NO_REG_TESTS

Unfortunately, these attributes act at register level, and not at field level, which would be useful to exclude individual fields or bits like a soft reset (to prevent the chip shutdown during the test).

Guess what ? In fact you can (exclude inividual fields/bits from the bit bashing). You just have to give your bits/fields the WO (write only) attribute. The test will not attempt to write to it because it has no means to read the written value back (write only means no read).

It is now extremely easy to prevent the soft reset to be triggered by the bit bashing test.

Note: you can also use these other filed attributes: WOC, WOS, WO1.

A few words about assertions, coverpoints and Verification Plan

Hi,

It might not be crystal clear how to use assertions and coverpoints, having in mind that these metrics are meant to be bound to a Verification Plan.​

Let's take an example. We have a 8 bit register in the design (a counter or whatever): 

• We want to make sure each time the register value changes, it is as expected. somehwere in the bench you'd calculate the expected value, and an assertion would make sure expected and actual values always match.
• But how do you know if all possible values of your register were actually verified ?
• Bad idea: create one assertion per possible value. Any non-triggered assertion would tell you what was not covered. But of course 8 bits would need you to create 256 assertions... And what if N is 32 bits or more ???
• Better: create a coverpoint that will give you an exhaustive status of the values that have actually been those of you register. In parallel a single "equation based" assertion would be enough.
• You would then bind both the assertion and the coverpoint to yout vPlan.

Hope this helps,

regards

- regis