Final AHB2Cusom PIPE Bridge
-
Upload
hardik-trivedi -
Category
Documents
-
view
6 -
download
0
description
Transcript of Final AHB2Cusom PIPE Bridge
THE DISSERTATION ENTITLED
“AHB to Custom PIPE Bridge”
Submitted in partial fulfillment of the requirements
For the degree of
Master of Technology
In
Electronics & Communication Engineering
With specialization in
VLSI & Embedded Systems
Prepared by
Parikh Vyom Tarunkumar
(14014061008)
Under the Guidance of
Mr. Nikunj Sanghani (Arastu Systems)
Mr. Hardik Trivedi (eiTRA)
ELECTRONICS & COMMUNICATION DEPARTMENT
U.V.PATEL COLLEGE OF ENGINEERING
GANPAT UNIVERSITY, KHERAVA-382711
November-December -2015
ii | P a g e
APPROVAL SHEET
This Dissertation entitled “AHB to Custom PIPE Bridge” by Vyom Parikh
(14014061008) is approved for the degree of Master of Technology.
Examiners:
____________________
____________________
____________________
Supervisors:
____________________
____________________
____________________
____________________
Coordinators:
____________________
____________________
____________________
Date: ____________
Place: eiTRA, UVPCE, GANPAT University
i | P a g e
DECLARATION
I declare that this written submission represents my ideas in my own words and where
others’ ideas or words have been included, I have adequately cited and referenced the
original sources. I also declare that I have adhered to all principles of academic honesty
and integrity and have not misrepresented or fabricated or falsified any
idea/data/fact/source in my submission. I understand that any violation of the above will
be cause for disciplinary action by the Institute and can also evoke penal action from the
sources which have thus not been properly cited or from whom proper permission has not
been taken when needed.
(Vyom Parikh)
Enrollment No: - 14014061008
Date:
ii | P a g e
CERTIFICATE
This is to certify that the dissertation entitled “AHB to Custom PIPE Bridge” submitted
by Parikh Vyom Tarunkumar (14014061008), towards the fulfillment of the
requirements for the degree of Master of Technology in Electronics and Communication
with specialization in VLSI & Embedded Systems at Ganpat University is the record work
carried out by him under our supervision and guidance. In our opinion, the submitted work
has reached at level required for being accepted for examination. The results embodied in
this dissertation, to the best of our knowledge, haven’t been submitted to any other
university or institute for the award of any degree or diploma.
Date: ____________
Place: ____________
Internal Guide
Mr. Hardik Trivedi
(TA-VLSI (Verification), eiTRA)
External Guide
Mr. Nikunj Sanghani
(Arastu Systems)
P.G.Coordinator
Ms. Bhoomika Sheth
(Electronics & Communication Dept.
eiTRA,Ganpat University)
P.G.Coordinator
Prof. Vijay Patel
(Assistant Professor EC Department
Ganpat University)
iii | P a g e
ACKNOWLEDGEMENT
I would like to take this opportunity to express my sincere gratitude to all the people who have
extended their support in part and whole and helped in successfully completing the dissertation
Phase I.
I am very thankful to my external project guide Mr. Umesh Patel (Arastu Systems) and Mr. Nikunj
Sanghani (Arastu Systems) to assign me with such an interesting and challenging project. They
always offer support and guide me if any require.
I would like to express my heartfelt gratitude towards my internal guide Mr. Ashish Purani and
Mr. Hardik Trivedi (Technical Associate - VLSI (Verification), eiTRA) for their genuine guidance
and constant encouragement throughout this project work. I am highly obliged as my honorable
guide has devoted his valuable time and shared his expertise knowledge.
My parents mean all to me. They left me on my way giving me great amount of freedom which
has been crucial in developing an open attitude. Their love pushed me to do my best and that I
think is take way I repay them. I would like to convey my hearty thanks to all friends from eiTRA
for their constant support and kind help.
Vyom Parikh
(14014061008)
iv | P a g e
ABSTRACT
Microprocessor performance has improved rapidly these years. In contrast, memory latencies and
bandwidths have improved little. As microprocessor performance has improved, it has become
increasingly important to provide a high-bandwidth, low-latency memory subsystem to achieve
full performance potential of these processors. Main thing is that memory access time limits the
system performance. Memory controller (MC) is designed for this problem but there is different
memory controller for different peripherals. Memory controller manages the flow of outgoing and
incoming data from the main memory. There is a requirement that the memory controller must
understood the request given by the processor. AMBA AHB is very popular and stable standard
and it is high performance on-chip bus standard. The ultimate aim of the project is to design a
module which converts the request from AHB master into suitable form which is understandable
by the Memory controller (MC).
v | P a g e
TABLE OF CONTENTS
ACKNOWLEDGEMENT ........................................................................................................................... iii
ABSTRACT ................................................................................................................................................. iv
Table of Contents .......................................................................................................................................... v
List of Tables .............................................................................................................................................. vii
List of Figures ............................................................................................................................................ viii
1 Introduction ........................................................................................................................................... 1
1.1 Objective and Scope of the Project ............................................................................................... 1
1.2 Overview ....................................................................................................................................... 1
1.3 Block Diagram .............................................................................................................................. 2
1.3.1 Proposed Architecture ........................................................................................................... 3
2 Literature Review .................................................................................................................................. 4
2.1 Basics of Advanced Microcontroller Bus Architecture (AMBA) ................................................. 4
2.2 History........................................................................................................................................... 4
2.3 Overview of AMBA Specifications .............................................................................................. 5
2.4 Why AHB? .................................................................................................................................... 6
3 AMBA – AHB (Advanced High - Performance Bus) .......................................................................... 8
3.1 AMBA – based Microcontroller ................................................................................................... 8
3.2 Advanced High – Performance Bus (AHB) .................................................................................. 8
3.2.1 Introduction to AHB ............................................................................................................. 8
3.2.2 AHB Signal List .................................................................................................................... 9
3.2.3 Overview of AMBA – AHB Operation .............................................................................. 11
3.3 Detailed Description of AHB Signals ......................................................................................... 14
3.3.1 Transfer Type ...................................................................................................................... 14
3.3.2 Burst Operation ................................................................................................................... 16
3.3.3 Control Signals .................................................................................................................... 19
3.3.4 Slave Transfer Responses ................................................................................................... 20
3.3.5 Data Buses .......................................................................................................................... 25
3.3.6 Reset .................................................................................................................................... 26
4 PIPE Interface ..................................................................................................................................... 27
4.1 PIPE Interface Signals ............................................................................................................... 27
4.2 PIPE Write and Read Operation ................................................................................................. 28
vi | P a g e
4.2.1 PIPE Write Operation ......................................................................................................... 28
4.2.2 PIPE Read Operation .......................................................................................................... 28
5 Conclusion .......................................................................................................................................... 29
6 Future Work ........................................................................................................................................ 30
References ................................................................................................................................................... 31
vii | P a g e
LIST OF TABLES
Table 2.1 Comparison between AHB and AXI ............................................................................................... 7
Table 2.2 Comparison between AHB and APB .............................................................................................. 7
Table 3.1 AMBA AHB Signal List .................................................................................................................. 10
Table 3.2 Transfer Type............................................................................................................................... 15
Table 3.3 Burst Type ................................................................................................................................... 16
Table 3.4 Transfer Size ................................................................................................................................ 20
Table 3.5 Transfer Responses ..................................................................................................................... 21
Table 3.6 Active Byte Lanes for a 32-bit little-endian data bus .................................................................. 26
Table 3.7 Active Byte Lanes for a 32-bit big-endian data bus ..................................................................... 26
Table 4.1 PIPE Interface Signals .................................................................................................................. 27
viii | P a g e
LIST OF FIGURES
Figure 1.1 Block Diagram .............................................................................................................................. 2
Figure 1.2 Proposed Block Diagram of the Project ....................................................................................... 3
Figure 3.1 AMBA Based Microcontroller ...................................................................................................... 8
Figure 3.2 AHB Master Interface ................................................................................................................... 9
Figure 3.3 AHB Slave Interface .................................................................................................................... 10
Figure 3.4 Transfer with No wait State ....................................................................................................... 12
Figure 3.5 Transfer with two wait state ...................................................................................................... 13
Figure 3.6 Multiple Transfer ....................................................................................................................... 14
Figure 3.7 Transfer Type example ............................................................................................................... 15
Figure 3.8 4-beat wrapping burst .............................................................................................................. 17
Figure 3.9 4-beat Incrementing burst ........................................................................................................ 17
Figure 3.10 8-beat Wrapping Burst ............................................................................................................ 18
Figure3.11 8-beat Incrementing Burst ........................................................................................................ 18
Figure3.12 Undefined Length Burst ............................................................................................................ 19
Figure 3.13 Transfer with RETRY Response ................................................................................................ 23
Figure 3.14 Transfer with ERROR response ................................................................................................ 24
Figure 4.1 PIPE Interface ............................................................................................................................. 27
1 | P a g e
1 INTRODUCTION
Advanced Microcontroller Bus Architecture (AMBA) – Advanced High-Performance Bus (AHB)
is new generation AMBA bus. It defines an on chip communications standard for designing high-
performance embedded microcontroller. The AMBA AHB is for high-performance, high clock
frequency system modules. The AHB acts as the high-performance system backbone bus. AHB
supports the efficient connection of processors, on-chip memories and off-chip external memory
interfaces with low-power peripheral macrocell functions. AHB is also specified to ensure ease of
use in an efficient design flow using synthesis and automated test techniques.
1.1 OBJECTIVE AND SCOPE OF THE PROJECT
The objective of the project is to design a generic converter which converts the request of the AHB
master (BFM) into suitable form in terms of PIPE BFM with the help of FIFO so that the request
can be easily understandable by the memory controller of the memories like DRAM, SRAM,
LPDDR RAM etc.
Using AMBA-AHB bus, we can develop a converter for the memory controller which uses AHB
slave. Our master can be a processor which gives request for data transmission to memory
controller (MC). Memory controller takes care for the incoming and outgoing transmission to and
from memory.
1.2 OVERVIEW
Project includes the design of the module slave to PIPE using Verilog and synthesis of the RTL
code which is written in Verilog. Design is to be done in Verilog. Whenever AHB master sends
read or write request to the slave, slave to PIPE module will convert the request and data into
suitable form which will be easily understandable by memory controller and latency should be as
low as possible.
This module is responsible to translate AHB Slave transaction that are initiated by Remote master
into custom PIPE Interface and vice versa.
2 | P a g e
1.3 BLOCK DIAGRAM
This is the block diagram for the AHB to custom PIPE Bridge. AHB Slave-PIPE Bridge is the
main part of the project which is to be designed.
AHB Master (BFM) is the AHB master which sends request and control signals and data to be
written to the memory.
AHB Slave-PIPE Bridge (RTL) is the main module of the project which is written into Verilog
and responsible to translate the AHB slave transaction into custom PIPE interface and vice versa.
PIPE Interface (BFM) is the PIPE i/f which is ready for the transmission when memory controller
is ready.
PIPE Interface (BFM)
AHB Master (BFM)
AHB Slave-PIPE Bridge (RTL)
Figure 1.1 Block Diagram
3 | P a g e
1.3.1 Proposed Architecture
Figure 1.2 Proposed Block Diagram of the Project
Command Generator Generates the command and store it in the command FIFO and Address is stored in
the address FIFO. Write Data FIFO stores the HWDATA and Read Data FIFO stores data coming from
memory controller.
4 | P a g e
2 LITERATURE REVIEW
2.1 BASICS OF ADVANCED MICROCONTROLLER BUS ARCHITECTURE (AMBA)
AMBA is on chip bus protocol for ARM. It is open standard. It is technology Independent protocol.
The AMBA protocol defines the behavior of various signals at the cycle level. The exact timing
requirements will depend on the process technology used and the frequency of operation. [1] It is
on-chip interconnection specification for the connection and management of functional blocks in
system-on-a-chip (SoC) designs.
The following points should be considered when reading the/implementing AMBA specification:
Technology independence: AMBA is technology independent on-chip protocol.
Specification only details the bus protocol at the clock cycle level.
Electrical characteristics: No information regarding electrical characteristics is supplied
within the AMBA specification as this will be entirely dependent on the manufacturing
process technology that is selected for the design.
Timing specification: The AMBA protocol defines the behavior of various signal at the
cycle level. The exact timing requirements will depend on the process technology used and
the frequency of operation.
2.2 HISTORY
AMBA was introduced by ARM in 1996. The first AMBA buses were Advanced System Bus
(ASB) and Advanced Peripheral Bus (APB). In 1999 AMBA 2, ARM added AMBA Advanced
High-performance bus (AHB) that is single clock-edge protocol. In 2003 ARM introduced the
third generation AMBA3, introducing AXI to reach even higher performance interconnect. In 2010,
the AMBA4 specifications were introduced starting with AMBA4 AXI4, then in 2011 extending
system wide coherency with AMBA4 ACE. In 2013 the AMBA5 CHI specification was
introduced, with a re-designed high-speed transport layer and features designed to reduce
congestion. [2]
APB is designed for low bandwidth control accesses. AHB is for high bandwidth control access.
AHB-Lite is a subset of AHB formally defined in AMBA3 standard. This sunset simplifies design
for a bus with a single master. AXI is the third generation AMBA interface defined in the AMBA3
specification targeted at high performance, high clock frequency system designs and includes
features that make it suitable for high speed sub-micrometer interconnect. ACE extends AXI with
additional signal coherency. This system coherency allows multiple processors to share memory
and enables technology like ARM’s big. LITTLE processing. The ACE-Lite protocol enables one-
way aka IO coherency, for example a network interface that can read from the caches of fully
coherent ACE processors. [2]
5 | P a g e
2.3 OVERVIEW OF AMBA SPECIFICATIONS
AMBA 5
o The AMBA 5 adds CHI and AHB5 interface protocols.
o AHB5 (Advanced High-performance Bus) architecture specification is an interface
protocol most widely used with Cortex-M processors for embedded designs and
other low latency SoCs. The AMBA5 specifications are intending to build next-
generation SoCs for applications including real time, IoT and embedded
microcontroller designs. [3]
o The AMBA 5 CHI (Coherent Hub Interface) architecture specification defines the
interfaces for connection of fully coherent processors, such as the Cortex-
A57 andCortex-A53.[3]
AMBA 4
o The AMBA 4 specification adds another five interface protocols on top of the
AMBA3 specifications. ACE, ACE-Lite, AXI4, AXI4-Lite and AXI4-stream.
o The ACE protocol, adds three additional channels for sharing data between ACE
master caches and hardware control of cache maintenance. ACE also adds barrier
support to enforce ordering of multiple outstanding transactions, thus minimizing
CPU stalls waiting for preceding transaction to complete. Distributed Virtual
Memory (DVM) signaling maintains virtual memory mapping across multiple
masters.[3]
o The ACE-Lite protocol is a small subset of ACE signals that offer I/O, or one-way,
coherency, where ACE masters maintain the cache coherency of ACE-Lite
masters.[3]
o The AXI4 protocol is an update to AXI3 to enhance the performance and utilization
of the interconnect when used by multiple masters.[3]
o The AXI4-Lite protocol is a subset of the AXI4 protocol intended for
communication with simpler, smaller control register-style interfaces in
components. It includes burst length of one and all data accesses are same size as
the width of the data bus.[3]
o The AXI4-Stream protocol is designed for unidirectional data transfers from master
to slave with greatly reduced signal routing.[3]
AMBA 3
o The AMBA 3 specification defines a set of four interface protocols that, between
them, cover the on-chip data traffic requirements from data intensive processing
components requiring high data throughput, low bandwidth communication
6 | P a g e
requiring low gate count and power and on-chip test and debug access. The four
interfaces are AXI, AHB-Lite, ATB and APB Interface.
o The AMBA 3 AXI interface specification provides the characteristics to support
highly effective data traffic throughput.[3]
o The AMBA 3 AHB interface specification enables highly efficient interconnect
between simpler peripherals in a single frequency subsystem where the
performance of AMBA 3 AXI is not required.[3]
o The AMBA 3 APB interface specification supports the low bandwidth transactions
necessary to access configuration registers in peripherals and data traffic through
low bandwidth peripherals.[3]
o The AMBA 3 ATB interface specification adds a data agnostic interface for trace
data in a trace system to the AMBA specification.[3]
AMBA 2
o The AMBA 3 specification replaces AMBA 2 and should be used for new designs.
Existing AMBA 2 peripherals can be used in an AMBA 3 based system. The
AMBA 2 specification defines a set of two interface protocols: AHB and APB
Interface.
o The AMBA 2 AHB interface specification enables highly efficient interconnect
between masters in a single frequency system.[3]
o The AMBA 2 APB interface specification supports the low bandwidth transactions
necessary to access configuration registers in peripherals and data traffic through
low bandwidth peripherals.[3]
AMBA
o This is the first version of AMBA specification include only two interface protocol
ASB and APB interface.
o ASB is the first generation of AMBA system bus. ASB sits above the current APB
and implements the features required for high-performance systems.[1]
o The APB is part of the AMBA hierarchy of buses and is optimized for minimal
power consumption and reduced interface complexity.[1]
2.4 WHY AHB?
A full AHB interface is used for bus masters, on-chip memory blocks, external memory
interfaces, and high-bandwidth peripherals with FIFO interfaces.
7 | P a g e
The following table consist of the comparison between AHB and AXI.
AHB AXI
Advanced High-Performance
Bus
Advanced Extensible bus
Single Channel bus Multi-Channel bus
Shared Bus Read/Write optimized bus
Less Power Uses 50% more power than AHB
Table 2.1 Comparison between AHB and AXI
AHB bus utilization is higher than AXI utilization.
The following table consist of the comparison between AHB and APB
AHB APB
Advanced High-Performance Bus Advanced Peripheral Bus
High Performance Lower Performance than AHB
Pipelined Operation Latched Address and Control
Burst Transfer and Split
Transaction
Simple Interface
Table 2.2 Comparison between AHB and APB
ASB (Advanced System Bus) supports burst transfers, pipelined transfer operations and
multiple bus master. While AHB supports above features and also include single-cycle bus
master handover, single-clock edge operation, non-tristate implementation and wider bus
configurations (64/128 bits).
8 | P a g e
3 AMBA – AHB (ADVANCED HIGH - PERFORMANCE BUS)
3.1 AMBA – BASED MICROCONTROLLER
An AMBA-based microcontroller typically consists of AHB, able to sustain the external memory
bandwidth, on which the CPU, on-chip memory and other DMA devices reside. This bus provides
a high-bandwidth interface between the elements that are involved in the majority of transfers.
Also located on the high-performance bus is a bridge to the lower bandwidth APB, where most of
the peripheral devices in the system are located.
Figure 3.1 AMBA Based Microcontroller [1]
3.2 ADVANCED HIGH – PERFORMANCE BUS (AHB)
3.2.1 Introduction to AHB
AHB is a new generation of AMBA bus which is intended to address the requirements of high-
performance synthesizable designs. It is a high-performance system bus that supports multiple bus
masters and provides high-bandwidth operation.
AMBA AHB implements the features required for high-performance, high clock frequency
systems including:
Burst transfers
Split transaction
Single-cycle bus master operation
Single-clock edge operation
9 | P a g e
Non-tristate implementation
Wider data bus configuration (64/128 bits).
A typical AMBA AHB system design contains the following components:
AHB master: A bus master is able to initiate read and write operations by providing an
address and control information. Only one bus master is allowed to actively use the bus at
any one time.
AHB slave: A bus slave responds to a read or write operation within a given address-
space range. The bus slave signals back to the active master the success, failure or waiting
of the data transfer.
AHB arbiter: The bus arbiter ensures that only one bus master at a time is allowed to
initiate data transfers. Even though the arbitration protocol is fixed, any arbitration
algorithm, such as highest priority or fair access can be implemented depending on the
application requirements. An AHB would include only one arbiter, although this would be
trivial in single bus master systems.
AHB decoder: The AHB decoder is used to decode the address of each transfer and
provide a select signal for the slave that is involved in the transfer. A single centralized
decoder is required in all AHB implementations.
3.2.2 AHB Signal List
Figure 3.2 AHB Master Interface [1]
10 | P a g e
Figure 3.3 AHB Slave Interface [1]
Following Table shows the signal list.
Signal Name Width Type (I/O) Description
Clock reset interface (Global Signal)
HCLK 1 I AHB clock
HRSTN 1 I AHB reset (Active
Low)
Select Signal
HSELx 1 Input to Slave Slave select
HGrantx 1 Input to Master Master Select
Address and Control Signals
HADDR AHB_ADDRWIDTH
Input to Slave and Output from
Master
AHB system address
HWRITE 1 Write/Read selector
HTRANS 2 Transfer type.
HSIZE 3 Transfer size
HBURST 3 Burst type.
Data Signals
HWDATA AHB_DATAWIDTH Input to Slave and Output from Master Write data
HRDATA AHB_DATAWIDTH Output from Slave and Input to Master Read Data
Response and Transfer Signal
HRESP 2 Output from Slave and Input to Master Slave response
HREADY 1 Output from Slave and Input to Master Slave ready.
Table 3.1 AMBA AHB Signal List
11 | P a g e
3.2.3 Overview of AMBA – AHB Operation
Before an AMBA AHB transfer can commence the bus master must be granted access to the bus.
This process is started by the master asserting a request signal to the arbiter. Then the arbiter
indicates when the master will be granted use of the bus.
A granted bus master starts an AMBA AHB transfer by driving the address and control signals.
These signals provide information on the address, direction and width of the transfer, as well as an
indication if the transfer forms part of a burst. Two different forms of burst transfers are allowed:
Incrementing bursts, which do not wrap at address boundaries
Wrapping bursts, which wrap at particular address boundaries.
A write data bus is used to move data from the master to a slave, while a read data bus is used to
move data from a slave to the master.
Every transfer consists of:
an address and control cycle
One or more cycles for the data.
The address cannot be extended and therefore all slaves must sample the address during this time.
The data, however, can be extended using the HREADY signal. When LOW this signal causes
wait states to be inserted into the transfer and allows extra time for the slave to provide or sample
data.
The address cannot be extended and therefore all slaves must sample the address during this time.
The data, however, can be extended using the HREADY signal. When LOW this signal causes
wait states to be inserted into the transfer and allows extra time for the slave to provide or sample
data.
Basic Transfer
An AHB transfer consists of two distinct sections:
o The address phase, which lasts only a single cycle.
o The data phase, which may require several cycles. This is achieved using the
HREADY signal.
Figure shows the simplest transfer, one with no wait states.
12 | P a g e
Figure 3.4 Transfer with No wait State [1]
In a simple transfer with no wait states:
The master drives the address and control signals onto the bus after the rising edge of
HCLK.
The slave then samples the address and control information on the next rising edge of the
clock.
After the slave has sampled the address and control it can start to drive the appropriate
response and this is sampled by the bus master on the third rising edge of the clock.
This simple example demonstrates how the address and data phases of the transfer occur during
different clock periods. In fact, the address phase of any transfer occurs during the data phase of
the previous transfer. This overlapping of address and data is fundamental to the pipelined nature
of the bus and allows for high performance operation, while still providing adequate time for a
slave to provide the response to a transfer.
A slave may insert wait states into any transfer, as shown in Figure, which extends the transfer
allowing additional time for completion.
13 | P a g e
Figure 3.5 Transfer with two wait state [1]
For write operations the bus master will hold the data stable throughout the extended
cycles.
For read transfers the slave does not have to provide valid data until the transfer is about
to complete.
When a transfer is extended in this way it will have the side-effect of extending the address phase
of the following transfer. This is illustrated in Figure 3.6 which shows three transfers to unrelated
addresses, A, B & C.
Two wait states are added by slave by asserting
HREADY low
14 | P a g e
Figure 3.6 Multiple Transfer [1]
In Figure:
The transfers to addresses A and C are both zero wait state
The transfer to address B is one wait state, extending the data phase of the transfer to
address B has the effect of extending the address phase of the transfer to address C.
3.3 DETAILED DESCRIPTION OF AHB SIGNALS
3.3.1 Transfer Type
Every transfer type can be classified into one of four different types, as indicated by the HTRANS
[1:0] signals as shown in Table.
HTRANS [1:0] Type Description
00 IDLE Indicates that no data transfer is required. The IDLE transfer
type is used when a bus master is granted the bus, but does not
wish to perform a data transfer.
Slaves must always provide a zero wait state OKAY response
to IDLE transfers and the transfer should be ignored by the
slave.
01 BUSY The BUSY transfer type allows bus masters to insert IDLE
cycles in the middle of bursts of transfers. This transfer type
indicates that the bus master is continuing with a burst of
transfers, but the next transfer cannot take place immediately.
When a master uses the BUSY transfer type the address and
control signals must reflect the next transfer in the burst.
15 | P a g e
The transfer should be ignored by the slave. Slaves must always
provide a zero wait state OKAY response, in the same way that
they respond to IDLE transfers.
10 NON-SEQ Indicates the first transfer of a burst or a single transfer. The
address and control signals are unrelated to the previous
transfer.
Single transfers on the bus are treated as bursts of one and
therefore the transfer type is NONSEQUENTIAL.
11 SEQ The remaining transfers in a burst are SEQUENTIAL and the
address is related to the previous transfer. The control
information is identical to the previous transfer. The address is
equal to the address of the previous transfer plus the size (in
bytes). In the case of a wrapping burst the address of the
transfer wraps at the address boundary equal to the size (in
bytes) multiplied by the number of beats in the transfer (either
4, 8 or 16). Table 3.2 Transfer Type
Figure shows a number of different transfer types being used.
Figure 3.7 Transfer Type example [1]
In Figure
The first transfer is the start of a burst and therefore is NONSEQUENTIAL.
The master is unable to perform the second transfer of the burst immediately and therefore
the master uses a BUSY transfer to delay the start of the next transfer.
In this example the master only requires one cycle before it is ready to start the next transfer
in the burst, which completes with no wait states.
16 | P a g e
The master performs the third transfer of the burst immediately, but this time the slave is
unable to complete and uses HREADY to insert a single wait state.
The final transfer of the burst completes with zero wait states.
3.3.2 Burst Operation
Four, eight and sixteen-beat bursts are defined in the AMBA AHB protocol, as well as undefined-
length bursts and single transfers. Both incrementing and wrapping bursts are supported in the
protocol:
Incrementing bursts access sequential locations and the address of each transfer in the burst
is just an increment of the previous address.
For wrapping bursts, if the start address of the transfer is not aligned to the total number of
bytes in the burst (size x beats) then the address of the transfers in the burst will wrap when
the boundary is reached. For example, a four-beat wrapping burst of word (4-byte) accesses
will wrap at 16-byte boundaries. Therefore, if the start address of the transfer is 0x34, then
it consists of four transfers to addresses 0x34, 0x38, 0x3C and 0x30.
Burst information is provided using HBURST [2:0] and the eight possible types are defined in
Table.
HBURST [2:0] Type Description
000 SINGLE Single transfer
001 INCR Incrementing burst of unspecified length
010 WRAP4 4-beat wrapping burst
011 INCR4 4-beat incrementing burst
100 WRAP8 8-beat wrapping burst
101 INCR8 8-beat incrementing burst
110 WRAP16 16-beat wrapping burst
111 INCR16 16-beat incrementing burst Table 3.3 Burst Type
Bursts must not cross a 1kB address boundary. Therefore it is important that masters do not
attempt to start a fixed-length incrementing burst which would cause this boundary to be crossed.
It is acceptable to perform single transfers using an unspecified-length incrementing burst which
only has a burst of length one.
An incrementing burst can be of any length, but the upper limit is set by the fact that the address
must not cross a 1kB boundary.
All transfers within a burst must be aligned to the address boundary equal to the size of the
transfer. For example, word transfers must be aligned to word address boundaries (that is A [1:0]
= 00), half word transfers must be aligned to half word address boundaries (that is A [0] = 0).
17 | P a g e
Figure 3.8 4-beat wrapping burst [1]
Figure 3.9 4-beat Incrementing burst [1]
As the burst is a four-beat burst of word transfers the address will wrap at 16-byte boundaries,
hence the transfer to address 0x3C is followed by a transfer to address 0x30.
Wrap around 0x30
18 | P a g e
The only difference with the incrementing burst is that the addresses continue past the 16-byte
boundary.
Figure 3.10 8-beat Wrapping Burst [1]
The address will wrap at 32-byte boundaries and therefore address 0x3C is followed by 0x20.
The burst in Figure uses half word transfers, so the addresses increase by 2 and the burst is
incrementing so the addresses continue to increment past the 16-byte boundary.
Figure3.11 8-beat Incrementing Burst [1]
Wrap around 0x20
19 | P a g e
The below figure shows incrementing burst of undefined length.
Figure3.12 Undefined Length Burst [1]
Above Figure shows two bursts:-
Two half word transfers starting at address 0x20. The half word transfer addresses
increment by 2.
Three word transfers starting at address 0x5C. The word transfer addresses increment by
4.
3.3.3 Control Signals
As well as the transfer type and burst type each transfer will have a number of control signals that
provide additional information about the transfer. These control signals have exactly the same
timing as the address bus. However, they must remain constant throughout a burst of transfers.
Transfer direction:
When HWRITE is HIGH, this signal indicates a write transfer and the master will
broadcast data on the write data bus, HWDATA [31:0]. When LOW a read transfer
will be performed and the slave must generate the data on the read data bus
HRDATA [31:0].
20 | P a g e
Transfer Size:
HSIZE [2:0] indicates the size of the transfer, as shown in Table.
HSIZE[2:0] Size Description
000 8 bits Byte
001 16 bits Halfword
010 32 bits Word
011 64 bits -
100 128 bits 4-word line
101 256 bits 8-word line
110 512 bits -
111 1024 bits - Table 3.4 Transfer Size
The size is used in conjunction with the HBURST [2:0] signals to determine the address boundary
for wrapping bursts.
3.3.4 Slave Transfer Responses
After a master has started a transfer, the slave then determines how the transfer should progress.
No provision is made within the AHB specification for a bus master to cancel a transfer once it
has commenced.
Whenever a slave is accessed it must provide a response which indicates the status of the transfer.
The HREADY signal is used to extend the transfer and this works in combination with the
response signals, HRESP [1:0], which provide the status of the transfer.
The slave can complete the transfer in a number of ways. It can:
Complete the transfer immediately
Insert one or more wait states to allow time to complete the transfer
Signal an error to indicate that the transfer has failed
Delay the completion of the transfer, but allow the master and slave to back off
the bus, leaving it available for other transfers.
Transfer Done
The HREADY signal is used to extend the data portion of an AHB transfer. When
LOW the HREADY signal indicates the transfer is to be extended and when HIGH
indicates that the transfer can complete.
NOTE:-
Every slave must have a predetermined maximum number of wait states that it will
insert before it backs off the bus, in order to allow the calculation of the latency of
accessing the bus. It is recommended, but not mandatory, that slaves do not insert
21 | P a g e
more than 16 wait states to prevent any single access locking the bus for a large
number of clock cycles.
Transfer Response
A typical slave will use the HREADY signal to insert the appropriate number of
wait states into the transfer and then the transfer will complete with HREADY
HIGH and an OKAY response, which indicates the successful completion of the
transfer.
The ERROR response is used by a slave to indicate some form of error condition
with the associated transfer. Typically this is used for a protection error, such as an
attempt to write to a read-only memory location.
The SPLIT and RETRY response combinations allow slaves to delay the
completion of a transfer, but free up the bus for use by other masters. These
response combinations are usually only required by slaves that have a high access
latency and can make use of these response codes to ensure that other masters are
not prevented from accessing the bus for long periods of time.[1]
The encoding of HRESP [1:0], the transfer response signals, and a description of
each response are shown in Table.
HRESP[1] HRESP[0] Response Description
0 0 OKAY WHEN HREADY is HIGH this shows the transfer has
completed successfully.
The OKAY response is also used for any additional
cycles that are inserted, with HREADY LOW, prior to
giving one of the three other responses. [1]
0 1 ERROR This responses shows an error has occurred. The error
condition should be signaled to the bus master so that it
is aware the transfer has been unsuccessful. [1]
A two-cycle response is required for an error condition.
1 0 RETRY The RETRY response shows the transfer has not yet
completed, so the bus master should retry the transfer.
The master should continue to retry the transfer until it
completes. [1]
A two-cycle RETEY response is required.
1 1 SPLIT The transfer has not yet completed successfully. The
bus master must retry the transfer when it is next
granted access to the bus. The slave will request access
to bus on behalf of the master when the transfer can
complete. [1]
A two-cycle SPLIT response is required.
Table 3.5 Transfer Responses
22 | P a g e
When it is necessary for a slave to insert a number of wait states prior to deciding what response
will be given then it must drive the response to OKAY.
Two-cycle response Only an OKAY response can be given in a single cycle. The ERROR, SPLIT and
RETRY responses require at least two cycles. To complete with any of these
responses then in the penultimate (one before last) cycle the slave drives HRESP
[1:0] to indicate ERROR, RETRY or SPLIT while driving HREADY LOW to
extend the transfer for an extra cycle. In the final cycle HREADY is driven HIGH
to end the transfer, while HRESP[1:0] remains driven to indicate ERROR, RETRY
or SPLIT.
If the slave needs more than two cycles to provide the ERROR, SPLIT or RETRY
response then additional wait states may be inserted at the start of the transfer.
During this time the HREADY signal will be LOW and the response must be set to
OKAY.[1]
The two-cycle response is required because of the pipelined nature of the bus. By
the time a slave starts to issue either an ERROR, SPLIT or RETRY response then
the address for the following transfer has already been broadcast onto the bus. The
two cycle response allows sufficient time for the master to cancel this address and
drive HTRANS[1:0] to IDLE before the start of the next transfer.
For the SPLIT and RETRY response the following transfer must be cancelled
because it must not take place before the current transfer has completed. However,
for the ERROR response, where the current transfer is not repeated, completion of
the following transfer is optional.
23 | P a g e
Figure shows an example of a RETRY operation.
Figure 3.13 Transfer with RETRY Response [1]
The following events are illustrated:
The master starts with a transfer to address A.
Before the response is received for this transfer the master moves the address on to A+4.
The slave at address A is unable to complete the transfer immediately and therefore it issues
a RETRY response. This response indicates to the master that the transfer at address A is
unable to complete and so the transfer at address A + 4 is cancelled and replaced by an
IDLE transfer.
Figure shows a transfer where the slave requires one cycle to decide on the response it is going to
give (during which time HRESP indicates OKAY) and then the slave ends the transfer with a two-
cycle ERROR response.
RETRY response indicated
by two cycle
24 | P a g e
ERROR response If a slave provide an ERROR response then the master may choose to cancel the
remaining transfer in the burst. However, this is not a strict requirement and it is
also acceptable for master to continue the remaining transfer in the burst.
SPLIT and RETRY The SPLIT and RETRY responses provide a mechanism for slaves to release the
bus when they are unable to supply data for a transfer immediately. Both
mechanisms allow the transfer to finish on the bus and therefore allow a higher-
priority master to get access to the bus.
The difference between SPLIT and RETRY is the way the arbiter allocates the bus
after a SPLIT or a RETRY has occurred:
For RETRY the arbiter will continue to use the normal priority scheme and
therefore only masters having higher priority will gain access to the bus.
For SPLIT transfer the arbiter will adjust the priority scheme so that any other
master requesting the bus will get access, even if it is a lower priority. In order
for a SPLIT transfer to complete the arbiter must be informed when the slave
has the data available.
The SPLIT transfer requires extra complexity in both the slave and the arbiter, but
has the advantage that it completely frees the bus for use by other masters, whereas
the RETRY case will only allow higher priority masters onto the bus.
Transfer with ERROR Response
Figure 3.14 Transfer with ERROR response [1]
25 | P a g e
A bus master should treat SPLIT and RETRY in the same manner. It should
continue to request the bus and attempt the transfer until it has either completed
successfully or been terminated with an ERROR response. [1]
3.3.5 Data Buses
In order to allow implementation of an AHB system without the use of tristate drivers separate
read and write data buses are required. The minimum data bus width is specified as 32 bits, but the
bus width can be increased.
HWDATA The write data bus is driven by the bus master during write transfers. If the transfer
is extended then the bus master must hold the data valid until the transfer completes,
as indicated by HREADY HIGH.
All transfers must be aligned to the address boundary equal to the size of the transfer.
For example, word transfers must be aligned to word address boundaries (that is
A[1:0] = 00), halfword transfers must be aligned to halfword address boundaries
(that is A[0] = 0).
For transfers that are narrower than the width of the bus, for example a 16-bit
transfer on a 32-bit bus, then the bus master only has to drive the appropriate byte
lanes. The slave is responsible for selecting the write data from the correct byte
lanes. Table show which byte lanes are active for a little-endian and big-endian
system respectively. If required, this information can be extended for wider data
bus implementations. Burst transfers which have a transfer size less than the width
of the data bus will have different active byte lanes for each beat of the burst.
The active byte lane is dependent on the endianness of the system, but AHB does
not specify the required endianness. Therefore, it is important that all masters and
slaves on the bus are of the same endianness.
HRDATA The read data bus is driven by the appropriate slave during read transfers. If the
slave extends the read transfer by holding HREADY LOW then the slave only
needs to provide valid data at the end of the final cycle of the transfer, as indicated
by HREADY HIGH.
For transfers that are narrower than the width of the bus the slave only needs to
provide valid data on the active byte lanes, as indicated in Table. The bus master is
responsible for selecting the data from the correct byte lanes.
A slave only has to provide valid data when a transfer completes with an OKAY
response. SPLIT, RETRY and ERROR responses do not require valid read data.
26 | P a g e
Transfer
Size
Address
offset
DATA[31:24] DATA[23:16] DATA[15:8] DATA[7:0]
Word 0
Halfword 0 - -
Halfword 2 - -
Byte 0 - - -
Byte 1 - - -
Byte 2 - - -
Byte 3 - - -
Table 3.7 Active Byte Lanes for a 32-bit big-endian data bus
Endianness In order for the system to function correctly it is essential that all modules are of the
same endianness and also that any data routing or bridges are of the same
endianness.
Dynamic endianness is not supported, because in the majority of embedded systems,
this would lead to a significant silicon overhead that is redundant.
For module designers it is recommended that only modules which will be used in a
wide variety of applications should be made bi-endian, with either a configuration
pin or internal control bit to select the endianness. For more application-specific
blocks, fixing the endianness to either little-endian or big-endian will result in a
smaller, lower power, higher performance interface.
3.3.6 Reset
The reset, HRESETn, is the only active LOW signal in the AMBA AHB specification and is the
primary reset for all bus elements. The reset may be asserted asynchronously, but is deasserted
synchronously after the rising edge of HCLK. During reset all masters must ensure the address
and control signals are at valid levels and that HTRANS [1:0] indicates IDLE.
Transfer
Size
Address
offset
DATA[31:24] DATA[23:16] DATA[15:8] DATA[7:0]
Word 0
Halfword 0 - -
Halfword 2 - -
Byte 0 - - -
Byte 1 - - -
Byte 2 - - -
Byte 3 - - -
Table 3.6 Active Byte Lanes for a 32-bit little-endian data bus
27 | P a g e
4 PIPE INTERFACE
Figure 4.1 PIPE Interface
4.1 PIPE INTERFACE SIGNALS
Signal
Name
Width Type
(I/O)
Description
RESETn 1 I PIPE Reset (Active Low)
CLK 1 I PIPE Clock
Txready 1 I Indicates PIPE i/f is ready for write-
data/write command
rxcmdready 1 I Indicates PIPE i/f is ready for read-
command
Rxvalid 1 I Indicates PIPE i/f has valid read data
Rxdata PIPE_DATAWIDTH I PIPE rxdata
Rxlast 1 I Indicates last data of burst
Txdata PIPE_DATAWIDTH O If (cmdvalid==1) PIPE request Address else
Transmit Data
txdatastrb (PIPE_DATAWIDTH)/
8
O If (cmdvalid==1) set to all 1 else PIPE
transmit DATA Strobe
Cmd 17 O PIPE Command.
If (cmdvalid==0)
[0]: txdata is valid on txdata and txdatastrb
[16:1]: Set to 0.
Else command.
cmdvalid 1 O Valid command on cmd.
rxready 1 I Indicates this module is ready to accept data. Table 4.1 PIPE Interface Signals
28 | P a g e
4.2 PIPE WRITE AND READ OPERATION
4.2.1 PIPE Write Operation
AHB Slave commence write request on PIPE interface if and only if txready Signal is
asserted.
At clock edge, cmdvalid signal is asserted along with write command and write address is
given on txdatabus. txdatastrb is don’t care for address transmission.
From next clock edge AHB2PIPE interface sends data transaction on PIPE bus.
AHB2PIPE should continue data transmission on PIPE interface once write transaction has
initiated unless the end of the burst.
4.2.2 PIPE Read Operation
AHB Slave commence read request and cmdvalid is asserted and valid read command
transmitted on PIPE interface along with read command. Read address is given on txdata
bus with datastrb don’t care.
After accepting read request from slave AHB side, MC process read request and gives
requested read data on rxdata & rxvalid. A valid data is received when rxready is asserted
from AHB2PIPE, when rxvalid is asserted.
29 | P a g e
5 CONCLUSION
During the Dissertation phase – I, Literature Review and How AHB is important and why it is
used in the system is learned and FSM of AHB Slave is made and started RTL coding of the
module using Verilog.
30 | P a g e
6 FUTURE WORK
Future Work includes
1. RTL coding of the module slave to PIPE in Verilog.
2. Synthesis of the module after coding is completed.
31 | P a g e
REFERENCES
[1] AMBA Specification 2.0 by ARM Inc.
[2] Wikipedia page available at https://en.wikipedia.org/wiki/Advanced-Microcontroller-
Bus-Architecture
[3] Overview of all specification available at https://www.arm.com/products/system-
ip/AMBA-specifications.php
[4] Specification Document of AHB to Custom PIPE Bridge.
[5] ARM Community Forum
[6] Verilog HDL by Samir Palintkar