Adding `uvm_info is changing the behaviour of the TB

UVM
1

Hi,

When I add the `uvm_info to the existing component I see change in the behaviour of the code.

Below is the code for AXI master driver component ; when I comment the uvm_info all the transaction items from the sequencer are driven and is seen on the waveform while if I enable the uvm_info I see that the driver shows the first beat in the second burst transfer to be driven but is not seen in the waveform.

Can the behaviour of code change when we add uvm_info statement?I see it happening just by commenting and uncommenting uvm_info statement . If so, how does it affect? How to fix it?

Below is the code:

task ma_driver::send_to_dut(ma_xtn xtn);
	apply_reset();
	//`uvm_info("FROM MASTER DRIVER","HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHELLLO",UVM_LOW);
	@(vif.madrv_cb);
	fork
			begin
				'''''
			end
			begin

				dly =$urandom_range(m_cfg.awaddr_to_awdata_lead_delay_min,m_cfg.awaddr_to_awdata_lead_delay_max);
				if(m_cfg.awaddr_to_awdata_config == LEAD)
				repeat(dly) @(vif.madrv_cb);
				wr_data(xtn);
			end
           join
        endtask

Below is the task which behaves differently when `uvm_info enabled or disabled

task ma_driver::wr_data(ma_xtn hdl);
	foreach (hdl.wr_tr[i])
	begin
			//@(vif.madrv_cb);
			foreach(hdl.wr_tr[i].Wdata[j])
			begin	
				`uvm_do_callbacks(ma_driver,master_driver_callback,pre_wr_data())
				if(m_cfg.wr_data_stream == OFF)
				begin
					vif.madrv_cb.Wvalid	<=	'b0;
					vif.madrv_cb.Wlast	<=	'0;
					vif.madrv_cb.Wdata	<=	'0;
					dly =$urandom_range(m_cfg.wr_addr_stream_min,m_cfg.wr_addr_stream_max);
					repeat(dly) @(vif.madrv_cb);
				end
				vif.madrv_cb.Wvalid	<= 	'b1;
              			vif.madrv_cb.Wdata	<=	hdl.wr_tr[i].Wdata[j];
			$display("$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$i=%d,j=%d,wdata=%d",i,j,hdl.wr_tr[i].Wdata[j],$time);	
				vif.madrv_cb.Wstrb     <=      hdl.wr_tr[i].Wstrb[j];
				if(j == hdl.wr_tr[i].Awlen)
				begin
				   vif.madrv_cb.Wlast	<=	'b1;
				`uvm_do_callbacks(ma_driver,master_driver_callback,post_wr_data())
				end
			 @(vif.madrv_cb);
              		if(vif.madrv_cb.Wready);	
			else
			begin
				wait(vif.madrv_cb.Wready);
	               	 		 @(vif.madrv_cb);
			end
 
		              
		
		end
		vif.madrv_cb.Wvalid	<=	'b0;
		vif.madrv_cb.Wlast	<=	'b0;
		vif.madrv_cb.Wdata	<=	'z;
			 @(vif.madrv_cb);
			if(vif.madrv_cb.Wready);	
			else
			begin
				wait(vif.madrv_cb.Wready);
			end
	
	end
endtask

When `uvm_info is uncommented I see that the i=1;j=0 value is driven by driver but not seen in the wavefrom
when it is commented it drives and the same can be seen on waveform. Not sure .why…

Thanks,
Shilpa

2

It is hard to know for sure what your problem is without more code. That might not be practical in this forum.

One potential problem is the mixture of wait statements and @(cb) events that may cause race conditions. My recommendation is once you start using @(cb) event control, only use those event controls.

Recode

 @(vif.madrv_cb);
			if(vif.madrv_cb.Wready);	
			else
			begin
				wait(vif.madrv_cb.Wready);
			end

as

 @(vif.madrv_cb iff vif.madrv_cb.Wready);
3

In reply to dave_59:

Thanks Dave!

I was not aware of race condition between @(cb)events and wait statements. With the change that u adviced I see that the code doesn’t break with or without the `uvm_info statement.

Also,I figured out the issue there had to be a clocking event after wait; to ensure that the data is driven at exact clock edge.The missing clocking event is causing the data to be driven just before the clock edge meanwhile at the clock edge next data is driven causing the previous data to not be seen on waveform.

                    @(vif.madrv_cb);
		if(vif.madrv_cb.Wready);	
		else
		begin
			wait(vif.madrv_cb.Wready);
                           //@(vif.madrv_cb); was missing in the previous code
		end

Adding the missing clocking event doesn’t break the code with or without `uvm_info.I see the TB is stable. Isn’t the above style not recommended; I ve used this style throughout my TB.

Thanks,
Shilpa