DESIGN AND VERIFICATION OF AMBA BASED AHB2APB BRIDGE PROTOCOL

Feroz Ahmed Choudhary1, Dr. Rajashekhar C. Biradar2

Dept. of Electronics and communication Engineering, REVA University, Bengaluru, India

---------------------------------------------------------------------***---------------------------------------------------------------------

Abstract – The AMBA AHB is for high-performance, high  APB Interface

clock frequency system modules. The AHB acts as the high-
performance backbone system bus. AHB supports the
efficient connection of processors. The AMBA APB is
optimized for low power consumption and interface reduced
complexity to support peripheral functions. In this project
functions of the AHB2APB Bridge protocol by writing the
code in VERILOG and simulating it in XILINX ISE. In this
project, we verify the all functions of Bridge protocol by
writing verification code in UVM with different test cases.
The code coverage and functional coverage and functional
verification of the Bridge RTL design is 100% covered by
using QUESTASIM.

Keywords: AHB, APB, QUESTASIM, XILINX ISE, AHB2APB

Bridge, Verilog, SVM, Coverage.
Fig 1.1Architecture of AHB2APB Bridge
1.INTRODUCTION

The AHB bus protocol is designed to be used with a 1. AHB Master: The bus master is able to initiate read and
multiplexer interconnection scheme. Using this scheme all write operations by providing an address and control
bus masters drive the address and control signal indicating information. One bus master is allowed to actively use the
the transfer to perform and the arbiter determines which bus at any one time.
master has its control signals and address routed to all of 2. AHB Arbiter: The bus arbiter ensures that one bus
the slaves. The central decoder is also required to control master at a time is allowed to initiate data transfers. Even
the data read and signal response multiplexer, which though the arbitration protocol is fixed, any arbitration
selects the appropriate signals from the slaves that is algorithm, such as highest priority and fair access can be
involved in the transfer. The APB should be used to implemented depending on the application requirements.
connected to any peripherals which are low bandwidth An AHB would include one arbiter, although this would be
and do not need high performance of a pipelined bus trivial in single bus master systems.
interface. The BUS Communication may be done in
different ways. (A) Transfer type: - Indicates type of the 3. AHB decoder: The AHB decoder is used to decode
current transfer, which can be NON-SEQUENTIAL, address of each transfer and provide a select signal for the
SEQUENTIAL, IDLE or BUSY. (B) Transfer direction: - slave that is involved transfer single centralized decoder is
When write HIGH this signal indicates a write transfer and required in all AHB implementations.
when write LOW a read transfer. (C) Transfer size: - 4. APB Interface: A bus slave responds to a read and a
Indicates this size of the transfer, which is typically byte write operation within a given address-space range. The
(8-bit), half word (16-bit) or word (32-bit). The protocol bus slave signals back to the active master the success,
allows larger transfer sizes up to a maximum of 1024 bits. failure and waiting of the data transfer address and data
(D) Burst type: - Indicates if the transfer forms the part of that received from the bridge suitably used for data
a burst. Four and eight and sixteen beat bursts are transaction from bridge to this module and vice versa
supported and the burst may be either incrementing or depending whether it is a write and a read operation.
wrapping. These modules contain block for P_CLK generation, which
is distributed to AHB2APB bridge module, and the P_CLK
II. AHB2APB BRIDGE generated obviously used in this module also.
5. AHB2APB Bridge: Out of all modules present, this
General architecture of AHB2APB Bridge consists of five
module is simplest and also very larger. All the signals are
main building blocks:
taken as wire to interconnect the various modules present
 AHB Master in the top module. In the module, all the three modules
namely
 AHB2APB Bridge
 AHB Master
 AHB Interface
 AHB2APB bridge
 APB FSM Controller
 APB interface These modules are all instantiated used done by using Verilog. If all the remaining Blocks are coded
Positional assignments which is again simple via Verilog then we have to instantiate coding by defining
compared naming assignment which is little tedious. module name for each block, module to module
These modules are all instantiated used Positional communication is very hectic thus we don’t prefer Verilog
assignments which is again simple compared naming for coding of other blocks instead prefer System Verilog.
assignment which is little tedious. The main reason is System Verilog includes OOPs concepts
thus defining each blocks codes in a class format provides
easy way of coding as compare to Verilog.
The following Figure can be divided as two parts for master
and slave configuration, the left hand side is for master and
the right hand side is for the slave. Depending upon the no
of slave and master the figure can be modified for different
design aspects.

Fig 2. AMBA Based Architecture

6. FSM Controller:

Fig 4. System Verilog Architecture

We can briefly define each block role independently as
follows
(i) Generator Block: Responsible for generating all the
signals required for all scenarios example clock & reset
signals etc.
(ii)Driver/Bus function model (BFM): Routing Signals
generated from the generator.
(iii)Monitor: To check signals and has inputs from coverage
& assertion blocks.
(iv)Coverage Block: checking the given input to the DUT
whether it’s complete or not.
(v)Assertion Block: checking at the interface as per the
protocol or not i.e. indicates violation of protocols.
(vi)Reference: kind of having desire results.
(vii)Checker: Compare the outputs from the reference and
DUT block.
(viii)Scoreboard: Displays the result of Checker.

 Verification Steps
Fig 3.0 State Machine (i) Features listing down.
(ii) Scenario listing down.
(iii) Test plan development.
(iv) Functional Coverage Point listing down.
III.. SYSTEM VERILOG WORKING METHODOLOGY (v) Testbench architecture definition.
(vi) Testbench component coding.
 Architecture (vii) Sanity test case development.
(viii) Sanity test case bring up.
The below show Fig-4 is for the System Verification
(ix) other test cases.
Architecture as can be seen there are various blocks which (x) Setting up regression.
are need to coding in the tool, but the question is why (xi) Running regression and debugging regression results.
Verilog only can be used and why in what way does System (xii) Generating coverage results.
Verilog have advantage over Verilog. DUT Block is the (xiii) Analyze coverage results.
Device under test i.e. the top module for which coding is (xiv) Closing functional Coverage.
 10.2c. The design is carried out using in Verilog
and the verification is carried out in SVM. The
 Verification Tools
Bridge is set up as DUT the functional verification
There are many companies which provides simulating
advanced verification tools namely QuestaSim, ModelSim, and the code coverage is obtained for 100%.
Xilinx, Cadence etc.
VI. COVERAGE REPORT
Usually the tools work in 3 steps which includes:
(i) Compilation.
(ii) Elaboration.
(iii) Simulation.

Tool like QuestaSim has an inbuilt writing notepad

otherwise the code written in a separate notepad can be
linked to the tools. For every Design prospective we need
to create a new project in the tool and make sure all the
required libraries linked to the directories are included for
the same project.

V. RESULTS AND DISCUSSION

Fig 7. Bridge top Schematic Diagram from

Synthesis

The Bridge is carried out for the functional

verification using the UVM techniques for both
the read as well as write operation. The
functional verification of the RTL design is the
Bridge is yields the complete code and functional
coverage. Functional Verification of the Bridge
Using UVM As verification methodology plays
important phase in the circuit design. The read
operation of the Bridge is carried out in XILINX
for the RTL design and the verification
methodologies are carried out using Questasim