Subject: Re: When to Cycle Stamp?
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Feb 27 2004 - 13:45:59 PST
Per,
Bojsen, Per wrote:
> Hi John,
>
> > 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
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
This archive was generated by hypermail 2b28 : Fri Feb 27 2004 - 13:50:49 PST