Bus Bridge

The essential behaviour of the bus bridge is that bus operations slaved on one side are mastered on the other. The bridge need not be symmetric: speeds and data widths may be different on each side.

A bus bridge connects together two busses that are potentially able to operate independently when traffic is not crossing. However, in some circumstances, especially when bridging down to a slower bus, there may be no initiator on the other side, so that side never actually operates independently and a unidirectional bridge is all that is needed.

The bridge need not support a unified or flat address space: addresses seen on one side may be totally re-organised when viewed on the other side or un-addressable. However, for debugging and test purposes, it is generally helpful to maintain a flat address space and to implement paths that are not likely to be used in normal operation.

A bus bridge might implement write posting using an internal FIFO. However it will generally block when reading. This is a motivation for having a network-on-chip.

As noted, the `busses' on each side use multiplexors and not tri-states on a SoC. These multiplexors are different from bus bridges since they do not provide spatial reuse of bandwidth. Spatial reuse occurs when different busses are simultaneously active with different transactions. Multiple busses is a poor-man's network-on-chip.

With a bus bridge, system bandwidth ranges from 1.0 to 2.0 bus bandwidth: inverse proportion to bridge crossing cycles.