Verification of I2C module for Multiprotocol Serial Controller

Transcription

1 e-issn Volume 2 Issue 4, April 2016 pp Scientific Journal Impact Factor : Verification of I2C module for Multiprotocol Serial Controller Subham Punit Patro1, Shreela Dattawadkar2, Shantala Kulkarni3, Dr.Kiran Bailey4,Sunil Matange5 1 Department of Electronics & Communication, BMS College of Engineering, subhampatro1994@gmail.com 2 Department of Electronics & Communication, BMS College of Engineering, shreelavd@gmail.com 3 Department of Electronics & Communication, BMS College of Engineering, shantala987@gmail.com 4 Department of Electronics & Communication, BMS College of Engineering, kiran.ece@bmsce.ac.in 5 Department of Electronics & Communication, BMS College of Engineering,shamtange@gmail.com Abstract Verification is an important aspect of any design. It is the process used to demonstrate the functional correctness of the design prior to its fabrication. Functional verification, in electronic design automation, is the task of verifying that the logic design conforms to specification. In everyday terms, functional verification attempts to answer the question "Does this proposed design do what is intended?" This is a complex task, and takes the majority of time and effort in most large electronic system design projects. Functional verification is a part of more encompassing design verification, which, besides functional verification, considers non-functional aspects like timing, layout and power. The I2C controller is one of the serial communication modules in multi-protocol serial controller. It communicates with the CPU through an interface. The I2C is a multi-master bus. The I2C interface uses a serial data line (SDA) and a serial clock line (SCL) for data transfers. Each data byte is 8 bits long. The main aim of this project is to verify the functional correctness of the I2C Module for Multiprotocol Serial Controller. The verification will be carried out in SystemVerilog using the layered testbench (LTB) architecture and waveforms and coverage reports will be generated and analysed to check the functional correctness of the design. It will also give us a glimpse of how the design would behave in erroneous conditions. Keywords I2C; LTB (Layered Testbench); Bugs; APB; Verification; Coverage; SystemVerilog. I. INTRODUCTION The I²C (Inter-Integrated Circuit) bus was developed in the early 1980's by Philips Semiconductors (now NXP Semiconductors). It is typically used for attaching lower-speed peripheral ICs to processors and microcontrollers. Alternatively I²C is spelled I2C or IIC. I2C is a two-wire, bi-directional serial bus that provides a simple and efficient method of data exchange between devices. It is most suitable for short distance communication between devices. It is a multimaster bus with collision detection and arbitration facilities to prevent data corruption in case if more than one master tries to access the bus simultaneously. The Device that provides the clock signal is considered to be master at that time. The I2C interface uses a serial data line (SDA) and a serial clock line (SCL) for data transfers. Data is transferred between a Master and a Slave on the SDA line in synchronization with SCL line on a byte-by-byte basis. Each data byte is 8 bits long. Simulation of a design validates the behavior of design for one particular computation path and is inexpensive in terms of execution time. However, simulation cannot fully ensure the functional correctness of the design. Verification guarantees the correct behavior of the design over the entire set of computation paths. The goals of Verification are to make sure that the design is an accurate representation of the specification, look for bugs or functional discrepancies in the design, ensure that most of the bugs are found before tape-out so that re-spinning cost time and money are reduced, check how the design operates when there are errors. In this project, the I2C module for Multiprotocol Serial Controller will be verified by using Mentor Graphics tools. Verification environment will be a Layered Testbench built by using different All rights Reserved 548

2 II. THE VERIFICATION ENVIRONMENT The SystemVerilog Layered Testbench Architecture used in the project for functional verification is as shown in Figure 1. The top module, in the Layered Testbench Architecture, encloses the RTL, the testbench and the interface. The testbench contains the environment, which in turn encloses the generator, transactor, receiver, scoreboard, driver and the coverage modules for the verification of the RTL. Figure 1 Verification Environment A simulation environment of LTB is typically composed of several types of components: DUT (Design Under Test): This is the RTL file which contains the design to be tested. Design description is given and functionality is implemented by using Verilog code. In this project the DUT is the combination of I2C with the interface block which generates I2C signals by using the APB signals. Figure 2 shows the Design Under Test. The DUT has signal connections to APB bus as well as I2C bus. On the APB side, signals such as PRESETn, PCLK, PSEL, PENABLE, PWRITE, PADDR and PWDATA are inputs to the DUT while PRDATA is an output. The I2C block represented here is the I2C Slave module. On the I2C side, SCL_out, SCL_en, SDA_out and SDA_en are the outputs of the DUT whereas SCL_in and SDA_in are the inputs. Figure 2 Design Under Test 549

3 INTERFACE: Interface block contains all the signals (inputs and outputs). It is used to define the inputs and outputs and also to connect the design and testbench. The modport blocks define the direction of ports for the signals. The clocking blocks include the synchronous signals and take care of timing. Assertions (concurrent or immediate) are also defined inside this block. Assertions are essential to estimate the correct functionality of a design in specific cases. TOP MODULE: In the top module, the design (Verilog RTL), interface and testbench modules are included and their instances are created. Clock is generated in this module. The monitor statement is also included in this module to see the inputs and outputs along with time instant. System task $dumpfile is used to create the.vcd file. ENVIRONMENT: The environment class envelopes all the classes in one block and establishes connections between them. The instances of all classes and the mailboxes needed are declared. Build function and Start task are included. TRANSACTOR: Transactor class will include the declaration of random signals (rand) or random signals with constraints (randc). The constraints for rand signals are applied here. Display function is included to see the values of signals in this class. Compare function is also defined. GENERATOR: The generator class is where the randomization happens. The rand signals declared in transactor class and randomized in this class and sent to the driver class. The mailbox connects this class to driver class. DRIVER: The driver class is connected to generator and scoreboard classes through mailboxes. It receives the randomized signals from the generator and applies them to the interface block signals. It also sends them to scoreboard. RECEIVER: The receiver class is connected to scoreboard through mailbox. It is used to send the data received from interface block to the scoreboard. COVERAGE: The coverage class contains covergroups needed for functional coverage. The bins for all coverpoints are defined. The randomized signals are sampled here. SCOREBOARD: Scoreboard is connected to driver and receiver through mailboxes. It receives signals from both through the mailboxes and compares the signals to see if they are equal. TESTBENCH (TEST): The testbench is a program block in which the environment class is included. The build and start functions of environment class are called here. All the test cases are exercised in the testbench. Figure 3 shows the design of the I2C block which was to be verified. 550

4 Figure 3 I2C Block Diagram III. IMPLEMENTATION The Project implementation was divided into four different phases: Study, Documentation, Implementation and Verification. For every phase, the steps that were carried out as per the plan have been listed below Study phase The tools required for the project execution (SVN and Bugzilla) were set up and demonstrations were carried out to help everyone understand the usage. A common directory structure was included in the SVN tool for all the teams to follow and update. With respect to I2C, the datasheets of PCF8584 and PCA9564 were referred and studied in detail. The design specifications to be implemented were shortlisted. The templates for Design Document and Verification Document were discussed in detail and finalised Documentation The various test features were extracted from the PCA9564 datasheet. The Verification document was updated by adding the Overview, Resources, Budget and Schedule, Verification Environment, System Verilog Verification Flow etc. Document Change Record was added to the Verification document. The test cases which are to be given as inputs to the I2C block were built by studying the flowcharts of the various I2C modes. The assertion cases were moved to stage 3. The basic outline of classes in the environment was built and the work for Implementation phase was discussed. 551

5 3.3. Implementation The block diagram of the DUT to be verified was developed. The Verification document was updated by adding the Feature extraction plan, Stimulus generation plan, Coverage plan etc. The modification of classes to suit the project requirement was discussed. The assertions and directed testcases were written to pump the inputs to I2C block. The extra features to be added to test bench architecture were studied Verification The test cases were incorporated into the layered testbench. Verification Document Template was updated. Test cases for the extracted features were written. Coverage reports were generated for few blocks of I2C. IV. RESULTS The verification of three blocks of I2C module i.e. the Register Access block, SDA enable block and the Clock Divider block was carried out using SystemVerilog LTB. Few bugs were found during the verification which got assigned to the design team on the Bugzilla software. The waveforms of the design were obtained and were verified. The Code Coverage and the Functional Coverage reports were generated. The waveforms and the coverage obtained are shown as below REGISTER ACCESS BLOCK Figure 4 Code Coverage obtained for Register Access Block Figure 5 Summary of the Coverage 552

6 Figure 6 Functional Coverage obtained for Register Access Block Figure 7 Waveforms obtained for Register Access Block SDA ENABLE LOGIC Figure 8 Functional Coverage for SDA Enable Logic 553

7 Figure 9 Code Coverage for SDA Enable Logic Figure 10 Waveforms for SDA Enable Logic CLOCK DIVIDER BLOCK Figure 11 Functional Coverage for Clock Divider Figure 12 Coverage Report for Clock Divider 554

8 V. CONCLUSION Feature Extraction for PCA9564 has been done. Testbench for Slave Receiver Mode with Fault Handler has been developed The Register Access Block, SDA enable block and the Clock Divider block were verified using the Layered TestBench Architecture in the Mentor Graphics tool. Functional coverage and Code coverage has been done and the various reports are generated. The Version Control Tool (SVN) and the Bug Tracking Tool (Bugzilla) have been used to keep track of the codes and the bugs. VI. FUTURE WORK The test cases which were written for the extracted features can be used in future to test the different features of the I2C Module. The testbench can be automated for running different test cases. Master and slave modules can be integrated in Test bench to account for arbitration and multi-master modes. There are four modes of operation for the I2C Master Transmitter, Master Receiver, Slave Transmitter and Slave Receiver. Only few blocks of Slave Receiver Mode have been verified in this project. The other modes and the features related to those modes needs to be verified. REFERENCES [1] Santosh Kumar Patro, Jyoti Prakash Sahoo, Development of Open Verification IP For I2C Controller, a thesis, NIT Rourkela, [2] T Tarun Kumar, CY Gopinath, Verification of I2C Master Core using SystemVerilog-UVM, International Journal of Science and Research (IJSR),ISSN (Online): , Volume 3 Issue 6, June [3] Chris Spear, Greg Tumbush, SystemVerilog for Verification, Third Edition, [4] SystemVerilog 3.1a Language Reference Manual Accellera s Extensions to Verilog, Accellera Organization, Inc. [5] Mulani P., Patoliya J., Patel H., Chauhan D., Verification of I2C DUT using SystemVerilog, International Journal of Advanced Engineering Technology, Oct.-Dec., Vol. 1, No. 3, pp [6] Rakhi Nangia, Neeraj Kr. Shukla, Functional verification of I2C core using SystemVerilog, International Journal of Engineering, Science and Technology, Vol. 6, No. 4, 2014, pp [7] K Surya Narayana Reddy, K Jansi Lakshmi, Design and Verification of USB-I2C Bridge Protocol by OVM, IOSR Journal of Electronics and Communication Engineering (IOSR-JECE) e-issn: ,p- ISSN: Volume 8, Issue 2 (Nov. - Dec. 2013), PP [8] UVM, OVM and VMM description: [9] B.Santosh Kumar, L. Ravi Chandra, A. L. G. N. Aditya, Fazal Noor Basha, T. Praveen Blessington, Design and Functional Verification of I2C Master Core using OVM, International Journal of Soft Computing and Engineering (IJSCE) ISSN: , Volume-2, Issue-2, May [10] Deepa Kaith, Janakkumar B. Patel, Neeraj Gupta, An Introduction to Functional Verification of I2C Protocol using UVM, International Journal of Computer Applications ( ) Volume 121 No.13, July [11] Chhikara J., Sinha R., Kaila. S., Implementing Communication Bridge between I2C and APB, Computational Intelligence & Communication Technology (CICT), 2015 IEEE International Conference. [12] Mulani, P.D., SoC Level Verification Using System Verilog, Emerging Trends in Engineering and Technology (ICETET), nd International Conference. [13] NXP Semiconductors, I2C-bus specification and user manual, Rev. 6-4 April