I have some questions regarding the dual-ready protocol:

1) Is the transmitter required to keep TransmitReady asserted
   once it has asserted it until ReceiveReady is seen asserted
   or is it allowed to deassert TransmitReady even if
   ReceiveReady is not seen asserted.  Of course, no message
   is transferred in this case.

2) Similarly, is the receiver required to keep ReceiveReady
   asserted once it has asserted until TrasnmitReady is seen
   asserted or is it allowed to deassert ReceiveReady even if
   TransmitReady is not seen asserted.  Again, I am not
   expecting messages to be transferred in this case.

3) On an input port, when TransmitReady is asserted, the message
   vector is stable and carries valid data, i.e., the
   transactor/BFM can sample it and use it even if it does not
   assert ReceiveReady.  Correct?  Once the transactor asserts
   ReceiveReady, the transactor must assume the message will
   change on the next rising edge of uclock.

4) On an output port, when TransmitReady is asserted, the
   transactor is required to drive the message vector with
   what it wants to send.  This is intentionally vague, because
   the transactor may want its message to be a sampling of
   some internal state that can potentially vary every clock
   cycle.  But, regardless of this wrinkle, the implementation
   is allowed to assume the transactor is holding the message
   data and is not required to sample the message data on the
   rising edge of TransmitReady.  Correct?

Re 1 and 2 above, these have some bearing on the message ordering
discussion.  For instance, if a transactor is allowed to cancel
a TransmitReady on an output port, the port should lose its place
in the queue of ports pending to be serviced.  If ordering is
strict, this is harder to implement than if ordering is loose.

=====================================================================

The dual ready protocol of the standard is borrowed from PCI and other similar systems.   Here are some clarifications.   All of these boil down to the idea that once an entity indicates that it is ready, it cannot "change its mind" or abort the cycle.   It must hold itself ready until the data moves.

 

Point #1:           The transmitter cannot "change its mind" or abort the cycle.

Point #2:           The receiver cannot "change its mind" about its readiness or
			abort the cycle.

Point #3:           Yes, this is a correct understanding.   When transmit ready
			is active, the data is good.

Point #4:           The sender must hold the message CONSTANT otherwise there
			could be a race between the data change and the receive ready.


Duaine

========================================================================

Thanks for the clarifications.  I propose to include these under
the description of the dual ready protocol in Section 5.1.1.  If
something is not explicitly forbidden people may assume it is
allowed . . .

> Point #4: The sender must hold the message CONSTANT otherwise
> there could be a race between the data change and the receive ready.

Are you saying the standard prohibits snooping internal state
with an output port without latching it in a holding register
first?  I agree with what you state if a specific message is
being sent, but if the user is snooping internal state and does
not care exactly when the sample is taken, then I don't see
a problem.  What do you think?

Per