OCP: Open Core Protocol Marta Posada ESA/ESTEC June 2006

Motivation  SOC designers want to reuse IP cores to shorten development schedules.  Problem: IP cores need to be re-adapted into each system design  Motivation: reuse without rework Plug-and-play between cores and interconnects systems from different sources. Plug-and-play between cores and interconnects systems from different sources.

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

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

OPEN CORE PROTOCOL 2.0  OCP is configurable to tailor the interface exactly to the features required by the core Basic OCP is very simple Basic OCP is very simple Many extensions exist for cores with more complex interface requirements 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 Control the presence of a set of signals example: core makes use of byte enablesexample: core makes use of byte enables Control the width of a set of signals Control the width of a set of signals example: address width is 14 bitsexample: address width is 14 bits Control protocol features Control protocol features example: core uses data handshaking to pipeline write dataexample: core uses data handshaking to pipeline write data

BASIC OCP INTERFACE  Master / Slave  Split protocol  Multiple phases: Request phase Request phase Response phase Response phase Separate data handshake (optional) Separate data handshake (optional)

COMUNICATION PHASES

SIMPLE EXTENSION  Byte enables Provide byte addressing capability on a multi-byte interface 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 core registers from core memory space Differentiate cores within a sub system Differentiate cores within a sub system  Custom in-band signaling To any of the transfer phases: Request, response, datahandshake To any of the transfer phases: Request, response, datahandshake Typical usage: Cache signaling, application/emulation qualifier, dynamic endianness qualifier… Typical usage: Cache signaling, application/emulation qualifier, dynamic endianness qualifier…

BURST EXTENSION(I)  Multiple independent OCP transfers can be linked together into a single burst transaction. Burst allow target to know there are more transfers coming for pre-fetching Burst allow target to know there are more transfers coming for pre-fetching Use of burst can greatly improve overall system performance Use of burst can greatly improve overall system performance  Burst 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 Burst signaling supplies the burst address sequence, the burst length, the burst type

OCP BURST EXTENSION(II)  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.

OCP THREAD 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 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 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 Allows for concurrency and out-of-order returns Each thread retains strict ordering semantics Each thread retains strict ordering semantics BUT: there are is no ordering between transfers in different threads BUT: there are is no ordering between transfers in different threads

SIDEBAND SIGNALS  Reset  Interrupt  Transaction error reporting  Core Flags (core-to-core)  Core Status/Control (system-to-core)  Test

Converting Existing Cores to OCP  Determine the OCP characteristics that the core will have  Design conversion logic to wrap the core  Describes the core’s interface and timing constraints  Develop a portable testbench for the core  If the core is synthesizable, develop a technology-independent synthesis script for it  Assemble the core, modelsm documentation… and package

CORE CONVERSION 1. Know the native core interface 2. Know OCP 3. Build bridge 4. Test 5. Package OCP core Existing Core OCP Bridge Core interface OCP interface

OCP CORE BRIDGE  Match OCP configurations to native protocol patterns. Chose the kind of socket  Master or Slave Chose the kind of socket  Master or Slave Choose the interface signals Choose the interface signals - Choose the simplest configuration that meets the functional and performance requirements of the core Develop the bridge logic to convert core signals into OCP signals Develop the bridge logic to convert core signals into OCP signals

Case of Study: CAN CORE CAN (Control Area Network) is a serial communications protocol which supports distributed real time control with a very high level of security. We are going to convert CAN Core 5.1 (developed by ESA) to OCP. Interface CAN:

Case of study: CAN CORE OCP BRIDGE  We are going to design a SLAVE OCP socket  OCP Burst Extension, with single request multiple data.  OCP Word : 1 byte (8 bits)  Commands : Idle (IDLE), Write (WR) and Read (RD)  Responses: Null (NULL), Data Valid (DVA) and Error (ERR).

Case of study: CAN CORE OCP INTERFACE

Case of study: CAN CORE CAN TO OCP  Model inspired in HurryAmba (developed by ESA).  The CAN core signals are going to be store in some registers.  Both CAN and OCP bridge have access to the registers  Pooling to know there are received data in the registers F4hRx_error_cnt F0hTx_error_cnt 8Ch - ECh Rx_msg0 – Rx_msg12 28h – 88h Tx_msg0-Tx_msg12 24hFilter3 20hFilter2 1ChFilter1 18hFilter0 14hStatus1 10hStatus0 0ChSetup3 08hSetup2 04hSetup1 00hSetup0ADDRESSREGISTER

Case of study: CAN CORE TIMING DIAGRAMS. Write operation

Case of study: CAN CORE TIMING DIAGRAMS. Read operation