verification of i2c module for multiprotocol serial controller · on the apb side, signals such as...

International Journal of Current Trends in Engineering & Research (IJCTER)

e-ISSN 2455–1392 Volume 2 Issue 4, April 2016 pp. 548 - 555

Scientific Journal Impact Factor : 3.468

http://www.ijcter.com

@IJCTER-2015, All rights Reserved 548

Verification of I2C module for Multiprotocol Serial Controller

Subham Punit Patro1, Shreela Dattawadkar

2, Shantala Kulkarni

3, Dr.Kiran Bailey

4 ,Sunil Matange

5

1Department of Electronics & Communication, BMS College of Engineering,

[email protected] 2Department of Electronics & Communication, BMS College of Engineering, [email protected]

3Department of Electronics & Communication, BMS College of Engineering, [email protected] 4Department of Electronics & Communication, BMS College of Engineering, [email protected] 5Department of Electronics & Communication, BMS College of Engineering,[email protected]

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 multi-

master 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

classes.


Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]


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




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.




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.

3.1. 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.

3.2. 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.




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.

3.4. 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




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




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




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, 2010.

[2] T Tarun Kumar, CY Gopinath,” Verification of I2C Master Core using SystemVerilog-UVM”, International Journal

of Science and Research (IJSR),ISSN (Online): 2319-7064, Volume 3 Issue 6, June 2014.

[3] Chris Spear, Greg Tumbush, “SystemVerilog for Verification”, Third Edition, 2012.

[4] SystemVerilog 3.1a Language Reference Manual Accellera’s Extensions to Verilog®, 2004. Accellera Organization,

Inc.

[5] Mulani P., Patoliya J., Patel H., Chauhan D., 2010. “Verification of I2C DUT using SystemVerilog”, International

Journal of Advanced Engineering Technology, Oct.-Dec., Vol. 1, No. 3, pp 130-134.

[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. 31-44.

[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: 2278-2834,p- ISSN: 2278-

8735.Volume 8, Issue 2 (Nov. - Dec. 2013), PP 27-31.

[8] UVM, OVM and VMM description: https://www.aldec.com/en/solutions/functional_verification/uvm_ovm_vmm.

[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: 2231-2307, Volume-2, Issue-2, May 2012.

[10] Deepa Kaith, Janakkumar B. Patel, Neeraj Gupta, “An Introduction to Functional Verification of I2C Protocol using

UVM”, International Journal of Computer Applications (0975 – 8887) Volume 121 – No.13, July 2015.

[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), 2009 2nd International Conference.

[13] NXP Semiconductors, “I2C-bus specification and user manual”, Rev. 6 - 4 April 2014.

verification of i2c module for multiprotocol serial controller · on the apb side, signals such as...

Documents