Simultaneous

Multi-Mastering with the

Avalon Bus
April 2002, ver. 1.1 Application Note 184

Introduction The Excalibur™ Development Kit, featuring the Nios® embedded

processor version 2.1 supports an enhanced bus architecture. The
architecture supports multiple bus masters that can execute transfers
between peripherals simultaneously within a single system. The SOPC
Builder automatically generates the interconnect logic to connect system
peripherals and generates arbitration logic to handle multiple bus
masters. The development kit also offers a direct memory access (DMA)
peripheral that takes advantage of the simultaneous multi-master bus
architecture. The DMA peripheral can be integrated with any slave
peripheral, allowing the slave to transfer data directly to and from
memory without interrupting a CPU. With these features, system
designers can optimize data flow by creating system bus architectures
custom-tailored to their application-specific bandwidth needs.

This document describes the simultaneous multi-master bus architecture

and the differences between it and traditional bus architectures. While this
document pertains to the Avalon™ bus specification used with the Nios
embedded processor, the simultaneous multi-master capabilities of the
SOPC Builder operate independently of the bus specification for a
particular system. Future enhancements to the SOPC Builder will include
support for other bus specifications in addition to the Avalon bus
specification.

1 Before you read this document, you should have a basic

understanding of the Nios processor, the SOPC Builder, and the
Avalon bus interface, described in the Avalon Bus Specification
Reference Manual.

Traditional Bus In traditional bus protocols, a single arbitrator controls communication

between one or more bus masters and bus slaves. Each bus master
Architectures requests control of the bus from the arbitrator. The arbitrator then grants
a single master access to the bus. If multiple masters attempt to access the
bus, the arbitrator allocates bus resources to a single master based on a
fixed set of arbitration rules. For example, the priority arbitration
scheme—in which the master with the highest priority receives control of
the bus first—is used in many existing bus architectures.

Once the master has control of the bus, the master sends information to
the appropriate slave. Figure 1 on page 2 illustrates the priority bus
architecture in a traditional processor system.

Altera Corporation 1

AN-184-1.1
AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Figure 1. Bus Architecture in a Traditional Microprocessor System

Master 1 Master 2
Masters DMA
System CPU
Controller

Arbitrator

Bottleneck

System Bus

UART PIO Program Data

Slaves
Memory Memory

This method of bus implementation works well for a traditional

microprocessor system because the masters and slaves are physically
separate devices located on a printed circuit board or across backplanes.
Designers must use a common set of bus lines because of limited board
resources and the number of available I/O pins.

Traditional systems have a bandwidth bottleneck because only one

master can access the system bus and system bus resources at a time.
When a master has control of the bus, all other masters must wait to
proceed with their bus transactions. The simultaneous multi-master bus
architecture increases system bandwidth by eliminating this bottleneck
because bus masters contend for individual slaves, not for the bus itself.

Simultaneous The simultaneous multi-mastering architecture offers increased

bandwidth between peripherals regardless of the bus standard that
Multi-Master connects them. This section focuses on how to use the simultaneous multi-
master architecture with the Avalon bus.
Avalon Bus
In Nios-based systems, the Avalon bus connects the Nios processor(s) and
other Avalon peripherals via active logic and interconnects inside an
Altera® programmable logic device. The system does not have shared bus
lines like traditional microprocessor-based systems. Instead, each master-
slave pair has a dedicated connection between them. When a peripheral
must accept data from multiple sources, such as a Nios processor that
receives data from multiple memory devices, multiplexers (not tri-states)
feed the appropriate signal into the peripheral. If a master never needs
access to a particular slave, a connection between the two is not generated,
saving hardware resources.

2 Altera Corporation
 AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Because master and slave peripherals are connected with dedicated paths,
multiple masters can be active at the same time and can simultaneously
transfer data to their slaves. This simultaneous multi-master architecture
offers great throughput performance advantages compared to a
traditional, shared bus architecture. Master peripherals do not have to
wait to access a target slave peripheral, as long as another master does not
access the same slave at the same time. Unlike a shared bus, a
simultaneous multi-master architecture with two masters offers up to
twice the throughput; with three masters, it offers up to three times the
throughput. The throughput improvement depends on how often all
three masters are active simultaneously.

A simultaneous multi-master system still requires arbitration, but only

when two masters contend for the same slave. This arbitration is called
slave-side arbitration, because it is implemented at the point where two
(or more) masters connect to a single slave. For Nios-based systems using
the Avalon bus, the SOPC Builder implements slave-side arbitration
entirely inside the Avalon bus module. Every slave peripheral that can be
accessed by multiple masters has an arbitrator. You can also set the
arbitration priorities in the SOPC Builder.

Simultaneous Multi-Master Avalon Bus Terminology

The bus architecture of a traditional processor system includes masters,
slaves, and a bus arbitrator. The simultaneous multi-master Avalon bus
module also contains these elements. Table 1 summarizes bus
terminology used in this document.

Table 1. Terminology (Part 1 of 2)

Term Definition
Avalon Bus Module The collection of Avalon bus interconnects, multiplexers, and arbitrator logic used to
implement a system using the simultaneous multi-master Avalon bus. The SOPC Builder
creates the Avalon bus module and its contents automatically based on the designer’s
system.
Master Peripheral Sometimes abbreviated as “master.” A master peripheral can initiate bus transfers on the
Avalon bus and must have at least one master port that connects to the Avalon bus module.
A master peripheral may also have a slave port. For example, the DMA peripheral has two
master ports to perform simultaneous reads and writes between peripherals and a slave
port. The slave port accepts commands from a Nios processor to set up the DMA transfer.
Slave Peripheral Sometimes abbreviated as “slave.” A slave peripheral only accepts bus transfers from the
Avalon bus and cannot initiate bus transfers. Slave peripherals usually have only one slave
port that connects to the Avalon bus module.

Altera Corporation 3
AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Table 1. Terminology (Part 2 of 2)

Term Definition
Master Port The collection of master peripheral signals used to initiate transfers on the Avalon bus.
Master ports present address and control signals to initiate read and write transfers from a
slave.
Slave Port The collection of peripheral signals used to accept Avalon bus transfers from another
peripheral’s master port. Slave ports accept the address and control signals presented by
a master port, allowing them to be read from or written to.
Master-Slave Pair The combination of a master port and a slave port that are connected via the Avalon bus.
Structurally, these master and slave ports connect to their respective ports on the Avalon
bus module. The master port’s control and data signals pass through the Avalon bus
module and interact with the slave port. You can specify connections between master and
slave ports (i.e., master-slave pairs) in the SOPC Builder.
Arbitrator A logic block inside the Avalon bus module that associates each slave port that is controlled
by multiple masters. When multiple masters request transfers to the same slave, the
arbitrator selects which master gains access to the slave. A single arbitrator controls access
to only one slave port. When several multi-master slaves exist, each slave has an
independent arbitrator.
Control Signals Signals that control the direction, sequence, and timing of a data transfer between a master
and slave port. These signals may vary depending on the implementation of the peripheral.
Control signals from a master port typically include read enable and write enable signals.
Control signals from a slave port typically include wait request and interrupt request (IRQ)
signals.

Simultaneous Multi-Master Avalon Bus Architecture

Figure 2 on page 5 shows conceptually illustrates how the Avalon bus
performs arbitration. In this example, the system CPU master port and the
DMA controller master port share the same slave peripheral (the data
memory block). Therefore, arbitration is performed on the data memory’s
slave port. The arbitrator dictates which master port gains access to the
slave port if both masters initiate a transfer with the slave at the same time.
The CPU uses the interconnect between the CPU and DMA controller to
set up DMA transfers.

4 Altera Corporation
 AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Figure 2. Simultaneous Multi-Master Avalon Bus Arbitration Note (1)

Master 1 Master 2
Masters DMA
System CPU
Controller

Arbitrator

UART PIO Program Data

Slaves
Memory Memory

Note:
(1) All arrows represent address, data, and control signals.

Figure 3 provides additional detail of the data, address, and control paths
of the system in Figure 2. From the master to the slave, the arbitrator logic
multiplexes all address, data, and control signals from a master port to a
shared slave port. From the slave to the master, the slave’s data and
control signals can be multiplexed into the master so that the master port
receives the target slave’s signals at the appropriate time.

Figure 3. Data & Control Paths

Multiplexer

M1 Address Arbitrator

Master 1 M1 Write Data Address

Data from System CPU Request Control
Write Data Data
Other Slaves
Control Memory
M2 Address
Address
M2 Write Data
Write Data
Control Request Control

Master 2
DMA
Controller
Slave Read Data

Altera Corporation 5
AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Slave Arbitrator
The Avalon bus module contains one slave arbitrator for each shared
slave port. You can parameterize each slave arbitrator individually in the
SOPC Builder. A slave arbitrator performs the following functions for its
associated slave port:

■ Defines control, address, and data paths from multiple master ports
to the slave port and specifies the arbitration mechanism to use when
multiple masters contend for the slave at the same time.

■ At any given time, selects which master port has access to the slave
port and forces all other contending masters (if any) to wait, based on
arbitration assignments.

■ Controls the slave port, based on the address, data, and control
signals presented by the currently selected master port.

Simultaneous multi-master arbitration has two elements, the request logic

and arbitrator logic. The request logic evaluates the address and control
signals presented by each master and generates a request signal that feeds
the arbitrator logic. This request signal also controls multiplexers that
connect slaves to the master initiating the transfer.

The slave arbitrator matches the appropriate data bus, address bus, and
control signals from a master to a slave. The arbitrator selects between
multiple master ports based on the arbitration assignments you make in
the SOPC Builder. The master request slave signal (MRS), presented by
the request logic, indicates a request for access to a slave. If multiple
masters generate requests for bus transactions to a slave, the winning
master accesses the slave and the slave arbitrator generates a wait signal
for the losing master(s). See “Bus Timing” on page 9 for an example multi-
master bus transfer.

Figure 4 on page 7 shows the request and arbitrator logic in an example

simultaneous multi-master system that permits bus transfers between two
masters and two slaves.

6 Altera Corporation
 AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Figure 4. Arbitrator Signals & Their Effect on Masters & Slaves

S1 Read Data & Control

MRS Request
Logic MSG Arbitrator
Logic

Master 1 M1 Address, Write

Data & Control Slave 1

Multiplexer
Multiplexer

MRS Request
Logic MSG Arbitrator
Logic

Master 2 M2 Address, Write

Data & Control Slave 2

Multiplexer
S2 Read Data & Control Multiplexer

The arbitrator and request blocks generate control signals that are fed to
multiplexers on the master and slave ports. See Table 2.

Table 2. Avalon Bus Control Signals

Signal Function
Master Request Slave Multiplexer control that connects the wait and data signals
(MRS) from multiple slave ports to a single master port.
Master Select Multiplexer control that connects the data and control
Granted (MSG) signals from multiple master ports to a single slave port.
Wait Input to each master port that indicates that the bus
transfer should be held when the desired slave port cannot
be accessed immediately.

Peripheral Design for the Simultaneous Multi-Master Bus

Many Avalon peripherals (e.g., memory, UART, timer, and PIO) only
have a single slave port. These peripherals can interrupt a master via
interrupt requests, but they cannot initiate a bus transfer. Figures 2
through 4 illustrate the simple case in which each peripheral has only a
single master or slave port.

Altera Corporation 7
AN 184: Simultaneous Multi-Mastering with the Avalon Bus

In more complex cases, Avalon peripherals can have more than one port
and may have both a master and slave port, e.g., the Nios processor or
DMA peripheral. The Nios processor has two master ports—separate
interfaces for instruction and data memory—and no slave ports. The
DMA peripheral has two master ports and a slave port. The slave port
accepts commands from a Nios processor to set up the DMA transfer and
the master ports initiate bus transfers with the source and destination
peripherals.

Because the Avalon bus module handles the arbitration details, special
considerations are not necessary when designing a peripheral to function
in a simultaneous multi-master Avalon bus system. However, the
peripheral master and slave ports must follow the rules of the Avalon bus
specification. For example, master peripherals must accept the
waitrequest signal because the arbitration logic may force the master
port to wait. A slave peripheral accepts bus transfers from the Avalon bus
module and is not aware of the multiple master ports that access it. The
slave only sees a sequence of bus transfers presented by the arbitration
logic.

Designers who want to build custom Nios peripherals can view the
system’s Peripheral Template File (.ptf) to see each peripheral’s master
and slave ports.

Arbitration Schemes
The Avalon arbitrator logic uses a fairness-based arbitration scheme,
sometimes referred to as a round-robin or weighted round-robin scheme.
For any given connection between a master and slave, you can select how
much access each master has to a given slave. You use the SOPC Builder
to make arbitration assignments to a specific master-slave pair.

In a fairness-based arbitration scheme, each master-slave pair has an

integer value of “shares” for bus transfers. If conflicting requests to access
a particular slave occur, the master that has the highest fairness setting is
granted access to the slave. After the master-slave pair exhausts its share
assignment, control of the slave is granted to the master-slave pairs with
lower share assignments.

For example, if master A, a DMA controller, has 1 share of access to a RAM

slave port and master B, the Nios processor, has 2 shares of access to the
same RAM slave port, the DMA controller can access the slave 33% of the
time (assuming both masters continually request transfers to the shared
slave). The arbitration settings do not have to be sequential values. For
example, an arbitration setting of 9 for one master, and 1 for another allots
90% and 10% access, respectively.

8 Altera Corporation
 AN 184: Simultaneous Multi-Mastering with the Avalon Bus

Bus Timing
Simultaneous multi-master transfer timing is the same as that of other
Avalon transfers. While the Avalon interface specification rules hold true
for individual bus transfers, you can observe the arbitration settings of
each master and the control signals each master transmits to understand
the workings of multiple transfers to a shared slave.

Figure 5 on page 9 shows the Avalon timing diagram of an example

system that has two master ports trying to access the same slave port. Both
masters issue a fundamental read transfer. This example uses fairness-
based arbitration and master 1 (M1) is allotted more shares than master 2
(M2). On the first bus cycle, both masters present address and readn for
access to slave 1 (S1). The arbitrator for S1 grants access to M1 because it
has a higher fairness setting. The Avalon bus module passes the address,
data, and control signals from M1 to S1 and asserts M2’s waitrequest
signal.

Just after the next rising edge of the clock, the transfer between M1 and S1
completes and the MRS signal from the M1 request logic to the S1
arbitrator is negated, as is the wait signal to M2. The next transfer, which
is between M2 and S1, can complete.

Figure 5. Successive Fundamental Read Transfers to a Common Slave

M1 Reads, M2 Waits M2 Reads from S1 Next Bus Transfer

clk

M1_address Valid Address for S1

M1_readn Read Request
M1_waitrequest
M1_readdata Read Data from S1

M2_address Valid Address for S1

M2_readn Read Request
M2_waitrequest Wait for M1
M2_data Read Data from S1

S1_address Address from M1 Address from M2

S1_readn
S1_chipselect
S1_readdata Read Data for M1 Read Data for M2

Altera Corporation 9
AN 184: Simultaneous Multi-Mastering with the Avalon Bus

You do not need to make special settings for these transfers to take place
correctly. All transfers, including those shown above and those that are
more complex, execute according to the Avalon bus specification.
Additionally, other transfers (such as between another master and slave)
execute transparently through separate control and data lines.

Conclusion As system throughput increases, designers need an easily customizable,

flexible bus architecture. The simultaneous multi-master Avalon bus
module lets system designers optimize the data flow between Nios
processors and peripherals. The designer can create system bus
architectures that are tailored to application-specific needs, maximizing
system performance.

More For more information, refer to the following documents:

Information ■ Nios Tutorial version 2.1

■ Avalon Bus Specification Reference Manual
■ SOPC Builder Data Sheet

Documentation Altera values your feedback. If you would like to provide feedback on this
document—e.g., clarification requests, inaccuracies, or inconsistencies—
Feedback send e-mail to nios_docs@altera.com.

Copyright  2002 Altera Corporation. Altera, The Programmable Solutions Company, the stylized Altera logo,
specific device designations, and all other words and logos that are identified as trademarks and/or service
101 Innovation Drive marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and
San Jose, CA 95134 other countries. All other product or service names are the property of their respective holders. Altera products
are protected under numerous U.S. and foreign patents and pending applications, mask work rights, and
(408) 544-7000 copyrights. Altera warrants performance of its semiconductor products to current
http://www.altera.com specifications in accordance with Altera’s standard warranty, but reserves the right to
Applications Hotline: make changes to any products and services at any time without notice. Altera assumes no
responsibility or liability arising out of the application or use of any information, product,
(800) 800-EPLD or service described herein except as expressly agreed to in writing by Altera Corporation.
Literature Services: Altera customers are advised to obtain the latest version of device specifications before
lit_req@altera.com relying on any published information and before placing orders for products or services.
All rights reserved.

10 Altera Corporation