Hi we're facing to what it seems a synchronization problem when driving the signals on the driver. To put you in context, we have an interface with a clocking block defined like this:
clocking cb @(posedge clk);
default input #1step output #(1.2ns);
output sb_id, nxt_sen, kill;
the run_phase of the driver looks like this:
task run_phase(uvm_phase phase);
vif.cb.sb_id <= trans.sb_id;
vif.cb.nxt_sen <= trans.nxt_sen;
vif.cb.kill <= trans.kill;
vif.cb.nxt_sen <= 1'b0;
vif.cb.kill <= 1'b0;
As you can see in the run_phase of the driver it has a synchronization after driving the the transaction, and then we set the nxt_sen and kill signals to '0, as it is the default state of the interface . The problem with this is that both nxt_sen and kill signals always stays at 0.
As you can see, transactions keep coming since sb_id signal is changing, but nxt_sen stays at 0, although in the transaction it is set to 1.
The way I thought this forever loop worked is:
cycle 0: If there is a transaction get it
cycle 0: Drive the signals and wait for clock posedge (nxt_sen should be to 1 at least for 1 cycle)
cycle 1: Set nxt_sen and kill singals to 0
cycle 1: Wait for a next transaction, if there's one get it so we would drive this new transaction in cycle 1. If there isn't new transactions step into next cycles until there's one.
For what I've been able to investigate, trying different approaches, is that the synchronization is not done properly but I couldn't find a resource that explains how timing in RTL simulations work and the behavior of SystemVerilog. Also when in the documentation of the get_next_item function says:
If no sequence is available, wait for a requesting unlocked relevant sequence, then re-arbitrate
How it does the wait ?
Thanks for the help.