SoCs: Design tools -> Bus protocols limit design reuse of IP

Bus protocols limit design reuse of IP
By Ed Smith, Director, Business Development, Sonics Inc., Mountain View, Calif., EE Times
May 15, 2000 (1:32 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000515S0026

Semiconductor intellectual-property designers strive to ensure their IP can be used by the widest possible range of applications to ensure maximum return on their engineering investment. However, the common practice of selecting a bus-centric protocol as an IP core's native interface will ultimately limit the market into which an IP core can subsequently be used or sold.

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.