Abstract The SoC level verification of AMBA AHB

Interconnect Matrix and I2C DUT is presented in this paper.

The verification environment has been developed and test
cases have been implemented for I2C DUT. The assertions and
monitor are developed to check the functionality of
Interconnect matrix of Multilayer AHB Lite. The whole
verification is done using SystemVerilog Hardware
Description and Verification Language. The verification
environment developed is reusable.
Keywords: SoC, AHB, I2C, Assertions
I. INTRODUCTION
The tremendous progress of VLSI technology enables the
integration of more than several million transistors in a
single chip to make a SoC (System-on-Chip). This has
made verification the most critical bottleneck in the chip
design flow. Roughly 70 to 80 percent of the design cycle
is spent in functional verification.
SystemVerilog is a special hardware verification
language to be used in function verification. It provides the
high-level data structures available in object-oriented
languages, such as C++. These data structures enable a
higher level of abstraction and modeling of complex data
types. The SystemVerilog also provides constructs
necessary for modeling hardware concepts such as cycles,
tri-state values, wires, just like Verilog hardware languages.
So SystemVerilog can be used to simulate the HDL design
and verify them by high level test case. In this paper, whole
implementation is done using SystemVerilog.
During verification of the SoC, a great deal of visual
simulation waveform inspection is required. The Simvision
waveform viewer is used and the observed waveforms are
also discussed in this paper.
An Introduction to DUT

Fig. 1. Contracture of SOC
The contracture of SoC used here which consists of AMBA
AHB masters, slaves and Interconnect matrix is shown in


fig 1. The DUT which is verified is Interconnect matrix of
AMBA AHB based SoC and slave 8 which is based on I2C
Protocol.
II. AHB ASSERTIONS
The assertions are written to verify Interconnect matrix
functionality as per Multilayer AMBA AHB Lite protocol.
The assertions written here for AMBA AHB Lite are
reusable to any AMBA AHB protocol. Writing assertions is
divided in two parts: (1) Master assertions which takes care
of signals going out to masters from matrix and coming in
from masters in matrix. (2) Slave assertions which takes
care of signals going out to slaves from matrix and coming
in from slaves in matrix. The Fig 2 shows the structure of
whole verification environment in case of assertion based
verification. There are various scenarios that are verified
using assertions. One of them is explained here:
CHECK_FOR_ADDRESS_STABLE: This scenario is
taking care of stability of address during HREADY signal
is low. The address is extended up to HREADY becomes
high as shown in Fig 3. If this functionality is not observed,
this assertion shouts so that error can be detected.
The master assertions and slave assertions are system
Verilog modules. The instance of both modules is taken in
top test bench and they are bound to top Testbench. To use
the signals of interconnect matrix from SOC as shown in
Fig. 1, nc_mirror function is used in VHDL Testbench.

Fig. 2. Assertion Based Verification Environment

SoC Level Verification using System Verilog

Purvi D. Mulani.
Lecturer, EC Dept, Charotar Institute of Technology, Changa

Second International Conference on Emerging Trends in Engineering and Technology, ICETET-09
978-0-7695-3884-6/09 $26.00 2009 IEEE 378




Fig. 3. An Example of Assertion CHECK_FOR_ADDRESS_STABLE

Advantages of assertion based verification: Assertions
are very user friendly means to check functionality of DUT
which saves time of verification engineer by eliminating the
need to look into monitors and checkers to verify all critical
functional scenarios and also by eliminating the need to
look at waveforms every time.
III. AHB MONITOR

AHB Monitor is developed to verify the interconnect
matrix DUT, which is made highly plug and play. AHB
monitor is System Verilog class which is a class which can
be reused to verify any AMBA AHB based DUT with little
modification (only the interface is needed to be developed).
The interface is developed in System Verilog to connect
class of monitor to the top level module which is
instantiated in test bench to connect to DUT. The monitor
contains checkers to check various functionality of DUT.
The verification environment which uses monitor is shown
in Fig. 4.

Fig. 4. Verification environment with AHB Monitor

IV. I2C DUT
The figure 5 below shows the architecture of environment
developed to verify the I2C DUT.
DUT can work in following four modes. Test cases are
written to verify the DUT for all possible four modes.
Master_TX: DUT is master and is in transmitting mode. So
slave part of verification environment has been used and it
is configured in RX mode to receive data transmitted by
DUT.


Fig. 5. Verification environment for I2C

Master_RX: DUT is master and is in receiving mode. So
slave part of our verification environment has been used
and it is configured in TX mode to transmit data to DUT.
Slave_TX: DUT is slave and is in transmitting mode. So
master part of our verification environment has been used
and it is configured in RX mode to receive data transmitted
by DUT.
Slave_RX: DUT is slave and is in receiving mode. So
master part of our verification environment has been used
and it is configured in TX mode to transmit data to DUT.
One of the configurations is explained with the help of
waveform.
i2c_master_tx_test.sv: DUT has been configured as
master and it is configured as a transmitter. To verify the
DUT, the verification environment is developed which is
slave and receives the data transmitted by DUT. First of all,
all configurations are done for DUT to work in master
mode, these configurations are done using AHB VIP. Then
DUT is master so it will generate clock and it will generate
start condition. And it will send address of the slave to
which it wants to communicate which is shown by signal
iic_sda_out in figure 6. This address is received by slave
part of our verification environment and then slave will
send acknowledgement to the DUT , after receiving
acknowledgement, DUT will send data to slave on the pin
iic_sda_out which will be received by slave on i2c_sda pin
which is signal of testbench. Then after data transfer has
been finished, DUT will generate stop condition which
indicates completion of transfer.

379




Fig. 6. i2c_master_tx_test result (i)



Fig. 7. i2c_master_tx_test result (ii)
V. CONCLUSION
In this paper, we have used System Verilog to put up a
verification environment which mainly focuses on
assertions and monitor development. Both the blocks are
reusable and can be reused easily for different design.
Using Assertions and the AHB Monitor can check the
DUTs protocol quickly. The I2C DUT has been verified
for its functionality using the verification environment
developed in SystemVerilog.
REFERENCES
[1] Han Ke, Deng Zhongliang, Shu Qiong Verification of AMBA Bus
Model Using SystemVerilog in The Eighth International Conference on
Electronic Measurement and Instruments
[2] ARM Ltd. AMBA Specification Rev.2.0, May
1999.http://www.arm.com
[3] SystemVerilog 3.1a Language Reference Manual Accelleras
Extensions to Verilog
[4] UM10204 I2C-bus specification and user manual Rev. 03 19 June
2007
[5] Micro computer control small area network specialists
[6] I2C bus Inter Integrated Circuits bus by Philips Semiconductors
TomMatouek tmd.havit.cz
[7] AHB-Lite Overview ARM



380