AMBA AHB Bus Potocol Checker with Efficient

Debugging Mechanism

Yi-Ting Lin, Chien-Chou Wang, and Ing-Jer Huang

Department of Computer Science and Engineering National Sun Yat-sen University
Kaohsiung, 80424 , Taiwan
itlin@esl.cse.nsysu.edu.tw
m933040032@student.nsysu.edu.tw
ijhuang@cse.nsysu.edu.tw

Abstract—Bus-based system-on-chip (SoC) design becomes the

major integration methods for shorting design cycle and time-to-
market, thus how to verify IP functionality on bus protocol is a
challenge. Traditional simulation-based bus protocol monitors
can check bus signals obey bus protocol or not, but they often
lack of efficient debugging mechanisms .We propose a rule-
based bus protocol checker, it contains 73 related bus protocol
rules to check bus signal behavior, and two corresponding
debugging mechanism to shorten debugging times. Error
reference table can summarize design under tests (DUTs) have
been violated; Windowed trace buffer can capture multiple
errors’ history data that helps designer debug efficiently.

I. INTRODUCTION
In recent years, on-chip bus architecture becomes the
major integration method for implementing a SoC. On-chip
bus specification provide a standard interface that enables IPs
can communicate with each others. Designer just integrates
his own IPs with third party IPs into the system to
significantly reduce design cycles. Thus how to efficiently
make sure the IP functionality works correctly after
integrating to dedicate bus architecture is a great challenge.
There are many verification works based on formal
verification [1] [2] [3] [4] [5] [6]. DUTs are modeled as finite
state transition and the properties are written by using
Computation Tree Logic (CTL) [7], then uses verification
tools [8] [9] [10] to verify DUT’s behaviors. Formal
verification can verify DUT’s behavior thoroughly, but it
needs to model all environment components not only the
DUTs we want to verify. The other verification is monitor-
based approaches [11] [12] [13] [14]. The specification is
defined as a set of rules, and then DUT is checked cycle by
cycle during simulation to make sure DUT obeys all these
rules. This method is efficient when we integrate several IPs
into a pre-verification environment.
But many errors may occur in real-time that monitor-based
approaches often cannot find errors in simulation environment.
Thus several commercial verification IPs provide hardware
protocol check to solve this problem. Although protocol
Fig. 1 AHB Protocol Checker Architecture
checkers can find errors on real-time environment, we need
more efficient ways to debug the system, only violated rules
cannot help designer to rapidly find errors.
We propose an AMBA AHB bus protocol checker based
on monitor-based method. There are total 73 rules we have
that include master, slave, reset, bus components, and
performance issue. In order to improve debugging ability, we
propose two debugging mechanisms. An error reference table
can summarize total errors that have been occurred in
simulation. A windowed trace buffer can capture multiple
error bus signals, which designer can find protocol errors
according to these waveforms.
II. AHB PROTOCOL CHECKER ARCHITECTURE
Fig. 1 shows AHB Protocol Checker (HPChecker)
architecture, which contains four main function blocks:
Protocol Checker, Configuration Registers, ERROR
Reference Table, and Windowed Trace Buffer. We will
introduce these four blocks individually.

978-1-4244-1684-4/08/$25.00 ©2008 IEEE 928


Fig. 2 Error Reference Table Illustration
A. Protocol Checker
HPChecker is a rule-based protocol checker, thus how to
establish a set of well-defined rules is very important. We
reference Synopsys Synopsys verification intellectual property
(VIP) to establish 67 rules. Besides, according to our design
experiences, we add 6 new rules to increase our error finding
ability. In conclusion, our protocol checker has total 73 rules,
including 31 master-related rules, 16 slave-related rules,
11reset-related rules, and 15 bus components-related rules.
Bus components include arbiter and decoder.
Protocol Checker is the main core of HPChecker, the
inputs are all AHB bus signals, and the outputs are 73-bit
ERROR signals and corresponding master and slave IDs.
Every rule has its own corresponded bit because every cycle
maybe occur more than one error. If the ith bit of ERROR is
set, which indicates current bus signals violate ith rule. The
Master/Slave ID is formed by the HMASTER signal. If an
error occurs, the HPChecker will output the corresponded
master ID number or slave ID number to indicate which
master or slave violates the AHB protocol.
B. Configuration Registers
The configuration register can let the designer to set some
parameters, including mask, protocol checker enable and max
waiting cycle. The designer can base on the requirement of
the system to mask some unnecessary rule checked. The
enable bit can enable or disable the HPChecker. For example,
if we integrate one master IP into pre-verified AHB platform,
we just need to check master-related rules and disable all
other rules. If we modified an arbiter, we only need to check
arbiter related rules. The max waiting cycle is set by the
designer to check the HREADY max waiting cycle.
As Fig. 1 shows, the rule configuration register will mask
the ERROR outputs. If we disable some rules, the
corresponding ERROR bits will be mask. Another applicable
debugging method is that if we want to focus on one target IP
we want to debug, we can enable corresponding rules and
disable irrelevant rules, which we can narrow down the
problem region.
C. Error Reference Table (ERT)
Traditional protocol checkers will assert error signals or a
printout error message for every error occurs, but this way is
very inefficiently for early debugging in long simulation
929
period. In early debugging period, there may have many
errors, especially when test bench or real case application has
very long execution time. Such large amount of log messages
or error signals waveform could help designer to debug
limitedly, because that will be hard to read or analyze.
Moreover, we do not care about the timing information when
error occurred in most case. Thus we provide an error
reference table that can summarize what errors have been
occurred.
Fig. 2 shows the concept of error reference table, which
the rows are corresponding to every error; the columns are
corresponding to every ID of master or slave. We total
support 16 masters and 16 slaves, thus the number of column
is 16. We total have 31 master-related rules, 16 slave-related
rules, 11 reset-related rules, and 15 bus components-related
rules. Each master-related and slave-related error needs one
row due to that every 16 master/slave may occur this error.
Bus-related and reset-related errors consume one row for
each other. Thus ERT total has 16 columns and 49 rows.
D. Windowed Trace Buffer
Traditional trace mechanisms are based on forward tracing,
which designer set one or more trigger points, the trace will
begin when bus signals match trigger value. But sometimes
designers need to understand the signals before some errors
occurred. Thus we need backward tracing mechanism to
capture the history signals especially in program and protocol
error debugging.
In general backward tracing, as Fig. 3 shows, designers use
a circular trace buffer to store the trace data until first error
occurred, which the trace depth depends on trace buffer size.
Thus, if we have multiple errors to debug, we need to do
multiple backward tracing to debug all errors, which may
cause a lot of debugging times. In case of protocol check
debugging, we only need recently few cycles of trace data to
find the error come from. Hence, we propose windowed trace
buffer to address this problem illustrated at Fig. 3. The main
idea of windowed trace buffer is that we record recently few
cycles trace data while every error occurred. Trace buffer not
only records first error trace data, but also records other error
trace data as much as we can.
Fig. 4 shows windowed trace buffer architecture. Trace
Data Buffer stores bus signals for debugging and Trace Error
Buffer stores current ERROR signals to indicate what errors
occurred. For our observation, we require capture 192-bit bus
signals and three cycles of trace data for debugging. All the
required signals are summarized in Table I. As Fig. 4 shows,
192-bit bus signals pass through a three stage shift registers to
TABLE I. TRACED AHB BUS SIGNALS SUMMARY
Signals Width Total Bits
HADDR, HWDATA 32 bits 64 bits
HBUSREQ, HGRANT, HLOCK 16 bits 48 bits
HWRITE, HSEL 16 bits 32 bits
HMASTER, HPROT 4 bits 8 bits
HBURST, HSIZE 3 bits 6 bits
HTRANS1~HTRAN15, HRESP 2 bits 32 bits
HREADY, HMASTLOCK 1 bit 2 bits
 Fig. 3 The concept of traditional backward tracing and windowed trace
buffer Fig. 5 AMBA EASY verification environment

AHB Bus
Signals[191:0]

Data
Trace
Data Buffer
Write
DataWrite
Error Flag Trace Buffer
Write Controller
Write
ErrorWrite

ERROR[72:0]
Trace
Error Buffer
Data

Fig. 4 Windowed trace buffer architecture

Fig. 6 3D graphic acceleration system

capture recently three cycle bus signals. Trace Buffer Write
Controller (TBWC) receives Error Flag, when Error Flag
asserted, TBWC asserts DataWrite for three cycles that we
can store latest three cycle bus signals and ErrorWrite for one
cycle that we can store what errors occurred.
In conclusion, we need total 649 (192 * 3 + 73 = 649) bits
per error occurred. If we use 1 KByte memory as trace buffer,
we can store up to 20 error occurrences, which can
significantly reduce the debugging time than traditional
backward tracing mechanism.
3) Synopsys VIP: The software is available from the
Synopsys. It can also verify the IP protocol and also can
generate the correct behavior of IP. We use the generated
correct behavior to correct our HPChecker. This step is used
to avoid out misunderstanding on AMBA AHB protocol or
some unconsidered conditions.
We run the simulation on the ARM EASY (Example
AMBA SYstem) environment like Fig. 5. For every rule, the
constructed case will add to the bus as a master or slave IP and
then run the simulation.

III. VERIFICATION STRATEGY IV. EXPERIMENTAL REULTS

We use three methods to verify our HPChecker. 1) RTL Firstly we compare Synopsys VIP and LEON3
trigger to generate bus signals. 2) Pre-compiled cycle-level AMBAMON with HPChecker shown as Table II. Synopsys
simulation patterns. 3) Synopsys VIP. The first two VIP and LEON3 AMBAMON are un-synthesizable and only
verification strategies are buggy verification plans. We output error messages when errors occurred. HPChecker is a
construct the wrong condition case by case. If the rule case is synthesizable hardware module and we provide Error
constructed, the protocol checking module will observe these Reference Table and Windowed Trace Buffer to achieve
signals. While the protocol checking module detect that it is a efficient debugging. And Table III shows HPChecker
protocol violation then it will assert a corresponded error flag synthesis results, the total area is 43,432 gate counts.
to tell the reference table and history memory.
We use HPChecker to verify a 3D graphic acceleration
1) RTL trigger to generate bus signals: Behavioral buggy
masters and slaves connect to the bus and then the HPChecker TABLE II. VERIFICATION MONITORS COMPARISON
will observe these signals.
Synopsys LEON3
2) Pre-compiled cycle-level simulation patterns: We use IP Name HPChecker
VIP AMBAMON
software to generate the corresponded condition. The software Synthesizable No No Yes
generates a ROM file and the verification module base on the ERT and
Debugging Error Error
content of the file cycle by cycle output these signals into the Support Messages Messages
Windowed
bus. And then the HPChecker will detect these signals whether Trace Buffer
violate the protocol or not. Number of
67 35 73
Rules

930
 TABLE III. SYNTHESIS RESULTS

Max Frequency 203MHz

Total Area 43,432 Gates
Submodule Gate Counts
Protocol Checker 28,825
Error Reference Table 10,172
Windowed Trace Buffer
4,435
(Without Trace Buffer)

simulation, and a windowed trace buffer that we can trace bus

signals for multiple errors. We use HPChecker to verify a real
example of 3D graphic acceleration system, which can find
Fig. 7 An example output picture of 3D graphic system buffer
the errors more efficient.

time T0 T1 T2 T3 T4 T5 T6 T7 REFERENCES
3D(RM)
HCLK
HMASTER RM
[1] S. V. Aguiar, CamposEdmund, M. Clarke, W. R. Marrero, and M.
HTRANS NONSEQ SEQ Minea, ‘‘Verifying the performance of the PCI local bus using symbolic
HBUSREQ
HBURST INCR16 techniques,’’ in Proceedings of International Conference on Computer
HGRANT Design: VLSI in Computers and Processors. IEEE Computer Society,
Jan. 1995, pp. 72---78.
HMASTER# RM OTHER
HTRANS# NONSEQ [2] E. M. Clarke, E. A. Emerson, and A. P. Sistla, ‘‘Automatic verification
HBUSREQ#
HBURST# INCR16 of finite-state concurrent systems using temporal logic specifications,’’
HGRANT#
ACM Transactions on Programming Languages and Systems
(TOPLAS), vol. 8, pp. 244 --- 263, 1986.
De-asserted too early
to do arbitration
[3] P. Chauhan, E. M. Clark, Y. Lu, and D. Wang, ‘‘Verifying IP-core
based System-On-Chip designs,’’ in Twelfth Annual IEEE International
Fig. 8 An error wrapper design waveform ASIC/SOC Conference, Sept. 1999, pp. 27---31.
[4] A. Roychoudhury, T. Mitra, and S. R. Karri, ‘‘Using formal techniques
system as a case study. The system is shown as Fig. 6. The 3D to debug the AMBA System-on-Chip bus protocol,’’ in Proceeding on
graphic system contains three main modules, geometry engine Conference on Design, Automation and Test in Europe (DATE), 2003.
(GM), tile divider (TD) and rendering engine (RM) and [5] L. Ivanov and R. Nunna, ‘‘Specification and formal verification of
contains a processor, ARM926EJ-S. The system deals with interconnect bus protocols,’’ in 43rd IEEE Midwest Symposium on
Circuits and Systems, vol. 1, Aug. 2000.
graphic computing. We find a case that some IPs violate the
[6] M. Kaufmann, A. Martin, and C. Pixley, ‘‘Design constraints in
AHB protocol but do not cause the system crash. This is an symbolic model checking,’’ in Proceedings of the 10th International
interesting case that we are hardly to find where the problem is. Conference on Computer Aided Verification. Springer-Verlag, 1998.
Fig. 7(a) shows the correct picture after 3D graphic calculation, [7] K. L. McMillan, Symbolic Model Checking, K. L. McMillan, Ed.
which is an intact hexagon. Fig. 7(b) shows the error picture Kluwer Academic Publishers, 1993.
that is a broken hexagon. In the beginning, we do not know [8] I. Ltd., ‘‘Sugar formal property language reference manual.’’ [Online].
this error is com from software or hardware. By using Available: http://www.haifa.il.ibm.com/projects/verification/sugar/
HPChecker, we find one wrapper hardware implementation [9] S. Ltd., OpenVera LRM 2.0. [Online]. Available: http://www.open-
error that cause an INCR8 burst transfer can only transfer one vera.com
beat. The error waveform is shown in Fig. 8. According to the [10] Property Specification Language Reference Manual. [Online].
AMBA AHB specification, for a fixed length burst, the master Available: www.eda.org/vfv/docs/PSL-v1.1.pdf
can de-assert the HBUSREQ signal once the master has been [11] H.-M. Lin, C.-C. Yen, C.-H. Shih, , and J.-Y. Jou, ‘‘On compliance test
of on-chip bus for SOC,’’ in Proceedings of the 2004 conference on
granted the bus for the first transfer. The RM de-asserts the Asia South Pacific design automation, 2004.
HBUSREQ signal as soon as it is granted. This behavior [12] A. Nightingale and J. Goodenough, ‘‘Testing for AMBA compliance,’’
causes RM can only perform one beat in an INCR8 burst. in 14th Annual IEEE International ASIC/SOC Conference, Sept. 2001.
[13] M. T. Oliveira and A. J. Hu, ‘‘High-level specification and automatic
V. CONCLUSION generation of IP interface monitors,’’ in ACM IEEE Design Automation
We propose a AMBA AHB protocol checker (HPChecker), Conference, June 2002, pp. 129 --- 134.
which contains a monitor-based protocol checker with 73 rules, [14] K. Shimizu and D. Dill, ‘‘Deriving a simulation input generator and a
coverage metric from a formal specification,’’ in Proceedings of the
a configuration register that can enable or disable some rules th
39 conference on Design automation, June 2002.
to focus the region we want to debug, a error reference table
(ERT) to summarize the total errors during an application or

931