Hi Experts
Before implementation of testbench ,
Avinash
In reply to Avinash:
Good question. Given the set of requirements, I approach the development in a bottom up approach, particularly since there are templates or other automation to build the the higher level structures (more on tools below). I also like the idea of building something fast, and then refining it. Thus,
1) Define the interfaces
This will define the signals that need to be driven
2) define the sequence item (the transaction) and some constraints
That defines what will be driven and with which constraints. I believe that the constraints can be refined later on, but easy known ones could be defined here.
3) define the driver
4) define the agent and environment
5) define top
6) do a sanity check
Hopefully, you also added assertions in the interface and a checker or module bound to the DUT.
7) build the rest of the Testbench units (monitor, checkere, etc)
Also refine the constraints and tests.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
In reply to ben@SystemVerilog.us:
Hi Ben
Thanks for your reply. I full understand your answer to it and it was really exaustive one.
Question : While building the scorboard(checker) I end up modelling the design.
Sometime it gets complex and my checkers wont be stable for all the possible scenarios ,
dont know if my approach is right. Any thoughts on it ?
Lets take a counter design which output a count value. The counter update happen on many input conditions. As inputs are many I cannot use assertions(Am ).
Now as I understand I take the same input and end up modelling how the output count should change depending on these numerous inputs.
Do you suggest any other way?
Your suggestions would be helpful.
Avinash
In reply to Avinash:
Lets take a counter design which output a count value. The counter update happen on many input conditions. As inputs are many I cannot use assertions
You’re underestimating the powers of assertions. For complex problems, like the ones you are referring to, you need to write multiple small assertions. Since you’re addressing a counter, below is something I wrote for a class on assertions. It’s a very funky type of counter!!!
Requirements
package counter_pkg;
timeunit 1ns; timeprecision 100ps;
`define TOP counter_tb
const int MAX_COUNT=6, MIN_COUNT=3;
typedef enum {CT_LOAD, CT_RESET, CT_WAIT, CT_DONE} ct_scen_e;
endpackage : counter_pkg
module counter_max (
input logic[3:0] data_in,
input logic ld,
output logic[3:0] counter,
input logic clk, rst_n) ;
import counter_pkg::*;
int cover_count=0;
int fail_count=0;
// ap_P: assert property(@ (posedge clk) P )
// parameter MIN_COUNT=2; // module item parameter
// If use of parameter port list, then can't use defparam
default disable iff !rst_n;
property p_load;
logic[3:0] v_data_in; // local variable to property
(ld && (data_in>= MIN_COUNT && data_in <= MAX_COUNT), v_data_in=data_in) |=>
counter==v_data_in;
endproperty : p_load
ap_load: assert property ( @(posedge clk) p_load);
property p_hold_on_load;
ld && (data_in< MIN_COUNT || data_in > MAX_COUNT) |=>
$stable(counter);
endproperty : p_hold_on_load
ap_hold_on_load: assert property ( @(posedge clk) p_hold_on_load);
ap_count: assert property(@(posedge clk)
!ld && (counter!=MAX_COUNT) |=> counter==$past(counter)+1'b1);
ap_hold: assert property(@(posedge clk)
!ld && counter==MAX_COUNT |=> counter==$past(counter));
mp_min_load: assume property(@(posedge clk)
ld |-> not(data_in<MIN_COUNT));
mp_max_load: assume property(@ (posedge clk)
ld |-> not(data_in > MAX_COUNT))
cover_count++; else fail_count++ ;
ap_statble8: assume property(@(posedge clk)
$stable(counter)|-> ##[1:8] !$stable(counter));
ap_reset: assert property(@ (posedge clk) disable iff (1'b0)
!rst_n |=> counter==MIN_COUNT);
always @(posedge clk) begin : counter1
if(!rst_n) counter <= MIN_COUNT;
else if (ld && data_in >= MIN_COUNT && data_in <= MAX_COUNT)
counter <= data_in;
else if (!ld && counter!=MAX_COUNT) begin : counter2
counter <= counter + 1'b1;
end : counter2
end : counter1
endmodule : counter_max
Notice the many small assertions that cover the different cases; thus, your statement that “As inputs are many I cannot use assertions” is not true.
Question : While building the scorboard(checker) I end up modelling the design.
Sometime it gets complex and my checkers wont be stable for all the possible scenarios ,
dont know if my approach is right. Any thoughts on it ?
The scoreboard may indeed possess a lot of the modeling feature of the original design, and this is why the checker with scoreboarding may not necessarily prove that the design is OK. Below is code from by testbench scoreboard (used as demo for the class)
virtual function void counter_scoreboard ();
//forever begin : f_ever
$display("counter_scoreboard started @ %t", $time);
// @(this.m_vif.driver_cb)
if (this.m_vif.mon_cb.rst_n==1'b0) begin
$display("counter_scoreboard reset @ %t", $time);
this.counter =MIN_COUNT;
end
else if (this.m_vif.mon_cb.ld) begin : load
if (this.m_vif.mon_cb.data_in >= MIN_COUNT &&
this.m_vif.mon_cb.data_in <= MAX_COUNT) begin : if2
this.counter = this.m_vif.mon_cb.data_in;
$display("this.counter in checker=%d", this.counter);
end : if2
end : load
else if(this.counter==MAX_COUNT)
this.counter = this.counter + 1'b0;
else this.counter = this.counter + 1'b1;
// end : f_ever
endfunction : counter_scoreboard
Do you suggest any other way?
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
In reply to ben@SystemVerilog.us:
related to this topic: PostPosted: Wed Aug 27, 2014 12:28 am Post subject: UVM scoreboard/monitor/predictor or SVA? Reply with quote Edit/Delete this post Delete this post
Interesting discussion about usage of scoreboard/monitors/predictors and SVA
https://verificationacademy.com/forums/uvm/any-idea-uvm-environment-general-counter-design
My summary point: A scoreboard / predictor / assertions are all techniques to implement a verification or checking that the design meets the requirements. In effect, they are all “assertions”, in the general sense, in that they assert or state/check that indeed everything that the DUT has experienced so far is indeed OK.
UVM puts a big hoopla about the scoreboard/monitor approach; but, as Gordon and I mentioned, an assertion language (e.g., SVA) is a methodology that is very efficient from a coding viewpoint because it skips those steps of monitoring and predicting the results. SVA does not work too well in all cases, but for many cases it does a fairly good job, and it should not be discounted, just because it is “NOT UVM”.
Another advantage of SVA is that it clarifies the requirements, something that should be done prior and during the design process.
I demonstrate the usage of assertions using an activity counter model
Ben SystemVerilog.us
In reply to ben@SystemVerilog.us:
Hi Ben
Thanks for your wonderful reply.
Will help me greatly.
Avinash