Doing Nothing Efficiently and Reliably
This discussion and proposal is motivated by a couple of concerns:

Repeatability
I hope it is self evident that it is quite important for the infrastructure to provide for repeatable simulations.  That is, that parts of the simulation/emulation environment not directly part of the system under test should not affect the results of the simulation in any way.  More specifically, in this discussion, that requests from a BFM for the next transaction must be consistently satisfied from the end user’s application i.e. the test.  The BFM must never get “input message unavailable” due to communications, or other processing delays not specified by the test. 

Efficiency
The above repeatability concern leads to situations where the test might respond to input requests with “nothing to do this clock cycle” for extended periods of simulation time.  Such NOP’s by definition are very short (one clock cycle) transactions that can lead to excessive communications between the hardware side and the test.

There are three scenarios where this happens – 
·	The test knows exactly how long it needs to wait: an example of this might be a test injecting transactions at a specific rate, and therefore needing to specify “spaces” (i.e. idle for N cycles) between the transactions.
·	The test might be injecting transactions to multiple BFM’s at related rates, perhaps 1 transaction to BFM A for each two transactions to BFM B.  It might be possible for the test writer to calculate the spaces between BFM A transactions, but it would be easier if the system/ infrastructure could help in this.
·	The test needs to wait for some condition, presumably driven from outputs from other transactors under its control.  In this case, the test cannot know a priori how long it needs to continue to wait.  The test should have a limit (timeout) as to how long it is willing to wait before deciding an error or other extenuating condition has occurred.  An example of this would be a test waiting for a response from one BFM before injecting another transaction into another BFM.

Solutions
To ensure repeatability, the test, with only one exception described below, may only inject input messages in response to an input request (ready for input).  In fact, the test must respond to every such request for input, even if only with a message to do nothing for some amount of (simulated) time.  Note that this requirement implies that all BFM’s be implemented to respond appropriately to an input message of “nothing to do this cycle”.  This closed loop communication link ensures that the test and the simulation can maintain sychronization.

In order to avoid exchanges of request/response every cycle, I would propose a special test response: “Idle for N cycles”, where the cycle time represents the clock being used by the specific BFM being told to idle.  Both ends of this request should appear to be regular transactions.  This should be obvious on the applications end, since it is a fairly specific input message.  On the BFM end of the link, this should appear to be N single cycle idle messages.
 
However, in order to support the two indeterminate time scenarios above, there needs to be a mechanism to “wake up” an idling BFM before its full idle time has elapsed.  This would be the one exception to the above rule of injecting input messages in response to a request – a wakeup message would be a special transport layer message that would be used to reopen the communication loop to an otherwise idling BFM.  This would cause the idling BFM to again begin requesting input at the first possible clock edge.  Again, this is legal only when the associated BFM is idling.  If it is attempted while the BFM is processing a transaction the results are indeterminate.  This mechanism is not intended to allow the test to interrupt an in progress transaction.

Output messages should generally be unaffected by the above mechanisms.  The test must accept such messages as they arrive from the hardware, that is flow control or throttling in the output direction is not allowed.

As long as all messages, both input and output, occurring on a particular clock cycle are processed before the clock is allowed to continue repeatability should be guaranteed.