The Eighth International Conference on Electronic Measurement and Instruments
Verification of AMBA Bus Model Using SystemVerilog
Han Ke1 Deng Zhongliang1 Shu Qiong2
(1. School of Electronic Engineering, Beijing University of Posts and Telecommunications, Beijing 100876, China; 2. School of
Electronic and Information Engineering, Beihang University, Beijing 100083, China)
Abstract: A verification environment to verify an ARM-based
SoC (System-on-Chip) by using SystemVerilog is presented in
this paper. The new verification constructs can be easily reused
for the objected-oriented feature of SystemVerilog. The paper
also introduced how to design the AMBA (Advanced
Microprocessors Bus Architecture) verification IP (Intellectual
Property) by SystemVerilog, which include AHB (Advanced
High Performance Bus) Master and AHB Monitor. The
verification IP can be reused to verify any AMBA protocol
based SoC. To reduce the time spending in the verification, a
reference model designing method is also discussed in the
paper.
Keywords: SoC, AMBA, SystemVerilog, Reference model,
Verification IP
1 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. However, the test program
need to provide more automation to maximize the
functional coverage from each test case and reduce the
time needed to create a test case[1-3]. So there is a
tradeoff between the sophistication of the verification
program and the time spent developing it.
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
1-4244-1135-1/07/$25.00 ©2007 IEEE.
1-776
ICEMI’2007
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, how to put up the simulation
environment using SystemVerilog is introduced. The
simulation environment using by SystemVerilog is
efficient and high-performance. The paper discusses
the usage experience to verify an SoC by the AMBA
verification IP and the AHB monitor.
During verify the SoC, a great deal of visual
simulation waveform inspection is required. To
generate the waveform will be time-consuming. The
paper presents SoC bus transaction verification IP
written by SystemVerilog, which are called reference
model to compare the behavior of the DUT. The IP
can be integrated into SystemVerilog simulation
environment. By using the reference model, we can
greatly reduce the waveform inspection time.
2 SystemVerilog Verification
Environment
The main purpose of the verification environment
is to generate stimulus, apply stimulus to the DUT
(design under test), and check results to verify that the
function is correct. Then test cases may be modified or
added referring to the coverage reports. By using
SystemVerilog we can easily do these works.
2.1 Introduction of the Verification Environment
Figure 1 shows the contracture of the
SystemVerilog verification environment. The
environments include the DUT written by Verilog
HDL, SystemVerilog test bench which include
SystemVerilog interface, simulation top module, and
test program. In the SystemVerilog test bench, the
generator can be used to create constrained random
test vectors. These test vectors are sent to the driver,
The Eighth International Conference on Electronic Measurement and Instruments ICEMI’2007

and then the driver can stimulate the DUT. The

System Verilog Testbench
monitor generates verification reports on states,
Coverage
transactions and model messages. Also the result can
be checked by the checker and added to the coverage Generator Checker

reports. These test bench components are all designed Channel Channel

by SystemVerilog. The object-oriented feature of Driver Monitor

SystemVerilog can greatly enhance the reusability of

test bench components. Modport Modport
As is divided in the Figure 1, there are three parts of Interface

the verification environment. The first is the DUT, DUT

which is the design top of the SoC to be verified. The
second is the test program (SystemVerilog Test bench),
which include the main test tasks. The interface part
(Interface) is the interface to be used to joining the
DUT and the test program. All the parts are instanced
in the test-top. The verification environment will also
be reused, without modifications, by as many test
cases as possible to minimize the amount of codes
required to verify the DUT.
Fig. 1 SystemVerilog Verification Environment
The DUT we designed is shown in the Fig. 2. It is
an AMBA based SoC that include the AHB bus and
the APB bus. Two AHB masters and four AHB slaves
are integrated into the SoC. AHB masters are
ARM7TDMI and DMA. AHB slaves are ROM,
SRAM and APB BUS.

ARM 7TDMI
Reference
DMA Generator (Replace by
Model
VIP Master)

Master Master
Arbiter AHB AHB
/Decoder Monitor
Slave Slave Slave Slave

Peripheral Bridge ROM SRAM Flash

APB

Fig. 2 Contracture of the DUT

2.2 Use of the Verification IP
To verify the DUT in the SystemVerilog
environment, we replace the ARM7TDMI by a VIP
(Verification IP) Master, which is designed by
SystemVerilog. It is a class to be reused in the
verification. The VIP Master serves as a driver
including trans-actor, and stimulates the DUT. To
observe the behavior of the VIP master and the
response of the DUT, An AHB Monitor IP is used
which can monitor the AHB protocol [4]. The Monitor
IP is also designed by SystemVerilog as a class.
The VIP Master and the Monitor IP have the
physical level interface and the transaction level
interface. The transaction level interface lets the
1-777
higher layers of the verification environment, such as
the generator, stimulate the DUT. The connection
between the driver and the generator requires a
channel instance. SystemVerilog gives a template
class, vmm_channnel[5], which can be specialized
based on the data or transaction descriptor it will
carry.
The physical level interface is used to connect the
DUT. By SystemVerilog we use the modport
definition to use the physical level interface. The
interface between the DUT and the test program
which include the VIP Master and the Monitor is
defined in Fig. 3. The definition includes a list of all
the pins, a list of clocking signals, two clocking blocks
of related clocked signals and two modports defining.
The Eighth International Conference on Electronic Measurement and Instruments ICEMI’2007

The ARM7TDMI master ports are wired by the VIP Generate configuration Wait for end
env.gen_cfg() env.wait_for_end()
master. The ports used by the monitor are wired
directly from the AHB bus. Build environment Stop environment
env.build() env.stop()
interface test _ahb_if(input hclk);
logic hresetn; Reset the DUT Sweep DUT and reports
logic [`AHB_DATA_WIDTH-1:0] hrdata; env.reset_dut() env.cleanup()
ĂĂ
//interface only used for the monitor
logic [`AHB_ADDR_WIDTH -1:0] haddr; Configure DUT Report pass/fail
logic hsel; env.cfg_dut env.report()
logic [`AHB_DATA_WIDTH-1:0] hwdata;
logic hgrant;
Start environment
logic hwrite; End Test
env.start()
ĂĂ
//interface only used for the VIP Master
logic [`AHB_ADDR_WIDTH -1:0] arm 1_haddr; Fig. 4 Executing Flow in the Verification
logic [`AHB_DATA_WIDTH-1:0] arm1_hwdata;
logic [`AHB_DATA_WIDTH-1:0] arm1_hrdata;
logic arm1_hgrant;
logic arm1_hwrite;
2.3 VIP Master Behavior Analysis
ĂĂ
clocking monitor_cb @(posedge HClk);
//default input #1skew output #0;
The VIP Master has two operating modes:
input hresetn; protocol-related and buffer access. Protocol related
input hrdata;
input haddr; features generate bus cycles and transfer responses to
input hesl;
input hwdata; slave response types. Buffer access features allow us
ĂĂ
endclocking
to create burst transfers in advance and reuse the burst
clocking master_cb @(posedge HClk); information. So it can give the DUT proper test to
default input#1 output #1;
input hresetn verify DUT’s protocol feature. VIP Master is not as
output arm1_haddr;
output arm1_hwata;
same as the ARM model. In the design, we use the
input arm1_hrata; ARM7TDMI core. The ARM7TDMI core uses a
output arm1_hwrite;
ĂĂ pipeline to increase the speed of the flow of
endclocking
modport Master(clocking master_cb); instructions to the processor. This allows several
modport Monitor(clocking monitor_cb);
endinterface
operations to take place simultaneously. A three stage
pipeline is used so instructions are executed in three
stages: fetch, decode and execute, as shown in fig
Fig. 3 Modport Define in the Test bench 5.While the instruction to be decoded by ARM may be
not necessary to verify.
During the simulation, the generator will transfer
test vectors by the channel to the VIP Master. Then the
master will drive the slaves. The reference model is
used to dynamically predict the response of the VIP
Master and compare with the data from the real slave.
The AHB monitor checks the bus protocol such as
which master requesting the bus and getting granted.
It also checks other AHB protocol such as the burst
type, the transfer size, and address increment size. Fig. 5 ARM7TDMI Simulation Waves
The executing flow of the SystemVerilog
simulation environment is shown in Fig.4. The first
step is to generate the configuration and connect
environment components, such as VIP master, monitor
and reference model. After reset the DUT, the
configuration will be downloaded into the DUT. Then
the VIP master, monitor, generator and reference
model will start and test begin. When the test is over,
logs will be generated and the designer can check the
reports. Fig. 6 VIP Master Simulation Waves

1-778
The Eighth International Conference on Electronic Measurement and Instruments
The VIP Master will not simulate the same behavior.
As shown in fig 6, the VIP Master need not fetch the
next command when executing an instruction, because
all the commands have been decoder when the test
vectors were designed. The VIP Master can verify if
the DUT behavior confirm to the AHB protocol and
execute the necessary commands. So it can be faster
to verify the function feature of the DUT than the
ARM.
3 Design of the Reference model
Rreference model that we designed is used to
dynamically predict the response of the DUT. As
shown in fig. 1 and fig. 2, the stimulus applied to the
DUT is concurrently provided to the reference model.
The reference model performs all the operations on
the stimulus to produce the form of the final response
and then inserts it in a data structure. Response from
the reference model is forward to be the same as the
DUT’s .
The reference model is also a class which includes
local variables and methods. It has the transaction
level interface. So it can get the VIP Master’s stimulus
by the channel to share the data contracture of the VIP
Master. Then the stimulus will be stored in the
reference model and expect response will be given to
verify the DUT. The comparison of the observed
response with the reference model’s is performed at
the transaction level, not at the cycle-by-cycle level.
The reference model first waits for a transaction to
be generated and then waits for the monitor to notify
that this transaction occurred. In order to determine
the transaction correctness, the following rules are
applied: Each generated WRITEING transactions are
stored to a register file; each generated READING
transactions get their data field filled from the register
file, so to provide an expected result. Each transaction
is then compared on a first-come first-serve basis.
In the SoC shown by the Fig.2, we want to verify
the SRAM AHB controller and Flash AHB controller.
So the reference model should record the SRAM and
Flash memory behaviour.
To use the Flash, the operation contains READ,
WRITE, PAGE ERASE and MASS ERASE. The flash
memory may be initiated, so we can read the memory
before we write the memory.
(1) Initiate the reference model by checking all the
memory initiate state.
1-779
ICEMI’2007
(2) Decode address; if an address is in the range of
the Flash memory map, then the Flash reference
model begin working.
(3) Read operation, the address will be stored, and
the data store in the address will be output to
compare with the response of the DUT.
(4) Write operation, the address will be stored and
the write data will be store in.
(5) Page erase, all the page unit address will be
calculate out and the memory will be filled with
16’hFFFF.
(6) Mass erase, all the memory will be filled in 16’
hFFFF.
The reference model includes initiate part,
memory address decoding part, operation checking
part, and address/data store part. The initiate part
can get all the memory initiate state by the VIP master.
The SRAM must be written before READ operation.
So which the reference model needs to do is to store
the write address and the write data. When read
address is given, the reference model should give the
data if the address has been written data in. Else, the
reference model should simulate the error information
like the SRAM.
Then a report will be generating when the
simulation is end. In the report we can debug the DUT
design. As shown in table 1, if the DUT responses
difference from the reference model, it will be
lightened in the report.
Table 1 Report For the Verification
Table 1 shows the results of the verification by using
reference model. The fail case is TC04-2, TC05-1,
TC06-1. These test cases are mass erase. The logs will
give more specific reports about the error.
4 Conclusions
In this paper, we use SystemVerilog to put up a
verification environment of the ARM-based SoC. The
environment can be reused easily for different design.
Using VIP Master and the AHB Monitor can check the
The Eighth International Conference on Electronic Measurement and Instruments ICEMI’2007

DUT’s protocol quickly. The reference model can be

considered as verification IP, and it can replace
time-consuming visual inspection for bus transaction
sequence verification. But using reference model
depends heavily on their availability. In this paper we
design a reference model that can be used to verify
SRAM and Flash controller. To verify other different
DUT we need to design different reference model.
How to enhance the flexible of the reference model to
verify different module needs to be discussed.
References

[1]C.Rowen. Reducing SoC simulation and development

time .Computer, 2002, 18:32-45.
[2]Rajsuman,Rajsuman. System-on-a-Chip: design and test,
Santa Clara: Advantest America R&D Center, 2000:5-27
[3]Faisal I.Haque, Khizar A.Khan, The Art of Verification with
Vera, California: 2001: 2-15
[4]ARM Ltd. AMBA Specification Rev.2.0, May
1999.http://www.arm.com
[5]Janick Bergeron, Eduard Cerny, Alan Hunter, et al.,
Verification Methodology Manual for SystemVerilog,
Synopsys Inc., 2006: 407-417
Author Biographies

Han Ke, male, born in 1980, is currently working toward the

PhD degree in the School of Electronic Engineering, Beijing
University of Posts and Telecommunications, and the major
subject is SoC technique and design of the testability(DFT) .
Deng Zhong-liang, male, born in 1965, Professor, is the dean
of in the School of Electronic Engineering, Beijing University
of Posts and Telecommunications. Currently, his research
emphasis focuses on the SoC and MEMS design
Shu Qiong, female, born in 1981, has received the MS Degree
in Electronic Engineering at the Beihang University. She is
now working on the design and verification method of SoC.

1-780