International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
A Proficient and Secured System On-Chip Bus Protocol with
OCP Interface
V.likitha, R.Ravi kumar*
#
#
Final Year B.Tech, Dept. of ECE, KL University, Vaddeswaram, AP, India
*
Associate Professor B.Tech, Dept. of ECE, KL University, Vaddeswaram, AP, India
Address
ABSTRACT:
The implementation of a massive scale SoC (Systemon-chip) is becoming increasingly difficult task not
only because of its complexity, but also the design of
a more amount of IP addresses. A consensusinterface protocol for IP-cores are still significant
even and predictable for a successful establishment
SoC. OCP, with his frankness, coordinated, not-forprofit nature, and the inherent large industry
membership, is quickly becoming a viable and
preferable solution over a narrow or an in-house
standard. In this project, well-defined interface
standard, the Open Core Protocol (OCP), and focus
on the design of the internal bus architecture. We
develop an efficient bus architecture to the most
advanced bus features defined in OCP, including
burst transactions, lock transactions, pipelined
transactions, and support. Out-of-order transactions
on-chip bus transaction level modeling to treat the
design flexibility and fast simulation speed is
proposed in this project.
Keywords: Soc, O.C.P, AMBA, AXI
of data communication between the cores increase
significantly. Consequently, the capacity of on-chip
buses to cope with the large amount of data traffic is
a dominant factor for the performance. The design of
the on-chip buses can be divided into two parts: bus
interface and bus architecture. The bus interface is a
set of interface signals and their timing relationship,
while the bus architecture refers to the internal
components of the buses and the interconnections
between IP cores. The generally accepted on-chip
bus, AMBA AHB [1], defines to facilitate basic
(single) and burst read / write operations. A set of bus
interface AHB also determines the internal bus
architecture, which is mainly composed of a shared
bus multiplexors. The multiplexer-based bus
architecture works well for a design with a small
number of IP cores. When the number of integrated
IP cores increases, the communication between the
IP-cores also increase and it is very common for two
or more master-IP's would ask the same time. Data
from different slaves The shared bus architecture
often can not provide an efficient communication. By
comparing with previous now we can get
acknowledgement for every time when we can send
data since only one bus transaction can support
simultaneously.
I. INTRODUCTION
As more and more IP cores, included in a SOC
design, the flow of communication between IP cores
drastically increased, and the efficiency of the onchip bus is a dominant factor for the performance of
the system.
A SOC chip usually contains a large number of IP
cores that communicate with each other via on-chip
buses. Since the VLSI process technology
continuously advances, the frequency and the amount
ISSN: 2231-5381
To solve this problem, two bus protocols recently
proposed. One is the advanced protocol Extensible
Interface (AXI) proposed by the ARM company.
AXI defines five independent channels (write
address, write data, write response, read address, and
read data channels). Each channel includes a series of
signals. AXI is the internal bus architecture is not
limited and leave it to designers. Thus, designers can
two IP cores with AXI integration between direct
wire connection or by profession an internal bus. The
other bus interface protocol is represented by a non-
http://www.ijettjournal.org
Page 1543
International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
profit organization, the Open Core Protocol International Partnership (OCP-IP) [2]. OCP is an
interface (or bus) aims to standardize and simplify so.
System integration problems It facilitates system
integration through a series of concrete interface (I /
O signals and handshaking) which is independent of
the bus architecture. Based on this interface IP core
designers can concentrate on designing the internal
functionality of IP cores, bus designers to focus on
the internal bus architecture, and system integrators
can focus on system issues such as the requirement of
bandwidth and the entire system architecture. For
example, system integration is much more efficient.
Most of the bus functionalities defined in AXI and
OCP are quite similar. The most obvious difference
between them is that divides the AXI address channel
independent channel write address and read address
channel such that read and write transactions can be
processed simultaneously. However, the additional
area of the channels separately address the
punishment. Some previous work has examined onchip buses of various aspects. The work in [3] and [4]
develops high-level AMBA bus models with fast
simulation speed and high accuracy of the timing.
The authors in [7] propose an automatic approach to
generate high-level bus models from a formal
channel model of OCP. In both of the above work,
the authors focus on fast and accurate simulation high
level, but gave no real hardware implementation
details. In [9], the authors implement the AXI
interface on the shared bus architecture. Even though
it costs less in area, the advantage of AXI in
communication efficiency are limited by the shared
bus architecture.
In this article we present a powerful on-chip bus
design with OCP as bus interface. We choose OCP
because it is open to the public and the OCP-IP has
some free tools to check this Protocol. Our proposed
bus architecture is characterized lat / partial crossbarbased interconnect and realizes most transactions
within the meaning of OCP, including 1) some
transactions, 2) burst transactions, 3) lock
transactions, 4) pipelined transactions, and 5) out-of order transactions. Moreover, the proposed bus is so
flexible that the bus architecture can adapt to the
system requirements.
ISSN: 2231-5381
The rest of this paper is as follows. Section 2The
various advanced functionalities on-chip buses are
described. Section 3 describes the operation of the
OCP Block Diagram. Chapter 4 presents the
implementation of OCP master / slave FSM. Section
5 experimental results show that the efficiency of
both simulation speed and data communications.
Conclusions are then drawn in Section 6.
II. ON-CHIP BUS FUNCTIONALITY
The different functionalities bus contains
1) Burst
2) Lock
3) pipeline and
4) Out-of-Order transactions.
• Burst transactions
The burst operations, the combination of multiple
transactions that address a particular relationship, and
can be divided into multi-application single-burst and
burst request depending on how often the addresses
are issued. Figure 1 shows the two types of burst read
transactions. The multi-burst request as defined in
AHB is illustrated in Figure 1 (a) where the address
must be issued for each order of a burst transaction
(eg, A11, A12, A13 and A14). This may cause some
unnecessary overhead. In the more advanced bus
architecture, is the single-burst request transaction is
supported. As shown in Figure 1 (b), which is defined
by the type of burst AXI is given once the address
information is output each burst transaction. In our
proposal we support both bus design burst
transactions such that IP cores with different types of
bursting the proposed on-chip bus can be used
without change. Their initial burst behavior
http://www.ijettjournal.org
Page 1544
International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
• Lock transactions
illustrated in Figure 3.In Figure 3 (a) which does not
allow out-of-order transactions, the corresponding
reactions of A21 and A31must are back after the
reaction of the A11. With the support of the out-oforder transactions, as shown in Figure 3 (b), the
reaction with reduced access latency (D21, D22 and
D31) may be returned before those with longer
latency (D11-D14) and thus the transactions can be
completed. into fewer cycles
Lock is a protection for bus masters that have low
priorities. Without this mechanism, the read / write
operations of the masters with lower priority would
be interrupted if a higher priority master has
requested. Lock transactions prevent an arbitrator of
performing arbitration and ensure that the lowpriority masters are given transaction can be
completed without being interrupted.
Figure3. Out-of-order transactions
Figure 1. Burst transactions
• Pipelined transactions
Figure 2 (a) and 2 (b) show the difference between
the non-pipeline and pipeline (also excellent in AXI)
read transactions. In Figure 2 (a), for a non-pipelined
operation is a read data is to be returned after the
corresponding address is delivered plus a latency
period. For example, D21 A21 shipped immediately
after delivery plus t. For a pipelined operation as
shown in Figure 2 (b), this rigid coupling is not
required. Thus A21 may be issued shall be issued
without waiting for the return of the information
requested by the A11 (ie, D11-D14) data.
Immediately after A11
The architecture of the proposed on-chip bus is
illustrated in Figure 4, we show an example where
four four masters and slaves. A shot architecture, so
that more than one master simultaneously
communicate with more than one slave applied. If not
all masters require the access paths to all slaves, is
partial crossbar architecture also allowed. The main
streets of the proposed bus architecture are described
below.
• Arbiter
In the traditional shared bus architecture, resource
contention occurs when more than one master may
request the bus at the same time. For a cross-beam or
partial crossbar architecture, resources conflict arises
when there is more than one master is to provide
concurrent access to the same slave. In the proposed
design each slave IP is associated with an arbitrator
that determines which master can access the slave.
The arbitrator sends signal to grant the requested
master.
Figure 2. Pipeline transactions
• Out-of-order transactions
The out-of-order transactions may be different from
the order of their request the return sequence of
reactions. These operations can significantly improve
the communication efficiency of a SOC system with
IP cores with different access latencies, such as
ISSN: 2231-5381
III. Functional blocks OCP THE BUS
• Decoder
http://www.ijettjournal.org
Page 1545
International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
For more than a slave exists in the system, the
decoder decodes the address and decides which slave
return response to the target master. Moreover, the
proposed decoder also checks whether the transaction
address is illegal or nonexistent and reactions with an
error message if necessary.
• Multiplexer
A multiplexer is used to solve the problem of
resource contention when multiple answers to the
same slave master. It selects the corresponding slave /
master according to the specified selection lines.
There are one multiplexers and address mux control
and two are for data reading and writing.
• Master / Slave
Master and Slave are the entities from different
Address and Data Locations. Only the master can
send the commands and is the controlling entity. The
Slave responds to commands presented to it, either by
accepting data from the master, or that data to the
master.
• FSM-FSM-M & S
FIGURE 4. OCP Block Diagram
FSM-M serves as a general and generates the OCP
signals from a master, while FSM-S acts as a slave
and generates that of a slave.
IV. IMPLEMENTATION OF OCP
The request is given to slave by MCMD signal
through the system. In Write operation, the input
address and the data from the system will be given to
the slave signal maddr and MData and when that
information will be accepted, slave signal that causes
the system to issue subsequent application give
SCmdAccept. During the read operation, the system
will request
and address to slave which will enable SResp and
remove the associated data that is given to the output
via Sdata.The design of the Open Core Protocol
begins with the first study which the development of
the
FSM (Finite State Machine) for the various support
operation after developing VHDL FSM.
FSM for OCP master: The Finite State Machine
(FSM) was developed for the simple read and write
operation of OCP Master. The simple writing and
reading operation indicates that the control goes to
idle after every operation. In principle, the operation
will be held in two stages. Into the OCP
• Phase Request
• Response Phase
Initially, the control will be in IDLE state (control =
"000") showing all exits, as MCMD, maddr and
MData are set to "do not care". The system will the
ISSN: 2231-5381
http://www.ijettjournal.org
Page 1546
International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
request to the master such that write request to the
WRITE state (control = "001"). In this state, the
address and the data to the slave that is to be written,
and thus the process will be given as to when the
SCmdAccept is asserted high. SCmdAccept If not
set, it means that the write operation will still be in
process and control in the WRITE state itself. Once
the write operation is then the control goes to the
IDLE state and then it will check for the next request.
corresponding memory address location is controlled
by the masters go. Once the write operation is
complete, the SCmdAccept signal to high and given
to the master. When MCMD is given as a read
request, then the control goes to the READ state in
which the data from the specific memory address
location that is given by the master will be read.
Hence the SCmdAccept is set to high and the SResp
is set to the DVA representing that reading about
operation and control goes to the IDLE state.
Depending on whether a transaction is a read or write
operation, the request and response processes are
different. So for burst, burst count is specified that
burst size for both reading and writing.
Figure 5: FSM for OCP master
When the read request is made, the control to the
READ state (control = "010") and send it to the slave
who in turn gives the SCmdAccept signal that the
request phase ends the address. Once the
SCmdAccept is set and SResp is not the data is valid
(DVA), the control of the WAIT state will go and
wait for the signal SResp. When the read operation
beyond that represents the SResp is set to DVA and
the data for the corresponding address is taken.
Hence the SResp signal ends the response phase and
the control will go IDLE state, then checks for the
next request.
FSM for OCP slave: the FSM for the OCP Slave
which is simple write and read operation has been
developed and is shown in the Figure 6
FIGURE 7. Burst transaction
FIGURE 6. fsm for ocp slave
The slave is set to the appropriate state based on the
MCMD issued by the master and the slave output of
this is that the SCmdAccept and SResp. Initially
check will be in the IDLE state and when the master
contract as write request, and then control the
WRITE state in which the data is written to the
ISSN: 2231-5381
http://www.ijettjournal.org
Page 1547
International Journal of Engineering Trends and Technology (IJETT) - Volume4Issue5- May 2013
[4] James Aldis, “Use of OCP in OMAP 2420”,
http://www.ocpip.org/, 2005.
FIGURE 8. Out-of-Order transaction
being performed and the basic commands and how it
can be identified on the basis of which the signal
flow diagram and specifications are developed for the
design of the OCP using VHDL. Cores with OCP
interfaces and OCP interconnect systems enable true
modular, plug-and-play integration. The simulation
result shows that the communication between
different IP cores with OCP is appropriate. On the
basis of the result obtained, the burst extension as
seen to automate the address generation. Only the
first address is delivered to the protocol. We can
check errors easily by comparing with previous work
V. RESULTS
The proposed design is coded in VHDL language and
simulated using Xilinx ISE tool. The simulated
waveforms for burst operations in Figure 7, and out
of order operations in Figure 8 will be displayed. The
pipeline system is also apparent from both the results.
VI. CONCLUSION
This project work presents the OCP (Open Core
Protocol) design that acts as an interface between two
different IP cores. In this work, initially the research
in the OCP
[5] G. Schirner and R. Domer, “Quantitative Analysis
of Transaction Level Models for the AMBA Bus,”
Design, Automation, and Test in Europe, 6 pages,
2006.
[6] David C.-W. Chang, I.-T. Liao, J.-K. Lee, W.-F.
Chen, S.-Y. Tseng and C.-W. Jen, “PAC DSP Core
and
Application
Processors,”
International
Conference on Multimedia and
Expo, pages 289-292, 2006.
[7] Partha Pratim Pande, Cristian Grecu, Michael
Jones, Andr´e vanov, and Resve Saleh, “Performance
evaluation and design trade-offs for network-on-chip
interconnect architectures”, IEEE Trans. Computers,
vol. 54, no. 8, pp. 1025–1040, Aug. 2005.
[8] IBM Corporation, “Prioritization of Out-of-Order
Data Transfers on Shared Data Bus,” US Patent No.
7,392,353, 2008.
[9] N.Y.-C. Chang, Y.-Z. Liao and T.-S. Chang,
“Analysis of Shared-link AXI,” IET Computers &
Digital Techniques, Volume 3, Issue 4, pages 373383, 2009.
V. likitha:
REFERENCES
[1] Advanced Microcontroller Bus Architecture
(AMBA) Specification Rev
2.0
& 3.0,
ttp://www.arm.com.
[2] Open Core Protocol (OCP) Specification,
http://www.ocpip.org/home.
R. Ravi Kumar:
[3] Y.-T. Kim, T. Kim, Y. Kim, C. Shin, E.-Y.
Chung, K.-M. Choi, J.-T. Kong, S.-K. Eo, “Fast and
Accurate Transaction Level Modeling of an Extended
AMBA2.0 Bus Architecture,”
Design, Automation, and Test in Europe, pages 138139, 2005.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 1548