Simultaneous Multi-Mastering with the Avalon Bus

Similar documents
Active Serial Memory Interface

Nios DMA. General Description. Functional Description

Estimating Nios Resource Usage & Performance

Legacy SDRAM Controller with Avalon Interface

Nios Soft Core Embedded Processor

Using MAX II & MAX 3000A Devices as a Microcontroller I/O Expander

2. System Interconnect Fabric for Memory-Mapped Interfaces

White Paper AHB to Avalon & Avalon to AHB Bridges

Practical Hardware Debugging: Quick Notes On How to Simulate Altera s Nios II Multiprocessor Systems Using Mentor Graphics ModelSim

Nios PIO. General Description. Functional Description

April 2002, Version 1.1. Component. PTF File. Component. Component GUI Wizards. Generation. System PTF file Files and Libraries.

Simple Excalibur System

Using MAX 3000A Devices as a Microcontroller I/O Expander

FPGAs Provide Reconfigurable DSP Solutions

AIRbus Interface. Features Fixed width (8-, 16-, or 32-bit) data transfers (dependent on the width. Functional Description. General Arrangement

Nios II Embedded Design Suite 6.1 Release Notes

Nios Timer. General Description. Functional Description

Simulating Nios II Embedded Processor Designs

Nios Embedded Processor UART Peripheral

DSP Development Kit, Stratix II Edition

POS-PHY Level 4 POS-PHY Level 3 Bridge Reference Design

December 2002, ver. 1.3 Application Note 191. Six individual interrupts Six-bit priority scheme Five-bit priority scheme plus one individual interrupt

PCI Express Multi-Channel DMA Interface

RapidIO Physical Layer MegaCore Function

Matrices in MAX II & MAX 3000A Devices

Implementing LED Drivers in MAX Devices

Excalibur Solutions Using the Expansion Bus Interface. Introduction. EBI Characteristics

Using the Nios Development Board Configuration Controller Reference Designs

Excalibur Solutions DPRAM Reference Design

POS-PHY Level 4 MegaCore Function

DDR and DDR2 SDRAM Controller Compiler User Guide

Introduction to the Altera SOPC Builder Using Verilog Design

Avalon Streaming Interface Specification

Avalon Interface Specifications

Benefits of Embedded RAM in FLEX 10K Devices

Cyclone II FPGA Family

RapidIO MegaCore Function

Nios II Embedded Design Suite 7.1 Release Notes

RapidIO MegaCore Function

Avalon Bus Specification

Video and Image Processing Suite

Toolflow for ARM-Based Embedded Processor PLDs

White Paper The Need for a High-Bandwidth Memory Architecture in Programmable Logic Devices

ZBT SRAM Controller Reference Design

Nios Soft Core. Nios Timer Peripheral. Altera Corporation 101 Innovation Drive San Jose, CA (408)

DDR & DDR2 SDRAM Controller Compiler

Introduction to the Altera SOPC Builder Using Verilog Designs. 1 Introduction

DDR & DDR2 SDRAM Controller

White Paper Configuring the MicroBlaster Passive Serial Software Driver

Introduction. Design Hierarchy. FPGA Compiler II BLIS & the Quartus II LogicLock Design Flow

DSP Builder. DSP Builder v6.1 Issues. Error When Directory Pathname is a Network UNC Path

Design Verification Using the SignalTap II Embedded

FFT/IFFT Block Floating Point Scaling

DDR & DDR2 SDRAM Controller

Supporting Custom Boards with DSP Builder

Simulating the PCI MegaCore Function Behavioral Models

Disassemble the machine code present in any memory region. Single step through each assembly language instruction in the Nios II application.

Generic Serial Flash Interface Intel FPGA IP Core User Guide

Using Flexible-LVDS I/O Pins in

ByteBlaster II Parallel Port Download Cable

FPGA Design Security Solution Using MAX II Devices

On-Chip Memory Implementations

Enhanced Configuration Devices

Debugging Nios II Systems with the SignalTap II Logic Analyzer

UTOPIA Level 2 Slave MegaCore Function

E3 Mapper MegaCore Function (E3MAP)

Avalon Interface Specifications

Using the Serial FlashLoader With the Quartus II Software

Using Flexible-LVDS Circuitry in Mercury Devices

Simulating the Reed-Solomon Model

RLDRAM II Controller MegaCore Function

Applying the Benefits of Network on a Chip Architecture to FPGA System Design

DSP Builder Release Notes

Table 1 shows the issues that affect the FIR Compiler v7.1.

White Paper Using the MAX II altufm Megafunction I 2 C Interface

Arria II GX FPGA Development Board

Introduction. Synchronous vs. Asynchronous Memory. Converting Memory from Asynchronous to Synchronous for Stratix & Stratix GX Designs

Implementing LED Drivers in MAX and MAX II Devices. Introduction. Commercial LED Driver Chips

9. PIO Core. Core Overview. Functional Description

Simulating the PCI MegaCore Function Behavioral Models

Altera ASMI Parallel II IP Core User Guide

T3 Framer MegaCore Function (T3FRM)

Using MicroC/OS-II RTOS with the Nios II Processor Tutorial Preliminary Information

SONET/SDH Compiler. Introduction. SONET/SDH Compiler v2.3.0 Issues

Nios II Performance Benchmarks

Stratix FPGA Family. Table 1 shows these issues and which Stratix devices each issue affects. Table 1. Stratix Family Issues (Part 1 of 2)

DDR & DDR2 SDRAM Controller Compiler

AN 549: Managing Designs with Multiple FPGAs

Making Qsys Components. 1 Introduction. For Quartus II 13.0

Table 1 shows the issues that affect the FIR Compiler, v6.1. Table 1. FIR Compiler, v6.1 Issues.

Logic Optimization Techniques for Multiplexers

4K Format Conversion Reference Design

Avalon Interface Specifications

Implementing Double Data Rate I/O Signaling in Stratix & Stratix GX Devices. Introduction. DDR I/O Elements. Input Configuration

Design of Embedded Hardware and Firmware

Remote Drive. Quick Start Guide. System Level Solutions, Inc. (USA) Murphy Avenue San Martin, CA (408) Version : 0.1.

Converting.srec Files to.flash Files for Nios Embedded Processor Applications

Figure 1. Device Package Ordering Information for Stratix, Stratix GX, Cyclone, APEX 20KC, APEX II, Mercury & Excalibur Devices EP1S 25 F 780 C 5 N

AN 547: Putting the MAX II CPLD in Hibernation Mode to Achieve Zero Standby Current

SONET/SDH STS-12c/STM-4 Framer MegaCore Function (STS12CFRM)

Transcription:

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-184-1.1

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

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

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

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

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

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

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

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

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