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.

3
What is needed?

• What is required is a standard, well-defined
  protocol for cores to talk to a system
  interconnect.

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 cores requirements exactly
• Tailor design to required features only

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
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 cores 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

• 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

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