Simultaneous
Multi-Mastering with the
Avalon Bus
April 2002, ver. 1.1
Introduction
Application Note 184
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
Traditional Bus
Architectures
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.
In traditional bus protocols, a single arbitrator controls communication
between one or more bus masters and bus slaves. Each bus master
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
AN-184-1.1
1
AN 184: Simultaneous Multi-Mastering with the Avalon Bus
Figure 1. Bus Architecture in a Traditional Microprocessor System
Masters
Master 2
DMA
Controller
Master 1
System CPU
Arbitrator
Bottleneck
System Bus
Slaves
UART
PIO
Program
Memory
Data
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
Multi-Master
Avalon Bus
The simultaneous multi-mastering architecture offers increased
bandwidth between peripherals regardless of the bus standard that
connects them. This section focuses on how to use the simultaneous multimaster architecture with the 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 masterslave 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
Masters
Note (1)
Master 2
DMA
Controller
Master 1
System CPU
Arbitrator
Slaves
UART
PIO
Program
Memory
Data
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
Data from
Other Slaves
Master 1
System CPU
M1 Address
M1 Write Data
Request Control
M2 Address
M2 Write Data
Request Control
Address
Write Data
Control
Arbitrator
Address
Write Data
Control
Data
Memory
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 multimaster 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
Granted (MSG)
Multiplexer control that connects the data and control
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 fairnessbased 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
S1_address
Read Data from S1
Address from M1
Address from M2
Read Data for M1
Read Data for M2
S1_readn
S1_chipselect
S1_readdata
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
Information
For more information, refer to the following documents:
Documentation
Feedback
Altera values your feedback. If you would like to provide feedback on this
document—e.g., clarification requests, inaccuracies, or inconsistencies—
send e-mail to nios_docs@altera.com.
101 Innovation Drive
San Jose, CA 95134
(408) 544-7000
http://www.altera.com
Applications Hotline:
(800) 800-EPLD
Literature Services:
lit_req@altera.com
10
■
■
■
Nios Tutorial version 2.1
Avalon Bus Specification Reference Manual
SOPC Builder Data Sheet
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
marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and
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
copyrights. Altera warrants performance of its semiconductor products to current
specifications in accordance with Altera’s standard warranty, but reserves the right to
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,
or service described herein except as expressly agreed to in writing by Altera Corporation.
Altera customers are advised to obtain the latest version of device specifications before
relying on any published information and before placing orders for products or services.
All rights reserved.
Altera Corporation