Subject: Re: SCE-MI Clock Control: Request for Clarification
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Jan 27 2004 - 13:36:28 PST
Per,
Yet more responses to your e-mails ...
Bojsen, Per wrote:
> Hi,
>
> this was originally sent to Brian and Duaine and Brian asked me to
> forward it to the mailing list. Hopefully the list is up now.
>
> I would like to have my understanding of certain aspects of SCE-MI
> clock control confirmed. Please correct anything in the following
> that you find is wrong:
>
> 1) On p. 34 in the section describing parameters and IOs of the
> SceMiClockControl macro under the description of the
> ReadyForClock and ReadyForClockNegEdge it is stated that the
> corresponding edge of the controlled clock must coincide with
> a rising edge of uclock. It is also stated that for don't
> care duty cycle cclocks, the ReadyFor* signal corresponding to the
> edge the user does not care about is constant 0.
>
> So, it follows, that any cclock with non-don't care duty cycle,
> both its edges must coincide with a rising edge of uclock. This
> implies that the highest possible frequency of a 1/1 cclock with
> a non-don't care duty cycle (e.g., 50/50) is 1/2 the uclock
> frequency, right?
johnS:
This is correct. The intent of the don't care duty cycle was to
get around this performance limitation in cases where explicit
negedge control is not needed.
The reason we state that each edge of a non-don't care duty cycle
concides with a posedge uclock is that this makes implementation of
the infrastructure a little more straightforward if the infrastructure
is using the same clock as the uclock (rather than an internal one that
is yet 2x faster than the uclock).
What we've seen in general is that posedge control of don't care duty
cycle clocks is generally adequate for all needs (i.e. the need for
negedge control is rare) and you can do it with no performance hit
in uclock:cclock ratios.
>
> However, if the duty cycle is don't care, then the frequency can
> be the same as the uclock frequency in the best case? This is
> stated as a goal (but not a requirement) on p. 28 in the last line
> of the 4th paragraph from the bottom.
johnS:
Yes.
>
> 2) The actual frequency of the 1/1 cclock relative to uclock is
> implementation defined, right?
johnS:
Yes this is correct.
> As long as the SCE-MI requirements
> are fulfilled, of course. The SCE-MI requirements define a
> maximum possible frequency but an implementation may choose a
> lower frequency if it wants to, right?
johnS:
Yes, the requirements are that the fastest cclock frequency cannot
exceed uclock frequency but we do allow it to be slower.
>
> 3) In Figure 13 on p. 32, the 1/1 cclock frequency is 1/2 the uclock
> frequency. The 1/1 cclock is not shown. It would be nice to
> show it in the figure as well, especially since it contrasts the
> goal on p. 28. A note explaining why the 1/1 cclock in this
> example must be slowed down would also be nice (and there is
> actually room on the page to do so :-) Here is a proposal for
> the text of such a note:
>
> NOTE--The 1/1 cclock in Figure 13 has a frequency that is 1/2
> the frequency of uclock. This is a consequence of the duty
> cycle and phase requirements of cclocks cclock2 through cclock5
> and the SCE-MI requirement that both edges of a cclock with
> a non-don't care duty cycle must coincide with some rising
> edge of uclock.
johnS:
This seems reasonable.
>
> 4) On p. 34, the second paragraph under ReadyForCclockNegEdge tries
> to motivate the need for the capability to disable negative
> edges. However I am unable to decipher what the first sentence
> of this paragraph is saying :-) How is it that transactor logic
> that only cares about controlling posedge clocks could or could
> not inadvertently disable the next negedge of any clock when it
> only intends to disable the next posedge of a clock? And how
> does this motivate the need for explicit negedge control?
>
johnS:
You're right, this is confusing !!
First, I think the "could not" should have been "could". That's a
typeo.
So, the intent of the wording is to convey that if you only
allowed one master clock control signal that affected both edges,
you can inadvertently (prematurely) disable the negedge by pulling
the ReadyForCclock low prior to it, when your intent was only to
disable the next posedge. And this could have undesired consequences
for example if the very condition you're waiting for to reenable the
posedge is triggered by the negdege you've just disabled !
So, to make a long story short, the API needs to allow explicit
control of each edge but in most cases users will probably only
need to tie the negedge control high. This will have the effect of
allowing the negedge to occur always and not stopping the clock
until the next posedge. Which is the typical intent of a
transactor.
> Why not simply state that negedge control is provided for
> transactors that use the negedge as the active edge of some
> clock (or both edges)? I am wondering if I am missing something
> here.
johnS:
No, you're not missing anything. Basically we just need to say that
the API only needs negedge controls to support transactors have this
explicit need which is what you've stated. I suggest we strike the
existing wording entirely and replace it with something along the lines
of what you've said here.
>
> 5) Also on p. 34, it is stated that ReadyForCclock disables the
> positive edge of the cclock being controlled, but not only that,
> it also disables the *posedge* of all other cclocks "just in time".
> So far so good. But why only the *posedges* of the other cclocks?
> Will it not stop all cclocks right before the edge of the cclock
> being controlled would have occurred?
johnS:
Yes, this is more correct wording.
> Won't that disable the
> negedge of any cclock whose next edge is a negedge?
johnS:
Yes it will.
> Perhaps
> my confusion is due to equating `disabling of edges' with stopping
> the cclocks?
johnS:
You're not confused. The wording should be adjusted here.
>
> 6) This is the same as 5 but for ReadyForCclockNegEdge.
johnS:
Yes.
>
> 7) This is a subtle issue. If ReadyForClock is deasserted after
> CclockEnabled is asserted, e.g., through a combinatorial mechanism,
> then will the cclock have the next rising edge disabled (forcing
> CclockEnabled to deassert again since the edge is now to be
> disabled) or will the cclock have the rising edge *following* the
> next rising edge disabled?
johnS:
CclockedEnabled is, by definition, combinatorially related to the
ReadyForCclock's. Therefore, combinatorially deriving ReadyForCclock
from CclockEnabled is generally a bad idea and could result in
a combinatorial loop.
>
> I think that's it for now regarding clock control.
>
> Thanks,
> 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
>
-- johnS
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
This archive was generated by hypermail 2b28 : Tue Jan 27 2004 - 13:41:25 PST