[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[oc] Re: [bender] WISHBONE submission / synchronous reset operation
- To: <cores@opencores.org>
- Subject: [oc] Re: [bender] WISHBONE submission / synchronous reset operation
- From: "Wade D. Peterson" <wadep@silicore.net>
- Date: Tue, 6 Feb 2001 12:44:45 -0600
- Organization: Silicore Corporation
- References: <000401c08c58$a85c3600$e53ac089@hmf8h> <200102020615.HAA22860@gatekeeper.pie.nl> <000e01c08d30$75d1bc40$5d3bc089@hmf8h> <200102050803.JAA06227@gatekeeper.pie.nl> <000a01c09040$cc010720$153bc089@hmf8h> <200102061450.PAA17478@gatekeeper.pie.nl>
- Reply-To: cores@opencores.org
- Sender: owner-cores@opencores.org
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.).
> >
> >
> >
> >