Everyone knows what a bus is and how to define it. Unfortunately, these definitions can be very cumbersome, especially in this new everything-connects-to-everything-else bus world. Maybe we need a new defining mechanism, something a bit higher in level and more conceptual, and something focussing less on the hardware signaling aspects of a bus.
Here's a modest proposal: a hardware API—that is, define the bus operational interface as we do a software interface. A software API defines a program interface in terms of its functional call interface (and its underlying state machine, if done correctly). Similarly, a hardware API can provide a higher-level definition of a bus in terms of its bus operations and underlying state machine. This is a conceptual, rather than a signaling definition of the bus.
This hardware API idea was triggered by Pentek (a VME board vendor) putting Ethernet across the VME backplane. Pentek accomplished this, not by adding more I/O signals, but instead by converting the Ethernet transactions into VME bus operations, passing the data over the bus, and reconverting that data into Ethernet transactions. In effect, they had a stack, with an Ethernet, a VME bus, and an Ethernet layer. The problem is how to describe it: VME bus definitions are defined in terms of bus operations, bus signaling, and bus exceptions. This isn't a high-level description that fits the communications stack model.
Bus definitions are hardware oriented, centering on hardware signaling and bus operations. The only written full bus definitions are Verilog, VHDL, or RTL bus controllers that actually implement the bus, and these don't make for an easy read.
Unfortunately, buses also are standard interconnects, which designers are using as easy-to-deploy connections between systems. For example, there are a number of system interconnects, like switch-fabrics or point-to-point serial links, that use the PCI bus as a standard connection, even if there's no PCI bus. After all, PCI is a standard to which everyone knows how to connect, and it has much available controller silicon. Designers, therefore, could use bus connections with no real bus, but just an interconnect standard.
A hardware API gets us around the problem. It gives us a top-level definition, independent of hardware signaling. This API should provide a connection bus width and bus rate for a top-level hardware connection. But, it's primarily a high-level definition for a bus, independent of the complex signaling details.
What's a bus definition? A bus specification primarily consists of a set of defined operations, a set of signal and bus connections, the signaling conventions of that connection, and a set of exceptions and special cases to implement or deal with. Good specifications also provide an overview and a top-down view on how the thing works. That's a lot of stuff. Further, no two specifications are defined in the same way.
A common bus definition with the same format for each bus, a hardware API, lets designers get at the bus's core without reading the full specification. Plus, it may help ASIC and SOC designers to take advantage of available common bus interconnects.
Actually, a hardware API permits designers to utilize the currently accepted communications stack model too. Although it took years, most of today's designers understand that model. With a hardware API, we could describe layers of bus interconnects using the communications stack model. This could be very handy, as designers seem to be in a world where every type of bus connects somewhere to every other bus.
Finally, the hardware API has a sexy acronym: H-API. What else could we ask for? On a more serious note, we're now in a design world where we need to describe everything in some written form. The hardware API might just fill the bill.