[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] Re: [bender] WISHBONE submission / synchronous reset operation




Hi Wade,

I tried to open the new revb.2 document, but it seems broken somehow.

Richard


> Hello Richard:
>
> Many thanks for the suggestions.  I've changed the WISHBONE reset section
> (section 3.1.1) by adding a new timing diagram and employed better
language in
> the text (using most of your suggestions).  These have been added to the
draft
> copy at: http://www.silicore.net/wishbone.htm#anchor426873
>
> Many thanks for the work you've put into this!
>
> Wade D. Peterson
> Silicore Corporation
> 6310 Butterworth Lane
> Corcoran, MN  USA  55340
> TEL: (763) 478-3567, FAX: (763) 478-3568
> URL: www.silicore.net  E-MAIL: wadep@silicore.net
>
>
> ----- Original Message -----
> From: Richard Herveille <Richard.Herveille@pie.nl>
> To: Wade D. Peterson <wadep@silicore.net>
> Sent: Tuesday, February 06, 2001 8:53 AM
> Subject: Re: [bender] WISHBONE submission / synchronous reset operation
>
>
> > Hi Wade,
> >
> > Some comments/suggestions
> >
> > > Hello Richard:
> > >
> > > I broke your email apart again to handle another issue that you
brought up
> > > seperately (see my snippit of your email below).
> > >
> > > The reset signal is not asynchronous (all WISHBONE signals are
synchronous
> > > as per RULE 4.10).
> > >
> > > This was bothering another person, so I think we ought to crispen up
the
> > > definition of the reset cycle.  For one thing, we could add a timing
> > diagram
> > > like the one attached to this email. Could you look at it and give me
your
> > > opinion?
> > >
> > > Here are some other changes that might be helpful as well:
> > >
> > > RULE 3.10 (CHANGE WORDING)
> > > MASTER and SLAVE interfaces MUST initialize themselves beginning at
the
> > rising
> > > [CLK_I] edge following the assertion of [RST_I].
> > >
> > RULE 3.10
> > MASTER and SLAVE interfaces MUST initialize themselves at the rising
> > [CLK_I] edge following the assertion of [RST_I] and must stay in this
> > pre-defined at least until the next rising [CLK_I] edge following the
> > negation of [RST_I].
> >
> >
> > > PERMISSION 3.05 (NEW, after RULE 3.20)
> > > [RST_I] MAY be asserted for more than one clock cycle, and MAY be
asserted
> > > indefinitely.
> > >
> > > RULE 3.40 (CHANGE WORDING)
> > > Self-starting state machines and counters on MASTER and SLAVE
interfaces
> > MUST
> > > initialize themselves to a pre-defined state beginning at the rising
> > [CLK_I]
> > > edge following the assertion of [RST_I].
> > >
> > RULE 3.40
> > Self-starting state machines and counters on MASTER and SLAVE interfaces
> > MUST
> > initialize themselves to a pre-defined state at the rising [CLK_I] edge
> > following the assertion of [RST_I] and must stay in this pre-defined
state
> > at least until the next rising [CLK_I] edge following the negation of
> > [RST_I].
> >
> >
> > > RULE 3.10 (CHANGE WORDING)
> > > The following MASTER signals MUST be negated beginning at the rising
> > [CLK_I]
> > > edge following the assertion of [RST_I]: [STB_O], [CYC_O].  The state
of
> > all
> > > other MASTER signals are undefined in response to a reset cycle.
> > >
> > RULE 3.50
> > The following MASTER signals MUST be negated at the rising [CLK_I]
> > edge following the assertion of [RST_I] and must be kept negated at
least
> > until the next rising [CLK_I] edge following the negation of [RST_I]:
> > [STB_O] and [CYC_O].  The state of all other MASTER signals are
undefined in
> > response to a reset cycle.
> >
> >
> > > OBSERVATION 3.15 (NEW, after RULE 3.50)
> > > On MASTER interfaces, [STB_O] and [CYC_O] may be asserted beginning at
the
> > > rising [CLK_I] edge following the negation of [RST_I].
> > >
> > > Wade D. Peterson
> > > Silicore Corporation
> > > 6310 Butterworth Lane
> > > Corcoran, MN  USA  55340
> > > TEL: (763) 478-3567, FAX: (763) 478-3568
> > > URL: www.silicore.net  E-MAIL: wadep@silicore.net
> > >
> > >
> > > > Why not make an (another) exception for the [RST_I] signal and
define it
> > as
> > > > [nRST_I] or [RSTn_I] ? It is already an exception to all other
signals
> > in
> > > > that it is the only asynchronous signal directly supported by
WISHBONE.
> > Also
> > > > by predefining the mnemonic there should be no babylonic speach
> > mistakes,
> > > > also this mnemonic is supported by every tool I know of (although
some
> > may
> > > > convert it to [NRST_I] or [RSTN_I] resp.).
> > >
> > >
> > >
> > >