Re: [oc] Wishbone historical perspective and a proposal to the OpenCores group

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

Jamil - see comments below.
Wade
----- Original Message -----
From: Jamil Khatib <jamilkhatib75@yahoo.com>
To: <cores@opencores.org>
Sent: Thursday, January 04, 2001 2:39 AM
Subject: Re: [oc] Wishbone historical perspective and a proposal to the
OpenCores group


> Hi,
> I have a question about interfacing cores via WISHBONE
> bus.
> 1. how can I connect systems having different clocks,
> shull I assume always the same clock and implement
> FIFO buffers inside each core or is it the
> responsibility of the system integrator?

WISHBONE works like a traditional, synchronous microcomputer bus in this regard
(e.g. Multibus II or PCI).  The bus interface on all the modules must work off
the same clock.  That way all of the modules communicate synchronously.  This is
one place where asynchronous buses (e.g. VMEbus) do better, as you don't need a
common clock to coordinate transfers.  However, asynchronous logic is much more
difficult to use on SoC, for a variety of reasons such as: (a) they are harder
to test, (b) harder to scale speeds up and down and (c) they tend to have a lot
of glitches on the interface caused by metastiblity and race conditions.

That means that your bus interface is pretty much tied to the common clock
frequency (whatever that is).  If the guts of your core need a different
frequency, then you do need to solve the problem of moving synchronous data
between two clock frequencies.  A FIFO is a great way to do that, but there are
other ways if you want to get creative.


> 2. How can I connect some status signals to the other
> core where these signals are core specific signals and
> has no relation to bus transactions (crc reporting, or
> lost cell indication) such signals can be made
> available to the external interface via core internal
> status registers but if I am working on a cominication
> controller I need to have two buses one for status and
> one for data which makes it very difficult to
> synchronize between both buses.
>
> Thanks
>

Sure.  In fact, most IP cores will include non-wishbone signals.  If it's a
general purpose signal then just define it.  WISHBONE doesn't really care about
it.  For example, if you look at that ap-note we wrote up (WBAN001), you'll see
how it includes both WISHBONE and non-WISHBONE signals.

By the way - you just brought up something that we clarified in the REV B spec.
I'm about to post these changes, but have to check the spelling and reformat the
document.  These include:

PERMISSION 2.11
Non-WISHBONE signals MAY be used with IP cores.

OBSERVATION 2.21
Most IP cores will include non-WISHBONE signals.  These are outside the scope of
this specification, and no attempt is made to govern them.  For example, a disk
controller IP core could have a WISHBONE interface on one end and a disk
interface on the other.  In this case the specification does not dictate any
technical requirements of the disk interface signals.  However, it does require
that the operation of these other signals be documented in the WISHBONE
DATASHEET.

OBSERVATION 2.22
[TAGN_I] and [TAGN_O] are user defined signals that must adhere to the timing
specifications given in this document.