Hello Everyone,
I created a DUT for a simple memory system along with its UVM testbench. I am unable to detect the problem that why my monitor is providing an incorrect data. It is displaying the “zero” value for the first set of Driver inputs. I have attached the link for my code, I will be grateful if you can detect the error for me.
Sincere Regards,
In reply to SV26:
THis happens because you are driving @0 data, but there is still the reset active, resetting all data.
In reply to chr_sue:
Thank you for the response, but I am still unable to rectify the problem. Can you please pinpoint the main position of error.
Regards,
In reply to SV26:
This is the first entry from the driver:
UVM_INFO my_pkg.sv(46) @ 0: uvm_test_top.env.agnt.sqncr@@seq [my_sequence] Starting the sequence
UVM_INFO @ 30000: uvm_test_top.env.agnt.driv [DRIV] Driving data across DUT:
wr= 1
addr= 1
data= 24
It is from runtime 0 (see @0). What you are printing is the content of your seq_item. At that time the reset is active in your DUT. This resets the mem to ‘0’ and the driver data do not show-up here. Thjis results in the monitor values of:
UVM_INFO my_pkg.sv(135) @ 50000: uvm_test_top.env.agnt.mon [MON] Monitor received data for WR operation
UVM_INFO @ 50000: uvm_test_top.env.agnt.mon [MONITOR] Monitoring data:
wr= 0
addr= 0
data= 0
And you had a few weaknesses in your code tolerated by VCS.
See how it works here:
In reply to chr_sue:
Thank you so much. I really appreciate the help.
In reply to chr_sue:
Sir,
So far I understood my previous error and I am getting positive results for the write operation. But, for the read operation, the value at vif.rdata is 0 for each case. I tried everything but was unable to correct the code.
Hi,
There are inconsistencies that should be resolved in your test bench.
You forgot to set the reset to 1 after you change it to 0, so your memory is always resenting all registers.
…
initial begin
rst = 1;
end
…
In your reading task you use non-blocking assignments,
vif.driver_cb.wr <= req.wr;
vif.driver_cb.addr <= req.addr;
req.rdata <= vif.driver_cb.rdata;
So your rdata is the current interface rdata and not the read from the requested address, since all three assignments occur in parallel. But switching them to blocking assignments is not enough, since your DUT needs a clock pulse to answer a read request. So to resolve this you should wait a clock pulse before copying rdata.
…
@ (vif.driver_cb)
req.rdata = vif.driver_cb.rdata;
…
This solves your reading problem, I hope I helped.
In reply to PedroCavalcante:
Hi,
Thank you for replying to my problem. I did the reset thing but even after changing the driver, it is still showing the same error, infact, now the monitor output is increased by 4 redundant display.
In reply to SV26:
The variables driver_cb.addr and driver_cb.wr is illegally driven by a
blocking assignment.
A simple solution is to change only the code displayed in my previous post to look like this:
vif.driver_cb.wr <= req.wr;
vif.driver_cb.addr <= req.addr;
@ (vif.driver_cb)
req.rdata = vif.driver_cb.rdata;
It is not a good practice to use blocking and nonblocking assignment in the same task but it solves your problem.
In reply to PedroCavalcante:
Yes, you are right and I already did that before, but still the problem remains intact.
Look at this,
UVM_INFO my_pkg.sv(142) @ 90000: uvm_test_top.env.agnt.mon [MON] Monitor received data for WR operation
UVM_INFO @ 90000: uvm_test_top.env.agnt.mon [MONITOR] Monitoring data:
wr= 1
addr= 2
data= 3f
UVM_INFO @ 90000: uvm_test_top.env.scb [SCOREBOARD] Data in Scoreboard:
wr= 1
addr= 2
data= 3f
UVM_INFO my_pkg.sv(149) @ 130000: uvm_test_top.env.agnt.mon [MON] Monitor received data for RD operation
UVM_INFO @ 130000: uvm_test_top.env.agnt.mon [MONITOR] Monitoring data:
wr= 0
addr= 2
rdata= 0
UVM_INFO @ 130000: uvm_test_top.env.scb [SCOREBOARD] Data in Scoreboard:
wr= 0
addr= 2
rdata= 0
UVM_INFO my_pkg.sv(110) @ 130000: uvm_test_top.env.agnt.driv [DRIV] Need Data from the memory:
wr = 0
addr = 2
rdata = 0
also,for 10 random inputs, monitor is displaying 14 outputs,
** Report counts by id
[DRIV] 10
[MON] 14
[MONITOR] 14
[RNTST] 1
[SCOREBOARD] 14
[TEST_DONE] 1
[UVM/RELNOTES] 1
[UVMTOP] 1
[my_sequence] 2
In reply to SV26:
On the monitor you should also wait for a clock pulse after you get the address to just get the rdata.
seq_item.wr=vif.monitor_cb.wr;
seq_item.addr=vif.monitor_cb.addr;
@(vif.monitor_cb);
seq_item.rdata=vif.monitor_cb.rdata;
In reply to PedroCavalcante:
Thankyou very much, that clears my problem.