RE: IM05: Clock control clarifications

Hi John,

> One of the things I outlined below is that I think we want to
> keep ReadyForCclockNegEdge for the benefit of the fastest clock.
> Also, if we ever want to restore a "just in time" clock control
> mode (as alternative to "emergency brake") it will
> be good to have these signals still there. (See more discussion
> below.)

Hmm, it doesn't make sense to me to keep something for the benefit
of a feature we have decided to deprecate in favor of a different
one just in case we decide to flip-flop on our decision :-) If
there is a chance we would want to restore `just in time' I would
think we should think about not getting rid of it in the first
place or, conversely, we should make sure that the new behavior
is really what we want so we don't need to go back later.

So the argument for keeping negedge clock control as distinct from
posedge clock control should be based on features that we decide
we cannot live without.

In thinking about my proposal of combining the two ready for
cclock signals into one versus the `emergency brake' proposal,
I'm coming to the conclusion that they have identical behavior
with respect to the clock waveforms in the case where the implicit
1/1 cclock has the same frequency as uclock. I'd like to find out
what if anything I'm overlooking.

Here is why I think they are identical. All cclock edges that
the user cares about fall on rising edges of uclock. At any given
time, when a ready for cclock signal (posedge or negedge) is
deasserted, the earliest time that the clocks will stop will be at
the next rising edge of uclock because that is the earliest time
any cclock edge the user cares about can occur. On the other hand,
the latest time the clocks will stop is also at the next rising
edge of uclock due to the implicit 1/1 cclock which has an edge
the user cares about at each rising edge of uclock. So in this
scenario, no matter which ready for cclock (posedge or negedge)
is deasserted by the application, the cclocks will always stop at
the same time, i.e., at the next rising edge of uclock. Similarly,
I believe the cclocks will always restart at the same time again
once the ready for cclock signal is asserted again.

Let me know if I am missing something here. But if the above is
true, then one will get the same behavior with my proposed scheme
where the ReadyForCclockNegEdge is deprecated although still
functional, but where it is simply and'ed with the ReadyForCclock
signal and this combined signal determine clock control. What I
am saying here certainly applies to the example you sent out.

Now, when the 1/1 cclock runs slower than uclock, there could be
a difference between my proposed scheme and yours in that in my
proposal clocks would still stop at the next rising edge of uclock
whereas in your scheme they may not if there are no `care' edges
on the next rising edge of uclock. Is this correct, by the way?
If this is correct, then we need to see if this difference is
important or not. Certainly, in terms of cycle stamp time there
is no difference.

While `just in time' is a bit more complicated to implement and
possibly a bit harder to comprehend, I do see the advantages of
this scheme over the `stop now' or `emergency brake' mechanism.
As I recall it, the only reason for introducing `emergency brake'
was the ambiguity in cycle stamps on output messages in certain
scenarios. If we could fix this, then I wouldn't mind retaining
the `just in time' mechanism.

Interestingly enough, one can get `emergency brake' semantics in
a `just in time' system by controlling a 1/1 cclock instead of
whatever clock the transactor uses. BTW, this was the motivation
for my proposal to reserve clock ID 0 for the implicit 1/1 cclock.

In summary, I think my immediate stop proposal is (almost) identical
to your `emergency brake' proposal except for the status of
ReadyForCclockNegEdge. Of course, I may be wrong on one or more
subtle points :-)

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