Missing the SoC bus

Missing the SoC bus
By Ron Wilson, EEdesign
August 1, 2002 (2:04 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020801S0051

The question of how to manage interconnect among the various functional blocks on a system on chip (SoC) has been raging for some time, and it occasionally breaks through into the world of press releases. The most recent guest appearance was in the recent announcement by MIPS Technologies of a central switch strategy for interconnect on high-end, MIPS-powered SoCs.

The announcement was intended to differentiate MIPS's new interconnect architecture from chip interconnect schemes based on conventional busses. Bus-based interconnect, as the name suggests, uses a structure derived from a conventional microprocessor bus to connect the functional blocks on a chip.

But before that simile goes to far, it is important to look at how busses and switches are actually implemented on SoCs. In fact they are not different critters, but different points on a continuum.

That is because of all the difficulties caused by the basic element of the board-level bus, the shared wire driven by a number of tri-state buffers. For many reasons, it's a non-starter on silicon. On-chip busses are not done with shared multi-master wires. Instead, there is a single interconnect net driving the inputs of the functional blocks, all right, but it's driven by a big multiplexer, not a bunch of separate tri-state buffers. The multiplexer selects the source, and sends the signal to all the destinations.

In contrast, a fully-populated cross-bar switch is made not with one multiplexer per bit selecting the source for the whole net, but with one multiplexer per bit on each functional block, so that each block can pick its own source. Thus in a full implementation the crossbar is entirely non-blocking: in theory each block on the SoC could select another block and all could transfer data on the same cycle.

The picture gets interesting because neither busses nor switches tend to be pure implementations in real life. A chip that uses a nominal bus architecture may in fact have special preferred paths for some transactions. For example, while all the peripheral blocks may be on a common net, there may be a dedicated path from the CPU cache controller to memory, so that a slow peripheral transfer can't block a cache load. In effect, the so-called bus has some of the features of a switch.

Conversely, few designs that use the switch architecture implement full, non-blocking crossbars. In previous process generations the amount of interconnect required would have been problematic. In current geometries with up to eight layers of fine-pitched copper, running out of routing isn't a problem. But having all those buffers on at once, and having active signals on all those lines at once can be a problem, either for power consumption, thermal effects, crosstalk or simply the capacity of the analysis tools.

Just verifying that capacitive coupling is not a problem for any arbitrary combination of sources and destinations would b e a daunting extraction task. Consequently, even on new designs switches aren't necessarily full switches-they often give priority to certain connections, while letting other connections share resources.

That is the case in the MIPS SoC-it approach, according to director of product strategy David Courtright. The MIPS switch is designed to give priority to the cache-to-memory path. But it trades off full crossbar implementation against the complexity and wiring density of the design.

So when is a bus a bus, and when is a switch a switch? It might be safer to take both terms as suggestions about the ultimate transfer rate of the interconnect structure, and then to look more closely at how individual blocks are connected to each other. The important thing is not architectural purity, but rather to achieve an interconnect architecture that reflects the data flow behavior of the end application without creating yield problems in the metal stack.

Ron Wilson is a contributor to EE Times, where he manages the Silicon Engineering section. He has covered chip-related matters for 15 years for various industry publications, and was once, in the distant past, a designer himself.