Re: IM05: Clock control clarifications

Per,

Bojsen, Per wrote:
> Hi,
>
> I know I'm supposed to be on vacation, but I saw the diagram
> and noticed a few things that I'd like to comment on before
> the issue is closed.
>
>
>>However, we can add the following diagram and text as an example of
>>clock control.
>
>
> The figure is good and shows some interesting cases. The
> *_enabled signals are showed with their falling edges coinciding
> with the falling edge of uclock, i.e., as if they require a
> clock with 2X the uclock frequency to be generated if they are
> generated synchronously. While I don't think this is in conflict
> with the spec I think it is misleading. They ought to be drawn
> as signals that are synchronous with uclock and generated by the
> rising edge of the uclock.

johnS:
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.

>
> The example showing clock control of clkfast_negedge is
> interesting as it shows that negedge clock control has not
> become redundant. This was one of the areas where the original

johnS:
Yes, this is what I was trying to explain in the meeting
last Thursday and asked the team to have a look at this
proposal before discussing further.

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

> new wording was ambiguous. The example shows that a rising
> edge of clkfast_negedge is allowed to occur before the clock
> stops. Since clkfast_negedge is the frequency of uclock this
> doesn't quite resolve the ambiguities, though. Here is the
> question: If clkfast_negedge had been a 4/1 clock for instance,
> and the next falling edge of this clock occurs several uclock
> periods later from the point when the ReadyForCclockNegEdge
> signal for this clock is asserted, then I'm assuming all clocks
> are allowed to run during this period. Specifically, an
> active edge of any clock that occurs during this period will
> be allowed to occur. Is this a correct interpretation

johnS:
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.

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.

If the clock were any slower, its edges would always be
scheduled on uclock posedges and therefore disabled upon
deassertion of any readyForClock (or readyForCclockNegEdge).

Hope this makes sense. It is, admittedly, a bit tricky.

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.

>
> Thanks,
> Per Bojsen
> Zaiq Technologies
>

-- johnS

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient. Any review, reliance or distribution by others or
forwarding without express permission /\
is strictly prohibited. If you are /\ | \
not the intended recipient please | \ / |
contact the sender and delete / \ \
all copies. /\_/ K2 \_ \_
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Mon Sep 13 16:53:24 2004