Motivation / Background The Open Core Protocol 2.0 Basic OCP OCP simple extensions Burst extension

Core-Centric Communication ProtocolIntroducing Open Core Protocol 2.0Franck Seigneret, Texas Instruments FranceOCP-IP GSC member

Introducing OCP 2.0…. • Motivation / Background • The Open Core Protocol 2.0 • Basic OCP • OCP simple extensions • Burst extension • Threading extension • OCP as a system socket • Related work / conclusion

Motivation: reuse without rework • SOC designers want to reuse IP cores to shorten development schedules. • Problem:IP cores need to be re-adapted into each system design • 1000s of cores, 10s or 100s of interconnects/buses • must understand lots of interfaces • overwhelming amount of adaptation work • Motivation: reuse without rework • Plug-and-play between cores and interconnects systems from different sources.

Core 1 Core 2 Core N Core designers core i/f core i/f core i/f On-chip interconnect System socket System socket System socket System integrator Solution: Core/System Protocol • What is needed is a standard, well-defined protocol for cores to talk to a system interconnect.

Core/System Protocol Requirements • Clearly-specified contract between core developer and system integrator • Core-Centric • Interconnect neutral (not some bus protocol) • Encompass entire core/system interface • Scalable and configurable • Process independent, synthesis/timing analysis friendly

Open Core Protocol 2.0 • Open Core Protocol (OCP) is a core-centric protocol under the governance of the OCP-IP association to enable true core plug-and-play and re-use • This is an OPEN standard • OCP-IP is driven by a pool of key players in the semiconductor industry: Nokia, Texas Instruments, STMicroelectronics, UMC, MIPS, Philips, Sonics, EDA vendors… • Multiple working groups (specification, functional verification, SystemC modeling…): make of OCP a “living” standard • Think of OCP as configurable core socket • OCP 2.0 specification (and much more) can be freely downloaded from the OCP-IP web site: www.ocpip.org

Basic OCP Concepts • Point-to-point, uni-directional, synchronous • Easy physical implementation • Master/Slave, Request/Response model • Well-defined, simple roles • Extensions • Added functionality to support cores with more complex interface requirements • Configurability • Match a core’s requirements exactly • Tailor design to required features only

Basic OCP • Master / Slave • Split protocol • Multiple phases: • Request phase • Response phase • Separate data handshake (optional) • System / Core

OCP commands • Idle… • Read transfer • Standard Read • ReadEx, ReadLinked for exclusive access • Write transfer • With or without response • Posted (Write) or non posted (WriteNonPost) semantics • Conditional (WriteConditional) for exclusive access • Exclusive accesses • Locked synchronization • Atomic ReadEx / Write pairs • Lazy synchronization • Non atomic ReadLinked / WriteConditional pairs

Handshaking • Each phase starts when sender asserts the phase • for example, request phase starts when master sends a non-idle command • Phase ends when receiver asserts handshake • for example, request phase ends when slave asserts the command accept signal • Handshaking allows both sides to assert flow control • sender can delay asserting the phase • receiver can delay asserting the handshake • Example: core can’t take a request every cycle • no need to add storage, just hold off on accepting requests if not ready

1 2 3 4 5 6 7 Clk MCmd Cmd1 Cmd3 Cmd2 MAddr Addr1 Addr2 Addr3 SCmdAccept valid command Cmd2accepted Cmd1accepted Handshake (Timing Diagram)

1 2 3 4 Master Slave 1 2 3 4 Ordering and Pipelining • An OCP transfer is a complete request/response interaction • For longer latency operations would like pipelining • multiple requests can be sent before first response comes back • example: CPU core has multiple outstanding cache misses • OCP allows pipelining of transfers • Responses must be returned in the order of the requests • Requests and responses form a single ordered thread Time

OCP phases within a transfer

Byte enables Provide byte addressing capability on a multi-byte interface Multiple address spaces, mapped at non contiguous address ranges. Typically to: Differentiate core registers from core memory space Differentiate cores within a sub system Custom in-band signaling To any of the transfer phases: Request, response, datahandshake Typical usage: Cache signaling, application/emulation qualifier, dynamic endianness qualifier… OCP Simple Extensions

Burst extension • Multiple OCP transfers can be linked into a burst transaction • Cores such as DRAM controllers can supply the second related piece of data much faster than the first • Bursts allow a target to know that there are more transfers coming, so it can pre-fetch • Bursts are linked together using a burst code that is supplied with every transfer • burst signaling supplies the burst address sequence, the burst length, the burst type, etc....

The OCP burst flexibility • Ability to handle precise bursts (the length is known) and un-precise bursts (the length is unknown). • Ability to specify standard address sequences (incrementing, wrapping, streaming, XOR) as well as custom address sequences. • Ability to support single request/multiple data transaction models. • Ability to define atomic sub-units within a burst for fine control of the request interleaving throughout the system interconnect. • Ability to add complete framing information with all transfer phases.

Threading extension • Within an OCP thread, responses must return in the order of the requests. • For some cores, out-of-order responses are desirable • A multi-bank DRAM controller can return requests to an open bank faster than to a closed one • A DMA controller can handle multiple outstanding transactions from multiple channels on the same OCP port • An OCP interface can support multiple threads • Allows for concurrency and out-of-order returns • Each thread retains strict ordering semantics • BUT: there are is no ordering between transfers in different threads

Threads (illustrated) • Golden rule • Strict ordering within a thread • No ordering betweenthreads • Requests, data, responses are tagged with a threadID • Multithreading also helps reducing the number of wires, to limit the routing congestions 1A 1B 2A 2B Master time Slave 1A 2A 1B 2B Thread A Thread B

Control and Test Signals • Reset • Interrupt • Transaction error reporting • Core Flags (core-to-core) • Core Status/Control (system-to-core) • Test: Scan chains and standard JTAG (IEEE1149) • …and platform specific signals also known as Sideband Signals because they areout-of-band with respect to data flow signals

Configurability • OCP is configurable to tailor the interface exactly to the features required by the core • Basic OCP is very simple • Many extensions exist for cores with more complex interface requirements • OCP is configured via a set of parameters • Control the presence of a set of signals • example: core makes use of byte enables • Control the width of a set of signals • example: address width is 14 bits • Control protocol features • example: core uses data handshaking to pipeline write data

OCP as IP Core Delivery Vehicle • OCP is not just a core/system interface specification • OCP also specifies: • Precise description format for core interfaces • Precise description format for timing of core interfaces • Core performance information • Configuration information is in machine-readable TCL file format • Allows for automated processing, at both core and interconnect level • Core designer and system integrator’s job is greatly simplified

Master Master Master Master Open Protocol Core IP Core IP Core IP Core Slave Slave Slave Slave On-Chip Interconnect System Usage of Open Core Protocol • Can wrap any on-chip interconnect using OCP • Yields system ready for plug-and-play with IP cores • Well-specified protocol allows interconnect wrapper-generation to be automated.

Related Work / Conclusion • Virtual Socket Interface Alliance (VSIA) has also putting forth the idea of a standard IP core socket • Virtual Component Interface (VCI) • VCI and OCP are completely aligned in terms of their goals • October 2003: VSIA endorses the OCP interface, OCP-IP becomes the first VSIA adoption group • The recently unveiled ARM AXI specification also refers to the same foundations, a well as many company in-house protocols…  This re-enforces the pioneer role played by OCP. Today, only OCP can be presented as the de-facto industry standard for a core complete socket

THANK YOU !For more information, please take a look at http://www.ocpip.org/and… stop at the OCP-IP booth in this conference center

Motivation / Background The Open Core Protocol 2.0 Basic OCP OCP simple extensions Burst extension