use sc_events for Slave to Master communication

In order to implement the consistency in the master requirement, At least in one direction, an event is required to guarantee (using the kernel) that a method will complete before responses are received from a slave.

An sc_event is used between each pair of Initiator/Target ports/exports.

TWO port/export pairs are required between any two IP blocks. One pair for communication in the Master to Slave direction. One pair for communication in the reverse direction.

Strictly, only one element in the chain between Slave and Master need use an event, however, this makes the interface somewhat more confusing. Alternatively the convenience layer could be left to guarantee this behaviour. However, the requirement to delay the transaction as it passes back from Slave to Master is sufficiently common, and the interface sufficiently simple that it is felt reasonable to stick with events.

In order to provide a reflective timed interface, events with payloads are required. This is a general utility built on top of sc_event_queue.

It's function is simply to delay the emission of a transaction to the target port for a period of time.

Any notion that the target port is unable, or unwilling to accept the transaction at the time specified is left to the protocol layer to negotiate.

Hence, if a "bus fabric" is not pipelined, and can only handle one transaction at a time, and is currently occupied, then it is expected that on receipt of an event indicating the transmission of a new transaction, the "bus fabric" will itself generate an event back to the master indicating that the transaction has been rejected.

Al alternative (and more efficient) scheme would have the master wait for the event indicating the end of the previous transaction before generating the next one.

These scenarios, and other possibilities, are left to the designer of the protocol layer

use of sc_event_queue

An sc_event_queue must be used, not "just" an sc_event because a target may which to schedule several events back to the master... (request acknowledge, and data elements for instance)