SoC bus war fizzles

SoC bus war fizzles
By Ron Wilson, EEdesign
July 1, 2002 (6:13 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020701S0065

It wasn't supposed to end this way. As the various approaches to system-on-chip (SoC) development began to congeal into distinct methodologies, the dominant approach began to look a lot like the design practices of the component-level days. Designers thought of an SoC not as one giant expanse of logic and memory cells, but as distinct functional blocks, often organized around one or more CPU cores.

This way of thinking led, more or less by accident, to a major departure from previous ASIC methodology. In the past, ASICs had always been partitioned into blocks-sometimes functional, sometimes structural, both to manage the cognitive complexity of the design and to create chunks small enough to feed successfully through the tools. But the blocks were always assumed to be connected to each other by ad-hoc, point-to-point interfaces. As designers began to think of SoCs as CPU-centric collections of functional blocks, they began to think of the interconne ct problem not in terms of point-to-point interfaces but in terms of a CPU bus architecture.

That held out to us reporters the promise of a really juicy bus war, parallel to the ones that raged through the industry back when microprocessors and board-level computers were changing everything. And the ground seemed fertile. Each vendor of a microprocessor core had his or her own pet bus architecture. Each major ASIC vendor had its own ideas about bus structures, and a number of third-party IP vendors offered integration methodologies that were, in effect, fully elaborated bus architectures.

Even the VSIA dipped briefly into the waters, but quickly withdrew, instead deciding -- in finest standards-group fashion -- to define a bus wrapper that would allow everyone to be right while letting the rest of us get some work done.

But the bus wars pretty much fizzled out. Not that you could tell from the press, necessarily, but it's about over. The AMBA architecture from ARM has now become so widely adopted that there is little chance of anyone, even mighty IBM, altering the will of the people.

Part of the reason for this rapid settlement has nothing to do with architecture, but everything to do with verification. In the last year or so, the realization has hit most practitioners of SoC design that verification badly needed more abstraction. The move from vector-based to transaction-based to property-based verification has been accelerating lately, with all three techniques coexisting in most designs.

In this environment, the greatest value of an on-chip bus is not so much that it interconnects the functional blocks as that it provides the protocol stack through which the chip can be viewed as a set of transaction-based objects, rather than as a huge state machine, or -- much worse -- a huge collection of asynchronous black boxes. By defining the required behavior of blocks in terms of transactions, the details of which are defined by the bus at a number of protocol layers, the design team enormously s implifies the verification problem and increases the level of abstraction with which the verification team can view the design.

And hence AMBA, with its clearly defined hierarchy of physical interconnect, unambiguous protocols and growing body of testbench and formal verification infrastructure, is armed to overwhelm its competitors. Not out of inherent virtue, but like so many other de-facto standards, because of the accumulated wisdom and work that design teams have put around it.

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