Guaranteed race-free sequence to sequence communication with their drivers being on the same clock

UVM
1

What is a possible approach to communicate between 2 sequences so that is 100% sure that the simulation result does not depend on the order in which the simulator (Questa) schedules its processes in a timestep?

To clarify with an example: I have 2 sequences and a communication channel between them (e.g. a mailbox M)

  • a source sequence, which will generate sequence items (driver sends these into the DUT). Everytime a sequence item was finished, the sequence checks M to know if it needs to send another sequence item, or if it needs to end.
  • a sink sequence: this will collect sequence items (data coming out of the DUT) and knows how many to collect. When it has collected all it needs, it puts a message in M to inform the source that it can stop.

Both drivers (need to) run on the same clock (edge). Assume the timestep where the sink ends and this is also when a source item was handled. see what happens depending on the order in which Questa schedules the processes:

possibility 1:

  • source sequence checks mailbox. it is empty → a new sequence item is sent into the DUT
  • sink sequence puts message in mailbox

possibility2 :

  • sink sequence puts message in mailbox
  • source sequence gets this message and ends

Although both simulations can be working, it is really awful to have such kind of non-determinism when debugging.
In my case I have 8 sources, 8 sinks, and all sources can interact with all sinks. So there are 64 possible point to point communications.

The issue I think is that systemVerilog and the available UVM channels do not use an evaluate-update mechanism (~NBA in SV?) like VHDL or systemC does. In systemC I could just have used a TLM_FIFO and as this uses evaluate update there is no race condition. The UVM TLM FIFO’s do not seem to have this mechanism (some extra NBA stuff had to be added for the driver/SQR communication uvm_tlm_fifo - (how) does it guarantee deterministic simulations? | Verification Academy). The mailbox also doesn’t have this.

Just 2 questions:

  • did I miss something obvious?
  • would it be possible to construct a communication channel around a mailbox that solves this? E.g. to combine a mailbox with some NBA or so?
2

In reply to NiLu:

The cheap thing I sometimes do is:


task body();
  // ... do stuff
  
  uvm_wait_for_nba_region();
  if (some_mailbox.try_get())
    // ... do stuff to stop
endtask

The uvm_wait_for_nba_region() task will give other threads a chance to execute(basically like a #0 on steroids) and when it returns you’ll know your sink sequence had a chance to say that enough is enough. That is, unless your other process is also calling this function; then you end up back where you started.

It’s not really an elegant solution, but it’s pragmatic.

3

In reply to NiLu:

This might be https://accellera.mantishub.com/view.php?id=4408

4

In reply to Tudor Timi:

Thanks! Like you say not the most elegant thing to do, but sounds like a workable solution.
I wonder if it also doesn’t even work when there are circular communication loops?

Just as a thought experiment (I prefer your solution): I was wondering if this problem could also be solved by using a real NBA somewhere in the communication?

5

In reply to dave_59:

Dave,

A tlm fifo as described on that page would be ideal. But it seems to be a pretty old issue. Any idea if there is a chance this will ever happen?

Another issue with the uvm tlm fifo is that it can currently not be intantiated in eg the run phase (even if I would not need port/export). As sequences are dynamic it would be nice that if we were to use tlm fifo’s to communicate between them that these can also be instantiated dynamically.

By the way, is there any way users of SV and UVM can influence the development and standardisation efforts?

6

In reply to NiLu:

A problem with this change is that it would not likely be backward compatible. But the bigger problem is the fact that, like most projects developed by committee, there is little incentive to fix exiting problems when adding new features is so much more interesting.

Short of joining the committees directly which involves financial and personal commitments, the best way to influence the committee is through one of your vendors on the committee.

7

In reply to dave_59:

In reply to NiLu:
This might be 404

I wanted to reread this link, but it seems to be broken. Any idea where it moved to?

8

In reply to NiLu:

I have updated the link