In reply to Francesco Colonna:
Assuming
clk and
clock are indeed the same “clock” generating a posedge in the same delta cycle, then you are correct that the monitor samples the “old” value of out_a.
I’m not sure if you indented to use two different clock signals, but that’'s where problems can be introduced, especially in gate-level simulations with delays. If
clock gets delayed more than a delta cycle from
clk, you get the “new” value of out_a.
A clocking block helps by guaranteeing that you use the sampled value out_a before the the clock edge and removing any skew between clocks. But if you do not plan on doing any gate-level simulation and have made sure all your synchronized clocks have no delta delays, you can avoid using clocking blocks.
All of what I just wrote assumes you start your UVM testbench with run_test() called in a module. All of the “old” verses “new” races get flipped around if you start your testbench in a program block (which I strongly recommend you avoid). In that case your monitor reads the “new” value of out_a, assuming there are no delays in the RTL. And now if
clk gets delayed more than a delta cycle from
clock, the monitor see the “old” instead of the “new” value. Add a clocking block makes sure you read the “old” values out_a in your monitor.