Prliminary verification of the DUT by designers

SystemVerilog
2

In reply to Farhad:

  • …how much effort should the design team put in order to do a preliminary verification of their design, before delivering it to the verification team?
    Good question. It is my belief that RTL designers should do code reviews of the code and the assertions with whoever wants to listen and also do sanity checks. Those assertions can originate from both the verification team and the designer who clarifies the internals of the design.

  • What is a sanity check? I use the following checks when I verify my assertions. the TB basically contains the instantiation of the DUT, variable declarations and clocks, and an initial statement to generate constrained-random tests. Below is my template for that initial statement. Randomized weights can be adjusted. You’ll be surprised at the number of errors you can catch.

initial begin
bit v_a, v_b, v_err;
repeat (200) begin
@(posedge clk);
if (!randomize(v_a, v_b, v_err) with {
v_a   dist {1'b1 := 1, 1'b0 := 1};
v_b   dist {1'b1 := 1, 1'b0 := 2};
v_err dist {1'b1 := 1, 1'b0 := 15};
}) `uvm_error("MYERR", "This is a randomize error");
a <= v_a;
if(v_err==0) b<=v_b; else b<=!v_b;
end
$finish;
end

  • Is is a good idea that they use the UVM or SV infrastructure, which is developed by the verification team?
    If the UVM model is available, I have no objections to using it. Typically, at when I was doing designs, the DUT consisted of small partitions that were integrated as a whole to make the complete design. Will the UVM accommodate testing those partitions? What modifications you need to make it work.

  • **My points:**There may be disagreement in what I am about to say, but I believe that before getting into simulation or formal verification, one needs a good set of assertions at the system and internal level to clarify the requirements and assumptions. Those assertions and the RTL code should be reviewed by engineers. Those reviews address the RTL approach and the understanding of the requirements. The designer can do the sanity check during the design process and after the reviews. The TB test team can then take it from there,

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
** SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
…

  1. SVA Package: Dynamic and range delays and repeats SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
  2. Free books: Component Design by Example https://rb.gy/9tcbhl
    Real Chip Design and Verification Using Verilog and VHDL($3) https://rb.gy/cwy7nb
  3. Papers:

Udemy courses by Srinivasan Venkataramanan (http://cvcblr.com/home.html)
https://www.udemy.com/course/sva-basic/
https://www.udemy.com/course/sv-pre-uvm/

The second question is, how should the designers do their initial verification? Or should they just pre-verify their design in any manner they like? I mean, ideally, the testbench and the design should be developed in parallel with each other, by two separate teams. So if the TB is ready by the time the design is finished, can the designers use the TB to do a preliminary verification of their design?