VERIFICATION OF AXIPROTOCOL SYSTEM VERILOG

Transcription

1 International Journal of Mechanical Engineering and Technology (IJMET) Volume 8, Issue 5, May 2017, pp , Article ID: IJMET_08_05_065 Available online at aeme.com/ijmet/issues.asp?jtype=ijmet&vtyp pe=8&itype=5 ISSN Print: and ISSN Online: IAEME Publication Scopus Indexed VERIFICATION OF AXIPROTOCOL USING SYSTEM VERILOG Krapanagalakshmi VLSI Design, School of Electronics, Vignan s University, Guntur. A.Surendar Assistant professor, School of Electronics, Vignan s University, Guntur. ABSTRACT Mainly this paper is focused on verification of the advanced extensible interface features. In this we are verifying the all transactions of axi and includes all the five channels of axi. Those are write address, write data, write response, read data and read address. Here for verification purpose we are using (vip) verification intellectual property based methodology. In the vip the total environment design is using system Verilog approach. Here we are verified the read and write transactions of axi using same and different memory locations. In this paper we are verifying the fundamental features of read and write cycles and verification is using functional coverage. Key words: read and write transactions,axiprotocol,verificationip,functional coverage analysis. Cite this Article: Krapanagalakshmi and A.Surendar Verification of Axiprotocol Using System Verilog. International Journal of Mechanical Engineering and Technology, 8(5), 2017, pp IType=5 1. INTRODUCTION Now a days many soc s are using the protocol is axi or advanced extensible interface. Axi is part of the ARM (AMBA) advanced microcontroller bus architecture specification. This AMBA AXI protocol is targeted at high-performance, high-frequency system designs and it includes number of features that make it suitable for high-speed sub microns interconnect. Vip is a good methodology and it is developed by the industry experts for reducing the time in test bench environment. Vip is inbuilt architecture for verification of on chip transactions and it is present inside of soc. In this paper the test bench is developed for the verification of memory transactions of axi and how the data is transferred from one location to another location during read phase and write phase in the same and different address. Here the main aim of verification environment is to verify the above memory transactions and it is developed by using of system Verilog. The main vip components are generator, bus editor@iaeme.com

2 Verification of Axiprotocol Using System Verilog functional model(bfm), mailbox, monitor, interface and coverage. Here each module is designed according to their functionality. The main purpose of generator is to generate different test cases for different applications. A mailbox is a communication mechanism that allows messages to be exchanged between processes. Here it communicates generator and bfm. In the verification environment bfm plays a major role and it receives the transactions from generator and it gives transactions to axi interface. Function of axi interface is it interconnects the slave and master and this is also responsible for handshaking during communication. By using of axi interface only we can take the outputs and it have all the signals for transaction. Axi monitor is used for checking the valid transactions as per handshaking protocol. Here the monitor is designed for transactions of memory. In top module we have to instantiate all the individual modules and proper synchronization should be maintained between them then only we will get exact handshaking. In this paper the memory transactions are verified for two test cases with their waveforms. i. Test case 1:write and read from the same location. ii. Test case 2:write and read from the different location. Test case 1: In this case it mainly focused on read and write transactions that occurs in the same address location. Where as in axi protocol write address operation occurs in single phase and write data operation occurs in multiple phases. AWADDR means write address signal with 32 bit of length represents the Particular address on which multiple data has to be written. In the same way read address operation occurs in single phase and read data operation occurs in multiple phases. ARADDR means read address signal with 32 bit of length. In this test case signals should be same for both AWADDR and ARADDR that occurs in same location also. Test case 2:Testcase 2 is entirely different than teatcase1. In this case read and write occurs in different locations. In this test case AWADDR and ARADDR signals comes from different addresses that indicates the read and write signals should come from different addresses. With the help of obtained waveforms we are verifying the above test cases practically in this paper. 2. ARCHITECTURE OF AXI PROTOCOL AXI architecture has two phases those are read phase and write phase and they are shown in fig-1&2. By using of system Verilog we developed the verification IP environment for the verification of read and write architecture. In fig 1 the write architecture contains write address, write data and write response channels. Write address channel carries all of the required address and control information for a transaction and this is single phase with 32 bit size. Write data channel conveys write data from master to slave and this is multiple phases. In write transactions all the data flows from master to slave and it has an additional write response channel to allow the signal from slave to the master. For the completion of write transaction means write address followed by write data and finally write response signals. In fig 2 the read architecture contains read address, read data channels. Read address channel carries all of the required address and control on formation for a transaction and this is single phase with 32 bit size. Read data channel conveys both read data and read response information from slave to the master. For the completion of read transaction means read address followed by read response signals. The programmer can create any number of test cases according to their verification. Verification engineer should verify all the results according to their requirement editor@iaeme.com

3 Krapanagalakshmi and A.Surendar ` MASTER INTERFACE Write address Write data channel Write response channel SLAVE NTERFACE Figure 1 Write Architecture MASTER INTERFACE Read address Read Data SLAVE NTERFACE Figure 2 Read Architecture 3. VERIFICATION ENVIRONMENT Memory transactions of axi is verified using verification environment and it is shown in fig 3. Verification environment helps to read the test cases using generator module for satisfying the verification criteria. Here we are mainly focused on two different testcases for verifying the both read and write transactions of same and different address locations. Mailbox is used to transfer the data from generator to bus functional model. This bus functional model plays a important role for getting the transactions from generator and drive them to the axi interface. By using of system Verilog we developed the verification environment. Nowadays verification intellectual property consists of inbuilt verifying option with all system on chips in the verification environment editor@iaeme.com

4 Verification of Axiprotocol Using System Verilog GEN MAIL BOX BFM AXI MONITOR AXI SLAVE AXI INTERFACE Figure 3 VIP for verifying memory transaction 4. RESULTS AND DISCUSSIONS Here we see the results for the verification of memory transactions of axi protocol by using of system Verilog approach. Here we are using the 32 bit size of mentor graphics questa-sim EDA tool for simulation process. In this the total verification is carried out in two cases. Case 1: read and write operation in the same memory location Case 2: read and write operation to the different memory location. Here we are using the random pattern generation based input combinations for analyzing the all test cases. Case 1: In this case the write and read operations from the same address locations are verified. AWADDR means write address signal with size of 32 bit in hex decimal format. Fig 4 and 5 indicates write and read operations using same address location. Here AWADDR and ARADDR are having same address that is e8. It means write and read operations are happening to the same location. Similarly in fig 4 and 5 WDATA and RDATA also happening with the proper sequence. By seeing the fig 4 and 5 write and read operations are happened effectively without any loss of data or response in the channel. Case 2: In this case the write and read operations from different address locations are verified. Write and read address both signals having 32 bit in hex decimal format. In fig 6for write address and e2 for read address operation. By observing the both read and write address locations the memory transactions are happening in two different locations. Similarly AWLEN and ARLEN are also different for every transactions editor@iaeme.com

5 Krapanagalakshmi and A.Surendar Figure 4 Writing to same location Figure 5 Reading from the same location editor@iaeme.com

6 Verification of Axiprotocol Using System Verilog Figure 6 Write and read from different locations By observing the waveform we can easily understand the signals and their working of AXI protocol. There are so many signals are there but here we are mainly worked on AWID,AWADDR,AWLEN,AWVALID,AWREADY,WID,WDATA,WLAST,WVALID,W READY,BID,BVALID,BREADY,ARID,ARREADY,ARVALID,ARADDR. These signals are belongs to write and read signals of AXI protocol. Verification is classified into three types that isucdb it means unified coverage database. Code coverage, Functional coverage and Assertion coverage. Code coverage means how much portion of our code is exercised in our simulation and it is not user defined only tool will generate the report in terms of percentage. It is six types FLBEST means Fsm, Condition, Branch, Expression and Toggle operations. Functional coverage means it measure the how much percentage of interesting scenarios has been covered in all test case runs put together. It is user defined and measured in terms of percentage only. In this paper we are mainly focused on functional coverage and it is three types Simple, Transition and Cross coverage. The below fig 6 shows the report for all the three verification methods by using of QUESTA SIM simulation tool. By using of system Verilog the memory transactions of axi is verified and simulated for the read and write channels. By using of questa-sim mentor graphics tool functional coverage verification is enabled. In the fig 6 shows the ucdb coverage results means for all three verification methods and in the fig-7it shows only functional coverage verification of AXI protocol. In this we got 73.9% for axi cover groups and 100% for axi scenario cover groups. The total average of functional verification is 86.97% editor@iaeme.com

7 Krapanagalakshmi and A.Surendar Figure 7 UCDB coverage report Figure 8 Functional coverage mode analysis 5. CONCLUSION In previous methods they verified the memory transactions of AXI protocol and they did code coverage analysis for AXI. In this paper we verified the memory transactions of AXI and we used UCDB verification. UCDB (unified code debugging) verification means all three methods of verification those are code, functional and assertion verification methods. But we are mainly focused on functional verification. Compared to code coverage functional coverage is difficult because code coverage is not user defined only tool will give the report based on how much portion of our code is exercised when we are simulating. Functional verification is user defined so we have to cover all the test cases and runs put together and we generated a html report for that. For functional verification we got 86.97%.It takes very less time to market and it applicable for complex designs of system on chips using system Verilog approach editor@iaeme.com

8 Verification of Axiprotocol Using System Verilog REFERENCES [1] Pasricha, S., Dutt, N., & Ben-Romdhane, M. (2004, June). Extending the transaction level modeling approach for fast communication architecture exploration. In Proceedings of the 41st annual Design Automation Conference (pp ). ACM. [2] Goossens, Kees, et al. "A design flow for application-specific networks on chip with guaranteed performance to accelerate SOC design and verification." Proceedings of the conference on Design, Automation and Test in Europe-Volume 2. IEEE Computer Society, [3] Kumar, Akash, et al. "Interactive presentation: An FPGA design flow for reconfigurable network-based multi-processor systems on chip." Proceedings of the conference on Design, automation and test in Europe. EDA Consortium, [4] Manju, K., R. S. Sabeenian, and A. Surendar. "A review on Optic Disc and Cup Segmentation." Biomedical and Pharmacology Journal 10.1 (2017): [5] Surendar, A., and M. Arun. "FPGA based multi-level architecture for next generation DNA sequencing." Biomedical Research (2016). [6] Bromley, Jonathan. "If SystemVerilog is so good, why do we need the UVM? Sharing responsibilities between libraries and the core language." Specification & Design Languages (FDL), 2013 Forum on. IEEE, [7] Neishaburi, Mohammad Hossein, and ZeljkoZilic. "A distributed AXI-based platform for post-silicon validation." VLSI Test Symposium (VTS), 2011 IEEE 29th. IEEE, [8] Anuja Dhar, Ekta Dudi, Hema Tiwari and Pallavi Atha, Coverage Driven Verification of I2C Protocol Using System Verilog. International Journal of Advanced Research in Engineering and Technology, 7(3), 2016, pp [9] R.Kathiresan, M.Thangavel, K.Rathinakumar and S.Maragadharaj, Analysis of Different Bit Carry Look Ahead Adder Using Verilog Code. International journal of Electronics and Communication Engineering &Technology (IJECET), 4(4), 2013, pp [10] Surendar, A. "Evolution of Gait Biometric System and Algorithms-A Review." Biomedical and Pharmacology Journal 10.1 (2017):