Subject: RE: When to Cycle Stamp?
From: Bojsen, Per (bojsen@zaiqtech.com)
Date: Fri Feb 27 2004 - 09:43:50 PST
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?
> 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 . . .
> 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.
Per
This archive was generated by hypermail 2b28 : Fri Feb 27 2004 - 09:48:07 PST