OCP: Open Core Protocol

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

2. 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. SoC designers want to reuse IP-Cores. This implies shorten development schedules and lower costs. Problem: for each SoC, the cores have to be readapted: 1000s of cores, 10s or 100s of interconnects/buses must understand lots of interfaces overwhelming amount of adaptation work SoC designers want to reuse IP-Cores. This implies shorten development schedules and lower costs. Problem: for each SoC, the cores have to be readapted: 1000s of cores, 10s or 100s of interconnects/buses must understand lots of interfaces overwhelming amount of adaptation work

3. What is needed? What is required is a standard, well-defined protocol for cores to talk to a system interconnect. We need a clearly-specific contract between core developer and system integrator. The protocol has to be core-centric Scalable and configurable Process independent and synthesis/analysis friendlyWe need a clearly-specific contract between core developer and system integrator. The protocol has to be core-centric Scalable and configurable Process independent and synthesis/analysis friendly

4. OPEN CORE PROTOCOL 2.0 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 Physical implementation: piont-to-point, simplex, synchronous with ocp rising edge. Short distance to/from unetwork OCP master can send commands to OCP slave, and can receive command responses. It is the only one which cann initiate a communication. OCP slave can receive commands from OCP master and can send command responses. Extensions: Simple extension -> add support for higher performance Burst Extension -> burst is a set of related words. It provides a method for linking together OCP transfers. Threat Extension -> add support for concurrency. It lets to have different transfers streams. Side Band Signals ->provides a means of transmitting control-oriented information.Physical implementation: piont-to-point, simplex, synchronous with ocp rising edge. Short distance to/from unetwork OCP master can send commands to OCP slave, and can receive command responses. It is the only one which cann initiate a communication. OCP slave can receive commands from OCP master and can send command responses. Extensions: Simple extension -> add support for higher performance Burst Extension -> burst is a set of related words. It provides a method for linking together OCP transfers. Threat Extension -> add support for concurrency. It lets to have different transfers streams. Side Band Signals ->provides a means of transmitting control-oriented information.

5. 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 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

6. BASIC OCP INTERFACE

7. COMUNICATION PHASES 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 Diferentes fases, lo q hace cada una Los comandos Las respuestas 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 Diferentes fases, lo q hace cada una Los comandos Las respuestas

8. SIMPLE EXTENSION 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�

9. 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 Use of burst can greatly improve overall system performance

10. 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.

11. 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 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

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

13. 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

14. CORE CONVERSION Know the native core interface Know OCP Build bridge Test Package OCP core

15. OCP CORE BRIDGE Match OCP configurations to native protocol patterns. Chose the kind of socket ? Master or Slave 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

16. Case of Study: CAN CORE

17. 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).

18. Case of study: CAN CORE OCP INTERFACE

19. 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

20. Case of study: CAN CORE TIMING DIAGRAMS. Write operation

21. Case of study: CAN CORE TIMING DIAGRAMS. Read operation