Subversion Repositories wb_tk

<!--# include virtual="/ssi/ssi_start.shtml" -->
<link REL="stylesheet" TYPE="text/css" HREF="/people/tantos/styles.css">
 
<h1>WisboneTK</h1>
<h2>WishboneTK extensions</h2>
<h3>General Description</h3>
<p>
WhisnoneTK extends the original Wishbone specification with some signals. These signals are common in all WishboneTK cores.
The cores are still 100% compatible with the original Wishbone specification. Other Wishbone cores without this extended signal set
can be integrated with WishboneTK cores with no problem. The Wishbone specification does not specifiy the topology of the bus. It
allows for both multiplexer-driven, three-stated, cross-bar or any other topology. WishboneTK extensions make this integration effort
easyer by introducing a distributed multiplexer scheme.
<h3>Additional signals</h3>
<p>
The following additional signals are defined:
<table border>
<tr><th>Signal name</ht><th>Description</th></tr>
<tr><td>ACK_OI      </td><td>WhisboneTK acknowledge chain input signal</td></tr>
<tr><td>RTY_OI      </td><td>WhisboneTK retry chain input signal</td></tr>
<tr><td>ERR_OI      </td><td>WhisboneTK error chain input signal</td></tr>
<tr><td>DAT_OI(..)  </td><td>WhisboneTK data bus chain input signal</td></tr>
</table>
<p>
The operation of these pins are simple and the same for all pins. They all have a pair in the original Wishbone specification. ACK_OI for
example paired with ACK_O. The rule is that an additional 'I' character is appended to the original Wishbone name to get the name for
the extended signal. So the pairing of the signals is as follows:
<table border>
<tr><th>WishboneTK signal name</ht><th>Paired Wishbone signal name</th></tr>
<tr><td>ACK_OI      </td><td>ACK_O</td></tr>
<tr><td>RTY_OI      </td><td>RTY_O</td></tr>
<tr><td>ERR_OI      </td><td>ERR_O</td></tr>
<tr><td>DAT_OI(..)  </td><td>DATA_O()</td></tr>
</table>
 
<h3>Signal operation</h3>
<p>
All signal with it's associated pair works in a similar way so operation will be described using the ACK_O/ACK_OI signals.
<p>
The generation of the original Wishbone signal was slightly modified. There is an internal (let's call it I_ACK_O) signal inside each
core which has the same behaviour that Wishbone specification dictates. The external ACK_O signal will be the same as the internal
I_ACK_O signal if the device is selected (STB_I is active) and will be tha same as ACK_OI otherwise. The logic representation of 
this is:<br>
<code>ACK_OI <= (I_ACK_O and STB_I) or (ACK_IO and not STB_I);</code>
<p>
Because Wishbone does not specify any bahaviour for these lines when STB_I is inactive this modification still fully conforms with
the original spec.
 
<h3>Signal usage for multiplexed buses</h3>
<p>
Multiplexed buses it is much easyer to build using this aproach. If you connect all salve devices in a chain by connecting previous 
slave's ACK_O to the next devices ACK_OI and all other mentioned pins likewise you get a distributed multiplexer achitecture. Note
that during flattening the design (part of the synthetizis process) this distributed multiplexer will turn into a normal multiplexer.
<p>
For this achitecture you should connect the outputs of the last slave in the chain to the inputs of the master device. (As Wishbone
does not provide any arbitation mechanism there can be only one master in a bus and arbiter bridges must be used for a multi-master
configuration.)
<p>
The inputs of the first slave in the chain must be connected as follows:
<table border>
<tr><th>WishboneTK signal name</ht><th>Default value</th></tr>
<tr><td>ACK_OI      </td><td>'0'</td></tr>
<tr><td>RTY_OI      </td><td>'0'</td></tr>
<tr><td>ERR_OI      </td><td>'1'</td></tr>
<tr><td>DAT_OI(..)  </td><td>'-' (don't care)</td></tr>
</table>
<p>
You can easily do this by setting these values as the defaults in your component declaration. This will give you another benefit: 
Wishbone defines a handshake between masters and slaves. The master will wait after a cycle issued until the slave signals the
end of the cycle by asserting either ACK_O, ERR_O or RTY_O. If the master (a micro-processor program) issues an access to an undefined
address, no slave will be addressed. In this case the master will wait endlessly if none of the handshake signals default to '1'.
If your design does not use the ERR_O handshake mechanism you should default another signal to '1'.
 
<h3>Signal usage for three-stated buses</h3>
<p>
For WishboneTK cores to be connected to three-stated buses use the following defaults:
<table border>
<tr><th>WishboneTK signal name</ht><th>Default value</th></tr>
<tr><td>ACK_OI      </td><td>'L' (weak pull-down)</td></tr>
<tr><td>RTY_OI      </td><td>'L' (weak pull-down)</td></tr>
<tr><td>ERR_OI      </td><td>'H' (weak pull-up)</td></tr>
<tr><td>DAT_OI(..)  </td><td>'Z' (hi-Z state)</td></tr>
</table>
Than connect all ACK_O signals of all slaves together and connect them to the master. Do the same with all other mentioned 
(RTY_O, ERR_O, DAT_O) signals.
 
<h3>Signal usage in none-WishboneTK multiplexed-bus applications</h3>
<p>
If an external multiplexer is used to connect slave signals to master, use the following defaults:
<table border>
<tr><th>WishboneTK signal name</ht><th>Default value</th></tr>
<tr><td>ACK_OI      </td><td>'-' (don't care)</td></tr>
<tr><td>RTY_OI      </td><td>'-' (don't care)</td></tr>
<tr><td>ERR_OI      </td><td>'-' (don't care)</td></tr>
<tr><td>DAT_OI(..)  </td><td>'-' (don't care)</td></tr>
</table>
 
<h2>Author & Maintainer</h2>
<p>
<a href="/people/tantos">Andras Tantos</a>
<!--# include virtual="/ssi/ssi_end.shtml" -->