Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]

IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

Architecture Analysis and Verification of I3C

Protocol
Anusha Mahale Dr Kariyappa B S
Department of ECE, Department of ECE
R V College of Engineering R V College of Engineering
Bengaluru-560059 , India Bengaluru-560059 , India
Email:[email protected] Email :[email protected]

Abstract— In VLSI industry the design cycle is categorized mixture of different message types such as: I2C-like single
into Front End Design and Back End Design. Front End data rate (SDR) messages which use SCL clock speeds of up
Design flow is from Specifications to functional verification of to 12.5 MHz and HDR messages which achieve higher data
RTL design. Back End Design is from logic synthesis to rates. The specification also provisions for peer-to-peer
fabrication of chip. Handheld devices like Mobile SOC’s is an communication between I3C slaves [3].
amalgamation of many components like GPU, camera, sensor,
display etc. on one single chip. In order to integrate these Verification of SOC is complex when multiple IC’s are
components protocols are needed. One such protocol in the integrated and communication between IC’s is major hurdle.
emerging trend is I3C protocol. I3C is abbreviated as Verification Engineer must spend rigorous time to learn IP
Improved Inter Integrated Circuit developed by Mobile code, building complex test bench and developing test cases
Industry Processor Interface (MIPI) alliance. Most probably foreach IP is tedious. One solution is reuse of IP testbench
used for the interconnection of sensors in Mobile SOC’s. The and testcase. The paper [7] here depicts the reusable
main motivation of adapting the standard is for the increase verification environment for SOC verification. The main
speed and low pin count in most of the hardware chips. The advantage is ease of debugging and less complexity. The
bus protocol is backward compatible with I2C devices. The paper [9] also describes an efficient approach to verify SOC
paper includes detailed study I3C bus protocol and developing and provides verification flow by using IP test bench ad test
verification environment for the protocol. The test bench
case based on UVM. It is well established verification
environment is written and verified using system Verilog and
approach for IP and SOC Using the flow, both SOC and IP
UVM. The Universal Verification Methodology (UVM) is base
class library built using System Verilog which provides the engineers can work in their own specialized area and
fundamental blocks needed to quickly develop reusable and collaborate on debugging.
well-constructed verification components and test
environments. The Functional Coverage of around 93.55 % II. I3C PROTOCOL
and Code Coverage of around 98.89 % is achieved by
verification closure.
I3C protocol is new standard for mobile sensor interface
developed MIPI alliance group. The new I3C standard
Keywords—I3C, MIPI, SOC, UVM, VLSI supports speed up to 12.5 MHz and new communication
modes like HDR- DDR which transfers data on both the
edges. I3C is new protocol introduced for mobile sensor
I. INTRODUCTION proliferation that combines the advantage of I²C and SPI is
Communication interface plays important role for introduced. New features like in band interrupt, dynamic
communicating with various subsystems of the embedded addressing and power management. I3C interface is intended
system. The interface classified as Onboard communication to improve upon the features of the I2C interface, preserving
interface and external communication interface. The protocol backward compatibility. Two main concerns are paramount
that interconnects various components or subcomponents for the I3C interface: The use of as little energy as possible
within a system is referred to as onboard communication in transporting data and control, while reducing the number
interface. Some of the example of Onboard Communication of physical pins used by the interface [3].
interface are serial Interfaces like I2C, UART, SPI etc. and I3C bus supports multi-master configuration, so bus can
parallel bus interface[1,5]. have more than one master. The main master can be only one
I3C stands for Improved Inter Integrated Circuit i.e. i.e. the current master it can pass the ownership to the
improved I2C. It is mainly used to interface sensor secondary master present on the bus. I3C device with both
peripherals. As compared to I2C it supports new the configuration capabilities i.e. to be master and slave
communication modes, higher speeds. The I3C interface was cannot function as both role at the same time, it must be
developed by a working group that included participation by configured either master or either slave[4]. Current master
engineers from Advanced Micro Devices, Inc., Analogix role only one device can be configured to be the main master
Semiconductor, Inc., Cadence Design Systems, Inc., Google, i.e. current master. The block diagram of bus configuration is
Inc., Intel Corporation, Knowles Electronics, Lattice shown in Figure 1.
Semiconductor Corp., MediaTek Inc., NXP Semiconductor, I3C master has following roles:
Qualcomm Technologies, Quick Logic, Sony Corporation,
STMicroelectronics, Synopsys Inc. and others [4,6]. 1. I3C main master
I3C is a two-wire bus: serial data (SDA) corresponds to 2. SDR-only main master
bidirectional serial data; serial clock (SCL) corresponds to 3. I3C secondary master
serial clock that can act as either a clock pin or a data pin in
certain high-data-rate (HDR). The I3C bus supports a 4. SDR- only secondary master.

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 930

 Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]
IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

I3C slave has following roles: A. Testbench Architecture

1. I3C slave
2. SDR – only I3C slave

Figure 1: I3C bus configuration[2]

Initially I3C bus is always configured only in SDR mode
for data transfer. The protocol supports two modes Single
Data Rate (SDR) mode and High Data Rate (HDR) mode.
1. Single Data Rate (SDR) mode
The default mode of data transfer on the I3C bus is
Single Data Rate (SDR) mode. It used to send messages
Figure 3:Testbench Architecture
from main master to the slave devices. Also, SDR modes
used to enter other modes and sub modes. The testbench environment is developed using System
Verilog and UVM. Figure 3 depicts the verification
2.High Data Rate (HDR) mode
environment. UVM is a framework for the verification
The other mode of data transfer in I3C protocol is HDR environment. It also gives base class library and reusability
wherein data transfer takes place in both the edges of the feature. The universal verification components are described
clock. There are three defined HDR modes: in the verification methodology section [8].
1. HDR – DDR (Double Data Rate) B. Verification Methodology
2. HDR – TSL (Ternary Symbol Legacy inclusive In traditional verification the testbench was not efficient
bus) enough to test large complex designs, a language was
required to verify the DUT which would improve the
3. HDR – TSP (Ternary Symbol Pure bus) efficiency as well and cover the drawbacks of traditional
I3C Address format for data transfer from device starts testbench. The approach is to use System Verilog and UVM
with start or repeated start bit initiated by Master device which provides coverage driven verification. UVM is widely
followed by broadcast address or dynamic address of slave accepted standard for implementing coverage driven
device then Read or Write bit as 0. After the address phase verification. UVM can be of transaction data related and
starts the data phase where it sends data to be written or read. testbench component related [10,11].
It is ended by T bit i.e. is Transition bit. Transaction Data Related:
In SDR write transfer it is determined as parity bit of ➢ UVM Sequence Item
preceding eight bits. In read transfer it signifies slave to end
of data read and allows master to abort read. ➢ UVM Sequences
Testbench Component Related:
➢ UVM Driver
➢ UVM Sequencer
➢ UVM Monitor
➢ UVM Agent
Figure 2: I3C address header[3]
➢ UVM Virtual Sequencer
III. VERIFICATION METHODOLOGY ➢ UVM Environment
I3C protocol verification starts with the verification plan. ➢ UVM Test.
The first thing in plan is to identify the verification
requirements provided. After the requirements are identified,
the verification engineer develops verification environment 1. Sequence Item
as per the plan using UVM base class library. The functional
correctness of the design is verified to avoid any bug further Sequence Items are nothing but transactions or data
using test bench environment created. items. It is main mode of communication between uvm
sequencers and driver also uvm agents and scoreboard.

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 931

 Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]
IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

Transactions are generated by a sequencer and sent to driver. sent to the driver which in turn drives the DUT ports. For
Drivers use the information in these transactions to drive example, for testing an AHB interface, the sequencer will
DUT signals. Transactions are sometimes referred to as create AHB read and write transactions.
sequence items, these objects contain data fields, constraints
and functions and tasks used to manipulate the transaction. Class Hierarchy:

Class Derivation Hierarchy: • All sequencers should be derived from the

uvm_sequencer class.
• all transactions/ sequence items must be derived
from the uvm_sequence_item class.
• the uvm_sequence_item is derived from the
uvm_transaction class.
• the uvm_transaction derived from uvm_object
class.

Figure 6: Steps for Creating a Sequencer

4. Driver
Drivers drive transactions on to DUT, they convert
transactions that are generated by the testbench environment
into signal level transitions.
Driver performs three functions
Figure 4: steps in creating sequence items • requests the sequencer to generate the next
2. Sequence transaction
Sequences are a group of transactions that focus on a • convert these transactions onto pin wiggles that
operation of the DUT. It is ordered collection of one or more can be driven on the DUT
sequence items. It is intended to test a scenario during the
verification process • sends the transaction information to the
scoreboard
Class Hierarchy:
• uvm_sequence_item is base class for user
defined sequence items
• uvm_sequence_base is base class for sequences
• uvm_sequence # (REQ, RSP) is parameterized
by the transaction type

Figure 7: Steps in Creating Driver Class

5. Monitor
Monitors are used to monitor signal transitions that occur
on the bus. They convert these signal level transitions into
transactions. The monitor sends these transactions to
scoreboards and coverage collectors for analysis purposes.
The monitor class is derived from uvm_monitor base class.

Figure 5: Steps in Creating Sequence Class

3. Sequencer
Sequencers are used to generate transactions required for
a given test connected to the driver. These transactions are

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 932

 Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]
IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

Figure 8: Steps in Creating Monitor Class.

Figure 10: Steps in Creating Scoreboard
6. Agent
Agents are reusable verification components that can
contain a sequencer, a driver, and a monitor. Although 8. Environment
sequencer, driver, or monitor can be reused directly, it Environment is the top-level container component that
requires a lot of work for the integrator to understand the holds different parts of a testbench. It contains all the agents
intricacies of these components. On the other hand, the agent needed in your testbench.
is a more abstract container that is easy to reuse.
Role of the UVM Environment:
Agents are used to initiate transactions, monitor
transactions, and respond to transactions. • Instantiates and initializes all required agents
during the build phase

Two types of agents: Active and Passive • Configures the testbench environment as
required; specifically, it sets up the appropriate
Active agent is one which contains driver and sequencer number of masters and slaves
and drives transactions to DUT.
• Creates the configuration objects that are
Passive agent is one which has only monitor and do not required to connect the UVM driver with the
drive the DUT. appropriate virtual interface or proxy class
• Connects the virtual sequencer to all the
sequencers in the testbench, which enables the
virtual sequencer to provide centralized control
to all sequencers
• Connects the scoreboard to all the agents
• The environment is also the best place for doing
factory overrides

Figure 9: Steps in Creating Agent Class

7. Scoreboard
Scoreboards are crucial in any self-checking environment
to ensure proper operation of the DUT. They verify the
proper operation of the DUT by keeping track of all the
transactions in the system. For example, if a slave contains a
memory component, the scoreboard keeps track of all the Figure 11: Steps in Creating Environment
write and read transactions and checks if the slave is 9. Test
returning the right value.
Tests are responsible for two important items
• Instantiates environment

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 933

 Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]
IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

• Starts appropriate virtual sequence on the virtual C. Implementation Block Diagram

sequencer. The virtual sequence starts multiple
sequences on the different sequencers.
Steps in Creating Test:
1. create a base class that will serve as the parent for all
the tests.
- extend the base class from the uvm_test class
- register the class with the factory
- set up the environment
- set up the virtual sequencer
- implement the build_phase (), connect_phase () and
run_phase () functions
2. create different classes for each new test
- derive each test from test base class
- declare the virtual sequence
- implement the phase functions would like to override

Figure 14: Implementation Block Diageam

The implementation block diagram is shown in figure 14.
The DUT I3C slave is connected to VIP environment which
has the interfaces of VIP master, VIP I3C slave and VIP I2C
Slave. It is configured via config database i.e., how many
instances of master and slave it can have.
The monitor block collects the transactions from the
interface and send it has scoreboard, checkers and functional
coverage which does the required functionality. Scoreboard
will compare the output responses; Checkers will check for
the assertions and functional coverage will cover the cover
Figure 12: Steps in Creating Test bins. Test will initiate the master slave sequences via virtual
10. Testbench Top sequence and send it to VIP env.
Testbench top module connects DUT and verification D. Test Cases
components through virtual interface. In the top module Test cases are created in order to test the functionality of
libraries are imported and instance of virtual interface is design has met the requirements or not. Test cases are
called. The DUT instance is mapped with virtual interface. extended from the test class which is in turn extended from
The generation of clock and reset signals take place in the uvm_test base class.
topmost module. The run_test () is called in this module.
1. Base test
Base test is the main test from which other test cases can
be extended. The main slave initialization is done by this
test. This test case will do the following task such as reset,
clock generation, i3c initialization by dynamic address
allocation and writing config register as per specification.
Steps:
1. Declare all the instances of sequences, interfaces
and test configuration.
2. Instantiate environment and main slave sequence.
3. Declare the variables to hold objects.
4. Implement the phases.
5. Call run test method where initialization takes
place.

Figure 13: Steps in Creating Testbench top

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 934

 Proceedings of the Third International Conference on Electronics Communication and Aerospace Technology [ICECA 2019]
IEEE Conference Record # 45616; IEEE Xplore ISBN: 978-1-7281-0167-5

2. SDR/HDR read / write test

SDR is single data rate mode where data transfer takes
place on the single edge of the clock. The test case is
extended from base test case. The test case will do the
following task
HDR is high data rate mode where data transfer occurs on
both the edges of clock. The test case is extended from base
test case. The test case will do the following task
1. Configure the test
Figure 17: Functional Coverage
2. Implement the base test method
3. In base test method call the transaction for
read/write
Figure 18:Code Coverage
IV. RESULTS AND DISCUSSIONS
The result presented here depicts the verification of the V. CONCLUSION
protocol and the test cases applied to check the behavior. This paper presents the verification flow of the protocol
to be verified and gives detailed study about the UVM
methodology. UVM is the methodology for verifying any
complex SOC with reusability of components across
different IPs.
The I3C IP design is verified using UVM and System
Verilog. UVM provides sophisticated testbench environment
and base class libraries to verify the IP. Coverage analysis is
also carried out to give out the code coverage and functional
coverage. The Functional Coverage of around 93.55 % and
Code Coverage of around 98.89 % is achieved by
Figure 15: UVM report summary verification closure. The coverage can be further improved
by covering the part of code not getting hit and writing test
Figure 15 depicts the UVM report summary of the base cases to achieve the targeted goal.
test. It gives the UVM display information, error and fatal
that occurred while running a test.
REFERENCES
[1] I2C-bus specification and user manual Rev. 6-4, Philips
semiconductors , April 2014.
[2] Introduction to the MIPI I3C Standardized Sensor Interface,MIPI
Alliance Group, December 2016.
[3] Specification for I3C Improved Inter Integrated Circuit Version 1.0 –,
mipi alliance, 23 December 2016.
[4] AMBA® 3 AHB-Lite Protocol v1.0 Specification, ARM, June 2006.
[5] High Performance and Scalable Sensor Connectivity with MIPI I3C, ,
Synopsys , December 2017.
[6] M. Sukanya and K. Gavaskar, “Functional Verification Environment
for I2C master controller using System Verilog”, International
Conference on Signal Processing, Communications and Networking
Figure 16: Base test pass (ICSCN-2017), , Chennai, India, March 16-18, 2017.
[7] Zheng-wei HU, “I2C Protocol Design for Reusability”, Third
Figure 16 depicts the test case pass result. If the uvm International Symposium on Information Processing, IEEE, 2010.
error and fatal is other than 0 i.e. if error occurs, it will give
[8] Lakshmi Manasa Kappaganthu et.al “I2C Protocol and its Clock
test case as fail. Stretching Verification using System Verilog and UVM” International
Conference on Inventive Communication and Computational
Figure 17 shows the functional coverage result where in Technologies (ICICCT 2017).
the first two bins are not covered and the green colored ones [9] The Questa Verification Solution, Functional Verification datasheet,
are the one which are covered and hit count is the number
2017.
which tells how many times it has covered by the code.
[10] Universal Verification Methodology (UVM) 1.2 User’s Guide,
Functional coverage measures the functionality coverage by Accellera, 2015.
the design and the specifications are to be known. [11] Universal Verification Methodology (UVM) 1.2 Class Reference,
Accellera, 2014.
[12] Frequently Asked Questions for MIPI I3C® v1.0 and I3C BasicSM
v1.0, FAQ Version 1.0, mipi alliance, December 2016.

978-1-7281-0167-5/19/$31.00 ©2019 IEEE 935