Forwarded message from Jason Rothfuss of Verisity

        Hi John,
        
        The reason for latching the TokenIn data is to prevent stale data on
the bus from being re-transmitted to the SceMiMessageOutPort. If data that
has already been sent to the SceMiMesageOutPort stays on the bus for some
time, the same data can be repeated (ie. log shows that DaffyDuck arrives in
Cupertino 20 times). The key here is that there was no logic to indicate
that the data has already moved, since transmitReady is only based on a
non-zero destID and cclockEnabled.
        
        Per the spec, transmitReady should indicate to the
SceMiMessageOutPort that it has valid data to be transmitted. Since there
is no handshaking with the sender of TokenIn, there is no way to "clear" the
TokenIn data. If receiveReady doesn't go low (implementation could provide
a buffer), transmitReady could falsely indicate that it has valid data
resulting in multiple transmissions of the same token.
        
        Regards,
        Jason
Received on Thu Nov 4 07:49:53 2004