Bus protocols limit design reuse of IP

Bus protocols are based upon the printed-circuit board style of interconnect structures that consist of hierarchical wire bundles, and are proving to be ineffective for system-on-chip (SoC) designs. All bus protocols strictly define an interblock data-flow communication methodology, and demand the use of this style to the exclusion of any other technique. Also, sideband control signals are typically not supported by computer-bus style protocols, and require the system integrator to deal with them in an ad-hoc way for each system design. This means that if an intellectual-pr operty designer inflicts a particular bus protocol upon his IP core, the path to another bus protocol may only be possible via the loss of features or performance-or may not be possible at all.

Core-centric protocol

The solution to maximizing an intellectual property's potential market size while still realizing the advantages of proven industry standards is to adopt a well-specified core-centric protocol as an IP core's native interface. A strict and complete interface specification between IP cores and on-chip interconnect systems allows an IP core developer to focus on core generation without having to know anything about the end systems in which the core might be eventually used, nor anything about the other intellectual property cores that might be a part of the app.

System integrators also benefit by not having to deal with today's diverse core protocols and delivery styles. Use of a standard intellectual property core interface eliminates having to adapt each core for ev ery SoC integration, and instead allows the system integrator to focus on system-level design issues. Also, since the cores are decoupled from the on-chip interconnect and from each other, it is simple to swap one core for another to better meet evolving system requirements.

For an IP core to be truly reusable it must remain untouched as it moves from system to system; its interface must match the unchanging requirements of the core rather than the continuously differing requirements of each system's interconnect. A core must not have to be adapted every time the bus width, frequency, or electrical loading changes.

Since core interface requirements are as diverse as the IP cores themselves, there is no one-size-fits-all. A standard core interface specification must be scalable and configurable to adapt to the wide range of requirements. It is also not sufficient for an interface specification to onl y capture data-flow signaling. It is important that all signaling between the core and the system is captured. Typically, the non-data-flow signals are control wires such as interrupts, error signals, flow-control signals or test signals.

The freely available Open Core Protocol (OCP) is a bus-independent protocol that meets all the core-centric considerations discussed above, and completely captures all of an IP core's communication requirements. The highly configurable OCP is not a one-size-fits-all protocol, but is instead analogous to a continuum of protocols that have a common definition structure. Sideband signals are explicitly supported via optional extensions to the basic OCP for reset, interrupts, errors, control/status information, etc. In addition, a generic flag bus is used to accommodate a core's unique signaling needs.

The optional test interface extensions of the OCP support scan, JTAG and clock control, enabling debug and manufacturing test of the core when integrated into the system-on-a-chip. A core's specific OCP configuration is, therefore, tailored to match the core's requirements exactly. A simple, low-performance core can have a very simple interface, while a complex, high-performance core can be accommodated just as effectively.

An intellectual property developer can therefore complete an IP core design using the OCP interface. No end-application knowledge is required beyond the OCP, allowing complete independence for members of the often global design teams. The system integrator is also free to choose the on-chip interconnect that best suits the system requirements of the application, then effectively "wraps" that interconnect to present OCP interfaces to the cores.

An IP core using the OCP as its native interface can be easily reached by any bus structure the customer chooses through simple bridge structures. Since the OCP doesn't constrain a core, every bus bridge to the OCP is able to reach that core's maximum capabilities. If the chosen interconnect system cannot interface directly to the OCP, the intellectual property developer could design prebuilt bus bridges for each of the more common bus structures that a customer may choose.

The work required to design an OCP interface wrapper for a core is bound by the distinct choices that the OCP protocol itself offers, so there typically is only a regular set of wrappers that need to be provided. In fact, the wrapper generation process is regular enough to be amenable to automatic interface synthesis, which is exactly what Sonics provides for its on-chip interconnect system, the SiliconBackplane.

Developers using the OCP also register for a free Developer ID number that they can then associate with Core ID and Revision ID numbers of their choosing. This facilitates a true plug-and-play environment for IP cores that have software drivers that need to be matched with specific versions of the core.

Sonics developed the CoreCreator tool as an OCP protocol-compliance environment and "packa ger" for all the representations necessary for efficient reuse of an IP core.

The alternative of designing multiple bus bridges from a bus-centric native core protocol creates a starting point with strictly defined limitations. Whenever there are differences in data and address presentation sequences between a core's native bus and target bus, the core's performance will likely suffer due to the bridge-on-a-bridge effect of having to correlate the signaling between the two disparate bus structures at their lowest common denominator. The implementation gate count for the bridged core is also likely to be higher.

AMBA-native core

A customer-based case study showed that installing the OCP on a slave USB core as the native interface, then building a bridge to one of the ARM AMBA bus protocols required no more implementation gates than installing the AMBA protocol as the core's native interface. In this instance, both implementations also passed through the full capabilities and per formance of the core, although the AMBA-native core required custom-defined implementations for all control and test signals since the AMBA bus standard did not directly address their implementation.

When these two cores were further interfaced to an IBM CoreConnect bus protocol (the OPB), the OCP-native core simply required a replacement bridge that again delivered all the core's capabilities and performance to the OPB.

The Virtual Socket Interface alliance (VSIA) also advocates this core-centric approach, and has a working group dedicated to specifying a protocol, the Virtual Component Interface (VCI). Sonics is an active member of several VSIA working groups and is committed to the concept of a standard core interface.

Unfortunately there is no published VCI specification yet, and although based upon Sonics' OCP work, the VCI is expected to be limited to only the data flow portion of a core's interface, and does not attempt to capture control and test signals.

It will ther efore not be possible to capture all of a core's communication requirements with the VCI specification.

The core-centric OCP is an openly licensed, royalty-free protocol that does not impose restrictions or interfere with an IP core's inherent capabilities.

It is scalable and configurable to match the different communication requirements associated with different IP cores.

The OCP functions ideally as a native IP core interface since bridges to any bus or integration structure can be implemented without the gate count or performance penalties typical of bus-centric protocols.

Cores with OCP interfaces and wrapped interconnect systems, such as Sonics' SiliconBackplane, enable true plug-and-play integration.

Further information about the OCP specification is available at www.sonicsinc.com/nova/ocpspec.html.