Chapter 1.

Introduction
1.0

Introduction about Project

There are many companies that develop core IP for SoC products. The
interfaces to these cores can differ from company to company and can
sometimes be proprietary in nature. The SoC developer then must
expend time, effort, and money to create bridge or glue logic that
allows all of the cores inside the SoC to communicate properly with each
other. Incompatible interfaces are thus barriers to both IP developers and
SoC developers. SoC integrated circuits envisioned by this subcommittee
span a wide breadth of applications, target system costs, and levels of
performance and integration.
Integrated circuits have entered the era of System-on-a-Chip (SoC),
which refers to integrating all components of a computer or other
electronic system into a single chip. It may contain digital, analog, mixedsignal, and often radio-frequency functions all on a single chip
substrate. With the increasing design size, IP is an inevitable choice for
SoC design. And the widespread use of all kinds of IPs has changed the
nature of the design flow, making On-Chip Buses (OCB) essential to the
design.

Of all OCBs existing in the market, the AMBA bus system is widely
used as the de facto standard SoC bus. On March 8, 2010, ARM
announced availability of the AMBA 4.0 specifications. As the de facto
standard SoC bus, AMBA bus is widely used in the high-performance
SoC designs. The AMBA specification defines an on-chip communication
standard for designing high-performance embedded microcontrollers.

ARM introduced the Advanced Microcontroller Bus Architecture

(AMBA) 4.0 specifications in March 2010, which includes Advanced
extensible Interface (AXI) 4.0. AMBA bus protocol has become the de
facto standard SoC bus. That means more and more existing IPs must be
able to communicate with AMBA 4.0 bus. Based on AMBA 4.0 bus, This
design is an Intellectual Property (IP) core of AXI(Advanced extensible
Interface) Lite to APB(Advanced Peripheral Bus) Bridge, which translates
the AXI4.0-lite transactions into APB 4.0 transactions. The bridge
provides interfaces between the high-performance AXI bus and low-power
APB domain [Ref 1].

Chapter 2.Literature Survey

The Advanced Microcontroller Bus Architecture (AMBA) is used as
the on-chip bus in system-on-a-chip (SoC) designs. Since its inception,
the scope of AMBA has gone far beyond microcontroller devices, and is
now widely used on a range of ASIC and SoC parts including applications
processors used in modern portable mobile devices like smart phones.
The AMBA protocol is an open standard, on-chip interconnect
specification for the connection and management of functional blocks in
a System-on-Chip (SoC). It facilitates right-first-time development of
multi-processor

designs

with

large

peripherals.

numbers

of

controllers

and

2.0 About System on Chip (SoC)

SOC is a device which integrates all the computer devices on to one

chip, which runs with desktop operating systems like windows, Linux
etc.
The contrast with a microcontroller is one of degree. Microcontrollers
typically have under 100 KB of RAM (often just a few kilobytes) and often
really are single-chip-systems, whereas the term SoC is typically used
with more powerful processors, capable of running software such as the
desktop versions of Windows and Linux, which need external memory
chips (flash, RAM) to be useful, and which are used with various external
peripherals. In short, for larger systems system on a chip is hyperbole,
indicating

technical

direction

more

than

reality:

increasing

chip

integration to reduce manufacturing costs and to enable smaller

systems. Many interesting systems are too complex to fit on just one chip
built with a process optimized for just one of the system's tasks.
When it is not feasible to construct an SoC for a particular
application, an alternative is a system in package (SiP) comprising a
number of chips in a single package. In large volumes, SoC is believed to
be more cost-effective than SiP since it increases the yield of the
4

fabrication and because its packaging is simpler.

2.0.1 Structure of SoC
A typical SoC consists of:

1.

A microcontroller, microprocessor or DSP core(s). Some SoCs

called multiprocessor system on chip (MPSoC)include
more than one processor core.

2.

Memory blocks including a selection of ROM,

RAM, EEPROM and flash memory.

3.

Timing sources including oscillators and phase-locked loops.

4.

Peripherals including counter-timers, realtime timers and power-on reset generators.

5.

External interfaces including industry standards such

as USB, FireWire, Ethernet, USART, SPI.

6.

Analog interfaces including ADCs and DACs.

7.

Voltage regulators and power management circuits.

These blocks are connected by either a proprietary or

industry

standard bus such

Holdings. DMA controllers

as

route

the AMBA bus

data

directly

from ARM
between

external interfaces and memory, bypassing the processor core and

thereby increasing the data throughput of the SoC [Ref 2].

Figure 2.0 ARM-SoC Block Diagram

2.1 About Advanced Microcontroller Bus Architecture

(AMBA)
Advanced Microcontroller Bus Architecture (AMBA) specification
defines an on chip communications standard for designing high-

performance embedded microcontrollers.

The de facto standard for on-chip communication
The AMBA protocol is an open standard, on-chip interconnect
specification for the connection and management of functional blocks in
a System-on-Chip (SoC). It facilitates right-first-time development of
multi-processor

designs

with large

numbers

of

controllers

and

peripherals. AMBA promotes design re-use by defining a common

backbone for SoC modules using specifications for ACE, AXI, AHB,
APB and ATB.
AMBA 4 is the latest addition to the AMBA family adding five new
interface protocols: ACE for full cache coherency between processors;
ACE-Lite for I/O coherency; AXI4 to maximize performance and power
efficiency; AXI4-Lite and AXI4-Stream ideal for implementation in FPGA.
Another family of buses that the Power.org Bus Architectures TSC
decided to investigate is the ARM AMBA (Advanced Microcontroller Bus
Architecture) set of buses: APB, AHB and AXI. The APB (Advanced
Peripheral Bus) is considered a low-performance, peripheral level bus.
The AHB (Advanced High-performance Bus) is considered (despite the
bus name) a mid-performance bus and the AXI (Advanced eXtensible
Interface) bus is considered a high-performance bus. The AMBA family of
7

buses was chosen for consideration because of their widespread

acceptance in the industry and large amount of existing IP cores.
We note in passing that the APB bus is not always used as a
standalone bus. Some AMBA based IP cores will use a higher performing
bus like AHB or AXI for the primary function, but use an APB port for
access to configuration registers [Ref 3].
2.1.1 AMBA Specifications
AMBA enables IP re-use
IP re-use is an essential component in reducing SoC development
costs and timescales. AMBA specifications provide the interface standard
that enables IP re-use meeting the essential requirements of:
1. Flexibility
IP re-use requires a common standard while supporting a wide
variety

of

SoCs

with

different

power,

performance

and

area

requirements. With its ACE, AXI, AHB and APB interface protocols;
AMBA 4 has the flexibility to match every requirement.
2. Multi-Layer
The Multi-layer architecture acts as a crossbar switch between
masters and slaves in an AMBA 3 AXI or AHB system. The parallel
8

links allow the bandwidth of the interconnect to support the peak

bandwidth of the masters without increasing the frequency of the
interconnect.
3. Compatibility
It is a standard interface specification that ensures compatibility
between IP components from different design teams or vendors. The
AMBA specification is available as both a written specification as well
as a set of assertions that unambiguously define the interface
protocol, thus ensuring this level of compatibility.
4. Support
The

wide

adoption

of

AMBA

specifications throughout

the

semiconductor industry has driven a comprehensive market in third

party IP products and tools to support the development of AMBA
based systems. The availability of AMBA assertions promotes this
industry wide participation [Ref 4].

2.1.2 Design principles of AMBA

The important aspect of a SoC is not only which components or
blocks it houses, but also how they are interconnected. AMBA is a
solution for the blocks to interface with each other.
The objective of the AMBA is to:

1. facilitate right-first-time development of embedded microcontroller

products with one or more CPUs, GPUs or signal processors,
2. be technology independent, to allow reuse of IP cores, peripheral
and system microcells across diverse IC processes,
3. encourage

modular

system

design

to

improve

processor

independence, and the development of reusable peripheral and

system IP libraries

Minimize silicon infrastructure while supporting high performance

and low power on-chip communication [Ref 5].

2.1.3 AMBA Versions

1. VER1.0 (ASB & APB)

10

2. VER 2.0 (AHB)

3. VER 3.0 (AXI ,ATB)
4. VER 4.0 (AXI 4,AXI LITE,AXI STREAM (AXI))

2.1.4 AMBA 4.0 specification buses/interfaces

1. Advanced eXtensible Interface (AXI)
a. AXI4
b. AXI4-Lite
c. AXI-4 Stream

2. Advanced High-performance Bus (AHB)

3. Advanced System Bus (ASB)
4. Advanced Peripheral Bus (APB)
5. Advanced Trace Bus (ATB)

In this project

these are to be used Advanced eXtensible

Interface (AXI4-Lite) & Advanced Peripheral Bus (APB) because these

are high bandwidth data transfer between high performance devices like
processor, DMA, RAM etc..,. and Peripheral devices[Ref 5].

2.2 About Advanced eXtensible Interface (AXI)

In previous SOC design a lot of buses are used which are
introduced by ARM. ARM introduced ASB the first High data transfer
11

between modules, then again ARM introduced AHB and AXI in followed
version of AMBA.
ARM AMBA (Advanced Microcontroller Bus Architecture) set of
buses: ASB, AHB and AXI. The AHB (Advanced High-performance Bus) is
considered (despite the bus name) a mid-performance bus and the AXI
(Advanced eXtensible Interface) bus is considered a high-performance
bus. The AMBA family of buses was chosen for consideration because of
their widespread acceptance in the industry and large amount of existing
IP cores.
History of High-Performance Buses
1. ASB (Advanced System Bus)
2. AHB (Advanced High-performance Bus)
3. AXI (Advanced eXtensible Interface)
1. AXI4
2. AXI4-Lite
3. AXI4-Stream
1. ASB (Advanced System Bus)
The Advanced System Bus (ASB) specification defines a highperformance bus that can be used in the design of high performance 16

12

and 32-bit embedded microcontrollers. AMBA ASB supports the efficient

connection of processors, on-chip memories and off-chip external
memory interfaces with low-power peripheral microcell functions. The
bus also provides the test infrastructure for modular macro cell test and
diagnostic access [Ref 6]. The features of ASB are;
1. High performance
2. Pipelined operation
3. Burst transfers
4. Multiple bus masters

2. AHB (Advanced High-performance Bus)

AHB is the mid-performance bus in the AMBA family. The protocol
defines a 32-bit address bus (HADDR), but this has been extended in
some implementations. The read and write data buses (HRDATA and
HWDATA) may be defined under the specification as 2n bits wide, from 8bit to 1024-bit, but the most common implementation has been 32-bit.
With 27 additional control signals, and assuming the most common
address and data bus width of 32-bit, AHB can have up to 123 I/O for
each AHB master.

13

Up to 16 AHB masters may be connected to a central interconnect

which arbitrates between master requests, and multiplexes the winning
request and corresponding transfer qualifiers to the slaves. Slave read
data is multiplexed back to the masters [Ref 3].
In addition to previous release, it has the following features:
1. single edge clock protocol
2. split transactions
3. several bus masters
4. burst transfers
5. pipelined operations
6. single-cycle bus master handover
7. non-tristate implementation
8. Large bus-widths (64/128 bit).

A simple transaction on the AHB consists of an address phase and a

subsequent data phase (without wait states: only two bus-cycles). Access
to the target device is controlled through a MUX (non-tristate), thereby
admitting bus-access to one bus-master at a time.
3. AXI (Advanced eXtensible Interface)

14

AXI is the high-performance bus in the AMBA family. The architecture

defines three write channels and two read channels. The write channels
are address, write data, and response. The read channels are address
and read data. The address channels include 32-bit address buses,
AWADDR

and

ARADDR,

but

this

could

be

extended

in

some

implementations. The write and read data buses (WDATA and RDATA)
may be defined under the specification as any 2n number, from 8-bit to
1024-bit. With the assumption that both the address and data buses are
32-bit, and that the data buses are 128-bit, the write address, write
data, and write response channels would require 56, 139, and 8 I/O,
respectively. The read address and read data channels would require 56
and 137 I/O, respectively. Thus, each 128-bit AXI master has 396 I/O
total.

AXI masters and slaves are connected together through a central

interconnect, which routes master requests and write data to the proper
slave, and returning read data to the requesting master. The interconnect
also maintains ordering based on tags if, for example, a single master
pipelines read requests to different slaves.
AXI uses a handshake between VALID and READY signals. VALID is
driven by the source, and READY is driven by the destination. Transfer of
information, either address and control or data, occurs when both VALID
15

and READY are sampled high. AXI, the third generation of AMBA
interface defined in the AMBA 3 specification, is targeted at high
performance, high clock frequency system designs and includes features
which make it very suitable for high speed sub-micrometer interconnect.

1.

separate address/control and data phases

2.

support for unaligned data transfers using byte strobes

3.

burst based transactions with only start address issued

4.

issuing of multiple outstanding addresses

5.

Easy addition of register stages to provide timing closure [Ref 3].

The AXI Revisions (Advanced eXtensible Interface)

1. AXI4
2. AXI4-Lite
3. AXI4-Stream
The table shows the differences between Interface parameters for above
revisions [Ref 7].

16

Table 2.0 Interface parameters for AXI4 and AXI4-Lite

Table 2.1 Interface parameters for AXI4-Stream

17

1. AXI4 signals modified in AXI4-Lite

The AXI4-Lite interface does not fully support the following signals:
RRESP, BRESP
2. AXI4 signals not supported in AXI4-Lite
The AXI4-Lite interface does not support the following signals:
a) AWLEN, ARLEN The burst length is defined to be 1, equivalent to
an AxLEN value of zero.
b) AWSIZE, ARSIZE All accesses are defined to be the width of the
data bus.
c) AWBURST, ARBURST The burst type has no meaning because
the burst length is 1.
d) AWLOCK, ARLOCK All accesses are defined as Normal accesses,
equivalent to an AxLOCK value of zero.
e) AWCACHE, ARCACHE All accesses are defined as Non-modifiable,
Non-buffer able, equivalent to an Ax CACHE value of 0b0000.
Note:-AXI4-Lite requires a fixed data bus width of either 32-bits or 64-bits
[Ref 7].
18

2.3 About the Advanced Peripheral Bus (APB)

The Advanced Peripheral Bus (APB) is part of the Advanced
Microcontroller Bus Architecture (AMBA) protocol family. It defines a lowcost interface that is optimized for minimal power consumption and
reduced interface complexity.
The APB protocol is not pipelined, use it to connect to lowbandwidth peripherals that do not require the high performance of the
AXI protocol.

The APB protocol relates a signal transition to the rising edge of

the clock, to simplify the integration of APB peripherals into any design
flow. Every transfer takes at least two cycles.
The APB can interface with:
1. AMBA Advanced High-performance Bus (AHB)
2. AMBA Advanced High-performance Bus Lite (AHB-Lite)
3. AMBA Advanced Extensible Interface (AXI)
4. AMBA Advanced Extensible Interface Lite (AXI4-Lite)
19

You can use it to access the programmable control registers of peripheral

devices.
2.3.1 APB revisions
The APB Specification Rev E, released in 1998, is now obsolete and
is superseded by the following three revisions:
1.

AMBA 2 APB Specification

2.

AMBA 3 APB Protocol Specification v1.0

3.

AMBA APB Protocol Specification v2.0.

Out of these AMBA APB Protocol Specification v2.0 is used in this

project.
AMBA 2 APB Specification
This specification defines the interface signals; the basic read and
write transfers and the two APB components the APB Bridge and the
APB slave. This version of the specification is referred to as APB2.
AMBA 3 APB Protocol Specification v1.0
The AMBA 3 APB Protocol Specification v1.0 defines the following
additional functionality:

Wait states.

Error reporting.

The following interface signals support this functionality:

PREADY A ready signal to indicate completion of an APB transfer.
20

PSLVERR An error signal to indicate the failure of a transfer.

This version of the specification is referred to as APB3.
AMBA APB Protocol Specification v2.0
The AMBA APB Protocol Specification v2.0 defines the following
additional functionality:

Transaction protection.

Sparse data transfer.

The following interface signals support this functionality:

PPROT A protection signal to support both non-secure and
secure transactions on APB.
PSTRB A write strobe signal to enable sparse data transfer on the
write data bus.
This version of the specification is referred to as APB4 [Ref 8].

2.4 Different types of Bridges

1. ASB to APB Bridge
2. AHB to APB Bridge
3. AXI4-Lite to APB Bridge
Out of these AXI4-Lite to APB Bridge is used for this project. This is the

21

latest bridge.
1. ASB to APB Bridge
The APB Bridge provides an interface between the ASB and the
Advanced Peripheral Bus (APB). It continues the pipelining of the ASB by
inserting wait cycles on the ASB only when they are needed. It inserts
them for burst transfers or read transfers when the ASB must wait for
the APB [Ref 9].

Fig. 2.1 ASB to APB Bridge Block Diagram

The implementation of this block contains:

22

1. a state machine, which is independent of the device memory

map
2. ASB address, and data bus latching
3. Combinatorial address decoding logic to produce PSELx
signals.
To add new peripherals, or alter the system memory map only the
address decode section needs to be modified

2. AHB to APB Bridge

The AHB2APB interfaces the AHB to the APB. It buffers address,
control and data from the AHB, drives the APB peripherals and returns
data and response signals to the AHB. It decodes the address using an
internal address map to select the peripheral. The AHB2APBis designed
to operate when the APB and AHB clocks have the same frequency and
phase.
In addition to supporting all basic requirements for AMBA
compliance, the AHB2APB provides enhancements to the APB protocol.
With AHB2APB, an APB peripheral can insert wait states by holding its
pready signal low for the required number of cycles.
23

In the AMBA specification, APB accesses are word-wide (32 bits). The
AHB2APB provides the signal pbyte_enable[3:0] to allow byte and halfword accesses. These can be used by the APB peripheral as necessary.
The AHB2APB does not perform any alignment of the data, but transfers
data from the AHB to the APB for write cycles and from the APB to the
AHB for read cycles.
The AHB2APB does not support burst transfers and converts any
burst transfers into a series of APB accesses. The AHB slave interface
supplied by the AHB2APB does not make use of the split response
protocol [Ref 10]

Fig. 2.2 AHB to APB Bridge Block Diagram

24

3. AXI4-Lite to APB Bridge

In this study, we focused mainly on the implementation aspect of an
AXI4-Lite to APB Bridge. The AXI4-Lite to APB Bridge provides an
interface between the high-performance AXI domain and the low power
APB domain. It appears as a slave on AXI bus but as a master on APB
that can access up to sixteen slave peripherals. Read and write transfers
on the AXI bus are converted into corresponding transfers on the APB.
The AXI4-Lite to APB bridge

Block diagram is shown in Figure. (2.3)

Fig. 2.3 AXI to APB Bridge Block Diagram

Features of bridge

25

The Xilinx AXI to APB Bridge is a soft IP core with these features:
4. AXI interface is based on the AXI4-Lite specification
5. APB interface is based on the APB3 specification, supports
optional APB4 selection
6. Supports 1:1 (AXI:APB) synchronous clock ratio
7. Connects as a 32-bit slave on 32-bit AXI4-Lite
8. Connects as a 32-bit master on 32-bit APB3/APB4
9. Supports optional data phase time out

2.5 Connections of an Asynchronous FIFO

The Asynchronous FIFO is a First-In-First-Out memory queue with
control logic that performs management of the read and write pointers,
generation of status flags, and optional handshake signals for interfacing
with the user logic.
Almost Full Flag: Generates an Almost Full signal, indicating that one
additional write can be performed before the FIFO is full.

26

Almost Empty Flag: Generates an Almost Empty signal, indicating that

one additional read can be performed before the FIFO is empty.

The optional handshaking control signals (acknowledge and/or

error) can be enabled via the Handshaking Options button. When
selected, a popup dialog box will appear.

Read Acknowledge Flag: Asserted active on the clock cycle after a

successful read has occurred. This signal, when selected, can be made
active high or low through the GUI.
Read Error Flag: Asserted active on the clock cycle after a read from
the FIFO was attempted, but not successful. This signal, when selected,
can be made active high or low through the GUI.
Write Acknowledge Flag: Asserted active on the clock cycle after a
successful write has occurred. This signal, when selected, can be made
active high or low through the GUI.
Write Error Flag: Asserted active on the clock cycle after a write to the
FIFO was attempted, but not successful. This signal, when selected, can
be made active high or low through the GUI[Ref 12].

27

Fig 2.4 Connections of an Asynchronous FIFO

Chapter 3. Why this Design is selected

Integrated circuits have entered the era of System-on-a-Chip (SoC),
which refers to integrating all components of a computer or other
electronic system into a single chip. It may contain digital, analog, mixed28

signal, and often radio-frequency functions all on a single chip

substrate. With the increasing design size, IP is an inevitable choice for
SoC design. And the widespread use of all kinds of IPs has changed the
nature of the design flow, making On-Chip Buses (OCB) essential to the
design.
The three main criteria used to select buses for consideration were:
1. The level of acceptance and penetration in the industry: It would
hinder acceptance of the bus hierarchy if an obscure set of buses were
chosen that did not have an existing industry support structure and
library of useful available IP.
2. The technical ability to support the wide range of applications found in
typical SoCs: It would be a mistake to specify a set of buses that lacked
the

features

or

sufficient

bandwidth

to

support

common

SoC

applications.
3. The ease of interfacing to Power Architecture processors: Given that
the main goal of Power.org is to promote Power Architecture processors, it
would make little sense for the Power.org Bus

29

4. Architectures to specify a set of buses that were difficult or

cumbersome to attach to Embedded Power Processors or would add
unnecessary bridges in the main transaction paths.
5. The ability to easily obtain a license for the bus architecture to create
verification and core IP. Buses that have been restricted to internal
development only were not considered in this report.
Of all OCBs existing in the market, the AMBA bus system is widely
used as the de facto standard SoC bus. On March 8, 2010, ARM
announced availability of the AMBA 4.0 specifications. As the de facto
standard SoC bus, AMBA bus is widely used in the high-performance
SoC designs. The AMBA specification defines an on-chip communication
standard for designing high-performance embedded microcontrollers.
ARM introduced the Advanced Microcontroller Bus Architecture
(AMBA) 4.0 specifications in March 2010, which includes advanced
extensible Interface (AXI) 4.0. AMBA bus protocol has become the de
facto standard SoC bus. That means more and more existing IPs must be
able to communicate with AMBA 4.0 bus. Based on AMBA 4.0 bus, we
designed an Intellectual Property (IP) core of AXI (Advanced extensible
Interface) Lite to APB (Advanced Peripheral Bus) Bridge, which translates
the AXI4.0-lite transactions into APB 4.0 transactions. The bridge provide
30

Interfaces between the high-performance AXI bus and low-power APB

domain.
Advanced Microcontroller Bus Architecture (AMBA) specification
defines an on chip communications standard for designing highperformance embedded microcontrollers.
AMBA Versions

1. VER1.0 (ASB & APB)

2. VER 2.0 (AHB)
3. VER 3.0 (AXI, ATB)
4. VER 4.0 (AXI 4,AXI LITE,AXI STREAM (AXI))

AMBA 4.0 specification buses/interfaces

1.Advanced eXtensible Interface (AXI)
d. AXI4
e. AXI4-Lite
f. AXI-4 Stream

2.Advanced High-performance Bus (AHB)

3.Advanced System Bus (ASB)
4. Advanced Peripheral Bus (APB)
5.Advanced Trace Bus (ATB)

31

In this project these are to be used

Advanced eXtensible

Interface (AXI4-Lite) & Advanced Peripheral Bus (APB) because these

are high bandwidth data transfer between high performance devices like
processor, DMA, RAM etc..,. and Peripheral devices.

Chapter 4. Aim of the Project

An Intellectual Property (IP) core of AXI4(Advanced eXtensible
Interface) Lite to APB(Advanced Peripheral Bus) Bridge, which translates
the AXI4.0-lite transactions into APB 4.0 transactions. The bridge
provides interfaces between the high-performance AXI bus and low-power
APB domain.

4.0 Functional Description

Overview:
The AXI to APB Bridge translates AXI4-Lite transactions into APB
transactions. The bridge functions as a slave on the AXI4-Lite interface
and as a master on the APB interface. The AXI to APB Bridge main use
model is to connect the APB slaves with AXI masters. Both AXI4-Lite
and APB transactions are happened during rising edge of the clock.
The AXI to APB Bridge block diagram is shown in Figure (i) and
described in subsequent sections.
32

Fig. (4.1) AXI to APB Bridge Block Diagram

AXI4-Lite Slave Interface
The AXI4-Lite Slave Interface module provides a bi-directional slave
interface to the AXI. The AXI address and data bus widths are always
fixed to 32-bits and 1024bits. When both write and read transfers are
simultaneously requested on AXI4-Lite, the read request is given more
priority than the write request. This module also contains the data phase
time out logic for generating OK response on AXI interface when APB
slave does not respond.
APB Master Interface
The APB Master module provides the APB master interface on the
APB. This interface can be APB3 or APB4, which can be selected by
setting the generic C_M_APB_PROTOCOL. When C_M_APB_PROTOCOL=apb4,

33

the M_APB_PSTRB, and M_APB_PPROT signals are driven at the APB

Interface. The APB address and data bus widths are fixed to 32-bits.

4.1 Features of the project

We provide an implementation of AXI4-Lite to APB Bridge which has
the following features:
1. 32-bit AXI slave and APB master interfaces.
2. PCLK clock domain completely independent of ACLK clock
domain.
3. Support up to 16 APB peripherals.
4. Support the PREADY signal which translates to wait states
on AXI.
5.

An error on any transfer results in SLVERR as the AXI

read/write response.

4.2 Objectives of the project:

1. With the increasing design size, IP is an inevitable choice for SoC
design. And the widespread use of all kinds of IPs has changed the
nature of the Design flow, making On-Chip Buses (OCB) essential
to the design. Of all OCBs existing in the market, the AMBA bus
system is widely used as the de facto standard SoC bus.
2. That means more and more existing IPs must be able to
communicate with AMBA 4.0 bus. Based on AMBA 4.0 bus, we
34

designed an Intellectual Property (IP) core of AXI4LITE-APB

Advanced Peripheral Bus (APB) Bridge, which translates the
AXI4.0-lite transactions into APB 4.0 transactions.
3. There will be data missing when high performance modules like
DMA,

RAM,

and

Processor

are

directly

interfaced

to

low

performance modules/devices like peripheral devices. By this the

system will slowdown in data transfer and there will be no
synchronization

of

clock

timings

between

the

modules.

To

overcome this problem a bridge should be provided which makes

good data communication and good synchronization of timings
between modules at any frequency. The data transfers are done like
two-way control operation that is source is master, destination is
slave and vice versa.
4. The bridge provides high speed of data transactions between high
performance modules and low performance devices.
5. The bridge provides interfaces between the high-performance AXI
bus and low-power APB domain.

Chapter 5. Overview of the Project

An AMBA-based microcontroller typically consists of a highperformance system backbone bus (AMBA AXI Lite), able to sustain the
external memory bandwidth, on which the CPU, on-chip memory and
other Direct Memory Access (DMA) devices reside. This bus provides a
high-bandwidth interface between the elements that are involved in the
35

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 (see Figure (4.1)).

Fig. (5.1) Overview of AXI Lite to APB Bridge

5.0 About the Advanced eXtensible Interface (AXI)

Protocol:
The AMBA AXI protocol supports high-performance, high-frequency
system designs.
The AXI protocol:

36

1. is suitable for high-bandwidth and low-latency designs

2. provides

high-frequency

operation

without

using

complex

bridges
3. meets the interface requirements of a wide range of components
4. is suitable for memory controllers with high initial access
latency
5. Provides flexibility in the implementation of interconnect
architectures is backward-compatible with existing AHB and
APB interfaces.
The key features of the AXI protocol are:
1. Separate address/control and data phases
2. Support for unaligned data transfers, using byte strobes
3. uses burst-based transactions with only the start address
issued
4. separate read and write data channels that can provide low-cost
DMA
5. Support for issuing multiple outstanding addresses
6. Support for out-of-order transaction completion
7. Permits easy addition of register stages to provide timing
closure.
The AXI protocol includes the optional extensions that cover signaling
for low-power operation
AXI Revisions
37

1. AXI4
2. AXI4-Lite
3. AXI4-stream
Note: Out of these AXI4-Lite is used
1. AXI4:
The AXI4 protocol is an update to AXI3 to enhance the performance
and utilization of the interconnect when used by multiple masters. It
includes the following enhancements:
1. Support for burst lengths up to 256 beats
2. Quality of Service signaling
3. Support for multiple region interfaces

2. AXI4-Lite:

The AXI4-Lite protocol is a subset of the AXI4 protocol intended for

communication with simpler, smaller control register style interfaces in
components. The key features of the AXI4-Lite interface are:

1. All transactions are burst length of one

2. All data accesses are the same size as the width of the data bus
3. Exclusive accesses are not supported
38

3. AXI4-Stream:

The AXI4-Stream protocol is designed for unidirectional data transfers

from master to slave with greatly reduced signal routing. Key features are
1. Supports single and multiple data streams using the same set of
shared wires
2. Support for multiple data widths within the same interconnect
3. Ideal for implementation in FPGA

5.0.1 AXI strengths:

AXI offers several features that allow for high performance. However,
achieving the highest performance at a system level requires that all of
the AXI masters and slaves are designed to a high performance target,
since,. AXI can use the higher frequency along with a data bus that can
be defined to 128-bit and above to achieve the band
1. Data Pipelining:
Buses that do not pipeline cannot achieve full bus utilization and
peak bandwidth given that there will be transfer latency to and from the
slaves. AXI supports 16 deep read and 16 deep write data pipelining.

39

This allows for full bus utilization, even with interfaces with extremely
long latency.

2. Multiple Data Beats per Burst Request:

AXI address and data phases are independent from one another, so
a burst request that is accepted by a slave when READY and VALID are
active must consist of the number of data beats the master requested,
with no further interaction with the address and control signals. The
driver of the burst data also sends a LAST signal to mark the last beat of
burst data. width required for mid- and some high-performance bus
applications
3. Write Strobes:
AXI defines write strobes to enable the transfer of some or all of the
bytes on the write data bus in a single beat. Given a 128-bit AXI, this
allows any number of bytes between 1 and 16 to be transferred in a
single beat on the write data bus. Buses that do not support write
strobes can require that multiple transfers be made for bytes inside a
single quad word. Having write strobes also enables AXI masters to limit
propagation of write data with errors. If the master discovers there are

40

errors in write data that has yet to be sent to AXI, it is allowed to

complete the burst from a data beat standpoint, but without enabling
any of the write strobes.
4. Out-of-order Reads:
AXI uses the ARID [3:0] bus on the read address channel to allow
slaves to return read data out-of-order with respect to the order of the
read requests. Reads made with the same ARID[3:0] must remain in
order, but reads made with different ARID[3:0] may be returned out-oforder. This improves read data channel utilization by allowing slaves with
shorter latencies to return data as soon as it is available, rather than
forcing them to return in the request order, potentially behind a slave
with much longer read latency. This is a better mechanism than
performing delayed reads, since they require communication between the
master and slave once the read data is available, and then a subsequent
repeat of the read request from the master. Simple slaves may not choose
to implement out-of-order read data, so system integrators must be
careful when selecting IP to be placed on the same AXI interconnect.
Simple slaves with long latency will negate the benefit of the other slaves
performing reads out-of-order, since the interconnect must guarantee

41

that reads with the same ARID from different slaves return read data in
the same order in which the requests were made.
5. Write Data Interleaving:
Multiple AXI masters may attempt to write data to a single slave at
the same time. Some masters buffer all of the write data before making
the request, but others assemble data to send after the request is made.
AXI slaves that support write data interleaving can accept write data
from both types of masters in what looks like a single data tenure, with
the AWID value switching between the masters sending write data. This
allows interconnect to avoid stalling the write data bus to the slave,
waiting for writes data to be assembled. Instead, the interconnect sends
write data from a buffered write master in between beats of write data
from the assemble write master.
6. Separate Data Buses:
AXI doubles the peak bandwidth at a given frequency by using
separate buses for read and write data. These buses are used in
conjunction with data pipelining to increase performance.
7. Handshaking:

42

The VALID and READY handshaking mechanism in AXI allows

both masters and slaves to control the flow of data. This can be
problematic if, for example, a poorly designed master makes a write
request while still assembling write data that is coming in from a slower
or narrower interface. One real benefit of having the handshake
mechanism is that slaves with long latencies can accept more requests
than they have buffer space for. So, for example, an AXI PCIe slave may
queue eight reads, but only have enough buffer space for four. The slave
can do this if the masters are guaranteed to accept the read data when
the slave drives it back. This is an area and cost savings, but requires
knowledge of specific AXI master capabilities, and should therefore be
implemented as a configuration option in a general purpose AXI slave.

8. Exclusive Access:
AXI supports an exclusive access mechanism that enables
semaphore types of operations without requiring the bus to be locked.
The process is
1) A master requests an exclusive read from an address location,

43

2) The same master, some time later, attempts to complete the exclusive
operation by attempting an exclusive write to the same address. The
exclusive write is only able to complete successfully if no other master
has written to that location between the exclusive read and write and
this mechanism could be used to improve the performance of Power
processors attached to AXI.
9. No Slave Burst Termination:
Once an AXI slave acknowledges a burst transfer, it is responsible for
accepting all of the write data or generating all the read data associated
with that burst. This simplifies master designs, since the master does not
have to prepare to make a subsequent request if the slave terminated the
original request before all of its data was transferred. Giving slaves the
ability to terminate bursts is not required when the burst length is
declared with the request, and is reasonably short. AXI bursts are 16
beats or fewer.

10. Excellent Verification Support:

44

AXI offers a large selection of verification IP from several different

suppliers. The solutions offered support several different languages and
run in a choice of environments.
11. Flexible Complexity:
AXI masters and slaves are more difficult to design than AHB
masters and slaves. However, there are several optional features that may
be left unimplemented in order to reduce the increase in complexity. And
may be somewhat offset with the availability of more sophisticated
verification support.
12. Data Bus Width:
AXI is defined with a choice of several bus widths, in 2n increments
from 8-bit to 1024-bit. The ability to select the data bus width at the
time of synthesis improves the scalability (in peak bandwidth) of the core
IP. However, supporting even a few bus widths does add to the complexity
of the design, and choices need to interlock with other core IP to
maintain interoperability.
13. Error Reporting:
AXI defines errors in the read and write response channels. The
slave can respond with SLVERR if it detects a problem, and the
45

interconnect can respond with DECERR if no slave accepts the transfer.

Interrupts from masters are handled outside the AXI architecture.
14. IP Core Portability:
The vast majority of the IP cores designed with an AXI interface are
available as synthesizable cores. The source Verilog or VHDL is
provided and synthesized into the target technology.

5.1 AXI Architecture

The AXI protocol is burst-based and defines the following
independent transaction channels:
1. read address
2. read data
3. write address
4. write data
5. Write response.
An address channel carries control information that describes the
nature of the data to be transferred. The data is transferred between
master and slave using either:

46

1. A write data channel to transfer data from the master to the slave.
In a write transaction, the slave uses the write response channel to
signal the completion of the transfer to the master.
2. A read data channel to transfer data from the slave to the master.
The AXI protocol:
1. Permits address information to be issued ahead of the actual data
transfer
2. supports multiple outstanding transactions
3. Supports out-of-order completion of transactions.
Figure (5.2) shows how a read transaction uses the read address and
read data channels.

Fig...(5.2) Channel architecture of reads

Figure (4.3) shows how a write transaction uses the write address, write
data, and write response channels.
47

Fig...(5.3) Channel architecture of writes

Channel definition for AXI Architecture

Each of the independent channels consists of a set of information
signals, in these VALID and READY signals that provide a two-way
handshake mechanism. Transfer occurs only when both the VALID and
READY signals are HIGH. All five transaction channels use the same
VALID/READY handshake process to transfer address, data and
control information.
The information source uses the VALID signal to show when valid
address, data or control information is available on the channel. The
destination uses the READY signal to show when it can accept the
information. Both the read data channel and the write data channel also

48

include a LAST signal to indicate the transfer of the final data item in a
transaction.
1. Read and write address channels
Read and write transactions each have their own address channel
which carries all of the required address and control information for a
transaction.
2. Read data channel
The read data channel conveys both the read data and read
response information from the slave back to the master. It includes:

1. The data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024
bits wide (RDATA)
2. A read response indicating the completion status of the read
transaction.
3. Data and response group signals are maintained until the RReady
signal is asserted
3. Write data channel
The write data channel conveys the write data from the master to
the slave and includes:
1. the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024
49

bits wide (WDATA)

2. One byte lane strobe for every byte, indicating which bytes of the
data bus are valid (WSTRB)
3. The last transfer inside a burst must be signaled through the
WLAST signal
4.data, strobe and WLast information are maintained until the
WReady signal is asserted
4. Write Response channel
The write response channel provides a way for the slave to respond
to write transactions.
1. All write transactions use completion signaling.
2. The completion signal occurs once for each burst, not for each
individual data transfer within the burst.
3. Response group signals are maintained until the BReady signal is
asserted.

5.2 About the Advanced Peripheral Bus (APB) Protocol

The Advanced Peripheral Bus (APB) is part of the Advanced
Microcontroller Bus Architecture (AMBA) protocol family. It defines a lowcost interface that is optimized for minimal power consumption and
reduced interface complexity.
50

APB revisions
The APB Specification Rev E, released in 1998, is now obsolete and
is superseded by the following three revisions:
1. AMBA 2 APB Specification
2. AMBA 3 APB Protocol Specification v1.0
3. AMBA APB Protocol Specification v2.0.
Out of these using AMBA APB Protocol Specification v2.0.

The APB Bus is the lowest performance bus in the AMBA family.
There are separate address (PADDR), write data (PWDATA), and read data
(PRDATA) buses, up to 32-bits each. With 7 additional control signals,
there can be up to 103 I/O for each APB slave. There is one APB master,
usually the bridge from a higher performance bus that begins a transfer
by asserting the appropriate PSELn signal with PADDR. PWRITE is active
for a write and inactive on a read. PENABLE is asserted in the second
clock, and is held active until PREADY is returned by the slave. The
minimum transfer, read or write, is two clocks. APB slaves also have the
option of inserting wait states for reads or writes by withholding PREADY.
There is an optional PSLVERR signal used by the slave to report an error
on a read or write with PREADY.
51

Assuming a frequency of 133MHz, (which should be achievable in a

90nm or smaller process) and the maximum data bus widths of 32-bits,
the overall APB bandwidth could be as high as 267MB/s, but that
assumes that none of the APB slaves would insert any wait states. Also,
the total APB bandwidth must be shared between all of the APB slaves.
5.2.1 APB strengths
The APB offers a very low cost (based on area), very low power (based
on I/O), and the least amount of complexity. It is intended for use with
simple slaves that do not require much bandwidth.
1. Interface Simplicity: The APB interface and protocol are very simple
and easy to learn. Relatively little effort needs to be spent on APB design
and verification, leaving more time to focus on the device logic.
2. Core IP: There are more than 75 APB cores available from at least 20
different companies. The cores cover a broad range of small bandwidth
applications. There is also verification enablement in models and
checkers/monitors available from at least 6 different companies with
support for 5 different languages.

52

3. Verification IP: There is verification enablement for APB in models

and checkers/monitors available from at least 6 different companies with
support for 5 different languages
4. Bridges Exist: APB cores are accessed by the AHB-to-APB or AXI-toAPB Bridge.
5. IP Core Portability: Most of the IP cores designed with an APB
interface are available as synthesizable cores. The source code, written
in Verilog or VHDL, is provided and synthesized into the target
technology. This IP delivery method typically presents few timing
challenges at the 66-133MHz range expected for APB.
6. Error Reporting: APB defines an optional signal, PSLVERR, driven by
APB slaves on reads or writes with PREADY to indicate an error with the
transfer.

53

Chapter 6.Signal connections

Figure (5.1) shows the component signal connections. The bridge uses:
AMBA AXI-Lite and APB signals as described in the AMBA AXI-Lite 4.0
protocol specification.

54

55

Fig...(6.1) Signal connections

INPUT / OUTPUT signal descriptions

AXI4-Lite Signals list:-

56

57

Table (6.1) signal connections for AXI4-Lite

APB Signals list:-

58

Table (6.2) signal connections for APB

6.0 Handshake mechanisms of AXI & APB

In AXI 4.0 specification, each channel has VALID and READY signals
for handshaking. The source asserts VALID when the control information

59

or data is available. The destination asserts READY when it can accept

the control information or data. Transfer occurs only when both the
VALID and READY are asserted. Figure(5.2) Shows all possible cases of
VALID/READY handshaking. Note that when source asserts VALID, the
corresponding control information or data must also be available at the
same time. The arrows in Figure. Indicate when the transfer occurs. A
transfer takes place at the positive edge of clock. Therefore, the source
needs a register input to sample the READY signal. In the same way, the
destination needs a register input to sample the VALID signal.
Considering the situation of Figure(c), we assume the source and
destination use output registers instead of combination circuit, they need
one cycle to pull low VALID/READY and sample the VALID/READY again
at T4 cycle. When they sample the VALID/READY again at T4, there
should be another transfer which is an error. Therefore source and
destination should use combinational circuit as output. In short, AXI
protocol is suitable register input and combinational output circuit.
The APB Bridge buffers address, control and data from AXI4-Lite, drives the
APB peripherals and returns data and response signal to the AXI4-Lite. It
decodes the address using an internal address map to select the peripheral.
The bridge is designed to operate when the APB and AXI4-Lite have

60

independent clock frequency and phase. For every AXI channel, invalid
commands are not forwarded and an error response generated. That is
once a peripheral accessed does not exist, the APB Bridge will generate
DE CERR as response through the response channel (read or write). And
if the target peripheral exists, but asserts PSLVERR, it will give a
SLVERR response.

Fig. (6.2) Waveforms for handshaking mechanism

6.1Asynchronous FIFO
An asynchronous FIFO refers to a FIFO design where data values
are written to a FIFO buffer from one clock domain and the data values

61

are read from the same FIFO buffer from another clock domain, where
the two clock domains are asynchronous to each other.
Asynchronous FIFOs are used to safely pass data from one clock domain
to another clock domain.
There are many ways to do asynchronous FIFO design, including
many wrong ways. Most incorrectly implemented FIFO designs still
function properly 90% of the time. Most almost-correct FIFO designs
function properly 99%+ of the time. Unfortunately, FIFOs that work
properly 99%+ of the time have design flaws that are usually the most
Difficult to detect and debug (if you are lucky enough to notice the bug
before shipping the product), or the most costly to diagnose and recall.
6.1.1 Passing multiple asynchronous signals:
Attempting to synchronize multiple changing signals from one
clock domain into a new clock domain and insuring that all changing
signals are synchronized to the same clock cycle in the new clock domain
has been shown to be problematic. FIFOs are used in designs to safely
pass multi-bit data words from one clock domain to another.
Data words are placed into a FIFO buffer memory array by control
signals in one clock domain, and the data words are removed from
another port of the same FIFO buffer memory array by control signals
62

from a second clock domain. Conceptually, the task of designing a FIFO

with these assumptions seems to be easy.
6.1.2 Asynchronous FIFO pointers:
In order to understand FIFO design, one needs to understand how the
FIFO pointers work. The write pointer always points to the next word to
be written; therefore, on reset, both pointers are set to zero, which also
happens to be the next FIFO word location to be written. On a FIFO-write
operation, the memory location that is pointed to by the write pointer is
written, and then the write pointer is incremented to point to the next
location to be written.
Similarly, the read pointer always points to the current FIFO word to
be read. Again on reset, both pointers are reset to zero, the FIFO is empty
and the read pointer is pointing to invalid data (because the FIFO is
empty and the empty flag is asserted). As soon as the first data word is
written to the FIFO, the write pointer increments, the empty flag is
cleared, and the read pointer that is still addressing the contents of the
first FIFO memory word, immediately drives that first valid word onto the
FIFO data output port, to be read by the receiver logic. The fact that the
read pointer is always pointing to the next FIFO word to be read means
that the receiver logic does not have to use two clock periods to read the
63

data word. If the receiver first had to increment the read pointer before
reading a FIFO data word, the receiver would clock once to output the
data word from the FIFO, and clock a second time to capture the data
word into the receiver. That would be needlessly inefficient.
The FIFO is empty when the read and write pointers are both equal.
This condition happens when both pointers are reset to zero during a
reset operation, or when the read pointer catches up to the write pointer,
having read the last word from the FIFO.
A FIFO is full when the pointers are again equal, that is, when the
write pointer has wrapped around and caught up to the read pointer.
This is a problem. The FIFO is either empty or full when the pointers are
equal, but which?
One design technique used to distinguish between full and empty is to
add an extra bit to each pointer. When the write pointer increments past
the final FIFO address, the write pointer will increment the unused MSB
while setting the rest of the bits back to zero as shown in Figure 1 (the
FIFO has wrapped and toggled the pointer MSB). The same is done with
the read pointer. If the MSBs of the two pointers are different, it means
that the write pointer has wrapped one more time that the read pointer.
If the MSBs of the two pointers are the same, it means that both

64

Pointers have wrapped the same number of times.

Using n-bit pointers where (n-1) is the number of address bits
required to access the entire FIFO memory buffer, the
FIFO is empty when both pointers, including the MSBs are equal. And
the FIFO is full when both pointers, except the MSBs are equal.
The FIFO design in this paper uses n-bit pointers for a FIFO with
2(n-1) write-able locations to help handle full and empty conditions.
More design details related to the full and empty logic.

65

Fig. (6.3) FIFO full and empty conditions

6.2 Software required

1. Simulation in Verilog
2. Synthesis on SPARTAN FPGA 3E

Chapter 7. Mechanisms of AXI & APB

7.1 Finite state machine
A finite-state machine (FSM) or finite-state automaton (plural: automata),
or

simply

a state

machine,

is

a mathematical

model used

to

design computer programs and digital logic circuits. It is conceived as an

abstract machine that can be in one of a finite number of states. The
machine is in only one state at a time; the state it is in at any given time
is called the current state. It can change from one state to another when
initiated by a triggering event or condition, this is called a transition. A
particular FSM is defined by a list of the possible transition states from
each current state, and the triggering condition for each transition.

66

Finite-state machines can model a large number of problems,

among

which

are electronic

protocol design, parsing and

In biology and
hierarchies

artificial
of

state

design
other

automation, communication
engineering

intelligence research,
machines

are

state

applications.
machines

sometimes

used

or
to

describe neurological systems, and in linguistics they can be used to

describe the grammars of natural languages.

7.2 State diagram of APB

7.2.0 Operating states

67

Figure 7.1 shows the operational activity of the APB.

The state machine operates through the following states:

IDLE: This is the default state of the APB.
SETUP: When a transfer is required the bus moves into the SETUP state,
where the appropriate select signal, PSELx, is asserted. The bus only
remains in the SETUP state for one clock cycle and always moves to the
ACCESS state on the next rising edge of the clock.

68

ACCESS: The enable signal, PENABLE, is asserted in the ACCESS state.

The address, writes, select, and write data signals must remain stable
during the transition from the SETUP to ACCESS state.
Exit from the ACCESS state is controlled by the PREADY signal from the
slave:
If PREADY is held LOW by the slave then the peripheral bus remains in
the ACCESS state.
If PREADY is driven HIGH by the slave then the ACCESS state is exited
and the bus returns to the IDLE state if no more transfers are required.
Alternatively, the bus moves directly to the SETUP state if another
transfer follows.
7.2.1 Write transfer

69

Fig: 7.2 waveform for Write transfer

The write transfer starts with the address, write data, write signal
and select signal all changing after the rising edge of the clock. The first
clock cycle of the transfer is called the SETUP cycle. After the following
clock edge the enable signal PENABLE is asserted and this indicates that
the ENABLE cycle is taking place. The address, data and control signals
all remain valid throughout the ENABLE cycle. The transfer completes at
the end of this cycle.
The enable signal, PENABLE, will be disserted at the end of the
transfer. The select signal will also go LOW, unless the transfer is to be
immediately followed by another transfer to the same peripheral.
In order to reduce power consumption the address signal and the write
signal will not change after a transfer until the next access occurs.
The protocol only requires a clean transition on the enable signal.
It is possible that in the case of back to back transfers the select and
write signals may glitch.
7.2.2 Read transfer

70

Fig: 7.3 wave form for Read transfer

The timing of the address, write, select and strobe signals are all
the same as for the write transfer. In the case of a read, the slave must
provide the data during the ENABLE cycle. The data is sampled on the
rising edge of clock at the end of the ENABLE cycle.
7.2.3 Protection unit support
To support complex system designs, it is often necessary for both
the interconnect and other devices in the system to provide protection
against illegal transactions. For the APB interface, this protection is
provided by the PPROT [2:0] signals.
The three levels of access protection are:
1. Normal or privileged, PPROT [0]
LOW indicates a normal access
HIGH indicates a privileged access.

71

This is used by some masters to indicate their processing mode. A

privileged processing mode typically has a greater level of access within a
system.
2. Secure or non-secure, PPROT [1]
LOW indicates a secure access
HIGH indicates a non-secure access.
This is used in systems where a greater degree of differentiation between
Processing modes is required.
Note: This bit is configured so that when it is HIGH then the transaction
is considered non-secure and when LOW, the transaction is considered
as secure.
3. Data or Instruction, PPROT [2]
LOW indicates a data access
HIGH indicates an instruction access.
This bit gives an indication if the transaction is a data or instruction
access.
Note: This indication is provided as a hint and is not accurate in all
cases. For example, where a transaction contains a mix of instruction
and data items. It is recommended that, by default, an access is marked

72

as a data access unless it is specifically known to be an instruction

access.

Table 7.1 Protection encoding

Note: The primary use of PPROT is as an identifier for Secure or Nonsecure transactions. It is acceptable to use different interpretations of
the PPROT [0] and PPROT [2] identifiers.

7.3 AXI4-Lite
7.3.0 Definition of AXI4-Lite
This section defines the functionality and signal requirements of
AXI4-Lite components.
The key functionality of AXI4-Lite operation is:
1. All transactions are of burst length 1
2. All data accesses use the full width of the data bus.
73

3. AXI4_Lite supports a data bus width of 32-bit or 64-bit.

4. All accesses are Non-modifiable, Non-bufferable
5. Exclusive accesses are not supported.
Signal list:
Shows the required signals on an AXI4-Lite interface.

Table 7.2 AXI4-Lite interface signals

7.3.1 Bus width

AXI4-Lite has a fixed data bus width and all transactions are the
same width as the data bus. The data bus width must be, either 32-bits
or 64-bits.
ARM expects that:
The majority of components use a 32-bit interface

74

 Only components requiring 64-bit atomic accesses use a 64-bit

interface.
A 64-bit component can be designed for access by 32-bit masters,
but the implementation must ensure that the component sees all
transactions as 64-bit transactions.
7.3.2 Write strobes
The AXI4-Lite protocol supports write strobes. This means multisized registers can be implemented and also supports memory structures
that require support for 8-bit and 16-bit accesses.
All master interfaces and interconnect components must provide
correct write strobes.
Any slave component can choose whether to use the write strobes.
The options permitted are:
To make full use of the write strobes
To ignore the write strobes and treat all write accesses as being the full
data bus width
To detect write strobe combinations that are not supported and provide
an error response.

75

A slave that provides memory access must fully support write

strobes. Other slaves in the memory map might support a more limited
write strobe option.
7.3.3 Conversion, protection, and detection
Connection of an AXI4-Lite slave to an AXI4 master requires some
form of adaptation if it can not be ensured that the master only issues
transactions that meet the AXI4-Lite requirements.
This section describes techniques that can be adopted in a system
design to aid with the interoperability of components and the debugging
of system design problems. These techniques are:
1. Conversion: This requires the conversion of all transactions to a
format that is compatible with the AXI4-Lite requirements.
2. Protection: This requires the detection of any non-compliant
transaction. The non-compliant transaction is discarded, and an error
response is returned to the master that generated the transaction.
3. Detection: This requires observing any transaction that falls outside
the AXI4-Lite requirements
notifying the controlling software of the unexpected access
permitting the access to proceed at the hardware interface level.

76

7.3.4 Address structure

The AXI protocol is burst-based. The master begins each burst by
driving control information and the address of the first byte in the
transaction to the slave. As the burst progresses, the slave must
calculate the addresses of subsequent transfers in the burst. A burst
must not cross a 4KB address boundary.
Note:
This prevents a burst from crossing a boundary between two
slaves. It also limits the number of address increments that a slave must
support.
1. Burst length
The burst length is specified by:
ARLEN [7:0], for read transfers
AWLEN [7:0], for write transfers.
In this specification, AxLEN indicates ARLEN or AWLEN.
AXI3 supports burst lengths of 1 to 16 transfers, for all burst types.
AXI4 extends burst length support for the INCR burst type to 1 to 256
transfers. Support for all other burst types in AXI4 remains at 1 to 16
transfers.
77

The burst length for AXI3 is defined as,

Burst Length = AxLEN[3:0] + 1

The burst length for AXI4 is defined as,

Burst Length = AxLEN [7:0] + 1, to accommodate the extended burst
length of the INCR burst type in AXI4.
AXI has the following rules governing the use of bursts:
For wrapping bursts, the burst length must be 2, 4, 8, or 16
A burst must not cross a 4KB address boundary
Early termination of bursts it not supported.
No component can terminate a burst early. However, to reduce the
number of data transfers in a write burst, the master can disable further
writing by deserting all the write strobes. In this case, the master must
complete the remaining transfers in the burst. In a read burst, the
master can discard read data, but it must complete all transfers in the
burst.
Note:
Discarding read data that is not required can result in lost data
when accessing a read-sensitive device such as a FIFO. When accessing
78

such a device, a master must use a burst length that exactly matches the
size of the required data transfer.
In AXI4, transactions with INCR burst type and length greater than
16 can be converted to multiple smaller bursts,
2. Burst size
The maximum number of bytes to transfer in each data transfer, or beat,
in a burst, is specified by:
ARSIZE [2:0], for read transfers
AWSIZE [2:0], for write transfers.

Table 7.3 Burst size encoding

3. Burst type
79

The AXI protocol defines three burst types:

1. FIXED: In a fixed burst, the address is the same for every transfer in
the burst.
This burst type is used for repeated accesses to the same location
such as when loading or emptying a FIFO.
2. INCR: In an incrementing burst, the address for each transfer in the
burst is an increment of the address for the previous transfer. The
increment value depends on the size of the transfer. For example, the
address for each transfer in a burst with a size of four bytes is the
previous address plus four.
This burst type is used for accesses to normal sequential memory.
3. WRAP: A wrapping burst is similar to an incrementing burst, except
that the address wraps around to a lower address if an upper address
limit is reached.
The following restrictions apply to wrapping bursts:
The start address must be aligned to the size of each transfer
The length of the burst must be 2, 4, 8, or 16 transfers.
The burst type is specified by:
ARBURST [1:0], for read transfers.
AWBURST [1:0], for write transfers.
80

In this specification, Ax BURST indicates ARBURST or AWBURST

Table 7.4 Burst type encoding

7.4 Applications

Product Type

Application

Computing

Net book, Smart book, Tablet, eReader, Thin client

Mobile Handset

Smartphones, Feature phones

Automotive

Infotainment, Navigation

Digital Home

Set-top Box, Digital TV, Blu-Ray player, Gaming consoles

Enterprise

LaserJet printers, routers, wireless base-stations, VOIP

phones and equipment
81

Wireless
Infrastructure

Web 2.0, wireless base stations, switches, servers

Table 7.5 Applications of the project

References
1. Design and Implementation of APB Bridge based on AMBA 4.0 (IEEE
2011), ARM Limited.
2. http://en.wikipedia.org/wiki/System_on_a_chip#Structure
3. Power.org Embedded Bus Architecture Report Presented by the Bus
Architecture TSC Version 1.0 11 April 2008
82

4. http://www.arm.com/products/system-ip/amba/amba-openspecifications.php
5. ARM, "AMBA Protocol Specification 4.0", www.arm.com, 2010
6. ARM,AMBA Specification (Rev 2.0).
7. AMBA 4 AXI4, AXI4-Lite, and AXI4-Stream Protocol Assertions
Revision: r0p0 User Guide.
8. AMBA APB Protocol Version: 2.0 Specifications.
9. ASB Example AMBA System Technical Reference Manual Copyright
1998-1999 ARM Limited.
10. AHB to APB Bridge (AHB2APB) Technical Data Sheet Part Number: TCS-PR-0005-100 Document Number: I-IPA01-0106-USR Rev 05 March
2007.
11. LogiCORE IP AXI to APB Bridge (v1.00a) DS788 June 22, 2011 Product
Specification.
12. Simulation and Synthesis Techniques for Asynchronous FIFO Design
Clifford E.Cummings, Sunburst Design, Inc. cliffc@sunburst-design.com.
SNUG San Jose 2002 Rev 1.2., FIFO Architecture, Functions, and
Applications SCAA042A November 1999.
13. ARM, "AMBA Protocol Specification 4.0", www.arm.com, 2010.

14.Ying-Ze Liao, "System Design and Implementation of AXI Bus",

National Chiao Tung University, October 2007.

83

15. Clifford E. Cummings, "Coding And Scripting Techniques For FSM

Designs With Synthesis-Optimized, Glitch-Free Outputs," SNUG
(Synopsys Users Group Boston, MA 2000) Proceedings, September 2000.

16. Clifford E. Cummings, Synthesis and Scripting Techniques for

Designing Multi-Asynchronous Clock Designs, SNUG 2001

17. Simulation and Synthesis Techniques for Asynchronous FIFO Design

Clifford E.Cummings, Sunburst Design, Inc. cliffc@sunburst-design.com.
SNUG San Jose 2002 Rev 1.2.,

18. Lahir, K., Raghunathan A., Lakshminarayana G., LOTTERYBUS: a

new high-performance communication architecture for system-on-chip
deisgns, in Proceedings of Design Automation Conference, 2001.

19. Sanghun Lee, Chanho Lee, Hyuk-Jae Lee, A new multi-channel

onchip-bus architecture for system-on-chips, in Proceedings of IEEE
International SOC Conference, September 2004.

84