Simultaneous Multi-Mastering with the Avalon Bus

Transcription

1 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 Architectures 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 1 AN

2 Figure 1. Bus Architecture in a Traditional Microprocessor System Masters Master 1 System CPU Master 2 DMA Controller 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

3 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

4 Table 1. Terminology (Part 2 of 2) Term Master Port Slave Port Master-Slave Pair Control Signals Definition 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. 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. 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. 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. 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

5 Figure 2. Simultaneous Multi-Master Avalon Bus Arbitration Note (1) Masters Master 1 System CPU Master 2 DMA Controller 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 Address Write Data Control Master 1 System CPU M1 Address M1 Write Data Request Control M2 Address M2 Write Data Request Control Address Write Data Control Data Memory Master 2 DMA Controller Slave Read Data Altera Corporation 5

6 Slave 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

7 Figure 4. Signals & Their Effect on Masters & Slaves S1 Read Data & Control MRS Request Logic MSG Logic Master 1 M1 Address, Write Data & Control Slave 1 Multiplexer Multiplexer MRS Request Logic MSG 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 Master Request Slave (MRS) Master Select Granted (MSG) Wait Function Multiplexer control that connects the wait and data signals from multiple slave ports to a single master port. Multiplexer control that connects the data and control signals from multiple master ports to a single slave port. 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

8 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

9 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 clk M1 Reads, M2 Waits M2 Reads from S1 Next Bus Transfer M1_address M1_readn M1_waitrequest M1_readdata Valid Address for S1 Read Request Read Data from S1 M2_address M2_readn M2_waitrequest M2_data Valid Address for S1 Read Request Wait for M1 Read Data from S1 S1_address S1_readn S1_chipselect S1_readdata Address from M1 Read Data for M1 Address from M2 Read Data for M2 Altera Corporation 9

10 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 More Information Documentation Feedback 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. For more information, refer to the following documents: Nios Tutorial version 2.1 Avalon Bus Specification Reference Manual SOPC Builder Data Sheet Altera values your feedback. If you would like to provide feedback on this document e.g., clarification requests, inaccuracies, or inconsistencies send to 101 Innovation Drive San Jose, CA (408) Applications Hotline: (800) 800-EPLD Literature Services: 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. 10 Altera Corporation