Synchronizing set and get uvm_config_db

UVM
,
1

Hey all; I hope you’re doing well this morning.
I have an issue to synshonize set and get in conifg db, I do set in the sequence and i get in scoreboard (for checking).To make it more clear here’s my pesuod code and my intentions about it.

I created a class called it rand_cfg( extends fr om uvm_sequence_item) where i randomize some bit vectors also some integers like


rand int        int_i;
rand bit        rd_n_wr;
rand bit [31:0] addr;
rand bit [31:0] data;
// wrote my constraints here

Then in my sequenc class, I randomize the the class (rand_cfg) to generate a random transfer then drive it to DUT.
But in my sequence I want to genarate many random transfers so my technique is as follows :


// Generate 1st transfer
assert(rand_cfg_i.randomize()); // randomization
uvm_config_db#(rand_cfg)::set(null,"*","rand_config_i",rand_config_i)

// Generate 2nd transfer
assert(rand_cfg_i.randomize()); // randomization
uvm_config_db#(rand_cfg)::set(null,"*","rand_config_i",rand_config_i)

// Generate 3rd transfer and so on

In scoreboard, In order to check the correctenss of the DUT output, we get the transfer set in sequence then drive to a ref mode then comapre DUT output with refmodel expected output.

to get the transfers in scoreboard, I do :


uvm_config_db#(rand_cfg)::get(null,"*","rand_config_i",rand_config_i)

Here, the scoreboard may get the 1st transfer twice if the 2nd transfer is not set yet in sequence (logical :;), I want my scoreboard to get the transfers after it was set.

2

In reply to abdelaali_21:

Please use code tags. I have added them for you.

The uvm_config_db is designed to pass configuration objects through the hierarchy. It is not designed to pass around transactions.

You should never pass any transactions from a sequence to a scoreboard. Your scoreboard should only receive data from monitors, and determine if the DUT response is correct based upon these transactions.

Also, never use ‘assert’ when calling randomize(). You should check the return value and respond appropriately.

3

In reply to cgales:

Thank you cglaes for your remarks; I have some questions;
1)I get transactions in the scoreboard because the refmodel inside the scoreboard needs to know the tranactions so it can issue the expected output then get dut output from the monitor. Is there a better way that can do the work without getting the transactions in scoreboard ?

  1. The DUT make transfers between memories and In scoreboard, In order to compare the data transfer between my UVCs (Slave UVC with memory). I created 2 memories where to store expected and actual data: here’s a part of my code

``` verilog
 
 // Scoreboard pseudo code
 bit [7:0] scb_exp_data_mem [99:0];
 bit [7:0] scb_act_data_mem [99:0];
 // build phase : build analysis port and tlm_fifos
 // connect phase : connect analysis port to tlm_fifos
 //run_phase 
    // wait if there s any transactions issued by one of monitors ( I have 4 UVC (4 monitor 
     and 4 memories inside the UVC))
 mtr1_fifo.get(tr1); // this expected data, store it in scb_exp_data_mem 
 mtr2_fifo.get(tr2);// get the actual, store in scb_act_data_mem 
 // at the end of each transfers : compare the scb_exp_data_mem with scb_act_data_mem ;




Is memories inside scoreboard the best way even data checking gets really complicated with 4 UVCs ? or what if i instantiate my UVC agnts in scoreboard (even if they re already instantiated in env) to have acces to memories of UVC. this way I'll compare the memories contents
4

In reply to abdelaali_21:

The scoreboard should function exactly like your DUT. It will get the same inputs that the DUT does via the monitor sensing the DUT inputs. It will determine what the correct response from the DUT should be using a golden reference model. And it will get the DUTs outputs from the monitor. By comparing the output of the DUT to the output of the reference model, the scoreboard will determine if the DUT functions correctly.

Using memories, queues, models, etc. inside the scoreboard are all valid ways of determining if the DUT is functioning correctly. At no point should the scoreboard receive any data that the DUT doesn’t also receive, hence no need to send data from the sequence to the scoreboard.