RE: When to Cycle Stamp?

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

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488