International Conference on Inventive Communication and Computational Technologies (ICICCT 2017)
Extensions of Open Core Protocol and their High Level Verification using System Verilog and UVM Gopika Rani Alekhya Pamarthy,M.Durga Prakash
Avinash yadlapati
Electronics and Communication Engineering K L University Guntur, India
[email protected] [email protected]
SEMICON Group CYIENT Ltd Hyderabad, India
[email protected]
Abstract— Today’s scenario of semiconductor technology is a tremendous innovation, System on chip (SOC) design is of a great number of Intellectual property (IP) Cores which requires an efficient protocol for all types of operations. Large scale SOC gets more demanding due to the unavoidable importance for IP reuse, complexity and abridging the design time while encouraging IP core reusability for SOC designs. Extended modes of a nonproprietary protocol like Open core protocol (OCP) are more efficient. OCP comes under socket based interface and openly licensed core concentric protocol. This paper addresses on the verification of implemented design of Extended OCP. The proposed paper is to verify the implemented design by using System Verilog and Universal Verification Methodology (UVM) in SimVision tool.
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. Further OCP being an existing standard, it is capable enough in meeting all the future SOC requirements in terms of performance, design methodology, including verification [3] and modelling tools. OCP is utilized by many pipelined signal processing applications such as MPEG2 decoding [6] and multiband DRAM architectures [6]. II. OVERVIEW
I. INTRODUCTION
A. Implementation Implementation is carried out using behavioral Verilog HDL [1] simulation environment. The design implements a simple memory read, write operations and Burst transactions between two IP cores .The design comply with subset of OCPIP handshake signals.
Open core protocol (OCP) is a competent protocol for communication on SoC. OCP [3] compliance IP cores can be reversed by the designer, depending on system integration and verification approach in multiple designs without reinstallation, reducing the development time, cost and design risk. OCP is an interface for communication between IP Cores on a SOC.OCP defines a bus independent configurable interface. IP Cores are rebuilt using OCP making them individual from the design in which they are used and lessens system testing and verification by giving them a dependable boundary around each IP core. OCP is simple, synchronous and point-topoint protocol. Even complex high-performance cores can be accommodated capably with OCP extensions. Cores with OCP interfaces enable true plug-and- play [5] approach and automated design processes. 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 test 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 [4]. One of them acts as the
B. Verification The implemented design i.e. DUT is verified using System Verilog and UVM.As the system Verilog is superset of Verilog and is based up on OOPS [2] (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. Modules, SOC’s are verified by driving the input stimuli to verify the behavior of design, by driving correct and error input, in either of the cases the expected behavior of design is verified, a bug may occur if it is not as per the requirement. Testbench/Verification environment is created to determine The correctness of the design under test (DUT).The verification setup is shown in figure 1. The simulations are done using SIM VISION an integrated graphical debugging environment within Cadence Simulator. It supports signal-level and transaction-based flows across all IEEE-standard design, Testbench, and assertion languages. It also funds concurrent visualization of hardware, software, and Analog domains. SimVision Debug can be used to debug Digital, analog, or mixed-signal designs written in Verilog, SystemVerilog, Verilog, VHDL, and SystemC® languages or a combination. It provides Effortless Simulation to analyze both design and test bench behavior irrespective of configuration at any point in the verification process.
Keywords—Open Core Protocol (OCP); System on Chip (SOC); Intellectual Property (IP); Socket Based Interface; Core concentric;
978-1-5090-5297-4/17/$31.00 ©2017 IEEE
475
International Conference on Inventive Communication and Computational Technologies (ICICCT 2017)
Top
Request
Test
Data
Environment
MASTER
Generator
Driver Transaction
Interface
Response
SLAVE
Data
DUT
Fig. 2. Block Diagram of OCP
Fig. 1. Verification setup III. THEORY OF OPERATION OCP is a configurable protocol defines one of the communicating entities as master and other as slave. Master initiates the operation by generating a request signal to the slave, in turn slave responds by sending the acknowledgement to the master [6]. Once master receives the acknowledgement [2] from slave it transmits the data to the slave this phenomenon illustrates the typical hand shaking process of communication which is shown in the following figure 2. 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 performed 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. An OCP interface by itself is inherently endian-neutral. Data widths must match between master and slave, addressing is on an OCP word granularity [2], and byte enables are tied to byte lanes (data bits) without tying the byte lanes to specific byte addresses. The issue of endianness arises in the context of multiple OCP interfaces, where the data widths of the initiator of a request and the final target of that request do not match. A. Master Block Master is the one who starts the transactions by providing data and address to the slave.it is the commander and controller of entire design [3]. It makes the slave to function on what it needed. B. 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 [9]. Slave acknowledges for each and every signals from master as a correspondence or acceptance of request from the master. Slave responds [4] to the request sent by the master [8] . Slave acknowledges the master for each and every transfer at enabled clock. During read mode of operation slave acknowledges the master that the data sent by master is the valid data by sending its response by means of Sresp signal. Both master and slave are controlled by the same clk.
IV. OCP EXTENSIONS A. Burst Extensions A burst transaction is a defined set of transfers (address sequence and number of transfers are constant). There are three general categories of bursts [9]: 1) Imprecise Bursts: Request information is given for each transfer. With a variable Length information during the burst. 2) Precise Bursts: An Imprecise Burst with constant length information throughout the burst. 3) Single request/multiple data bursts: A precise burst, with Single request information for the entire burst. B. Tag Extensions A master drives a tag on MTagID during the request phase. The value of the tag is determined by the master .For write transactions with data handshake enabled, the master repeats the same tag on MDataTagID during the data handshake phase. For read transactions, the slave acknowledges the tag of the corresponding request on STagID while delivering the response [7]. C. Thread Extensions All transfers within a given thread must either remain strictly ordered or follow the tag ordering rules, but there are no ordering rules for transfers that are in different threads. Master maps an individual request to threads through the MthreadID and slave acknowledges through SThreadID. MDataThreadID field is used to during the data handshake phase (multiple threads). V. RESULTS A. Burst Extensions 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. The simulation results are shown in Fig. 3. B. Tag Extensions Tag Extensions are verified by initiating the transfer by master. Slave receives request (mcmd), address (maddr), data (mdata) and tag on mtagID from master. Master enables mtagID when ordering of request is required and Mtaginorder
978-1-5090-5297-4/17/$31.00 ©2017 IEEE
476
International Conference on Inventive Communication and Computational Technologies (ICICCT 2017)
=1 denotes that request ordering is not required. Slave acknowledges the m a s t e r b y enabling scmdaccept. StagID =1, Staginorder =1represents ordering of response is required and response ordering is not required. Figure 4 shows the simulation of OCP Tag Extensions [5]. C. Thread Extensions Master initiates the transaction by sending the request to slave (mcmd), address (maddr), thread ID (mthreadID) and data (mdata).Slave acknowledges the master by enabling scmdaccept. MThreadID=1 indicates the request thread identifier. Sthreadid =1 indicates the response thread identifier. Thread Extensions verification results are shown in Fig. 5. VI. FUTURESCOPE This paper delivers that OCP is an efficient protocol for secured, proper data core communication. Extensions of OCP are capable enough in reducing the design time and risk by simultaneously designing the cores and working in the system. As a Future Scope the work can be implemented on an FPGA Kit. ACKNOWLEDGMENT The authors would like to thank the entire semiconductor team of CYIENT for sharing their pearls of wisdom with us during the course of this work.
REFERENCES [1]
Open Core Protocol (OCP) Specification 2.2 Revision 1.0, Accellera, 2001 [online] Available: http://www.ocpip.org/home [2] OCP-IP, The importance of Sockets in SoC Design [online] Available: http://www.ocpip.org/whitepapers.php [3] Technical Information on Open Core Protocol [online] Available: http://wwwocpip.org/, Open Core Protocol International Partnership (OCP-IP) [4] 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 [5] Shine Zhang, Asif Iqbal Ahmed and Otmane Atit Mohamed, “A Reusable Verification Framework of Open Core Protocol (OCP)”, OCP-IP, 2008. [6] Chin-Yao Chang, Yi-Hiun Chang, Kuen-Jong lee 1, Jen-Chieh Yeh 2, Shih-Yin Lin2 and Jui-Liangma 2, “Design of ON-chip Bus with OCP Interface”. [7] R. Usselmann, “Implementation of Re Configurable Open Core Protocol Compliant Memory System using VHDL”, 5th International conference on Industrial and Information systems, ICIIS, 2010, Jul 29 – Aug 01, India. [8] S. Palnitkar, “Verilog HDL: A Guide to Digital Design and Synthesis”, Upper Saddle River, New Jersey, Prentice Hall, Jan 1996. [9] Chris Spear, “System Verilog for Verification: A Guide to Learning the Testbench for Language Features”, Springer, Second Edition. [10] Vincet Himpe, “Mastering the Protocol Bus”. [11] Saikat Bandopadhyay, Simulation in Sanjay ChuriwalaNagel (eds) Designing with Xilinx FPGAs, LNCS, pp. 127-140, Springer, Switzerland, 2017. [12] Rashinkar, Prakash, Paterson, Peter, Singh, Leena, “System-on-a-chip Verification: Methodology and Techniques”, Norwell, MA, USA, 2000.
Fig. 3. Simulation results of OCP‘s Burst Extensions (write and read transfers)
Fig. 4. Simulation results of OCP‘s Tag Extensions (write and read transfers)
Fig. 5. Simulation results of OCP’s Thread Extensions (write and read transfers)
978-1-5090-5297-4/17/$31.00 ©2017 IEEE
477
