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.

What is needed?

What is required is a standard, well-defined

protocol for cores to talk to a system
interconnect.
Core
designers

System
integrator

Core
1

Core
2

Core
N

core i/f

core i/f

core i/f

System
socket

System
socket

System
socket

On-chip interconnect

OPEN CORE PROTOCOL 2.0

Point-to-point, uni-directional, synchronous

Master/Slave, Request/Response model

Well-defined, simple roles

Extensions

Easy physical implementation

Added functionality to support cores with more

complex interface requirements

Configurability

Match a cores requirements exactly

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

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

BASIC OCP INTERFACE

Clock

Master / Slave

Accept WR Data

Slave

Master

Write Data

Response

Response
Accept Response

Control signals

Core

System

Read Data

test signals

Optional handshake signals

Dataflow signals

Accept Request

Request

Request

Split protocol
Multiple phases:

Request phase
Response phase
Separate data
handshake
(optional)

COMUNICATION PHASES
Possible Response Code

Read
ReadEx
ReadLinked

Request

Response

DVA / ERR

Write

Request

Response

DVA / ERR

Request

Response

DVA / ERR

WriteNonPost
WriteConditional

Request

Response

DVA / FAIL / ERR

Write
w/datahandshake

Request

w/o
datahandshake

Data

Response DVA / ERR

Response

Optional response phase

DVA

Data Valid / Acknowledge

ERR

Transfer Error

FAIL

Write operation has failed

SIMPLE EXTENSION

Byte enables

Multiple address spaces, mapped at non

contiguous address ranges. Typically to:

Provide byte addressing capability on a multi-byte

interface

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

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

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

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

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

CORE CONVERSION
Existing
Core

OCP
Bridge
Core interface

1.
2.
3.
4.
5.

Know the native core interface

Know OCP
Build bridge
Test
Package OCP core

OCP interface

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

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:

Bit_stream
Tx_bit

CAN CORE

Remote_frame
Reset
Clock
Tx_msg[0-101]
Start
Ps1
Ps2
Rsj
Bpr
Bus_off
Tx_completed
Rx_completed
Rx_msg[0-101]
Err_passive
Rx_err_cnt
Tx_err_cnt
Syncbit
Tx_busy
Test
Sample
Sample_bit
Reset_asyn
Filter_remote

= 1
= 1

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

= 1
= 1

Remote_frame
Reset
Clock
Tx_msg[0-101]
Start
Ps1
Ps2
Rsj
Bpr
Bus_off
Tx_completed
Rx_completed
Rx_msg[0-101]
Err_passive
Rx_err_cnt
Tx_err_cnt
Syncbit
Tx_busy
Test
Sample
Sample_bit
Reset_asyn
Filter_remote

Clk

REGISTERS

STATE MACHINE

Mreset_n
MCmd
Maddr
MData
MBurstLength
MBurstSeq
MBurstPrecise
MBurstSingleReq
MDataValid
Mdata
MDataLast
SCmdAccept
SData
SDataAccept
Sresp
SRespLast

OCP SLAVE

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

REGISTER

ADDRESS

Setup0

00h

Setup1

04h

Setup2

08h

Setup3

0Ch

Status0

10h

Status1

14h

Filter0

18h

Filter1

1Ch

Filter2

20h

Filter3

24h

Tx_msg0-Tx_msg12

28h 88h

Rx_msg0
Rx_msg12

8Ch - ECh

Tx_error_cnt

F0h

Rx_error_cnt

F4h

Case of study: CAN CORE

TIMING DIAGRAMS. Write operation

Case of study: CAN CORE

TIMING DIAGRAMS. Read operation