Validation of Open Core Protocol

by Exploiting Design Framework Using

System Verilog and UVM

Gopika Rani Alekhya Pamarthy, M. Durga Prakash

and Avinash Yadlapati

Abstract Today’s scenario of semiconductor technology is a tremendous inno-

vation; it includes a large number of intellectual property (IP) cores, interconnects,
or buses in system on chip (SOC) design and based upon the necessity its com-
plexity keeps on increasing. Hence, for the communication between these IP cores,
a standard protocol is developed. The necessity of IP reuse, abridging the design
time and the complexity makes large-scale SOC more challenging in order to
endorse IP core reusability for SOC designs. An efficient non-proprietary protocol
for communication between IP cores is open core protocol (OCP). OCP comes
under socket-based interface and openly licensed core concentric protocol. This
paper addresses on the verification of implemented design of OCP. The proposed
paper is to verify the implemented design by using System Verilog and Universal
Verification Methodology (UVM) in SimVision tool.

Keywords Open core protocol (OCP) Intellectual property (IP)



System on chip (SOC) Socket-based interface Core concentric

1 Introduction

Open core protocol (OCP) is a competent protocol for communication on SoC.

OCP [1] compliance IP cores can be reversed by the designer, depending on system
integration and verification approach in multiple designs without reinstallation,

G. R. A. Pamarthy (&)
M. Durga Prakash

Department of Electronics and Communication Engineering, K L University, Guntur,
Andhra Pradesh, India
e-mail: alekhya.rani.gopika@gmail.com
M. Durga Prakash
e-mail: mdprakash82@gmail.com
A. Yadlapati
CYIENT Ltd, Hyderabad, India
e-mail: avinash.amd@gmail.com

© Springer Nature Singapore Pte Ltd. 2018 9

S. Bhalla et al. (eds.), Intelligent Computing and Information and Communication,
Advances in Intelligent Systems and Computing 673,
https://doi.org/10.1007/978-981-10-7245-1_2
10 G. R. A. Pamarthy et al.

reducing the development time, cost, and design risk. OCP is an interface for
communication between IP cores on an SOC. OCP defines a bus-independent
configurable interface.
OCP renovates IP cores making them independent of the architecture and design
of the systems in which they are used and shortens system verification and testing
by providing a secure boundary around each IP core. OCP is simple, synchronous,
point-to-point, highly scalable, and configurable to match the communication
requirements associated with different IP cores. Even complex high-performance
cores can be accommodated capably with OCP extensions. Cores with OCP
interfaces enable true plug-and-play [2] approach and automated design processes,
thus allowing the system integrator to choose the best cores and best interconnect
system.
Unlike bus approach, with reference to the standard communication approach,
there are mainly two protocols: VCI (Virtual Component Interface) and OCP. OCP
which is scalable and bus independent is a superset of VCI which reports only data
flow aspects; moreover, OCP supports sideband control signaling and tests harness
signals which are configurable. OCP is the only protocol which unifies all the
inter-core communication. OCP establishes a point-to-point interface between two
IP cores [3]. One of them acts as the master who is the controller and generates the
commands and other as the slave responding to commands generated by the master,
either by accepting or giving data to the master.
The OCP defines a point-to-point interface between two communicating entities
such as IP cores and bus interface modules (bus wrappers). One entity acts as the
master of the OCP instance and the other as the slave. Only the master can present
commands and is the controlling entity. The slave responds to commands presented
to it, either by accepting data from the master or presenting data to the master. For
two entities to communicate in a peer-to-peer fashion, there need to be two
instances of the OCP connecting them—one where the first entity is a master, and
one where the first entity is a slave.

2 Project Scope

Implementation is carried out using behavioral Verilog HDL [4] simulation envi-
ronment. The design implements a simple memory read and write operations and
Burst transactions between two IP cores. The design complies with subset of
OCPIP handshake signals. The implemented design, i.e., DUT, is verified using
system Verilog and UVM. As the system Verilog is superset of Verilog and is based
upon OOPS [5] (Object Oriented Programming) concepts, the environment can be
extended without modifying the intention of the original existing code by adding all
the required new features.
Validation of Open Core Protocol by Exploiting Design Framework … 11

3 OCP Protocol

OCP is a configurable protocol that defines one of the communicating entities as

master and other as slave. Master initiates the operation by generating a request
signal to the slave, and in turn slave responds by sending the acknowledgement to
the master. Once master receives the acknowledgement [5] from slave, it transmits
the data to the slave; this phenomenon illustrates the typical handshaking process of
communication as shown in Fig. 1.

3.1 OCP Signal Description

The dataflow signals consist of a small set of required signals and a number of
uncompelled signals that can be configured to support additional requirements [1].
The dataflow signals are grouped into basic signals, burst extensions (support for
bursting). The naming conventions for dataflow signals use the prefix M for signals
driven by the OCP master and S for signals driven by the OCP slave [3].
• Clk: Input clock signal for the OCP clock.
• Maddr: Input address to the master in which data has to be written into the
corresponding memory location and is to be accessible later during read oper-
ation. Maddr width is configurable.
• MCmd: Mode assignment command of width 3. This signal specifies the mode
of OCP which is requested by the master. Usually, depending upon the com-
mand generated by the master, slave responds and performs that operation.
If OCP is in idle state, it does not perform any mode of transfer, whereas during
non-idle state depending on the direction of data flow, OCP [2] performs either
read/write operation.
• Mdata: The data sent by the master that has to be written into the prescribed
memory location of slave which is a configurable one.
• MDatavalid [6]: This is the indication to the slave that the data sent by the
master is valid only. When it is set, it specifies that the Mdata field is valid.
• MRespAccept: Acknowledgment from master that the response from slave was
accepted by it when MRespAccept is set.

Fig. 1 Signal transmission between master and slave

12 G. R. A. Pamarthy et al.

• SCmdAccept: Acknowledgment from slave that the response from master was
accepted by it when SCmdAccept is set.
• Sresp: Response from the slave to a transfer request from the master. It is of
width 2.
• SData: It transfers the requested data by master as read data from the slave to
the master.
• MBurstLength: This illustrates configurable number of transfers in a burst.
MBurstLength of value 0 is illegal.
• MBurstPrecise: This specifies whether the precise burst length is known at the
start of the burst or not.
• MBurstSeq: This 3-bit-width field indicates the sequence of addresses for
requests in a burst.
• SRespLast: Last response from the slave in a burst.
• MReqlast: Last request from the master in a burst.

4 Functional Description

The data transfer between master and slave is communicated non-serially.

Commands are generated by the master to the slave. Based on the command given
by the master, slave responds and decides the mode of operation need to be per-
formed that is requested by the master. Data is either written or read based upon the
command from master into the particular memory location which is specified by the
master [6].

4.1 Master

Master is the one who starts the transactions by providing data and address to the
slave. It is the commander and controller of the entire design. It makes the slave to
function on what it needs. The basic block diagram of master with all the input and
output signal specifications is shown in the figure.
Master activates the OCP by sending command, address, and data to the slave
when clock is active. Slave responds to the master’s command and sends an
acknowledgment to the master indicating the acceptance of command from master
as SCmdAccept [7]. Write/read mode of transmission is performed based on the
master’s request. In order to indicate that the data sent by master is valid, it sends a
valid bit on MDatavalid to the slave; on receiving it, slave starts writing the data in
the corresponding memory location. Similarly, master reads the data from slave by
activating data to be read on SData by specifying the exact memory location.
Master block with all its inputs and outputs driving to slave are shown in Fig. 2.
Validation of Open Core Protocol by Exploiting Design Framework … 13

Fig. 2 OCP master block

4.2 Slave Block

Slave simply performs the operation depending on the command sent by the master.
It activates itself to respond on to the master request. Data handshaking process of
communication is adopted to have a proper and efficient communication [8]. Slave
acknowledges for each and every signal from master as a correspondence or
acceptance of request from the master. The detailed slave block is shown in Fig. 3.
Slave responds to the request sent by the master [9]. It performs read/write mode
of transfer by responding to the signals from master. Slave acknowledges the master
for each and every transfer at enabled clock. During read mode of operation, it
acknowledges the master that the data sent by it is a valid one by sending its

Fig. 3 OCP slave block

14 G. R. A. Pamarthy et al.

response by means of Sresp signal. Both master and slave are controlled by the
same clock [1].

5 Timing Analysis

To connect two IP cores together by allowing them to communicate over an OCP

interface, the protocols, signals, and pin-level timing must be compatible. OCP
establishes the communication based on the applied clock to the master [3]. Timing
plays a vital role while sending the data to the slave or from the slave.

5.1 Basic Mode of OCP

The timing analysis for simple write and simple read of OCP is illustrated in Fig. 4.
The diagram shows a write with no response enabled on the write [5].

Fig. 4 Timing analysis of basic mode OCP

Validation of Open Core Protocol by Exploiting Design Framework … 15

5.2 Burst Mode of Operation

OCP burst mode for a burst of four 32-bit words, incrementing precise burst write,
with optional burst framing information (MReqlast) is illustrated [4]. As the burst is
precise (with no response on write), the MBurstLength signal is constant during the
whole burst. MReqlast flags the last request of the burst, and SRespLast flags the
last response of the burst. The slave monitors MReqlast for the end of burst. The
timing diagram is shown in Fig. 5.

6 Simulation Results

The implemented design of OCP is verified by creating the UVM verification

environment by using SimVision, cadence tool. SimVision Debug can be used to
debug digital, analog, or mixed-signal designs. These can be written in Verilog,
SystemVerilog, e, VHDL, and SystemC® languages. It supports all IEEE standard
designs of signal-level and transaction-based flows, testbench, and assertion lan-
guages. SimVision Debug provides a unified simulation and debug environment. It
allows Incisive Enterprise Simulator to manage multiple simulation runs easily [8].
To analyze both design and testbench at any point in the verification process is quiet
easy.

Fig. 5 Timing analysis of burst mode OCP

16 G. R. A. Pamarthy et al.

6.1 Simple Mode of Operation (Both Write and Read)

Basic mode of OCP with simple write and read is implemented and verified [2].
Master initiates the transfer by sending the address and data to the slave on Maddr
and MCmd, respectively. Slave acknowledges the master by asserting the
SCmdAccept to the master. It performs either read or write based upon the com-
mand generated by the master. The simulation results obtained for the applied
transaction between master and slave when RTL is verified by using UVM
Methodology on SimVision tool are shown in Fig. 6.

6.2 Burst Mode of Operation (Both Write and Read)

Precise burst mode was implemented and verified. MBurstLength,

MBurstSequence, and MBurstPrecise are considered constant throughout the
transaction. Master initiates precise burst write operation by sending the request to
slave (MCmd), address (Maddr), and data (Mdata). Mreqlast = 1 indicates the end
of request from master. Slave acknowledges the master by enabling SCmdAccept.
A high on SRespLast represents the end of precise burst read [6]. The simulation
result obtained for the applied transaction between master and slave when RTL is
verified by using UVM methodology on SimVision tool is shown in Fig. 7.

Fig. 6 Simulation results of basic mode OCP

Validation of Open Core Protocol by Exploiting Design Framework … 17

Fig. 7 Simulation results of burst mode OCP

7 Conclusion

This paper is mainly about the implementation and verification of basic modes of
OCP. This work delivers that OCP is an efficient protocol for secured data core
communication. OCP is capable enough in reducing the design time and risk by
simultaneously designing the cores and working in the system. Based upon the
real-time applications, IP cores are supposed to be designed such that they can be
redesigned by cores which are not having inbuilt system logic that can be reused
with no additional time for cores to be re-created.

References

1. Technical Information on Open Core Protocol, [online] Available: http://www.ocpip.org/,

Open Core Protocol - International Partnership (OCP-IP).
2. Shihua Zhang, Asif Iqbal Ahmed and Otmane Ait Mohamed, “A Re-Usable Verification
Framework of Open Core Protocol (OCP)”. OCP-IP, 2008.
3. Elina Rajan Varughese and Rony Antony, “Implementation of extended open core protocol
interface memory system using Verilog HDL,” P. 978-1-4673- 6126-2/13/$31.00 c 2013 IEEE.
4. Open Core protocol (OCP) Specifications 2.2, Revision 1.0, Accellera 2004, [online]
Available: http://www.ocpip.org/home.
5. OCP-IP, The Importance of Sockets in SoC Design, [online] Available: http://www.ocpip.org/
white papers.php.
6. Chin-Yao Chang, Yi-Jiun Chang, Kuen-Jong Lee, Jen-Chieh Yeh, Shih-Yin Lin and
Jui-liangma “Design of On-Chip Bus with OCP Interface,”.
7. R. Usselmann, “Implementation of Re-configurable Open Core Protocol Compliant Memory
System using VHDL 2010 5th International Conference on Industrial and Information
Systems,” ICIIS 2010, Jul 29–Aug 01, 2010, India.
8. Chris Spear, “System Verilog for verification: A Guide to Learning the test bench for Language
Features”: Springer, second edition.
9. S. Palnitkar, “Verilog HDL: A Guide to Digital Design and Synthesis”, Upper Saddle River,
New Jersey: Prentice Hall, Jan. 1996.