Re: [oc] Wishbus Bus

["Wade D. Peterson" <wadep@silicore.net>]

Hello Winefred:

Non-existent addresses are handled by WISHBONE in a way that is similar to many
standard microcomputer buses.  That is, the MASTER that generates a bus cycle
receives an error signal that forces it to terminate the bus cycle.  The error
signal can be sourced by a participating SLAVE module, or from the bus
interconnection logic.

The actual method by which the [ERR_I] signal is generated is user defined.
However, it is commonly done in one of two ways:

1) A bus timer (i.e. a watchdog) monitors the common strobe [STB_O]
interconnection.  If the bus cycle takes too long (say, 16 microseconds), then
the error signal is asserted at the current MASTER.  The length of time is
defined by the system integrator.

2) An address decoder is designed so that all unused addresses force the
assertion of the error signal [ERR_I].  For example, if the top half of memory
isn't used, then all bus cycles to that area will generate an error.

What actually happens in response to this error is not defined by WISHBONE.
It's defined by the IP core at the MASTER end.  For example, in high-end
microprocessors the error signal will often generate a trap or fault condition
that allows some level of recovery.  However, low-end microprocessors might not
have any support for this at all, and will ignore the error signal.  In these
cases the system integrator may wish to do something else, like reset the whole
system.

Another thing to remember - IP cores designed to WISHBONE don't have to be used
only in a traditional Von Neumann architecture.  They can also be used as
endpoints in crossbar switch and data flow (e.g. FIFO coupled) architectures.
In those cases, both the failure mode(s) and the error handling mechanism is
going to be different.

As for time limits on transactions - they should never be standardized.  That's
because the system integrator is the best person to determine how long and when
an error should be generated.  For example, if a transaction is occuring between
a CPU and memory, then the time limit should be quite short.  However, if the
transaction is occuring across a bridge then it might take fairly long.

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: Winefred Washington <wwashington@austin.rr.com>
To: <cores@opencores.org>
Sent: Monday, January 01, 2001 10:51 AM
Subject: Re: [oc] Wishbus Bus


> Hi Wade,
>
> Thanks for the reply regarding dynamic bus sizing. I'm currently working on
> a set of behaviorals for WISHBONE and didn't know how to handle the dynamic
> bus sizing issues. Could please respond to a couple earlier questions I
> have:
>
> 1. How should transactions which target non-exist addresses be trapped and
> handled?
> 2. Should we support time limits on transactions?
>
> Thanks,
> WW
>
> ----- Original Message -----
> From: "Wade D. Peterson" <wadep@silicore.net>
> To: <cores@opencores.org>
> Sent: Monday, January 01, 2001 9:11 AM
> Subject: Re: [oc] Wishbus Bus
>
>
> > Hello Winefred:
> >
> > Please correct me if I'm wrong, but I think the question that you're
> asking is:
> > how do I make WISHBONE slaves indicate (back to the MASTER) the data
> operand
> > size that they're transferring?
> >
> > As I'll describe below, you can design a WISHBONE interconnection system
> that
> > does this.  Quite frankly, most of my own bus bridge work has been done
> between
> > VMEbus and WISHBONE, and I haven't spent much time on this particular
> problem.
> > However, I after thinking about it I can offer the following suggestions:
> >
> > 1) Make sure that you actually need your slaves to acknowledge their
> transfer
> > size.  For example, in the VMEbus bridges this is not a problem because
> each
> > master is aware of each slave's interface size.  The MASTER does this by
> > dividing its addressing range into chunks where the slaves in those chunks
> have
> > 8, 16, 32 or 64 bit data paths.  For example, if the MASTER is
> transferring at a
> > high address, then would assume a 64-bit transfer.  If it's at a low
> address,
> > then it could be 16-bits or something like that.  This technique has been
> done
> > for years, and works very well.
> >
> > 2) This same thing could be done by the system integrator.  In this case,
> the
> > WISHBONE interconnection (which is defined by the system integrator) would
> > contain an address decoder that informs the bridge of the size of each
> slave.
> > This makes the IP core design easier, but increases the work load for the
> system
> > integrator.
> >
> > 3) Your idea about standardizing on common slave sizes (e.g. 32-bits) will
> solve
> > this problem and make system integration easier, as there are less
> variables to
> > deal with.  However, there are so many different types of cores and
> applications
> > that no matter what you choose, I think you'll regret it in the future.
> >
> > 4) If you really do want your slaves to acknowledge with a transfer size,
> then
> > you could do one of two things:
> >
> >   (a) The system integrator can create some logic that works in conjuction
> with
> > a standard WISHBONE IP core.  Under this scenario, the system integrator
> adds
> > some glue logic (to their interconnection) that generates some data size
> > signals.  This can be done outside of the IP core interface, and is very
> easy
> > for the system integrator to do.  Information from the WISHBONE DATASHEET
> will
> > help in this regard too.  These added signals then carry the size
> information
> > wherever it is needed.
> >
> >   (b) If your SLAVE needs to dynamically change the width of it's
> interface
> > (i.e. on-the-fly), then you can define the IP core with one or more
> [TAG_O]
> > signals that indicate the width of the transfer.  These are combined with
> > special instructions for the system integrator.
> >
> >
> > 5) The final answer may be that we add some signals to the slave to make
> your
> > life easier in this application.  If you can think of some strategy for
> doing
> > this (within the context of the current WISHBONE philosophy), then we
> could add
> > them in a future revision.  I've learned a lot about VMEbus bridges in my
> own
> > research.  That, together with what you have learned about PCI bridges,
> might
> > lead to a better standard.  I would be willing to commit some time to work
> with
> > you on this concept if you're interested.
> >
> > Best regards,
> >
> > 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
> >
> >
> > > > on 12/31/00 11:14, Winefred Washington at wwashington@austin.rr.com
> wrote:
> > > > > We may need to make an additional requirement to the Wishbone spec
> or
> > > > > perhaps Silicore is already working on it.
> > > > >
> > > > > I was working on a simple testbench and here's the problem I think I
> > > found.
> > > > > A master device has to know what the bus width of the slave device
> is
> > > for
> > > > > the transfer to work correctly. Suppose we have a 32-bit PCI to
> Wishbone
> > > > > device and it has to transfer data to 32-bit  and an 8-bit devices.
> The
> > > PCI
> > > > > core has to change how the data is presented on the bus to match the
> > > data
> > > > > width of the slave devices. That means the PCI core has to contain
> logic
> > > > > specific to the application which hurts reuse.
> > > > >
> > > > > One solution is to fix the data widths to 32-bits for all cores.
> > > > >
> > > > > Any comments?
> > > > >
> > > > > Did I miss something in the spec?
> > > > >
> > > > > WW
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >