I2C-Master Core Verification
Project
Nir Zepkowitz & Amir Nahir
Supervisor : Sagi Rotem
Project Goal
• to provide a testing environment for the
I2C-Master Core and an easy-to-use API
for test writing.
• Perform direct and random tests on the
given implementation.
• Define coverage points and collect
coverage.
Background – the I2C Protocol
• 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 applications
requiring occasional communication over
a short distance between many devices
Example - I2C write transaction
Start Signal
Slave Address Transfer
(address = 0x7e)
Ack
Memory Address Transfer
(address = 0x01)
Ack
Data Transfer (data = 0x0a)
Ack
Data Transfer with Auto Increment Stop
AckSignal
(data = 0x14)
Verification Environment
Master
I2C-Master Core - DUT
2
Slave
Slave
Slave
….
Slave
Implementing the Verification
Environment
• The Test Bench and tests are all
implemented in Verisity’s ‘e’ language.
• Simulation is performed on the Specman
Elite simulator (with the virsim HDL
simulator).
Test bench Structure
Our test bench is comprised of three main modules:
• WishBone Master Module – this module represents
the master of the DUT, including capabilities to
perform WishBone transactions and checking that
the DUT responds accordingly.
• Slave Module – this module represents the DUT's
slave, it is able to perform in a multiple slave
environment and respond to DUT transactions on the
bus.
• Environment Module – engulfs the two other modules
and gives the user (test writer) easy access.
Test bench Internal Structure
Environment
Monitor
Injector
WishBone_Master
Injector
Slave
DUT
Injector
Monitor
Monitor
Checker
Checker
Checker
Monitoring
Monitors are strictly passive components; their
duty is to track interactions to, from and
within the DUT. Our Test Bench includes the
following monitors:
• Slave monitor: a complex state machine which
tracks interactions between the DUT and the
slaves on the scl / sda bus; based on those
interactions, the slave's memory is updated.
• WishBone monitor: tracks read and write
transactions to and from the DUT's
registers.
Checking
Our Test bench performs two kinds of
verification:
• End-To-End verification: verifying that
transactions initiated by the Master
(write, read) will be properly translated
by the DUT to actions on the bus
towards the slaves.
Checking (cont.)
• Local checkers:
• WishBone checker that will verify that the
registers are properly accessed via the WB
interface, and that their value is right.
• Clock frequency checker: verifying that the scl
clock is in the right proportion to the PRER value.
• Bit controller checker that will verify that the
different signals (start, repeated start, stop) are
properly generated by the DUT.
• Byte controller FSM simulation: will be
implemented according to the spec and will verify
that the DUT's byte controller FSM works
properly.
Testing Methodologies
Our test plan consists of two parts:
• Direct testing: we performed tests on
the DUT according to basic scenario we
believe cover most of the DUT's
functionalities.
• Random testing: by constructing simple
building-blocks we will be able to easily
perform massive random testing.
Simulation
SCL frequency bug
• As part of it’s functionalities, the DUT
generates the bus’s clock.
• Clock frequency is user defined by
writing to the PRER register.
• The resulting scl frequency should be
(according to the spec):
(input clock frequency) / (4 * PRER value)
SCL frequency bug (cont.)
• Using our scl frequency checker, we
discovered that the resulting frequency
is actually
(input clock frequency) / (5 * PRER value)
SCL frequency bug (cont.)
SCL frequency bug (cont.)
Summary
• We believe that our Test Bench enables
user to easily write tests for the I2C
Core.
• We hold that our checkers combined
with the direct and random testing fully
verified the core’s clean design (except
for the scl bug).