UVM End of test

UVM
,
24

In reply to chr_sue:

Thanks for the response, Here is my basic scoreboard structure. Following are the points which need to be taken into consideration.

  1. The below structure is having two analysis imports, which are connected to Two different monitors (let just say monitor_trans1 and monitor_Rec1). Both these monitor writes into the scoreboard using these analysis imports.
  2. To differentiate between two different write imports, I have used decl macro. I am using tlm fifo (not analysis fifo) here to store incoming transactions. Why I am using it? because I have analysis import and I can use it write method, I know analysis fifo has its own merits, but my scope of work suits this kind of implementation.
  3. Both monitors as described in point-1 send data, monitor-trans1 is monitoring the driven data to the DUT and monitor_Rec1 is monitoring response data from the DUT.
  4. Now what is happening, I come to the Issue, You see in the analysis_import write implementation I am also printing the received transaction from its respective monitor (you can assume it as a write print). In task thread1 when we are getting the stored transaction, we are again printing the transaction (you can say it as read print).
  5. I have run a test containing 10-transactions, which means 10 transactions being sent to DUT and DUT will give a response and that will also be 10 in number. So the total entries to each respective monitor will be 10. (means there will be 10 write prints.)
  6. Now in task thread1(), I am getting those transactions from the fifos and comparing the concerning data. What I am seeing in my log, there are 10-write print present for each fifo, which means monitor have sent transaction 10-times, but when I am seeing read print for each fifo, they are only 7, which means there are still some entries in both fifos, which are not taken out during the normal simulation time of scoreboard run-phase.

I need to know, why this behavior is happening, I have used queues, fifos everything, but this behaviour keeps on happening. I feel somehow my scoreboard is shutdown and it did not recover.
I read somewhere in the blog, when there is some delay in a uvm_oomponent in response, other uvm component which are dependent on that response of uvm_component shuts themselves down. Is it correct or not



`uvm_analysis_imp_decl(_trans1)
`uvm_analysis_imp_decl(_Rec1)

class scoreboard extends uvm_scoreboard;
 uvm_tlm_fifo #(seq_item) fifoRec1,fifotrans1;
 uvm_analysis_imp_fifotrans1 #(seq_item,scoreboard) item_fifotrans1;
 uvm_analysis_imp_fifoRec1 #(seq_item,scoreboard) item_fifoRec1;

 function new(string name, uvm_component parent);
  super.new(name,parent);
 endfunction
 
// There is a usual build_phase is implemented. I have not given its implementation.
endclass

task scoreboard::write_trans1(input seq_item tr);
 seq_item pkt = new();
 pkt.copy(tr);
 fifotrans1.try_put(pkt);
 $display("Queue Got this data: %0h",pkt.data);
endtask
 
task scoreboard::write_Rec1(input seq_item tr);
 seq_item pkt = new();
 pkt.copy(tr);
 fifoRec1.try_put(pkt);
 $display("Queue Got this data: %0h",pkt.data);
endtask
 
task scoreboard::run_phase (uvm_phase phase);
  forever begin
    thread1();
  end
endtask
function compare_data (input bit [31:0] indata1, indata2);
 if (indata1 == indata2) begin
  $display("Pass");
 end
 else begin 
  $display("Fail");
 end
endfunction 

task scoreboard::thread1()
	fifo_Rec1.get(Rec1);
	$display("Queue Received this Data: %0h", trans1.data);
	fifo_trans1.get(trans1);
	$display("Queue Received this Data: %0h", Rec1.data);
	compare_data(trans1.data,Rec1.data);  // this function two inputs and check equality
endtask