The right level of Determinism

It is important to be able to model non-deterministic systems. At the limit, clocks on a SoC vary in speed and their "edge" varies across the die. It is then possible that the results of transactions could occur before they are expected.

So, for instance, it is quite possible that a Timed model should be able to represent the return of a transaction response phase in the same delta that the request was sent.

This means that no "deltas" should be placed in the path by the interoperability layer.

However some level of determinism is required in order to be able to construct a system that is deterministic (i.e. to implement a protocol around a communication path that ensures the system works correctly irrespective of the clocks and timing delays).

There is a choice about how this can be achieved,

Imagine the following pseudo code for a master :

The (very silly) "receive" function is called, somehow, by the slave. The question is how.

The three nb_transact are all non-blocking. The model writer could rely on them completing straight away, with no other activity.

If the model writer can not rely on that, then they must use sc_signals, which will guarantee that x,y and z keep their value during the current delta cycle.

Since sc_signals suffer a per use cost, it becomes quite expensive to use them in the main. They are very infrequently employed within the context of "TLM".

The conclusion is that the deterministic behaviour of a master issuing several transactions together, as a collection of non-blocking function calls, before any of them return values would seem to be desirable from a simulation speed perspective.

Hence : the receive function should be triggered by the slave using an event, which can be an immediate trigger, but this guarantees that the triggered method will not be called until the previous thread (in this case the master::send) has yielded...