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.
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 549
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
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 550
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.
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 551
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.
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 552
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
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 553
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
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 554
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
International Journal of Current Trends in Engineering & Research (IJCTER)
Volume 2, Issue 4; April – 2016 [Online ISSN 2455–1392]
@IJCTER-2016, All rights Reserved 555
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.