as I was thinking about the time-ordering issues we were
discussing at yesterday's meeting I realized that it is
not clear to me exactly when a message is cycle stamped.
I have been assuming that the cycle stamp is derived from
a (possibly implicit) 64-bit counter running off the
implicit 1/1 clock.  So is the value for the CycleStamp()
method of the SceMiMessageData object taken from this
counter

  a) at the time when TransmitReady is asserted on
     the output port,

  b) when the message moves (ReceiveReady and TransmitReady
     asserted), or

  c) some other time?

The spec does not say much about this.  My guess and
preference is a.  Note, this is an issue even when the
BFM stops the cclocks before asserting TransmitReady since
if it is using a very slow clock, due to just-in-time,
several/many 1/1 cclock periods could pass before the
cclocks actually stop.

Points well taken.

> 
>  > Our preference, and, I believe our current implementation
>  > is at the time of grant (i.e. data movement) rather than
>  > request.
> 
> This would mean that in certain cases the actual cycle
> stamp value on a specific message could vary between runs
> and between implementations.  For instance, if the transactor
> is controlling a very slow cclock, and it deasserts
> ReadyForCclock just before it asserts TransmitReady on its
> out port, then, due to the just-in-time principle many
> 1/1 cclock cycles could pass before the cclocks are actually
> stopped and hence, the cycle stamp value that the output
> message is stamped with could end up being any of a range
> of values from the value at the time TransmitReady is asserted
> to the value when the controlled clocks actually stop.
> 
> Am I missing something here?

johnS:
It seems that there should always be a static number
of fast cclocks preceding a given slow cclock edge (since
SCE-MI requires clock port ratios to be observed) that
will not vary from simulation to simulation so I don't
think there's an issue there.

However, there is a more sinister issue. An ill behaved
transactor, i.e. one that does not stop the clock upon
assertion of MsgOutputTransmitReady, can introduce
an element of non-determinsim. This is because it
will not be clear how many cclocks can elapse before
the infrastructure can finally take the transaction.

Only when this happens can you see varying cyclestamps
from run to run. But then, one can argue that if there
is non-determinsim in the system, you'd like the cyclestamps
to reflect that. In fact, we relied on this feature
heavily to debug non-deterministic applications. It
turned out to be quite easy to figure out where non-
determinsm first creeps into the simulation by logging
the cyclestamps from run to run. This turned out to
be useful to isolate which transactors were not "playing
by the rules".

This is another advantage of cyclestamping on data movement
rather than on MsgOutTransmitReady assertion.

However, unless I too am missing something, if the
transactor asserts proper clock control - fast cclock
or slow cclock, you should have consistent cyclestamps
from run to run.

BTW, I would have no objections to possibly revising
to the spec to say that clock control (specifically of
the 1:1 clock) is implicitly done by the infrastructure
upon assertions of any MsgOutputTransmitReady's. This would
have two benefits:

1. It circumvents the determinsim issue described above
     by making it impossible to have "ill-behaved" output
     transactors.

2. It circumvents a large part of the output priority
    issue that we discussed Thursday

The only downside is that it can result in more 1:1 cclock
stoppages where are clusters of simultanously occuring
MsgOutputTransmitReady's occur. But, one may argue that this
would be infrequent and therefore a small price for the
benefits gained above.

What do you think ?

> 
>  > This does make the implementation a bit easier
> 
> Yep, I can appreciate that :-)  I do agree that there is
> overhead associated with stamping at the time of TransmitReady
> being asserted.
> 
>  > What we do is opposite what you suggest below. But I think
>  > either is valid as long as different implementations are
>  > consistent.
> 
> I am worried that they are not consistent . . .

johnS:
Should we just be explicit in the spec to say the cyclestamp
reflects time of data movement ?

> 
>  > Since it does not matter, I would err on the side of ease
>  > of implementation. But I recognize that your implementation
>  > may be different than ours so you may have a different opinion !
> 
> My angle is to ensure that when the application is controlling
> the clocks sanely, the same exact cycle stamp values will be
> seen every time the test is run, whether on the same
> implementation or across implementations.
>
> If we keep the flexibility in how cycle stamping is implemented,
> one way for the transactor to ensure consistent cycle stamp
> values would be to always control the 1/1 cclock rather than
> whatever clock the transactor is actually using.  But, the
> implicit 1/1 cclock cannot be directly controlled, can it?  I
> don't recall seeing a definition that mandates the clock ID
> of the implicit 1/1 cclock.  If we added this, say ID 0, then
> the transactor can control the implicit cclock and be assured
> of consistent cycle stamp values.

johnS:
Actually I was not suggesting that we let the standard be
flexible on when cyclestamping is done. Rather I was being
flexible in agreeing which one the standard should require.
It should certainly require one or the other.

The more I think about it however, the more I think time
of data movement makes sense.

> 
> Per
> 

-- johnS

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

Hi John,

I have attached a PDF with some waveforms intended to show and example
where a BFM is controlling a slow cclock.  It is practicing good/sane
clock control and deasserting ReadyForCclock before trying to send
its output message.  In this example, it asserts ReceiveReady a few
uclock cycles after deasserting ReadyForCclock.  However, due to
just-in-time the slow cclock (and the other cclocks) are not actually
stopped yet.  Once ReceiveReady is asserted, TransmitReady is expected
to assert some time later.  I have tried to show with shading how it
might happen any number of uclock cycles later.  Depending on when it
happens, the cycle stamp counter will have different values.

Now, if cycle stamping is to be done when the message is *transferred*,
this example seems to indicate that the cycle stamp value for this
particular setup can vary from run to run and from SCE-MI implementation
to SCE-MI implementation.  

John, you said a couple of weeks ago:

> It seems that there should always be a static number
> of fast cclocks preceding a given slow cclock edge (since
> SCE-MI requires clock port ratios to be observed) that
> will not vary from simulation to simulation so I don't
> think there's an issue there.
> 
> However, there is a more sinister issue. An ill behaved
> transactor, i.e. one that does not stop the clock upon
> assertion of MsgOutputTransmitReady, can introduce
> an element of non-determinsim. This is because it
> will not be clear how many cclocks can elapse before
> the infrastructure can finally take the transaction.
> 
> Only when this happens can you see varying cyclestamps
> from run to run. But then, one can argue that if there
> is non-determinsim in the system, you'd like the cyclestamps
> to reflect that. In fact, we relied on this feature
> heavily to debug non-deterministic applications. It
> turned out to be quite easy to figure out where non-
> determinsm first creeps into the simulation by logging
> the cyclestamps from run to run. This turned out to
> be useful to isolate which transactors were not "playing
> by the rules".

This seems to contradict my example.  Is there something I'm missing
that makes my example invalid?

BTW, if my example is valid, a way for a transactor to work around this
behavior is to control a fast cclock rather than a slow one.  This is
the motivation for my proposal to define the clock ID 0 as the clock ID
of the implicit 1/1 cclock so that BFMs can control it.

Thanks,
Per

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

I think Duaine's proposal of "emergency brake" stoppage semantics
rather than "just-in-time" may make this whole issue moot.

Let's discuss in tomorrow's meeting.

-- johnS


Per - I agree