Re: IM05: Clock control clarifications

ITC Team,

I've re-transmitting this message without the diagrams.

Brian already re-transmitted part of it but without the
embedded responses to Per on the clock control semantics.

Please combine this e-mail with the diagrams Brian sent
individually.

Sorry for the confusion.

-- johnS

ITC Team,

I've attached two new diagrams for the IM05 clock forms.
In the first diagram (revised_clock_control_1.jpg) it is
simply what I had before but with added reference lines so
it is easier to see where clocks align around the
'ready_for_clk*' signal transitions.

In the second diagram (revised_clock_control_2.jpg), I've
implemented Per's request of showing assertions of
'clk*enabled' signals on posedges of uclock rather than
negedges to avoid possibly misleading implementors. As it
turns out, either is acceptable and compliant.

The important thing is that a 'clk*enabled' signal
can be sampled properly on the relevant posedge of a uclock.

I elaborate on this a bit more in specific responses
to Per's e-mail below.

Please let me know which of the two you would prefer
for the specification.

Brian please let me know if the reflector does not take this.
I'll send you .fm versions privately.

-- johnS

Per,

Sorry I had skipped a response to your earlier e-mail
about this.

I realized after reading it that my original response
did not address your question.

I've embedded responses.

Bojsen, Per wrote:

> Hi John,
>
> I sent the email quoted below a few weeks ago (10/13) and was
> wondering if you have had time to think about these questions.
> I'm particularly interested in understanding the difference
> between the so-called emergency brake mechanism and the mechanism
> I proposed where there is effectively only one global clock
> control signal and clocks are stopped on the next rising edge at
> which this signal is seen deasserted. I am envisioning that
> all the ReadyForCclock signals are and'ed together by the
> infrastructure to create this global clock control signal. The
> ReadyForCclockNegEdge signals could be and'ed in too for backwards
> compatibility with existing testbenches, but otherwise this
> signal would become deprecated.

johnS:
One of the things I outlined below is that I think we want to
keep ReadyForCclockNegEdge for the benefit of the fastest clock.
Also, if we ever want to restore a "just in time" clock control
mode (as alternative to "emergency brake") it will
be good to have these signals still there. (See more discussion
below.)

>
> I think these two mechanism are identical in the majority of
> cases. I am wondering what the merits of the slightly more
> complicated emergency brake mechanism is over the above.

johnS:
I have to agree that in the majority of cases, it is customary
to tie ReadyForCclockNegEdge high on all clock control macro
instances. But I've seen isolated cases where negedge control is
needed.

>
> Thanks,
> Per
>
> > 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.

johnS:
Actually I don't have a problem with changing this in the diagram.
The point of the diagram is to show that when this signal is sampled
it will always be done so on a posedge of uclock. Whether it was
asserted by the infrastructure on uclock earlier or 1/2 uclock
earlier will not matter from the application transactor's P.O.V
as long as it can be sampled on the uclock posedge itself.

However, that said, I've attached a modification of the diagram
that shows the changes you're referring to.

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

johnS:
Your agruments are good. However, I still have concerns about
taking away the ability to sequence control in individual edges
of clocks. Also, if we decide to re-instate a "just-in-time"
clock control mode, we may wish to still have these signals
here to support that.

I've seen some recent cases where "emergency brake" semantics leads
to less efficient implementation of transactors than "just in time"
would have improved upon.

Right now in our product we're supporting both modes controlled
via a run-time switch. In fact, as it stands today, our default
is "just-in-time" though many of our uses select "emergency brake"
model.

> >
> > > 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?
> >

johnS:
That's correct. It is completely up to the implementation as ti
where in falls in this interval.

<eom>

> > > 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
>

-- 
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
________________________________________________________________