Effect of clocking block on uvm driver/monitor

In reply to dave_59:
@Dave_59

Wow! Thanks Dave. I didn’t know/think about 0-delay forever loop.

And you wrote:
“You could change your clocking block signal directions to ‘inout’. Thet would allow you to both drive and sample them”

I did this and things look good. Or should we have 2 clocking blocks? one for driver and one for monitor? which method is recommended?

BTW, I see below warnings after making clocking block signals to inout(I see warnings on DUT outputs):

"Variable ‘/tb_updn_counter_top/intf/current_value’, driven via a port connection, is multiply driven. "

Do i ignore them?

One more thing:
If i mentione input delay to be ‘0’ in clocking block, I have a data match in my TB. If i mention it to be non-zero, I see a data mismatch. RTL is offset by 1 value. Is this because the output is sammpled just before the clock edge and gets the previous value? How do we take care of this? Do we just check for previous value in TB?
Or keep input delay to be ‘0’?

PLease let me know.