Design and Analysis of Low power Open Core

Protocol Compliant Interface using VHDL

Ramesh Bhakthavatchalu
1
,Deepthy G R
2

Dept. of ECE
Amrita Vishwa Vidyapeetham,
Amritapuri, Kollam-690525, Kerala, India
1
rameshb@am.amrita.edu
2
deepthy.gr@gmail.com




Vidhya S
3
, Nisha V
4

Dept. of ECE
Amrita Vishwa Vidyapeetham,
Amritapuri, Kollam-690525, Kerala, India
3
vidhu67@gmail.com
4
vsn4891@gmail.com
Abstract The necessity of Intellectual Properties (IP) reuse
to shorten the design time and the complexity makes the large
scale System On Chip (SoC) more challenging. An efficient bus
protocol for the core communication between IP block is OCP.
Open Core Protocol (OCP) defines the only non-proprietary,
openly licensed, core centric protocol with high-performance,
bus-independent interface between IP cores that reduces
design time, design risk, and manufacturing costs and promote
IP core reusability for SOC designs. Bus Bridge interconnects
other bus standard to OCP. This paper focus on the design and
implementation of Bus Bridge using OCP master and I2C slave
protocol.I2C is a simple bi-directional 2-wire bus for efficient
inter-IC control. The developed FSMs for OCP and I2C were
implemented using VHDL and the synthesis is done using
Xilinx ISE 10.1.
Keyword-Bus Bridge; I2C Controller; Processor; Master; Slave;
OCP compliant; Interface.
I. INTRODUCTION
Open Core Protocol interface addresses communication
between the functional units that comprise a system on a
chip. OCP provides independence from bus protocols
without having to sacrifice high performance access to on
chip interconnects. The interface boundary defined by the
OCP can develop reusable IP cores without regard for the
ultimate target system. OCP unifies all inter-core
communications, including sideband control and test
harness signals. OCPs synchronous unidirectional signaling
produces simplified core implementation, integration, and
timing analysis. OCP eliminates the task of repeatedly
defining, verifying, documenting, and supporting
proprietary interface protocols. The OCP readily adapts to
support new core capabilities. Clearly delineated design
boundaries enable cores to be designed independently of
other system cores yielding definitive, reusable IP cores
with reusable verification and test suites. The OCP supports
very high performance data transfer models ranging from
simple request-grants through pipelined and multi-threaded
objects. Higher complexity SOC communication models are
supported using thread identifiers to manage out-of-order
completion of multiple concurrent transfer sequences [1].
I2C is a two wire bi-directional serial bus that provides a
simple and efficient method of data exchange between
devices. It is low bandwidth, short distance protocol for on
board communications. All devices are connected through
two wires-serial data (SDA) and serial clock (SCL), carry
information between the devices connected to the bus [3].
II. OPEN CORE PROTOCOL COMPLIANT SYSTEM
Strength of OCP is the ability to configure an interface to
match a cores communication requirements. Profiles
address only the OCP interface, with each profile consisting
of OCP interface signals, specific protocol features, and
application guidelines. For cores natively equipped with
OCP interfaces, profiles minimize the number of interface
and protocol options that need to be considered. For
Compliance the core must include at least one OCP
interface. The core and OCP interfaces must be described
using an RTL configuration file. Each OCP interface on the
core must comply with all aspects of the OCP interface
specification. OCP provides predefined profiles to help map
the requirements of common and standard communication
to OCP configuration. There are three types of OCP Profiles
(i)High Performance (HP) (ii) Generic Profile (GP)
(iii)Peripheral Profile (PP) [2]. The PP only implements the
simple read/write transfer without other OCP extensions.
GP extends the PP with additional data handshake phase
and burst extensions for generic device with block data
transfer. HP extends the GP with OCP tag extensions to
support out-of-order response. OCP specifies 3 major types
of interfaces. (i) Bus Bridge Interface (ii) Processor
Interface (iii) Memory Interface [6]. The Bus bridge
interface includes an external bus like USB or AXI and the
internal bus will be OCP. In the Processor interface the
interface is between processors which include only the OCP
master.. These OCP interfaces are different in protocol
features or signals to optimize the needs of IP cores.
However, all of them follow the same OCP timing and
validation rules, which simplify the cost in verification and
implementation [2].
PROCEEDINGS OF ICETECT 2011
978-1-4244-7926-9/11/$26.00 2011 IEEE 621
III. BUS BRIDGE INTERFACE SYSTEM
The bridging profiles of OCP are designed to simplify or
automate the creation of bridges to other interface protocols.
The bridge can have an OCP master or slave port. There are
two types (i)The simple H-bus profile is intended to provide
a connection through an external bridge, for example to a
CPU with an AMBA AHB protocol.(ii)The X-bus interfaces
support cacheable and non-cacheable instruction and data
traffic between a CPU and the memories and register
interfaces of other targets[1].

Figure1. Simple H bus signal processing

The scope of the research is that for understanding the
OCP Bus bridge compliant system and also a processor
interface system, a model is needed. Hence a Bus Bridge
system with a Processor as the OCP Master and I2C
controller as the OCP Slave is designed.
The system includes an OCP compliant Processor and a
I2C controller where the Processor acts as the OCP master
and I2C controller as the OCP Slave. This paper discusses
the Peripheral OCP profile with Simple Write and Read
transfer and Generic OCP profile with data handshaking [2].
The Master gives Requests and accepts responses. The slave
receives and responds to the Requests provided by the
master. Bus Bridge act as both a master and slave on the
internal SoC interconnect. The master sent the bus traffic to
the desired location and the slave WRITEs or READS the
bus bridge internal control or status registers. Handshake
signals are provided for both Master and Slave which
indicates acknowledgements. The processor designed with
OCP master is interfaced with the I2C controller that gives
the output to serial I2C buses.

IV. IMPLEMENTED SYSTEM
The proposed system is tested under 32-bit data bus and
32-bit address bus without the burst transfer for processor
and 8- bit data and 8 bit address for I2C .

Figure2. Block Schematic of the Design Implemented

The I2C controller will respond to the master signal
from processor and give the serial 2 wire output SDA and
SCL.During write operation the master starts a request
phase by switching its command field to write and presents
a valid data and address. The slave accepts the command
and captures data and address and a write is performed
according to the design. The master starts a Read request by
switching its command field to Read. It presents a valid
address and slave accepts the command. The slave captures
data from the specified the address and is driven to the
Master. The response is also given to master to indicate that
the data is valid. There is no change in the designs of
Processor and I2C controller when OCP wrapper is
introduced. The wrapper covers the existing designs to make
them OCP compliant. The proposed system is
parameterizable for both address and data.
A. Processor without OCP
Processor is the Master of the interface whose address and
data are mapped to the I2C Controller which gives the I2C
bus protocol. A multicycle MIPS processor with 32 bit
address and 32 bit data is designed as the Master, allows a
functional unit to be used more than once per instruction [7].
TABLE I. DESIGN PARAMETERS OF PROCESSOR
Design Parameter

Size(in bits)

Address 32
Data 32
Instruction 32

B. I2C controller without OCP
An I2C controller is designed as the slave in the
interface. The data is transferred in I2C bus synchronously




622
to SCL on the SDA line on a byte-by-byte basis. Each data
byte is 8 bits long. There is one SCL clock pulse for each
data bit with the MSB being transmitted first. The device is
recognized by a unique address. An acknowledgement bit
follows each transferred byte. The slave address for I2C
slave, the address and data to be written and read are
obtained from the master. The informations are carried by
the I2C serial buses SDA, SCL according to the I2C bus
protocol [3].
TABLE II. DESIGN PARAMETERS OF I2C CONTROLLER
Design Parameter

Size(in bits)

Address 8
Data 8
C. OCP complaint processor
The processor is reconfigurable. This processor is
configured with OCP which contains the basic OCP signals
and will serve as an OCP master.OCP Master command is
for Transfer command and this 3-bit signal indicates the
type of OCP transfer the master is requesting. Each non-idle
command is either a read or write-type request, depending
on the direction of data flow. According to the Master
command the slave will be either written into or read from
[1].

D. OCP complaint I2C controller
I2C controller is the slave which responds to the
transfer requests provided by the master. I2C controller is
configured with contains the basic OCP signals and will acts
as an OCP slave. The response signals will be sending back
to the master [1].

E. OCP Compliant Bus Bridge Interface
The entire system acts as an OCP-I2C bus bridge
for interface. The design covers peripheral profile with
simple read and write and Generic profile with data
handshaking [2].
V. EXPERIMENTAL OBSERVATIONS AND RESULTS
A. Design Setup
The test set up for the implementation is given in the
table below.
TABLE III SET UP SUMMARY
Design method VHDL based behavioral modeling
Verification Platform Modelsim 6.2C
Synthesis platform Xilinx ISE 10.1
Hardware Platform Xilinx Vertex 5
B. Simulation Results
Simulation output is shown for simple Bus Bridge
Interface System. The simulation is done for 1000 ns.


Figure3. Simulation Results.
Simulation results show that the signals are sampled at
the rising edge of the clock signal (clk).OCP defines active
low resets (reset_n). The MCmd signal (Master Command)
is the output of the processor signal. When MCmd is is 000
it is the idle state. When MCmd is 001 data and the address
to be written is sent to SDA of I2C bus. When MCmd is 010
the address of the data to be read from is sent to SDA.
C. Synthesis Results
The design is synthesized using Xilinx ISE 10.1. The
hardware platform is Xilinx Vertex 5 for the designs. The
master, slave and the interface were synthesized with and
without OCP.
The high level synthesis report of the bridge architectures
depicted below.
TABLE IV DEVICE UTILIZATION FOR I2C CONTROLLER

Logic Unit

Used

Available

Utilization

Number of
Slice
Registers

With OCP

50

19200

0%

Without OCP

44

19200

0%


Number of
Slice LUTs

With OCP

84

19200

0%

Without OCP

61

19200

0%


Number of
GCLKs

With OCP

1

32

3%

Without OCP

1

32

3%
The timing analysis of I2C controller is shown in the table
below.

623
TABLE V TIMING ANALYSIS OF I2C CONTROLLER
Quantity Value

Minimum period
Without OCP 2.001 ns
With OCP 1.900 ns

Maximum Frequency
Without OCP 499.725MHz
With OCP 526.288MHz
The high level synthesis report of Processor is depicted
below.
TABLE VI DEVICE UTILIZATION FOR PROCESSOR


Logic Unit

Used

Available

Utilization

Number of
Slices
Registers

With OCP

17004

19200

88%

Without OCP

16971

19200

88%

Number of
Slice LUTs

With OCP

19990

19200

100%

Without OCP

19900

19200

100%

Number of
GCLKs

With OCP

7

32

21%

Without OCP

6

32

18%

The timing analysis of the Processor with and without OCP
is shown in the table.

TABLE VII TIMING ANALYSIS OF PROCESSOR
.
The Table below shows the high level synthesis reports of
the bridge interface system.





TABLE VIII DEVICE UTILIZATION FOR BUSBRIDGE INTERFACE


Logic Unit

Used

Available

Utilization

Number of
Slices
Registers

With OCP

17033

19200

88%

Without OCP

16998

19200

88%


Number of
Slice LUTs

With OCP

19994

19200

100%

Without OCP

19890

19200

100%


Number of
GCLKs

With OCP

7

32

21%

Without OCP

6

32

18%

The timing analysis of the Bus bridge interface with and
without OCP is shown in the table.
TABLE IX TIMING ANALYSIS OF BRIDGE INTERFACE

Comparing the timing analysis of the designs with and
without wrapper it is clear that there is only a small
variation in the speed of operation with the use of OCP.
Synthesis report shows that the device utilization is better
for OCP compliant designs.

VI. FUTURE PLANS
The bus bridge interface system using processor and I2C
covers the peripheral and generic profiles without burst of
the OCP interface. Generic profile with Burst transfer and
High Performance profile with Tag support for out of order
responses has to be designed which makes the system more
efficient. The burst transfer is not possible for I2C bus so
several other bus protocols with high performance have to
be incorporated in the research. More prominent future
designs may extend in analyzing the aspects of designing
the high level OCP interfaces like processor interface and
bus bridge interface.
Quantity Value

Minimum period
Without OCP 1.061 ns
With OCP 1.061 ns

Maximum Frequency
Without OCP 942.774 MHz
With OCP 942.774 MHz
Quantity Value

Minimum period
Without OCP 2.217ns
With OCP 2.238 ns

Maximum Frequency
Without OCP 450.979 MHz
With OCP 446.867 MHz
624
VII. CONCLUSION
This paper presents a parameterizable and reconfigurable
OCP compliant bus bridge interface and processor interface
system specifically targeted to use with high speed
applications. The primary trigger to the development of such
design is the lack of availability of a common interface that
can be used with the different IP cores in a SoC design. In a
SoC the different IP cores are interfaced through different
protocols. It increases the complexity of the design. If there
is a common interface which supports all the needs of a
current day SoC design then it offers IP core reusability and
reduces the complexity. In this sense OCP provides a
common platform for all the IP cores and offers IP core
reusability. This paper also concentrates on enhancing the
processor interface.
REFERENCES
[1] Open Core Protocol Specification 3.0, International Partnership,
2000- 2009 OCP-IP Association, Document Revision 1.0.
[2] Chih-Wea Wang, Chi-Shao Lai, Chi-Feng Wu, Shih-Arn Hwang, and
Ying-Hsi Lin, On-chip Interconnection Design and SoC Integration
with OCP, Proceedings of VLSI-DAT, 2008, pp. 25 28, April
2008.
[3] The I2C Specification version 2.1
[4] www.i2c-bus.org
[5] OCP-IP, Open core protocol international partnership,
http://www.ocpip.org/, 2007.
[6] JamesAldis,Use of OCP in OMAP 2420
http://www.ocpip.org/,2005.
[7] www.mips.com,Computer Architecture and Engineering,
Lecture 8 ,Designing a Multicycle Processor.
[8] David A. Patterson, John L.Hennessy, Computer Organization and
Design,Third Edition,Morgan Kaufmann Publishers, pp.318-339.
[9] Shihua Zhang, Asif Iqbal Ahmed and Otmane Ait Mohamed, A Re-
usable verification Framework of Open Core Protocol, Circuits and
Systems and TAISA Conference, 2009, pp. 1-4, june 28,2009.
[10] W.-D. Weber, Enabling reuse via an IP core-centric communications
Protocol, In Proc. IP 2000 System-on-Chip Conference, pages 217-
224, Mar 2000.
[11] Prashant D. Karandikar, Open Core Protocol ( OCP ) An
Introduction to Interface Specification, 1
st
Workshop on SoC
Architecture, Accelerators & Workloads Jan 10 2010.
[12] Chien-Chun (Joe) Chou, Konstantinos Aisopos, David Lau, Yasuhiko
Kurosawa and D. N. (Jay) Jayasimha, Using OCP and Coherence
Extensions to Support System-Level Cache Coherence, Technical
Paper, pg. nos.10, April 2009.






625