0 évaluation0% ont trouvé ce document utile (0 vote)
31 vues10 pages
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 IP’s.
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 FSM’s 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.
Titre original
Design and PSL Verification of SoC Interconnect Using Open
Core Protocol (OCP)
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 IP’s.
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 FSM’s 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.
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 IP’s.
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 FSM’s 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.
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, International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3293
thereby implementation of SoC interconnect using OCP is worthy. 1.1 Need for Project With the increasing complexity of modern System-on-Chip (SoC) designs, more and more intellectual property (IP) blocks will be integrated 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. International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3294
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 With the increasing complexity of modern System-on-Chip (SoC) designs, more and more intellectual property (IP) blocks will be integrated 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.
International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3295
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 International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3296
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 International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3297
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 International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3298
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 International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3299
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. International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3300
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 International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 9 Sep 2013 ISSN: 2231-2803 http://www.ijcttjournal.org Page 3301
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.