Design and PSL Verification of SoC Interconnect Using Open Core Protocol (OCP)

International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013
ISSN: 2231-2803 http://www.ijcttjournal.org Page 3292

Design and PSL Verification of SoC Interconnect Using Open
Core Protocol (OCP)
Naga Prasad Reddy.T*1, Avinash.K*2

ABSTRACT
Bus protocols have been of much importance in
the field of System on Chip (SoC) design. As SoC's
mostly being an integration of different
Intellectual Property (IP) blocks, core
communications are handled using proprietary
or non- proprietary bus protocols such as AXI and
OCP. These bus protocols native to an IP core vary
with the native bus protocol of other IPs.
Further bus bridges clear the incompatibilities for
communication between IP cores. Hence these bus
protocols or SoC interconnects ensure a proper
communication between the IP cores in a SoC.
In this project OCP protocol (master and
slave) is designed and a communication between
two different bus protocols, AXI master (an ARM
proprietary high-performance, high-frequency bus
protocol) and OCP slave (a non-proprietary,
openly licensed high performance bus independent
protocol) has been established using a OCP
complaint bus bridge. It includes developing FSM's
for OCP and AXI profiles such as simple, burst,
pipelined, and tagged read-write transactions. The
developed FSMs were implemented using VHDL.
By understanding the signal set of these protocols, a
bus bridge has been developed for necessary signal
conversion. Finally the bus bridge has been verified
using property specification language (PSL)
assertions.
The developed test benches ensured that the test
setup comprising AXI master, OCP complaint Bus
Bridge, OCP slave and memory are functioning
properly. The simulation results were analyzed for
the functional failures. Further different scenarios
for the operation of AXI, OCP and OCP complaint
Bus Bridge are identified. These scenarios have been
verified by writing 72 PSL properties. It was
observed that the AXI-OCP bus bridge has
established a proper communication channel between
AXI and OCP protocols with all the AXI requests
processed by the OCP slave through OCP
complaint Bus Bridge.
KEYWORDS: Low drop out, quiescent current,
settling time, Line Regulation and Load Regulation
I.INTRODUCTION
With the increasing complexity of modern
System-on-Chip (SoC) designs, more and more
intellectual property (IP) blocks will be integrated
into a chip. The core communications are
handled by bus protocols of IPs. A bus protocol
works on a bus request - grant mechanism, which
establishes on-chip interconnections and improves
SoC integration. If bus protocols of IPs vary,
then the master, slave functionality of one other
doesn't match. This will be taken care by a bridge
that does a protocol conversion. A bus bridge will
have protocol complaint of any or both IPs based
on the communication flow (single or bi-
directional) between the IPs.
This work is to implement OCP for various
profiles and to connect two OCP complaint cores,
one acting as an initiator and the other as the
target. The project also includes connecting or
creating a compatible communication link
between two cores having different protocol
complaints, one being an AXI complaint core
(initiator) and the other being an OCP
complaint core (target). Verification f or the
designed units is carried out using PSL assertions.
The main job in SoC design lies in integrating the
IPs of different vendors. The interconnections
between IPs will be done by understanding the
requirements of the communicating cores. Each
time a SoC is built, the system integrator will
have to rework in integrating the IPs. Hence a
requirement arises for a standard like OCP
which defines a common interface and
communication protocol between IP cores and
system-on-chip interconnects. Such a standard
allows IP core developers develop an IP to a
known standard, which need not require any
knowledge on the application it is being used.
OCP being an open protocol is well encouraged
by many core developers and system integrators,

thereby implementation of SoC interconnect using
OCP is worthy.
1.1 Need for Project
into a chip. An open, non-profit and configurable
standard protocol like OCP for IP core
interface is quickly becoming necessary for
efficient on-chip interconnection desi gn and
SoC integration. Even in case if native protocols of
IP cores vary, an OCP complaint bus bridges will
clear the incompatibilities between IP cores.
Hence a SoC interconnect implemented using
OCP will serve the communication between
any two IP Cores

Figure 1 General SoC Architecture with OCP
based Interconnects
The innovation in semiconductor technology gave
rise to more and more complex SoC designs. Today's
SoC with IPs can perform various functionalities
such as communication, networking, multimedia,
storage. SoC's found their applications in devices
like mobile phones, digital media players, digital
TVs. Figure 1 shows such an SoC architecture that
has contains various IPs like USB, LCD, CCD,
UART, PCIe, DMA etc., and the OCP based
Interconnects that connect any two IPs.
Depending on the functionality an IP core acts as an
initiator (CPU, DSP etc) or a target (RAM,
Peripherals etc). The initiator has an OCP master and
the target will have an OCP slave and the
communication happens through request-grant
mechanism.

1.2 SoC Interconnect using OCP
Figure 2 shows the basic block diagram for open
core protocol (OCP) with one core having an
OCP Complaint (Master) and the other core having
an OCP Complaint (Slave). The OCP master
either starts a read or write request by presenting a
request command on the 'request' line to the slave.
With the request command the master also presents
the request information on the 'data' lines to the
slave. The slave accepts the master request and
sends an acknowledge signal by registering the
request information. Internally the slave presents
the request to the CORE 2 and waits for the
response from it. Once the request is processed
from the CORE 2, the slave sends the response
status and response information to the master
through the 'response' and 'data' lines.

Figure 2 OCP Block Diagram

Figure 3 shows the bus bridge with an OCP
complaint for transferring the AXI transactions to
legal OCP transactions.
The AXI Compl aint (Master) i n CORE 1
generates t h e r equest s and presents it to the bus
bridge through the 'request' and 'data' lines. The
bus bridge accepts the AXI requests and presents
it to the OCP Complaint (Master) in it. The
OCP master generates the valid OCP requests.
These OCP request commands and its
information are presented to the to the CORE 2
OCP slave by the bus bridge through the request
and data lines. The OCP slave accepts the
requests and presents back the response status and
response information through the 'response' and
'data' lines. The bus bridge accepts the OCP
response signals and transforms them to valid
AXI response signals. This way the OCP
complaint bus bridge creates an efficient
communication between two protocols.

Figure 3 Bus Bridge with OCP Compliant

1.3 Advanced Extensible Interface Protocol
The AMBA AXI protocol is targeted at high-
performance, high-frequency system designs and
includes a number of features that make it suitable
for a high-speed submicron interconnects. Every
AXI transaction includes address and control
information. The data is transferred between
master and slave using a write data channel to the
slave or a read data channel to the master.

Figure 4 AXI Bus Architecture
AXI has five independent channels consisting of
a set of information signals and a two-way
VALID and READY handshake mechanism for
exchanging information between sender and
receiver. On the other hand being a data transfer
protocol, AXI have signal extensions for low power
operations. Figure 4 shows AXI bus architecture
with the five channels that are used for write and
read transfers. For the write request, the write
address channel, write data channels are used. For
Read request, the Read address channel is used.
For write response, the write response channel is
used. For Read response, Read Data channel is
used. Each write request is acknowledged with
AWREADY, WREADY signals a n d e a c h
r e a d r e q u e s t i s a c k n o wl e d g e d with
a n ARREADY signal by the slave. In the same
way the master acknowledges the write response
with BREADY signal and read response with
RREADY signal.
II.PROBLEM DEFINITION
into a chip. An open, non-profit, and configurable
standard protocol like OCP for IP core
interface is quickly becoming necessary for
efficient on-chip interconnection desi gn and
SoC integration. Even in case if native protocols of
IP cores vary, an OCP complaint bus bridges will
clear the incompatibilities bet ween IP cores.
Hence a SoC interconnect implemented using
OCP will serve the communication between any
two IP Cores.
III.METHODOLOGY
Literature study on open core protocol, signals,
timing diagrams, FSMs has been carried out by
referring specifications and related documents. The
FSMs for the OCP Master and OCP Slave has
been developed based on the reviewed literature.
Using FSMs, the OCP with basic signals has
been modeled in VHDL. The modeled OCP has
been modified to accommodate various signal
profiles. Suitable test vectors has been
identified based on the timing diagram from
reviewed literature. Verification of OCP has
been performed using identified test vectors in
ModelSim. FSMs for AXI profiles has been
identified and developed in VHDL. A SoC
interconnect between AXI and OCP using bus
bridge is developed, Functionality of the SoC
interconnect between AXI and OCP is verified
using PSL assertion verification methodology.

IV. DESIGN AND IMPLEMENTATION
The protocol specification defines the timing
diagrams for a particular profile and the required
protocol signals for the profile operation. The
FSMs are identified from the timing diagrams.
Implementation of FSMs is done using VHDL.
The OCP FSMs for simple, burst, pipeline and
tags are explained. Similarly, AXI FSMs for
simple and tags are explained.


4.1 Design of OCP
4.1.1 Open Core Protocol

The Open Core Protocol (OCP) is a non-
profit, openly licensed, core- centric protocol that
has a capability of describing integration
requirements of intellectual property (IP) cores in
SoC. OCP in addition to managing the data
flow between IP cores, it unifies all inter-core
communications like sideband control and test
signals. Therefore OCP provides a high-
performance, bus-independent interface between
IP cores reducing design time, design risk, and
manufacturing costs for SOC designs.
An established point-to-point interface between
any two IP cores and bus interface module will
have one of the two IP cores acting as an OCP
master and the other acts as the OCP slave. The
Master initiates the commands and the slave
responds to it by accepting data from the master
(for write), or presenting data to the master (for
read).
Here the system initiator as an OCP master
issues a command and its relevant request
information to the connected slave (Bus initiator).
The command request is placed across the on-
chip bus system. The system target (OCP
slave) receives the command and takes the
requested action.
4.1.2 OCP Design Specification

The OCP signal specifications are provided in
the Table 1. The data has been sampled using
1OOMHz clock. The discussed signal set for
various profiles basic, burst and tag are shown in
Table 1.
Table 1 OCP Design Specifications

4.1.3 OCP Signal Descriptions
OCP Basic Signals
The basic signals include master signals write/read
address (MAddr), command (MCmd), write data
(MData), and slave signals acknowledgement
(SCmdAccept), response (SResp), response data
(SData). The configurable width for a signal
depends on the connected core requirement. The
three bit MCmd will carry request command
information such as Idle, Write, Read, ReadEx,
Read Linked, WriteNonPost, WriteConditional
and Broadcast. The two bit SResp will carry the
response status information such as NULL, DVA,
FAIL and ERR. The basic signals are primary
signals for building a simple OCP master-slave
unit.
4.1.4 OCP Burst Extensions
Each IP core support burst to achieve high
transfer efficiency. The burst request information
is carried with the OCP burst extension
signals, which include number of burst
transfers (MBurstLength), precise/imprecise
type of burst transfer (MBurstPrecise), address
sequence for burst requests (MBurstSeq), last
request indication for the burst (MReqLast), and
last response indication for the burst request
(SRespLast). A precise type of burst
(MBurstPrecise = '1') indicates that the total
number of transfers or burst length is constant
throughout the burst and an imprecise burst
type (MBurstPrecise = '0') indicates that the
number of transfers keeps varying through the
burst. For an imprecise burst the burst transfer
ends when the master places the burst length
'one'. The MBurstSequence indicates the address
sequence during the burst such as incrementing
address, wrapping address, exclusive or and
streaming address.
4.1.5 OCP Tag Extensions
Tags will used for controlling out of order
responses. The OCP tag extensions includes
request tag ID (MTagID) and response tag ID
(STagID). The master generates the tag ID for a
request and in return the slave sends the response
associating the same tag ID.
4.1.6 Simple Read - Write Operation
OCP Master
Figure 5 shows the FSM for simple read-write
operation of OCP Master. The operations of
OCP Master FSM are

The master remains in IDLE state until there is
a request. Being in IDLE state, master moves to
WRITE state on write request and READ state
on read request. In IDLE state it assigns MCMD
= "000" and doesn't present any data and address
on MDATA, ADDR signal lines.
The master presents data on MDATA, address
on ADDR and sets MCMD = "001" in
WRITE state and remains in the same
state until it gets an acknowledgement signal,
CMDACCEPT from slave. On
CMDACCEPT the master will move from
WRITE state to IDLE state. This completes the
write operation.
The master presents address on ADDR and sets
MCMD = "010" in READ state and remains in
the same state until it gets an
acknowledgement signal, CMDACCEPT from
slave. On CMDACCEPT and no response
signal RESP = "00" the master will move to
WAITR (wait for response RESP) state. On
CMDACCEPT and RESP = "01" the master will
move to the IDLE state.
The master remains in the WAITR state until
RESP = "01" and moves to the IDLE state when
RESP = "01". This completes the read operation.

Figure 5 FSM for OCP Master, Slave to
handle Simple Read-Write

OCP Slave
Figure 5 shows the FSM for simple read-write
operation of OCP Slave. The operations of OCP
Slave FSM are
The Slave remains in the IDLE state till MCMD
is "000". Slave moves to WRITE state if MCMD
= "001" and to READ state if MCMD = "010".
In this state it sets CMDACCEPT to '0', RESP
to "00" and doesn't present any response data
on SDATA.
In WRITE state Slave asserts CMDACCEPT
and goes backs to IDLE state. Since write
operation doesn't have any response, response data
SDATA will be null and RESP will be "00".
In READ state Slave asserts CMDACCEPT and
goes back to the IDLE state when 'resp_val"
signal is '1'. If "resp_val" is '0' slave goes to
WAITR state (wait for resp_val). Being in READ
state, slave sets RESP to "01" and presents
SDATA if "resp_val" is '1' else RESP = "00",
SDATA to null.
In WAITR state slave remains in the same state
till "resp_val" is '0' and goes to IDLE state when
"resp_val" is '1'. Being in WAITR state, slave
sets RESP to "01" and presents SDATA if
"resp_val" is '1' else RESP = "00", SDATA to
null.

Figure 6 Test Setup for OCP
4.1.7 Simulation Result for Simple Read - Write
Operation
The broad level test setup for functionally
verifying the OCP Master - Slave units is
shown in the Figure 6. The top level RTL for
OCP is shown in the Appendix A. OCP Master
gets requests from the test bench. The master
presents the requests to the slave and the slave
performs a write or read request on the memory.
For simple read - write operation the test bench
drives in the signals wreq, rreq, mdatain, and
maddrin. The simulation results are shown in the
Figure 7. First there is a write request to address
'8' with data '14'. The master presented the write
command, data, and address to the slave. The
slave has responded by asserting the
CMDACCEPT. The master has moved back to

IDLE state. Later similarly another write was
done to address '24' with data '28'. After this
read requests, to fetch data from address '8' and
'24' are made. The data fetched was '14' from
'8' and '28' from '24', which is nothing but the
same data that is written previously. This shows a
functional write read operation.

Figure 7 Simulation Result: OCP Simple Read
- Write Operation
4.2 Design of AXI IP
4.2.1 AXI Protocol
The AMBA AXI protocol is targeted at high-
performance, high-frequency system designs and
includes a number of features that make it suitable
for a high-speed submicron interconnects. Every
AXI transaction includes address and control
information. The data is transferred between
master and slave using a write data channel to the
slave or a read data channel to the master.
4.2.2 AXI Design Specification

The AXI design specifications are provided in the
Table 2. The data has been sampled using
1OOMHz clock. All data, address widths are of 5
bit, and tag ID width of 3 bit. Table 2. covers all
the discussed signal set profiles.
Table 2 AXI Design Specifications

4.2.3 AXI Signal Descriptions
AXI has five independent channels such as write
address channel, write data channel, write
response channel, read address channel and read
data channel for transferring requests and
responses between master and slave. The signals
for various AXI profiles are:
4.2.3.1 AXI Basic Signals
The basic signals include write address, write
data, read address, write address valid, write data
valid, read address valid, write address ready,
write data ready, read address ready, write
response, write response valid, read response
data, read response, and read response data
valid signals. The data and address signals are
configurable. The read response signal is of two bit
that carries the response status information
OKAY, EXOKAY, SLVERR and DECERR.
Due to the use of separate channels for carrying
write and read request information AXI will have
high performance achievement.
4.2.3.2 AXI Burst Extensions
The burst signals include write burst length, write
burst type, read burst length, read burst type, write
request last, and read response last. The burst type
will have address sequences incrementing, wrap
and streaming.
4.2.3.3 AXI Tag Extensions
The tag signals include write address tag ID,
write data tag ID, read address tag ID, write
response tag ID and read response tag ID. Using
the tags out of order responses can be managed.
4.2.4 Design of AXI, AXI-OCP Bridge
4.2.4.1 Simple Read - Write Operation
AXI Master
Figure 8 shows the FSM for simple read write
operation of AXI Master. The oprations of AXI
Master FSM are The AXI Master remains in the
AXI_IDLE state until there is a write (awreq) or
read (arreq) request. The AXI Master moves to
AXI_WRITE state on write request or to
AXI_READ state on read request. Being in
this state the AXI_MASTER will reset
AWADDR, AWVALID, WDATA, WVALID,
ARADDR, and ARVALID.
In AXI_WRITE state, the AXI Master

presents the write address, data information on
AWADDR, WDATA lines by asserting
AWVALID, WVALID signals. Then it will see
for the acknowledgement signals AWREADY,
WREADY and remains in the same state until
they are asserted. If AWREADY = '1' and
WREADY = '1', the master moves to
AXI_IDLE state if BRESP = '01', BVALID =
'1' else remains moves to AXI_WWAIT (wait
for write response) state.
In AXI_READ state, the AXI Master presents the
Read address information on ARADDR by
asserting ARVALID. Then the master see for the
acknowledgment signal ARREADY and remains
in the same till ARREADY is asserted. If
ARREADY = '1', the AXI Master moves to
AXI_IDLE if RRESP = '01', RVALID = '1'
else moves to AXI_RWAIT (wait for read
response) state.
In AXI_WWAIT state, the master waits
for the write response BRESP and write response
valid signal BVALID. When BRESP = "01" and
BVALID = '1' then it moves to AXI_ILDE state.
In AXI_RWAIT state, the master waits for the
read response RRESP and read response valid
signal RVALID. When RRESP = "01" and
RVALID = '1', the master gets the response data
RDATA and moves to AXI_ILDE state.

Figure 8 FSM for AXI Master to handle Simple
Read - Write Operation
4.2.4.2 AXI - OCP Bridge
Figure 8 shows the FSM for simple read - write
operations of AXI-OCP Bridge. The operations
of AXI - OCP Bridge FSM are The AXI-OCP
bridge remains in A2O_IDLE state if ARVALID
= '0', WVALID = '0', AWVALID = '0'. The
bridge moves to the A2O_WRITE state when
WVALID = '1' and AWVALID = '1' or
moves to the A20_READ state when ARVALID
= '1'. Being in this state the bus bridge sets
MCMD, MDATA, ADDR, ARREADY,
RRESP, RDATA, RVALID, AWREADY,
WREADY, BRESP and BVALID to null.
In A20_WRITE state the bridge presents the write
request information MDATA, ADDR and sets
MCMD to "001". It then waits for the
acknowledgement signal CMDACCEPT from
the 0CP slave and remains in the same
state till CMDACCEPT = '1'. 0n
CMDACCPET the bridge moves to the
A20_WRESP state (generate write response).
In A20_READ state the bridge presents
the read request address ADDR and sets MCMD
to "010". It then waits for the acknowledgement
signal CMDACCEPT from the 0CP slave by
remaining in the same state. 0n
CMDACCEPT, if RESP = "01" the bridge
moves to the A20_RRESP (generate read
response) state else moves to A20_RWAIT state
(wait for response from slave).
In A20_WRESP state the bridge sets
BRESP = "01", BVALID = '1' and moves to
A20_IDLE state. In A20_RWAIT state the
bridge waits for RESP by remaining in the same
state and moves to A20_RRESP state when RESP
= "01".
4.3 Comparison between OCP and AXI
Table 3 shows the differences between OCP-
IP Open Core protocol, v2.1 and AMBA AXI
protocol, v1.O.
Table 3 Comparison between OCP and AXI

OCP is referred is a socket based core centric
protocol, because OCP facilitates unrestricted
delivery of core signals (i.e., even sideband
signals) and features. Whereas for AXI is a bus

centric protocol that addresses only the bus
signals and all the sideband signal, test signals are
unaddressed. Table 3 also shows the differences
between OCP and AXI features. It shows the
extra OCP burst features like packed, non
packed and exclusive bur st types when
compared to AXI. It further shows the AXI
support for low power signals, atomic access
and cache support when compared with OCP.
V VALIDATIONS AND DISCUSSION OF
RESULTS
The VHDL implementation for the designed
FSMs is performed. Test benches with sample
vectors are created. The simulation results that
depict the functionality of the HDL design of both
OCP and AXI are shown in the figures and brief
explanation of the results has been presented. For
PSL simulation, based on the identified scenarios
PSL properties are written in VHDL. Separate
VUNIT are built and bound to the top module of
the design. The PSL bound design is simulated
with ModelSim-6.4b
5.1 Simulation Result for AXI to OCP
5.1.1 Simple Read - Write Operation
The setup for functionally verifying the AXI
Master - OCP Slave through bus bridge units is
shown in the Figure 9. The top level RTL for
AXI-OCP is shown in the Appendix A.

Figure 9 Test Setup for AXI to OCP
For read - write operation the test bench drives in
the signals awreq, arreq, amdatain, and amaddrin.
Figure 10 shows the simulation result for simple
read - write operation between AXI Master and
OCP Slave through Bus Bridge. The master
placed a write request on address '8' with data
'14' and after it read data '14' from the same
address '8'. The master then made a write to
location '24' with data '28' and made a twice
read operations on the same address '24' and
received responses '28' for both the reads. This
simulation result therefore shows a proper
functioning of AXI Master and Bus Bridge.

Figure 10 PSL Simulation Result: AXI-OCP
Bridge Simple Requests
5.1.2 AXI - OCP Bridge Simple Requests
Figure 1 1 shows the PSL simulation result for
AXI-OCP Bridge simple read-write requests. The
simulation result shows the assertions triggered
and passed for the scenarios like MCMD,
MDATA, and ADDR for AXI write, MCMD,
ADDR for AXIread, and CMDACCEPT for AXI
read/write.

Figure 11 PSL Simulation Result: AXI-OCP
Bridge Simple Requests
5.1.3 PSL Assertion Coverage
Figure 1 2 shows the PSL assertion coverage
report for AXI to OCP simple and tag operation
respectively. It is seen all the assertions are
covered at least once during the simulation period.

Figure 12 Coverage Report: AXI - OCP Tag
Operation
A total of 30 PSL assertions are passed for
verifying AXI to OCP simple operation and 42
PSL assertions passed for verifying AXI to OCP
tag request operation. All the assertions are bind
to the top module and any internal signals
required are addressed using the
'init_signal_spy' procedure in MODELSIM,
which is mirroring the actual signal in the current
instance where it is called.

5.2 Code Coverage

Code coverage is a measure of amount of design
exercised when a set of test vectors are passed to
the design. Table 4 shows the ModelSim coverage
summary obtained for designed OCP and AXI-
OCP profiles. A total of 81.16% coverage
and 90.1% assertion coverage has been achieved
for OCP. For AXI-OCP, total coverage of
87.35% and assertion coverage of 97.15% has been
achieved.

Table 4 Coverage Summary for OCP and AXI-
OCP

Figure 13 shows the AXI-OCP simple design
coverage percentage achieved for the code
coverage types directive, statement, branch,
condition, toggle, FSM state, FSM transition and
assertion. An overall weighted average of 87.3%
coverage has been achieved for simple AXI-
OCP design. From Figure 13, total 17 FSM
states in the design are exercised with the
provided test vectors and out of 30 PSL
assertions, 29 assertions are covered. The left
out assertion is a "never" assertion that should
not be triggered, which mean all the assertions
are triggered. Figure 13 shows the code
coverage summary by instance for the simple
AXI-OCP design. The AXI-OCP design
contains four instances: AXI Master, AXI-OCP
Bridge, AXI Slave and Memory.

Figure 13 Code Coverage Summary: AXI-
OCP Simple Operation
VI CONCLUSIONS
The d e s i g n e d OCP profiles simple,
precise burst, imprecise burst, pipeline, and tags
are functionally proper with the data that is
written to the memory is successfully read back.
The AXI to OCP simulation results, the
successive writes and reads from same memory
locations shows that the AXI-OCP bridge is able
to process the AXI requests to OCP requests and
OCP responses to AXI responses. A overall code

coverage of 81.16% is achieved for OCP design
and 87.35% is achieved for AXI-OCP design
All the assertions (30 for simple and 42 for
tag AXI to OCP operation) are successfully
passed during simulation. Assertion coverage of
90.1% is achieved for OCP design and 97.15% is
achieved for AXI-OCP design.
The coverage report shows that all the PSL
assertions are covered/passed at least once during
the simulation period
VII.RECOMMENDATIONS FOR FUTURE
WORK
Data handshake signals can be used along with the
normal signal set for achieving high performance.
OCP Burst operation can be extended to different
burst sequences like WRAP burst, FIFO burst etc.,
OCP Tag implementation can be upgraded with
"taginorder" sideband signal, so that the master
can request the slave which requests responses
should be sent in order and which request responses
can be sent out of order Implementation of
OCP Arbiter with multiple masters
VIII.REFERENCES
[1] 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, IEEE International Symposium on VLSI
Design, Automation and Test, pp: 25-28, April 2008
[2] Krishnan Srinivasan and Erno Salminen, A
Methodology for Performance Analysis ofNetwork-
on-Chip Architectures for Video SoC, OCP-IP,
April 2009
[3] OCP-IP, Open core protocol Specification v2.1,
2005. Last accessed on 01/09/2009 from
http://www.ocpip.org/
[4] Shihua Zhang, Asif Iqbal Ahmed and Otmane Ait
Mohamed, A Re-UsableVerification Framework of
Open Core Protocol (OCP), IEEE North-East
Workshop on Circuits and Systems, pp: 1-4, June
2009
[5] ARM, AMBA AXI Protocol Specifcation v1.O,
2003-04. Last accessed on 08/09/2009 from
http://www.arm.com/
[6] Derek Graham, Scott Roy and Fernando
Rodriguez, A low-tech solution to avoid the severe
impact of transient errors on the IP interconnect,
IEEE/IFIP International Conference on Dependable
Systems & Networks, pp: 478-483, 2009
[7] Konstantinos Aisopos, Chien-Chun Chou
and Li-Shiuan Peh, Extending Open Core Protocol
to Support System-Level Cache Coherence, IEEE
International Conference on Hardware/Software
codesign and system synthesis, pp: 167-172, 2008
[8] Fu-ming Xiao, Dong-sheng Li, Gao-ming Du,
Yu-kun Song, Duo-li Zhang and Ming- lun Gao,
Design of AXI Bus Based MPSoC on FPGA, 3rd
International Conference on Anti-counterfeiting,
Security and Identification in Communication, pp:
560-564, August 2009
T. Naga Prasad reddy was
completed his B.Tech from JNTU Hyderabad in 2008
with first class and he was completed his M.Sc
(Engg..) from Coventry University in 2010 with first
class. He have 3.4 years of teaching experience and
10 months of industrial experience, presently
working as an assistant professor in EVM college of
engineering and technology, Guntur, His mail id
isnagaprasaadreddy.t@gmail.com.

Design and PSL Verification of SoC Interconnect Using Open Core Protocol (OCP)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Design and PSL Verification of SoC Interconnect Using Open Core Protocol (OCP)

Încărcat de

Drepturi de autor:

Formate disponibile

International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013

ISSN: 2231-2803 http://www.ijcttjournal.org Page 3292

S-ar putea să vă placă și