Variables

SystemVerilog
,
1

Is internal variable declared in dut , can be used by scoreboard?

2

In reply to SidRaj:

Is internal variable declared in dut , can be used by scoreboard?

There is nothing in SystemVerilog to prevent that. However, a scoreboard should not depend on the internals of the DUT for several reasons: 1) The DUT design can change, 2) The DUT should be seen as a black box with visibility to its ports only, 3) Scoreboard should rely on the requirements and not the DUT design.

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

  1. SVA Alternative for Complex Assertions
    https://verificationacademy.com/news/verification-horizons-march-2018-issue
  2. SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
  3. SVA in a UVM Class-based Environment
    https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment
3

In reply to ben@SystemVerilog.us:

Thanks for your answer.
I want to ask one thing more that , you told that only dut ports are available to verification Engineer, then without knowing internal structure of dut, how I will predicts correct output?

Also , like I am verifying FIFO model, in Scoreboard I copied whole internal structure of FIFO as a reference model. Is this correct way of predicting results?

Please solve my queries!

4

In reply to SidRaj:

In reply to ben@SystemVerilog.us:
Also , like I am verifying FIFO model, in Scoreboard I copied whole internal structure of FIFO as a reference model. Is this correct way of predicting results?

No, you shouldn’t use the internal structure of RTL for creating reference model. you should go through the specification and create the reference model.

Verification is process of checking RTL w.r.t specification.

5

In reply to Rahulkumar Patel:

Ok ,but if in dut like FIFO model , I uses registers to store and pop the data according to order,I push-in data in FIFO
Then to predict correct output in Scoreboard, there also ,I need to use registers to store and pop data sequentially
Then for this I copied this internal features of dut in scoreboard , So Is this wrong?

6

In reply to SidRaj:

In reply to Rahulkumar Patel:
Ok ,but if in dut like FIFO model , I uses registers to store and pop the data according to order,I push-in data in FIFO
Then to predict correct output in Scoreboard, there also ,I need to use registers to store and pop data sequentially
Then for this I copied this internal features of dut in scoreboard , So Is this wrong?

  1. Yes, it is wrong. In the scoreboard model, the FIFO is modeled as a queue. For example:
    int dataQ [$:1024];

  2. Then to predict correct output in Scoreboard
    From my SVA Handbook 4th Edition
    scoreboard: In verification, a scoreboard is a data structure, independent from the design under test, used to store expected results for later comparisons against actual results. Scoreboards can be records (e.g., struct), queues, associative arrays, dynamic arrays. Assertions can access scoreboards in the verification process.
    Thus, a scoreboard works in conjunction with the verification environment. For a simple problem, I suggest that you use assertions. See below for some examples using the queue that models the FIFO at a higher level than registers and controls.


// ..
int rdata_from_q; // read data from queue to compare to Receiver
int dataQ [$:1024];  // queue, to store/read incoming data, restricted to 1K
int dataQsize; // queue size.
assign dataQsize= dataQ.size;  // for use with assertions and 1800-2009 style
// Storage of data into queue
always @ (posedge clk_xt33)
if (reset_n==1'b0)
dataQ = {1}; // clear the queue contents
else  if (wr_33) dataQ.push_front(wdata);  // store data
// Collect data from the Q
always @ (posedge clk_rcv25)
if (rd_25)  rdata_from_q <= dataQ.pop_back();
// Data integrity check
property p_read_data_integrity;
@(posedge clk_rcv25)
rd_25 |=>  rdata_from_q==rdata;
endproperty : p_read_data_integrity
ap_read_data_integrity : assert property (p_read_data_integrity);
// Never a READ with no data received
property p_never_read_on_empty;
@(posedge clk_rcv25)
// not (dataQsize == 0 && rd_25); // Poor style
(dataQsize == 0) |-> !rd_25;
endproperty : p_never_read_on_empty
ap_never_read_on_empty : assert property (p_never_read_on_empty);
// never a write on a full buffer
ap_write_on_max_buff : assert property (@(posedge clk_xt33)
// not (dataQsize == MAX_BUFF_SIZE && wr_33);  //
// using "not" does not provide for good statistics or counterexamples
(dataQsize == MAX_BUFF_SIZE) |-> !wr_33); // better style
// After a write, dataQ.size !=0"
ap_Q_SizeNot0_afterWr : assert property(@(posedge clk_xt33)
wr_33 |=> dataQ_size!=0);
// "after a reset, dataQ.size==0"
always_comb begin
if(!reset_n) ap_Qsize_reset: assert #0 (dataQ_size==0);
end

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

  1. SVA Alternative for Complex Assertions
    https://verificationacademy.com/news/verification-horizons-march-2018-issue
  2. SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
  3. SVA in a UVM Class-based Environment
    https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment
7

In reply to ben@SystemVerilog.us:

Now ,I want to ask that as a Verification Engineer we should check for normal functioning of DUT as well as the corner cases in which DUT can show error.
Now in my Dut model which is FIFO model, there are 3 output port which are fifofull,fifoempty,dataout.
Now there can be corner case where if push and pop occurs simultaneously dut will show errors.
Now should I include this case in the RTL design coding of FIFO and make one another output port which becomes high when this type of corner cases occurs and display error message in dut model itself ?
Or should I predicts this corner cases only in scoreboard and display error there in Scoreboard ?
Or should I make another output port for corner cases in dut coding and pass this signal to scoreboard and compare this output with the scoreboard prediction and display message in Scoreboard accordingly if predicted and actual results matches or not?

8

In reply to SidRaj:

Now in my Dut model which is FIFO model, there are 3 output port which are fifofull,fifoempty,dataout.
Now there can be corner case where if push and pop occurs simultaneously dut will show errors.

You have to go back to the requirements. Do they say that it is illegal to do simultaneously do a read and a write? Depending on the RTL design it may be legal to do that.

Now should I include this case in the RTL design coding of FIFO and make one another output port which becomes high when this type of corner cases occurs and display error message in dut model itself ?

I FIFO as an IP unit that can be reused in many systems needs an error output for several reasons. At the system level, it may take corrective actions. It is also useful for debug.
The requirements should specify what happens when you do error conditions, as these states can be entered with the input smiluli. For example, on a read and write, what is provided as read-data, and what is written, if any into the FIFO. Same question on a push on full, or pop on empty.

Or should I predicts this corner cases only in scoreboard and display error there in Scoreboard ?

I defined above what is a scoreboard; it keeps the score as to what the DUT (FIFO here) should behave to the stiluli in accordance with the detailed requirements. If you have weak requirements, it’s the GBGO. The scoreboard is not a monitor, it does not record what is happening, but what should happen.
Also, the scoreboard is not a verifier. The verification logic will use the scoreboard along with the monitor (or active monitoring) of the DUT. The the code i presented in my previous reply, the queue and its requirement rules models the scorebooard. The assertions do the verification.
There is no “prediction of corner cases”. The testcases should cover all the aspects of the requirements. Sounds like you do not have a requirement document.
The following book demonstrates how to write chip specs. I used VHDL as a model, and the verification methodology in that book is not something i recommend today because the technology has significantly changed since then. However, the spec writing has not really changed; requirements and specs are just that, specs.
FREE BOOK: Component Design by Example
… A Step-by-Step Process Using VHDL with UART as Vehicle

Or should I make another output port for corner cases in dut coding and pass this signal to scoreboard and compare this output with the scoreboard prediction and display message in Scoreboard accordingly if predicted and actual results matches or not?

I don’t understand this concept of another port. You have a DUT and a verification environment that drives the DUT and checks it in accordance with the requirements.
The requirements have normal cases and define the behavior under corner cases.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr

  1. SVA Alternative for Complex Assertions
    https://verificationacademy.com/news/verification-horizons-march-2018-issue
  2. SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
  3. SVA in a UVM Class-based Environment
    https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment
9

In reply to ben@SystemVerilog.us:

Thanks for clearing my doubts.Can I send my code to your mail id so that you can help to find where I am getting wrong.?

10

In reply to SidRaj:
I can can give you guidelines. I presume that you have a requirement document.
Ben