"nb_transact" method call for timed communication

The choices for the timed interface are wider. We have already chosen to use Port to Port binding, and not to expect a channel. Further the interface must be non-blocking

The design decision rests around whether there is sufficient use for a master "delaying" a transaction before it proceeds towards a bus fabric.

Also, whether people want to have reactive slaves, or method/thread based slaves.

The situation would be that a master model would know, ahead of time, that it will certainly be emitting a transaction, but that it will not do so for a known (and certain) period of time.

In order to simulate this, a different language constructs is required that does not exist in SystemC today. sc_event(queue) with payload:: With this construct, the master could send an event to the slave, that the master could arbitrarily delay in the normal way that events work. The event would carry the transaction payload.

However, because (a) this construct does not exist today, and (b) we consider the case of a master "posting" transactions in this way to be rare, we choose to simply implement a "normal" method in the target port.

This means that if a master does wish to delay a transaction, it has to arrange to do so itself by delaying the call to the non blocking method. (this could be built into the convenience layer)

It also means it is possible to write a (timed) slave with NO method/thread (simply responding to the transact request and "posting" timed events for the return).

Call Signature

The method call operates over a transaction AND a timing. As has been seen, these two objects have different Life spans, therefore they should not be combined.

Again, the use of C++ templates creates a fast low-level connection and allows the convenience layer to add safety.

The transaction is passed to the method call as a projects/GreenBus/docs/Design/passByReference Reference.

The method may NOT call wait.

This method is only applicable from Initiator to Target during the Master to Slave communication path. In the other direction some other mechanism is employed for projects/GreenBus/docs/Design/sameDeltaDifferentThread consistency in the master.

---

Other implementations

If SystemC was enhanced with an event that carries a payload, this would be an acceptable implementation. However, such a mechanism would have to be very efficient as there is no requirement on the slave not to see the masters request until the master finishes writing all requests (As there is in the reverse direction projects/GreenBus/docs/Design/sameDeltaDifferentThread as noted elsewhere. Hence, using such a payload carrying event would simply make the interface reflexive, which is elegant, but fulfils no other engineering requirement.