RE: IM05: Clock control clarifications

Hi John,

I owe you a response to your email from 3 weeks ago about the clock
control figure.

> My intent here was to show controlled clocks with maximum possible
> frequencies with respect to uclock. This is why clkfast and
> clkfast_negedge use don't care duty cycle.
>
> In an optmimal implementation, because these are don't care
> duty, it is possible for their inactive edges to coincide
> with negedges of uclock which is what I show here.
>
> The 3rd clock, clkslow, naturally has edges scheduled
> on posedges of uclock.

I agree with all this. My comment was more directed at the fact
that the *_enabled signals are shown as pulses that are half a
uclock period wide which could easily confuse people looking at
this and make them think they need a (at least) 2X uclock clock
to generate these signals. Of course, in an efficient implementation
these are not really synchronous signals, but I still think it
make sense to show them as signals generated in the uclock domain.
This would make clkfast_enabled and clkfast_negedge_enabled show
as constant high except during the disabled periods while
clkslow_negedge_enabled would have pulses that are 1 uclock period
wide.

What do you think?

> This is indeed a case where negedge cclock control is not
> redundant and should probably be kept.

I think we ought to have a discussion as to what purpose keeping
this serves. The simplest clock control mechanism would be to
have one clock control signal that would stop all clocks
immediately on the first rising edge of uclock at which this
clock control signal is asserted. Given that we have already
decided to drop the sliding stop mechanism, why not go all out
to the simplest mechanism? This would have the greatest chance
of being implemented the same by everybody.

> No. In this case, the next edge that you "care"
> about (i.e. "non-don't care" edge which is always scheduled on
> a uclock posedge) of any clock will be disabled.
> That is what emergency brake semantics mean. When a ready
> for cclock is deasserted, the next scheduled edge that you
> "care" about is disabled.

OK, I think I'm finally getting it now. I'm assuming that the
implicit 1/1 cclock is also taken into consideration here? That
would be an important point that nails any amgiguity in the
behavior.

> The reason the next posedge of the clkfast_negedge is allowed
> to occur in this example is because that is a don't care
> edge that does not happen to be scheduled on a uclock posedge.

OK. I'm assuming that it is actually up to the implementation
whether it lets this don't care edge occur where you drew it or
at some later time up until the falling edge of uclock just after
ready_for_clkfast_negedge is asserted again. Do you agree?

> BTW, a corrolary to don't care duty cycle clock edge control
> is that the edge you don't care about is not controllable.
> I.e. readyForCclock clkfast_negedge essentially has no effect
> as does readyForcclockNegedge on clkfast.

If we had only one clock control signal we would not have to
describe this fine point.

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