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

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



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