RE: IM05: Duty Cycle and Skew questions

I have a question regarding duty cycle and phase shift arguments
to the SceMiClockPort macro - specifically, their effect with
regard to uclock frequency. The concern I have is over the
possibility that a (poorly) chosen duty cycle and/or phase shift
can create the need for a very high frequency uclock, relative
to the 1/1 clock frequency.

For example:

SceMiClockPort #(4, 1, 50, 50, 33) four_one (clk_4_1, reset_4_1);

This would define a 4/1 clock, with 50% duty cycle and 33% shift.
In order for each edge of this clock to occur coincident with an
edge of the uclock, and for the 1/1 clock to do so, the uclock
would need to run at a frequency 25x (I think) that of the 1/1
clock. (Again, in order to faithfully align a uclock edge with
the phase-shifted cclock.)

Some questions:

1) Is my assumption here correct? That is, as specified today in
SCE-MI 1.0, the ability to specify arbitrary duty cycle / phase
shift combinations can imply a high uclock frequency (relative to
the 1/1 cclock frequency)?

2) If so, are there explicit restrictions on the uclock duty
cycle? For example, could an implementation generate a uclock
for which the duty cycle and/or frequency varied during the
course of a SCE-MI run - so long as all other clock/edge require-
ments are met?

3) In the above example, from the user's perspective, the only
visibility into the temporal location of 'four_one' clock's
edges is through the time stamps associated with messages
transferred on edges of 'four_one' clock. These time stamps
will not contain the 'actual' time of 'four_one' clock's edges,
since these time stamps are based on 1/1 clock edges, which are
skewed from 'four_one' clock's edges. As such, if a SCE-MI
implementation faithfully reproduces the relative *order* of
any clock's edges with respect to all other clocks, and faith-
fully achieves the correct time stamp information for messages
transferred, is that sufficient to meet the requirements of
the standard?

Perhaps some of this has been questioned and/or clarified in
discussion surrounding IM05, but I'd appreciate direct feedback
to my questions above.

Thanks,

Matt

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf
>Of Bojsen, Per
>Sent: Sunday, September 12, 2004 2:41 AM
>To: 'Brian Bailey '
>Cc: 'itc@eda.org'
>Subject: RE: IM05: Clock control clarifications
>
>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 Mon Oct 11 12:32:54 2004