Scoreboard input output compare problem

OVM
1

Hi,

I have problem in Scoreboard, where I try to compare DUT input and outputs.

I have one task which has DUT input fifo:
if (fifo_item1.reg_data_in[3:0] == 4’b0101 ) begin
ovm_report_info(“”, “PUT STUFF INTO A FIFO”); // This is ok!
local_analysis_queue[1].push_front(fifo_item1); // put into a fifo

Then I have checker task:
forever begin
// wait for queue events
@(freq_analysis_queue[0][0]); // DUT output queue

     queue_item1 = local_analysis_queue[1].pop_front();
     queue_item0 = freq_analysis_queue[0].pop_front();
     $display("DUT input: ", queue_item1.reg_data_in);

So when something happens in DUT output (@(freq_analysis_queue[0][0]) ), DUT input and output fifo’s are read. Problem is that dut Input fifo reg_data_in = 0 even thou I will put data into a fifo when ifo_item1.reg_data_in[3:0] == 4’b0101 and I can see this “PUT STUFF INTO A FIFO” is happening, so I should get 4’b0101 out from fifo. I can see that DUT output is 4’b0101 so something is done right but I don’t understand why DUT input is = 0 even thou it shouldn’t. Queue items are defined like this:

  out_transaction queue_item0;
  reg_transaction queue_item1;

Any idea’s what could be the problem here?

2

It’s hard to tell what’s the problem from the code you posted, but here’s a thought: Have you cloned or copied the transaction item before storing it in the queue? If not, are you certain that you’re not simply overwriting the contents of the “fifo_item1”?
It’s easy to forget that the “instance” of a class is really just a pointer that you copy around. So if you want to take a copy of an object for later use, you must copy the object using OVM’s clone() or compare() methods - just copying the pointer is not enough.
Hope this helps.

3

I still don’t understand this. I attached scoreboard.sv here.

In row 143 if I put there reg_data_out, which is in VHDL is constant FFF…F, then I get correct output. Reg_data_in, which is not constant, for some reason gives 0 instead of 5…

This is what I get in Questa:

OVM_INFO @ 26325: ovm_test_top.m_otso_env.scoreboard PUT STUFF INTO A FIFO

OVM_INFO @ 48255: ovm_test_top.m_otso_env.scoreboard PUT STUFF INTO A FIFO

Reg data in: 0

temp1: 5

temp1_LB: 0

Reg data in: 0

temp1: 5

temp1_LB: 0

Any ideas?

4

It seems that local_analysis_queue[1] fills up nicely and reg_data_in is 00…0101 as it should be. Then when it at the first time goes to here queue_item1 = local_analysis_queue[1].pop_back(); // read first
suddenly every 101 changes to 000 in every position of queue. So the whole queue reg_data_in is reset to 0. Interesting.

5

I have used Questa 6.4c. Could it be Questa problem in this case? I guess there’s 6.5 version available…

6

This is the same with Questa 6.5 and ovm-2.0.1…

7

The symptoms you describe sounds exactly like you’re NOT cloning your transaction objects before pushing them into the queue.
I can’t help you with Questa debug as I’m a Cadence guy, but I would imagine that Questa can tell you some information about the objects in the queue.
In IUS you could use the GUI to see the content of the queue and the object handles (pointers) so it would be very easy to see if all the object handles are pointing to the same class instance.

Have you tried isolating the scoreboard code into a small stand-alone testbench so that you can eliminate the DUT and other SV code from the confusion?

8

Thank you stephenh, you were absolutely rigth about this, now it’s ok :D

Here’s the ok version of task:

virtual protected task local_analysis_fifo_read();
reg_transaction fifo_item2;
reg_transaction fifo_itemy;

  forever begin
 
     // wait for data in fifo     
     local_analysis_fifo.get(fifo_item2 ); // blocking, purposefully...
 fifo_itemy = new fifo_item2;
 
     // check transaction validity for specific check(s)/queue(s) & insert
     if (fifo_item2.reg_data_in[3:0] === 4'b0101 ) begin 
    ovm_report_info("", "PUT STUFF INTO A FIFO");
        local_analysis_queue[1].push_front(fifo_itemy); // write last 
 end
  end

endtask : local_analysis_fifo_read;