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.
The following additional signals are defined:
Signal name | Description |
---|---|
ACK_OI | WhisboneTK acknowledge chain input signal |
RTY_OI | WhisboneTK retry chain input signal |
ERR_OI | WhisboneTK error chain input signal |
DAT_OI(..) | WhisboneTK data bus chain input signal |
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:
WishboneTK signal name | Paired Wishbone signal name |
---|---|
ACK_OI | ACK_O |
RTY_OI | RTY_O |
ERR_OI | ERR_O |
DAT_OI(..) | DATA_O() |
All signal with it's associated pair works in a similar way so operation will be described using the ACK_O/ACK_OI signals.
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:
ACK_OI <= (I_ACK_O and STB_I) or (ACK_IO and not STB_I);
Because Wishbone does not specify any bahaviour for these lines when STB_I is inactive this modification still fully conforms with the original spec.
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.
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.)
The inputs of the first slave in the chain must be connected as follows:
WishboneTK signal name | Default value |
---|---|
ACK_OI | '0' |
RTY_OI | '0' |
ERR_OI | '1' |
DAT_OI(..) | '-' (don't care) |
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'.
For WishboneTK cores to be connected to three-stated buses use the following defaults:
WishboneTK signal name | Default value |
---|---|
ACK_OI | 'L' (weak pull-down) |
RTY_OI | 'L' (weak pull-down) |
ERR_OI | 'H' (weak pull-up) |
DAT_OI(..) | 'Z' (hi-Z state) |
If an external multiplexer is used to connect slave signals to master, use the following defaults:
WishboneTK signal name | Default value |
---|---|
ACK_OI | '-' (don't care) |
RTY_OI | '-' (don't care) |
ERR_OI | '-' (don't care) |
DAT_OI(..) | '-' (don't care) |