Uvm_tlm_fifo - (how) does it guarantee deterministic simulations?

I have been working a lot with the systemC tlm_fifo’s. They use the evaluate/update mechanism like the sc_signal, etc… to guarantee deterministic simulations.

I have just started on UVM, but I can’t find if the uvm_tlm_fifo’s use a similar mechanism? I have browsed through the src code, and my first impression is that they just do an immediate write/read to the underlying mailbox object.

Does the uvm_tlm_fifo have a similar mechanism as the systemC equivalents?

They do not currently. See 404

The sequencer put ant get ports have implemented the NBA update to handle this.

I assume this isn’t limited to the sequencer. Is it correct that all the uvm_*_port implement this?

Does also the analysis port guarantee determinism?

In reply to NiLu:

It is limited to the sequence ports. This goes back to the OVM. Instead of fixing the TLM ports, the people on the OVM committee just added a whole new set of put and get ports that were completely independent of the existing TLM ports.

Analysis ports do not have the same issue because they are just implementing write() function calls that can never block. It’s when the write is used together with a tlm fifo extended to make an analysis_fifo that you get the non-determinism.

In reply to dave_59:

I am confused. I think to understand:

If I were to add a uvm_*_port or analyis_port to any of my modules or classes, and connect a uvm tlm fifo to that port to communicate to another thread I am having a chance of non deterministic behavior?
The problem is only fixed for the (implicit) tlm fifo’s used in the sequence context?

Is that correct?

In reply to NiLu:

It really depends on what non-deterministic behaviors your are concerned about. And remember that deterministic behavior is a sub-set of non-deterministic behavior - just because it there is no guarantee, your chance of actually observing non-deterministic behavior it is still very low.

The only place I have ever observed non-deterministic behaviors is when there are three or more threads involved in a single TLM fifo connection; multiple put() threads, or multiple get()threads. The majority of the time, there is only one put() thread and one get() thread. And in the case of multiple threads, there are a number of specific conditions that need to occur before this becomes a problem.