AMBA®APB

Protocol
Specification
 1 Introduction

Contents 2 Signal Descriptions

AMBA APB Protocol
Specifi cation 3 Transfers

4 Operating States

5 Interface parity protection

Meet the
team
Nam

Khánh

Kiệt

Nhựt
Thành
 I. Introduction
AMBA:
• AMBA(advanced Microcontroller Bus Architecture) was introduced in 1996 and
designed by the famous chip manufacturing company - ARM. Currently, AMBA
has been and is a widely used bus architecture in SoC systems.
• AMBA has 5 versions, some protocol standards can be mentioned as: APB, AHB,
AXI, ACE,…
• Some characteristics of AMBA: flexibility, high performance, high reliability, low
cost, easy integration into system components.
APB:
• APB stands for (Advanced Peripheral Bus) which is an advanced peripheral
communication standard.
• APB is one of the bus standards of the AMBA family.
 • Main features of APB:
Few communication signals.
Simple data transmission method.
Low resource cost to design.
Low power consumption.
Each read/write requires less than 2 clock cycles.
EX: APB protocol connection example:
II. Signal Descriptions

2. AMBA APB signals

III. Transfers
Realm Management
1 Write transfers 6
Extension, RME

2 Write strobes .
7 Wake-up signaling
3 Read transfers
8 User
4 Error response signaling

5 Protection unit support

 3.1 Write
transfers

• This section describes the following types of write transfer:

• With no wait states
• With wait states
• All signals shown in this section are sampled at the rising edge of
PCLK.
In a write transfer with no wait states, during the Setup phase, PSEL is asserted,
and PADDR, PWRITE, and PWDATA must be valid. In the Access phase, PENABLE
is asserted, and PREADY indicates that the write data will be accepted. Once the
data is accepted, PENABLE and PSEL are deasserted unless another transfer
follows.
3.1.2 With wait states
• Figure 3-2 shows how the Completer can use PREADY to extend the transfer.
In a write transfer with no wait states, during the Setup phase, PSEL is asserted, and
PADDR, PWRITE, and PWDATA must be valid. In the Access phase, PENABLE is
asserted, and PREADY indicates that the write data will be accepted. Once the data
is accepted, PENABLE and PSEL are deasserted unless another transfer follows
3.2 Write strobes
• PSTRB enables sparse data transfer on the write data bus. Each PSTRB
corresponds to 1 byte of the write data bus.
• There is one write strobe for each 8 bits of the write data bus, so PSTRB[n]
corresponds to PWDATA[(8n + 7):(8n)].
• Figure 3-3 shows this relationship on a 32-bit data bus.

• For read transfers, the Requester must drive all bits of PSTRB
LOW.
3.2.1 PSTRB presence and compatibility
• PSTRB is an optional signal. An APB peripheral might support a limited set of access
types, which must be documented for the programmer. This means that all
combinations of PSTRB presence might be compatible, if this document states that
sparse writes are not supported.
• The compatibility of PSTRB when connecting Requesters and Completers is
described inTable 3-1.
 3.3 Read transfers

Two types of read transfer are described in this section:

• With no wait states
• With wait states
All signals shown in this section are sampled at the rising edge of
PCLK
3.3.1 With no wait states
Figure 3-4 shows a read transfer.
The timing of the address, PADDR, write, PWRITE, select, PSEL, and
enable, PENABLE, signals are the same as described in Write
transfers on page 3-20. The Completer must provide the data before
the end of the read transfer.
3.3.2 With wait states
• Figure 3-5 shows how the PREADY signal can extend the
transfer.
• If PREADY is driven low during the Access phase, the read transfer is extended.
Signals such as PADDR, PWRITE, PSEL, and PENABLE remain unchanged, and
the number of added cycles can vary.
• Figure 3-5 on page 3-23 shows that two cycles are added using PREADY.
However, any number of additional cycles can be added, from zero upwards.
3.4 Error response

• PSLVERR indicates an error condition during APB transfers, which can occur
during both reads and writes. PSLVERR is valid only during the final cycle when
PSEL, PENABLE, and PREADY are high. For write errors, the state of the peripheral
may or may not be updated. For read errors, data may be invalid but is not
required to be driven to zero. Completers may or may not support PSLVERR, and
if unsupported, the signal should be tied low.
3.4.1 Write transfer
Figure 3-6 shows an example of a failing write transfer that completes with an
error.
3.4.2 Read transfer
• A read transfer can also complete with an error response, indicating that there is no
valid read data available.
Figure 3-7 shows a read transfer completing with an error response.
3.4.3 Mapping of PSLVERR
• When bridging:
+ From AXI to APB An APB error on PSLVERR is mapped
back to RRESP for reads and BRESP for writes.
+ From AHB to APB An APB error on PSLVERR is mapped
back to HRESP for reads and writes.
 3.5 Protection unit
3.5 Protection unit support 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.
 3.6 Realm Management Extension, RME

The RME adds Root and Realm physical address spaces into the Arm architecture.
These can be used in permission checks of APB transactions.

PNSE signal description

 • PNSE and PPROT[1] with the resulting physical address space
The RME_Support property is used to indicate whether an APB interface supports RME.
3.7 Wake-up signaling

• The wake-up signal, PWAKEUP, is used to indicate any activity associated with
any APB interface. PWAKEUP provides a glitch-free signal that can be routed
to a clock controller, or similar component, to enable power and clocks to
connected components.
3.8 User signaling

• The users of APB protocols can encounter an application that requires the
addition of signaling that is not specified in the APB protocol. User signaling
defines a standard method of adding this signaling to a transaction, without
defining the signal usage.

• Generally, it is recommended that User signals are not used. The APB
protocol interface does not define the function of these signals, causing
interoperability problems if two components use the same User signals in
an incompatible way.

• User signaling can only be added to APB5 protocol interfaces.

 IV. Operating States
4. Operating states
Figure 4-1 shows the operating
states of the APB interface.
• The state machine operates through the following states:
• IDLE: This is the default state of the APB interface.
• SETUP: When a transfer is required, the interface moves into the
SETUP state, where the appropriate select signal, PSELx, is asserted.
The interface 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.
 • ACCESS: The enable signal, PENABLE, is asserted in the ACCESS state. The
following signals must not change in the transition between SETUP and ACCESS and
between cycles in the ACCESS state:
• PADDR
• PPROT
• PWRITE
• PWDATA, only for write transactions
• PSTRB
• PAUSER
• PWUSER
 1 Protection using parity

Configuration of interface
2
protection
V. Interface parity Parity check
3
protection
4 Error detection behavior

5 Parity check signals

5.1 Protection using parity

• For safety-critical applications, it is necessary to detect and correct transient and

functional errors on individual wires within an SoC.
• An error in a system component can propagate and cause numerous errors across
connected components. Error Detection and Correction (EDC) is required to operate
end-to-end, covering all logic and wires from source to destination.
• This section describes a parity scheme for detecting single-bit errors on the
interface between components. Multi-bit errors can be detected if they occur in
different parity signal groups.
• Figure 5-1 shows the locations where parity can be used.
5.2 Configuration of interface protection

• EDC Scheme: Defined by the Check_Type property.

+ False: No checking signals on the interface.
+ Odd_Parity_Byte_All: Odd parity checking is included for all signals.
Each parity signal covers up to 8 bits.
+ APB5 Interfaces: Check signaling can be added to these interfaces
only.
5.3 Parity check

• .Odd Parity Requirement: An odd number of bits must be asserted across the
interface signal and the check signal.
• 8-Bit Limit: Covers no more than 8 bits of payload, with each parity bit
assuming up to three logic levels.
• Critical Control Signals: A single parity bit is defined as the inversion of the
original signal.
• Cycle Accuracy: Must be correctly driven in every cycle when the Check
Enable term is True.
• Full Coverage: Parity signals must cover all associated data bits, even if not
in use
• Missing Signals: Missing signals are assumed to be LOW; if no signals are
present, the check signal is omitted.
 5.4 Error detection behavior

• This specification is not prescriptive regarding component or system behavior

when a parity error is detected.
• Possible Actions by the Completer:
+ Terminate or propagate the transfer.
+ Correct or propagate the error.
+ Update memory or leave it untouched.
+ Signal an error response through other means, such as an interrupt.
 5.5 Parity check signals

• Check signals are synchronous to PCLK and must be driven correctly every cycle
in which the Check Enable term is True.
THANKS
FOR
WATCHING