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.
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
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, any
active edge of any clock that occurs during this period will
be allowed to occur. Is this a correct interpretation?
Thanks,
Per Bojsen
Zaiq Technologies
Received on Sat Sep 11 23:40:23 2004
This archive was generated by hypermail 2.1.8 : Sat Sep 11 2004 - 23:40:32 PDT