Ug Embedded Ip
Ug Embedded Ip
Contents
Altera Corporation
TOC-3
UART Core...........................................................................................................7-1
Core Overview..............................................................................................................................................7-1
Supported Devices........................................................................................................................... 7-1
Altera Corporation
TOC-4
Functional Description................................................................................................................................7-2
Avalon-MM Slave Interface and Registers....................................................................................7-2
RS-232 Interface............................................................................................................................... 7-2
Transmitter Logic............................................................................................................................. 7-3
Receiver Logic...................................................................................................................................7-3
Baud Rate Generation..................................................................................................................... 7-3
Instantiating the Core..................................................................................................................................7-3
Configuration Settings.....................................................................................................................7-3
Simulation Settings.......................................................................................................................... 7-6
Simulation Considerations......................................................................................................................... 7-7
Software Programming Model................................................................................................................... 7-7
HAL System Library Support......................................................................................................... 7-7
Software Files.................................................................................................................................. 7-10
Register Map................................................................................................................................... 7-10
Interrupt Behavior......................................................................................................................... 7-14
Document Revision History.....................................................................................................................7-15
Altera Corporation
TOC-5
scr..................................................................................................................................................... 8-40
afr..................................................................................................................................................... 8-41
tx_low.............................................................................................................................................. 8-42
Document Revision History.....................................................................................................................8-42
Altera Corporation
TOC-6
Altera Corporation
TOC-7
Altera Corporation
TOC-8
Altera Corporation
TOC-9
Altera Corporation
TOC-10
alt_avalon_sgdma_stop()............................................................................................................24-25
alt_avalon_sgdma_open().......................................................................................................... 24-25
Document Revision History...................................................................................................................24-26
Altera Corporation
TOC-11
alt_msgdma_irq........................................................................................................................... 25-51
Document Revision History...................................................................................................................25-52
Altera Corporation
TOC-12
Mutex Core.........................................................................................................29-1
Core Overview............................................................................................................................................29-1
Supported Devices......................................................................................................................... 29-1
Functional Description..............................................................................................................................29-1
Configuration............................................................................................................................................. 29-2
Software Programming Model................................................................................................................. 29-2
Software Files.................................................................................................................................. 29-2
Hardware Access Routines............................................................................................................29-2
Mutex API................................................................................................................................................... 29-3
altera_avalon_mutex_is_mine().................................................................................................. 29-3
altera_avalon_mutex_first_lock()................................................................................................29-4
altera_avalon_mutex_lock()......................................................................................................... 29-4
altera_avalon_mutex_open()........................................................................................................29-4
altera_avalon_mutex_trylock()....................................................................................................29-5
altera_avalon_mutex_unlock().................................................................................................... 29-5
Document Revision History.....................................................................................................................29-6
Altera Corporation
TOC-13
Altera Corporation
TOC-14
Core Overview............................................................................................................................................33-1
Supported Devices......................................................................................................................... 33-1
Resource Utilization and Performance................................................................................................... 33-1
Test Pattern Generator.............................................................................................................................. 33-2
Functional Description..................................................................................................................33-2
Configuration................................................................................................................................. 33-3
Test Pattern Checker..................................................................................................................................33-4
Functional Description..................................................................................................................33-4
Configuration................................................................................................................................. 33-5
Hardware Simulation Considerations.....................................................................................................33-6
Software Programming Model................................................................................................................. 33-6
HAL System Library Support....................................................................................................... 33-6
Software Files.................................................................................................................................. 33-6
Register Maps................................................................................................................................. 33-6
Test Pattern Generator API.................................................................................................................... 33-10
data_source_reset()..................................................................................................................... 33-10
data_source_init()........................................................................................................................33-11
data_source_get_id()...................................................................................................................33-11
data_source_get_supports_packets()........................................................................................33-11
data_source_get_num_channels().............................................................................................33-12
data_source_get_symbols_per_cycle()..................................................................................... 33-12
data_source_set_enable()........................................................................................................... 33-12
data_source_get_enable()........................................................................................................... 33-12
data_source_set_throttle()..........................................................................................................33-13
data_source_get_throttle()......................................................................................................... 33-13
data_source_is_busy().................................................................................................................33-13
data_source_fill_level()............................................................................................................... 33-14
data_source_send_data()............................................................................................................33-14
Test Pattern Checker API........................................................................................................................33-15
data_sink_reset()..........................................................................................................................33-15
data_sink_init()............................................................................................................................33-15
data_sink_get_id()....................................................................................................................... 33-16
data_sink_get_supports_packets()............................................................................................ 33-16
data_sink_get_num_channels().................................................................................................33-16
data_sink_get_symbols_per_cycle()......................................................................................... 33-17
data_sink_set enable().................................................................................................................33-17
data_sink_get_enable()............................................................................................................... 33-17
data_sink_set_throttle()..............................................................................................................33-17
data_sink_get_throttle()............................................................................................................. 33-18
data_sink_get_packet_count()...................................................................................................33-18
data_sink_get_symbol_count()................................................................................................. 33-18
data_sink_get_error_count()..................................................................................................... 33-19
data_sink_get_exception()......................................................................................................... 33-19
data_sink_exception_is_exception().........................................................................................33-19
data_sink_exception_has_data_error().................................................................................... 33-20
data_sink_exception_has_missing_sop().................................................................................33-20
data_sink_exception_has_missing_eop().................................................................................33-20
data_sink_exception_signalled_error().................................................................................... 33-20
data_sink_exception_channel().................................................................................................33-21
Altera Corporation
TOC-15
PLL Cores...........................................................................................................35-1
Core Overview............................................................................................................................................35-1
Functional Description..............................................................................................................................35-2
ALTPLL Megafunction..................................................................................................................35-2
Clock Outputs.................................................................................................................................35-2
PLL Status and Control Signals.................................................................................................... 35-2
System Reset Considerations........................................................................................................35-3
Instantiating the Avalon ALTPLL Core.................................................................................................. 35-3
Instantiating the PLL Core........................................................................................................................35-3
Hardware Simulation Considerations.....................................................................................................35-5
Register Definitions and Bit List.............................................................................................................. 35-5
Status Register.................................................................................................................................35-5
Control Register............................................................................................................................. 35-6
Phase Reconfig Control Register..................................................................................................35-6
Document Revision History.....................................................................................................................35-7
Altera Corporation
TOC-16
Altera Corporation
TOC-17
Altera Corporation
TOC-18
Signals.......................................................................................................................................................... 42-9
How to Translate the Bridge's I2C Data and I2C I/O Ports to an I2C Interface...............................42-10
Document Revision History...................................................................................................................42-11
Altera Corporation
TOC-19
Registers...................................................................................................................................................... 45-8
Register Memory Map...................................................................................................................45-8
Register Description...................................................................................................................... 45-9
Document Revision History.....................................................................................................................45-9
Altera Corporation
2017.05.08
Embedded Peripherals IP User Guide
Introduction 1
UG-01085 Subscribe Send Feedback
This user guide describes the IP cores provided by Altera that are included in the Quartus Prime design
software.
The IP cores are optimized for Altera devices and can be easily implemented to reduce design and test
time. You can use the IP parameter editor from Qsys to add the IP cores to your system, configure the
cores, and specify their connectivity.
Altera's Qsys system integration tool is available in the Quartus Prime software subcription edition version
15.0.
Before using Qsys, review the (Quartus Prime software Release Notes) for known issues and limitations.
To submit general feedback or technical support, click Feedback on the Quartus Prime software Help
menu and also on all Altera technical documentation.
Related Information
Quartus Prime Handbook Volume 1: Design and Synthesis
Quartus Prime Handbook Volume 2: Design Implementation and Optimization
Quartus Prime Handbook Volume 3: Verification
Quartus Prime Software and Device Support Release Notes
Tool Support
Qsys is a system-level integration tool which is included as part of the Quartus Prime software. Qsys saves
significant time and effort in the FPGA design process by automatically generating interconnect logic to
connect intellectual property (IP) functions and subsystems.You can implement a design using the IP
cores from the Qsys component library.
All the IP cores described in this user guide are supported by Qsys except for the following cores which are
only supported by SOPC Builder.
Common Flash Interface Controller Core
SDRAM Controller Core (pin-sharing mode)
System ID Core
For more information on Qsys or SOPC Builder, refer to Volume 1: Design and Synthesis of the
Quartus Prime Handbook or SOPC Builder User Guide.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
1-2 Obsolescence 2017.05.08
Obsolescence
The following IP cores are scheduled for product obsolescence and discontinued support:
PCI Lite Core
Mailbox Core
Altera recommends that you do not use these cores in new designs.
For more information about Alteras current IP offering, refer to Alteras Intellectual Property website.
Related Information
Altera's Intellectual Property
Device Support
The IP cores described in this user guide support all Altera device families except the cores listed in the
table below.
Different device families support different I/O standards, which may affect the ability of the core to
interface to certain components. For details about supported I/O types, refer to the device handbook for
the target device family.
Send Feedback
UG-01085
2017.05.08 Document Revision History 1-3
December 2013 v13.1.0 Removed listing of the DMA Controller core in the Qsys unsupported
list. The DMA controller core is now supported in Qsys.
Removed listing of the MDIO core in Device Support Table. The
MDIO core support all device families that the 10-Gbps Ethernet MAC
MegaCore Function supports.
Send Feedback
2017.05.08
SDRAM Controller Core
2
UG-01085 Subscribe Send Feedback
Core Overview
The SDRAM controller core with Avalon interface provides an Avalon Memory-Mapped (Avalon-MM)
interface to off-chip SDRAM. The SDRAM controller allows designers to create custom systems in an
Altera device that connect easily to SDRAM chips. The SDRAM controller supports standard SDRAM as
described in the PC100 specification.
SDRAM is commonly used in cost-sensitive applications requiring large amounts of volatile memory.
While SDRAM is relatively inexpensive, control logic is required to perform refresh operations, open-row
management, and other delays and command sequences. The SDRAM controller connects to one or more
SDRAM chips, and handles all SDRAM protocol requirements. Internal to the device, the core presents an
Avalon-MM slave port that appears as linear memory (flat address space) to Avalon-MM master
peripherals.
The core can access SDRAM subsystems with various data widths (8, 16, 32, or 64 bits), various memory
sizes, and multiple chip selects. The Avalon-MM interface is latency-aware, allowing read transfers to be
pipelined. The core can optionally share its address and data buses with other off-chip Avalon-MM tri-
state devices. This feature is valuable in systems that have limited I/O pins, yet must connect to multiple
memory chips in addition to SDRAM.
Functional Description
The diagram below shows a block diagram of the SDRAM controller core connected to an external
SDRAM chip.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
2-2 Avalon-MM Interface 2017.05.08
Altera FPGA
The following sections describe the components of the SDRAM controller core in detail. All options are
specified at system generation time, and cannot be changed at runtime.
Related Information
SDRAM Controller Core on page 2-1
Avalon-MM Interface
The Avalon-MM slave port is the user-visible part of the SDRAM controller core. The slave port presents a
flat, contiguous memory space as large as the SDRAM chip(s). When accessing the slave port, the details
of the PC100 SDRAM protocol are entirely transparent. The Avalon-MM interface behaves as a simple
memory interface. There are no memory-mapped configuration registers.
The Avalon-MM slave port supports peripheral-controlled wait states for read and write transfers. The
slave port stalls the transfer until it can present valid data. The slave port also supports read transfers with
variable latency, enabling high-bandwidth, pipelined read transfers. When a master peripheral reads
sequential addresses from the slave port, the first data returns after an initial period of latency. Subsequent
reads can produce new data every clock cycle. However, data is not guaranteed to return every clock cycle,
because the SDRAM controller must pause periodically to refresh the SDRAM.
For details about Avalon-MM transfer types, refer to the Avalon Interface Specifications.
Send Feedback
UG-01085
2017.05.08 Synchronizing Clock and Data Signals 2-3
standards, and therefore are capable of interfacing with a greater variety of SDRAM chips. For details,
refer to the device handbook for the target device family.
tools provide example hardware designs that use the SDRAM controller core in conjunction with a PLL,
which you can use as a reference for your custom designs.
The Nios II development tools are available free for download from www.Altera.com.
Send Feedback
UG-01085
2-4 Performance Considerations 2017.05.08
Performance Considerations
Under optimal conditions, the SDRAM controller cores bandwidth approaches one word per clock cycle.
However, because of the overhead associated with refreshing the SDRAM, it is impossible to reach one
word per clock cycle. Other factors affect the cores performance, as described in the following sections.
Configuration
The SDRAM controller MegaWizard has two pages: Memory Profile and Timing. This section describes
the options available on each page.
The Presets list offers several pre-defined SDRAM configurations as a convenience. If the SDRAM
subsystem on the target board matches one of the preset configurations, you can configure the SDRAM
Send Feedback
UG-01085
2017.05.08 Memory Profile Page 2-5
controller core easily by selecting the appropriate preset value. The following preset configurations are
defined:
Micron MT8LSDT1664HG module
Four SDR100 8 MByte 16 chips
Single Micron MT48LC2M32B2-7 chip
Single Micron MT48LC4M32B2-7 chip
Single NEC D4564163-A80 chip (64 MByte 16)
Single Alliance AS4LC1M16S1-10 chip
Single Alliance AS4LC2M8S0-10 chip
Selecting a preset configuration automatically changes values on the Memory Profile and Timing tabs
to match the specific configuration. Altering a configuration setting on any page changes the Preset
value to custom.
Send Feedback
UG-01085
2-6 Timing Page 2017.05.08
Based on the settings entered on the Memory Profile page, the wizard displays the expected memory
capacity of the SDRAM subsystem in units of megabytes, megabits, and number of addressable words.
Compare these expected values to the actual size of the chosen SDRAM to verify that the settings are
correct.
Timing Page
The Timing page allows designers to enter the timing specifications of the SDRAM chip(s) used. The
correct values are available in the manufacturers data sheet for the target SDRAM.
Send Feedback
UG-01085
2017.05.08 Hardware Simulation Considerations 2-7
Regardless of the exact timing values you specify, the actual timing achieved for each parameter is an
integer multiple of the Avalon clock period. For the Issue one refresh command every parameter, the
actual timing is the greatest number of clock cycles that does not exceed the target value. For all other
parameters, the actual timing is the smallest number of clock ticks that provides a value greater than or
equal to the target value.
Send Feedback
UG-01085
2-8 Using the Generic Memory Model 2017.05.08
Example Configurations
The following examples show how to connect the SDRAM controller outputs to an SDRAM chip or chips.
The bus labeled ctl is an aggregate of the remaining signals, such as cas_n, ras_n, cke and we_n.
The address, data, and control signals are wired directly from the controller to the chip. The result is a 128-
Mbit (16-Mbyte) memory space.
Figure 2-2: Single 128-Mbit SDRAM Chip with 32-Bit Data
Altera FPGA
SDRAM
addr
Controller
ctl
cs_n
Avalon-MM
interface
to
on-chip
data 32 128 Mbits
logic
16 Mbytes
32 data width device
The address and control signals connect in parallel to both chips. The chips share the chipselect (cs_n)
signal. Each chip provides half of the 32-bit data bus. The result is a logical 128-Mbit (16-Mbyte) 32-bit
data memory.
Send Feedback
UG-01085
2017.05.08 Software Programming Model 2-9
Figure 2-3: Two 64-MBit SDRAM Chips Each with 16-Bit Data
Altera FPGA
addr
SDRAM
Controller ctl 64 Mbits 16
8 Mbytes
cs_n 16 data width device
Avalon-MM
interface
to
on-chip
logic
64 Mbits 16
8 Mbytes
16 data width device
data 32
The address, data, and control signals connect in parallel to the two chips. The chipselect bus (cs_n[1:0])
determines which chip is selected. The result is a logical 256-Mbit 32-bit wide memory.
Figure 2-4: Two 128-Mbit SDRAM Chips Each with 32-Bit Data
Altera FPGA
SDRAM addr
Controller
ctl 128 Mbits
32
16 Mbytes
cs_n [0] 32 data width device
Avalon-MM
interface
to
on-chip
logic
128 Mbits 32
16 Mbytes
32 data width device
cs_n [1]
data 32
Send Feedback
UG-01085
2-10 Factors Affecting SDRAM Timing 2017.05.08
correct values. At slower clock frequencies, the clock naturally falls within the valid window. At higher
frequencies, you must compensate the SDRAM clock to align with the valid window.
Determine when the valid window occurs either by calculation or by analyzing the SDRAM pins with an
oscilloscope. Then use a PLL to adjust the phase of the SDRAM clock so that edges occur in the middle of
the valid window. Tuning the PLL might require trial-and-error effort to align the phase shift to the
properties of your target board.
For details about the PLL circuitry in your target device, refer to the appropriate device family handbook.
For details about configuring the PLLs in Altera devices, refer to the ALTPLL Megafunction User Guide.
Send Feedback
UG-01085
2017.05.08 Estimating the Valid Signal Window 2-11
Signal skew due to delays on the printed circuit board These calculations assume zero skew.
Delay from the PLL clock output nodes to destinations These calculations assume that the delay
from the PLL SDRAM-clock output-node to the pin is the same as the delay from the PLL controller-
clock output-node to the clock inputs in the SDRAM controller. If these clock delays are significantly
different, you must account for this phase shift in your window calculations.
Lag is a negative time shift, relative to the controller clock, and lead is a positive time shift. The SDRAM
clock can lag the controller clock by the lesser of the maximum lag for a read cycle or that for a write
cycle. In other words, Maximum Lag = minimum(Read Lag, Write Lag). Similarly, the SDRAM clock
can lead by the lesser of the maximum lead for a read cycle or for a write cycle. In other words,
Maximum Lead = minimum(Read Lead, Write Lead).
Figure 2-5: Calculating the Maximum SDRAM Clock Lag
Send Feedback
UG-01085
2-12 Example Calculation 2017.05.08
Example Calculation
This section demonstrates a calculation of the signal window for a Micron MT48LC4M32B2-7 SDRAM
chip and design targeting the Stratix II EP2S60F672C5 device. This example uses a CAS latency (CL) of 3
cycles, and a clock frequency of 50 MHz. All SDRAM signals on the device are registered in I/O cells,
enabled with the Fast Input Register and Fast Output Register logic options in the Quartus Prime
software.
Send Feedback
UG-01085
2017.05.08 Example Calculation 2-13
The FPGA I/O Timing Parameters table below shows the relevant timing information, obtained from the
Timing Analyzer section of the Quartus Prime Compilation Report. The values in the table are the
maximum or minimum values among all device pins related to the SDRAM. The variance in timing
between the SDRAM pins on the device is small (less than 100 ps) because the registers for these signals
are placed in the I/O cell.
You must compile the design in the Quartus Prime software to obtain the I/O timing information for the
design. Although Altera device family datasheets contain generic I/O timing information for each device,
the Quartus Prime Compilation Report provides the most precise timing information for your specific
design.
The timing values found in the compilation report can change, depending on fitting, pin location, and
other Quartus Prime logic settings. When you recompile the design in the Quartus Prime software, verify
that the I/O timing has not changed significantly.
The following examples illustrate the calculations from figures Maximum SDRAM Clock Lag and
Maximum Lead also using the values from the Timing Parameters and FPGA I/O Timing Parameters
table.
Send Feedback
UG-01085
2-14 Document Revision History 2017.05.08
The SDRAM clock can lag the controller clock by the lesser of Read Lag or Write Lag:
Read Lag = tOH(SDRAM) tH_MAX(FPGA)
= 2.5 ns (5.607 ns) = 8.107 ns
or
Write Lag = tCLK tCO_MAX(FPGA) tDS(SDRAM)
= 20 ns 2.477 ns 2 ns = 15.523 ns
The SDRAM clock can lead the controller clock by the lesser of Read Lead or Write Lead:
Read Lead = tCO_MIN(FPGA) tDH(SDRAM)
= 2.399 ns 1.0 ns = 1.399 ns
or
Write Lead = tCLK tHZ(3)(SDRAM) tSU_MAX(FPGA)
= 20 ns 5.5 ns 5.936 ns = 8.564 ns
Therefore, for this example you can shift the phase of the SDRAM clock from 8.107 ns to 1.399 ns relative
to the controller clock. Choosing a phase shift in the middle of this window results in the value (8.107
+ 1.399)/2 = 3.35 ns.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
Send Feedback
2017.05.08
Tri-State SDRAM Core
3
UG-01085 Subscribe Send Feedback
Core Overview
The Altera SDRAM Tri-State Controller core with Avalon interface provides an Avalon Memory-Mapped
(Avalon-MM) interface to off-chip SDRAM. The SDRAM controller allows designers to create custom
systems in an Altera device that connect easily to SDRAM chips. The SDRAM controller supports
standard SDRAM defined by the PC100 specification.
SDRAM is commonly used in cost-sensitive applications requiring large amounts of volatile memory.
While SDRAM is relatively inexpensive, control logic is required to perform refresh operations, open-row
management, and other delays and command sequences. The SDRAM controller connects to one or more
SDRAM chips, and handles all SDRAM protocol requirements. The SDRAM controller core presents an
Avalon-MM slave port that appears as linear memory (flat address space) to Avalon-MM master
peripherals.
The Avalon-MM interface is latency-aware, allowing read transfers to be pipelined. The core can optionally
share its address and data buses with other off-chip Avalon-MM tri-state devices. This feature is valuable
in systems that have limited I/O pins, yet must connect to multiple memory chips in addition to SDRAM.
The Altera SDRAM Tri-State Controller has the same functionality as the SDRAM Controller Core with
the addition of the Tri-State feature.
Related Information
Avalon Interface Specifications
Feature Description
The Altera SDRAM Tri-State controller core has the following features:
Maximum frequency of 100-MHz
Single clock domain design
Sharing of dq/dqm/addr I/
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
3-2 Block Diagram 2017.05.08
Block Diagram
Figure 3-1: Tri-State SDRAM Block Diagram
altera_sdram_controller
Request
Buffer
Avalon-MM
Signal Generation
SDRAM
Interface Main Interface
FSM
Tri-state
Conduit
Master Signals
Init FSM
Clock Reset
Configuration Parameter
The following table shows the configuration parameters available for user to program during generation
time of the IP core.
Timing Page
The Timing page allows designers to enter the timing specifications of the Tri-State SDRAM chip(s) used.
The correct values are available in the manufacturers data sheet for the target SDRAM.
Send Feedback
UG-01085
2017.05.08 Interface 3-3
Interface
The following are top level signals from core
Send Feedback
UG-01085
3-4 Interface 2017.05.08
Send Feedback
UG-01085
2017.05.08 Interface 3-5
Send Feedback
UG-01085
3-6 Interface 2017.05.08
Send Feedback
UG-01085
2017.05.08 Reset and Clock Requirements 3-7
Note: The SDRAM controller does not have any configurable control status registers (CSR).
Architecture
The SDRAM Controller connects to one or more SDRAM chips, and handles all SDRAM protocol require
ments. Internal to the device, the core presents an Avalon-MM slave ports that appears as a linear memory
(flat address space) to Avalon-MM master device.
The core can access SDRAM subsystems with:
Various data widths (8-, 16-, 32- or 64-bits)
Various memory sizes
Multiple chip selects
The Avalon-MM interface is latency-aware, allowing read transfers to be pipelined. The core can optionally
share its address and data buses with other off-chip Avalon-MM tri-state devices.
Note: Limitations: for now the arbitration control of this mode should be handled by the host/master in
the system to avoid a device monopolizing the shared buses.
Control logic within the SDRAM core responsible for the main functionality listed below, among others:
Refresh operation
Open_row management
Delay and command management
Use of the data bus is intricate and thus requires a complex DRAM controller circuit. This is because data
written to the DRAM must be presented in the same cycle as the write command, but reads produce
output 2 or 3 cycles after the read command. The SDRAM controller must ensure that the data bus is
never required for a read and a write at the same time.
Send Feedback
UG-01085
3-8 Avalon-MM Slave Interface and CSR 2017.05.08
Send Feedback
UG-01085
2017.05.08 Block Level Usage Model 3-9
Send Feedback
UG-01085
3-10 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Compact Flash Core
4
UG-01085 Subscribe Send Feedback
Core Overview
The CompactFlash core allows you to connect systems built on Osys to CompactFlash storage cards in
true IDE mode by providing an Avalon Memory-Mapped (Avalon-MM) interface to the registers on the
storage cards. The core supports PIO mode 0.
The CompactFlash core also provides an Avalon-MM slave interface which can be used by Avalon-MM
master peripherals such as a Nios II processor to communicate with the CompactFlash core and manage
its operations.
Supported Devices
The Compact Flash core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
4-2 Functional Description 2017.05.08
Functional Description
Figure 4-1: System With a CompactFlash Core
Altera FPGA
id e
System Interconnect Fabric IRQ
Avalon-MM
Master
(e.g. CPU)
IRQ
idectl
As shown in the block diagram, the CompactFlash core provides two Avalon-MM slave interfaces: the ide
slave port for accessing the registers on the CompactFlash device and the ctl slave port for accessing the
core's internal registers. These registers can be used by Avalon-MM master peripherals such as a Nios II
processor to control the operations of the CompactFlash core and to transfer data to and from the
CompactFlash device.
You can set the CompactFlash core to generate two active-high interrupt requests (IRQs): one signals the
insertion and removal of a CompactFlash device and the other passes interrupt signals from the Compact
Flash device.
The CompactFlash core maps the Avalon-MM bus signals to the CompactFlash device with proper timing,
thus allowing Avalon-MM master peripherals to directly access the registers on the CompactFlash device.
For more information, refer to the CF+ and CompactFlash specifications available at www.compact-
flash.org.
Required Connections
The table below lists the required connections between the CompactFlash core and the CompactFlash
device.
Send Feedback
UG-01085
2017.05.08 Required Connections 4-3
Send Feedback
UG-01085
4-4 Software Programming Model 2017.05.08
Software Files
The CompactFlash core provides the following software files. These files define the low-level access to the
hardware. Application developers should not modify these files.
altera_avalon_cf_regs.hThe header file that defines the core's register maps.
altera_avalon_cf.h, altera_avalon_cf.cThe header and source code for the functions
and variables required to integrate the driver into the HAL system library.
Register Maps
This section describes the register maps for the Avalon-MM slave interfaces.
Ide Registers
The ide port in the CompactFlash core allows you to access the IDE registers on a CompactFlash device.
Send Feedback
UG-01085
2017.05.08 Ctl Registers 4-5
1 Error Features
3 Sector No Sector No
7 Status Command
Ctl Registers
The ctl port in the CompactFlash core provides access to the registers which control the cores operation
and interface.
2 Reserved Reserved
3 Reserved Reserved
Cfctl Register
The cfctl register controls the operations of the CompactFlash core. Reading the cfctl register clears the
interrupt.
Send Feedback
UG-01085
4-6 idectl Register 2017.05.08
idectl Register
The idectl register controls the interface to the CompactFlash device.
May 2008 v8.0.0 Added the mode supported by the CompactFlash core.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
Send Feedback
2017.05.08
EPCS Serial Flash Controller Core
5
UG-01085 Subscribe Send Feedback
Core Overview
The EPCS serial flash controller core with Avalon interface allows Nios II systems to access an Altera EPCS
serial configuration device. Altera provides drivers that integrate into the Nios II hardware abstraction
layer (HAL) system library, allowing you to read and write the EPCS device using the familiar HAL
application program interface (API) for flash devices.
Using the EPCS serial flash controller core, Nios II systems can:
Store program code in the EPCS device. The EPCS serial flash controller core provides a boot-loader
feature that allows Nios II systems to store the main program code in an EPCS device.
Store non-volatile program data, such as a serial number, a NIC number, and other persistent data.
Manage the device configuration data. For example, a network-enabled embedded system can receive
new FPGA configuration data over a network, and use the core to program the new data into an EPCS
serial configuration device.
The EPCS serial flash controller core is Qsys-ready and integrates easily into any Qsys-generated
system. The flash programmer utility in the Nios II IDE allows you to manage and program data
contents into the EPCS device.
For information about the EPCS serial configuration device family, refer to the Serial Configuration
Devices Data Sheet.
For details about using the Nios II HAL API to read and write flash memory, refer to the Nios II
Software Developer's Handbook.
For details about managing and programming the EPCS memory contents, refer to the Nios II Flash
Programmer User Guide.
For Nios II processor users, the EPCS serial flash controller core supersedes the Active Serial Memory
Interface (ASMI) device. New designs should use the EPCS serial flash controller core instead of the
ASMI core.
Related Information
Serial Configuration Devices (EPCS1, EPCS4, EPCS16, EPCS64 and EPCS128) Data Sheet
Nios II Classic Software Developer's Handbook
Nios II Flash Programmer User Guide
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
5-2 Functional Description 2017.05.08
Functional Description
As shown below, the EPCS device's memory can be thought of as two separate regions:
FPGA configuration memoryFPGA configuration data is stored in this region.
General-purpose memoryIf the FPGA configuration data does not fill up the entire EPCS device,
any left-over space can be used for general-purpose data and system startup code.
Figure 5-1: Nios II System Integrating an EPCS Serial Flash Controller Core
Altera FPGA
EPCS Serial
Configuration
Device Nios II CPU
By virtue of the HAL generic device model for flash devices, accessing the EPCS device using the HAL
API is the same as accessing any flash memory. The EPCS device has a special-purpose hardware
interface, so Nios II programs must read and write the EPCS memory using the provided HAL flash
drivers.
The EPCS serial flash controller core contains an on-chip memory for storing a boot-loader program.
When used in conjunction with Cyclone and Cyclone II devices, the core requires 512 bytes of boot-
loader ROM. For Cyclone III, Cyclone IV, Stratix II, and newer device families in the Stratix series, the
core requires 1 KByte of boot-loader ROM. The Nios II processor can be configured to boot from the
EPCS serial flash controller core. To do so, set the Nios II reset address to the base address of the EPCS
serial flash controller core. In this case, after reset the CPU first executes code from the boot-loader ROM,
which copies data from the EPCS general-purpose memory region into a RAM. Then, program control
Send Feedback
UG-01085
2017.05.08 Avalon-MM Slave Interface and Registers 5-3
transfers to the RAM. The Nios II IDE provides facilities to compile a program for storage in the EPCS
device, and create a programming file to program into the EPCS device.
For more information, refer to the Nios II Flash Programmer User Guide.
If you program the EPCS device using the Quartus Prime Programmer, all previous content is erased. To
program the EPCS device with a combination of FPGA configuration data and Nios II program data, use
the Nios II IDE flash programmer utility.
The Altera EPCS configuration device connects to the FPGA through dedicated pins on the FPGA, not
through general-purpose I/O pins. In all Altera device families except Cyclone III and Cyclone IV, the
EPCS serial flash controller core does not create any I/O ports on the top-level Qsys system module. If the
EPCS device and the FPGA are wired together on a board for configuration using the EPCS device (in
other words, active serial configuration mode), no further connection is necessary between the EPCS
serial flash controller core and the EPCS device. When you compile the Qsys system in the Quartus Prime
software, the EPCS serial flash controller core signals are routed automatically to the device pins for the
EPCS device.
You, however, have the option not to use the dedicated pins on the FPGA (active serial configuration
mode) by turning off the respective parameters in the MegaWizard interface. When this option is turned
off or when the target device is a Cyclone III or Cyclone IV device, you have the flexibility to connect the
output pins, which are exported to the top-level design, to any EPCS devices. Perform the following tasks
in the Quartus Prime software to make the necessary pin assignments:
On the Dual-purpose pins page (Assignments > Devices > Device and Pin Options), ensure that the
following pins are assigned to the respective values:
Data[0] = Use as regular I/O
Data[1] = Use as regularr I/O
DCLK = Use as regular I/O
FLASH_nCE/nCS0 = Use as regular I/O
Using the Pin Planner (Assignments > Pins), ensure that the following pins are assigned to the
respective configuration functions on the device:
data0_to_the_epcs_controller = DATA0
sdo_from the_epcs_controller = DATA1,ASDO
dclk_from_epcs_controller = DCLK
sce_from_the_epcs_controller = FLASH_nCE
For more information about the configuration pins in Altera devices, refer to the Pin-Out Files for Altera
Devices page.
Related Information
Nios II Flash Programmer User Guide
Pin-Out Files for Altera Devices
Send Feedback
UG-01085
5-4 Configuration 2017.05.08
The EPCS serial flash controller core includes an interrupt signal that can be used to interrupt the CPU
when a transfer has completed.
Note: Altera does not publish the usage of the control and data registers. To access the EPCS device, you
must use the HAL drivers provided by Altera.
Configuration
The core must be connected to a Nios II processor. The core provides drivers for HAL-based Nios II
systems, and the precompiled boot loader code compatible with the Nios II processor.
In device families other than Cyclone III and Cyclone IV, you can use the MegaWizard interface to
configure the core to use general I/O pins instead of dedicated pins by turning off both parameters,
Automatically select dedicated active serial interface, if supported and Use dedicated active serial
interface.
Only one EPCS serial flash controller core can be instantiated in each FPGA design.
Send Feedback
UG-01085
2017.05.08 Software Files 5-5
enabled, you can define the preprocessor symbol, ALT_USE_EPCS_FLASH, before including the header, as
follows:
#define ALT_USE_EPCS_FLASH
#include <altera_avalon_epcs_flash_controller.h>
The HAL API for programming flash, including C-code examples, is described in detail in the Nios II
Classic Software Developer's Handbook.
For details about managing and programming the EPCS device contents, refer to the Nios II Flash
Programmer User Guide.
Software Files
The EPCS serial flash controller core provides the following software files. These files provide low-level
access to the hardware and drivers that integrate into the Nios II HAL system library. Application
developers should not modify these files.
altera_avalon_epcs_flash_controller.h, altera_avalon_epcs_flash_controller.c
Header and source files that define the drivers required for integration into the HAL system library.
epcs_commands.h, epcs_commands.cHeader and source files that directly control the EPCS
device hardware to read and write the device. These files also rely on the Altera SPI core drivers.
March 2009 v9.0.0 Updated the boot ROM memory offset for other device familes in the
EPCS Serial Flash Controller Core Register Map" table.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
Send Feedback
2017.05.08
JTAG UART Core
6
UG-01085 Subscribe Send Feedback
Core Overview
The JTAG UART core with Avalon interface implements a method to communicate serial character
streams between a host PC and a Qsys system on an Altera FPGA. In many designs, the JTAG UART core
eliminates the need for a separate RS-232 serial connection to a host PC for character I/O. The core
provides an Avalon interface that hides the complexities of the JTAG interface from embedded software
programmers. Master peripherals (such as a Nios II processor) communicate with the core by reading and
writing control and data registers.
The JTAG UART core uses the JTAG circuitry built in to Altera FPGAs, and provides host access via the
JTAG pins on the FPGA. The host PC can connect to the FPGA via any Altera JTAG download cable, such
as the Intel FPGA download cable II. Software support for the JTAG UART core is provided by Altera.
For the Nios II processor, device drivers are provided in the hardware abstraction layer (HAL) system
library, allowing software to access the core using the ANSI C Standard Library stdio.h routines.
Nios II processor users can access the JTAG UART via the Nios II IDE or the nios2-terminal command-
line utility. For further details, refer to the Nios II Software Developer's Handbook or the Nios II IDE
online help.
For the host PC, Altera provides JTAG terminal software that manages the connection to the target,
decodes the JTAG data stream, and displays characters on screen.
The JTAG UART core is Qsys-ready and integrates easily into any Qsys-generated system.
Supported Devices
The JTAG UART core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The figure below shows a block diagram of the JTAG UART core and its connection to the JTAG circuitry
inside an Altera FPGA. The following sections describe the components of the core.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
6-2 Avalon Slave Interface and Registers 2017.05.08
TRST
TCK
TDO
TMS
TDI
Altera FPGA
JTAG
Controller
Registers
JTAG Interface
Altera FPGAs contain built-in JTAG control circuitry between the device's JTAG pins and the logic inside
the device. The JTAG controller can connect to user-defined circuits called nodes implemented in the
FPGA. Because several nodes may need to communicate via the JTAG interface, a JTAG hub, which is a
multiplexer, is necessary. During logic synthesis and fitting, the Quartus Prime software automatically
generates the JTAG hub logic. No manual design effort is required to connect the JTAG circuitry inside the
device; the process is presented here only for clarity.
Host-Target Connection
Below you can see the connection between a host PC and an Qsys-generated system containing a JTAG
UART core.
Send Feedback
UG-01085
2017.05.08 Configuration 6-3
Altera FPGA
JTAG Nios II
Host PC Debug Processor
Module
Debugger
M
C PC
Download Altera JTAG System InterconnectFabric
Controller
JTAG Interface
JTAG
Cable Download
JTAG
Hub
Server
Driver Cable
JTAG Terminal
Host PC
S S
Debugger
JTAG On-Chip
UART Memory
C PC
Debug Data M Avalon-MM master port
Download Interface Altera
Character Stream JTAG
S Avalon-MM slave port Cable Downlo
Server
The JTAG controller on the FPGA and the download cable driver on the host PC implement a simple data-
link layer between host and target. All JTAG nodes inside the FPGA are multiplexed through the single
JTAG connection. JTAG server software on the host PC controls and decodes the JTAG data stream, and
maintains distinct connections with nodes inside the FPGA.
The example system in the figure above contains one JTAG UART core and a Nios II processor. Both
agents communicate with the host PC over a single Altera download cable. Thanks to the JTAG server
software, each host application has an independent connection to the target. Altera provides the JTAG
server drivers and host software required to communicate with the JTAG UART core.
Systems with multiple JTAG UART cores are possible, and all cores communicate via the same JTAG
interface. To maintain coherent data streams, only one processor should communicate with each JTAG
UART core.
Configuration
The following sections describe the available configuration options.
Configuration Page
The options on this page control the hardware configuration of the JTAG UART core. The default settings
are pre-configured to behave optimally with the Altera-provided device drivers and JTAG terminal
software. Most designers should not change the default values, except for the Construct using registers
instead of memory blocks option.
Send Feedback
UG-01085
6-4 Write FIFO Settings 2017.05.08
Simulation Settings
At system generation time, when Qsys generates the logic for the JTAG UART core, a simulation model is
also constructed. The simulation model offers features to simplify simulation of systems using the JTAG
UART core. Changes to the simulation settings do not affect the behavior of the core in hardware; the
settings affect only functional simulation.
tive windows during simulation. These windows allow the user to send and receive ASCII characters via a
Send Feedback
UG-01085
2017.05.08 Hardware Simulation Considerations 6-5
console, giving the appearance of a terminal session with the system executing in hardware. The following
options are available:
Do not generate ModelSim aliases for interactive windowsThis option does not create any
ModelSim macros for character I/O.
Create ModelSim alias to open a window showing output as ASCII textThis option creates a
ModelSim macro to open a console window that displays output from the write FIFO. Values written to
the write FIFO via the Avalon interface are displayed in the console as ASCII characters.
Create ModelSim alias to open an interactive stimulus/response windowThis option creates a
ModelSim macro to open a console window that allows input and output interaction with the core.
Values written to the write FIFO via the Avalon interface are displayed in the console as ASCII
characters. Characters typed into the console are fed into the read FIFO, and can be read via the Avalon
interface. When this option is enabled, the simulated character input stream option is ignored.
Send Feedback
UG-01085
6-6 HAL System Library Support 2017.05.08
The "Printing Characters to a JTAG UART core as stdout" example below demonstrates the simplest
possible usage, printing a message to stdout using printf(). In this example, the Qsys system contains a
JTAG UART core, and the HAL system library is configured to use this JTAG UART device for stdout.
#include <stdio.h>
int main ()
{
printf("Hello world.\n");
return 0;
}
The Transmitting characters to a JTAG UART Core example demonstrates reading characters from and
sending messages to a JTAG UART core using the C standard library. In this example, the Qsys system
contains a JTAG UART core named jtag_uart that is not necessarily configured as the stdout device. In
this case, the program treats the device like any other node in the HAL file system.
Send Feedback
UG-01085
2017.05.08 HAL System Library Support 6-7
In this example, the ferror(fp) is used to check if an error occurred on the JTAG UART connection,
such as a disconnected JTAG connection. In this case, the driver detects that the JTAG connection is
disconnected, reports an error (EIO), and discards data for subsequent transactions. If this error ever
occurs, the C library latches the value until you explicitly clear it with the clearerr() function.
For complete details of the HAL system library, refer to the Nios II Classic Software Developer's
Handbook.
The Nios II Embedded Design Suite (EDS) provides a number of software example designs that use the
JTAG UART core.
Send Feedback
UG-01085
6-8 Driver Options: Fast vs. Small Implementations 2017.05.08
ioctl() Operations
The fast version of the JTAG UART driver supports the ioctl() function to allow HAL-based programs to
request device-specific operations. Specifically, you can use the ioctl() operations to control the timeout
period, and to detect whether or not a host is connected. The fast driver defines the ioctl() operations
shown in below.
Table 6-3: JTAG UART ioctl() Operations for the Fast Driver Only
Request Meaning
TIOCSTIMEOUT Set the timeout (in seconds) after which the driver will decide that the host is not
connected. A timeout of 0 makes the target assume that the host is always connected.
The ioctl arg parameter passed in must be a pointer to an integer.
TIOCGCON- Sets the integer arg parameter to a value that indicates whether the host is connected
NECTED and acting as a terminal (1), or not connected (0). The ioctl arg parameter passed in
must be a pointer to an integer.
For details about the ioctl() function, refer to the Nios II Classic Software Developer's Handbook.
Software Files
The JTAG UART core is accompanied by the following software files. These files define the low-level
interface to the hardware, and provide the HAL drivers. Application developers should not modify these
files.
Send Feedback
UG-01085
2017.05.08 Accessing the JTAG UART Core via a Host PC 6-9
Register Map
Programmers using the HAL API never access the JTAG UART core directly via its registers. In general,
the register map is only useful to programmers writing a device driver for the core.
Note: The Altera-provided HAL device driver accesses the device registers directly. If you are writing a
device driver, and the HAL driver is active for the same device, your driver will conflict and fail to
operate.
The table below shows the register map for the JTAG UART core. Device drivers control and communicate
with the core through the two, 32-bit memory-mapped registers.
Data Register
Embedded software accesses the read and write FIFOs via the data register. The table below describes the
function of each bit.
Send Feedback
UG-01085
6-10 Control Register 2017.05.08
A read from the data register returns the first character from the FIFO (if one is available) in the DATA
field. Reading also returns information about the number of characters remaining in the FIFO in the
RAVAIL field. A write to the data register stores the value of the DATA field in the write FIFO. If the write
FIFO is full, the character is lost.
Control Register
Embedded software controls the JTAG UART core's interrupt generation and reads status information via
the control register. The Control Register Bits table below describes the function of each bit.
A read from the control register returns the status of the read and write FIFOs. Writes to the register can
be used to enable/disable interrupts, or clear the AC bit.
The RE and WE bits enable interrupts for the read and write FIFOs, respectively. The WI and RI bits indicate
the status of the interrupt sources, qualified by the values of the interrupt enable bits (WE and RE).
Embedded software can examine RI and WI to determine the condition that generated the IRQ. See the
Interrupt Behavior section for further details.
The AC bit indicates that an application on the host PC has polled the JTAG UART core via the JTAG
interface. Once set, the AC bit remains set until it is explicitly cleared via the Avalon interface. Writing 1 to
AC clears it. Embedded software can examine the AC bit to determine if a connection exists to a host PC. If
no connection exists, the software may choose to ignore the JTAG data stream. When the host PC has no
data to transfer, it can choose to poll the JTAG UART core as infrequently as once per second. Delays
caused by other host software using the JTAG download cable could cause delays of up to 10 seconds
between polls.
Interrupt Behavior
The JTAG UART core generates an interrupt when either of the individual interrupt conditions is pending
and enabled.
Send Feedback
UG-01085
2017.05.08 Document Revision History 6-11
Interrupt behavior is of interest to device driver programmers concerned with the bandwidth performance
to the host PC. Example designs and the JTAG terminal program provided with Nios II Embedded Design
Suite (EDS) are pre-configured with optimal interrupt behavior.
The JTAG UART core has two kinds of interrupts: write interrupts and read interrupts. The WE and RE
bits in the control register enable/disable the interrupts.
The core can assert a write interrupt whenever the write FIFO is nearly empty. The nearly empty threshold,
write_threshold, is specified at system generation time and cannot be changed by embedded software.
The write interrupt condition is set whenever there are write_threshold or fewer characters in the write
FIFO. It is cleared by writing characters to fill the write FIFO beyond the write_threshold. Embedded
software should only enable write interrupts after filling the write FIFO. If it has no characters remaining
to send, embedded software should disable the write interrupt.
The core can assert a read interrupt whenever the read FIFO is nearly full. The nearly full threshold value,
read_threshold, is specified at system generation time and cannot be changed by embedded software.
The read interrupt condition is set whenever the read FIFO has read_threshold or fewer spaces
remaining. The read interrupt condition is also set if there is at least one character in the read FIFO and no
more characters are expected. The read interrupt is cleared by reading characters from the read FIFO.
For optimum performance, the interrupt thresholds should match the interrupt response time of the
embedded software. For example, with a 10-MHz JTAG clock, a new character is provided (or consumed)
by the host PC every 1 s. With a threshold of 8, the interrupt response time must be less than 8 s. If the
interrupt response time is too long, performance suffers. If it is too short, interrupts occurs too often.
For Nios II processor systems, read and write thresholds of 8 are an appropriate default.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
Send Feedback
2017.05.08
UART Core
7
UG-01085 Subscribe Send Feedback
Core Overview
The UART core with Avalon interface implements a method to communicate serial character streams
between an embedded system on an Altera FPGA and an external device. The core implements the RS-232
protocol timing, and provides adjustable baud rate, parity, stop, and data bits. The feature set is configu
rable, allowing designers to implement just the necessary functionality for a given system.
The core provides an Avalon Memory-Mapped (Avalon-MM) slave interface that allows Avalon-MM
master peripherals (such as a Nios II processor) to communicate with the core simply by reading and
writing control and data registers.
Supported Devices
The UART core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
7-2 Functional Description 2017.05.08
Functional Description
Figure 7-1: Block Diagram of the UART Core in a Typical System
Altera FPGA
UART Core
baud rate divisor
clock
divisor
rxdata RXD
shift register
address
data CTS
Avalon-MM status
Connector
signals
RS - 232
Shifter
connected IRQ
Level
to on-chip TXD
logic endofpacket txdata shift register
dataavailable RTS
control
readyfordata
endofpacket
RS-232 Interface
The UART core implements RS-232 asynchronous transmit and receive logic. The UART core sends and
receives serial data via the TXD and RXD ports. The I/O buffers on most Altera FPGA families do not
comply with RS-232 voltage levels, and may be damaged if driven directly by signals from an RS-232
connector. To comply with RS-232 voltage signaling specifications, an external level-shifting buffer is
required (for example, Maxim MAX3237) between the FPGA I/O pins and the external RS-232 connector.
The UART core uses a logic 0 for mark, and a logic 1 for space. An inverter inside the FPGA can be used to
reverse the polarity of any of the RS-232 signals, if necessary.
Send Feedback
UG-01085
2017.05.08 Transmitter Logic 7-3
Transmitter Logic
The UART transmitter consists of a 7-, 8-, or 9-bit txdata holding register and a corresponding 7-, 8-, or
9-bit transmit shift register. Avalon-MM master peripherals write the txdata holding register via the
Avalon-MM slave port. The transmit shift register is loaded from the txdata register automatically when a
serial transmit shift operation is not currently in progress. The transmit shift register directly feeds the TXD
output. Data is shifted out to TXD LSB first.
These two registers provide double buffering. A master peripheral can write a new value into the txdata
register while the previously written character is being shifted out. The master peripheral can monitor the
transmitter's status by reading the status register's transmitter ready (TRDY), transmitter shift register
empty (tmt), and transmitter overrun error (TOE) bits.
The transmitter logic automatically inserts the correct number of start, stop, and parity bits in the serial
TXD data stream as required by the RS-232 specification.
Receiver Logic
The UART receiver consists of a 7-, 8-, or 9-bit receiver-shift register and a corresponding 7-, 8-, or 9-bit
rxdata holding register. Avalon-MM master peripherals read the rxdata holding register via the Avalon-
MM slave port. The rxdata holding register is loaded from the receiver shift register automatically every
time a new character is fully received.
These two registers provide double buffering. The rxdata register can hold a previously received character
while the subsequent character is being shifted into the receiver shift register.
A master peripheral can monitor the receiver's status by reading the status register's read-ready (RRDY),
receiver-overrun error (ROE), break detect (BRK), parity error (PE), and framing error (FE) bits. The
receiver logic automatically detects the correct number of start, stop, and parity bits in the serial RXD
stream as required by the RS-232 specification. The receiver logic checks for four exceptional conditions,
frame error, parity error, receive overrun error, and break, in the received data and sets corresponding
status register bits.
Configuration Settings
This section describes the configuration settings.
Send Feedback
UG-01085
7-4 Baud Rate Options 2017.05.08
clock frequency
baud rate = ---------------
----------------
----------
divisor +1
Send Feedback
UG-01085
2017.05.08 Synchronizer Stages 7-5
Synchronizer Stages
The option Synchronizer Stages allows you to specify the length of synchronization register chains. These
register chains are used when a metastable event is likely to occur and the length specified determines the
meantime before failure. The register chain length, however, affects the latency of the core.
For more information on metastability in Altera devices, refer to AN 42: Metastability in Altera Devices.
For more information on metastability analysis and synchronization register chains, refer to the Area and
Timing Optimization chapter in volume 2 of the Quartus Prime Handbook.
Send Feedback
UG-01085
7-6 Include End-of-Packet Register 2017.05.08
Simulation Settings
When the UART core's logic is generated, a simulation model is also created. The simulation model offers
features to simplify and accelerate simulation of systems that use the UART core. Changes to the
simulation settings do not affect the behavior of the UART core in hardware; the settings affect only
functional simulation.
Note: For simulation, the UART core will not respond to data received on the rxdata register.
For examples of how to use the following settings to simulate Nios II systems, refer to AN 351: Simulating
Nios II Embedded Processor Designs.
the UART simulation model. After reset in reset, the string is input into the RXD port character-by-
character as the core is able to accept new data.
Send Feedback
UG-01085
2017.05.08 Simulation Considerations 7-7
speed, or roughly one character per 20 clock cycles. You can choose one of the following options for the
simulated transmitter baud rate:
Accelerated (use divisor = 2)TXD emits one bit per 2 clock cycles in simulation.
Actual (use true baud divisor)TXD transmits at the actual baud rate, as determined by the divisor
register.
Simulation Considerations
The simulation features were created for easy simulation of Nios II processor systems when using the
ModelSim simulator. The documentation for the processor documents the suggested usage of these
features. Other usages may be possible, but will require additional user effort to create a custom simulation
process.
The simulation model is implemented in the UART core's top-level HDL file; the synthesizable HDL and
the simulation HDL are implemented in the same file. The simulation features are implemented using
translate on and translate off synthesis directives that make certain sections of HDL code visible
only to the synthesis tool.
Do not edit the simulation directives if you are using Altera's recommended simulation procedures. If you
do change the simulation directives for your custom simulation flow, be aware that Qsys overwrites
existing files during system generation. Take precaution so that your changes are not overwritten.
For details about simulating the UART core in Nios II processor systems, refer to AN 351: Simulating
Nios II Processor Designs.
Send Feedback
UG-01085
7-8 Driver Options: Fast vs Small Implementations 2017.05.08
#include <stdio.h>
int main ()
{
printf("Hello world.\n");
return 0;
}
The following code demonstrates reading characters from and sending messages to a UART device using
the C standard library. In this example, the system contains a UART core named uart1 that is not necessa
rily configured as the stdout device. In this case, the program treats the device like any other node in the
HAL file system.
For more information about the HAL system library, refer to the Nios II Classic Software Developer's
Handbook.
Send Feedback
UG-01085
2017.05.08 ioct() Operations 7-9
The small driver is a polled implementation that waits for the UART hardware before sending and
receiving each character. There are two ways to enable the small footprint driver:
Enable the small footprint setting for the HAL system library project. This option affects device drivers
for all devices in the system as well.
Specify the preprocessor option -DALTERA_AVALON_UART_SMALL. You can use this option if you want
the small, polled implementation of the UART driver, but do not want to affect the drivers for other
devices.
Refer to the help system in the Nios II IDE for details about how to set HAL properties and preprocessor
options.
ioct() Operations
The UART driver supports the ioctl() function to allow HAL-based programs to request device-specific
operations. The table below defines operation requests that the UART driver supports.
Additional operation requests are also optionally available for the fast driver only, as shown in Optional
UART ioctl() Operations for the Fast Driver Only Table. To enable these operations in your program,
you must set the preprocessor option -DALTERA_AVALON_UART_USE_IOCTL.
Table 7-3: Optional UART ioctl() Operations for the Fast Driver Only
Request Description
TIOCMGET Returns the current configuration of the device by filling in the contents of the input termios
structure.
A pointer to this structure is supplied as the value of the parameter opt.
TIOCMSET Sets the configuration of the device according to the values contained in the input termios
structure.
A pointer to this structure is supplied as the value of the parameter arg.
Note: The termios structure is defined by the Newlib C standard library. You can find the definition in the
file <Nios II EDS install path>/components/altera_hal/HAL/inc/sys/termios.h.
Send Feedback
UG-01085
7-10 Limitations 2017.05.08
For details about the ioctl() function, refer to the Nios II Classic Software Developer's Handbook.
Limitations
The HAL driver for the UART core does not support the endofpacket register. Refer to the Register map
section for details.
Software Files
The UART core is accompanied by the following software files. These files define the low-level interface to
the hardware, and provide the HAL drivers. Application developers should not modify these files.
altera_avalon_uart_regs.hThis file defines the core's register map, providing symbolic
constants to access the low-level hardware. The symbols in this file are used only by device driver
functions.
altera_avalon_uart.h, altera_avalon_uart.cThese files implement the UART core device
driver for the HAL system library.
Register Map
Programmers using the HAL API never access the UART core directly via its registers. In general, the
register map is only useful to programmers writing a device driver for the core.
The Altera-provided HAL device driver accesses the device registers directly. If you are writing a device
driver and the HAL driver is active for the same device, your driver will conflict and fail to operate.
The UART Core Register map table below shows the register map for the UART core. Device drivers
control and communicate with the core through the memory-mapped registers.
(1) Writing zero to the status register clears the dcts, e, toe, roe, brk, fe, and pe bits.
(2)
These bits may or may not exist, depending on the Data Width hardware option. If they do not exist, they
read zero, and writing has no effect.
(3)
This register may or may not exist, depending on hardware configuration options. If it does not exist, reading
returns an undefined value and writing has no effect.
Send Feedback
UG-01085
2017.05.08 rxdata Register 7-11
Some registers and bits are optional. These registers and bits exists in hardware only if it was enabled at
system generation time. Optional registers and bits are noted in the following sections.
rxdata Register
The rxdata register holds data received via the RXD input. When a new character is fully received via the
RXD input, it is transferred into the rxdata register, and the status register's rrdy bit is set to 1. The
status register's rrdy bit is set to 0 when the rxdata register is read. If a character is transferred into the
rxdata register while the rrdy bit is already set (in other words, the previous character was not retrieved),
a receiver-overrun error occurs and the status register's roe bit is set to 1. New characters are always
transferred into the rxdata register, regardless of whether the previous character was read. Writing data to
the rxdata register has no effect.
txdata Register
Avalon-MM master peripherals write characters to be transmitted into the txdata register. Characters
should not be written to txdata until the transmitter is ready for a new character, as indicated by the TRDY
bit in the status register. The TRDY bit is set to 0 when a character is written into the txdata register. The
TRDY bit is set to 1 when the character is transferred from the txdata register into the transmitter shift
register. If a character is written to the txdata register when TRDY is 0, the result is undefined. Reading the
txdata register returns an undefined value.
For example, assume the transmitter logic is idle and an Avalon-MM master peripheral writes a first
character into the txdata register. The TRDY bit is set to 0, then set to 1 when the character is transferred
into the transmitter shift register. The master can then write a second character into the txdata register,
and the TRDY bit is set to 0 again. However, this time the shift register is still busy shifting out the first
character to the TXD output. The TRDY bit is not set to 1 until the first character is fully shifted out and the
second character is automatically transferred into the transmitter shift register.
status Register
The status register consists of individual bits that indicate particular conditions inside the UART core.
Each status bit is associated with a corresponding interrupt-enable bit in the control register. The status
register can be read at any time. Reading does not change the value of any of the bits. Writing zero to the
status register clears the DCTS, E, TOE, ROE, BRK, FE, and PE bits.
1 FE RC Framing error. A framing error occurs when the receiver fails to detect a
correct stop bit. The FE bit is set to 1 when the core receives a character
with an incorrect stop bit. The FE bit stays set to 1 until it is explicitly
cleared by a write to the status register. When the FE bit is set, reading
from the rxdata register produces an undefined value.
Send Feedback
UG-01085
7-12 status Register 2017.05.08
6 TRDY R Transmit ready. The TRDY bit indicates the txdata holding registers
current state. When the txdata register is empty, it is ready for a new
character, and TRDY is 1. When the txdata register is full, TRDY is 0. An
Avalon-MM master peripheral must wait for TRDY to be 1 before writing
new data to txdata.
7 RRDY R Receive character ready. The RRDY bit indicates the rxdata holding
registers current state. When the rxdata register is empty, it is not ready
to be read and RRDY is 0. When a newly received value is transferred into
the rxdata register, RRDY is set to 1. Reading the rxdata register clears
the RRDY bit to 0. An Avalon-MM master peripheral must wait for RRDY
to equal 1 before reading the rxdata register.
8 E RC Exception. The E bit indicates that an exception condition occurred. The
E bit is a logical-OR of the TOE, ROE, BRK, FE, and PE bits. The E bit and its
corresponding interrupt-enable bit (IE) bit in the control register
provide a convenient method to enable/disable IRQs for all error
conditions.
The E bit is set to 0 by a write operation to the status register.
10 (4) DCTS RC Change in clear to send (CTS) signal. The DCTS bit is set to 1 whenever a
logic-level transition is detected on the CTS_N input port (sampled
synchronously to the Avalon-MM clock). This bit is set by both falling
and rising transitions on CTS_N. The DCTS bit stays set to 1 until it is
explicitly cleared by a write to the status register.
Send Feedback
UG-01085
2017.05.08 control Register 7-13
12 (4) EOP R(4) End of packet encountered. The EOP bit is set to 1 by one of the following
events:
An EOP character is written to txdata
An EOP character is read from rxdata
The EOP character is determined by the contents of the endofpacket
register. The EOP bit stays set to 1 until it is explicitly cleared by a write
to the status register.
If the Include End-of-Packet Register hardware option is not enabled,
the EOP bit always reads 0. Refer to Streaming Data (DMA) Control
Section.
control Register
The control register consists of individual bits, each controlling an aspect of the UART core's operation.
The value in the control register can be read at any time.
Each bit in the control register enables an IRQ for a corresponding bit in the status register. When both
a status bit and its corresponding interrupt-enable bit are 1, the core generates an IRQ.
(4)
This bit is optional and may not exist in hardware.
Send Feedback
UG-01085
7-14 divisor Register (Optional) 2017.05.08
Interrupt Behavior
The UART core outputs a single IRQ signal to the Avalon-MM interface, which can connect to any master
peripheral in the system, such as a Nios II processor. The master peripheral must read the status register
to determine the cause of the interrupt.
Every interrupt condition has an associated bit in the status register and an interrupt-enable bit in the
control register. When any of the interrupt conditions occur, the associated status bit is set to 1 and
remains set until it is explicitly acknowledged. The IRQ output is asserted when any of the status bits are
set while the corresponding interrupt-enable bit is 1. A master peripheral can acknowledge the IRQ by
clearing the status register.
(5)
This bit is optional and may not exist in hardware.
Send Feedback
UG-01085
2017.05.08 Document Revision History 7-15
At reset, all interrupt-enable bits are set to 0; therefore, the core cannot assert an IRQ until a master
peripheral sets one or more of the interrupt-enable bits to 1.
All possible interrupt conditions are listed with their associated status and control (interrupt-enable) bits.
Details of each interrupt condition are provided in the status bit descriptions.
Send Feedback
2017.05.08
16550 UART Core
8
UG-01085 Subscribe Send Feedback
Core Overview
The Altera 16550 UART (Universal Asynchronous Receiver/Transmitter) soft IP core with Avalon
interface is designed to be register space compatible with the de-facto standard 16550 found in the PC
industry. The core provides RS-232 Signaling interface, False start detection, Modem control signal and
registers, Receiver error detection and Break character generation/detection. The core also has an Avalon
Memory-Mapped (Avalon-MM) slave interface that allows Avalon-MM master peripherals (such as a Nios
II processor) to communicate with the core simply by reading and writing control and data registers.
The 16550 UART supports all memory types depending on the device family. Supported devices are listed
below:
Arria V
Arria 10
Cyclone V
MAX 10
Stratix IV
Feature Description
The 16550 Soft-UART has the following features:
RS-232 signaling interface
Avalon-MM slave
Single clock
False start detection
Modem control signal and registers
Receiver error detection
Break character generation/detection
Supports full duplex mode by default
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
8-2 Unsupported Features 2017.05.08
Note: When a feature is both Generate time and Run time configurable, the feature must be enabled
during Generate time before Run time configuration can be used. Therefore, turning ON a feature
during Generate time is a prerequisite to enabling/disabling it during run time.
Unsupported Features
Unsupported Features vs PC16550D:
Separate receive clock
Baud clock reference output
Interface
The Soft UART will have the following signal interface, exposed using _hw.tcl through Qsys software.
Send Feedback
UG-01085
2017.05.08 Interface 8-3
Send Feedback
UG-01085
8-4 General Architecture 2017.05.08
General Architecture
Figure 8-1: Soft-UART High Level Architecture
The figure above shows the high level architecture of the UART IP. Both Transmit and Receive logic have
their own dedicated control & data path. An interrupt block and clock generator block is also present to
service both transmit and receive logic.
Send Feedback
UG-01085
2017.05.08 16550 UART General Programming Flow Chart 8-5
Note: You are free to change this flow to fit your own usage model but the changes might cause undefined
results.
Figure 8-2: 16550 UART Configuration Flow
FIFO Enable
Write to FCR
Transmit Empty Trigger
Receive Trigger
Data Length
Write to LCR Stop Bits
Parity Enable
Odd/Even parity
Change Baud
Rate? Write to LCR Set DLAB = 1
Set DLAB = 0
Write to LCR
For more information on the register descriptions used in the flow chart, refer to the "Address Map and
Register Descriptions" section.
Related Information
Address Map and Register Descriptions on page 8-22
Send Feedback
UG-01085
8-6 Configuration Parameters 2017.05.08
Configuration Parameters
The table below shows all the parameters that can be used to configure the UART. (_hw.tcl) is the
mechanism used to enforce and validate correct parameter settings.
FIFO_MODE must be 1
DMA Support
The DMA interface (DMA_EXTRA) is disabled by default. It must be enabled in the IP to have the
additional DMA_Handshaking_tx and DMA_Handshaking_rx interfaces. DMA support is only available
when used with the HPS DMA controller. The HPS DMA controller has the required handshake signals to
control DMA data transfers with the IP through the DMA_Handshaking_tx and DMA_Handshaking_rx
interfaces. The DMA handshaking interfaces are connected to the HPS through the f2h DMA request
lines.
Send Feedback
UG-01085
2017.05.08 FPGA Resource Usage 8-7
Figure 8-3: Altera 16550 UART's DMA Handshaking Interfaces Connection to Arria V/Cyclone V HPS in Qsys
For more information about the HPS DMA Controller handshake signals, refer to the DMA Controller
chapter in the Cyclone V Device Handbook, Volume 3.
Related Information
DMA Controller
Send Feedback
UG-01085
8-8 Timing and Fmax 2017.05.08
Resource Number
Total MLAB memory bits 2432
The diagram above shows worst case combinatorial delays throughout the UART IP Core. These estimates
are provided by TimeQuest under the following condition:
Device Family: Series V and above
Avalon Master connected to Avalon Slave port of the UART with outputs from the Avalon Master
registered
RS-232 Serial Interface is exported to FPGA Pin
Clocks for entire system set at 125 MHz
Based on the conditions above the UART IP has an Fmax value of 125 MHz, with the worst delay being
internal register-to-register paths.
The UART has combinatorial logic on both the Input and Output side, with system level implications on
the Input side.
The Input side combinatorial logic (with 7ns delay) goes through the Avalon address decode logic, to the
Read data output registers. It is therefore recommended that Masters connected to the UART IP register
their output signals.
The Output side combinatorial logic (with 2ns delay) goes through the RS-232 Serial Output. There should
not be any concern on the output side delays though as it is not a single cycle path. Using the highest
clock divider value of 1, the serial output only toggles once every 16 clocks. This naturally gives a 16 clock
multi-cycle path on the output side. Furthermore, divider of 1 is an unlikely system, if the UART is clocked
at 125 MHz, the resulting baud rate would be 7.81 Mbps.
Avalon-MM Slave
The Avalon-MM Slave has the following configuration:
Send Feedback
UG-01085
2017.05.08 Read behavior 8-9
Feature Configuration
Burst Support No burst support. Interconnect is expected to
handle burst conversion
Fixed read and write wait time 0 cycles
Fixed read latency 1 cycle
Fixed write latency 0 cycles
Lock support No
Note: The Avalon-MM interface is intended to be a thin, low latency layer on top of the registers.
Read behavior
Figure 8-5: Reading UART over Avalon-MM
0 1 2 3 4 5 6 7 8 9
read
readdata data1 data2 data3 data4
Write behavior
Figure 8-6: Writing to UART over Avalon-MM
0 1 2 3 4 5 6 7 8 9
read
readdata data1 data2 data3 data4
Configuration Writing to
TX FIFO
Send Feedback
UG-01085
8-10 Overrun/Underrun Conditions 2017.05.08
Writes to the UART are expected as singles during setup phase of any transaction and as back-to-back
writes to the same address when the Tx FIFO needs to be filled.
Overrun/Underrun Conditions
Consistent with UART implementation in PC16550D, the soft UART will not implement overrun or
underrun prevention on the Avalon-MM interface.
Preventing overruns and underruns on the Avalon-MM interface by back-pressuring a pending transac
tion may cause more harm than good as the interconnect can be held up by the far slower UART.
Overrun
On receive path, interrupts can be triggered (when enabled) when overrun occurs. In FIFO-less mode,
overrun happens when an existing character in the receive buffer is overwritten by a new character before
it can be read. In FIFO mode, overrun happens when the FIFO is full and a complete character arrives at
the receive buffer.
On transmit path, software driver is expected to know the Tx FIFO depth and not overrun the UART.
Underrun
No mechanisms exist to detect or prevent underrun.
On transmit path, an interrupts, when enabled, can be generated when the transmit holding register is
empty or when the transmit FIFO is below a programmed level.
On receive path, the software driver is expected to read from the UART receive buffer (FIFO-less) or the
(Rx FIFO) based on interrupts, when enabled, or status registers indicating presence of receive data (Data
Ready bit, LSR[0]). If reads to Receive Buffer Register is triggered with data ready register being zero,
undefined read data is returned.
Send Feedback
UG-01085
2017.05.08 Clock and Baud Rate Selection 8-11
The rts_n output will go active (low state), when the Rx FIFO is empty, signaling to the opposite UART
that it is ready for data. The rts_n output goes inactive (high state) when the Rx FIFO level is reached,
signaling to the opposite UART that the FIFO is about to go full and it should stop transmitting.
Due to the delays within the UART logic, one additional character may be transmitted after cts_n is
sampled active low. For the same reason, the Rx FIFO will accommodate up to 1 additional character after
asserting rts_n (this is allowed because Rx FIFO trigger level is at worst, two entries from being truly
full). Both are observed to prevent overflow/underflow between UARTs.
Figure 8-7: Hardware Auto Flow-Control Between two UARTs
UART 1 UART 2
sout sin
Transmit Buffer Receive Buffer
TX RX
FIFO FIFO
cts_n rts_n
Flow Control Flow Control
sin sout
Receive Buffer Transmit Buffer
RX TX
FIFO FIFO
rts_n cts_n
Flow Control Flow Control
Table 8-11: UART Clock Frequency, Divider value and Baud Rate Relationship
18.432 MHz 24 MHz 50 MHz
Baud Rate Divisor for % Error Divisor for % Error Divisor for % Error (baud)
16x clock (baud) 16x clock (baud) 16x clock
9,600 120 0.00% 156 0.16% 326 -0.15%
38,400 30 0.00% 39 0.16% 81 0.47%
115,200 10 0.00% 13 0.16% 27 0.47%
Send Feedback
UG-01085
8-12 Overview 2017.05.08
Overview
The following describes the programming model for the Altera compatible 16550 Soft-UART.
Supported Features
For the following features, the 16550 Soft-UART HAL driver can be configurable in run time or generate
time. For run-time configuration, users can use altera_16550_uart_config API . Generate time is during
Qsys generation, that is to say once FIFO Depth is selected the depth for the FIFO cant be change
anymore.
Unsupported Features
The 16550 UART driver does not support Software flow control.
Configuration
The figure below shows the Qsys setup on the 16550 Soft-UART's FIFO Depth
Send Feedback
UG-01085
2017.05.08 16550 UART API 8-13
Public APIs
Send Feedback
UG-01085
8-14 Public APIs 2017.05.08
Include: <altera_16550_uart.h>
Parameters: dev - The UART device
ptr destination address
len maximum length of the data
flags for indicating blocking/non-blocking access
for single/multi threaded
Send Feedback
UG-01085
2017.05.08 Private APIs 8-15
Private APIs
Send Feedback
UG-01085
8-16 UART Device Structure 2017.05.08
Send Feedback
UG-01085
2017.05.08 UART Device Structure 8-17
* foreground/background in mult-threaded
* mode */
ALT_SEM (read_lock) /* Semaphore used to control access to the
* read buffer in multi-threaded mode */
ALT_SEM (write_lock) /* Semaphore used to control access to the
* write buffer in multi-threaded mode */
volatile wchar_t rx_buf[ALT_16550_UART_BUF_LEN]; /* The receive buffer */
volatile wchar_t tx_buf[ALT_16550_UART_BUF_LEN]; /* The transmit buffer */
line_status_reg line_status; /* line register status for the current read
byte data of RBR or data at the top of FIFO*/
alt_u8 error_ignore; /* received data will be discarded
for the current read byte data of RBR or data at the top of FIFO if pe, fe
and bi errors detected after error_ignore is set to '0' */
} altera_16550_uart_state;
Send Feedback
UG-01085
8-18 Driver Examples 2017.05.08
Driver Examples
Below is a simple test program to verify that the Altera 16550 UART driver support is functional.
The test reads, validates, and writes a modified baud rate, data bits, stop bits, parity bits to the UART
before attempting to write a character stream to it from UART0 to UART1 and vice verse (ping pong test).
This also tests the FIFO and FIFO-less mode as well as the HW flow control to ensure the IP is functioning
for FIFO and HWFC.
Prerequisites needed before running test:
An instance of UART named "uart0" and another instance UART named "uart1".
Both UARTs need to be connected in loopback in Quartus.
Additional coverage:
Non-blocking UART support
UART HAL driver
HAL open/write support
The test will print "PASS: . . ." from the UART to indicate success.
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/termios.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <sys/time.h>
#include <time.h>
#include "system.h"
#include "altera_16550_uart.h"
#include "altera_16550_uart_regs.h"
#define ERROR -1
#define SUCCESS 0
#define MOCK_UART
#define BUFSIZE 512
char TXMessage[BUFSIZE] = "Hello World";
char RXMessage[BUFSIZE] = "";
int UARTBaudRateTest()
{
UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));
Send Feedback
UG-01085
2017.05.08 Driver Examples 8-19
switch(direction)
{
case 0:
printf("Ping Pong Baud Rate Test: UART#0 to UART#1\n");
for(j=0; j<strlen(TXMessage); j++)
{
altera_16550_uart_write(uart_0, &TXMessage[j], 1, 0);
usleep(1000);
if(ERROR== altera_16550_uart_read(uart_1, RXMessage, 1,
0)) return ERROR;
if(TXMessage[j]==RXMessage[0]) Match=1; else return
ERROR;
printf("Sent:'%c', Received:'%c', Match:%d\n",
TXMessage[j], RXMessage[0], Match);
}
break;
case 1:
printf("Ping Pong Baud Rate Test: UART#1 to UART#0\n");
for(j=0; j<strlen(TXMessage); j++)
{
altera_16550_uart_write(uart_1, &TXMessage[j], 1, 0);
usleep(1000);
if(ERROR== altera_16550_uart_read(uart_0, RXMessage, 1,
0)) return ERROR;
if(TXMessage[j]==RXMessage[0]) Match=1; else return
ERROR;
printf("Sent:'%c', Received:'%c', Match:%d\n",
TXMessage[j], RXMessage[0], Match);
}
break;
default:
break;
}
usleep(1000);
}
}
free(UART0_Config);
free(UART1_Config);
return SUCCESS;
}
int UARTLineControlTest()
{
Send Feedback
UG-01085
8-20 Driver Examples 2017.05.08
int UARTFIFOModeTest()
{
Send Feedback
UG-01085
2017.05.08 Driver Examples 8-21
altera_16550_uart_state* uart_0;
altera_16550_uart_state* uart_1;
switch(direction)
{
case 0:
printf("Ping Pong FIFO Test: UART#0 to UART#1\n");
CharCounter=altera_16550_uart_write(uart_0, &TXMessage,
strlen(TXMessage), 0);
//usleep(50000);
if(ERROR== altera_16550_uart_read(uart_1, RXMessage,
strlen(TXMessage), 0)) return ERROR;
if(strcmp(TXMessage, RXMessage)==0) Match=1; else Match=0;
printf("Sent:'%s' CharCount:%d, Received:'%s' CharCount:%d,
Match:%d\n", TXMessage, CharCounter, RXMessage, strlen(RXMessage), Match);
if(Match==0) return ERROR;
break;
case 1:
printf("Ping Pong FIFO Test: UART#1 to UART#0\n");
CharCounter=altera_16550_uart_write(uart_1, &TXMessage,
strlen(TXMessage), 0);
//usleep(50000);
if(ERROR== altera_16550_uart_read(uart_0, RXMessage,
strlen(TXMessage), 0)) return ERROR;
if(strcmp(TXMessage, RXMessage)==0) Match=1; else Match=0;
printf("Sent:'%s' CharCount:%d, Received:'%s' CharCount:%d,
Match:%d\n", TXMessage, CharCounter, RXMessage, strlen(RXMessage), Match);
if(Match==0) return ERROR;
break;
default:
break;
}
//usleep(100000);
}
}
free(UART0_Config);
free(UART1_Config);
return SUCCESS;
}
int main()
{
int result=0;
Send Feedback
UG-01085
8-22 Address Map and Register Descriptions 2017.05.08
result = UARTBaudRateTest();
if(result==ERROR)
{
printf("UARTBaudRateTest FAILED\n");
return ERROR;
}
result = UARTLineControlTest();
if(result==ERROR)
{
printf("UARTLineControlTest FAILED\n");
return ERROR;
}
result = UARTFIFOModeTest();
if(result==ERROR)
{
printf("UARTFIFOModeTest FAILED\n");
return ERROR;
}
printf("\n\nALL TESTS PASS\n\n");
return 0;
}
Send Feedback
UG-01085
2017.05.08 rbr_thr_dll 8-23
rbr_thr_dll
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
- rbr_thr_dll
Send Feedback
UG-01085
8-24 rbr_thr_dll 2017.05.08
Send Feedback
UG-01085
2017.05.08 ier_dlh 8-25
ier_dlh
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
8-26 ier_dlh 2017.05.08
Send Feedback
UG-01085
2017.05.08 iir 8-27
iir
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
- fifose - id
Send Feedback
UG-01085
8-28 fcr 2017.05.08
fcr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
2017.05.08 fcr 8-29
[2] Tx FIFO Reset (xfifor) This bit resets the control portion of the transmit W 0x0
FIFO and treats the FIFO as empty. Note that this
bit is 'self-clearing' and it is not necessary to clear
this bit. Please allow for 8 clock cycles to pass after
changing this register bit before reading from RBR
or writing to THR.
[1] Rx FIFO Reset (rfifor) Resets the control portion of the receive FIFO and W 0x0
treats the FIFO as empty. Note that this bit is self-
clearing' and it is not necessary to clear this bit.
Allow for 8 clock cycles to pass after changing this
register bit before reading from RBR or writing to
THR.
[0] FIFO Enable (fifoe) This bit enables/disables the transmit (Tx) and W 0x0
receive (Rx ) FIFO's. Whenever the value of this bit
is changed both the Tx and Rx controller portion of
FIFO's will be reset.
Any existing data in both Tx and Rx FIFO will be
lost when this bit is changed. Please allow for 8
clock cycles to pass after changing this register bit
before reading from RBR or writing to THR.
Send Feedback
UG-01085
8-30 lcr 2017.05.08
lcr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
[6] Break Control Bit This is used to cause a break condition to be RW 0x0
(break) transmitted to the receiving device. If set to one the
serial output is forced to the spacing (logic 0) state
until the Break bit is cleared.
[5] Stick Parity (sp) The SP bit works in conjunction with the EPS and RW 0x0
PEN bits. When odd parity is selected (EPS = 0), the
PARITY bit is transmitted and checked as set. When
even parity is selected (EPS = 1), the PARITY bit is
transmitted and checked as cleared.
[4] Even Parity Select (eps) This is used to select between even and odd parity, RW 0x0
when parity is enabled (PEN set to one). If set to
one, an even number of logic '1's is transmitted or
checked. If set to zero, an odd number of logic '1's is
transmitted or checked.
[3] Parity Enable (pen) This bit is used to enable and disable parity RW 0x0
generation and detection in a transmitted and
received data character.
Send Feedback
UG-01085
2017.05.08 lcr 8-31
[1:0] Data Length Select (dls) Selects the number of data bits per character that RW 0x0
the peripheral will transmit and receive.
0-5 data bits per character
1-6 data bits per character
2-7 data bits per character
3-8 data bits per character
Send Feedback
UG-01085
8-32 mcr 2017.05.08
mcr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
[4] LoopBack Bit This is used to put the UART into a diagnostic mode RW 0x0
(loopback) for test purposes. If UART mode is NOT active, bit
[6] of the modem control register MCR is set to
zero, data on the sout line is held high, while serial
data output is looped back to the sin line, internally.
In this mode all the interrupts are fully functional.
Also, in loopback mode, the modem control inputs
(dsr_n, cts_n, ri_n, dcd_n) are disconnected and
the modem control outputs (dtr_n, rts_n, out1_n,
out2_n) are loopedback to the inputs, internally.
[3] Out2 (out2) This is used to directly control the user-designated RW 0x0
out2_n output. The value written to this location is
inverted and driven out on out2_n
[2] Out1 (out1) This is used to directly control the user-designated RW 0x0
out1_n output. The value written to this location is
inverted and driven out on out1_n pin.
Send Feedback
UG-01085
2017.05.08 mcr 8-33
[0] Data Terminal Ready This is used to directly control the Data Terminal RW 0x0
(dtr) Ready output. The value written to this location is
inverted and driven out on uart_dtr_n. The Data
Terminal Ready output is used to inform the
modem or data set that the UART is ready to
establish communications.
Send Feedback
UG-01085
8-34 lsr 2017.05.08
lsr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
[6] Transmitter Empty bit If in FIFO mode and FIFO's enabled (FCR[0] set to R 0x1
(temt) one), this bit is set whenever the Transmitter Shift
Register and the FIFO are both empty. If FIFO's are
disabled, this bit is set whenever the Transmitter
Holding Register and the Transmitter Shift Register
are both empty. Indicator is cleared when new data
is written into the THR or Transmit FIFO.
[5] Transmit Holding This bit indicates that the THR or Tx FIFO is empty. R 0x1
Register Empty bit This bit is set when data is transferred from the
(thre) THR or Tx FIFO to the transmitter shift register and
no new data has been written to the THR or Tx
FIFO. This also causes a THRE Interrupt to execute,
if the THRE Interrupt is enabled.
Send Feedback
UG-01085
2017.05.08 lsr 8-35
[3] Framing Error (fe) This is used to indicate the occurrence of a framing RC 0x0
error in the receiver. A framing error occurs when
the receiver does not detect a valid STOP bit in the
received data. In the FIFO mode, since the framing
error is associated with a character received, it is
revealed when the character with the framing error
is at the top of the FIFO. When a framing error
occurs the UART will try to resynchronize. It does
this by assuming that the error was due to the start
bit of the next character and then continues
receiving the other bit data, and/or parity and stop.
It should be noted that the Framing Error (FE)
bit(LSR[3]) will be set if a break interrupt has
occurred, as indicated by a Break Interrupt BIT bit
(LSR[4]). This bit always stays in sync with the
associated character in RBR. If the current
associated character is read through RBR, this bit
will be updated to be in sync with the next character
in RBR. Reading the LSR clears the FE bit.
[2] Parity Error (pe) This is used to indicate the occurrence of a parity RC 0x0
error in the receiver if the Parity Enable (PEN) bit
(LCR[3]) is set. Since the parity error is associated
with a character received, it is revealed when the
character with the parity error arrives at the top of
the FIFO. It should be noted that the Parity Error
(PE) bit (LSR[2]) will be set if a break interrupt has
occurred, as indicated by Break Interrupt (BI) bit
(LSR[4]). In this situation, the Parity Error bit is set
depending on the combination of EPS (LCR[4]) and
DLS (LCR[1:0]). This bit always stays in sync with
the associated character in RBR. If the current
associated character is read through RBR, this bit
will be updated to be in sync with the next character
in RBR. Reading the LSR clears the PE bit.
Send Feedback
UG-01085
8-36 lsr 2017.05.08
[0] Data Ready bit (dr) This is used to indicate that the receiver contains at R 0x0
least one character in the RBR or the receiver FIFO.
This bit is cleared when the RBR is read in the non-
FIFO mode, or when the receiver FIFO is empty, in
the FIFO mode.
Send Feedback
UG-01085
2017.05.08 msr 8-37
msr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
[6] Ring Indicator (ri) This bit is the complement of modem control R 0x0
line (ri_n). This bit is used to indicate the
current state of ri_n. When the Ring
Indicator input (ri_n) is asserted it is an
indication that a telephone ringing signal has
been received by the modem or data set.
Send Feedback
UG-01085
8-38 msr 2017.05.08
[4] Clear to Send (cts) This bit is the complement of modem control R 0x0
line cts_n. This bit is used to indicate the
current state of cts_n. When the Clear to
Send input (cts_n) is asserted it is an
indication that the modem or data set is
ready to exchange data with the uart.
[3] Delta Data Carrier This is used to indicate that the modem RC 0x0
Detect (ddcd) control line dcd_n has changed since the last
time the MSR was read. Reading the MSR
clears the DDCD bit.
Note: If the DDCD bit is not set and the
dcd_n signal is asserted (low) and a
reset occurs (software or otherwise),
then the DDCD bit will get set when
the reset is removed if the dcd_n
signal remains asserted.
[2] Trailing Edge of Ring This is used to indicate that a change on the RC 0x0
Indicator (teri) input ri_n (from an active low, to an inactive
high state) has occurred since the last time
the MSR was read. Reading the MSR clears
the TERI bit.
[1] Delta Data Set Ready This is used to indicate that the modem RC 0x0
(ddsr) control line dsr_n has changed since the last
time the MSR was read. Reading the MSR
clears the DDSR bit.
Note: If the DDSR bit is not set and the dsr_
n signal is asserted (low) and a reset
occurs (software or otherwise), then
the DDSR bit will get set when the
reset is removed if the dsr_n signal
remains asserted.
Send Feedback
UG-01085
2017.05.08 msr 8-39
Send Feedback
UG-01085
8-40 scr 2017.05.08
scr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
- scr
Send Feedback
UG-01085
2017.05.08 afr 8-41
afr
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
- tx_low_en
Send Feedback
UG-01085
8-42 tx_low 2017.05.08
tx_low
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
- value
Send Feedback
UG-01085
2017.05.08 Document Revision History 8-43
December 2015 2015.12.16 Product ID changed in "16550 UART Release Information" section.
November 2015 2015.11.06 Updated the following topics:
Core Overview on page 8-1
Feature Description
Table 8-1
General Architecture
Figure 8-1
Configuration Parameters
Table 8-8
DMA Support on page 8-6
Supported Features
Table 8-12
Configuration
Figure 8-8
UART Device Structure on page 8-16
Example 1 and 2
Address Map and Register Descriptions on page 8-22
June 2015 2015.06.12 Added "16550 UART General Programming Flow Chart" section
Added "16550 UART Release Information" section
Added "Address Map and Register Descriptions" section
Added Stick parity/Force parity feature into the "UART Features
and Configurability" table in the "Feature Description" section
Updated "Interface" section with sout_oe signal details in the "Flow
Control" table
Updated "Underrun" section
Send Feedback
2017.05.08
SPI Core
9
UG-01085 Subscribe Send Feedback
Core Overview
SPI is an industry-standard serial protocol commonly used in embedded systems to connect
microprocessors to a variety of off-chip sensor, conversion, memory, and control devices. The SPI core
with Avalon interface implements the SPI protocol and provides an Avalon Memory-Mapped (Avalon-
MM) interface on the back end.
The SPI core can implement either the master or slave protocol. When configured as a master, the core can
control up to 32 independent SPI slaves. The width of the receive and transmit registers are configurable
between 1 and 32 bits. Longer transfer lengths can be supported with software routines. The core provides
an interrupt output that can flag an interrupt whenever a transfer completes.
Functional Description
The SPI core communicates using two data lines, a control line, and a synchronization clock:
Master Out Slave In (mosi)Output data from the master to the inputs of the slaves
Master In Slave Out (miso)Output data from a slave to the input of the master
Serial Clock (sclk)Clock driven by the master to slaves, used to synchronize the data bits
Slave Select (ss_n) Select signal (active low) driven by the master to individual slaves, used to select
the target slave
The SPI core has the following user-visible features:
A memory-mapped register space comprised of five registers: rxdata, txdata, status, control, and
slaveselect
Four SPI interface ports: sclk, ss_n, mosi, and miso
The registers provide an interface to the SPI core and are visible via the Avalon-MM slave port. The
sclk, ss_n, mosi, and miso ports provide the hardware interface to other SPI devices. The behavior of
sclk, ss_n, mosi, and miso depends on whether the SPI core is configured as a master or slave.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
9-2 Example Configurations 2017.05.08
status
ss_n0
ss_n1
IRQ control
The SPI core logic is synchronous to the clock input provided by the Avalon-MM interface. When
configured as a master, the core divides the Avalon-MM clock to generate the SCLK output. When
configured as a slave, the core's receive logic is synchronized to SCLK input.
For more details, refer to the "Interval Timer Core" chapter.
Example Configurations
The core block diagram and the SPI core configured as a slave diagram show two possible configurations.
In Figure 9-2 the core provides a slave interface to an off-chip SPI master.
Figure 9-2: SPI Core Configured as a Slave
Altera FPGA
SPI component
(configured as slave)
In the SPI core block diagram, the SPI core provides a master interface driving multiple off-chip slave
devices. Each slave device in Figure 9-2 must tristate its miso output whenever its select signal is not
asserted.
The ss_n signal is active-low. However, any signal can be inverted inside the FPGA, allowing the slave-
select signals to be either active high or active low.
Transmitter Logic
The core transmitter logic consists of a transmit holding register (txdata) and transmit shift register, each
n bits wide. The register width n is specified at system generation time, and can be any integer value from 8
Send Feedback
UG-01085
2017.05.08 Receiver Logic 9-3
to 32. After a master peripheral writes a value to the txdata register, the value is copied to the shift register
and then transmitted when the next operation starts.
The shift register and the txdata register provide double buffering during data transmission. A new value
can be written into the txdata register while the previous data is being shifted out of the shift register. The
transmitter logic automatically transfers the txdata register to the shift register whenever a serial shift
operation is not currently in process.
In master mode, the transmit shift register directly feeds the mosi output. In slave mode, the transmit shift
register directly feeds the miso output. Data shifts out LSB first or MSB first, depending on the configura
tion of the SPI core.
Receiver Logic
The core receive logic consists of a receive holding register (rxdata) and receive shift register, each n bits
wide. The register width n is specified at system generation time, and can be any integer value from 8 to
32. A master peripheral reads received data from the rxdata register after the shift register has captured a
full n-bit value of data.
The shift register and the rxdata register provide double buffering while receiving data. The rxdata
register can hold a previously received data value while subsequent new data is shifting into the shift
register. The receiver logic automatically transfers the shift register content to the rxdata register when a
serial shift operation completes.
In master mode, the shift register is fed directly by the miso input. In slave mode, the shift register is fed
directly by the mosi input. The receiver logic expects input data to arrive LSB first or MSB first, depending
on the configuration of the SPI core.
In master mode, an intelligent host (for example, a microprocessor) configures the SPI core using the
control and slaveselect registers, and then writes data to the txdata buffer to initiate a transaction. A
master peripheral can monitor the status of the transaction by reading the status register. A master
peripheral can enable interrupts to notify the host whenever new data is received (for example, a transfer
has completed), or whenever the transmit buffer is ready for new data.
The SPI protocol is full duplex, so every transaction both sends and receives data at the same time. The
master transmits a new data bit on the mosi output and the slave drives a new data bit on the miso input
Send Feedback
UG-01085
9-4 Slave Mode Operation 2017.05.08
for each active edge of sclk. The SPI core divides the Avalon-MM system clock using a clock divider to
generate the sclk signal.
When the SPI core is configured to interface with multiple slaves, the core has one ss_n signal for each
slave. During a transfer, the master asserts ss_n to each slave specified in the slaveselect register. Note
that there can be no more than one slave transmitting data during any particular transfer, or else there will
be a contention on the miso input. The number of slave devices is specified at system generation time.
In slave mode, the SPI core simply waits for the master to initiate transactions. Before a transaction begins,
the slave logic continuously polls the ss_n input. When the master asserts ss_n, the slave logic
immediately begins sending the transmit shift register contents to the miso output. The slave logic also
captures data on the mosi input, and fills the receive shift register simultaneously. After a word is received
by the slave, the master must de-assert the ss_n signal and reasserts the signal again when the next word is
ready to be sent.
An intelligent host such as a microprocessor writes data to the txdata registers, so that it is transmitted
the next time the master initiates an operation. A master peripheral reads received data from the rxdata
register. A master peripheral can enable interrupts to notify the host whenever new data is received, or
whenever the transmit buffer is ready for new data.
Multi-Slave Environments
When ss_n is not asserted, typical SPI cores set their miso output pins to high impedance. The provided
SPI slave core drives an undefined high or low value on its miso output when not selected. Special
consideration is necessary to avoid signal contention on the miso output, if the SPI core in slave mode is
connected to an off-chip SPI master device with multiple slaves. In this case, the ss_n input should be used
to control a tristate buffer on the miso signal.
Send Feedback
UG-01085
2017.05.08 Configuration 9-5
sclk sclk
SPI mosi mosi
Master miso miso
Device ss_n0 ss_n0
ss_01
SPI component
(configured as slave)
sclk
mosi SPI
miso Slave
SS_n Device
Configuration
The following sections describe the available configuration options.
Master/Slave Settings
The designer can select either master mode or slave mode to determine the role of the SPI core. When
master mode is selected, the following options are available: Number of select (SS_n) signals, SPI clock
rate, and Specify delay.
Specify Delay
Turning on this option causes the SPI master to add a time delay between asserting the ss_n signal and
shifting the first bit of data. This delay is required by certain SPI slave devices. If the delay option is on, you
must also specify the delay time in units of ns, s or ms. An example is shown in below.
Send Feedback
UG-01085
9-6 Data Register Settings 2017.05.08
Figure 9-4: Time Delay Between Asserting ss_n and Toggling sclk
The delay generation logic uses a granularity of half the period of sclk. The actual delay achieved is the
desired target delay rounded up to the nearest multiple of half the sclk period, as shown in the follow two
equations.
Table 9-3:
p = 1/2 x (period of sclk)
Table 9-4:
Actual delay = ceiling x (desired delay/ p)
Timing Settings
The timing settings affect the timing relationship between the ss_n, sclk, mosi and miso signals. In this
discussion the mosi and miso signals are referred to generically as data. There are two timing settings:
Clock polarityThis setting can be 0 or 1. When clock polarity is set to 0, the idle state for sclk is low.
When clock polarity is set to 1, the idle state for sclk is high.
Clock phaseThis setting can be 0 or 1. When clock phase is 0, data is latched on the leading edge of
sclk, and data changes on trailing edge. When clock phase is 1, data is latched on the trailing edge of
sclk, and data changes on the leading edge.
The following four clock polarity figures demonstrate the behavior of signals in all possible cases of
clock polarity and clock phase.
Figure 9-5: Clock Polarity = 0, Clock Phase = 0
Send Feedback
UG-01085
2017.05.08 Software Programming Model 9-7
alt_avalon_spi_command()
alt_u32 write_length,
const alt_u8* wdata,
alt_u32 read_length,
alt_u8* read_data,
alt_u32 flags)
Send Feedback
UG-01085
9-8 Software Files 2017.05.08
Thread-safe: No.
Available from ISR: No.
Include: <altera_avalon_spi.h>
Description: This function performs a control sequence on the SPI bus. It supports only
SPI masters with data width less than or equal to 8 bits. A single call to this
function writes a data buffer of arbitrary length to the mosi port, and then
reads back an arbitrary amount of data from the miso port. The function
performs the following actions:
(1) Asserts the slave select output for the specified slave. The first slave select
output is 0.
(2) Transmits write_length bytes of data from wdata through the SPI
interface, discarding the incoming data on the miso port.
(3) Reads read_length bytes of data and stores the data into the buffer
pointed to by read_data. The mosi port is set to zero during the read transac
tion.
(4) De-asserts the slave select output, unless the flags field contains the value
ALT_AVALON_SPI_COMMAND_MERGE. If you want to transmit from
scattered buffers, call the function multiple times and specify the merge flag
on all the accesses except the last.
To access the SPI bus from more than one thread, you must use a semaphore
or mutex to ensure that only one thread is executing within this function at
any time.
Software Files
The core is accompanied by the following software files. These files provide a low-level interface to the
hardware.
altera_avalon_spi.hThis file defines the core's register map, providing symbolic constants to
access the low-level hardware.
altera_avalon_spi.cThis file implements low-level routines to access the hardware.
Send Feedback
UG-01085
2017.05.08 Register Map 9-9
Register Map
An Avalon-MM master peripheral controls and communicates with the core via the six 32-bit registers,
shown in below in the Register Map for SPI Master Device figure. The table assumes an n-bit data width
for rxdata and txdata.
4 Reserved
5 slaveselect (7)
R/W Slave Select Mask
6 eop_value(8) R/W End of Packet Value (n-1..0)
Reading undefined bits returns an undefined value. Writing to undefined bits has no effect.
rxdata Register
A master peripheral reads received data from the rxdata register. When the receive shift register receives a
full n bits of data, the status register's RRDY bit is set to 1 and the data is transferred into the rxdata
register. Reading the rxdata register clears the RRDY bit. Writing to the rxdata register has no effect.
New data is always transferred into the rxdata register, whether or not the previous data was retrieved. If
RRDY is 1 when data is transferred into the rxdata register (that is, the previous data was not retrieved), a
receive-overrun error occurs and the status register's ROE bit is set to 1. In this case, the contents of
rxdata are undefined.
txdata Register
A master peripheral writes data to be transmitted into the txdata register. When the status register's
TRDY bit is 1, it indicates that the txdata register is ready for new data. The TRDY bit is set to 0 whenever
the txdata register is written. The TRDY bit is set to 1 after data is transferred from the txdata register into
the transmitter shift register, which readies the txdata holding register to receive new data.
A master peripheral should not write to the txdata register until the transmitter is ready for new data. If
TRDY is 0 and a master peripheral writes new data to the txdata register, a transmit-overrun error occurs
and the status register's TOE bit is set to 1. In this case, the new data is ignored, and the content of txdata
remains unchanged.
(6)
A write operation to the status register clears the ROE, TOE, and E bits.
(7)
Present only in master mode.
(8)
Bits 31 to n are undefined when n is less than 32.
Send Feedback
UG-01085
9-10 status Register 2017.05.08
As an example, assume that the SPI core is idle (that is, the txdata register and transmit shift register are
empty), when a CPU writes a data value into the txdata holding register. The TRDY bit is set to 0
momentarily, but after the data in txdata is transferred into the transmitter shift register, TRDY returns to
1. The CPU writes a second data value into the txdata register, and again the TRDY bit is set to 0. This time
the shift register is still busy transferring the original data value, so the TRDY bit remains at 0 until the shift
operation completes. When the operation completes, the second data value is transferred into the
transmitter shift register and the TRDY bit is again set to 1.
status Register
The status register consists of bits that indicate status conditions in the SPI core. Each bit is associated
with a corresponding interrupt-enable bit in the control register, as discussed in the Control Register
section. A master peripheral can read status at any time without changing the value of any bits. Writing
status does clear the ROE, TOE and E bits.
8 E Error
The E bit is the logical OR of the TOE and ROE bits. This is a convenience for the programmer to
detect error conditions. Writing to the status register clears the E bit to 0.
Send Feedback
UG-01085
2017.05.08 control Register 9-11
# Name Description
9 EOP End of Packet
The EOP bit is set when the End of Packet condition is detected. The End of Packet condition is
detected when either the read data of the rxdata register or the write data to the txdata
register is matching the content of the eop_value register.
control Register
The control register consists of data bits to control the SPI core's operation. A master peripheral can read
control at any time without changing the value of any bits.
Most bits (IROE, ITOE, ITRDY, IRRDY, and IE) in the control register control interrupts for status
conditions represented in the status register. For example, bit 1 of status is ROE (receiver-overrun error),
and bit 1 of control is IROE, which enables interrupts for the ROE condition. The SPI core asserts an
interrupt request when the corresponding bits in status and control are both 1.
After reset, all bits of the control register are set to 0. All interrupts are disabled and no ss_n signals are
asserted.
slaveselect Register
The slaveselect register is a bit mask for the ss_n signals driven by an SPI master. During a serial shift
operation, the SPI master selects only the slave device(s) specified in the slaveselect register.
The slaveselect register is only present when the SPI core is configured in master mode. There is one bit
in slaveselect for each ss_n output, as specified by the designer at system generation time.
A master peripheral can set multiple bits of slaveselect simultaneously, causing the SPI master to
simultaneously select multiple slave devices as it performs a transaction. For example, to enable communi
cation with slave devices 1, 5, and 6, set bits 1, 5, and 6 of slaveselect. However, consideration is
necessary to avoid signal contention between multiple slaves on their miso outputs.
Send Feedback
UG-01085
9-12 end of packet value Register 2017.05.08
Upon reset, bit 0 is set to 1, and all other bits are cleared to 0. Thus, after a device reset, slave device 0 is
automatically selected.
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 Revised register width in transmitter logic and receiver logic.
Added description on the disable flow control option.
Added R/W column in Table 9-5 .
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. Updated the width of the parameters
and signals from 16 to 32.
May 2008 v8.0.0 Updated the description of the TMT bit.
Send Feedback
2017.05.08
Optrex 16207 LCD Controller Core
10
UG-01085 Subscribe Send Feedback
Core Overview
The Optrex 16207 LCD controller core with Avalon Interface (LCD controller core) provides the
hardware interface and software driver required for a Nios II processor to display characters on an
Optrex 16207 (or equivalent) 162-character LCD panel. Device drivers are provided in the HAL system
library for the Nios II processor. Nios II programs access the LCD controller as a character mode device
using ANSI C standard library routines, such as printf(). The LCD controller is Qsys-ready, and
integrates easily into any Qsys-generated system.
The Nios II Embedded Design Suite (EDS) includes an Optrex LCD module and provide several ready-
made example designs that display text on the Optrex 16207 via the LCD controller.
For details about the Optrex 16207 LCD module, see the manufacturer's Dot Matrix Character LCD
Module User's Manual available online.
Functional Description
The LCD controller core consists of two user-visible components:
Eleven signals that connect to pins on the Optrex 16207 LCD panelThese signals are defined in the
Optrex 16207 data sheet.
EEnable (output)
RSRegister Select (output)
R/WRead or Write (output)
DB0 through DB7Data Bus (bidirectional)
An Avalon Memory-Mapped (Avalon-MM) slave interface that provides access to 4 registers.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
10-2 Software Programming Model 2017.05.08
Altera FPGA
address E
RS
Avalon-MM slave data Optrex 16207
LCD
interface to Controller
R/W LCD Module
on-chip logic control
DB0 . DB7
Send Feedback
UG-01085
2017.05.08 Software Files 10-3
Sequence Meaning
CR (\r) Moves the cursor to the start of the current line.
LF (\n) Moves the cursor to the start of the line and move it down one
line.
ESC ( (\x1B) Starts a VT100 control sequence.
ESC [ <y> ; <x> H Moves the cursor to the y, x position specified positions are
counted from the top left which is 1;1.
ESC [ K Clears from current cursor position to end of line.
ESC [ 2 J Clears the whole screen.
The LCD controller is an output-only device. Therefore, attempts to read from it returns immediately
indicating that no characters have been received.
The LCD controller drivers are not included in the system library when the Reduced device drivers
option is enabled for the system library. If you want to use the LCD controller while using small drivers for
other devices, add the preprocessor optionDALT_USE_LCD_16207 to the preprocessor options.
Software Files
The LCD controller is accompanied by the following software files. These files define the low-level interface
to the hardware and provide the HAL drivers. Application developers should not modify these files.
altera_avalon_lcd_16207_regs.h This file defines the core's register map, providing
symbolic constants to access the low-level hardware.
altera_avalon_lcd_16207.h, altera_avalon_lcd_16207.c These files implement the
LCD controller device drivers for the HAL system library.
Register Map
The HAL device drivers make it unnecessary for you to access the registers directly. Therefore, Altera does
not publish details about the register map. For more information, the altera_avalon_lcd_16207_
regs.h file describes the register map, and the Dot Matrix Character LCD Module User's Manual from
Optrex describes the register usage.
Interrupt Behavior
The LCD controller does not generate interrupts. However, the LCD driver's text scrolling feature relies on
the HAL system clock driver, which uses interrupts for timing purposes.
Send Feedback
UG-01085
10-4 Document Revision History 2017.05.08
Send Feedback
2017.05.08
PIO Core
11
UG-01085 Subscribe Send Feedback
Core Overview
The parallel input/output (PIO) core with Avalon interface provides a memory-mapped interface between
an Avalon Memory-Mapped (Avalon-MM) slave port and general-purpose I/O ports. The I/O ports
connect either to on-chip user logic, or to I/O pins that connect to devices external to the FPGA.
The PIO core provides easy I/O access to user logic or external devices in situations where a bit banging
approach is sufficient. Some example uses are:
Controlling LEDs
Acquiring data from switches
Controlling display devices
Configuring and communicating with off-chip devices, such as application-specific standard products
(ASSP)
The PIO core interrupt request (IRQ) output can assert an interrupt based on input signals.
Supported Devices
The PIO core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Each PIO core can provide up to 32 I/O ports. An intelligent host such as a microprocessor controls the
PIO ports by reading and writing the register-mapped Avalon-MM interface. Under control of the host,
the PIO core captures data on its inputs and drives data to its outputs. When the PIO ports are connected
directly to I/O pins, the host can tristate the pins by writing control registers in the PIO core. The example
below shows a processor-based system that uses multiple PIO cores to drive LEDs, capture edges from on-
chip reset-request control logic, and control an off-chip LCD display.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
11-2 Data Input and Output 2017.05.08
Altera FPGA
PIO core 4
(output only) LEDs
CPU
System InterconnectFabric
PIO
Reset
core Edge
request
(input Capture
IRQ only) logic
Program
and Data
Memory PIO 11 LCD
core display
(bidirectional)
When integrated into an Qsys-generated system, the PIO core has two user-visible features:
A memory-mapped register space with four registers: data, direction, interruptmask, and
edgecapture
1 to 32 I/O ports
The I/O ports can be connected to logic inside the FPGA, or to device pins that connect to off-chip
devices. The registers provide an interface to the I/O ports via the Avalon-MM interface. See Register
Map for the PIO Core table for a description of the registers.
Edge Capture
The PIO core can be configured to capture edges on its input ports. It can capture low-to-high transitions,
high-to-low transitions, or both. Whenever an input detects an edge, the condition is indicated in the
edgecapture register. The types of edges detected is specified at system generation time, and cannot be
changed via the registers.
IRQ Generation
The PIO core can be configured to generate an IRQ on certain input conditions. The IRQ conditions can
be either:
Send Feedback
UG-01085
2017.05.08 Example Configurations 11-3
Level-sensitiveThe PIO core hardware can detect a high level. A NOT gate can be inserted external to
the core to provide negative sensitivity.
Edge-sensitiveThe core's edge capture configuration determines which type of edge causes an IRQ
Interrupts are individually maskable for each input port. The interrupt mask determines which input
port can generate interrupts.
Example Configurations
Figure 11-2: PIO Core with Input Ports, Output Ports, and IRQ Support
Avalon-MM address 32
in
interface data data
to on-chip control out
logic
interruptmask
IRQ
edgecapture
The block diagram below shows the PIO core configured in bidirectional mode, without support for IRQs.
Figure 11-3: PIO Cores with Bidirectional Ports
Avalon-MM address in
data 32
interface data
out
to on-chip control
logic
direction
Avalon-MM Interface
The PIO core's Avalon-MM interface consists of a single Avalon-MM slave port. The slave port is capable
of fundamental Avalon-MM read and write transfers. The Avalon-MM slave port provides an IRQ output
so that the core can assert interrupts.
Configuration
The following sections describe the available configuration options.
Basic Settings
The Basic Settings page allows you to specify the width, direction and reset value of the I/O ports.
Send Feedback
UG-01085
11-4 Width 2017.05.08
Width
The width of the I/O ports can be set to any integer value between 1 and 32.
Direction
You can set the port direction to one of the options shown below.
Output Register
The option Enable individual bit set/clear output register allows you to set or clear individual bits of the
output port. When this option is turned on, two additional registersoutset and outclearare
implemented. You can use these registers to specify the output bit to set and clear.
Input Options
The Input Options page allows you to specify edge-capture and IRQ generation settings. The Input
Options page is not available when Output ports only is selected on the Basic Settings page.
Send Feedback
UG-01085
2017.05.08 Edge Capture Register 11-5
Interrupt
Turn on Generate IRQ to assert an IRQ output when a specified event occurs on input ports. The user
must further specify the cause of an IRQ event:
Level The core generates an IRQ whenever a specific input is high and interrupts are enabled for that
input in the interruptmask register.
Edge The core generates an IRQ whenever a specific bit in the edge capture register is high and
interrupts are enabled for that bit in the interruptmask register.
When Generate IRQ is off, the interruptmask register does not exist.
Simulation
The Simulation page allows you to specify the value of the input ports during simulation. Turn on
Hardwire PIO inputs in test bench to set the PIO input ports to a certain value in the testbench, and
specify the value in Drive inputs to field.
system library header file that defines the PIO core registers. The PIO core does not match the generic
device model categories supported by the HAL, so it cannot be accessed via the HAL API or the ANSI C
standard library.
The Nios II Embedded Design Suite (EDS) provides several example designs that demonstrate usage of the
PIO core. In particular, the count_binary.c example uses the PIO core to drive LEDs, and detect
button presses using PIO edge-detect interrupts.
Software Files
The PIO core is accompanied by one software file, altera_avalon_pio_regs.h. This file defines the
core's register map, providing symbolic constants to access the low-level hardware.
Register Map
An Avalon-MM master peripheral, such as a CPU, controls and communicates with the PIO core via the
four 32-bit registers, shown below. The table assumes that the PIO core's I/O ports are configured to a
width of n bits.
Send Feedback
UG-01085
11-6 data Register 2017.05.08
data Register
Reading from data returns the value present at the input ports if the PIO core hardware is configured to
input, or inout mode only. If the PIO core hardware is configured to output-only mode, reading from the
data register returns the value present at the output ports. Whereas, if the PIO core hardware is
configured to bidirectional mode, reading from data register returns value depending on the direction
register value, setting to 1 returns value present at the output ports, setting to 0 returns undefined value.
Writing to data stores the value to a register that drives the output ports. If the PIO core hardware is
configured in input-only mode, writing to data has no effect. If the PIO core hardware is in bidirectional
mode, the registered value appears on an output port only when the corresponding bit in the direction
register is set to 1 (output).
direction Register
The direction register controls the data direction for each PIO port, assuming the port is bidirectional.
When bit n in direction is set to 1, port n drives out the value in the corresponding bit of the data
register.
The direction register only exists when the PIO core hardware is configured in bidirectional mode. In
input-only, output-only and inout mode, the direction register does not exist. In this case, reading
Send Feedback
UG-01085
2017.05.08 interruptmask Register 11-7
direction returns an undefined value, writing direction has no effect. The mode (input, output, inout
or bidirectional) is specified at system generation time, and cannot be changed at runtime.
After reset, all direction register bits are 0, so that all bidirectional I/O ports are configured as inputs. If
those PIO ports are connected to device pins, the pins are held in a high-impedance state. In bi-directional
mode, you will need to write to the direction register to change the direction of the PIO port (0-input, 1-
output).
interruptmask Register
Setting a bit in the interruptmask register to 1 enables interrupts for the corresponding PIO input port.
Interrupt behavior depends on the hardware configuration of the PIO core. See the Interrupt Behavior
section.
The interruptmask register only exists when the hardware is configured to generate IRQs. If the core
cannot generate IRQs, reading interruptmask returns an undefined value, and writing to interruptmask
has no effect.
After reset, all bits of interruptmask are zero, so that interrupts are disabled for all PIO ports.
edgecapture Register
Bit n in the edgecapture register is set to 1 whenever an edge is detected on input port n. An Avalon-MM
master peripheral can read the edgecapture register to determine if an edge has occurred on any of the
PIO input ports. If the edge capture register bit has been previously set, in_port toggling activity will not
change value.
If the option Enable bit-clearing for the edge capture register is turned off, writing any value to the
edgecapture register clears all bits in the register. Otherwise, writing a 1 to a particular bit in the register
clears only that bit.
The type of edge(s) to detect is fixed in hardware at system generation time. The edgecapture register
only exists when the hardware is configured to capture edges. If the core is not configured to capture
edges, reading from edgecapture returns an undefined value, and writing to edgecapture has no effect.
Interrupt Behavior
The PIO core outputs a single IRQ signal that can connect to any master peripheral in the system. The
master can read either the data register or the edgecapture register to determine which input port caused
the interrupt.
When the hardware is configured for level-sensitive interrupts, the IRQ is asserted whenever
corresponding bits in the data and interruptmask registers are 1. When the hardware is configured for
edge-sensitive interrupts, the IRQ is asserted whenever corresponding bits in the edgecapture and
interruptmask registers are 1. The IRQ remains asserted until explicitly acknowledged by disabling the
appropriate bit(s) in interruptmask, or by writing to edgecapture.
Send Feedback
UG-01085
11-8 Software Files 2017.05.08
Software Files
The PIO core is accompanied by the following software file. This file provide low-level access to the
hardware. Application developers should not modify the file.
altera_avalon_pio_regs.hThis file defines the core's register map, providing symbolic
constants to access the low-level hardware. The symbols in this file are used by device driver functions.
March 2009 v9.0.0 Added a section on new registers, outset and outclear
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. Added the description for Output
Port Reset Value and Simulation parameters
May 2008 v8.0.0 No change from previous release
Send Feedback
2017.05.08
Avalon-ST Serial Peripheral Interface Core
12
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Serial Peripheral Interface (SPI) core is an SPI slave that allows data
transfers between Qsys systems and off-chip SPI devices via Avalon-ST interfaces. Data is serially
transferred on the SPI, and sent to and received from the Avalon-ST interface in bytes.
The SPI Slave to Avalon Master Bridge is an example of how this core is used.
For more information on the bridge, refer to Avalon-ST Serial Peripheral Interface Core.
Functional Description
Figure 12-1: System with an Avalon-ST SPI Core
Altera FPGA
System Interconnect Fabric
Avalon-ST data_out
sclk
Avalon-ST Source
mosi Serial
SPI Rest of the
SPI
SPI System
Clock Clock
Interfaces
The serial peripheral interface is full-duplex and does not support backpressure. It supports SPI clock
phase bit, CPHA = 1, and SPI clock polarity bit, CPOL = 0.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
12-2 Operation 2017.05.08
Feature Property
Channel Not supported.
Error Not used.
Packet Not supported.
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specifications.
Operation
The Avalon-ST SPI core waits for the nSS signal to be asserted low, signifying that the SPI master is
initiating a transaction. The core then starts shifting in bits from the input signal mosi. The core packs the
bits received on the SPI to bytes and checks for the following special characters:
0x4aIdle character. The core drops the idle character.
0x4dEscape character. The core drops the escape character, and XORs the following byte with 0x20.
For each valid byte of data received, the core asserts the valid signal on its Avalon-ST source interface
and presents the byte on the interface for a clock cycle.
At the same time, the core shifts data out from the Avalon-ST sink to the output signal miso beginning
with from the most significant bit. If there is no data to shift out, the core shifts out idle characters
(0x4a). If the data is a special character, the core inserts an escape character (0x4d) and XORs the data
with 0x20.
The data shifts into and out of the core in the direction of MSB first.
Figure 12-2: SPI Transfer Protocol
sclk
(CPOL = 0)
Sample I
MOSI/MISO
Change O
MISO pin
Change O
MOSI pin
nSS
TL TT TI TL
Timing
The core requires a lead time (TL) between asserting the nSS signal and the SPI clock, and a lag time (TT)
between the last edge of the SPI clock and deasserting the nSS signal. The nSS signal must be deasserted
for a minimum idling time (TI) of one SPI clock between byte transfers. A TimeQuest SDC file (.sdc) is
Send Feedback
UG-01085
2017.05.08 Limitations 12-3
provided to remove false timing paths. The frequency of the SPI masters clock must be equal to or lower
than the frequency of the cores clock.
Limitations
Daisy-chain configuration, where the output line miso of an instance of the core is connected to the input
line mosi of another instance, is not supported.
Configuration
The parameter Number of synchronizer stages: Depth allows you to specify the length of
synchronization register chains. These register chains are used when a metastable event is likely to occur
and the length specified determines the meantime before failure. The register chain length, however,
affects the latency of the core.
For more information on metastability in Altera devices, refer to AN 42: Metastability in Altera Devices.
For more information on metastability analysis and synchronization register chains, refer to the Area and
Timing Optimization chapter in volume 2 of the Quartus Prime Handbook.
Send Feedback
2017.05.08
Avalon-ST Single-Clock and Dual-Clock FIFO
Cores 13
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Single-Clock and Avalon-ST Dual-Clock FIFO cores are FIFO buffers
which operate with a common clock and independent clocks for input and output ports respectively. The
FIFO cores are configurable, SOPC Builder-ready, and integrate easily into any SOPC Builder-generated
systems.
Supported Devices
The Avalon-ST Single Clock and Dual Clock FIFO cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The following two figures show block diagrams of the Avalon-ST Single-Clock FIFO and Avalon-ST Dual-
Clock FIFO cores.
Figure 13-1: Avalon-ST Single Clock FIFO Core
csr
Avalon-MM
Slave
Avalon-ST Avalon-ST
Status Status
Source Source
almost_full almost_empty
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
13-2 Interfaces 2017.05.08
in_csr out_csr
Avalon-MM Avalon-MM
Slave Slave
in Avalon-ST Avalon-ST
Data
Avalon-ST out
Data
Sink Dual-Clock Source
FIFO
Clock A Clock B
Interfaces
This section describes the interfaces implemented in the FIFO cores.
RL**For more information about Avalon interfaces, refer to the Avalon Interface Specifications.
Send Feedback
UG-01085
2017.05.08 Operating Modes 13-3
Operating Modes
The following lists the FIFO operating modes:
Default modeThe core accepts incoming data on the in interface (Avalon-ST data sink) and forwards
it to the out interface (Avalon-ST data source). The core asserts the valid signal on the Avalon-ST
source interface to indicate that data is available at the interface.
Store and forward modeThis mode only applies to the single-clock FIFO core. The core asserts the
valid signal on the out interface only when a full packet of data is available at the interface.
In this mode, you can also enable the drop-on-error feature by setting the drop_on_error register to 1.
When this feature is enabled, the core drops all packets received with the in_error signal asserted.
Cut-through mode This mode only applies to the single-clock FIFO core. The core asserts the valid
signal on the out interface to indicate that data is available for consumption when the number of
entries specified in the cut_through_threshold register are available in the FIFO buffer.
To use the store and forward or cut-through mode, turn on the Use store and forward parameter to
include the csr interface (Avalon-MM slave). Set the cut_through_threshold register to 0 to enable
the store and forward mode; set the register to any value greater than 0 to enable the cut-through
mode. The non-zero value specifies the minimum number of FIFO entries that must be available before
the data is ready for consumption. Setting the register to 1 provides you with the default mode.
Fill Level
You can obtain the fill level of the FIFO buffer via the optional Avalon-MM control and status interface.
Turn on the Use fill level parameter (Use sink fill level and Use source fill level in the dual-clock FIFO
core) and read the fill_level register.
The dual-clock FIFO core has two fill levels, one in each clock domain. Due to the latency of the clock
crossing logic, the fill levels reported in the input and output clock domains may be different at any given
instance. In both cases, the fill level is pessimistic for the clock domain; the fill level is reported high in the
input clock domain and low in the output clock domain.
The dual-clock FIFO has an output pipeline stage to improve fMAX. This output stage is accounted for
when calculating the output fill level, but not when calculating the input fill level. Hence, the best measure
of the amount of data in the FIFO is given by the fill level in the output clock domain, while the fill level in
the input clock domain represents the amount of space available in the FIFO (Available space = FIFO
depth input fill level).
Thresholds
You can use almost-full and almost-empty thresholds as a mechanism to prevent FIFO overflow and
underflow. This feature is only available in the single-clock FIFO core.
To use the thresholds, turn on the Use fill level, Use almost-full status, and Use almost-empty status
parameters. You can access the almost_full_threshold and almost_full_threshold registers via the
csr interface and set the registers to an optimal value for your application.
You can obtain the almost-full and almost-empty statuses from almost_full and almost_empty
interfaces (Avalon-ST status source). The core asserts the almost_full signal when the fill level is equal to
or higher than the almost-full threshold. Likewise, the core asserts the almost_empty signal when the fill
level is equal to or lower than the almost-empty threshold.
Send Feedback
UG-01085
13-4 Parameters 2017.05.08
Parameters
For more information on metastability in Altera devices, refer to AN 42: Metastability in Altera Devices.
For more information on metastability analysis and synchronization register chains, refer to the Area and
Timing Optimization chapter in volume 2 of the Quartus Prime Handbook.
Send Feedback
UG-01085
2017.05.08 Register Description 13-5
Register Description
The csr interface in the Avalon-ST Single Clock FIFO core provides access to registers. The table below
describes the registers.
The in_csr and out_csr interfaces in the Avalon-ST Dual Clock FIFO core reports the FIFO fill level. The
table below describes the fill level.
Send Feedback
UG-01085
13-6 Document Revision History 2017.05.08
Table 13-5: Avalon-ST Single-Clock and Dual-Clock FIFO Core Revision History
Date Version Changes
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 Added description of the new features of the single-clock FIFO: store
and forward mode, cut-through mode, and drop on error.
Added parameters and registers.
March 2009 v9.0.0 Added description of new parameters, Write pointer synchronizer
length and Read pointer synchronizer length.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
Send Feedback
2017.05.08
MDIO Core
14
UG-01085 Subscribe Send Feedback
Core Overview
The Altera Management Data Input/Output (MDIO) IP core is a two-wire standard management interface
that implements a standardized method to access the external Ethernet PHY device management registers
for configuration and management purposes. The MDIO IP core is IEEE 802.3 standard compliant.
To access each PHY device, the PHY register address must be written to the register space followed by the
transaction data. The PHY register addresses are mapped in the MDIO cores register space and can be
accessed by the host processor via the Avalon Memory-Mapped (Avalon-MM) interface. This IP core can
also be used with the Altera 10-Gbps Ethernet MAC to realize a fully manageable system.
Functional Description
The core provides an Avalon Memory-Mapped (Avalon-MM) slave interface that allows Avalon-MM
master peripherals (such as a CPU) to communicate with the core and access the external PHY by reading
and writing the control and data registers. The system interconnect fabric connects the Avalon-MM
master and slave interface while a buffer connects the MDIO interface signals to the external PHY.
For more information about system interconnect fabric for Avalon-MM interfaces, refer to the System
Interconnect Fabric for Memory-Mapped Interfaces.
Figure 14-1: MDIO Core Block Diagram
Altera FPGA
clk
reset
csr_read mdc
System csr_write
mdio_in
User Inter- csr_address Avalon-MM MDIO mdio External PHY
6 Slave
Logic connect MDIO Core Ports mdio_out
Fab ric csr_writedata Interface
32
mdio_oen
csr_readdata
32
csr_waitrequest
MDIO Buffer
Connection
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
14-2 MDIO Frame Format (Clause 45) 2017.05.08
00 Address
01 Write Z0 Read
11 Read 10 Address/Write
PRTAD The port address (PRTAD) is 5 bits, allowing 32 unique port addresses. Transmission is MSB to
LSB. A station management entity (STA) must have a prior knowledge of the appropriate port
address for each port to which it is attached, whether connected to a single port or to multiple
ports.
DEVAD The device address (DEVAD) is 5 bits, allowing 32 unique MDIO manageable devices (MMDs) per
port. Transmission is MSB to LSB.
TA The turnaround time is a 2-bit time spacing between the device address field and the data field of
a management frame to avoid contention during a read transaction.
For a read transaction, both the STA and the MMD remain in a high-impedance state (Z) for the
first bit time of the turnaround. The MMD drives a 0 during the second bit time of the
turnaround of a read or postread-increment-address transaction.
For a write or address transaction, the STA drives a 1 for the first bit time of the turnaround and a
0 for the second bit time of the turnaround.
Send Feedback
UG-01085
2017.05.08 MDIO Clock Generation 14-3
Field Description
Name
REGAD/ The register address (REGAD) or data field is 16 bits. For an address cycle, it contains the address of
the register to be accessed on the next cycle. For the data cycle of a write frame, the field contains
Data
the data to be written to the register. For a read frame, the field contains the contents of the
register. The first bit transmitted and received is bit 15.
Idle The idle condition on MDIO is a high-impedance state. All tri-state drivers are disabled and the
MMDs pullup resistor pulls the MDIO line to a one.
Interfaces
The MDIO core consists of a single Avalon-MM slave interface. The slave interface performs Avalon-MM
read and write transfers initiated by an Avalon-MM master in the client application logic. The Avalon-MM
slave uses the waitrequest signal to implement backpressure on the Avalon-MM master for any read or
write operation which has yet to be completed.
For more information about Avalon-MM interfaces, refer to the Avalon Interface Specifications.
Operation
The MDIO core has bidirectional external signals to transfer data between the external PHY and the core.
Write Operation
Follow the steps below to perform a write operation.
1. Issue a write to the device register at address offset 0x21 to configure the device, port, and register
addresses of the PHY.
2. Issue a write to the MDIO_ACCESS register at address offset 0x20 to generate an MDIO frame and write
the data to the selected PHY devices register.
Read Operation
Follow the steps below to perform a read operation.
Send Feedback
UG-01085
14-4 Parameter 2017.05.08
1. Issue a write to the device register at address offset 0x21 to configure the device, port, and register
addresses of the PHY.
2. Issue a read to the MDIO_ACCESS register at address offset 0x20 to read the selected PHY devices
register.
Parameter
Configuration Registers
An Avalon-MM master peripheral, such as a CPU, controls and communicates with the MDIO core via
32-bit registers, shown in the Register Map table.
0x20 (1) 31:0 MDIO_ACCESS RW Performs a read or write of 32-bit data to the external
PHY device. The addresses of the external PHY devices
register, device, and port are specified in address offset
0x21.
Send Feedback
UG-01085
2017.05.08 Document Revision History 14-5
Send Feedback
2017.05.08
On-Chip FIFO Memory Core
15
UG-01085 Subscribe Send Feedback
Core Overview
The on-chip FIFO memory core buffers data and provides flow control in an Qsys system. The core can
operate with a single clock or with separate clocks for the input and output ports, and it does not support
burst read or write.
The input interface to the on-chip FIFO memory core may be an Avalon Memory Mapped (Avalon-MM)
write slave or an Avalon Streaming (Avalon-ST) sink. The output interface can be an Avalon-ST source or
an Avalon-MM read slave. The data is delivered to the output interface in the same order that it was
received at the input interface, regardless of the value of channel, packet, frame, or any other signals.
In single-clock mode, the on-chip FIFO memory core includes an optional status interface that provides
information about the fill level of the FIFO core. In dual-clock mode, separate, optional status interfaces
can be included for the input and output interfaces. The status interface also includes registers to set and
control interrupts.
Device drivers are provided in the HAL system library allowing software to access the core using ANSI C.
Functional Description
The on-chip FIFO memory core has four configurations:
Avalon-MM write slave to Avalon-MM read slave
Avalon-ST sink to Avalon-ST source
Avalon-MM write slave to Avalon-ST source
Avalon-ST sink to Avalon-MM read slave
In all configurations, the input and output interfaces can use the optional backpressure signals to
prevent underflow and overflow conditions. For the Avalon-MM interface, backpressure is
implemented using the waitrequest signal. For Avalon-ST interfaces, backpressure is implemented
using the ready and valid signals. For the on-chip FIFO memory core, the delay between the sink
asserts ready and the source drives valid data is one cycle.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
15-2 Avalon-ST Sink to Avalon-ST Source 2017.05.08
If Allow backpressure is turned on, the waitrequest signal is asserted whenever the data_in master tries
to write to a full FIFO buffer. waitrequest is only deasserted when there is enough space in the FIFO
buffer for a new transaction to complete. waitrequest is asserted for read operations when there is no
data to be read from the FIFO buffer, and is deasserted when the FIFO buffer has data.
Figure 15-1: FIFO with Avalon-MM Input and Output Interfaces
S S
On-Chip FIFO
Memory
Wr Rd
Input dat a Output dat a
S S
S Ava lon-MM S la ve Po rt
S S
On -Chip FIFO
Me mory
St re aming
Out put Dat a
SN K S RC
Send Feedback
UG-01085
2017.05.08 Avalon-MM Write Slave to Avalon-ST Source 15-3
(source) data width must also be 32 bits. You can configure output interface parameters, including: bits
per symbol, symbols per beat, and the width of the channel and error signals. The FIFO core performs
the endian conversion to conform to the output interface protocol.
The signals that comprise the output interface are mapped into bits in the Avalon address space. If Allow
backpressure is turned on, the input interface asserts waitrequest to indicate that the FIFO core does not
have enough space for the transaction to complete.
Figure 15-3: FIFO with Avalon-MM Input Interface and Avalon-ST Output Interface
S S
On -Chip FIFO
Me mory
S trea ming
Input Da ta Output Da ta
S S RC
Send Feedback
UG-01085
15-4 Avalon-ST Sink to Avalon-MM Read Slave 2017.05.08
If Enable packet data is turned off, the Avalon-MM write master writes all data at address offset 0
repeatedly to push data into the FIFO core.
If Enable packet data is turned on, the Avalon-MM write master starts by writing the SOP, ERROR
(optional), CHANNEL (optional), EOP, and EMPTY packet status information at address offset 1. Writing to
address offset 1 does not push data into the FIFO core. The Avalon-MM master then writes packet data to
address offset 0 repeatedly, pushing 8-bit symbols into the FIFO core. Whenever a valid write occurs at
address offset 0, the data and its respective packet information is pushed into the FIFO core. Subsequent
data is written at address offset 0 without the need to clear the SOP field. Rewriting to address offset 1 is not
required each time if the subsequent data to be pushed into the FIFO core is not the end-of-packet data, as
long as ERROR and CHANNEL do not change.
At the end of each packet, the Avalon-MM master writes to the address at offset 1 to set the EOP bit to 1,
before writing the last symbol of the packet at offset 0. The write master uses the empty field to indicate the
number of unused symbols at the end of the transfer. If the last packet data is not aligned with the symbols
per beat, the EMPTY field indicates the number of empty symbols in the last packet data. For example, if the
Avalon-ST interface has symbols per beat of 4, and the last packet only has 3 symbols, the empty field will
be 1, indicating that one symbol (the least significant symbol in the memory map) is empty.
Send Feedback
UG-01085
2017.05.08 Status Interface 15-5
S S
On -Chip FIFO
Memory
S trea ming
Input Da ta Output Da ta
SN K S
If Enable packet data is turned off, read data repeatedly at address offset 0 to pop the data from the FIFO
core.
If Enable packet data is turned on, the Avalon-MM read master starts reading from address offset 0. If the
read is valid, that is, the FIFO core is not empty, both data and packet status information are popped from
the FIFO core. The packet status information is obtained by reading at address offset 1. Reading from
address offset 1 does not pop data from the FIFO core. The ERROR, CHANNEL, SOP, EOP and EMPTY fields are
available at address offset 1 to determine the status of the packet data read from address offset 0.
The EMPTY field indicates the number of empty symbols in the data field. For example, if the Avalon-ST
interface has symbols-per-beat of 4, and the last packet data only has 1 symbol, the empty field is 3 to
indicate that 3 symbols (the 3 least significant symbols in the memory map) are empty.
Status Interface
The FIFO core provides two optional status interfaces, one for the master writing to the input interface and
a second for the read master reading from the output interface. For FIFO cores that operate in a single
domain, a single status interface is sufficient to monitor the status of the FIFO core. In the dual clocking
scheme, a second status interface using the output clock is necessary to accurately monitor the status of the
FIFO core in both clock domains.
Clocking Modes
When single-clock mode is used, the FIFO core being used is SCFIFO. When dual-clock mode is chosen,
the FIFO core being used is DCFIFO. In dual-clock mode, input data and write-side status interfaces use
the write side clock domain; the output data and read-side status interfaces use the read-side clock
domain.
Configuration
The following sections describe the available configuration options.
FIFO Settings
The following sections outline the settings that pertain to the FIFO core as a whole.
Send Feedback
UG-01085
15-6 Interface Parameters 2017.05.08
Depth
Depth indicates the depth of the FIFO buffer, in Avalon-ST beats or Avalon-MM words. The default depth
is 16. When dual clock mode is used, the actual FIFO depth is equal to depth-3. This is due to clock
crossing and to avoid FIFO overflow.
Clock Settings
The two options are Single clock mode and Dual clock mode. In Single clock mode, all interface ports
use the same clock. In Dual clock mode, input data and input side status are on the input clock domain.
Output data and output side status are on the output clock domain.
Status Port
The optional status ports are Avalon-MM slaves. To include the optional input side status interface, turn
on Create status interface for input on the Qsys MegaWizard. For FIFOs whose input and output ports
operate in separate clock domains, you can include a second status interface by turning on Create status
interface for output. Turning on Enable IRQ for status ports adds an interrupt signal to the status ports.
FIFO Implementation
This option determines if the FIFO core is built from registers or embedded memory blocks. The default is
to construct the FIFO core from embedded memory blocks.
Interface Parameters
The following sections outline the options for the input and output interfaces.
Input
Available input interfaces are Avalon-MM write slave and Avalon-ST sink.
Output
Available output interfaces are Avalon-MM read slave and Avalon-ST source.
Allow Backpressure
When Allow backpressure is on, an Avalon-MM interface includes the waitrequest signal which is
asserted to prevent a master from writing to a full FIFO buffer or reading from an empty FIFO buffer. An
Avalon-ST interface includes the ready and valid signals to prevent underflow and overflow conditions.
Send Feedback
UG-01085
2017.05.08 Software Programming Model 15-7
Software Files
Altera provides the following software files for the on-chip FIFO memory core:
altera_avalon_fifo_regs.hThis file defines the core's register map, providing symbolic
constants to access the low-level hardware.
altera_avalon_fifo_util.hThis file defines functions to access the on-chip FIFO memory
core hardware. It provides utilities to initialize the FIFO, read and write status, enable flags and read
events.
altera_avalon_fifo.hThis file provides the public interface to the on-chip FIFO memory
altera_avalon_fifo_util.cThis file implements the utilities listed in altera_avalon_
fifo_util.h.
Send Feedback
UG-01085
15-8 Software Control 2017.05.08
Software Control
The table below provides the register map for the status register. The layout of status register for the
input and output interfaces is identical.
base + 1 i_status
base + 2 event
Send Feedback
UG-01085
2017.05.08 Software Control 15-9
base + 3 interrupt
enable
base + 4 almostfull
base + 5 almostempty
The table below outlines the use of the various fields of the
status register.
Send Feedback
UG-01085
15-10 Software Control 2017.05.08
4 OVERFLOW Is set to 1 for 1 cycle every time the FIFO overflows. The FIFO overflows
when an Avalon write master writes to a full FIFO. OVERFLOW is only
valid when Allow backpressure is off.
5 UNDERFLOW Is set to 1 for 1 cycle every time the FIFO underflows. The FIFO
underflows when an Avalon read master reads from an empty FIFO.
UNDERFLOW is only valid when Allow backpressure is off.
These fields are identical to those in the status register and are set at the same time; however, these fields
are only cleared when software writes a one to clear (W1C). The event fields can be used to determine if a
particular event has occurred.
4 E_OVERFLOW Has a value of 1 if the FIFO has overflowed and the bit has not been
cleared by software.
5 E_UNDERFLOW Has a value of 1 if the FIFO has underflowed and the bit has not been
cleared by software.
The table below provides a mask for the six STATUS fields. When a bit in the event register transitions
from a zero to a one, and the corresponding bit in the interruptenable register is set, the master is
interrupted.
Send Feedback
UG-01085
2017.05.08 Software Example 15-11
Macros to access all of the registers are defined in altera_avalon_fifo_regs.h. For example, this file
includes the following macros to access the status register.
#define ALTERA_AVALON_FIFO_LEVEL_REG 0
#define ALTERA_AVALON_FIFO_STATUS_REG 1
#define ALTERA_AVALON_FIFO_EVENT_REG 2
#define ALTERA_AVALON_FIFO_IENABLE_REG 3
#define ALTERA_AVALON_FIFO_ALMOSTFULL_REG 4
#define ALTERA_AVALON_FIFO_ALMOSTEMPTY_REG 5
For a complete list of predefined macros and utilities to access the on-chip FIFO hardware, see:
<install_dir>\quartus\sopc_builder\components\altera_avalon_fifo\HAL\inc\
alatera_avalon_fifo.h and <install_dir>\quartus\sopc_builder\components\altera_avalon_fifo
\HAL\inc\
alatera_avalon_fifo_util.h.
Software Example
/***********************************************************************/
//Includes
#include "altera_avalon_fifo_regs.h"
#include "altera_avalon_fifo_util.h"
#include "system.h"
#include "sys/alt_irq.h"
#include <stdio.h>
#include <stdlib.h>
#define ALMOST_EMPTY 2
#define ALMOST_FULL OUTPUT_FIFO_OUT_FIFO_DEPTH-5
volatile int input_fifo_wrclk_irq_event;
void print_status(alt_u32 control_base_address)
{
printf("--------------------------------------\n");
printf("LEVEL = %u\n", altera_avalon_fifo_read_level(control_base_address) );
printf("STATUS = %u\n", altera_avalon_fifo_read_status(control_base_address,
ALTERA_AVALON_FIFO_STATUS_ALL) );
printf("EVENT = %u\n", altera_avalon_fifo_read_event(control_base_address,
ALTERA_AVALON_FIFO_EVENT_ALL) );
printf("IENABLE = %u\n", altera_avalon_fifo_read_ienable(control_base_address,
ALTERA_AVALON_FIFO_IENABLE_ALL) );
printf("ALMOSTEMPTY = %u\n",
altera_avalon_fifo_read_almostempty(control_base_address) );
printf("ALMOSTFULL = %u\n\n",
altera_avalon_fifo_read_almostfull(control_base_address));
}
static void handle_input_fifo_wrclk_interrupts(void* context, alt_u32 id)
{
/* Cast context to input_fifo_wrclk_irq_event's type. It is important
* to declare this volatile to avoid unwanted compiler optimization.
*/
volatile int* input_fifo_wrclk_irq_event_ptr = (volatile int*) context;
/* Store the value in the FIFO's irq history register in *context. */
Send Feedback
UG-01085
15-12 On-Chip FIFO Memory API 2017.05.08
*input_fifo_wrclk_irq_event_ptr =
altera_avalon_fifo_read_event(INPUT_FIFO_IN_CSR_BASE, ALTERA_AVALON_FIFO_EVENT_ALL);
printf("Interrupt Occurs for %#x\n", INPUT_FIFO_IN_CSR_BASE);
print_status(INPUT_FIFO_IN_CSR_BASE);
/* Reset the FIFO's IRQ History register. */
altera_avalon_fifo_clear_event(INPUT_FIFO_IN_CSR_BASE,
ALTERA_AVALON_FIFO_EVENT_ALL);
}
/* Initialize the fifo */
static int init_input_fifo_wrclk_control()
{
int return_code = ALTERA_AVALON_FIFO_OK;
/* Recast the IRQ History pointer to match the alt_irq_register() function
* prototype. */
void* input_fifo_wrclk_irq_event_ptr = (void*) &input_fifo_wrclk_irq_event;
/* Enable all interrupts. */
/* Clear event register, set enable all irq, set almostempty and
almostfull threshold */
return_code = altera_avalon_fifo_init(INPUT_FIFO_IN_CSR_BASE,
0, // Disabled interrupts
ALMOST_EMPTY,
ALMOST_FULL);
/* Register the interrupt handler. */
alt_irq_register( INPUT_FIFO_IN_CSR_IRQ,
input_fifo_wrclk_irq_event_ptr, handle_input_fifo_wrclk_interrupts );
return return_code;
}
altera_avalon_fifo_init()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
Send Feedback
UG-01085
2017.05.08 altera_avalon_fifo_read_status() 15-13
Description: Clears the event register, writes the interruptenable register, and sets the
almostfull register and almostempty registers.
altera_avalon_fifo_read_status()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
altera_avalon_fifo_read_ienable()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
Returns: Returns the logical AND of the interruptenable register and the mask.
Description: Gets the logical AND of the interruptenable register and the mask.
altera_avalon_fifo_read_almostfull()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Send Feedback
UG-01085
15-14 altera_avalon_fifo_read_almostempty() 2017.05.08
altera_avalon_fifo_read_almostempty()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
altera_avalon_fifo_read_event()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
Returns: Returns the logical AND of the event register and the mask.
Description: Gets the logical AND of the event register and the mask. To read single bits of the
event register use the single bit masks, for example: ALTERA_AVALON_FIFO_FIFO_
EVENT_F_MSK. To read the entire event register use the full mask: ALTERA_
AVALON_FIFO_EVENT_ALL.
altera_avalon_fifo_read_level()
Thread-safe: No.
Send Feedback
UG-01085
2017.05.08 altera_avalon_fifo_clear_event() 15-15
altera_avalon_fifo_clear_event()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
maskthe mask to use for bit-clearing (1 means clear this bit, 0 means do not
clear)
altera_avalon_fifo_write_ienable()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
Send Feedback
UG-01085
15-16 altera_avalon_fifo_write_almostfull() 2017.05.08
altera_avalon_fifo_write_almostfull()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
altera_avalon_fifo_write_almostempty()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: addressthe base address of the FIFO control slave
altera_avalon_write_fifo()
Thread-safe: No.
Available from No.
ISR:
Send Feedback
UG-01085
2017.05.08 altera_avalon_write_other_info() 15-17
altera_avalon_write_other_info()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: write_addressthe base address of the FIFO write slave
altera_avalon_fifo_read_fifo()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Send Feedback
UG-01085
15-18 Document Revision History 2017.05.08
Returns: Returns the data from address offset 0, or 0 if the FIFO is empty.
Description: Gets the data addressed by read_address.
R**altera_avalon_fifo_read_other_info()
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_fifo_regs.h>, <altera_avalon_fifo_utils.h>
Parameters: read_addressthe base address of the FIFO read slave
Returns: Returns the packet status information from address offset 1 of the Avalon
interface. See the Avalon Interface Specifications section for the ordering of the
packet status information.
Description: Reads the packet status information from the specified read_address. Only
valid when Enable packet data is on.
Send Feedback
2017.05.08
Avalon-ST Multi-Channel Shared Memory FIFO
Core 16
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Multi-Channel Shared Memory FIFO core is a FIFO buffer with
Avalon-ST data interfaces. The core, which supports up to 16 channels, is a contiguous memory space with
dedicated segments of memory allocated for each channel. Data is delivered to the output interface in the
same order it was received on the input interface for a given channel.
The example below shows an example of how the core is used in a system. In this example, the core is used
to buffer data going into and coming from a four-port Triple Speed Ethernet MegaCore function. A
processor, if used, can request data for a particular channel to be delivered to the Triple Speed Ethernet
MegaCore function.
Figure 16-1: Multi-Channel Shared Memory FIFO in a SystemAn Example
Altera
FPGA
Multi-Channel
Shared Memory FIFO Multi-port
(Receive FIFO buffer) Triple Speed Ethe rnet
System Interconnect Fabric
Channel 0 Port 0
Port 1
Demux
Channel 1 From
Mux
Rest of the
Network
System Channel 2 Port 2
Channel 3 Port 3
Processor/
Scheduler
Supported Devices
The Avalon-ST Multi-Channel Shared Memory FIFO core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
16-2 Performance and Resource Utilization 2017.05.08
Table 16-1: Memory Utilization and Performance Data for Stratix II GX Devices
The table below shows the resource utilization and performance data for a Stratix III device
(EP3SL340F1760C3). The performance of the MegaCore function in Stratix IV devices is similar to
Stratix III devices.
Table 16-2: Memory Utilization and Performance Data for Stratix III Devices
The table below shows the resource utilization and performance data for a Cyclone III device
(EP3C120F780I7).
Table 16-3: Memory Utilization and Performance Data for Cyclone III Devices
Channels Total Logic Total Registers Memory fMAX
Elements
M9K (MHz)
Send Feedback
UG-01085
2017.05.08 Functional Description 16-3
Functional Description
Figure 16-2: Avalon-ST Multi-Channel Shared Memory FIFO Core
in out
Avalon-ST Multi-Channel Shared FIFO Avalon-ST
Data Sink Data Source
Avalon-ST Avalon-ST
Status Source Status Source
almost_empty almost_full
Interfaces
This section describes the core's interfaces.
Avalon-ST Interfaces
The core includes Avalon-ST interfaces for transferring data and almost-full status.
Send Feedback
UG-01085
16-4 Operation 2017.05.08
Avalon-MM Interfaces
The core can have up to three Avalon-MM interfaces:
Avalon-MM control interfaceAllows master peripherals to set and access almost-full and almost-
empty thresholds. The same set of thresholds is used by all channels. See Control Interface Register
Map figure for the description of the threshold registers.
Avalon-MM fill-level interfaceAllows master peripherals to retrieve the fill level of the FIFO buffer
for a given channel. The fill level represents the amount of data in the FIFO buffer at any given time.
The read latency on this interface is one. See the Fill-level Interface Register Map table for the descrip
tion of the fill-level registers.
Avalon-MM request interfaceAllows master peripherals to request data for a given channel. This
interface is implemented only when the Use Request parameter is turned on. The request_address
signal contains the channel number. Only one word of data is returned for each request.
For more information about Avalon interfaces, refer to the Avalon Interface Specifications.
Operation
The Avalon-ST Multi-Channel Shared FIFO core allocates dedicated memory segments within the core for
each channel, and is implemented such that the memory segments occupy a single memory block. The
parameter FIFO depth determines the depth of each memory segment.
The core receives data on its in interface (Avalon-ST sink) and stores the data in the allocated memory
segments. If a packet contains any error (in_error signal is asserted), the core drops the packet.
When the core receives a request on its request interface (Avalon-MM slave), it forwards the requested
data to its out interface (Avalon-ST source) only when it has received a full packet on its in interface. If
the core has not received a full packet or has no data for the requested channel, it deasserts the valid
signal on its out interface to indicate that data is not available for the channel. The output latency is three
and only one word of data can be requested at a time.
When the Avalon-MM request interface is not in use, the request_write signal is kept asserted and the
request_address signal is set to 0. Hence, if you configure the core to support more than one channel,
you must also ensure that the Use request parameter is turned on. Otherwise, only channel 0 is accessible.
You can configure almost-full thresholds to manage FIFO overflow. The current threshold status for each
channel is available from the core's Avalon-ST status interfaces in a round-robin fashion. For example, if
the threshold status for channel 0 is available on the interface in clock cycle n, the threshold status for
channel 1 is available in clock cycle n+1 and so forth.
Parameters
Send Feedback
UG-01085
2017.05.08 Parameters 16-5
Send Feedback
UG-01085
16-6 Software Programming Model 2017.05.08
Register Map
You can configure the thresholds and retrieve the fill-level for each channel via the Avalon-MM control
and fill-level interfaces respectively. Subsequent sections describe the registers accessible via each interface.
Send Feedback
UG-01085
2017.05.08 Register Map 16-7
Send Feedback
UG-01085
16-8 Document Revision History 2017.05.08
Table 16-8: Avalon-ST Multi-Channel Shared Memory FIFO Core Revision History
Date Version Changes
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 Added the description of almost-empty thresholds and fill-level
registers. Revised the Operation section.
November 2009 v9.1.0 No change from previous release.
Send Feedback
2017.05.08
SPI Slave/JTAG to Avalon Master Bridge Cores
17
UG-01085 Subscribe Send Feedback
Core Overview
The SPI Slave to Avalon Master Bridge and the JTAG to Avalon Master Bridge cores provide a connection
between host systems and Qsys systems via the respective physical interfaces. Host systems can initiate
Avalon Memory-Mapped (Avalon-MM) transactions by sending encoded streams of bytes via the cores
physical interfaces. The cores support reads and writes, but not burst transactions.
Functional Description
Figure 17-1: System with a SPI Slave to Avalon Master Bridge Core
Altera FPGA
Bytes to
src
src
ter
Packets
Avalon-MM Mas
Packets to
sink
src
src
Bytes
Converter
SPI System
Clock Clock
Avalon-ST Avalon-ST
sink
src
Source Sink
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
17-2 Functional Description 2017.05.08
Altera FPGA
JTAG toTransaction Bridge
Avalon-ST Avalon-ST
sink
Single Clock
sink
src
src
src
FIFO Packets
(64 bytes) Converter
Avalon-MM
Avalon-ST Avalon-ST Rest of the
JTAG Packets to System
JTAG
Host Interface Transactions
PC Core Converter
Avalon-ST
sink
Packets to
sink
src
src
Bytes
Converter
JTAG System
Clock Clock
Avalon-ST Avalon-ST
sink
src
Source Sink
The SPI Slave to Avalon Master Bridge and the JTAG to Avalon Master Bridge cores accept encoded
streams of bytes with transaction data on their respective physical interfaces and initiate Avalon-MM
transactions on their Avalon-MM interfaces. Each bridge consists of the following cores, which are
available as stand-alone components in Qsys:
Avalon-ST Serial Peripheral Interface and Avalon-ST JTAG InterfaceAccepts incoming data in bits
and packs them into bytes.
Avalon-ST Bytes to Packets ConverterTransforms packets into encoded stream of bytes, and a
likewise encoded stream of bytes into packets.
Avalon-ST Packets to Transactions ConverterTransforms packets with data encoded according to a
specific protocol into Avalon-MM transactions, and encodes the responses into packets using the same
protocol.
Avalon-ST Single Clock FIFOBuffers data from the Avalon-ST JTAG Interface core. The FIFO is
only used in the JTAG to Avalon Master Bridge.
For the bridges to successfully transform the incoming streams of bytes to Avalon-MM transactions,
the streams of bytes must be constructed according to the protocols used by the cores.
The following example shows how a bytestream changes as it is transferred through the different layers
in the bridges.
Send Feedback
UG-01085
2017.05.08 Parameters 17-3
LSB MSB
4A 7A 7C 4A 00 00 00 4A 00 04 02 4B 7D 5A 40 4D 6A FF 03 7B 5F Bytes carried over
the physical interface
after idles and escapes
Idle Idle Idle Escape have been inserted.
Physical Layer
Input: Bits Escape is dropped.
Output: Bytes Next byte is XORed
Dropped with 0x20.
00 00 00 04 ... 02 4B 7A 40 4A FF 03 5F
The transaction
encapsulated as a
packet.
Transaction Layer
Input: Avalon-ST
Command Address Data
Packets
Output: Avalon-MM The Avalon-MM
Transaction Writes four bytes of data (4A, FF, 03 and
5F) to address 0x024B7A40 transaction.
When the transaction is complete, the bridges send a response to the host system using the same protocol.
Figure 17-4: Bits to Avalon-MM Transaction (Read)
LSB MSB
4A 7A 7C 4A 00 00 00 4A 00 04 02 4B 7D 5A 40 4D 6A FF 03 7B 5F Bytes carried over
the physical interface
after idles and escapes
Idle Idle Idle Escape have been inserted.
Physical Layer
Input: Bits Escape is dropped.
Output: Bytes Next byte is XORed
Dropped with 0x20.
10 00 00 04 ... 02 4B 7A 40 4A FF 03 5F
The transaction
encapsulated as a
packet.
Transaction Layer
Input: Avalon-ST
Command Address Data
Packets
Output: Avalon-MM The Avalon-MM
Transaction Reads four bytes of data (4A, FF, 03 and
5F) to address 0x024B7A40 transaction.
Parameters
For the SPI Slave to Avalon Master Bridge core, the parameter Number of synchronizer stages: Depth
allows you to specify the length of synchronization register chains. These register chains are used when a
Send Feedback
UG-01085
17-4 Document Revision History 2017.05.08
metastable event is likely to occur and the length specified determines the meantime before failure. The
register chain length, however, affects the latency of the core.
For more information on metastability in Altera devices, refer to AN 42: Metastability in Altera Devices.
For more information on metastability analysis and synchronization register chains, refer to the Area and
Timing Optimization chapter in volume 2 of the Quartus Prime Handbook.
Table 17-1: SPI Slave/JTAG to Avalon Master Bridge Cores Revision History
Date Version Changes
May 2017 2017.05.08 Read operation added: Figure 17-4
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 No change from previous release.
Send Feedback
2017.05.08
Avalon Streaming Channel Multiplexer and
Demultiplexer Cores 18
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon streaming (Avalon-ST) channel multiplexer core receives data from a number of input
interfaces and multiplexes the data into a single output interface, using the optional channel signal to
indicate which input the output data is from. The Avalon-ST channel demultiplexer core receives data
from a channelized input interface and drives that data to multiple output interfaces, where the output
interface is selected by the input channel signal.
The multiplexer and demultiplexer can transfer data between interfaces on cores that support the unidirec
tional flow of data. The multiplexer and demultiplexer allow you to create multiplexed or de-multiplexer
datapaths without having to write custom HDL code to perform these functions. The multiplexer includes
a round-robin scheduler. Both cores are SOPC Builder-ready and integrate easily into any SOPC Builder-
generated system. This chapter contains the following sections:
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
18-2 Supported Devices 2017.05.08
Stratix II and Cyclone II Stratix
Stratix II GX
Schedulin
No. of Data (Approximate LEs)
g Size
Inputs Width
(Cycles) fMAX ALM fMAX Logic fMAX Logic Cells
Cells
(MHz) Count (MHz) (MHz)
The core operating frequency varies with the device, the number of interfaces and the size of the datapath.
Supported Devices
The Avalon Streaming Channel Multiplexer and Demultiplexer cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Multiplexer
This section describes the hardware structure and functionality of the multiplexer component.
Send Feedback
UG-01085
2017.05.08 Functional Description 18-3
Functional Description
The Avalon-ST multiplexer takes data from a number of input data interfaces, and multiplexes the data
onto a single output interface. The multiplexer includes a simple, round-robin scheduler that selects from
the next input interface that has data. Each input interface has the same width as the output interface, so
that all other input interfaces are backpressured when the multiplexer is carrying data from a different
input interface.
The multiplexer includes an optional channel signal that enables each input interface to carry channelized
data. When the channel signal is present on input interfaces, the multiplexer adds log2
(num_input_interfaces) bits to make the output channel signal, such that the output channel signal has all
of the bits of the input channel plus the bits required to indicate which input interface each cycle of data is
from. These bits are appended to either the most or least significant bits of the output channel signal as
specified in the SOPC Builder MegaWizard interface.
da ta _in0
s ink
...
...
da ta _o ut
sr c
s ink s ink
da ta_ in_n
s ink
The internal scheduler considers one input interface at a time, selecting it for transfer. Once an input
interface has been selected, data from that input interface is sent until one of the following scenarios
occurs:
The specified number of cycles have elapsed.
The input interface has no more data to send and valid is deasserted on a ready cycle.
When packets are supported, endofpacket is asserted.
Input Interfaces
Each input interface is an Avalon-ST data interface that optionally supports packets. The input interfaces
are identical; they have the same symbol and data widths, error widths, and channel widths.
Output Interface
The output interface carries the multiplexed data stream with data from all of the inputs. The symbol, data,
and error widths are the same as the input interfaces. The width of the channel signal is the same as the
input interfaces, with the addition of the bits needed to indicate the input each datum was from.
Parameters
The following sections list the available options in the MegaWizard interface.
Send Feedback
UG-01085
18-4 Demultiplexer 2017.05.08
Functional Parameters
You can configure the following options for the multiplexer:
Number of Input PortsThe number of input interfaces that the multiplexer supports. Valid values
are 216.
Scheduling Size (Cycles)The number of cycles that are sent from a single channel before changing to
the next channel.
Use Packet SchedulingWhen this option is on, the multiplexer only switches the selected input
interface on packet boundaries. Hence, packets on the output interface are not interleaved.
Use high bits to indicate source portWhen this option is on, the high bits of the output channel
signal are used to indicate the input interface that the data came from. For example, if the input
interfaces have 4-bit channel signals, and the multiplexer has 4 input interfaces, the output interface has
a 6-bit channel signal. If this parameter is true, bits [5:4] of the output channel signal indicate the input
interface the data is from, and bits [3:0] are the channel bits that were presented at the input interface.
Output Interface
You can configure the following options for the output interface:
Data Bits Per SymbolThe number of bits per symbol for the input and output interfaces. Valid values
are 132 bits.
Data Symbols Per BeatThe number of symbols (words) that are transferred per beat (transfer). Valid
values are 132.
Include Packet SupportIndicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
Channel Signal Width (bits)The number of bits used for the channel signal for input interfaces. A
value of 0 indicates that input interfaces do not have channels. A value of 4 indicates that up to 16
channels share the same input interface. The input channel can have a width between 031 bits. A value
of 0 means that the optional channel signal is not used.
Error Signal Width (bits)The width of the error signal for input and output interfaces. A value of 0
means the error signal is not used.
Demultiplexer
This section describes the hardware structure and functionality of the demultiplexer component.
Functional Description
That Avalon-ST demultiplexer takes data from a channelized input data interface and provides that data to
multiple output interfaces, where the output interface selected for a particular transfer is specified by the
input channel signal. The data is delivered to the output interfaces in the same order it was received at the
input interface, regardless of the value of channel, packet, frame, or any other signal. Each of the output
interfaces has the same width as the input interface, so each output interface is idle when the demultiplexer
is driving data to a different output interface. The demultiplexer uses log2 (num_output_interfaces) bits of
the channel signal to select the output to which to forward the data; the remainder of the channel bits are
forwarded to the appropriate output interface unchanged.
Send Feedback
UG-01085
2017.05.08 Parameters 18-5
da ta _ou t0
sr c
...
...
data_in
s ink
s ink s ink
da ta _ou t_n
sr c
cha nne l
Input Interface
Each input interface is an Avalon-ST data interface that optionally supports packets.
Output Interfaces
Each output interface carries data from a subset of channels from the input interface. Each output
interface is identical; all have the same symbol and data widths, error widths, and channel widths. The
symbol, data, and error widths are the same as the input interface. The width of the channel signal is the
same as the input interface, without the bits that were used to select the output interface.
Parameters
The following sections list the available options in the MegaWizard Interface.
Functional Parameters
You can configure the following options for the demultiplexer as a whole:
Number of Output PortsThe number of output interfaces that the multiplexer supports Valid values
are 216.
High channel bits select outputWhen this option is on, the high bits of the input channel signal are
used by the de-multiplexing function and the low order bits are passed to the output. When this option
is off, the low order bits are used and the high order bits are passed through.
The following example illustrates the significance of the location of these signals. In the Select Bits for
Demltiplexer figure below there is one input interface and two output interfaces. If the low-order bits
of the channel signal select the output interfaces, the even channels goes to channel 0 and the odd
channels goes to channel 1. If the high-order bits of the channel signal select the output interface,
channels 07 goes to channel 0 and channels 815 goes to channel 1.
Send Feedback
UG-01085
18-6 Hardware Simulation Considerations 2017.05.08
s ink
dat a _ou t0
s rc cha nne l<3..0>
da ta _in
cha nne l<4. .0> s ink s ink
da ta _out1
s rc cha nne l<3..0>
Input Interface
You can configure the following options for the input interface:
Data Bits Per SymbolThe number of bits per symbol for the input and output interfaces. Valid values
are 1 to 32 bits.
Data Symbols Per BeatThe number of symbols (words) that are transferred per beat (transfer). Valid
values are 1 to 32.
Include Packet SupportIndicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
Channel Signal Width (bits)The number of bits used for the channel signal for output interfaces. A
value of 0 means that output interfaces do not use the optional channel signal.
Error Signal Width (bits)The width of the error signal for input and output interfaces. A value of 0
means the error signal is not unused.
Send Feedback
UG-01085
2017.05.08 Document Revision History 18-7
Table 18-3: Avalon Streaming Channel Multiplexer and Demultiplexer Cores Revision History
Date Version Changes
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. Added parameter Include Packet
Support.
May 2008 v8.0.0 No change from previous release.
Send Feedback
2017.05.08
Avalon-ST Bytes to Packets and Packets to
Bytes Converter Cores 19
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Bytes to Packets and Packets to Bytes Converter cores allow an
arbitrary stream of packets to be carried over a byte interface, by encoding packet-related control signals
such as startofpacket and endofpacket into byte sequences.The Avalon-ST Packets to Bytes Converter
core encodes packet control and payload as a stream of bytes. The Avalon-ST Bytes to Packets Converter
core accepts an encoded stream of bytes, and converts it into a stream of packets.
The SPI Slave to Avalon Master Bridge and JTAG to Avalon Master Bridge are examples of how the cores
are used.
For more information about the bridge, refer to Avalon-ST Bytes to Packets and Packets to Bytes
Converter Cores
Supported Devices
The Avalon-ST Bytes to Packets and Packets to Bytes cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The following two figures show block diagrams of the Avalon-ST Bytes to Packets and Packets to Bytes
Converter cores.
Figure 19-1: Avalon-ST Bytes to Packets Converter Core
Avalon-ST
Avalon-ST
(packet)
Sink
(bytes)
Bytes toPackets
Converter
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
19-2 Interfaces 2017.05.08
Avalon-ST
Avalon-ST
data_out data_in
Avalon-ST
Source
(bytes) (packet)
Sink
Packets to Bytes
Converter
Interfaces
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specifications.
Altera Corporation Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores
Send Feedback
UG-01085
2017.05.08 OperationAvalon-ST Packets to Bytes Converter Core 19-3
0x7c 0x01 0x7a 0x7d 0x5 a 0x0 1 ... 0xff 0x7b 0x3a
Ch ann e l 2 SO P EOP Da ta
byte
0x7c 0x00 0x7a 0x10 0x1 1 0x7 c 0x0 1 0x3 0 0x3 1 0x7 c 0x00 0x12 0x13 0x7b 0x14
Table 19-2: Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores Revision History
Date Version Changes
November 2015 2015.11.06 Updated "Operation-Avalon-ST Bytes to
Packets Converter Core" section.
July 2014 2014.07.24 Removed mention of SOPC Builder,
updated to Qsys.
December 2010 v10.1.0 Removed the Device Support, Instanti
ating the Core in SOPC Builder, and
Referenced Documents sections.
Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores Altera Corporation
Send Feedback
UG-01085
19-4 Document Revision History 2017.05.08
Altera Corporation Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores
Send Feedback
2017.05.08
Avalon Packets to Transactions Converter Core
20
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Packets to Transactions Converter core receives streaming data from upstream components
and initiates Avalon Memory-Mapped (Avalon-MM) transactions. The core then returns Avalon-MM
transaction responses to the requesting components.
The SPI Slave to Avalon Master Bridge and JTAG to Avalon Master Bridge are examples of how this core is
used.
For more information on the bridge, refer to Avalon Packets to Transactions Converter Core
Supported Devices
The Avalon Packets to Transactions Converter core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Figure 20-1: Avalon Packets to Transactions Converter Core
Avalon-ST
Sink
data_in
Avalon-MM Mas te r
Avalon
Packets to Avalon-MM
Transactions Slave
Converter Component
Avalon-ST
Source
data_out
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
20-2 Interfaces 2017.05.08
Interfaces
The Avalon-MM master interface supports read and write transactions. The data width is set to 32 bits and
burst transactions are not supported.
For more information about Avalon-ST interfaces, refer to Avalon Interface Specifications.
Operation
The Avalon Packets to Transactions Converter core receives streams of packets on its Avalon-ST sink
interface and initiates Avalon-MM transactions. Upon receiving transaction responses from Avalon-MM
slaves, the core transforms the responses to packets and returns them to the requesting components via its
Avalon-ST source interface. The core does not report Avalon-ST errors.
Packet Formats
The core expects incoming data streams to be in the format shown in the table below. A response packet is
returned for every write transaction. The core also returns a response packet if a no transaction (0x7f) is
received. An invalid transaction code is regarded as a no transaction. For read transactions, the core
simply returns the data read.
Send Feedback
UG-01085
2017.05.08 Operation 20-3
Supported Transactions
The table below lists the Avalon-MM transactions supported by the core.
The core can handle only a single transaction at a time. The ready signal on the core's Avalon-ST sink
interface is asserted only when the current transaction is completely processed.
No internal buffer is implemented on the data paths. Data received on the Avalon-ST interface is
forwarded directly to the Avalon-MM interface and vice-versa. Asserting the waitrequest signal on the
Avalon-MM interface backpressures the Avalon-ST sink interface. In the opposite direction, if the Avalon-
ST source interface is backpressured, the read signal on the Avalon-MM interface is not asserted until the
backpressure is alleviated. Backpressuring the Avalon-ST source in the middle of a read could result in
data loss. In such cases, the core returns the data that is successfully received.
A transaction is considered complete when the core receives an EOP. For write transactions, the actual
data size is expected to be the same as the value of the size field. Whether or not both values agree, the
core always uses the EOP to determine the end of data.
Malformed Packets
The following are examples of malformed packets:
Consecutive start of packet (SOP)An SOP marks the beginning of a transaction. If an SOP is
received in the middle of a transaction, the core drops the current transaction without returning a
response packet for the transaction, and initiates a new transaction. This effectively handles packets
without an end of packet(EOP).
Unsupported transaction codesThe core treats unsupported transactions as a no transaction.
Send Feedback
UG-01085
20-4 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Avalon-ST Round Robin Scheduler Core
21
UG-01085 Subscribe Send Feedback
Core Overview
Avalon Streaming (Avalon-ST) components in SOPC Builder provide a channel interface to stream data
from multiple channels into a single component. In a multi-channel Avalon-ST component that stores
data, the component can store data either in the sequence that it comes in (FIFO) or in segments
according to the channel. When data is stored in segments according to channels, a scheduler is needed to
schedule the read operations from that particular component. The most basic of the schedulers is the
Avalon-ST Round Robin Scheduler core.
The Avalon-ST Round Robin Scheduler core is SOPC Builder-ready and can integrate easily into any
SOPC Builder-generated systems.
Supported Devices
The Avalon-ST Round Robin Scheduler core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
estimates are obtained by compiling the core using the Quartus Prime software.
The table below shows the resource utilization and performance data for a Stratix II GX device
(EP2SGX130GF1508I4).
Table 21-1: Resource Utilization and Performance Data for Stratix II GX Devices
Number of ALUTs Logic Registers Memory M512/ fMAX
Channels M4K/
(MHz)
M-RAM
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
21-2 Functional Description 2017.05.08
The table below shows the resource utilization and performance data for a Stratix III device
(EP3SL340F1760C3). The performance of the MegaCore function in Stratix IV devices is similar to
Stratix III devices.
Table 21-2: Resource Utilization and Performance Data for Stratix III Devices
Number of ALUTs Logic Registers Memory M9K/ fMAX
Channels M144K/ MLAB
(MHz)
The table below shows the resource utilization and performance data for a Cyclone III device
(EP3C120F780I7).
Table 21-3: Resource Utilization and Performance Data for Cyclone III Devices
Number of Total Logic Total Registers Memory M9K fMAX
Channels Elements
(MHz)
4 12 7 0 > 125
12 32 17 0 > 125
24 71 30 0 > 125
Functional Description
The Avalon-ST Round Robin Scheduler core controls the read operations from a multi-channel Avalon-ST
component that buffers data by channels. It reads the almost-full threshold values from the multiple
channels in the multi-channel component and issues the read request to the Avalon-ST source according
to a round-robin scheduling algorithm.
Send Feedback
UG-01085
2017.05.08 Interfaces 21-3
Avalon-ST Sink
Write Master
Request
Avalon-MM
Avalon-ST
(Channel_select) Round-Robin Almost Full Status
Scheduler
Interfaces
The following interfaces are available in the Avalon-ST Round Robin Scheduler core:
Almost-Full Status Interface
Request Interface
The interface collects the almost-full status from the sink components for all the channels in the sequence
provided.
Request Interface
The Request Interface is an Avalon Memory-Mapped (MM) Write Master interface. This interface requests
data from a specific channel. The Avalon-ST Round Robin Scheduler core cycles through all of the
channels it supports and schedules data to be read.
Operations
If a particular channel is almost full, the Avalon-ST Round Robin Scheduler will not schedule data to be
read from that channel in the source component.
Send Feedback
UG-01085
21-4 Operations 2017.05.08
The Avalon-ST Round Robin Scheduler only requests 1 beat of data from a channel at each transaction. To
request 1 beat of data from channel n, the scheduler writes the value 1 to address (4 n). For example, if
the scheduler is requesting data from channel 3, the scheduler writes 1 to address 0xC.
At every clock cycle, the Avalon-ST Round Robin Scheduler requests data from the next channel.
Therefore, if the Avalon-ST Round Robin Scheduler starts requesting from channel 1, at the next clock
cycle, it requests from channel 2. The Avalon-ST Round Robin Scheduler does not request data from a
particular channel if the almost-full status for the channel is asserted. In this case, one clock cycle is used
without a request transaction.
The Avalon-ST Round Robin Scheduler cannot determine if the requested component is able to service the
request transaction. The component asserts waitrequest when it cannot accept new requests.
request_waitrequest In Wait request signal, used to pause the scheduler when the
slave cannot accept a new request.
Avalon-ST Almost-Full Status Interface
almost_full_valid In Indicates that almost_full_channel and almost_full_
data are valid.
almost_full_data (log2 In A 1-bit signal that is asserted high to indicate that the
Max_Channels1:0) channel indicated by almost_full_channel is almost
full.
Send Feedback
UG-01085
2017.05.08 Parameters 21-5
Parameters
Send Feedback
2017.05.08
Avalon-ST Delay Core
22
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Delay core provides a solution to delay Avalon-ST transactions by a
constant number of clock cycles. This core supports up to 16 clock cycle delays.
The Avalon-ST Delay core is SOPC Builder-ready and integrates easily into any SOPC Builder-generated
system.
Supported Devices
The Avalon-ST Delay core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Figure 22-1: Avalon-ST Delay Core
Avalon-ST Sink
Avalon-ST Source
In_Data
Out_Data
Avalon-ST
Delay Core
Clock
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
22-2 Reset 2017.05.08
The Avalon-ST Delay core adds a delay between the input and output interfaces. The core accepts all
transactions presented on the input interface and reproduces them on the output interface N cycles later
without changing the transaction.
The input interface delays the input signals by a constant (N) number of clock cycles to the corresponding
output signals of the Avalon-ST output interface. The Number Of Delay Clocks parameter defines the
constant (N) number, which must be between 0 and 16. The change of the In_Valid signal is reflected on
the Out_Valid signal exactly N cycles later.
Reset
The Avalon-ST Delay core has a reset signal that is synchronous to the clk signal. When the core asserts
the reset signal, the output signals are held at 0. After the reset signal is deasserted, the output signals
are held at 0 for N clock cycles. The delayed values of the input signals are then reflected at the output
signals after N clock cycles.
Interfaces
The Avalon-ST Delay core supports packetized and non-packetized interfaces with optional channel and
error signals. This core does not support backpressure.
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specifications.
Parameters
Send Feedback
UG-01085
2017.05.08 Parameters 22-3
Send Feedback
UG-01085
22-4 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Avalon-ST Splitter Core
23
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Streaming (Avalon-ST) Splitter core allows you to replicate transactions from an Avalon-ST
source interface to multiple Avalon-ST sink interfaces. This core can support from 1 to 16 outputs.
The Avalon-ST Splitter core is SOPC Builder-ready and integrates easily into any SOPC Builder-generated
system.
Supported Devices
The Avalon-ST Splitter core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Figure 23-1: Avalon-ST Splitter Core
Avalon-ST
Source 0
Output 0
Avalon-ST Sink
In_Data
Avalon-ST
Splitter Core Out_Data
Avalon-ST
Source N
Clock
Output N
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
23-2 Backpressure 2017.05.08
The Avalon-ST Splitter core copies all input signals from the input interface to the corresponding output
signals of each output interface without altering the size or functionality. This include all signals except for
the ready signal.
The Avalon-ST Splitter core includes a clock signal used by SOPC Builder to determine the Avalon-ST
interface and clock domain that this core resides in. Because the clock signal is unused internally, no
latency is introduced when using this core.
Backpressure
The Avalon-ST Splitter core handles backpressure by AND-ing the ready signals from all of the output
interfaces and sending the result to the input interface. This way, if any output interface deasserts the
ready signal, the input interface receives the deasserted ready signal as well. This mechanism ensures that
backpressure on any of the output interfaces is propagated to the input interface.
When the Qualify Valid Out parameter is set to 1, the Out_Valid signals on all other output interfaces are
gated when backpressure is applied from one output interface. In this case, when any output interface
deasserts its ready signal, the Out_Valid signals on the rest of the output interfaces are deasserted as well.
When the Qualify Valid Out parameter is set to 0, the output interfaces have a non-gated Out_Valid
signal when backpressure is applied. In this case, when an output interface deasserts its ready signal, the
Out_Valid signals on the rest of the output interfaces are not affected.
Interfaces
The Avalon-ST Splitter core supports packetized and non-packetized interfaces with optional channel and
error signals. The core propagates backpressure from any output interface to the input interface.
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specifications.
Send Feedback
UG-01085
2017.05.08 Parameters 23-3
Parameters
Send Feedback
UG-01085
23-4 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Scatter-Gather DMA Controller Core
24
UG-01085 Subscribe Send Feedback
Core Overview
The Scatter-Gather Direct Memory Access (SG-DMA) controller core implements high-speed data
transfer between two components. You can use the SG-DMA controller core to transfer data from:
Memory to memory
Data stream to memory
Memory to data stream
The SG-DMA controller core transfers and merges non-contiguous memory to a continuous address
space, and vice versa. The core reads a series of descriptors that specify the data to be transferred.
For applications requiring more than one DMA channel, multiple instantiations of the core can provide
the required throughput. Each SG-DMA controller has its own series of descriptors specifying the data
transfers. A single software module controls all of the DMA channels.
For the Nios II processor, device drivers are provided in the Hardware Abstraction Layer (HAL)
system library, allowing software to access the core using the provided driver.
Example Systems
The block diagram below shows a SG-DMA controller core for the DMA subsystem of a printed circuit
board. The SG-DMA core in the FPGA reads streaming data from an internal streaming component and
writes data to an external memory. A Nios II processor provides overall system control.
Figure 24-1: SG-DMA Controller Core with Streaming Peripheral and External Memory
Altera FPGA
S OPC Builde r Syste m
Sc a tter Ga ther DMA Control ler Core
Co ntrol
Des c ripto r
& DMA Write
Proce s sor
S tatus Block
Blo c k
Registe rs
Rd Wr Wr Rd
S M M
M M SN K
DDR2
S DRAM
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
24-2 Comparison of SG-DMA Controller Core and DMA Controller Core 2017.05.08
The figure below shows a different use of the SG-DMA controller core, where the core transfers data
between an internal and external memory. The host processor and memory are connected to a system bus,
typically either a PCI Express or Serial RapidIO.
Figure 24-2: SG-DMA Controller Core with Internal and External Memory
Altera FP GA
S OP C Builde r Syste m
S ca tte r Ga the r DMA Controlle r Core
Con trol
De s c ripto r DMA Re ad/
&
Pro ce s sor Write
Stat us
Block Blo ck
Reg iste rs
Rd Wr Wr Rd
Internal
Memo ry
S S M M M M M M
Supported Devices
The Scatter Gather DMA Controller core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Send Feedback
UG-01085
2017.05.08 Functional Description 24-3
The core operating frequency varies with the device and the size of the datapath. The table below provides
an example of expected performance for SG-DMA cores instantiated in several different device families.
Functional Description
The SG-DMA controller core comprises three major blocks: descriptor processor, DMA read, and DMA
write. These blocks are combined to create three different configurations:
Memory to memory
Memory to stream
Stream to memory
The type of devices you are transferring data to and from determines the configuration to implement.
Examples of memory-mapped devices are PCI, PCIe and most memory devices. The Triple Speed
Ethernet MAC, DSP MegaCore functions and many video IPs are examples of streaming devices. A
recompilation is necessary each time you change the configuration of the SG-DMA controller core.
Send Feedback
UG-01085
24-4 Functional Blocks and Configurations 2017.05.08
Descriptor Processor
The descriptor processor reads descriptors from the descriptor list via its Avalon Memory-Mapped (MM)
read master port and pushes commands into the command FIFOs of the DMA read and write blocks.
Each command includes the following fields to specify a transfer:
Source address
Destination address
Number of bytes to transfer
Increment read address after each transfer
Increment write address after each transfer
Generate start of packet (SOP) and end of packet (EOP)
After each command is processed by the DMA read or write block, a status token containing informa
tion about the transfer such as the number of bytes actually written is returned to the descriptor
processor, where it is written to the respective fields in the descriptor.
Memory-to-Memory Configuration
Memory-to-memory configurations include all three blocks: descriptor processor, DMA read, and DMA
write. An internal FIFO is also included to provide buffering and flow control for data transferred between
the DMA read and write blocks.
The example below illustrates one possible memory-to-memory configuration with an internal Nios II
processor and descriptor list.
Send Feedback
UG-01085
2017.05.08 Functional Blocks and Configurations 24-5
Alte ra FPG A
S O PC Builder S ys te m
S ca tte r G a th er DMA C on trolle r C ore
DMA Write B lo c k
SN K
De s c rip to r c o m m an d
Con tro l P ro c e ss o r
st atu s
& B lo c k Data
S tatu s st atu s FIFO
Re g ist e rs c o m m an d
SR C
DMA Re ad B lo c k
Wr Rd
S M M M M
S Avalo n- MM S la ve P ort
Me m o ry
Me m o ry Nio s II
Con tro lle r De s criptor Pro c es s o r S RC Avalo n- S T S our ce P or t
Ta ble
DD R2
SDRA M
Memory-to-Stream Configuration
Memory-to-stream configurations include the descriptor processor and DMA read blocks.
In this example, the Nios II processor and descriptor table are in the FPGA. Data from an external DDR2
SDRAM is read by the SG-DMA controller and written to an on-chip streaming peripheral.
Figure 24-4: Example of Memory-to-Stream Configuration
Altera FP GA
S OPC Builder S yste m
Wr Rd
S M M M SR C
DDR2
SDR AM
Stream-to-Memory Configuration
Stream-to-memory configurations include the descriptor processor and DMA write blocks. This configu
ration is similar to the memory-to-stream configuration as the figure below illustrates.
Send Feedback
UG-01085
24-6 DMA Descriptors 2017.05.08
Alte ra FPG A
SO P C Builde r Syst em
S ca tte r Ga the r DMA Con trolle r Core
De s c riptor
Con trol Proc e s s or c omma nd
& Block
Sta tus st atus DMA Write Blo c k
Re gi s ters
S RC
Wr Rd
S M M M SN K
Memo ry
Memo ry Nios II SR C
S NK Ava lon-S T S ink P ort
Con trolle r De s criptor Pro c e s s or S tre aming
Ta ble Compon e nt
S RC Ava lon -S T So urce Port
DDR2
S DRAM
DMA Descriptors
DMA descriptors specify data transfers to be performed. The SG-DMA core uses a dedicated interface to
read and write the descriptors. These descriptors, which are stored as a linked list, can be stored on an on-
chip or off-chip memory and can be arbitrarily long.
Storing the descriptor list in an external memory frees up resources in the FPGA; however, an external
descriptor list increases the overhead involved when the descriptor processor reads and updates the list.
The SG-DMA core has an internal FIFO to store descriptors read from memory, which allows the core to
perform descriptor read, execute, and write back operations in parallel, hiding the descriptor access and
processing overhead.
The descriptors must be initialized and aligned on a 32-bit boundary. The last descriptor in the list must
have its OWNED_BY_HW bit set to 0 because the core relies on a cleared OWNED_BY_HW bit to stop processing.
See the DMA Descriptors section for the structure of the DMA descriptor.
Descriptor Processing
The following steps describe how the DMA descriptors are processed:
1. Software builds the descriptor linked list. See the Building and Updating Descriptors List section for
more information on how to build and update the descriptor linked list.
2. Software writes the address of the first descriptor to the next_descriptor_pointer register and
initiates the transfer by setting the RUN bit in the control register to 1. See the Software Programming
Model section for more information on the registers.
On the next clock cycle following the assertion of the RUN bit, the core sets the BUSY bit in the status
register to 1 to indicate that descriptor processing is executing.
3. The descriptor processor block reads the address of the first descriptor from the
next_descriptor_pointer register and pushes the retrieved descriptor into the command FIFO,
which feeds commands to both the DMA read and write blocks. As soon as the first descriptor is read,
the block reads the next descriptor and pushes it into the command FIFO. One descriptor is always
read in advance thus maximizing throughput.
4. The core performs the data transfer.
Send Feedback
UG-01085
2017.05.08 Error Conditions 24-7
In memory-to-memory configurations, the DMA read block receives the source address from its
command FIFO and starts reading data to fill the FIFO on its stream port until the specified
number of bytes are transferred. The DMA read block pauses when the FIFO is full until the FIFO
has enough space to accept more data.
The DMA write block gets the destination address from its command FIFO and starts writing until
the specified number of bytes are transferred. If the data FIFO ever empties, the write block pauses
until the FIFO has more data to write.
In memory-to-stream configurations, the DMA read block reads from the source address and
transfers the data to the cores streaming port until the specified number of bytes are transferred or
the end of packet is reached. The block uses the end-of-packet indicator for transfers with an
unknown transfer size. For data transfers without using the end-of-packet indicator, the transfer
size must be a multiple of the data width. Otherwise, the block requires extra logic and may impact
the system performance.
In stream-to-memory configurations, the DMA write block reads from the cores streaming port
and writes to the destination address. The block continues reading until the specified number of
bytes are transferred.
5. The descriptor processor block receives a status from the DMA read or write block and updates the
DESC_CONTROL, DESC_STATUS, and ACTUAL_BYTES_TRANSFERRED fields in the descriptor. The
OWNED_BY_HW bit in the DESC_CONTROL field is cleared unless the PARK bit is set to 1.
Once the core starts processing the descriptors, software must not update descriptors with
OWNED_BY_HW bit set to 1. It is only safe for software to update a descriptor when its OWNED_BY_HW bit is
cleared.
The SG-DMA core continues processing the descriptors until an error condition occurs and the
STOP_DMA_ER bit is set to 1, or a descriptor with a cleared OWNED_BY_HW bit is encountered.
Error Conditions
The SG-DMA core has a configurable error width. Error signals are connected directly to the Avalon-ST
source or sink to which the SG-DMA core is connected.
Send Feedback
UG-01085
24-8 Error Conditions 2017.05.08
The list below describes how the error signals in the SG-DMA core are implemented in the folowing
configurations:
Memory-to-memory configuration
No error signals are generated. The error field in the register and descriptor is hardcoded to 0.
Memory-to-stream configuration
If you specified the usage of error bits in the core, the error bits are generated in the Avalon-ST source
interface. These error bits are hardcoded to 0 and generated in compliance with the Avalon-ST slave
interfaces.
Stream-to-memory configuration
If you specified the usage of error bits in the core, error bits are generated in the Avalon-ST sink
interface. These error bits are passed from the Avalon-ST sink interface and stored in the registers and
descriptor.
The table below lists the error signals when the core is operating in the memory-to-stream configura
tion and connected to the transmit FIFO interface of the Altera Triple-Speed Ethernet MegaCore
function.
The table below lists the error signals when the core is operating in the stream-to-memory configura
tion and connected to the transmit FIFO interface of the Triple-Speed Ethernet MegaCore function.
Each streaming core has a different set of error codes. Refer to the respective user guides for the codes.
Send Feedback
UG-01085
2017.05.08 Parameters 24-9
Parameters
Enable burst On/Off Turning on this option enables burst reads and writes.
transfers
Read burstcount 116 The width of the read burstcount signal. This value determines
signal width the maximum burst read size.
Write burstcount 116 The width of the write burstcount signal. This value determines
signal width the maximum burst write size.
Data width 8, 16, 32, 64 The data width in bits for the Avalon-MM read and write ports.
Source error 07 The width of the error signal for the Avalon-ST source port.
width
Sink error width 07 The width of the error signal for the Avalon-ST sink port.
Data transfer 2, 4, 8, 16, 32, 64 The depth of the internal data FIFO in memory-to-memory
FIFO depth configurations with burst transfers disabled.
The SG-DMA controller core should be given a higher priority (lower IRQ value) than most of the
components in a system to ensure high throughput.
Send Feedback
UG-01085
24-10 Simulation Considerations 2017.05.08
Simulation Considerations
Signals for hardware simulation are automatically generated as part of the Nios II simulation process
available in the Nios II IDE.
Software Files
The SG-DMA controller core provides the following software files. These files provide low-level access to
the hardware and drivers that integrate into the Nios II HAL system library. Application developers should
not modify these files.
altera_avalon_sgdma_regs.hdefines the core's register map, providing symbolic constants to
access the low-level hardware
altera_avalon_sgdma.hprovides definitions for the Altera Avalon SG-DMA buffer control and
status flags.
altera_avalon_sgdma.cprovides function definitions for the code that implements the SG-
DMA controller core.
altera_avalon_sgdma_descriptor.hdefines the core's descriptor, providing symbolic
constants to access the low-level hardware.
Register Maps
The SG-DMA controller core has three registers accessible from its Avalon-MM interface; status,
control and next_descriptor_pointer. Software can configure the core and determines its current
status by accessing the registers.
The control/status register has a 32-bit interface without byte-enable logic, and therefore cannot be
properly accessed by a master with narrower data width than itself. To ensure correct operation of the
core, always access the register with a master that is at least 32 bits wide.
Send Feedback
UG-01085
2017.05.08 Register Maps 24-11
Send Feedback
UG-01085
24-12 Register Maps 2017.05.08
6 STOP_DMA_ER R/W Set this bit to 1 to stop the core when an Avalon-ST
error is encountered during a DMA transaction.
This bit applies only to stream-to-memory configu
rations.
7 IE_MAX_DESC_PROCESSED R/W Set this bit to 1 to generate an interrupt after the
number of descriptors specified by MAX_DESC_
PROCESSED are processed.
Send Feedback
UG-01085
2017.05.08 Register Maps 24-13
Altera recommends that you read the status register only after the RUN bit in the control register is
cleared.
5 .. Reserved
31
Table 24-8 :
1. This bit must be cleared after a read is performed. Write one to clear this bit.
2. This bit is updated by hardware after each DMA transfer completes. It remains set until
software writes one to clear.
3. This bit is continuously updated by the hardware.
Send Feedback
UG-01085
24-14 DMA Descriptors 2017.05.08
DMA Descriptors
See the Data Structure section for the structure definition.
base + 4 Reserved
base + 8 destination
base Reserved
+ 12
base next_desc_ptr
+ 16
base Reserved
+ 20
base Reserved bytes_to_transfer
+ 24
base desc_control desc_status actual_bytes_transferred
+ 28
Send Feedback
UG-01085
2017.05.08 Timeouts 24-15
[6: Reserved
3]
3 . AVALON-ST_CHANNEL_ R/W The DMA read block sets the channel signal to this
. 6 NUMBER value for each word in the transaction. The DMA
write block replaces this value with the channel
number on its sink port.
7 OWNED_BY_HW R/W This bit determines whether hardware or software has
write access to the current register.
When this bit is set to 1, the core can update the
descriptor and software should not access the
descriptor due to the possibility of race conditions.
Otherwise, it is safe for software to update the
descriptor.
After completing a DMA transaction, the descriptor processor block updates the desc_status field to
indicate how the transaction proceeded.
Timeouts
The SG-DMA controller does not implement internal counters to detect stalls. Software can instantiate a
timer component if this functionality is required.
Send Feedback
UG-01085
24-16 Programming with SG-DMA Controller 2017.05.08
Data Structure
Send Feedback
UG-01085
2017.05.08 SG-DMA API 24-17
typedef struct {
alt_u32 *read_addr;
alt_u32 read_addr_pad;
alt_u32 *write_addr;
alt_u32 write_addr_pad;
alt_u32 *next;
alt_u32 next_pad;
alt_u16 bytes_to_transfer;
alt_u8 read_burst; /* Reserved field. Set to 0. */
alt_u8 write_burst;/* Reserved field. Set to 0. */
alt_u16 actual_bytes_transferred;
alt_u8 status;
alt_u8 control;
} alt_avalon_sgdma_packed alt_sgdma_descriptor;
SG-DMA API
Send Feedback
UG-01085
24-18 alt_avalon_sgdma_do_async_transfer() 2017.05.08
Name Description
alt_avalon_sgdma_check_ Reads the status of a given descriptor.
descriptor_status()
alt_avalon_sgdma_stop() Stops the DMA engine. This is not required when alt_avalon_
sgdma_do_async_transfer()and alt_avalon_sgdma_do_
sync_transfer() are used.
alt_avalon_sgdma_do_async_transfer()
Send Feedback
UG-01085
2017.05.08 alt_avalon_sgdma_do_sync_transfer() 24-19
alt_avalon_sgdma_do_sync_transfer()
alt_avalon_sgdma_construct_mem_to_mem_desc()
Send Feedback
UG-01085
24-20 alt_avalon_sgdma_construct_stream_to_mem_desc() 2017.05.08
Returns: void
Description: This function constructs a single SG-DMA descriptor in the memory specified in
alt_avalon_sgdma_descriptor *desc for an Avalon-MM to Avalon-MM
transfer. The function sets the OWNED_BY_HW bit in the descriptor's control
field, marking the completed descriptor as ready to run. The descriptor is
processed when the SG-DMA controller receives the descriptor and the RUN bit
is 1.
The next field of the descriptor being constructed is set to the address in *next.
The OWNED_BY_HW bit of the descriptor at *next is explicitly cleared. Once
the SG-DMA completes processing of the *desc, it does not process the
descriptor at *next until its OWNED_BY_HW bit is set. To create a descriptor
chain, you can repeatedly call this function using the previous call's *next pointer
in the *desc parameter.
You must properly allocate memory for the creation of both the descriptor under
construction as well as the next descriptor in the chain.
Descriptors must be in a memory device mastered by the SG-DMA controllers
chain read and chain write Avalon master ports. Care must be taken to ensure
that both *desc and *next point to areas of memory mastered by the controller.
alt_avalon_sgdma_construct_stream_to_mem_desc()
Send Feedback
UG-01085
2017.05.08 alt_avalon_sgdma_construct_mem_to_stream_desc() 24-21
Returns: void
Description: This function constructs a single SG-DMA descriptor in the memory specified in
alt_avalon_sgdma_descriptor *desc for an Avalon-ST to Avalon-MM transfer.
The source (read) data for the transfer comes from the Avalon-ST interface
connected to the SG-DMA controller's streaming read port.
The function sets the OWNED_BY_HW bit in the descriptor's control field,
marking the completed descriptor as ready to run. The descriptor is processed
when the SG-DMA controller receives the descriptor and the RUN bit is 1.
The next field of the descriptor being constructed is set to the address in *next.
The OWNED_BY_HW bit of the descriptor at *next is explicitly cleared. Once
the SG-DMA completes processing of the *desc, it does not process the
descriptor at *next until its OWNED_BY_HW bit is set. To create a descriptor
chain, you can repeatedly call this function using the previous call's *next pointer
in the *desc parameter.
You must properly allocate memory for the creation of both the descriptor under
construction as well as the next descriptor in the chain.
Descriptors must be in a memory device mastered by the SG-DMA controllers
chain read and chain write Avalon master ports. Care must be taken to ensure
that both *desc and *next point to areas of memory mastered by the controller.
alt_avalon_sgdma_construct_mem_to_stream_desc()
Send Feedback
UG-01085
24-22 alt_avalon_sgdma_enable_desc_poll() 2017.05.08
Returns: void
Description: This function constructs a single SG-DMA descriptor in the memory specified in
alt_avalon_sgdma-descriptor *desc for an Avalon-MM to Avalon-ST transfer.
The destination (write) data for the transfer goes to the Avalon-ST interface
connected to the SG-DMA controller's streaming write port. The function sets
the OWNED_BY_HW bit in the descriptor's control field, marking the
completed descriptor as ready to run. The descriptor is processed when the SG-
DMA controller receives the descriptor and the RUN bit is 1.
The next field of the descriptor being constructed is set to the address in *next.
The OWNED_BY_HW bit of the descriptor at *next is explicitly cleared. Once
the SG-DMA completes processing of the *desc, it does not process the descriptor
at *next until its OWNED_BY_HW bit is set. To create a descriptor chain, you
can repeatedly call this function using the previous call's *next pointer in the
*desc parameter.
You are responsible for properly allocating memory for the creation of both the
descriptor under construction as well as the next descriptor in the chain. Descrip
tors must be in a memory device mastered by the SG-DMA controllers chain
read and chain write Avalon master ports. Care must be taken to ensure that both
*desc and *next point to areas of memory mastered by the controller.
alt_avalon_sgdma_enable_desc_poll()
Send Feedback
UG-01085
2017.05.08 alt_avalon_sgdma_disable_desc_poll() 24-23
Parameters: frequencythe frequency value to set. Only the lower 11-bit value of the
frequency is written to the control register.
Returns: void
Description: Enables descriptor polling mode with a specific frequency. There is no effect if
the hardware does not support this mode.
alt_avalon_sgdma_disable_desc_poll()
Returns: void
Description: Disables descriptor polling mode.
alt_avalon_sgdma_check_descriptor_status()
Send Feedback
UG-01085
24-24 alt_avalon_sgdma_register_callback() 2017.05.08
alt_avalon_sgdma_register_callback()
Returns: void
Description: Associates a user-specific routine with the SG-DMA interrupt handler. If a
callback is registered, all non-blocking transfers enables interrupts that causes
the callback to be executed. The callback runs as part of the interrupt service
routine, and care must be taken to follow the guidelines for acceptable interrupt
service routine behavior as described in the Nios II Software Developers
Handbook.
To disable callbacks after registering one, call this routine with 0x0 as the
callback argument.
alt_avalon_sgdma_start()
Send Feedback
UG-01085
2017.05.08 alt_avalon_sgdma_stop() 24-25
alt_avalon_sgdma_stop()
alt_avalon_sgdma_open()
Send Feedback
UG-01085
24-26 Document Revision History 2017.05.08
July 2014 2014.07.24 Updated Register Maps table, included version register
December 2010 v10.1.0 Updated figure 19-4 and figure 19-5.
Revised the bit description of IE_GLOBAL in table 19-7.
Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
March 2009 v9.0.0 Added description of Enable bursting on descriptor read master.
Send Feedback
2017.05.08
Modular Scatter-Gather DMA Core
25
UG-01085 Subscribe Send Feedback
Core Overview
In a processor subsystem, data transfers between two memory spaces can happen frequently. In order to
offload the processor from moving data around a system, a Direct Memory Access (DMA) engine is
introduced to perform this function instead. The Modular Scatter-Gather DMA (mSGDMA) is capable of
performing data movement operations with preloaded instructions, called descriptors. Multiple descrip
tors with different transfer sizes, and source and destination addresses have the option to trigger
interrupts.
The mSGDMA core has a modular design that facilitates easy integration with the FPGA fabric. The core
consists of a dispatcher block with optional read master and write master blocks. The descriptor block
receives and decodes the descriptor, and dispatches instructions to the read master and write master
blocks for further operation. The block is also configured to transfer additional information to the host. In
this context, the read master block reads data through its Avalon-MM master interface, and channels it
into the Avalon-ST source interface, based on instruction given by the dispatcher block. Conversely, the
write master block receives data from its Avalon-ST sink interface and writes it to the destination address
via its Avalon-MM master interface.
Supported Devices
The Modular Scatter-Gather DMA core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Feature Description
The mSGDMA provides three configuration structures for handling data transfers between the Avalon-
MM to Avalon-MM, Avalon-MM to Avalon-ST, and Avalon-ST to Avalon-MM modes. The sub-core of
the mSGDMA is instantiated automatically according to the structure configured for the mSGDMA use
model.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
25-2 Feature Description 2017.05.08
Figure 25-1: mSGDMA Module Configuration with support for Memory-Mapped Reads and Writes
Send Feedback
UG-01085
2017.05.08 Feature Description 25-3
Figure 25-2: mSGDMA Module Configuration with Support for Memory-Mapped Streaming Reads to the
Avalon-ST data bus
Send Feedback
UG-01085
25-4 mSGDMA Interfaces and Parameters 2017.05.08
Figure 25-3: mSGDMA Module Configuration with Support for Avalon-ST Data Write Streaming to the
Memory-Mapped Bus
The mSGDMA support 32-bit addressing by default. However, the core can support 64-bit addressing
when you select Extended Feature Options in the parameter editor. It also supports extended features
such as dynamic burst count programming, stride addressing, extended discriptor format (64-bit
addressing), and unique sequence number identification for executed descriptor.
Send Feedback
UG-01085
2017.05.08 Descriptor Slave Port 25-5
Response Port
The response port can be set to disabled, memory-mapped, or streaming. In memory-mapped mode the
response information is communicated to the host via an Avalon-MM slave port. The response informa
tion is wider than the slave port, so the host must perform two read operations to retrieve all the informa
tion.
Note: Reading from the last byte of the response slave port performs a destructive read of the response
buffer in the dispatcher module. As a result, always make sure that your software reads from the last
response address last.
When you configure the response port to an Avalon Streaming source interface, connect it to a module
capable of pre-fetching descriptors from memory. The following table shows the ST data bits and their
description.
(9)
Interrupt masks are buffered so that the descriptor pre-fetching block can assert the IRQ signal.
(10)
Combinational signal to inform the descriptor pre-fetching block that space is available for another
descriptor to be committed to the dispatcher descriptor FIFO(s).
Send Feedback
UG-01085
25-6 Parameters 2017.05.08
Parameters
Send Feedback
UG-01085
2017.05.08 Parameters 25-7
Send Feedback
UG-01085
25-8 mSGDMA Parameter Editor 2017.05.08
mSGDMA Descriptors
The descriptor slave port is 128-bits for standard descriptors and 256-bits for extended descriptors. The
tables below show acceptable standard and extended descriptor formats.
Send Feedback
UG-01085
2017.05.08 Read and Write Address Fields 25-9
All descriptor fields are aligned on byte boundaries and span multiple bytes when necessary. You can
access each byte lane of the descriptor slave port independently of the others, allowing you to populate the
descriptor using any access size.
Note: The location of the control field is dependent on the descriptor format you used. The last bit of the
control field commits the descriptor to the dispatcher buffer when it is asserted. As a result, the
control field is located at the end of a descriptor. This allows you to write the descriptor sequentially
to the dispatcher block.
Send Feedback
UG-01085
25-10 Length Field 2017.05.08
Length Field
The length field is used to specify the number of bytes to transfer per descriptor. The length field is also
used for streaming to memory-mapped packet transfers. This limits the number of bytes that can be
transferred before the end-of-packet (EOP) arrives. As a result, you must always program the length field.
If you do not wish to limit packet based transfers in the case of Avalon-ST to Avalon-MM transfers,
program the length field with the largest possible value of 0xFFFFFFFF. This method allows you to specify
a maximum packet size for each descriptor that has packet support enabled.
Send Feedback
UG-01085
2017.05.08 Control Field 25-11
Control Field
The control field is available for both the standard and extended descriptor formats. This field can be
programmed to configure parked descriptors, error handling, and interrupt masks. The interrupt masks
are programmed into the descriptor so that interrupt enables are unique for each transfer.
30:25 <reserved>
24 Early done enable Hides the latency between read descriptors.
When the read master is set, it does not wait for pending reads
to return before requesting another descriptor.
Typically this bit is set for all descriptors except the last one.
This bit is most effective for hiding high read latency. For
example, it reads from SDRAM, PCIe, and SRIO.
23:16 Transmit Error / Error IRQ For for Avalon-MM to Avalon-ST transfers, this field is used to
Enable specify a transmit error.
This field is commonly used for transmitting error information
downstream to streaming components, such as an Ethernet
MAC.
In this mode, these control bits control the error bits on the
streaming output of the read master.
For Avalon-ST to Avalon-MM transfers, this field is used as an
error interrupt mask.
As errors arrive at the write master streaming sink port, they
are held persistently. When the transfer completes, if any error
bits were set at any time during the transfer and the error
interrupt mask bits are set, then the host receives an interrupt.
In this mode, these control bits are used as an error
encountered interrupt enable.
Send Feedback
UG-01085
25-12 Programming Model 2017.05.08
14 Transfer Complete IRQ Signals an interrupt to the host when a transfer completes.
Enable
In the case of Avalon-MM to Avalon-ST transfers, this
interrupt is based on the read master completing a transfer.
In the case of Avalon-ST to Avalon-MM or Avalon-MM to
Avalon-MM transfers, this interrupt is based on the write
master completing a transfer.
13 <reserved>
12 End on EOP End on end of packet allows the write master to continuously
transfer data during Avalon-ST to Avalon-MM transfers
without knowing how much data is arriving ahead of time.
This bit is commonly set for packet-based traffic such as
Ethernet.
11 Park Writes When set, the dispatcher continues to reissue the same
descriptor to the write master when no other descriptors are
buffered.
10 Park Reads When set, the dispatcher continues to reissue the same
descriptor to the read master when no other descriptors are
buffered. This is commonly used for video frame buffering.
9 Generate EOP Emits an end of packet on last beat of a Avalon-MM to
Avlaon-ST transfer
8 Generate SOP Emits a start of packet on the first beat of a Avalon-MM to
Avalon-ST transfer
7:0 Transmit Channel Emits a channel number during Avalon-MM to Avalon-ST
transfers
Programming Model
Stop DMA Operation
The stop DMA operation is also referring to stop dispatcher. Once the Stop Dispatcher bit is set in the
Control Register, no further new read or write transaction is issued. However, existing transactions
pending completion are allowed to complete. The command buffer in both the read master and write
Send Feedback
UG-01085
2017.05.08 Stop Descriptor Operation 25-13
master must be clear before the DMA resumes operation via a reset request. Proceed with the follwing
steps for the stop DMA operation:
1. Set the Stop Dispatcher bit of the Control Register.
2. Recursively check if Stopped bit of Status Register is asserted.
3. When the Stopped bit of the Status Register is asserted, reset the DMA by setting the Reset
Dispatcher bit of the Control Register.
4. Check if the Resetting bit of the Status Register is deasserted. If it is, DMA is now back in normal
operation.
(11)
Writing to reserved bits will have no impact on the hardware, reading will return unknown data.
Send Feedback
UG-01085
25-14 Status Register 2017.05.08
Byte Lanes
0x10 Read Write Sequence Read Sequence Number[15:0]2
Number[15:0](12)
0x14 N/A <reserved>1
0x18 N/A <reserved>1
0x1C N/A <reserved>1
Status Register
8 Stopped on Early When the dispatcher is programmed to stop on early termination, this bit is set.
Termination Also set, when the write master is performing a packet transfer and does not
receive EOP before the pre-determined amount of bytes are transferred, which
is set in the descriptor length field. If you do not wish to use early termination
you should set the transfer length of the descriptor to 0xFFFFFFFF ,which gives
you the maximum packet based transfer possible (early termination is always
enabled for packet transfers).
7 Stopped on Error When the dispatcher is programmed to stop errors and when an error beat
enters the write master the bit is set.
6 Resetting Set when you write to the software reset register and the SGDMA is in the
middle of a reset cycle. This reset cycle is necessary to make sure there are no
incoming transfers on the fabric. When this bit de-asserts you may start using
the SGDMA again.
5 Stopped Set when you either manually stop the SGDMA, or you setup the dispatcher to
stop on errors or early termination and one of those conditions occurred. If you
manually stop the SGDMA this bit is asserted after the master completes any
read or write operations that were already in progress.
4 Response Buffer Set when the response buffer is full.
Full
3 Response Buffer Set when the response buffer is empty.
Empty
2 Descriptor Buffer Set when either the read or write command buffers are full.
Full
(12)
Sequence numbers will only be present when dispatcher enhanced features are enabled.
Send Feedback
UG-01085
2017.05.08 Control Register 25-15
Control Register
The response slave port of mSGDMA contains registers providing information of the executed transaction.
This register map is only applicable when the response mode is enabled and set to memory mapped. Also
when the response port is enabled, it needs to have responses read because it buffers responses. When
setup as a memory-mapped slave port, reading byte offset 0x7 outputs the response. If the response FIFO
becomes full the dispatcher stops issuing transfer commands to the read and write masters. The following
describes the registers definition.
Send Feedback
UG-01085
25-16 Control Register 2017.05.08
(13)
Reading from byte 7 outputs the response FIFO.
(14)
Early Termination is a single bit located at bit 8 of offset 0x4.
Send Feedback
UG-01085
2017.05.08 Modular Scatter-Gather DMA Prefetcher Core 25-17
Feature Description
Supported Features
Descriptor linked list
Data transfer to non-contiguous memory space
Descriptor write back
Hardware descriptor polling
64-bit address spaces
Supported Devices
The Modular Scatter-Gather DMA Prefetcher core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Architecture Overview
The Prefetcher core supports all the three existing Modular SGDMA configurations:
Memory-Mapped to Memory-Mapped
Memory-Mapped to Streaming
Streaming to Memory-Mapped
On interfaces facing host and external peripherals, it has dedicated Avalon-MM read and write master
interfaces to fetch series of descriptors from memory as well as performing a descriptor write back. It has
one Avalon Memory-Mapped CSR slave interface for the host processor to access the configuration
register in the Prefetcher core.
On interfaces facing the internal dispatcher core, it has an Avalon-MM descriptor write master interface to
write a descriptor to the dispatcher core. It has Avalon-ST response sink interface to receive response
information from the dispatcher core upon completion of each descriptor execution.
Send Feedback
UG-01085
25-18 Architecture Overview 2017.05.08
SRC SNK
SNK SRC
CSR S S
MM Read ST Data
M SRC Descriptors SNK Dispatcher
Descriptors
Prefetcher
MM Write
M SNK Response SRC
Descriptors
SNK SRC
IRQ
SRC SNK
Send Feedback
UG-01085
2017.05.08 Architecture Overview 25-19
SRC SNK
SNK SRC
CSR S S
MM Read
M SRC Descriptors SNK Dispatcher
Descriptors
Prefetcher
MM Write
M SNK Response SRC
Descriptors
IRQ
Send Feedback
UG-01085
25-20 Descriptor Format 2017.05.08
CSR
Host
CSR S S
MM Read
M SRC Descriptors SNK Dispatcher
Descriptors
Prefetcher
MM Write
M SNK Response SRC
Descriptors
SNK SRC
IRQ
SRC SNK
Descriptor Format
The mSGDMA without the Prefetcher core defines two types of descriptor formats. Standard descriptor
format which consists of 128 bits and extended descriptor format which consists of 256 bits. With the
Prefetcher core enabled, the existing descriptor format is expanded to 256 bits and 512 bits respectively in
order to accommodate additional control information for the prefetcher operation.
Send Feedback
UG-01085
2017.05.08 Descriptor Fields Definition 25-21
Send Feedback
UG-01085
25-22 Descriptor Processing 2017.05.08
7:0 Error Indicates an error has arrived at the write master streaming sink
port.
This field is not applicable if Modular SGDMA is configured as
Memory-Mapped to Streaming transfer.
For bit 31 and 29:0, refer to descriptor control field bit 31 and 29:0 defined in dispatcher core. Table 25-5
Descriptor Processing
The DMA descriptors specify data transfers to be performed. With the Prefetcher core, a descriptor is
stored in memory and accessed by the Prefetcher core through its descriptor write and descriptor read
Avalon-MM master. The mSGDMA has an internal FIFO to store descriptors read from memory. This
FIFO is located in the dispatchers core. The descriptors must be initialized and aligned on a descriptor
read/write data width boundary. The Prefetcher core relies on a cleared Owned By Hardware bit to stop
processing. When the Owedn by Hardware bit is 1, the Prefetcher core goes ahead to process the
descriptor. When the Owned by Hardware bit is 0, the Prefetcher core does not process the current
descriptor and assumes the linked list has ended or the next descriptor linked list is not yet ready.
Each time a descriptor has been processed, the core updates the Actual Byte Transferred, Status and
Control fields of the descriptor in memory (descriptor write back). The Owned by Hardware bit in the
descriptor control field is cleared by the core during descriptor write back. Refer to software programming
model section to know more about recommended way to set up the Prefetcher core, building and updating
the descriptor list.
In order for the Prefetcher to know which memory addresses to perform descriptor write back, the next
descriptor pointer information will need to be buffered in Prefetcher core. This buffer depth will be similar
to descriptor FIFO depth in dispatcher core. This information is taken out from buffer each time a
response is received from dispatcher.
Send Feedback
UG-01085
2017.05.08 Registers 25-23
Registers
Register Map
Next Descriptor Pointer 0x2 Contains the address [63:32] of the next
High descriptor to process. Software set this
register to the address of the first descriptor
as part of the system initialization sequence.
This field is used only when higher than 32-
bit addressing is used when mSGDMAs
extended feature is enabled.
If descriptor polling is enabled, this register
is also updated by hardware to store the
latest next descriptor address. The latest
next descriptor address is used by the
Prefetcher core to perform descriptor
polling.
Control Register
The address offset for the Control Register table is 0x0.
Send Feedback
UG-01085
25-24 Control Register 2017.05.08
Send Feedback
UG-01085
2017.05.08 Control Register 25-25
Send Feedback
UG-01085
25-26 Control Register 2017.05.08
Send Feedback
UG-01085
2017.05.08 Descriptor Polling Frequency 25-27
Status
(15)
W1S register attribute means, software can write 1 to set the field. Software write 0 to this field has no effect.
Send Feedback
UG-01085
25-28 Interfaces 2017.05.08
Interfaces
(16)
W1C register attribute means, software write 1 to clear the field. Software write 0 to this field has no effect.
Send Feedback
UG-01085
2017.05.08 Avalon-MM Write Descriptor 25-29
Avalon-MM CSR
This interface is used to access the Prefetcher CSR registers. It has fixed write and read wait time of 0 cycles
and read latency of 1 cycle.
Send Feedback
UG-01085
25-30 Avalon-ST Response 2017.05.08
Avalon-ST Response
This interface is used by the Prefetcher core to retrieve response information from dispatchers core upon
each transfer completion.
Streaming interface (ST) data bus format and definition are similar to the dispatchers response source
format:
Send Feedback
UG-01085
2017.05.08 IRQ Interface 25-31
IRQ Interface
When the Prefetcher is enabled, IRQ generation no longer outputs from the dispatchers core. It will be
outputted from the Prefetcher core. The sources of the interrupt remain the same which are transfer
completion, early termination, and error detection. Masking bits for each of the interrupt sources are
programmed in the descriptor. This information will be passed to the Prefetcher core through the ST
response interface. An equivalent global interrupt enable mask and IRQ status bit which are defined in
dispatcher core are now defined in the Prefetcher core as well. These two bits need to be defined in the
Prefetcher core since the actual IRQ register is now located in the Prefetcher core.
Send Feedback
UG-01085
25-32 Resetting Prefetcher Core Flow 2017.05.08
Parameters
Send Feedback
UG-01085
2017.05.08 Driver Implementation 25-33
Driver Implementation
Following section contains the APIs for the mSGDMA HAL Driver. An open mSGDMA API will
instantiate an mSGDMA device with optional register interrupt service routine (ISR). You must define
your own specific handling mechanism in the callback function when using an ISR. A callback function
will be called by the ISR on error, early termination, and on transfer complete.
alt_msgdma_standard_descriptor_async_transfer
Returns: 0 for success, ENOSPC indicates FIFO buffer is full, EPERM indicates
operation not permitted due to descriptor type conflict, -ETIME indicates Time out
and skipping the looping after 5 msec.
Send Feedback
UG-01085
25-34 alt_msgdma_extended_descriptor_async_transfer 2017.05.08
alt_msgdma_extended_descriptor_async_transfer
Returns: 0 for success, ENOSPC indicates FIFO buffer is full, EPERM indicates
operation not permitted due to descriptor type conflict, -ETIME indicates time out
and skipping the looping after 5 msec.
Description: A descriptor needs to be constructed and passing as a parameter pointer to the *desc
when calling this function. This function will call the helper function alt_msgdma_
descriptor_async_transfer to start a non-blocking transfer of one standard
descriptor at a time. If the FIFO buffer for a read/write is full at the time of this call,
the routine will immediately return ENOSPC, the application can then decide how
to proceed without being blocked.-ETIME will be returned if the time spending for
writing descriptor to the dispatcher takes longer than 5 msec. You are advised to
refer the helper function for details. If a callback routine has been previously
registered with this particular mSGDMA controller, the transfer will be set up to
enable interrupt generation.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_descriptor_async_transfer 25-35
alt_msgdma_descriptor_async_transfer
Returns: 0 for success, ENOSPC indicates FIFO buffer is full, EPERM indicates
operation not permitted due to descriptor type conflict, -ETIME indicates Time out
and skipping the looping after 5 msec.
Send Feedback
UG-01085
25-36 alt_msgdma_standard_descriptor_sync_transfer 2017.05.08
alt_msgdma_standard_descriptor_sync_transfer
Returns: 0 for success, error indicates errors or conditions causing msgdma stop issuing
commands to masters, suggest checking the bit set in the error with CSR status
register.-EPERM indicates operation not permitted due to descriptor type conflict.
-ETIME indicates Time out and skipping the looping after 5 msec.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_extended_descriptor_sync_transfer 25-37
alt_msgdma_extended_descriptor_sync_transfer
Returns: 0 for success, error indicates errors or conditions causing msgdma stop issuing
commands to masters, suggest checking the bit set in the error with CSR status
register.-EPERM indicates operation not permitted due to descriptor type conflict.
-ETIME indicates Time out and skipping the looping after 5 msec.
Send Feedback
UG-01085
25-38 alt_msgdma_descriptor_sync_transfer 2017.05.08
alt_msgdma_descriptor_sync_transfer
Returns: 0 for success, error indicates errors or conditions causing msgdma stop issuing
commands to masters, suggest checking the bit set in the error with CSR status
register.-EPERM indicates operation not permitted due to descriptor type conflict.
-ETIME indicates Time out and skipping the looping after 5 msec.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_construct_standard_st_to_mm_descriptor 25-39
alt_msgdma_construct_standard_st_to_mm_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function will call helper function alt_msgdma_construct_standard_descriptor for
constructing st_to_mm standard descriptors. Unnecessary elements are set to 0 for
completeness and will be ignored by the hardware.
Send Feedback
UG-01085
25-40 alt_msgdma_construct_standard_mm_to_st_descriptor 2017.05.08
alt_msgdma_construct_standard_mm_to_st_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function will call helper function alt_msgdma_construct_standard_descriptor for
constructing mm_to_st standard descriptors. Unnecessary elements are set to 0 for
completeness and will be ignored by the hardware.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_construct_standard_mm_to_mm_descriptor 25-41
alt_msgdma_construct_standard_mm_to_mm_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function will call helper function alt_msgdma_construct_standard_descriptor for
constructing mm_to_mm standard descriptors. Unnecessary elements are set to 0
for completeness and will be ignored by the hardware.
Send Feedback
UG-01085
25-42 alt_msgdma_construct_standard_descriptor 2017.05.08
alt_msgdma_construct_standard_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Helper functions for constructing mm_to_st, st_to_mm, mm_to_mm standard
descriptors. Unnecessary elements are set to 0 for completeness and will be ignored
by the hardware.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_construct_extended_st_to_mm_descriptor 25-43
alt_msgdma_construct_extended_st_to_mm_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function will call helper function alt_msgdma_construct_extended_descriptor for
constructing st_to_mm extended descriptors. Unnecessary elements are set to 0 for
completeness and will be ignored by the hardware.
Send Feedback
UG-01085
25-44 alt_msgdma_construct_extended_mm_to_st_descriptor 2017.05.08
alt_msgdma_construct_extended_mm_to_st_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_construct_extended_mm_to_mm_descriptor 25-45
alt_msgdma_construct_extended_mm_to_mm_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Send Feedback
UG-01085
25-46 alt_msgdma_construct_extended_descriptor 2017.05.08
alt_msgdma_construct_extended_descriptor
Returns: 0 for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Send Feedback
UG-01085
2017.05.08 alt_msgdma_register_callback 25-47
alt_msgdma_register_callback
Returns: N/A
Description: Associate a user-specific routine with the mSGDMA interrupt handler. If a callback
is registered, all non-blocking mSGDMA transfers will enable interrupts that will
cause the callback to be executed. The callback runs as part of the interrupt service
routine, and great care must be taken to follow the guidelines for acceptable
interrupt service routine behavior as described in the Nios II Software Developer's
Handbook. However, user can change some of the CSR control setting in blocking
transfer by calling this function.
Send Feedback
UG-01085
25-48 alt_msgdma_open 2017.05.08
alt_msgdma_open
Send Feedback
UG-01085
2017.05.08 alt_msgdma_write_standard_descriptor 25-49
alt_msgdma_write_standard_descriptor
Returns: Returns 0 upon success. Other return codes are defined in "alt_errno.h".
Description: Sends a fully formed standard descriptor to the dispatcher module. If the dispatcher
descriptor buffer is full, -ENOSPC is returned. This function is not reentrant since
it must complete writing the entire descriptor to the dispatcher module and cannot
be pre-empted.
Send Feedback
UG-01085
25-50 alt_msgdma_write_extended_descriptor 2017.05.08
alt_msgdma_write_extended_descriptor
Returns: Returns 0 upon success. Other return codes are defined in "alt_errno.h".
Description: Sends a fully formed extended descriptor to the dispatcher module. If the dispatcher
descriptor buffer is full an error is returned. This function is not reentrant since it
must complete writing the entire descriptor to the dispatcher module and cannot be
pre-empted.
Send Feedback
UG-01085
2017.05.08 alt_avalon_msgdma_init 25-51
alt_avalon_msgdma_init
Returns: N/A
Description: Initializes the mSGDMA controller. This routine is called from the ALTERA_
AVALON_MSGDMA_INIT macro and is called automatically by "alt_sys_init.c".
alt_msgdma_irq
Returns: N/A
Description: Interrupt handler for mSGDMA. This function will call the user defined interrupt
handler if user registers their own interrupt handler with calling alt_register_
callback.
Send Feedback
UG-01085
25-52 Document Revision History 2017.05.08
May 2017 2017.05.08 Status Register on page 25-14 : Bit 9 description updated
May 2016 2016.05.03 Updated tables:
Table 25-2
Send Feedback
2017.05.08
DMA Controller Core
26
UG-01085 Subscribe Send Feedback
Core Overview
The direct memory access (DMA) controller core with Avalon interface performs bulk data transfers,
reading data from a source address range and writing the data to a different address range. An Avalon
Memor-Mapped (Avalon-MM) master peripheral, such as a CPU, can offload memory transfer tasks to the
DMA controller. While the DMA controller performs memory transfers, the master is free to perform
other tasks in parallel.
The DMA controller transfers data as efficiently as possible, reading and writing data at the maximum
pace allowed by the source or destination. The DMA controller is capable of performing Avalon transfers
with flow control, enabling it to automatically transfer data to or from a slow peripheral with flow control
(for example, UART), at the maximum pace allowed by the peripheral.
Instantiating the DMA controller in Qsys creates one slave port and two master ports. You must specify
which slave peripherals can be accessed by the read and write master ports. Likewise, you must specify
which other master peripheral(s) can access the DMA control port and initiate DMA transactions. The
DMA controller does not export any signals to the top level of the system module.
For the Nios II processor, device drivers are provided in the HAL system library. See the Software
Supported Devices
The DMA Controller core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
You can use the DMA controller to perform data transfers from a source address-space to a destination
address-space. The controller has no concept of endianness and does not interpret the payload data. The
concept of endianness only applies to a master that interprets payload data.
The source and destination may be either an Avalon-MM slave peripheral (for example, a constant
address) or an address range in memory. The DMA controller can be used in conjunction with peripherals
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
26-2 Setting Up DMA Transactions 2017.05.08
with flow control, which allows data transactions of fixed or variable length. The DMA controller can
signal an interrupt request (IRQ) when a DMA transaction completes. A transaction is a sequence of one
or more Avalon transfers initiated by the DMA controller core.
The DMA controller has two Avalon-MM master portsa master read port and a master write portand
one Avalon-MM slave port for controlling the DMA as shown in the figure below.
Figure 26-1: DMA Controller Block Diagram
Addr,
Register File
data,
control
status Read
Master
readaddress Port
Control Sepa rate
Avalon-MM
Port
writeaddress Avalon-MM
Save Port
Write Master Ports
IRQ
length
Master
control Port
Send Feedback
UG-01085
2017.05.08 Addressing and Address Incrementing 26-3
addresses. Read and write start addresses should be aligned to the transfer size. For example, to transfer
data words, if the start address is 0, the address will increment to 4, 8, and 12. For heterogeneous systems
where a number of different slave devices are of different widths, the data width for read and write masters
matches the width of the widest data-width slave addressed by either the read or the write master. For
bursting transfers, the burst length is set to the DMA transaction length with the appropriate unit
conversion. For example, if a 32-bit data width DMA is programmed for a word transfer of 64 bytes, the
length registered is programmed with 64 and the burst count port will be 16. If a 64-bit data width DMA is
programmed for a doubleword transfer of 8 bytes, the length register is programmed with 8 and the burst
count port will be 1.
There is a shallow FIFO buffer between the master read and write ports. The default depth is 2, which
makes the write action depend on the data-available status of the FIFO, rather than on the status of the
master read port.
Both the read and write master ports can perform Avalon transfers with flow control, which allows the
slave peripheral to control the flow of data and terminate the DMA transaction.
For details about flow control in Avalon-MM data transfers and Avalon-MM peripherals, refer to Avalon
Interface Specifications.
In systems with heterogeneous data widths, care must be taken to present the correct address or offset
when configuring the DMA to access native-aligned slaves. For example, in a system using a 32-bit
Nios II processor and a 16-bit DMA, the base address for the UART txdata register must be divided by
the dma_data_width/cpu_data_width2 in this example.
Parameters
This section describes the parameters you can configure.
Send Feedback
UG-01085
26-4 DMA Parameters (Basic) 2017.05.08
Transfer Size
The parameter Width of the DMA Length Register specifies the minimum width of the DMAs transac
tion length register, which can be between 1 and 32. The length register determines the maximum
number of transfers possible in a single DMA transaction.
By default, the length register is wide enough to span any of the slave peripherals mastered by the read or
write ports. Overriding the length register may be necessary if the DMA master port (read or write)
masters only data peripherals, such as a UART. In this case, the address span of each slave is small, but a
larger number of transfers may be desired per DMA transaction.
Burst Transactions
When Enable Burst Transfers is turned on, the DMA controller performs burst transactions on its master
read and write ports. The parameter Maximum Burst Size determines the maximum burst size allowed in
a transaction.
In burst mode, the length of a transaction must not be longer than the configured maximum burst size.
Otherwise, the transaction must be performed as multiple transactions.
FIFO Depth
The parameter Data Transfer FIFO Depth specifies the depth of the FIFO buffer used for data transfers.
Altera recommends that you set the depth of the FIFO buffer to at least twice the maximum read latency
of the slave interface connected to the read master port. A depth that is too low reduces transfer
throughput.
FIFO Implementation
This option determines the implementation of the FIFO buffer between the master read and write ports.
Select Construct FIFO from Registers to implement the FIFO using one register per storage bit. This
option has a strong impact on logic utilization when the DMA controllers data width is large. See the
Advanced Options section.
To implement the FIFO using embedded memory blocks available in the FPGA, select Construct FIFO
from Memory Blocks.
Advanced Options
The Advanced Options page includes the following parameters.
Allowed Transactions
Send Feedback
UG-01085
2017.05.08 Software Programming Model 26-5
You can choose the transfer datawidth(s) supported by the DMA controller hardware. The following
datawidth options can be enabled or disabled:
Byte
Halfword (two bytes)
Word (four bytes)
Doubleword (eight bytes)
Quadword (sixteen bytes)
Disabling unnecessary transfer widths reduces the number of on-chip logic resources consumed by the
DMA controller core. For example, if a system has both 16-bit and 32-bit memories, but the DMA
controller transfers data to the 16-bit memory, 32-bit transfers could be disabled to conserve logic
resources.
ioctl() Operations
ioctl() operation requests are defined for both the receive and transmit channels, which allows you to
control the hardware-dependent aspects of the DMA controller. Two ioctl() functions are defined for
the receiver driver and the transmitter driver: alt_dma_rxchan_ioctl() and alt_dma_txchan_ioctl().
The table below lists the available operations. These are valid for both the transmit and receive channels.
Send Feedback
UG-01085
26-6 Software Files 2017.05.08
Request Meaning
ALT_DMA_RX_ONLY_OFF Turns off streaming mode for a receive channel. The parameter arg is ignored.
(1)
ALT_DMA_TX_ONLY_ON Sets a DMA transmitter into streaming mode. In this case, data is written
(1) continuously to a single location. The parameter arg specifies the address to
write to.
ALT_DMA_TX_ONLY_OFF Turns off streaming mode for a transmit channel. The parameter arg is ignored.
(1)
Table 26-2 :
1. These macro names changed in version 1.1 of the Nios II Embedded Design Suite (EDS). The old
names (ALT_DMA_TX_STREAM_ON, ALT_DMA_TX_STREAM_OFF, ALT_DMA_RX_STREAM_ON, and ALT_DMA_
RX_STREAM_OFF) are still valid, but new designs should use the new names.
Limitations
Currently the Altera-provided drivers do not support 64-bit and 128-bit DMA transactions.
This function is not thread safe. If you want to access the DMA controller from more than one thread then
you should use a semaphore or mutex to ensure that only one thread is executing within this function at
any time.
Software Files
The DMA controller is accompanied by the following software files. These files define the low-level
interface to the hardware. Application developers should not modify these files.
altera_avalon_dma_regs.hThis file defines the cores register map, providing symbolic
constants to access the low-level hardware. The symbols in this file are used only by device driver
functions.
altera_avalon_dma.h, altera_avalon_dma.cThese files implement the DMA controllers
device driver for the HAL system library.
Register Map
Programmers using the HAL API never access the DMA controller hardware directly via its registers. In
general, the register map is only useful to programmers writing a device driver.
The Altera-provided HAL device driver accesses the device registers directly. If you are writing a device
driver, and the HAL driver is active for the same device, your driver will conflict and fail to operate.
Device drivers control and communicate with the hardware through five memory-mapped 32-bit
registers.
Send Feedback
UG-01085
2017.05.08 Register Map 26-7
4 Reserved (3)
5 Reserved (3)
6 con RW (2) SOF QUA DOU WCO RCO LEE WEE REE I_ GO WOR HW BYT
tro TWA DWO BLE N N N N N EN D E
l RER RD WOR
ESE D
T
7 Reserved (3)
Table 26-3 :
1. Writing zero to the status register clears the LEN, WEOP, REOP, and DONE bits.
2. These bits are reserved. Read values are undefined. Write zero.
3. This register is reserved. Read values are undefined. The result of a write is undefined.
status Register
The status register consists of individual bits that indicate conditions inside the DMA controller. The
status register can be read at any time. Reading the status register does not change its value.
Send Feedback
UG-01085
26-8 Register Map 2017.05.08
readaddress Register
The readaddress register specifies the first location to be read in a DMA transaction. The readaddress
register width is determined at system generation time. It is wide enough to address the full range of all
slave ports mastered by the read port.
writeaddress Register
The writeaddress register specifies the first location to be written in a DMA transaction. The writead-
dress register width is determined at system generation time. It is wide enough to address the full range of
all slave ports mastered by the write port.
length Register
The length register specifies the number of bytes to be transferred from the read port to the write port.
The length register is specified in bytes. For example, the value must be a multiple of 4 for word transfers,
and a multiple of 2 for halfword transfers.
The length register is decremented as each data value is written by the write master port. When length
reaches 0 the LEN bit is set. The length register does not decrement below 0.
The length register width is determined at system generation time. It is at least wide enough to span any of
the slave ports mastered by the read or write master ports, and it can be made wider if necessary.
control Register
The control register is composed of individual bits that control the DMAs internal operation. The control
registers value can be read at any time. The control register bits determine which, if any, conditions of the
DMA transaction result in the end of a transaction and an interrupt request.
Send Feedback
UG-01085
2017.05.08 Register Map 26-9
4 I_EN RW Enables interrupt requests (IRQ). When the I_EN bit is 1, the DMA
controller generates an IRQ when the status registers DONE bit is set
to 1. IRQs are disabled when the I_EN bit is 0.
5 REEN RW Ends transaction on read-side end-of-packet. When the REEN bit is
set to 1, a slave port with flow control on the read side may end the
DMA transaction by asserting its end-of-packet signal.
6 WEEN RW Ends transaction on write-side end-of-packet. WEEN bit shoudl be set
to 0.
7 LEEN RW Ends transaction when the length register reaches zero. When this
bit is 0, length reaching 0 does not cause a transaction to end. In
this case, the DMA transaction must be terminated by an end-of-
packet signal from either the read or write master port.
8 RCON RW Reads from a constant address. When RCON is 0, the read address
increments after every data transfer. This is the mechanism for the
DMA controller to read a range of memory addresses. When RCON is
1, the read address does not increment. This is the mechanism for the
DMA controller to read from a peripheral at a constant memory
address. For details, see the Addressing and Address Incrementing
section.
9 WCON RW Writes to a constant address. Similar to the RCON bit, when WCON is 0
the write address increments after every data transfer; when WCON is 1
the write address does not increment. For details, see Addressing
and Address Incrementing.
10 DOUBLEWORD RW Specifies doubleword transfers.
11 QUADWORD RW Specifies quadword transfers.
12 SOFTWARERESET RW Software can reset the DMA engine by writing this bit to 1 twice.
Upon the second write of 1 to the SOFTWARERESET bit, the DMA
control is reset identically to a system reset. The logic which
sequences the software reset process then resets itself automatically.
The data width of DMA transactions is specified by the BYTE, HW, WORD, DOUBLEWORD, and QUADWORD bits.
Only one of these bits can be set at a time. If more than one of the bits is set, the DMA controller behavior
is undefined. The width of the transfer is determined by the narrower of the two slaves read and written.
For example, a DMA transaction that reads from a 16-bit flash memory and writes to a 32-bit on-chip
memory requires a halfword transfer. In this case, HW must be set to 1, and BYTE, WORD, DOUBLEWORD, and
QUADWORD must be set to 0.
Send Feedback
UG-01085
26-10 Interrupt Behavior 2017.05.08
To successfully perform transactions of a specific width, that width must be enabled in hardware using the
Allowed Transaction hardware option. For example, the DMA controller behavior is undefined if
quadword transfers are disabled in hardware, but the QUADWORD bit is set during a DMA transaction.
Executing a DMA software reset when a DMA transfer is active may result in permanent bus lockup (until
the next system reset). The SOFTWARERESET bit should therefore not be written except as a last resort.
Interrupt Behavior
The DMA controller has a single IRQ output that is asserted when the status registers DONE bit equals 1
and the control registers I_EN bit equals 1.
Writing the status register clears the DONE bit and acknowledges the IRQ. A master peripheral can read
the status register and determine how the DMA transaction finished by checking the LEN, REOP, and
WEOP bits.
Send Feedback
2017.05.08
Video Sync Generator and Pixel Converter
Cores 27
UG-01085 Subscribe Send Feedback
Core Overview
The video sync generator core accepts a continuous stream of pixel data in RGB format, and outputs the
data to an off-chip display controller with proper timing. You can configure the video sync generator core
to support different display resolutions and synchronization timings.
The pixel converter core transforms the pixel data to the format required by the video sync generator. The
Typical Placement in a System figure shows a typical placement of the video sync generator and pixel
converter cores in a system.
In this example, the video buffer stores the pixel data in 32-bit unpacked format. The extra byte in the pixel
data is discarded by the pixel converter core before the data is serialized and sent to the video sync
generator core.
Figure 27-1: Typical Placement in a System
Avalon-MM Avalon-ST
These cores are deployed in the Nios II Embedded Software Evaluation Kit (NEEK), which includes an
LCD display daughtercard assembly attached via an HSMC connector.
Supported Devices
The Video Sync Generator and Pixel Converter cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reservesAvthe alonright
-MM to make changes to any products A and services
valon-ST at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
27-2 Video Sync Generator 2017.05.08
Functional Description
The video sync generator core adds horizontal and vertical synchronization signals to the pixel data that
comes through its Avalon (Avalon-ST) input interface and outputs the data to an off-chip display
clk
reset rgb_out
data
hd
ready
vd
valid
sop den
eop
You can configure various aspects of the core and its Avalon-ST interface to suit your requirements. You
can specify the data width, number of beats required to transfer each pixel and synchronization signals.
See the Parameters section for more information on the available options.
To ensure incoming pixel data is sent to the display controller with correct timing, the video sync
generator core must synchronize itself to the first pixel in a frame. The first active pixel is indicated by an
sop pulse.
The video sync generator core expects continuous streams of pixel data at its input interface and assumes
that each incoming packet contains the correct number of pixels (Number of rows * Number of columns).
Data starvation disrupts synchronization and results in unexpected output on the display.
Parameters
Send Feedback
UG-01085
2017.05.08 Signals 27-3
Vertical Blank Lines The number of blanking lines that proceed the active lines. During this period,
there is no data flow from the Avalon-ST sink port to the LCD output data port.
Data Stream Bit The width of the inbound and outbound data.
Width
Signals
Send Feedback
UG-01085
27-4 Timing Diagrams 2017.05.08
sop 1 Input Start-of-packet. This signal is asserted when the first pixel is
received.
eop 1 Input End-of-packet. This signal is asserted when the last pixel is received.
LCD Output Signals
rgb_out Variable- Output Display data. The datawidth is determined by the parameter Data
width Stream Bit Width.
hd 1 Output Horizontal synchronization pulse for display.
vd 1 Output Vertical synchronization pulse for display.
den 1 Output This signal is asserted when the video sync generator core outputs
valid data for display.
Timing Diagrams
The horizontal and vertical synchronization timings are determined by the parameters setting. The table
below shows the horizontal synchronization timing when the parameters Data Stream Bit Width and
Beats Per Pixel are set to 8 and 3, respectively.
Figure 27-3: Horizontal Synchronization Timing8 Bits DataWidth and 3 Beats Per Pixel
clk
Horizontal sync pulse
hd
den
1 pixel
rgb_out RG B RG B
Horizontal blank pixels Horizontal front porch
The table below sho.ws the horizontal synchronization timing when the parameters Data Stream Bit
Width and Beats Per Pixel are set to 24 and 1, respectively.
Send Feedback
UG-01085
2017.05.08 Pixel Converter 27-5
Figure 27-4: Horizontal Synchronization Timing24 Bits DataWidth and 1 Beat Per Pixel
clk
Horizontal synchronization pulse
hd
den
1 pixel
Figure 27-5: Vertical Synchronization Timing8 Bits DataWidth and 3 Beats Per Pixel / 24 Bits DataWidth
and 1 Beat Per Pixel
vd
hd
Pixel Converter
This section describes the hardware structure and functionality of the pixel converter core.
Functional Description
The pixel converter core receives pixel data on its Avalon-ST input interface and transforms the pixel data
to the format required by the video sync generator. The least significant byte of the 32-bit wide pixel data is
removed and the remaining 24 bits are wired directly to the core's Avalon-ST output interface.
Parameters
You can configure the following parameter:
Source symbols per beatThe number of symbols per beat on the Avalon-ST source interface.
Signals
Send Feedback
UG-01085
27-6 Hardware Simulation Considerations 2017.05.08
empty_ 1 Output
out
Table 27-4: Video Sync Generator and Pixel Converter Cores Revision History
Date Version Changes
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
Send Feedback
UG-01085
2017.05.08 Document Revision History 27-7
Send Feedback
2017.05.08
Interval Timer Core
28
UG-01085 Subscribe Send Feedback
Core Overview
The Interval Timer core with Avalon interface is an interval timer for Avalon-based processor systems,
such as a Nios II processor system. The core provides the following features:
Supported Devices
The Interval Timer core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
28-2 Functional Description 2017.05.08
Functional Description
Figure 28-1: Interval Timer Core Block Diagram
Register File
status
control
Address & period_ n
Data Counter
Avalon-MM snap_n
slave interface IRQ
to on-chip Control timeout_pulse
resetrequest
logic Logic
(watchdog)
Send Feedback
UG-01085
2017.05.08 Configuration 28-3
Configuration
This section describes the options available in the MegaWizard Interace.
Timeout Period
The Timeout Period setting determines the initial value of the period registers. When the Writeable
period option is on, a processor can change the value of the period by writing to the period registers.
When the Writeable period option is off, the period is fixed and cannot be updated at runtime. See the
Hardware Options section for information on register options.
The Timeout Period is an integer multiple of the Timer Frequency. The Timer Frequency is fixed at the
frequency setting of the system clock associated with the timer. The Timeout Period setting can be
specified in units of s (microseconds), ms (milliseconds), seconds , or clocks (number of cycles of the
system clock associated with the timer). The actual period depends on the frequency of the system clock
associated with the timer. If the period is specified in s, ms, or seconds, the true period will be the
smallest number of clock cycles that is greater or equal to the specified Timeout Period value. For
example, if the associated system clock has a frequency of 30 ns, and the specified Timeout Period value is
1 s, the true timeout period will be 1.020 microseconds.
Counter Size
The Counter Size setting determines the timer's width, which can be set to either 32 or 64 bits. A 32-bit
timer has two 16-bit period registers, whereas a 64-bit timer has four 16-bit period registers. This option
applies to the snap registers as well.
Hardware Options
The following options affect the hardware structure of the interval timer core. As a convenience, the Preset
Configurations list offers several pre-defined hardware configurations, such as:
Simple periodic interruptThis configuration is useful for systems that require only a periodic IRQ
generator. The period is fixed and the timer cannot be stopped, but the IRQ can be disabled.
Full-featuredThis configuration is useful for embedded processor systems that require a timer with
variable period that can be started and stopped under processor control.
WatchdogThis configuration is useful for systems that require watchdog timer to reset the system in
the event that the system has stopped responding. Refer to the Configuring the Timer as a Watchdog
Timer section.
Register Options
Send Feedback
UG-01085
28-4 Configuring the Timer as a Watchdog Timer 2017.05.08
Option Description
Start/Stop When this option is enabled, a master peripheral can start and stop the timer by writing the
control bits START and STOP bits in the control register. When disabled, the timer runs continuously.
When the System reset on timeout (watchdog) option is enabled, the START bit is also
present, regardless of the Start/Stop control bits option.
To prevent the system from resetting, the processor must periodically reset the timer's count-down
value by writing one of the period registers (the written value is ignored). If the processor fails to access
the timer because, for example, software stopped executing normally, the watchdog timer resets the
system and returns the system to a defined state.
Send Feedback
UG-01085
2017.05.08 Software Programming Model 28-5
Timestamp Driver
The interval timer core may be used as a timestamp device if it meets the following conditions:
The timer has a writeable period register, as configured in Qsys.
The timer is not selected as the system clock.
The Nios II IDE allows you to specify system library properties that determine which timer device will
be used as the timestamp timer.
If the timer hardware is not configured with writeable period registers, calls to the
alt_timestamp_start() API function will not reset the timestamp counter. All other HAL API calls
will perform as expected.
For more information about using the system clock and timestamp features that use these drivers, refer
to the Nios II Software Developers Handbook. The Nios II Embedded Design Suite (EDS) also
provides several example designs that use the interval timer core.
Limitations
The HAL driver for the interval timer core does not support the watchdog reset feature of the core.
Software Files
The interval timer core is accompanied by the following software files. These files define the low-level
interface to the hardware, and provide the HAL drivers. Application developers should not modify these
files.
Send Feedback
UG-01085
28-6 Register Map 2017.05.08
altera_avalon_timer_regs.hThis file defines the core's register map, providing symbolic constants to
access the low-level hardware.
altera_avalon_timer.h, altera_avalon_timer_sc.c, altera_avalon_timer_ts.c,
altera_avalon_timer_vars.cThese files implement the timer device drivers for the HAL system
library.
Register Map
You do not need to access the interval timer core directly via its registers if using the standard features
provided in the HAL system library for the Nios II processor. In general, the register map is only useful to
programmers writing a device driver.
The Altera-provided HAL device driver accesses the device registers directly. If you are writing a device
driver, and the HAL driver is active for the same device, your driver will conflict and fail to operate
correctly.
The table below shows the register map for the 32-bit timer. The interval timer core uses native address
alignment. For example, to access the control register value, use offset 0x4.
For more information about native address alignment, refer to the System Interconnect Fabric for
Memory-Mapped Interfaces.
Send Feedback
UG-01085
2017.05.08 Register Map 28-7
Description of Bits
Offset Name R/W
15 ... 4 3 2 1 0
4 period_2 RW Timeout Period 1 (bits [47:32])
5 period_3 RW Timeout Period 1 (bits [63:48])
6 snap_0 RW Counter Snapshot (bits [15:0])
7 snap_1 RW Counter Snapshot (bits [31:16])
8 snap_2 RW Counter Snapshot (bits [47:32])
9 snap_3 RW Counter Snapshot (bits [63:48])
Table 28-4 :
1. Reserved. Read values are undefined. Write zero.
status Register
The status register has two defined bits.
control Register
The control register has four defined bits.
Send Feedback
UG-01085
28-8 Interrupt Behavior 2017.05.08
Table 28-6 :
1. Writing 1 to both START and STOP bits simultaneously produces an undefined result.
period_n Registers
The period_n registers together store the timeout period value. The internal counter is loaded with the
value stored in these registers whenever one of the following occurs:
A write operation to one of the period_n register
The internal counter reaches 0
The timer's actual period is one cycle greater than the value stored in the period_n registers because
the counter assumes the value zero for one clock cycle.
Writing to one of the period_n registers stops the internal counter, except when the hardware is
configured with Start/Stop control bits off. If Start/Stop control bits is off, writing either register does
not stop the counter. When the hardware is configured with Writeable period disabled, writing to one
of the period_n registers causes the counter to reset to the fixed Timeout Period specified at system
generation time.
Note: A timeout period value of 0 is not a supported use case. Software configures timeout period values
greater than 0.
snap_n Registers
A master peripheral may request a coherent snapshot of the current internal counter by performing a write
operation (write-data ignored) to one of the snap_n registers. When a write occurs, the value of the
counter is copied to snap_n registers. The snapshot occurs whether or not the counter is running.
Requesting a snapshot does not change the internal counter's operation.
Interrupt Behavior
The interval timer core generates an IRQ whenever the internal counter reaches zero and the ITO bit of the
control register is set to 1. Acknowledge the IRQ in one of two ways:
Send Feedback
UG-01085
2017.05.08 Document Revision History 28-9
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. Updated the cores name to reflect the
name used in SOPC Builder.
May 2008 v8.0.0 Added a new parameter and register map for the 64-bit timer.
Send Feedback
2017.05.08
Mutex Core
29
UG-01085 Subscribe Send Feedback
Core Overview
Multiprocessor environments can use the mutex core with Avalon interface to coordinate accesses to a
shared resource. The mutex core provides a protocol to ensure mutually exclusive ownership of a shared
resource.
The mutex core provides a hardware-based atomic test-and-set operation, allowing software in a
multiprocessor environment to determine which processor owns the mutex. The mutex core can be used
in conjunction with shared memory to implement additional interprocessor coordination features, such as
mailboxes and software mutexes.
The mutex core is designed for use in Avalon-based processor systems, such as a Nios II processor
system. Altera provides device drivers for the Nios II processor to enable use of the hardware mutex.
Supported Devices
The Mutex core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The mutex core has a simple Avalon Memory-Mapped (Avalon-MM) slave interface that provides access
to two memory-mapped, 32-bit registers.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
29-2 Configuration 2017.05.08
The mutex core has the following basic behavior. This description assumes there are multiple processors
accessing a single mutex core, and each processor has a unique identifier (ID).
When the VALUE field is 0x0000, the mutex is unlocked and available. Otherwise, the mutex is locked
and unavailable.
The mutex register is always readable. Avalon-MM master peripherals, such as a processor, can read the
mutex register to determine its current state.
The mutex register is writable only under specific conditions. A write operation changes the mutex
register only if one or both of the following conditions are true:
The VALUE field of the mutex register is zero.
The OWNER field of the mutex register matches the OWNER field in the data to be written.
A processor attempts to acquire the mutex by writing its ID to the OWNER field, and writing a non-zero
value to the VALUE field. The processor then checks if the acquisition succeeded by verifying the OWNER
field.
After system reset, the RESET bit in the reset register is high. Writing a one to this bit clears it.
Configuration
The MegaWizard Interface provides the following options:
Initial Valuethe initial contents of the VALUE field after reset. If the Initial Value setting is non-zero,
you must also specify Initial Owner.
Initial Ownerthe initial contents of the OWNER field after reset. When Initial Owner is specified, this
owner must release the mutex before it can be acquired by another owner.
Software Files
Altera provides the following software files accompanying the mutex core:
altera_avalon_mutex_regs.hDefines the core's register map, providing symbolic constants to
access the low-level hardware.
altera_avalon_mutex.hDefines data structures and functions to access the mutex core
hardware.
altera_avalon_mutex.cContains the implementations of the functions to access the mutex core
Send Feedback
UG-01085
2017.05.08 Mutex API 29-3
These routines coordinate access to the software mutex structure using a hardware mutex core. For a
complete description of each function, see section the Mutex API section.
The code shown in below demonstrates opening a mutex device handle and locking a mutex.
#include <altera_avalon_mutex.h>
/*
* Access a shared resource here.
*/
altera_avalon_mutex_unlock( mutex );
Mutex API
This section describes the application programming interface (API) for the mutex core.
altera_avalon_mutex_is_mine()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: devthe mutex device to test.
Send Feedback
UG-01085
29-4 altera_avalon_mutex_first_lock() 2017.05.08
altera_avalon_mutex_first_lock()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: devthe mutex device to test.
Returns: Returns 1 if this mutex has not been released since reset, otherwise returns 0.
Description: altera_avalon_mutex_first_lock() determines whether this mutex has
been released since reset.
altera_avalon_mutex_lock()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: devthe mutex device to acquire.
Returns:
Description: altera_avalon_mutex_lock() is a blocking routine that acquires a hardware
mutex, and at the same time, loads the mutex with the value parameter.
altera_avalon_mutex_open()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: namethe name of the mutex device to open.
Send Feedback
UG-01085
2017.05.08 altera_avalon_mutex_trylock() 29-5
Returns: A pointer to the mutex device structure associated with the supplied name, or
NULL if no corresponding mutex device structure was found.
Description: altera_avalon_mutex_open() retrieves a pointer to a hardware mutex device
structure.
altera_avalon_mutex_trylock()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: devthe mutex device to lock.
altera_avalon_mutex_unlock()
Thread-safe: Yes.
Available from No.
ISR:
Include: <altera_avalon_mutex.h>
Parameters: devthe mutex device to unlock.
Returns: Null.
Description: altera_avalon_mutex_unlock() releases a hardware mutex device. Upon
release, the value stored in the mutex is set to zero. If the caller does not hold the
mutex, the behavior of this function is undefined.
Send Feedback
UG-01085
29-6 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Vectored Interrupt Controller Core
30
UG-01085 Subscribe Send Feedback
Core Overview
The ability to process interrupt events quickly and to handle large numbers of interrupts can be critical to
many embedded systems. The Vectored Interrupt Controller (VIC) is designed to address these require
ments. The VIC can provide interrupt performance four to five times better than the Nios II processors
default internal interrupt controller (IIC). The VIC also allows expansion to a virtually unlimited number
of interrupts, through daisy chaining.
The vectored interrupt controller (VIC) core serves the following main purposes:
Provides an interface to the interrupts in your system
Reduces interrupt overhead
Manages large numbers of interrupts
The VIC offers high-performance, low-latency interrupt handling. The VIC prioritizes interrupts in
hardware and outputs information about the highest-priority pending interrupt. When external
interrupts occur in a system containing a VIC, the VIC determines the highest priority interrupt,
determines the source that is requesting service, computes the requested handler address (RHA), and
provides information, including the RHA, to the processor.
The VIC core contains the following interfaces:
Up to 32 interrupt input ports per VIC core
One Avalon Memory-Mapped (Avalon-MM) slave interface to access the internal control status
registers (CSR)
One Avalon Streaming (Avalon-ST) interface output interface to pass information about the selected
interrupt
One optional Avalon-ST interface input interface to receive the Avalon-ST output in systems with
daisy-chained VICs
The Sample System Layout Figure below outlines the basic layout of a system containing two VIC
components.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
30-2 Supported Devices 2017.05.08
Avalon-ST
CPU
...
...
IRQ IRQ IRQ IRQ
Avalon-ST
To use the VIC, the processor in your system needs to have a matching Avalon-ST interface to accept the
interrupt information, such as the Nios II processor's external interrupt controller interface.
The characteristics of each interrupt port are configured via the Avalon-MM slave interface. When you
need more than 32 interrupt ports, you can daisy chain multiple VICs together.
Separate programmable requested interrupt level (RIL) for each interrupt
Separate programmable requested register set (RRS) for each interrupt, to tell the interrupt handler
which processor register set to use
Separate programmable requested non-maskable interrupt (RNMI) flag for each interrupt, to control
whether each interrupt is maskable or non-maskable
Software-controlled priority arbitration scheme
The VIC core is Qsys ready and integrates easily into any Qsys generated system. For the Nios II
processor, Altera provides Hardware Abstraction Layer (HAL) driver routines for the VIC core. Refer
to Altera HAL Software Programming Model section for HAL support details.
Supported Devices
The Vectored Interrupt Controller core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Send Feedback
UG-01085
2017.05.08 Functional Description 30-3
Functional Description
Figure 30-2: VIC Block Diagram
clk
(clock)
Interrupt Priority Vector interrupt_controller_out
irq_input
Request Processing Generation (Avalon-ST to processor or
(external inter rupt input)
Block Block Block to inter rupt_controller_in
interrupt_controller_in of another VIC)
(optional Avalon-ST
VIC daisy chain input)
Control Status Registers
csr_access
(Avalon-MM slave
from processor)
External Interfaces
The following sections describe the external interfaces for the VIC core.
clk
clk is a system clock interface. This interface connects to your systems main clock source. The interfaces
signals are clk and reset_n.
irq_input
irq_input comprises up to 32 single-bit, level-sensitive Avalon interrupt receiver interfaces. These
interfaces connect to interrupt sources. There is one irq signal for each interface.
interrupt_controller_out
interrupt_controller_out is an Avalon-ST output interface, as defined in the VIC Avalon-ST Interface
Fields, configured with a ready latency of 0 cycles. This interface connects to your processor or to the
interrupt_controller_in interface of another VIC. The interfaces signals are valid and data.
interrupt_controller_in
interrupt_controller_in is an optional Avalon-ST input interface, as defined in VIC Avalon-ST
Interface Fields, configured with a ready latency of 0 cycles. Include this interface in the second, third, etc,
VIC components of a daisy-chained multiple VIC system. This interface connects to the
Send Feedback
UG-01085
30-4 csr_access 2017.05.08
csr_access
csr_access is a VIC CSR interface consisting of an Avalon-MM slave interface. This interface connects to
the data master of your processor. The interfaces signals are read, write, address, readdata, and
writedata.
For information about the Avalon-MM slave and Avalon-ST interfaces, refer to the Avalon Interface
Specifications.
Related Information
Avalon Interface Specifications
Functional Blocks
The following main design blocks comprise the VIC core:
Interrupt request block
Priority processing block
Vector generation block
(17) RHA contains the 32-bit address of the interrupt handling routine.
(18)
Refer to The INT_CONFIG Register Map Table for a description of this field.
Send Feedback
UG-01085
2017.05.08 Priority Processing Block 30-5
controlled interrupts. You configure the number of interrupt input ports when you create the component.
Refer to Parameters section for configuration options.
This block contains the majority of the VIC CSRs. The CSRs are accessed via the Avalon-MM slave
interface.
Optional output from another VIC core can also come into the interrupt request block. Refer to the Daisy
Chaining VIC Cores section for more information.
Each interrupt can be driven either by its associated irq_input signal (connected to a component with an
interrupt source) or by a software trigger controlled by a CSR (even when there is no interrupt source
connected to the irq_input signal).
Figure 30-3: Interrupt Request Block
irq_input PortId[5:0]
(external inter rupt input) x32
RIL RIL[5:0]
per port x32
SW_INTERRUPT
RNMI
RNMI
per port
x32
RRS
RRS[5:0]
per port
x32
Send Feedback
UG-01085
30-6 Daisy Chaining VIC Cores 2017.05.08
The information then passes out of the vector generation block and the VIC using the Avalon-ST interface.
Refer to the VIC Avalon-ST Interface Fields table for details about the outgoing information. The output
from the VIC typically connects to a processor or another VIC, depending on the design.
Latency Information
The latency of an interrupt request traveling through the VIC is the sum of the delay through each of the
blocks. Clock delays in the interrupt request block and the vector generation block are constants. The
clock delay in the priority processing block varies depending on the total number of interrupt ports.
When daisy-chaining multiple VICs, interrupt latency increases as you move through the daisy chain away
from the processor. For best performance, assign interrupts with the lowest latency requirements to the
VIC connected directly to the processor.
Send Feedback
UG-01085
2017.05.08 Register Maps 30-7
Register Maps
The VIC core CSRs are accessible through the Avalon-MM interface. Software can configure the core and
determine current status by accessing the registers.
Each register has a 32-bit interface that is not byte-enabled. You must access these registers with a master
that is at least 32 bits wide.
Send Feedback
UG-01085
30-8 Register Maps 2017.05.08
(19)
This register contains a 1-bit field for each of the 32 interrupt inputs. When the VIC is configured for less
than 32 interrupts, the corresponding 1-bit field for each unused interrupts is tied to zero. Reading these
locations always returns 0, and writing is ignored. To determine which interrupts are present, write the
value 0xffffffff to the register and then read the register contents. Any bits that return zero do not have an
interrupt present.
Send Feedback
UG-01085
2017.05.08 Register Maps 30-9
6 RNMI R/W 0 The requested non-maskable interrupt field. RNMI contains the
non-maskable interrupt mode of the interrupt requesting service.
When 0, the interrupt is maskable. When 1, the interrupt is non-
maskable.
7:12 RRS R/W 0 The requested register set field. RRS contains the number of the
processor register set that the processor should use for processing
the interrupt. Software must ensure that only register values
supported by the processor are used.
13:31 Reserved
For expanded definitions of the terms in the INT_CONFIG Register Map table, refer to the Exception
Handling chapter of the Nios II Software Developers Handbook.
Send Feedback
UG-01085
30-10 Register Maps 2017.05.08
4:31 Reserved
6 Reserved
:
3
0
3 IP R 0 The interrupt pending field. IP indicates when there is an interrupt ready
1 to be serviced. A 1 indicates an interrupt is pending; a 0 indicates no
interrupt is pending.
Send Feedback
UG-01085
2017.05.08 Register Maps 30-11
Related Information
Exception Handling
Priority Processing Block on page 30-5
Send Feedback
UG-01085
30-12 Parameters 2017.05.08
Parameters
Generation-time parameters control the features present in the hardware.The table below lists and
describes the parameters you can configure.
Because multiple VICs can exist in a single system, Qsys assigns a unique interrupt controller identifica
tion number to each VIC generated.
Keep the following considerations in mind when connecting the core in your Qsys system:
The CSR access interface (csr_access) connects to a data master port on your processor.
The daisy chain input interface (interrupt_controller_in) is only visible when the daisy chain
enable option is on.
The interrupt controller output interface (interrupt_controller_out) connects either to the EIC
port of your processor, or to another VICs daisy chain input interface (interrupt_controller_in).
For Qsys interoperability, the VIC core includes an Avalon-MM master port. This master interface is
not used to access memory or peripherals. Its purpose is to allow peripheral interrupts to connect to
the VIC in Qsys. The port must be connected to an Avalon-MM slave to create a valid Qsys system.
Then at system generation time, the unused master port is removed during optimization. The most
simple solution is to connect the master port directly into the CSR access interface (csr_access).
Qsys automatically connects interrupt sources when instantiating components. When using the
provided HAL device driver for the VIC, daisy chaining multiple VICs in a system requires that each
interrupt source is connected to exactly one VIC. You need to manually remove any extra connections.
Send Feedback
UG-01085
2017.05.08 Altera HAL Software Programming Model 30-13
Software Files
The VIC driver includes the following software files. These files provide low-level access to the hardware
and drivers that integrate with the Nios II HAL BSP. Application developers should not modify these files.
altera_vic_regs.hDefines the cores register map, providing symbolic constants to access the
low-level hardware.
altera_vic_funnel.h, altera_vic_irq.h, altera_vic_irq.h, altera_vic_irq_init.h
Define the prototypes and macros necessary for the VIC driver.
altera_vic.c, altera_vic_irq_init.c, altera_vic_isr_register.c, altera_vic_sw_
intr.c, altera_vic_set_level.c, altera_vic_funnel_non_preemptive_nmi.S,
altera_vic_funnel_non_preemptive.S, and altera_vic_funnel_preemptive.SProvide the code that
implements the VIC driver.
altera_<name>_vector_tbl.SProvides a vector table file for each VIC in the system. The BSP
generator creates these files.
Macros
Macros to access all of the registers are defined in altera_vic_regs.h. For example, this file includes macros
to access the INT_CONFIG register, including the following macros:
For a complete list of predefined macros and utilities to access the VIC hardware, refer to the following
files:
<install_dir>\ip\altera\altera_vectored_interrupt_controller\top\inc\altera_vic_regs.h
<install_dir>\ip\altera\altera_vectored_interrupt_controller\top\HAL\inc\altera_vic_funnel.h
<install_dir>\ip\altera\altera_vectored_interrupt_controller\top\HAL\inc\altera_vic_irq.h
Send Feedback
UG-01085
30-14 Data Structure 2017.05.08
Data Structure
} alt_vic_dev;
VIC API
The VIC device driver provides all the routines required of an Altera HAL external interrupt controller
(EIC) device driver. The following functions are required by the Altera Nios II enhanced HAL interrupt
API:
alt_ic_isr_register ()
alt_ic_irq_enable()
alt_ic_irq_disable()
alt_ic_irq_enabled()
These functions write to the register map to change the setting or read from the register map to check
the status of the VIC component thru a memory-mapped address.
For detailed descriptions of these functions, refer to the to the HAL API Reference chapter of the Nios
II Software Developers Handbook.
The table below lists the API functions specific to the VIC core and briefly describes each. Details of
each function follow the table.
Related Information
HAL API Reference
Send Feedback
UG-01085
2017.05.08 alt_vic_sw_interrupt_set() 30-15
alt_vic_sw_interrupt_set()
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
The value in ic_id is invalid
The value in irq is invalid
alt_vic_sw_interrupt_clear()
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
The value in ic_id is invalid
The value in irq is invalid
alt_vic_sw_interrupt_status()
Send Feedback
UG-01085
30-16 alt_vic_irq_set_level() 2017.05.08
Returns: Returns non-zero if the corresponding software trigger interrupt is active; otherwise zero
for one or more of the following reasons:
The corresponding software trigger interrupt is disabled
The value in ic_id is invalid
The value in irq is invalid
alt_vic_irq_set_level()
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
The value in ic_id is invalid
The value in irq is invalid
The value in level is invalid
Run-time Initialization
During system initialization, software configures the each VIC instance's control registers using settings
specified in the BSP. The RIL, RRS, and RNMI fields are written into the interrupt configuration register of
each interrupt port in each VIC. All interrupts are disabled until other software registers a handler using
the alt_ic_isr_register() API.
Send Feedback
UG-01085
2017.05.08 Board Support Package 30-17
altera_vic_driver.enable_preemption
Identifier: ALTERA_VIC_DRIVER_ISR_PREEMPTION_ENABLED
Type: BooleanDefineOnly
Default value: 1 when all components connected to the VICs support
preemption. 0 when any of the connected components dont
support preemption.
Destination file: system.h
Description: Enables global interrupt preemption (nesting). When enabled
(set to 1), the macro ALTERA_VIC_DRIVER_ISR_PREEMPTION_
ENABLED is defined in system.h.
Send Feedback
UG-01085
30-18 altera_vic_driver.enable_preemption_into_new_register_set 2017.05.08
altera_vic_driver.enable_preemption_into_new_register_set
Identifier: ALTERA_VIC_DRIVER_PREEMPTION_INTO_NEW_
REGISTER_SET_ENABLED
Type: BooleanDefineOnly
Default value: 0
Destination file: system.h
Description: Enables interrupt preemption (nesting) if a higher priority
interrupt is asserted while a lower priority ISR is executing, and
that higher priority interrupt uses a different register set than
the interrupt currently being serviced.
When this setting is enabled (set to 1), the macro ALTERA_VIC_
DRIVER_ISR_PREEMPTION_INTO_NEW_REGISTER_SET_ENABLED
is defined in system.h and the Nios II config.ANI (automatic
nested interrupts) bit is asserted during system software initiali
zation.
Use this setting to limit interrupt preemption to higher priority
(RIL) interrupts that use a different register set than a lower
priority interrupt that might be executing. This setting allows
you to support some preemption while maintaining the lowest
possible interrupt response time. However, this setting does not
allow an interrupt at a higher priority (RIL) to preempt a lower
priority interrupt if the higher priority interrupt is assigned to
the same register set as the lower priority interrupt.
altera_vic_driver.enable_preemption_rs_<n>
Identifier: ALTERA_VIC_DRIVER_ENABLE_PREEMPTION_RS_<n>
Type: Boolean
Default value: 0
Destination file: system.h
Send Feedback
UG-01085
2017.05.08 altera_vic_driver.linker_section 30-19
Occurs: Per register set; <n> refers to the register set number.
altera_vic_driver.linker_section
Identifier: ALTERA_VIC_DRIVER_LINKER_SECTION
Type: UnquotedString
Default value: .text
Destination file: system.h
Send Feedback
UG-01085
30-20 altera_vic_driver.<name>.vec_size 2017.05.08
Description: Specifies the linker section that each VIC's generated vector
table and each interrupt funnel link to. The memory device that
the specified linker section is mapped to must be connected to
both the Nios II instruction and data masters in your Qsys
system.
Use this setting to link performance-critical code into faster
memory. For example, if your system's code is in DRAM and
you have an on-chip or tightly-coupled memory interface for
interrupt handling code, assigning the VIC driver linker section
to a section in that memory improves interrupt response time.
For more information about linker sections and the Nios II BSP
Editor, refer to the Getting Started with the Graphical User
Interface chapter of the Nios II Software Developers Handbook.
altera_vic_driver.<name>.vec_size
Identifier: <name>_VEC_SIZE
Type: DecimalNumber
Default value: 16
Destination file: system.h
Description: Specifies the number of bytes in each vector table entry. Legal
values are 16, 32, 64, 128, 256, and 512.
The generated VIC vector tables in the BSP require a minimum
of 16 bytes per entry.
If you intend to write your own vector table or locate your ISR
at the vector address, you can use a larger size.
The vector table's total size is equal to the number of interrupt
ports on the VIC instance multiplied by the vector table entry
size specified in this setting.
Occurs: Per instance; <name> refers to the component name you assign
in Qsys.
altera_vic_driver.<name>.irq<n>_rrs
Identifier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RRS
Type: DecimalNumber
Default value: Refer to the Default Settings for RRS and RIL section.
Send Feedback
UG-01085
2017.05.08 altera_vic_driver.<name>.irq<n>_ril 30-21
altera_vic_driver.<name>.irq<n>_ril
Identifier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RIL
Type: DecimalNumber
Default value: Refer to Default Settings for RRS and RIL section.
Destination file: system.h
Description: Specifies the RIL for the interrupt connected to the
corresponding port. Legal values are 0 to 2RIL width -1.
Occurs: Per IRQ per instance; <name> refers to the VICs name and
<n> refers to the IRQ number that you assign in Qsys. Refer to
Qsys to determine which IRQ numbers correspond to which
components in your design.
altera_vic_driver.<name>.irq<n>_rnmi
Identifier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RNMI
Type: Boolean
Default value: 0
Destination file: system.h
Description: Specifies whether the interrupt port is a maskable or non-
maskable interrupt (NMI). Legal values are 0 and 1. When set
to 0, the port is maskable. NMIs cannot be disabled in hardware
and there are several restrictions imposed for the RIL and RRS
settings associated with any interrupt with NNI enabled.
Occurs: Per IRQ per instance; <name> refers to the VICs name and
<n> refers to the IRQ number that you assign in Qsys. Refer to
Qsys to determine which IRQ numbers correspond to which
components in your design.
Send Feedback
UG-01085
30-22 Default Settings for RRS and RIL 2017.05.08
Send Feedback
UG-01085
2017.05.08 RTOS Considerations 30-23
Each components interrupt interface in your system should only be connected to one VIC instance per
processor.
The number of shadow register sets for the processor must be greater than zero.
RRS values must always be greater than zero and less than or equal to the number of shadow register
sets.
RIL values must always be greater than zero and less than or equal to the maximum RIL.
All RILs assigned to a register set must be sequential to avoid a higher priority interrupt overwriting
contents of a register set being used by a lower priority interrupt.
Note: The Nios II BSP Editor uses the term overlap condition to refer to nonsequential RIL assignments.
NMIs cannot share register sets with maskable interrupts.
NMIs must have RILs set to a number equal to or greater than the highest RIL of any maskable
interrupt. When equal, the NMIs must have a lower logical interrupt port number than any maskable
interrupt.
The vector table and funnel code section's memory device must connect to a data master and an
instruction master.
NMIs must use funnels with preemption disabled.
When global preemption is disabled, enabling preemption into a new register set or per-register-set
preemption might produce unpredictable results. Be sure that all interrupt service routines (ISR) used
by the register set support preemption.
Enabling register set preemption for register sets with peripherals that don't support preemption might
result in unpredictable behavior.
RTOS Considerations
BSPs configured to use a real time operating system (RTOS) might have additional software linked into the
HAL interrupt funnel code using the ALT_OS_INT_ENTER and ALT_OS_INT_EXIT macros. The exact nature
and overhead of this code is RTOS-specific. Additional code adds to interrupt response and recovery time.
Refer to your RTOS documentation to determine if such code is necessary.
Send Feedback
UG-01085
30-24 Adding the EIC Interface Shadow Register Set 2017.05.08
1. In Qsys, double-click the Nios II processor to open the parameter editor interface.
2. Enable the EIC interface on the Nios II processor by selecting it in the Interrupt Controller list in the
Advanced Features tab, as shown in the figure below.
There are two options for Interrupt Controller: Internal and External. If you select Internal, the
processor is implemented with the internal interrupt controller. Select External to implement the
processor with an EIC interface.
Note: When you implement the EIC interface, you must connect an EIC, such as the VIC. Failure to
connect an EIC results in a Qsys error.
3. Select the desired number of shadow register sets. In the Number of shadow register sets list, select the
number of register sets that matches your system performance goals.
4. Click Finish to exit from the Nios II parameter editor interface . Notice that the processor shows an
unconnected interrupt_controller_in Avalon-ST sink, as shown in the figure below.
Figure 30-4: Configuring the Interrupt Controller and Shadow Register Sets
Shadow register sets reduce the context switching overhead associated with saving and restoring registers,
which can otherwise be significant. If possible, add one shadow register set for each interrupt that requires
high performance.
Send Feedback
UG-01085
2017.05.08 VIC Instantiation, Parameterization, and Connection 30-25
Instantiation
To instantiate a VIC in your Qsys system, execute the following steps:
1. Browse to the IP Catalog window in Qsys.
2. Type "vector" in the search box. The interface hides all components except the VIC, as shown in the
figure below.
3. Double click the Vectored Interrupt Controller component to add this component to your Qsys System.
Figure 30-6: Vectored Interrupt Controller Component
Send Feedback
UG-01085
30-26 Parameterization 2017.05.08
Parameterization
When you add the VIC to your system, the Vectored Interrupt Controller interface appears as shown
below.
Figure 30-7: Vectored Interrupt Controller Parameterization
Send Feedback
UG-01085
2017.05.08 VIC Connections 30-27
VIC Connections
When you have added the VIC to your system, it appears in Qsys as shown below.
Note: If you have enabled daisy chaining, Qsys adds an Avalon-ST sink, called
interrupt_controller_in, to the VIC.
After adding a VIC to the Qsys system, you must parameterize the VIC and the EIC interface at the system
level. Immediately after you add the VIC, several error messages appear. Resolve these error messages by
executing the following actions in any order:
Connect the VICs interrupt_controller_out Avalon-ST source to the interrupt_controller_in
Avalon-ST sink on either the Nios II processor or the next VIC in a daisy-chained configuration.
Connect the Nios II processor's data_master Avalon-MM ports to the csr_access Avalon-MM slave
port.
Assign an interrupt number for each interrupt-based component in the system, as shown below. This
step connects each component to an interrupt port on the VIC.
Note: If your system contains more than one EIC connected to a single processor, you must ensure that
each component is connected to an interrupt port on only one EIC.
Figure 30-9: Assigning Interrupt Numbers
Send Feedback
UG-01085
30-28 Software for VIC 2017.05.08
When you use the HAL VIC driver, the driver makes a default assignment from register sets to interrupts.
The default assignment makes some assumptions about interrupt priorities, based on how devices are
connected to the VIC.
Note: To make effective use of the VIC interrupt setting defaults, assign your highest priority interrupts to
low interrupt port numbers on the VIC closest to the processor.
#ifdef ALT_ENHANCED_INTERRUPT_API_PRESENT
void timer_interrupt_latency_init (void* base, alt_u32 irq_controller_id,
alt_u32 irq)
{
/* Register the interrupt */
alt_ic_isr_register(irq_controller_id, irq, timer_interrupt_latency_irq,
base, NULL);
/* Start timer */
IOWR_ALTERA_AVALON_TIMER_CONTROL(base, ALTERA_AVALON_TIMER_CONTROL_ITO_MSK
| ALTERA_AVALON_TIMER_CONTROL_START_MSK);
}
#else
void timer_interrupt_latency_init (void* base, alt_u32 irq)
{
/* Register the interrupt */
alt_irq_register(irq, base, timer_interrupt_latency_irq);
/* Start timer */
IOWR_ALTERA_AVALON_TIMER_CONTROL(base, ALTERA_AVALON_TIMER_CONTROL_ITO_MSK
| ALTERA_AVALON_TIMER_CONTROL_START_MSK);
}
#endif
Send Feedback
UG-01085
2017.05.08 alt_ic_isr_register() versus alt_irq_register() 30-29
The first line of Example 30-2 detects whether the BSP implements the enhanced interrupt API. If the
enhanced API is implemented, the timer_interrupt_latency_init() function calls the enhanced
function. If not, timer_interrupt_latency_init() reverts to the legacy interrupt API function.
For an explanation of how the Nios II Software Build Tools select which API to implement in a BSP, refer
to Interrupt Service Routines in the Exception Handling chapter of the Nios II Software Developers
Handbook.
Example 30-3 shows the function prototype for alt_ic_isr_register(), which registers an ISR in the
enhanced API. The interrupt controller identifier (for argument ic_id) and the interrupt port number (for
argument irq) are defined in system.h.
For comparison, Example 30-4 shows the function prototype for alt_irq_register(), which
registers an ISR in the legacy API.
The arguments passed into alt_ic_isr_register() are slightly different from those passed into
alt_irq_register(). The table below compares the arguments to the two functions.
Send Feedback
UG-01085
30-30 Example Designs 2017.05.08
There are other significant differences between the legacy interrupt API and the enhanced interrupt API.
Some of these differences impact the ISR body itself. Notably, the two APIs employ completely different
interrupt preemption models. The example code accompanying this document illustrates many of the
differences.
For further information about the other functions in the HAL interrupt APIs, refer to the Exception
Handling and HAL API Reference chapters of the Nios II Software Developers Handbook.
Related Information
Exception Handling
HAL API Reference
Example Designs
This section provides a brief description of the example designs provided with this document to
demonstrate the usage of the VIC. Additionally, this section provides instructions for running the software
examples on the Cyclone V SoC development kit.
Related Information
VIC_collateral_cv.zip
Example Description
The example designs are provided in a file called VIC_collateral_cv.zip. VIC_collateral_cv.zip is available
on the Documentation: Nios II Processor page of the Altera website under Vectored Interrupt
Controller Design Files.
The top-level folder in VIC_collateral_cv.zip, called VIC_collateral_cv, contains the following files:
run_sw.shShell script to run one, several or all of the examples
README.txtDescribes the .zip file contents
Send Feedback
UG-01085
2017.05.08 Example Description 30-31
Send Feedback
UG-01085
30-32 Example Usage 2017.05.08
The IIC design is the same as the VIC Basic design, with the VIC and the EIC interface replaced by the
IIC. The VIC Table-Resident design is identical to the VIC Basic design.
In each example, the software uses timers in conjunction with performance counters to measure the
interrupt performance. Each examples software calculates the performance and sends the results to stdout.
VIC_collateral_cv.zip includes a script, run_sw.sh, to run one, several, or all of the example. run_sw.sh
downloads the SRAM Object File (.sof) and the Executable and Linkable Format File (.elf) for each
example, and executes the code on the Cyclone V SoC, for the examples that you specify on the command
line.
Note: run_sw.sh assumes that you have only one JTAG download cable connected to your host computer.
If you have multiple JTAG cables, you must modify run_sw.sh to specify the cable connected to
your Cyclone V SoC development kit.
Related Information
Documentation: Nios II Processor
VIC_collateral_cv.zip
Example Usage
Initially, Altera recommends that you run each example design as distributed, to see the examples
performance on your own hardware. Thereafter, you can modify any of the examples to investigate the
VICs performance options, or customize the code for you application.
Execute the following steps to run each example design:
1. Power up your Cyclone V SoC board.
2. Connect the USB cable.
3. Unzip the VIC_collateral_cv.zip file to a working directory, expanding folder names.
Note: The path name to your working directory must not contain any spaces.
4. In a Nios II Command Shell, change to the top-level directory, VIC_collateral_cv.
5. At the command prompt, type the following command:
./run_sw.sh
Software Description
The software for the various example designs is very similar. For example, the difference between the
software for the VIC Basic example and the software for the IIC example is the printf() call that
generates the output to the terminal.
Send Feedback
UG-01085
2017.05.08 Software Description 30-33
Send Feedback
UG-01085
30-34 Software Description 2017.05.08
Related Information
Positioning the ISR in Vector Table on page 30-35
Latency Measurement with the Performance Counter on page 30-36
Send Feedback
UG-01085
2017.05.08 Positioning the ISR in Vector Table 30-35
When the ISR is in the vector table, the HAL does not provide funnel code. Therefore, the ISR code must
perform any context-switching actions normally handled by the funnel. Funnel context switching can
include some or all of the following actions:
Saving and restoring registers
Managing preemption
Managing the stack pointer
To create the fastest possible ISR, minimize or eliminate the context-switching actions your ISR must
perform by conforming to the following guidelines:
Write the ISR in assembly language
Assign a shadow register set for the ISRs use
Ensure that the ISR cannot be preempted by another ISR using the same register set. By default,
preemption within a register set is disabled on the Nios II processor. You can also ensure this condition
by giving the ISR exclusive access to its register set.
The VIC Table-Resident example requires modifying a BSP-generated file, altera_vic1_vector_tbl.S. If you
regenerate the BSP after making these modifications, the Nios II Software Build Tools regenerate
altera_vic1_vector_tbl.S, and your changes are overwritten.
Related Information
Software Description on page 30-32
Send Feedback
UG-01085
30-36 Insert ISR in Vector Table 2017.05.08
#include "altera_vic_funnel.h"
#include "vector.h" /* ADD THIS LINE MANUALLY */
.section .text
.align 2
.globl VIC1_VECTOR_TABLE
VIC1_VECTOR_TABLE:
MY_ISR 256 /* THIS LINE REPLACES THE FIRST VECTOR
TABLE ENTRY */
ALT_SHADOW_NON_PREEMPTIVE_INTERRUPT 256
ALT_SHADOW_NON_PREEMPTIVE_INTERRUPT 256
ALT_SHADOW_NON_PREEMPTIVE_INTERRUPT 256
ALT_SHADOW_NON_PREEMPTIVE_INTERRUPT 256
After completion of these steps, build the software, run it, and observe the reported interrupt time. This
example is about 18 clock cycles faster than the unmodified VIC Basic example.
Some variation is likely for reasons discussed in Real-Time Latency Concerns.
Related Information
Real Time Latency Concerns on page 30-37
Send Feedback
UG-01085
2017.05.08 Advanced Topics 30-37
Advanced Topics
This section presents several topics that are useful for advanced interrupt handling.
Interrupt Request
Time
Background Background
ISR Code
Cause,
Selection
&
Funnel
Pipeline Latency Latency
Interrupt Recovery
(Back-end Funnel)
Interrupt Latency
This section summarizes each element of latency and describes how to measure latency. The accompa
nying example designs use the performance counter core to capture all of the timing measurements.
Performance counter core usage is described in Latency Measurement with the Performance Counter.
Related Information
Insert ISR in Vector Table on page 30-36
Latency Measurement with the Performance Counter on page 30-36
Send Feedback
UG-01085
30-38 Pipeline Latency 2017.05.08
Pipeline Latency
Pipeline latency is defined as the number of clock cycles between an interrupt signal being asserted and
the execution of the first instruction at the exception vector. It can vary widely, depending on the type of
memory the processor is executing from and the impact of other master ports in your hardware. Theoreti
cally, this time could be infinite if an ill-behaved master port blocks the processor from accessing memory,
freezing the processor.
Cause Latency
Cause latency is the time required for the processor to identify an exception as a hardware interrupt. With
an EIC, such as the VIC, the cause latency is zero because each hardware interrupt has a dedicated
interrupt vector address, separate from the software exception vector address.
Selection Latency
Selection latency is the time required for the system to transfer control to the correct interrupt vector,
depending on which interrupt is triggered. The selection latency with the VIC component depends on the
number of interrupts that it services. The table below outlines selection latency on a single VIC as a
function of the number of interrupts.
Funnel Latency
Funnel latency is the time required for the interrupt funnel to switch context. Funnel latency can include
saving and restoring registers, managing preemption, and managing the stack pointer. Funnel latency
depends on the following factors:
Whether a separate interrupt stack is used
The number of clock cycles required for load and store instructions
Whether the interrupt requires switching to a different register set
Whether the interrupt is preempting another interrupt within the same register set
Whether preemption within the register set is allowed
Preemption within the register set requires special attention. The HAL VIC driver provides special funnel
code if an interrupt is allowed to preempt another interrupt assigned to the same register set. In this case,
the funnel incurs additional overhead to save and restore the register contents. When creating the BSP, you
can control preemption within the register set by using the VIC drivers
altera_vic_driver_enable_preemption_rs_<n> setting.
Note: With tightly-coupled memory, the Nios II processor can execute a load or store instruction in 1
clock cycle. With onchip memory, not tightly-coupled, the processor requires two clock cycles.
Send Feedback
UG-01085
2017.05.08 Funnel Latency 30-39
42 64
Same register set Same register set (sstatus.SRS=0)
(sstatus.SRS=0)
27 33
Different register set Different register set (sstatus.SRS=1)
Shadow register set, (sstatus.SRS=1) Not preempting another interrupt
preemption within the Not preempting another (sstatus.IH=0)
register set enabled interrupt (sstatus.IH=0)
28 34
Different register set Different register set (sstatus.SRS=1)
(sstatus.SRS=1) Preempting another interrupt
Preempting another (sstatus.IH=1)
interrupt (sstatus.IH=1)
Send Feedback
UG-01085
30-40 Compiler-Related Latency 2017.05.08
In the tables above, notice that the lowest latencies occur under the following conditions:
A different register setShadow register set switch; the ISR runs in a different register set from the
interrupted task, eliminating any need to save or restore registers.
Preemption (nesting) within the register set disabled.
Conversely, the highest latencies occur under the following conditions:
The same register setNo shadow register set switch; the ISR runs in the same register set as the
interrupted task, requiring the funnel code to save and restore registers.
Preemption within the register set enabled.
Of these two important factors, preemption makes the largest difference in latencies. With preemption
disabled, much lower latencies occur regardless of other factors.
Compiler-Related Latency
The GNU C compiler creates a prologue and epilogue for many C functions, including ISRs. The prologue
and epilogue are code sequences that take care of housekeeping tasks, such as saving and restoring context
for the C runtime environment. The time required for the prologue and epilogue is called compiler-related
latency.
The C compiler generates a prologue and epilogue as needed. If compiler optimization is enabled, and the
routine is compact, with few local variables, the prologue and epilogue are usually omitted. You can
determine whether a prologue and epilogue are generated by examining the functions assembly code.
Compiler latency normally has only a minor impact on overall interrupt servicing performance. If you are
concerned about compiler latency, you have two options:
Enable compiler optimizations, and simplify your ISR, minimizing local variables.
Write your ISR in assembly language.
Software Interrupt
Software can trigger any VIC interrupt by writing to the appropriate VIC control and status register (CSR).
Software can trigger the interrupt connected to any hardware interrupt source, as well as interrupts that
are not connected to hardware (software-only interrupts).
Triggering an interrupt from software is useful for debugging. Software can control exactly when an
interrupt is triggered, and measure the systems interrupt response.
You can use a software-only interrupt to reprioritize an interrupt. An ISR that responds to a high-priority
hardware interrupt can perform the minimum processing required by the hardware, and then trigger a
software-only interrupt at a lower priority level to complete the interrupt processing.
The following functions are available for managing software interrupts:
alt_vic_sw_interrupt_set()
alt_vic_sw_interrupt_clear()
alt_vic_sw_interrupt_status()
The implementations of these functions are in bsp/hal/drivers/src/altera_vic_sw_intr.c after you generate
the BSP.
Note: You must define a value for the interrupt number in SOFT_IRQ.
Send Feedback
UG-01085
2017.05.08 Document Revision History 30-41
alt_ic_isr_register(
VIC1_INTERRUPT_CONTROLLER_ID,
SOFT_IRQ,
soft_interrupt_latency_irq,
NULL, NULL)
alt_ic_isr_register(
LATENCY_TIMER_IRQ_INTERRUPT_CONTROLLER_ID,
LATENCY_TIMER_IRQ,
timer_interrupt_latency_irq,
LATENCY_TIMER_BASE,
NULL);
Send Feedback
2017.05.08
System ID Core
31
UG-01085 Subscribe Send Feedback
Core Overview
The system ID core with Avalon interface is a simple read-only device that provides Qsys systems with a
unique identifier. Nios II processor systems use the system ID core to verify that an executable program
was compiled targeting the actual hardware image configured in the target FPGA. If the expected ID in the
executable does not match the system ID core in the FPGA, it is possible that the software will not execute
correctly.
Supported Devices
The System ID core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The system ID core provides a read-only Avalon Memory-Mapped (Avalon-MM) slave interface. This
interface has two 32-bit registers, as shown in the table below. The value of each register is determined at
system generation time, and always returns a constant value.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
31-2 Configuration 2017.05.08
Configuration
The id and timestamp register values are determined at system generation time based on the
configuration of the Qsys system and the current time. You can add only one system ID core to an Qsys
system, and its name is always sysid.
After system generation, you can examine the values stored in the id and timestamp registers by opening
the MegaWizard interface for the System ID core.
Since a unique timestamp value is added to the System ID HDL file each time you generate the Qsys
system, the Quartus Prime software recompiles the entire system if you have added the system as a design
partition.
alt_avalon_sysid_test()
Send Feedback
UG-01085
2017.05.08 Document Revision History 31-3
Description: Returns 0 if the values stored in the hardware registers match the values expected by
software. Returns 1 if the hardware timestamp is greater than the software timestamp.
Returns -1 if the software timestamp is greater than the hardware timestamp.
November 2009 v9.1.0 Added description to the Instantiating the Core in SOPC Builder
section.
March 2009 v9.0.0 No change from previous release.
Send Feedback
2017.05.08
Performance Counter Core
32
UG-01085 Subscribe Send Feedback
Core Overview
The performance counter core with Avalon interface enables relatively unobtrusive, real-time profiling of
software programs. With the performance counter, you can accurately measure execution time taken by
multiple sections of code. You need only add a single instruction at the beginning and end of each section
to be measured.
The main benefit of using the performance counter core is the accuracy of the profiling results. Alterna
tives include the following approaches:
GNU profiler, gprofgprof provides broad low-precision timing information about the entire
software system. It uses a substantial amount of RAM, and degrades the real-time performance. For
many embedded applications, gprof distorts real-time behavior too much to be useful.
Interval timer peripheralThe interval timer is less intrusive than gprof. It can provide good results
for narrowly targeted sections of code.
The performance counter core is unobtrusive, requiring only a single instruction to start and stop
profiling, and no RAM. It is appropriate for high-precision measurements of narrowly targeted sections
of code.
For further discussion of all three profiling methods, refer to AN 391: Profiling Nios II Systems.
The core is designed for use in Avalon-based processor systems, such as a Nios II processor system.
Altera device drivers enable the Nios II processor to use the performance counters.
Supported Devices
The Performance Counter core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The performance counter core is a set of counters which track clock cycles, timing multiple sections of
your software. You can start and stop these counters in your software, individually or as a group. You can
read cycle counts from hardware registers.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
32-2 Section Counters 2017.05.08
Section Counters
Each 64-bit time counter records the aggregate number of clock cycles spent in a section of code. The 32-
bit event counter records the number of times the section executes.
The performance counter core can have up to seven section counters.
Global Counter
The global counter controls all section counters. The section counters are enabled only when the global
counter is running.
The 64-bit global clock cycle counter tracks the aggregate time for which the counters were enabled. The
32-bit global event counter tracks the number of global events, that is, the number of times the perform
ance counter core has been enabled.
Register Map
The performance counter core has an Avalon Memory-Mapped (Avalon-MM) slave interface that provides
access to memory-mapped registers. Reading from the registers retrieves the current times and event
counts. Writing to the registers starts, stops, and resets the counters.
Send Feedback
UG-01085
2017.05.08 System Reset 32-3
Bit Description
Offset Register Name Read Write
31 ... 0 31 ... 1 0
. . . . .
. . . . .
. . . . .
System Reset
After a system reset, the performance counter core is stopped and disabled, and all counters are set to zero.
Configuration
The following sections list the available options in the MegaWizard interface.
Define Counters
Choose the number of section counters you want to generate by selecting from the Number of
simultaneously-measured sections list. The performance counter core may have up to seven sections. If
you require more that seven sections, you can instantiate multiple performance counter cores.
Send Feedback
UG-01085
32-4 Software Files 2017.05.08
Software Files
Altera provides the following software files for Nios II systems. These files define the low-level access to the
hardware and provide control and reporting functions. Do not modify these files.
altera_avalon_performance_counter.h, altera_avalon_performance_counter.c
The header and source code for the functions and macros needed to control the performance counter
core and retrieve raw results.
perf_print_formatted_report.cThe source code for simple profile reporting.
For a complete description of each macro and function, see the Performance counter API section.
Hardware Constants
You can get the performance counter hardware parameters from constants defined in system.h. The
constant names are based on the performance counter instance name, specified on the System Contents
tab in Qsys.
Send Feedback
UG-01085
2017.05.08 Using the Performance Counter 32-5
Startup
Before using the performance counter core, invoke PERF_RESET to stop, disable and zero all counters.
perf_print_formatted_report(
(void *)PERFORMANCE_COUNTER_BASE, // Peripheral's HW base address
alt_get_cpu_freq(), // defined in "system.h"
3, // How many sections to print
"1st checksum_test", // Display-names of sections
"pc_overhead",
"ts_overhead");
Send Feedback
UG-01085
32-6 Interrupt Behavior 2017.05.08
+-----------------+--------+-----------+---------------+-----------+
+-----------------+--------+-----------+---------------+-----------+
+-----------------+--------+-----------+---------------+-----------+
+-----------------+--------+-----------+---------------+-----------+
+-----------------+--------+-----------+---------------+-----------+
For full documentation of perf_print_formatted_report(), see the Performance and Counter API
section.
Interrupt Behavior
The performance counter core does not generate interrupts.
You can start and stop performance counters, and read raw performance results, in an interrupt service
routine (ISR). Do not call the perf_print_formatted_report() function from an ISR.
If an interrupt occurs during the measurement of a section of code, the time taken by the CPU to process
the interrupt and return to the section is added to the measurement time. The same applies to context
switches in a multithreaded environment. Your software must take appropriate measures to avoid or
handle these situations.
PERF_RESET()
Prototype: PERF_RESET(p)
Thread-safe: Yes.
Available Yes.
from ISR:
Include: <altera_avalon_performance_counter.h>
Send Feedback
UG-01085
2017.05.08 PERF_START_MEASURING() 32-7
Returns:
Description: Macro PERF_RESET() stops and disables all counters, resetting them to 0.
PERF_START_MEASURING()
Prototype: PERF_START_MEASURING(p)
Thread-safe: Yes.
Available Yes.
from ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: pperformance counter core base address.
Returns:
Description: Macro PERF_START_MEASURING() starts the global counter, enabling the
performance counter core. The behavior of individual section counters is
controlled by PERF_BEGIN() and PERF_END(). PERF_START_MEASURING() defines
the start of a global event, and increments the global event counter. This macro is
a single write to the performance counter core.
PERF_STOP_MEASURING()
Prototype: PERF_STOP_MEASURING(p)
Thread-safe: Yes.
Available from Yes.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: pperformance counter core base address.
Returns:
Description: Macro PERF_STOP_MEASURING() stops the global counter, disabling the perform
ance counter core. This macro is a single write to the performance counter core.
PERF_BEGIN()
Prototype: PERF_BEGIN(p,n)
Thread-safe: Yes.
Send Feedback
UG-01085
32-8 PERF_END() 2017.05.08
Returns:
Description: Macro PERF_BEGIN() starts the timer for a code section, defining the beginning
of a section event, and incrementing the section event counter. If you
subsequently use PERF_STOP_MEASURING() and PERF_START_MEASURING() to
disable and re-enable the core, the section counter will resume. This macro is a
single write to the performance counter core.
PERF_END()
Prototype: PERF_END(p,n)
Thread-safe: Yes.
Available from Yes.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: pperformance counter core base address.
Returns:
Description: Macro PERF_END() stops timing a code section. The section counter does not
run, regardless whether the core is enabled or not. This macro is a single write to
the performance counter core.
perf_print_formatted_report()
void* perf_base,
alt_u32 clock_freq_hertz,
int num_sections,
char* section_name_n)
Send Feedback
UG-01085
2017.05.08 perf_get_total_time() 32-9
Thread-safe: No.
Available from No.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: perf_basePerformance counter core base address.
clock_freq_hertzClock frequency.
Returns: 0
Description: Function perf_print_formatted_report() reads the profiling results from the
performance counter core, and prints a formatted summary table.
This function disables all counters. However, for predictable results in a multi-
threaded or interrupt environment, invoke PERF_STOP_MEASURING() when you
reach the end of the code to be measured, rather than relying on perf_print_
formatted_report().
perf_get_total_time()
Thread-safe: No.
Available from Yes.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: hw_base_addressbase address of performance counter core.
perf_get_section_time()
Thread-safe: No.
Send Feedback
UG-01085
32-10 perf_get_num_starts() 2017.05.08
perf_get_num_starts()
Thread-safe: Yes.
Available from Yes.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters: hw_base_addressperformance counter core base address.
alt_get_cpu_freq()
Thread-safe: Yes.
Available from Yes.
ISR:
Include: <altera_avalon_performance_counter.h>
Parameters:
Returns: CPU frequency in Hz.
Send Feedback
UG-01085
2017.05.08 Document Revision History 32-11
May 2008 v8.0.0 Updated the parameter description of the function perf_print_
formatted_report().
Send Feedback
2017.05.08
Avalon Streaming Test Pattern Generator and
Checker Cores 33
UG-01085 Subscribe Send Feedback
Core Overview
The data generation and monitoring solution for Avalon Streaming (Avalon-ST) consists of two
components: a test pattern generator core that generates packetized or non-packetized data and sends it
out on an Avalon-ST data interface, and a test pattern checker core that receives the same data and checks
it for correctness.
The test pattern generator core can insert different error conditions, and the test pattern checker reports
these error conditions to the control interface, each via an Avalon Memory-Mapped (Avalon-MM) slave.
Supported Devices
The Avalon Streaming Test Pattern Generator and Checker cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Table 33-1: Test Pattern Generator Estimated Resource Utilization and Performance
Datawi Stratix II and Stratix II GX Cyclone II Stratix
dth
fMAX ALM Memor fMAX Logic Memor fMAX Logic Memory
No. of (No. of Packet
Channe 8-bit Suppor (MHz) Count y (bits) Cells y (bits) Cells (bits)
(MHz) (MHz)
ls Symbol t
s Per
Beat)
1 4 Yes 284 233 560 206 642 560 202 642 560
1 4 No 293 222 496 207 572 496 245 561 496
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
33-2 Test Pattern Generator 2017.05.08
Datawi Stratix II and Stratix II GX Cyclone II Stratix
dth
fMAX ALM Memor fMAX Logic Memor fMAX Logic Memory
No. of (No. of Packet
Channe 8-bit Suppor (MHz) Count y (bits) Cells y (bits) Cells (bits)
(MHz) (MHz)
ls Symbol t
s Per
Beat)
32 4 Yes 276 270 912 210 683 912 197 707 912
32 4 No 323 227 848 234 585 848 220 630 848
1 16 Yes 298 361 560 228 867 560 245 896 560
1 16 No 340 330 496 230 810 496 228 845 496
32 16 Yes 295 410 912 209 954 912 224 956 912
32 16 No 269 409 848 219 842 848 204 912 848
Table 33-2: Test Pattern Checker Estimated Resource Utilization and Performance
Datawi Stratix II and Stratix II GX Cyclone II Stratix
dth
fMAX ALM Memor fMAX Logic Memor fMAX Logic Memory
No. of (No. of Packet
y (bits) Cells y (bits) Cells (bits)
Channe 8-bit Suppor (MHz) Count (MHz) (MHz)
ls Symbol t
s Per
Beat)
1 4 Yes 270 271 96 179 940 0 174 744 96
1 4 No 371 187 32 227 628 0 229 663 32
32 4 Yes 185 396 3616 111 875 3854 105 795 3616
32 4 No 221 363 3520 133 686 3520 133 660 3520
1 16 Yes 253 462 96 185 1433 0 166 1323 96
1 16 No 277 306 32 218 1044 0 192 1004 32
32 16 Yes 182 582 3616 111 1367 3584 110 1298 3616
32 16 No 218 473 3520 129 1143 3520 126 1074 3520
Functional Description
The test pattern generator core accepts commands to generate data via an Avalon-MM command
interface, and drives the generated data to an Avalon-ST data interface. You can parameterize most aspects
of the Avalon-ST data interface such as the number of error bits and data signal width, thus allowing you
to test components with different interfaces.
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Configuration 33-3
Avalon-MM
Slave Port
Ava lo n -MM
S la ve P o r t
Ava lo n -S T
S o u rc e
command TEST PATTERN data_out
GENERATOR
Command Interface
The command interface is a 32-bit Avalon-MM write slave that accepts data generation commands. It is
connected to a 16-element deep FIFO, thus allowing a master peripheral to drive a number of commands
into the test pattern generator core.
The command interface maps to the following registers: cmd_lo and cmd_hi. The command is pushed into
the FIFO when the register cmd_lo (address 0) is written to. When the FIFO is full, the command interface
asserts the waitrequest signal. You can create errors by writing to the register cmd_hi (address 1). The
errors are only cleared when 0 is written to this register or its respective fields. See page the Test Pattern
Generator Command Registers section for more information on the register fields.
Output Interface
The output interface is an Avalon-ST interface that optionally supports packets. You can configure the
output interface to suit your requirements.
Depending on the incoming stream of commands, the output data may contain interleaved packet
fragments for different channels. To keep track of the current symbols position within each packet, the test
pattern generator core maintains an internal state for each channel.
Configuration
The following sections list the available options in the MegaWizard interface.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-4 Test Pattern Checker 2017.05.08
Functional Parameter
The functional parameter allows you to configure the test pattern generator as a whole: Throttle Seed
The starting value for the throttle control random number generator. Altera recommends a value which is
unique to each instance of the test pattern generator and checker cores in a system.
Output Interface
You can configure the output interface of the test pattern generator core using the following parameters:
Number of ChannelsThe number of channels that the test pattern generator core supports. Valid
values are 1 to 256.
Data Bits Per SymbolThe number of bits per symbol for the input and output interfaces. Valid values
are 1 to 256. ExampleFor typical systems that carry 8-bit bytes, set this parameter to 8.
Data Symbols Per BeatThe number of symbols (words) that are transferred per beat. Valid values
are 1 to 256.
Include Packet SupportIndicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
Error Signal Width (bits)The width of the error signal on the output interface. Valid values are 0 to
31. A value of 0 indicates that the error signal is not used.
Functional Description
The test pattern checker core accepts data via an Avalon-ST interface, checks it for correctness against the
same predetermined pattern used by the test pattern generator core to produce the data, and reports any
exceptions to the control interface. You can parameterize most aspects of the test pattern checker's Avalon-
ST interface such as the number of error bits and the data signal width, thus allowing you to test
components with different interfaces.
The test pattern checker has a throttle register that is set via the Avalon-MM control interface. The value of
the throttle register controls the rate at which data is accepted.
Figure 33-1: Test Pattern Checker
Avalon-MM
Slave Port
Avalon-ST
data_in
Sink
TESTPATTERN
CHECKER
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Configuration 33-5
The test pattern checker core detects exceptions and reports them to the control interface via a 32-element
deep internal FIFO. Possible exceptions are data error, missing start-of-packet (SOP), missing end-of-
packet (EOP) and signalled error.
As each exception occurs, an exception descriptor is pushed into the FIFO. If the same exception occurs
more than once consecutively, only one exception descriptor is pushed into the FIFO. All exceptions are
ignored when the FIFO is full. Exception descriptors are deleted from the FIFO after they are read by the
control and status interface.
Input Interface
The input interface is an Avalon-ST interface that optionally supports packets. You can configure the input
interface to suit your requirements.
Incoming data may contain interleaved packet fragments. To keep track of the current symbols position,
the test pattern checker core maintains an internal state for each channel.
Configuration
The following sections list the available options in the MegaWizard interface.
Functional Parameter
The functional parameter allows you to configure the test pattern checker as a whole: Throttle SeedThe
starting value for the throttle control random number generator. Altera recommends a unique value to
each instance of the test pattern generator and checker cores in a system.
Input Parameters
You can configure the input interface of the test pattern checker core using the following parameters:
Data Bits Per SymbolThe number of bits per symbol for the input interface. Valid values are 1 to
256.
Data Symbols Per BeatThe number of symbols (words) that are transferred per beat. Valid values
are 1 to 32.
Include Packet SupportIndicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
Number of ChannelsThe number of channels that the test pattern checker core supports. Valid
values are 1 to 256.
Error Signal Width (bits)The width of the error signal on the input interface. Valid values are 0 to
31. A value of 0 indicates that the error signal is not in use.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-6 Hardware Simulation Considerations 2017.05.08
Software Files
The following software files define the low-level access to the hardware, and provide the routines for the
HAL device drivers. Application developers should not modify these files.
Software files provided with the test pattern generator core:
data_source_regs.hThe header file that defines the test pattern generator's register maps.
data_source_util.h, data_source_util.cThe header and source code for the functions
and variables required to integrate the driver into the HAL system library.
Software files provided with the test pattern checker core:
data_sink_regs.hThe header file that defines the cores register maps.
data_sink_util.h, data_sink_util.cThe header and source code for the functions and
variables required to integrate the driver into the HAL system library.
Register Maps
This section describes the register maps for the test pattern generator and checker cores.
Test Pattern Generator Control and Status Registers
The table below shows the offset for the test pattern generator control and status registers. Each register is
32 bits wide.
Table 33-3: Test Pattern Generator Control and Status Register Map
Offset Register Name
base + 0 status
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Register Maps 33-7
base + 2 fill
[17] SOFT RESET RW When this bit is set to 1, all internal counters and statistics are reset.
Write 0 to this bit to exit reset.
[31:18] Reserved
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-8 Register Maps 2017.05.08
base + 1 cmd_hi
The command is pushed into the FIFO only when the cmd_lo register is written to.
Table 33-10: Test Pattern Checker Control and Status Register Map
Offset Register Name
base + 0 status
base + 1 control
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Register Maps 33-9
base + 6 indirect_select
base + 7 indirect_count
[17] SOFT RESET RW When this bit is set to 1, all internal counters and statistics are reset.
Write 0 to this bit to exit reset.
[31:18] Reserved
The table below describes the exception_descriptor register bits. If there is no exception, reading this
register returns 0.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-10 Test Pattern Generator API 2017.05.08
[23:16] Reserved
[31:24] CHANNEL RO The channel on which the exception was detected.
data_source_reset()
Thread-safe: No.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Returns: void.
Description: This function resets the test pattern generator core including all internal counters
and FIFOs. The control and status registers are not reset by this function.
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 data_source_init() 33-11
data_source_init()
Thread-safe: No.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Description: This function performs the following operations to initialize the test pattern
generator core:
Resets and disables the test pattern generator core.
Sets the maximum throttle.
Clears all inserted errors.
data_source_get_id()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_get_supports_packets()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Description: This function checks if the test pattern generator core supports packets.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-12 data_source_get_num_channels() 2017.05.08
data_source_get_num_channels()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_get_symbols_per_cycle()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_set_enable()
Thread-safe: No.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Returns: void.
Description: This function enables or disables the test pattern generator core. When disabled,
the test pattern generator core stops data transmission but continues to accept
commands and stores them in the FIFO.
data_source_get_enable()
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 data_source_set_throttle() 33-13
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_set_throttle()
Thread-safe: No.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Returns: void.
Description: This function sets the throttle value, which can be between 0256 inclusively. The
throttle value, when divided by 256 yields the rate at which the test pattern
generator sends data.
data_source_get_throttle()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_is_busy()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-14 data_source_fill_level() 2017.05.08
Description: This function checks if the test pattern generator is busy. The test pattern
generator core is busy when it is sending data or has data in the command FIFO
to be sent.
data_source_fill_level()
Thread-safe: Yes.
Include: <data_source_util.h>
Parameters: baseThe base address of the control and status slave.
data_source_send_data()
Thread-safe: No.
Include: <data_source_util.h>
Parameters: cmd_baseThe base address of the command slave.
flagsSpecifies whether to send or suppress SOP and EOP signals. Valid values
are DATA_SOURCE_SEND_SOP, DATA_SOURCE_SEND_EOP, DATA_SOURCE_SEND_
SUPRESS_SOP and DATA_SOURCE_SEND_SUPRESS_EOP.
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Test Pattern Checker API 33-15
data_sink_reset()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Returns: void.
Description: This function resets the test pattern checker core including all internal counters.
data_sink_init()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-16 data_sink_get_id() 2017.05.08
Description: This function performs the following operations to initialize the test pattern
checker core:
Resets and disables the test pattern checker core.
Sets the throttle to the maximum value.
data_sink_get_id()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
data_sink_get_supports_packets()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Description: This function checks if the test pattern checker core supports packets.
data_sink_get_num_channels()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 data_sink_get_symbols_per_cycle() 33-17
data_sink_get_symbols_per_cycle()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
data_sink_set enable()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Returns: void.
data_sink_get_enable()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
data_sink_set_throttle()
Thread-safe: No.
Include: <data_sink_util.h>
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-18 data_sink_get_throttle() 2017.05.08
Returns: void.
Description: This function sets the throttle value, which can be between 0256 inclusively. The
throttle value, when divided by 256 yields the rate at which the test pattern
checker receives data.
data_sink_get_throttle()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
data_sink_get_packet_count()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
channelChannel number.
data_sink_get_symbol_count()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
channelChannel number.
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 data_sink_get_error_count() 33-19
data_sink_get_error_count()
Thread-safe: No.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
channelChannel number.
data_sink_get_exception()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: baseThe base address of the control and status slave.
Description: This function retrieves the first exception descriptor in the exception FIFO and
pops it off the FIFO.
data_sink_exception_is_exception()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor
Description: This function checks if a given exception descriptor describes a valid exception.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
33-20 data_sink_exception_has_data_error() 2017.05.08
data_sink_exception_has_data_error()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor.
data_sink_exception_has_missing_sop()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor.
Description: This function checks if a given exception descriptor indicates missing SOP.
data_sink_exception_has_missing_eop()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor.
Description: This function checks if a given exception descriptor indicates missing EOP.
data_sink_exception_signalled_error()
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 data_sink_exception_channel() 33-21
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor.
data_sink_exception_channel()
Thread-safe: Yes.
Include: <data_sink_util.h>
Parameters: exceptionException descriptor.
Table 33-16: Avalon Streaming Test Pattern Generator and Checker Cores Revision History
Date Version Changes
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 No change from previous release.
May 2008 v8.0.0 Updated the section on HAL System Library Support.
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
2017.05.08
Avalon Streaming Data Pattern Generator and
Checker Cores 34
UG-01085 Subscribe Send Feedback
Core Overview
The data generation and monitoring solution for Avalon Streaming (Avalon-ST) interfaces consists of two
components: a data pattern generator core that generates data patterns and sends it out on an Avalon-ST
interface, and a data pattern checker core that receives the same data and checks it for correctness.
Supported Devices
The Avalon Streaming Data Pattern Generator and Checker cores supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The data pattern generator core accepts commands to generate and drive data onto a parallel Avalon-ST
source interface.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
34-2 Functional Description 2017.05.08
Avalon-MM
Slave Port
Avalon-ST
Source
data_out
DATA PATTERN
GENER ATOR
You can configure the width of the output data signal to either 32-bit or 40-bit when instantiating the core.
You can configure this core to output 8-bit or 10-bit wide symbols. By default, the core generates 4 symbols
per beat, which outputs 32-bit or 40-bit wide data to the Avalon-ST interfaces, respectively. The cores data
format endianness is the most significant symbol first within a beat and the most significant bit first within
a symbol. For example, when you configure the output data to 32-bit, bit 31 is the first data bit, followed by
bit 30, and so forth. This interfaces endianness may change in future versions of the core.
For smaller data widths, you can use the Avalon-ST Data Format Adapter for data width adaptation. The
Avalon-ST Data Format Adapter converts the output from 4 symbols per beat, to 2 or 1 symbol per beat.
In this way, the 32-bit output of the core can be adapted to a 16-bit or 8-bit output and the 40-bit output
can be adapted to a 20-bit or 10-bit output.
For more information about the Avalon-ST Data Format Adapter, refer to SOPC Builder User Guide.
Output Interface
The output interface is a parallel Avalon-ST interface. You can configure the data width at the output
interface to suit your requirements.
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Configuration 34-3
Inject Error
Errors can be injected into the data stream by controlling the Inject Error register bits in the register
map (refer to the Inject Error Field Descriptions table). When the inject error bit is set, one bit of error is
produced by inverting the LSB of the next data beat.
If the inject error bit is set before the core starts generating the data pattern, the error bit is inserted in the
first output cycle.
The Inject Error register bit is automatically reset after the error is introduced in the pipeline, so that
the next error can be injected.
Preamble Mode
The preamble mode is used for synchronization or word alignment. When the preamble mode is set, the
preamble control register sends the preamble character a specified number of times before the selected
pattern is generated, so the word alignment block in the receiver can determine the word boundary in the
bit stream.
The number of beats (NumBeats) determines the number of cycles to output the preamble character in the
preamble mode. You can set the number of beats (NumBeats) in the preamble control register. The default
setting is 0 and the maximum value is 255 beats. This mode can only be set when the data pattern
generation core is disabled.
Configuration
The following section lists the available option in the MegaWizard interface.
Output Parameter
You can configure the output interface of the data pattern generator core using the following parameter:
ST_DATA_W The width of the output data signal that the data pattern generator core supports.
Valid values are 32 and 40.
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
34-4 Functional Description 2017.05.08
Functional Description
The data pattern checker core accepts data via an Avalon-ST sink interface, checks it for correctness
against the same predetermined pattern used by the data pattern generator core or other PRBS generators
to produce the data, and reports any exceptions to the control interface.
Figure 34-2: Data Pattern Checker
Avalon-MM
Slave Port
Avalon-ST
data_in
Sink
DATA PATTERN
CHECKER
You can configure the width of the output data signal to either 32-bit or 40-bit when instantiating the core.
The chosen data width is not configurable during run time.
You can configure this core to output 8-bit or 10-bit wide symbols. By default, the core generates 4 symbols
per beat, which outputs 32-bit or 40-bit wide data to the Avalon-ST interfaces, respectively. The cores data
format endianness is the most significant symbol first within a beat and the most significant bit first within
a symbol. For example, when you configure the output data to 32-bit, bit 31 is the first data bit, followed by
bit 30, and so forth. This interfaces endianness may change in future versions of the core.
If you configure the width of the output data to 32-bit, the core inputs four 8-bit wide symbols per beat. To
achieve an 8-bit and 16-bit data width, you can use the Avalon-ST Data Format Adapter component to
convert 4 symbols per beat to 1 or 2 symbols per beat.
Similarly, if you configure the width of the output data to 40-bit, the core inputs four 10-bit wide symbols
per beat. The 10-bit and 20-bit input can be achieved by switching from 4 symbols per beat to 1 and 2
symbols per beat.
Input Interface
The input interface is a parallel Avalon-ST interface. You can configure the data width at this interface to
suit your requirements.
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Configuration 34-5
Lock
The lock bit in the status register is asserted when 40 consecutive beats of correct data are received. The
lock bit is deasserted and the receiver loses the lock when 40 consecutive beats of incorrect data are
received.
Configuration
The following section lists the available option in the MegaWizard interface.
Input Parameter
You can configure the input interface of the data pattern checker core using the following parameter:
ST_DATA_W The width of the input data signal that the data pattern checker core supports. Valid
values are 32 and 40.
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
34-6 Register Maps 2017.05.08
Register Maps
This section describes the register maps for the data pattern generator and checker cores.
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Register Maps 34-7
This register allows you to set the error inject bit and insert one bit of error into the stream.
This register enables preamble and set the number of cycles to output the preamble character.
This register is for the user-defined preamble character (bit 32-39) but is ignored if the ST_DATA_W value is
set to 32.
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
34-8 Register Maps 2017.05.08
Table 34-10: Data Pattern Checker Control and Status Register Map
Offset Register Name
base + 0 Status
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
UG-01085
2017.05.08 Register Maps 34-9
This register snapshots and resets the NumBits, NumErrors, and also the internal counters.
[17] RST W Writing this bit to 1 resets all internal counters and statistics. This
bit resets itself automatically after the reset process. Re-enabling the
core does not automatically reset the number of bits received and
number of error bits received in the internal counter.
[31:18] Reserved
This register is the lower word of the 64-bit bit counter snapshot value. The register is reset when the
component-reset is asserted or when the RST bit is set to 1.
This register is the higher word of the 64-bit bit counter snapshot value. The register is reset when the
component-reset is asserted or when the RST bit is set to 1.
This register is the lower word of the 64-bit error counter snapshot value. The register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
UG-01085
34-10 Document Revision History 2017.05.08
This register is the higher word of the 64-bit error counter snapshot value. The register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Table 34-18: Avalon Streaming Data Pattern Generator and Checker Cores Revision History
Date Version Changes
December 2010 v10.1.0 Removed the Device Support, Instantiating the Core in SOPC
Builder, and Referenced Documents sections.
July 2010 v10.0.0 No change from previous release.
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
2017.05.08
PLL Cores
35
UG-01085 Subscribe Send Feedback
Core Overview
The PLL cores, Avalon ALTPLL and PLL, provide a means of accessing the dedicated on-chip PLL
circuitry in the Altera Stratix , except Stratix V, and Cyclone series FPGAs. Both cores are a component
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
35-2 Functional Description 2017.05.08
Functional Description
Figure 35-1: PLL Core Block Diagram
Status
Avalon-MM ALTPLL Megafunc
tion
Slave Interface PLL Locked
locked
areset
pfdena
Control
Registers c0
PLL Reset
PFD Enable c1
PLL Enab le pllena
PLL Clock
Outputs
e0
e1
Reference inclk
Clock
PLL Co
re
ALTPLL Megafunction
The PLL cores consist of an ALTPLL megafunction instantiation and an Avalon-MM slave interface. This
interface can optionally provide access to status and control registers within the cores. The ALTPLL
megafunction takes an SOPC Builder system clock as its reference, and generates one or more phase-
locked loop output clocks.
Clock Outputs
Depending on the target device family, the ALTPLL megafunction can produce two types of output clock:
internal (c)clock outputs that can drive logic either inside or outside the SOPC Builder system
module. Internal clock outputs can also be mapped to top-level FPGA pins. Internal clock outputs are
available on all device families.
external (e)clock outputs that can only drive dedicated FPGA pins. They cannot be used as on-chip
clock sources. External clock outputs are not available on all device families.
The Avalon ALTPLL core, however, does not differentiate the internal and external clock outputs and
allows the external clock outputs to be used as on-chip clock sources.
To determine the exact number and type of output clocks available on your target device, refer to the
ALTPLL Megafunction User Guide.
Send Feedback
UG-01085
2017.05.08 System Reset Considerations 35-3
control signals which are not mapped to registers are exported to the top-level module. For details, refer to
the Instantiating the Avalon ALTPLL Core.
Builder.
Interface Page
The Interface page configures the access modes for the optional advanced PLL status and control signals.
Send Feedback
UG-01085
35-4 Instantiating the PLL Core 2017.05.08
For each advanced signal present on the ALTPLL megafunction, you can select one of the following access
modes:
ExportExports the signal to the top level of the SOPC builder system module.
RegisterMaps the signal to a bit in a status or control register.
The advanced signals are optional. If you choose not to create any of them in the ALTPLL MegaWizard
Plug-In, the PLL's default behavior is as shown in below.
You can specify the access mode for the advanced signals shown in below. The ALTPLL core signals,
not displayed in this table, are automatically exported to the top level of the SOPC Builder system
module.
pfde input PFD Enable Input The phase-frequency This signal enables the phase-frequency
na detector is enabled. detector in the PLL, allowing it to lock on to
changes in the clock reference.
lock output PLL Locked Output This signal is asserted when the PLL is locked
ed to the input clock.
Asserting areset resets the entire SOPC Builder system module, not just the PLL.
Finish
Click Finish to insert the PLL into the SOPC Builder system. The PLL clock output(s) appear in the clock
settings table on the SOPC Builder System Contents tab.
If the PLL has external output clocks, they appear in the clock settings table like other clocks; however, you
cannot use them to drive components within the SOPC Builder system.
For details about using external output clocks, refer to the ALTPLL Megafunction User Guide.
The SOPC Builder automatically connects the PLL's reference clock input to the first available clock in the
clock settings table.
If there is more than one SOPC Builder system clock available, verify that the PLL is connected to the
appropriate reference clock.
Send Feedback
UG-01085
2017.05.08 Hardware Simulation Considerations 35-5
Status Register
Embedded software can access the PLL status via the status register. Writing to status has no effect.
Send Feedback
UG-01085
35-6 Control Register 2017.05.08
Control Register
Embedded software can control the PLL via the control register. Software can also read back the status of
control bits.
Send Feedback
UG-01085
2017.05.08 Document Revision History 35-7
Table 35-5 :
1. Phase step up or down when set to 1 (only applicable to the Avalon ALTPLL core).
The table below lists the counter number and selection. For example, 100 000 000 selects counter C0 and
100 000 001 selects counter C1.
March 2009 v9.0.0 Added information on the new Avalon ALTPLL core.
Send Feedback
UG-01085
35-8 Document Revision History 2017.05.08
Send Feedback
2017.05.08
Altera MSI to GIC Generator Core
36
UG-01085 Subscribe Send Feedback
Core Overview
In the PCI subsystem, Message Signaled Interrupts (MSI) is a feature that enables a device function to
request service by writing a system-specified data value to a system-specified message address (using a PCI
DWORD memory write transaction). System software initializes the message address and message data
during device configuration, allocating one or more system-specified data and system-specified message
addresses to each MSI capable function.
A MSI target (receiver), Altera PCIe RootPort Hard IP, receives MSI interrupts through the Avalon
Streaming (Avalon-ST) RX TLP of type MWr. For Avalon-MM based PCIe RootPort Hard IP, the
RP_Master issues a write transaction with the system-specified message data value to the system-specified
message address of a MSI TLP received. This memory mapped mechanism does not issue any interrupt
output to host the processor; and it relies on the host processor to poll the value changes at the system-
specified message address in order to acknowledge the interrupt request and service the MSI interrupt.
This polling mechanism may overwhelm the processor cycles and it is not efficient.
The Altera MSI-to-GIC Generator is introduced with the purpose of allowing level interrupt generation to
the host processor upon arrival of a MSI interrupt. It exists as a separate module to Altera PCIe HIP for
completing the interrupt generation to host the processor upon arrival of a MSI TLP.
Supported Devices
The Altera MSI to GIC Generator core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Background
The existing implementation of the MSI target at Altera PCIe RootPort translates the MSI TLP received
into a write transaction via PCIe Hard IP Avalon-MM Master port (RP_Master). No interrupt output
directed to the host processor to kick start the service routine for the MSI sender is needed.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
36-2 Feature Description 2017.05.08
Feature Description
The Altera MSI-to-GIC Generator provides storage for the MSI system-specified data value. It also
generates level interrupt output when there is an unread entry. The following figure illustrates the
connection of the MSI-to-GIC Generator module in a PCIe subsystem.
Figure 36-1: MSI-to-GIC Generator in PCIe RP system
This module is connected to RP_Master of PCIe RootPort HIP issuing memory map write transaction
upon MSI TLP arrival. System-specified data value carried by the MSI TLP is written into the module
storage. The same Avalon MM Data Slave port also connects to the host processor for MSI data retrieval
upon interrupt assertion. An Altera MSI-to-GIC Generator module could contain data storage from one
to 32 words of continuous address span. Each data word of storage is associated with a corresponding
numbered bit of Status Bits and Mask Bits registers. Each data word address location can store up to 32
entries.
There is an up to 32-bit Status Register that indicates which storage word location has an unread entry.
Also, there is a similar bit size of Interrupt Mask Register that is in place to allow control of module
behavior by the host processor. The Interrupt Mask register provides flexibility for the host processor to
disregard the incoming interrupt.
The base address assigned for Altera MSI-to-GIC Generator module in the subsystem should cover the
system-specified message address of MSI capable functions during device configuration. Multiple Altera
MSI-to-GIC Generator modules could be instantiated in a subsystem to cover different system-specified
message addresses.
Avalon-MM Slave interfaces of this module honors fixed latency of access to ensure the connected master
(in this case, the RP_Master) can successfully write into the module without back pressure. This avoids the
PCIe upstream traffic from impact because of backpressuring of RP_Master.
Since MSI is multiple messages capable and multiple vectors are supported by each MSI capable function,
there is a tendency that a system-specified message address receives more than one MSI message data
before the host processor is able to service the MSI request. The Component is configurable to have each
data word address to receive up to 32 entries, before any data value is retrieved. When you reach the
Send Feedback
UG-01085
2017.05.08 Interrupt Servicing Process 36-3
maximum data value entry of 32, subsequent write transactions are dropped and logged. This ensures
every write transaction to the storage has no back pressure which may lead to system lock up.
When a new message data is written into Altera MSI-to-GIC Generator module, the storage word
associated Status bit is set automatically and a level interrupt output is then fired. The host processor that
receives this interrupt output is required to service the MSI request, as indicated in the following
procedure:
1. The host processor reads the Status Register to recognize which data word location of its storage is
causing the interrupt.
2. The host processor reads the firing data word location for its system-specified message data value sent
by the MSI capable function. Upon reading the data word, message data is considered consumed, the
associated Status bit is then unset automatically. If the word location entry is empty, then the Status bit
still remains asserted.
3. The host processor services either the MSI sender or the function who calls for the MSI.
4. Upon completing the interrupt service for the first entry, the host processor may continue to service the
remaining entry if there is any residing inside the word location, by observing the associated Status bit.
5. The host processor may run through the Status Register and service each firing Status bit in any order.
Registers of Component
The following table illustrates the Altera MSI-to-GIC Generator registers map as observed by the host
processor from its Avalon-MM CSR interfaces. The bit size of each register is numbered according to the
configured number of data word storage for MSI message of the component. The maximum width of each
register should be 32 bits because the configurable value range is from 1 to 32.
Status Register
The status register contains individual bits representing each of the data words location entry status. An
unread entry sets the Status bit. The Status bit is cleared automatically when entry is empty. The value of
the register is defaulted to 0 upon reset.
The following table illustrates the Status register field.
Send Feedback
UG-01085
36-4 Error Register 2017.05.08
Error Register
The Error register bit is set automatically only when the associated message data word location that
contains the write entry, indicating it was dropped due to maximum entry limit reached. The Error bit
indicates the possibility of the MSI TLP targeting the associated system-specified address. This condition
should not happen as each MSI capable function is only allowed to send up to 32 MSI even with multiple
vector supported.
The Error bit can be cleared by the host processor by writing 1 to the location.
Upon reset, the default value of the Error register bits are set to 0.
The following table illustrates the Pending register field.
The Interrupt Mask register provides a masking bit to individual Status bit before the Status is used to
generate level interrupt output. Having the masking bit set, disregards the corresponding Status bit from
causing interrupt output.
Upon reset, the default value of Interrupt Mask register is 0, which means every single data word address
location is disabled for interrupt generation. To enable interrupt generation from a dedicated message
entry location, the associated Mask bit needs to be set to 1.
The following table illustrates the Interrupt Mask register field.
Unsupported Feature
Send Feedback
UG-01085
2017.05.08 Document Revision History 36-5
The message data entry Avalon-MM Slave represents the system-specified address for MSI function. The
offset seen by MSI function should be similar to the offset seen by the host processors. As this Avalon-MM
Slave interface is accessible (write and read) by both the host processor and the PCIe RP HIP, any read
transaction to the offset address (system-specified address) is considered to have the message data entry
consumed. Observing this limitation, only host master, which is expected to serve the MSI should read
from the Avalon-MM Slave interface. A read from the PCIe RP_Master to the Avalon-MM Slave is
prohibited.
Send Feedback
2017.05.08
Altera Interrupt Latency Counter Core
37
UG-01085 Subscribe Send Feedback
Core Overview
A processor running a program can be instructed to divert from its original execution path by an interrupt
signal generated either by peripheral hardware or the firmware that is currently being executed. The
processor now executes the portions of the program code that handles the interrupt requests known as
Interrupt Service Routines (ISR) by moving to the instruction pointer to the ISR, and then continues
operation. Upon completion of the routine, the processor returns to the previous location.
Alteras Interrupt Latency Calculator (ILC) is developed in mind to measure the time taken in terms of
clock cycles to complete the interrupt service routine. Data obtained from the ILC is utilized by other
latency sensitive IPs in order for it to maintain its proper operation. The data from the ILC can also be
used to help the general firmware debugging exercise.
The ILC sits as a parallel to any interrupt receiver that will consume and perform an interrupt service
routine. The following figure shows the orientation of a ILC in a system design.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
37-2 Supported Devices 2017.05.08
Interrupt Latency
Processor Calculator
Data CSR
Master Slave
IRQ
Receiver
Peripheral
IRQ IRQ
Receiver Sender
Supported Devices
The Altera Interrupt Latency Counter core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Feature Description
The ILC is made up of three sub functional blocks. The top level interface is Avalon Memory Mapped
(Avalon-MM) protocol compliant. The interrupt detector block will be activated by the rising edge of the
interrupt signal or pulse, determined by a parameter during component generation. The interrupt detector
block determines when to start or stop the 32-bit internal counter, which is reset to zero every time it
begins operation without affecting previous stored latency data register value. The latency data register is
updated after the counter is stopped.
Each counter can be configured to host up to 32 identical counters to monitor separate IRQ channels.
Each counter only observes one interrupt input. The interrupt could be level sensitive or pulse (edge)
sensitive. In the case where more interrupt lines need to be monitored, multiple counters could be instanti
ated in Qsys.
Send Feedback
UG-01085
2017.05.08 Avalon-MM Compliant CSR Registers 37-3
ILC only keeps track of the latest interrupt latency value. If multiple interrupts are happening in series,
only the last interrupt latency will be maintained. On the other hand, every start of interrupt edge
refreshes the internal counter from zero.
Control Register
The control registers of the Interrupt Latency Counter is divided into four fields. The LSB is the global
enable bit which by default stores a binary 0. To enable the IP to work, it must be set to binary 1. The next
bit denotes the IRQ type the IP is configured to measure, with binary 0 indicating it is sensitive to level
type IRQ signal; while binary 1 means the IP is accepting pulse type interrupt signal. The next six bits
stores the number of IRQ port count configured through the Qsys GUI. Bit 8 through bit 31 stores the
revision value of the ILC instance.
Send Feedback
UG-01085
37-4 Frequency Register 2017.05.08
Frequency Register
The frequency registers stores the clock frequency supplied to the IP. This 32-bit read only register holds
system frequency data in Hz. For example, a 50 MHz clock signal is represented by hexadecimal
0x2FAF080.
If the ILC is configured to support the pulse IRQ signal, then the counter stop registers are utilized by
running software to halt the counter. Each bit corresponds to the IRQ port. For example, bit 0 controls
IRQ_0 counter. To stop the counter you have to write a binary 1 into the register. Counter stop registers
do not affect the operation of the ILC in level mode.
Note: You need to clear the counter stop register to properly capture the next round of IRQ delay.
The latency data registers holdthe latency value in terms of clock cycle from the moment the interrupt
signal is fired until the IRQ signal goes low for level configuration or counter stop register being set for
pulse configuration. This is a 32-bit read only register with each address corresponding to one IRQ port.
The latency data registers can only be read three clock cycles after the IRQ signal goes low or when the
counter stop registers are set to high in the level and pulse operating mode, respectively.
The data valid registers indicate whether the data from the latency data regsters are ready to be read or
not. By default, these registers hold a binary value of 0 out of reset. Once the counter data is transfered to
Send Feedback
UG-01085
2017.05.08 32-bit Counter 37-5
the latency data register, the corresponding bit within the data valid register is set to binary '1'. It reverts
back to binary 0 after a read operation has been consumed by the ILC.
32-bit Counter
The 32-bit positive edge triggered D-flop base up counter takes in a reset signal which clears all the
registers to zero. It also has an enable signal that determines when the counter operation is turned on or
off.
Interrupt Detector
The interrupt detector can be customized to detect either signal edges or pulse using the Qsys interface.
The interrupt detector generates an enable signal to start and stop the 32-bit counter.
Component Interface
Altera Interrupt Latency Calculator has an Avalon-MM slave interface which communicates with the
Interrupt service routine initiator.
The table below shows the component interface that is available on the Altera Interrupt Latency Counter
IP.
Component Parameterization
The table below shows the configuration parameters available on the Altera Interrupt Latency Counter IP.
Send Feedback
UG-01085
37-6 Software Access 2017.05.08
Software Access
Since the component supports two types of incoming interrupts - level and edge/pulse, the software access
routine for supporting each of the interrupt types has slightly different expectations.
1. Upon completion of ISR, read the data valid bit to ensure that the data is "valid" before reading the
interrupt latency counter.
2. Read from the Latency Data Register to obtain the actual cycle spend for the interrupt.
The value presented is in the amount of clock cycle associated with the clock connected to Interrupt
Latency Counter.
1. Upon completion of ISR, or at the end of ISR, software needs to write binary 1 to one of the 32-bit
registers of the Counter Stop Register to stop the internal counter from counting. The LSB represents
counter 0 and the MSB represents counter 31. This is the same as the level sensitive interrupt. Data
valid bit is recommended to be read before reading the latency counter.
2. Read from Latency Data Register to obtain the actual cycle spend for the interrupt. The counter stop bit
only needs clearing when the IP is configured to accept pulse IRQ. If level IRQ is employed. The
counter stop bit is ignored.
Send Feedback
UG-01085
2017.05.08 Implementation Details 37-7
Implementation Details
Interrupt Latency Counter Architecture
Figure 37-2: Interrupt Latency Calculator Architecture
The interrupt latency calculator operates on a single clock domain which is determined by which clock it
is receiving at the CLK interface. The interrupt detector circuit is made up of a positive-edge triggered flop
which delays the IRQ signal to be XORed with the original signal. The pulse resulted from the previous
operation is then fed to an enable register where it will switch its state from logic low to high. This will
trigger the counter to start its operation. Prior to this, the reset signal is assumed to be triggered through
the firmware. Once the Interrupt service routine has been completed, the IRQ signal drops to logic low.
This causes another pulse to be generated to stop the counter. Data from the counter is then duplicated
into the latency data register to be read out.
When the interrupt detector is configured to react to a pulse signal, the incoming pulse is fed directly to
enable the register to turn on the counter. In this mode, to halt the counters operation, you have to write a
Boolean 1 to the counter stop bit. Only the first IRQ pulse can trigger the counter to start counting and
that subsequent pulse will not cause the counter to reset until a Boolean 1 is written into the counter stop
register. In pulse mode, the latency measured by the IP is one clock cycle more than actual latency.
Send Feedback
UG-01085
37-8 IP Caveats 2017.05.08
IP Caveats
There are limitations in the Altera interrupt latency which the user needs to be aware of. This limitation
arises due to the nature of state machines which incurs a period of clock cycle for state transitions.
1. The data latency registers cannot be read before a first IRQ is fired in any of the 32 channels. This
causes the Waitrequest signal to be perpetually high which would lead to a system stall.
2. The data registers can only be read three clock cycles after the counter registers stop counting. These
three clock cycles originate from the state machine moving from the start state to the stop/store state.
It takes an additional clock cycle to propagate the data from the counter registers to the data store
registers.
3. In the pulse IRQ mode, there is an idle cycle present between two consecutive write commands into the
counter stop register. So, in the event that channel 1 is halted immediately after channel 0 is halted,
then the minimum difference you see in the registered values is 2.
4. The interrupt latency counter will not notify you if an overflow occurs but the counter can count up to
very huge numbers before an overflow happens. The magnitude of the delay numbers reported will
suggest that the system has hung indefinitely.
Send Feedback
2017.05.08
Altera GMII to RGMII Converter Core
38
UG-01085 Subscribe Send Feedback
Core Overview
The Altera GMII to RGMII converter core is an available soft IP for the FPGA fabric. It converts the
GMII/MII interface of the Ethernet controller in the hard processor system (HPS) to an RGMII interface.
By default, the HPS Ethernet controller can either provide an RGMII interface on the HPS pins or an
GMII/MII interface by using the FPGA loaner I/O. However, the GMII to RGMII converter offers a
solution for designers who want to interface to an external RGMII PHY through the FPGA without
adding external interface logic.
Feature Description
Supported Features
Unsupported Features
The Altera GMII to RGMII converter core does not support an internal delay of the TX/RX clock.
However, the FPGA may still provide the 2 ns delay for center-aligned data transmission/reception
through the FPGA I/O buffer. This delay feature is commonly supported by the PHY device or handled at
the board level.
For more information on Quartus Prime delay settings, refer to your device's Golden Hardware Reference
Design (GHRD) user manual on RocketBoards.org.
Related Information
GSRD User Manual
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
38-2 Parameters 2017.05.08
Parameters
IP Configuration Parameter
These parameters are configurable by user during generation time.
Figure 38-1: Altera GMII to RGMII Converter Core Top Level Interfaces
peri_clock
peri_reset Altera GMII to RGMII
Converter Core phy_rgmii
pll_25m_clock
pll_2_5m_clock
hps_gmii
Note: For more information and a detailed list of the interfaces denoted on this figure, refer to the
corresponding interface name in the following tables.
Send Feedback
UG-01085
2017.05.08 Altera GMII to RGMII Converter Core Interface 38-3
Send Feedback
UG-01085
38-4 Altera GMII to RGMII Converter Core Interface 2017.05.08
Send Feedback
UG-01085
2017.05.08 Functional Description 38-5
Functional Description
Figure 38-2: System Level Block Diagram
FPGA
peri_clock
peri_clock
peri_reset
peri_reset
pll_25m_clock
AXI AXI/Avalon avalon_slave MAC Speed pll_2_5m_clock
H2F CSR Altera GMII to phy_rgmii RGMII
Bridge RGMII Converter PHY
hps_gmii core
Altera HPS Emac
HPS core Interface Splitter
emac core
emac_gtx_clk
emac_tx_reset
EMAC
Interfaces emac_rx_reset
ptp
emac_rx_clk_in
mdio
emac_tx_clk_in
Altera GMII to RGMII connverter core is not directly connected to the HPS Ethernet controller. Instead,
an intermediate component called the Altera HPS EMAC interface splitter core is used as a bridge between
HPS core and Altera GMII to RGMII converter core. This intermediate component is responsible for
splitting the emac conduit interface output from HPS core into several interfaces according to their
function (hps_gmii, ptp, mdio interfaces). It is also responsible for managing differences between the
EMAC interfaces in the Arria V, Cyclone V, and Arria 10 HPS.
Related Information
Altera HPS EMAC Interface Splitter Core on page 38-7
For more information about Altera HPS EMAC Interface Splitter Core.
Architecture
Data Path
Send Feedback
UG-01085
38-6 Clock Scheme 2017.05.08
TX Path
mac_rst_tx_n
rgmii_txd[3:0],
rgmii_txctl
mac_tx_clk_o
SDR/DDR
RX Path
Converter rgmii_rxd[3:0],
Soft pipeline with rgmii_rctl
configurable deep rxd_i[7:0],
rxdv_i,
mac_rxd[7:0], rxerr _i
mac _rxdv,
mac _rxerr
mac_col,
mac _crs
mac_rst_rx_n
mac_rx_clk
For transmit path, the GMII/MII data goes through the transmit pipeline register stage before going into
the SDR/DDR converter block. The pipeline logic can be optionally enabled or disabled by the user during
generation time.
For receive path, the GMII/MII data right after the SDR/DDR converter block goes directly to EMAC
controller through Altera HPS EMAC interface splitter core; and also goes through the receive pipeline
register stage. Similarly, this pipeline logic can be optionally enabled or disabled by the user during
generation time.
The SDR/DDR converter block manages single data rate to double data rate conversion and vice-versa.
Altera DDIO component (ALTDDIO_IN and ALTDDIO_OUT) is used to perform this task. This block
also decodes collision and carrier sense condition through In-Band status detection.
Clock Scheme
Transmit
All transmit sequential logic in the Altera GMII to RGMII Converter core is clocked by the HPS PLL
during GMII mode (1000 Mbps) and by the FPGA PLL during MII mode (10/100 Mbps).
Send Feedback
UG-01085
2017.05.08 Receive 38-7
FPGA
phy_txclk_o
HPS rgmii_txc
Clock Mux in EMAC
GMII
Divider and To the rest of Altera
Clock Muxing Ethernet Interface
Manager Converter TX
Sequential Logic RGMII
MII PHY
25MHz
FPGA
2.5MHz PLL
clk_tx_i
Receive
All receive sequential logic in the Altera GMII to RGMII converter core is clocked by rgmii_rx_clk
(always driven from the PHY device).
The Altera HPS EMAC interface splitter core is used as a bridge between the HPS core and the Altera
GMII to RGMII converter core. It is responsible for splitting the EMAC conduit interface output from the
HPS core into several interfaces according to their function (hps_gmii, ptp, mdio interfaces). It is also
responsible for managing the differences between the EMAC interfaces in the Arria V, Cyclone V, and
Arria 10 HPS. Besides the Avalon-MM slave interface logic, there is no additional real logic in this core,
except it takes the input signals from HPS, regroups them according to their function, and outputs them.
Related Information
Feature Description on page 45-1
Parameter
System Info Parameter
Parameter Description
DEVICE_FAMILY Name: DEVICE_FAMILY
Indicates the device family type of the current selected device in QSYS.
This parameter is used to determine the version of HPS (Arria V, Cyclone
V, and Arria 10 HPS) supported by the current selected device. This
information is used to enable or disable certain logic; or to terminate
certain interfaces of this core.
Send Feedback
UG-01085
38-8 HDL Parameter 2017.05.08
HDL Parameter
This parameter is not configurable by the user through Qsys. Its value is automatically derived by the
component based on the DEVICE_FAMILY parameter.
Parameter Description
Enable mac speed CSR Name: MAC_SPEED_CSR_ENABLE
0: The MAC Speed CSR block is not instantiated in this core. In this case,
the Mac Speed information is directly coming from the HPS EMAC
interface.
1: The MAC Speed CSR block is instantiated in this core. In this case, the
Mac Speed information is determined by the control register defined in
this core.
Figure 38-5: Altera HPS EMAC Interface Splitter Core Top Level Interfaces
peri_clock
peri_reset
MAC Speed
avalon_slave CSR
Send Feedback
UG-01085
2017.05.08 Altera HPS EMAC Interface Splitter Core Interface 38-9
(20)
The address bus is in the unit of Word addressing.
Send Feedback
UG-01085
38-10 Altera HPS EMAC Interface Splitter Core Interface 2017.05.08
(21)
These bits exist only when the selected device is Arria 10.
Send Feedback
UG-01085
2017.05.08 Altera HPS EMAC Interface Splitter Core Interface 38-11
Send Feedback
UG-01085
38-12 Altera HPS EMAC Interface Splitter Core Interface 2017.05.08
Send Feedback
UG-01085
2017.05.08 Register 38-13
Related Information
Avalon-MM Slave Interface on page 38-14
For more information about the Avalon-MM Slave interface, refer to the Avalon-MM Slave interface
section.
Register
This register block exists only when the selected device is Arria V or Cyclone V. Each address offset
represents one word of memory address space.
Register Description
Control Register
Send Feedback
UG-01085
38-14 Avalon-MM Slave Interface 2017.05.08
The following information describes the characteristics of the Avalon slave interface of the HPS EMAC
interface splitter core:
Burst width: 32-bit
Burst support: No
Fixed read and write wait time: 0 cycle
Fixed read latency: 1 cycle
Lock support: No
November 2015 2015.11.06 Updated "Altera HPS EMAC Interface Splitter Core Interface" PTP
table
Updated "Unsupported Features"
Send Feedback
2017.05.08
Altera Generic QUAD SPI Controller Core
39
UG-01085 Subscribe Send Feedback
Core Overview
The Generic QUAD SPI controller wraps around the Altera ASMI PARALLEL IP, and a soft ASMI block.
The flash interface is exported to the top wrapper.
Functional Description
The Altera Generic QUAD SPI Controller supports the following devices:
Arria V
Arria 10
Cyclone V
MAX 10
Stratix V
Figure 39-1: Altera Generic QUAD SPI Controller Block Diagram
IRQ
Serial
ASMI Soft Block Flash
Memory
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
39-2 Parameters 2017.05.08
Parameters
Figure 39-2: Qsys Parameters
I/O Mode
From the parameters menu you can select either standard or QUAD I/O mode.
Chip Selects
You can choose up to three flash chips from the parameters menu.
Note: This feature is only for Arria 10 devices.
Interface Signals
Send Feedback
UG-01085
2017.05.08 Interface Signals 39-3
Send Feedback
UG-01085
39-4 Interface Signals 2017.05.08
Send Feedback
UG-01085
2017.05.08 Registers 39-5
Registers
Send Feedback
UG-01085
39-6 Register Descriptions 2017.05.08
Register Descriptions
FLASH_RD_STATUS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_status
FLASH_RD_SID
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_sid
Send Feedback
UG-01085
2017.05.08 FLASH_RD_RDID 39-7
FLASH_RD_RDID
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_rdid
FLASH_MEM_OP
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
39-8 FLASH_ISR 2017.05.08
Related Information
Valid Sector Combination for Sector Protect and Sector Erase Command on page 39-10
FLASH_ISR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
2017.05.08 FLASH_IMR 39-9
FLASH_IMR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved M_ M_illegal_
illegal_ erase
write
FLASH_CHIP_SELECT
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
39-10 Valid Sector Combination for Sector Protect and Sector Erase Command 2017.05.08
Bit Fields
Valid Sector Combination for Sector Protect and Sector Erase Command
Sector Protect
For the sector protect command, you are allowed to perform the operation on more than one sector by
giving the valid sector combination value to FLASH_MEM_OP[23:8] .
There are only 5 bits needed to provide the sector combination value. Bit 13 to bit 23 are reserved and
should be set to zero.
Sector Erase
For the sector erase command, you are allowed to perform the operation on one sector at a time. Each
sector contains of 65536 bytes of data, which is equivalent to 65536 address locations. You need to provide
one sector value if you wish to erase to FLASH_MEM_OP[23:8] . For example, if you want to erase sector 127
in flash 256, you will need to assign b0000 0000 0111 1111 to FLASH_MEM_OP[23:8] .
Send Feedback
UG-01085
2017.05.08 Nios II Tools Support 39-11
Flash Memory Map and Setting Nios II Reset Vector when Using a Boot Copier
The figure below shows what the flash memory map will look like when using a boot copier. This memory
map assumes a FPGA image is stored at the start.
Figure 39-3: EPCQ Flash Layout When Using Boot Copier
0x01E0E400
Customer Data (*.hex)
Application Code
Boot Copier
0x0000E400
Send Feedback
UG-01085
39-12 Boot Copier File 2017.05.08
At the start of the memory map is the FPGA image, followed by the boot copier, the application and then
customer data. The size of the FPGA image is unknown and the exact size can only be known after the
Quartus compile. However, the Nios II Reset Vector must be set in Qsys and must point to right after the
FPGA image (i.e. the start of the boot copier).
The customer will have to determine an upper bound for the size of the FPGA image and will have to set
the Nios II Reset Vector in Qsys to start after the FPGA image(s).
Programming Flash
Programming the flash is done by using quartus_cpf to combine a compiled FPGA image (SOF) with an
application image (HEX file generated by Nios II SBT). The result of this combination is a (POF) which
can be programmed to the flash using the Quartus Prime Programmer.
In the Quartus Prime software, "Convert Programming File tool" (quartus_cpf) can be called by selecting
File >> Convert Programming Files.
Executing in Place
Executing in place shouldnt be any different than executing in place with an On-chip RAM. As long as
both the Nios II reset and exception vectors point to the flash memory, execution will happen in place.
The Nios II board support package (BSP) settings are edited to enable alt_load function to copy the
writable memory section into volatile memory and keep the read only section in the flash memory.
Send Feedback
UG-01085
2017.05.08 Nios II HAL Driver 39-13
Send Feedback
UG-01085
39-14 Configuration Device Types 2017.05.08
Table 39-20: Altera Generic QUAD SPI Controller Core Revision History
Send Feedback
2017.05.08
Altera Serial Flash Controller Core
40
UG-01085 Subscribe Send Feedback
Core Overview
The Altera Serial Flash Controller wraps around the Altera ASMI Parallel IP, and consists of some
conversion logic which converts the ASMI Parallel conduit interface to Avalon interface.
Supported Devices
The Altera Serial Flash Controller core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
The core supports the following devices:
Arria V
Arria 10
Cyclone V
MAX 10
Stratix V
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
40-2 Parameters 2017.05.08
clk
Altera ASMI
reset_n Altera EPCQ Controller IP Parallel IP Core
avl_csr
Serial
avl_mem
ASMI Hard Block Flash
Memory
IRQ
Parameters
Figure 40-2: Qsys Parameters
Send Feedback
UG-01085
2017.05.08 I/O Mode 40-3
EPCQL256
EPCQL512
EPCQL1024
I/O Mode
From the parameters menu you can select either standard or Quad I/O mode.
Chip Selects
You can choose up to 3 flash chips from the parameters menu.
Note: This feature is only for Arria 10 devices.
Interface Signals
Table 40-1: Altera Serial Flash Controller Controller Qsys Interface Signals
Signal Width Direction Description
Clock
clk 1 Input 25MHz maximum input clock.
Reset
reset_n 1 Input Asynchronous reset used to reset
Quad SPI Controller
Avalon-MM Slave Interface for CSR (avl_csr)
avl_csr_addr 3 Input Avalon-MM address bus. The
address bus is in word
addressing.
avl_csr_read 1 Input Avalon-MM read control to csr
avl_csr_write 1 Input Avalon-MM write control to csr
avl_csr_ 1 Output Avalon-MM waitrequest control
waitrequest from csr
avl_csr_wrdata 32 Input Avalon-MM write data bus to csr
avl_csr_rddata 32 Output Avalon-MM read data bus from
csr
avl_csr_rddata_ 1 Output Avalon-MM read data valid
valid which indicates that csr read
data is available
Interrupt Signals
irq 1 Output Interrupt signal to determine if
there is an illegal write or illegal
erase
Avalon-MM Slave Interface for Memory Access (avl_ mem)
Send Feedback
UG-01085
40-4 Interface Signals 2017.05.08
Send Feedback
UG-01085
2017.05.08 Registers 40-5
Registers
Send Feedback
UG-01085
40-6 Register Descriptions 2017.05.08
Register Descriptions
FLASH_RD_STATUS
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_status
FLASH_RD_SID
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_sid
Send Feedback
UG-01085
2017.05.08 FLASH_RD_RDID 40-7
FLASH_RD_RDID
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Read_rdid
FLASH_MEM_OP
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
40-8 FLASH_ISR 2017.05.08
Related Information
Valid Sector Combination for Sector Protect and Sector Erase Command on page 40-10
FLASH_ISR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
2017.05.08 FLASH_IMR 40-9
FLASH_IMR
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved M_ M_illegal_
illegal_ erase
write
FLASH_CHIP_SELECT
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Send Feedback
UG-01085
40-10 Valid Sector Combination for Sector Protect and Sector Erase Command 2017.05.08
Bit Fields
Valid Sector Combination for Sector Protect and Sector Erase Command
Sector Protect
For the sector protect command, you are allowed to perform the operation on more than one sector by
giving the valid sector combination value to FLASH_MEM_OP[23:8] .
There are only 5 bits needed to provide the sector combination value. Bit 13 to bit 23 are reserved and
should be set to zero.
Sector Erase
For the sector erase command, you are allowed to perform the operation on one sector at a time. Each
sector contains of 65536 bytes of data, which is equivalent to 65536 address locations. You need to provide
one sector value if you wish to erase to FLASH_MEM_OP[23:8] . For example, if you want to erase sector 127
in flash 256, you will need to assign b0000 0000 0111 1111 to FLASH_MEM_OP[23:8] .
Send Feedback
UG-01085
2017.05.08 Nios II Tools Support 40-11
Flash Memory Map and Setting Nios II Reset Vector when Using a Boot Copier
The figure below shows what the flash memory map will look like when using a boot copier. This memory
map assumes a FPGA image is stored at the start.
Figure 40-3: EPCQ Flash Layout When Using Boot Copier
0x01E0E400
Customer Data (*.hex)
Application Code
Boot Copier
0x0000E400
Send Feedback
UG-01085
40-12 Boot Copier File 2017.05.08
At the start of the memory map is the FPGA image, followed by the boot copier, the application and then
customer data. The size of the FPGA image is unknown and the exact size can only be known after the
Quartus compile. However, the Nios II Reset Vector must be set in Qsys and must point to right after the
FPGA image (i.e. the start of the boot copier).
The customer will have to determine an upper bound for the size of the FPGA image and will have to set
the Nios II Reset Vector in Qsys to start after the FPGA image(s).
Executing in Place
Executing in place shouldnt be any different than executing in place with an On-chip RAM. As long as
both the Nios II reset and exception vectors point to the flash memory, execution will happen in place.
The Nios II board support package (BSP) settings are edited to enable alt_load function to copy the
writable memory section into volatile memory and keep the read only section in the flash memory.
Send Feedback
UG-01085
2017.05.08 Nios II HAL Driver 40-13
Send Feedback
UG-01085
40-14 Configuration Device Types 2017.05.08
Send Feedback
2017.05.08
Altera Avalon Mailbox (simple) Core
41
UG-01085 Subscribe Send Feedback
Core Overview
In a multiprocessor design, each processor may be dedicated to perform a specific task. Communication
between processors becomes crucial if the tasks of each individual processor are interdependent.
Communication between processors may involve data passing or task control coordination to accomplish
certain functions.
The Altera Avalon Mailbox (simple) component provides the medium of communication between
processors. It provides a message passing location between the sending processor and receiving
processor. The receiving processor is notified upon a message arrival. The notification can be in the form
of an interrupt issuing to the receiving processor or it can continue pooling for new messages by the
receiving processor.
If more than two processors require message passing, multiple Mailboxes can be instantiated between
the two processors. Each Altera Avalon Mailbox corresponds to one direction message passing.
Supported Devices
The Altera Avalon Mailbox (simple) core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Functional Description
Altera Avalon Mailbox (simple) provides two 32-bit registers for message passing between processors,
Command register (0x0) and Pointer register (0x1). The message sender processor and message receiver
processor have individual Avalon Memory Mapped (Avalon-MM) interfaces to a Mailbox component. A
write to the command register by the sender processor indicates a pending message in the Mailbox and an
interrupt will be issued to the receiver processor. Upon retrieval of the message by the receiver processor
via a read transaction, the message is consumed, Mailbox is empty. The status register (0x2) is used to
indicate if the Mailbox is full or empty.
The Mailbox Avalon-MM interface which receives messages, or identified as sender interface, will back
pressure the sender if there is message pending in the Mailbox. This will ensure every single message
passed into the Mailbox is not overwritten. Upon message arrival, the receiving processor will then receive
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
41-2 Message Sending and Retrieval Process 2017.05.08
a level interrupt by the Mailbox. The interrupt will hold high until the single message is retrieved from the
Mailbox via the Avalon-MM interface of receiving processor.
In addition, the Interrupt Masking Register (0x3) is writable by the Avalon-MM interface to mask its
dedicated interrupt output. For example, receiver interface will be able to set the mask bit to mask off the
message pending interrupt generated by Mailbox. Meanwhile, sender interface will be able to set the mask
bit to mask off the message space interrupt output.
Figure 41-1: Altera Avalon Mailbox (simple) Block Diagram
IRQ_space
clk
IRQ_msg
Rst_n
if (write && addr == 0x0) then if (read && addr == 0x0) then
AvMM 1 pending bit = 1, full bit = 1 pending bit = 0, full bit = 1 AvMM 2
Pointer Register 0x1
if (((full == 1) && write req) II IRQ_msg = pending bit
~rst_n) then waitrequest = 0 IRQ spave = !(full bit)
The Mailbox is clocked with single source. Both of the Avalon-MM Slave interfaces have its individual
function to set and clear the Full bit and Message Pending bit. The Avalon-MM Slave of the sender
processor will only set the status bits, while the Avalon-MM Slave of the receiver processor only clears the
status bit.
An interrupt is derived from the Status register bits. It will remain high until the message in the Mailbox is
read.
Registers of Component
The following table illustrates the Mailbox registers map that is observed by each processor from its
Avalon-MM interfaces.
Send Feedback
UG-01085
2017.05.08 Command Register 41-3
Command Register
The Command register is a 32-bit register which contains a user defined command to be passed between
processors. This register is read-writeable via Avalon-MM Slave (sender). However it is only readable by
the Avalon-MM Slave (receiver) interface.
Pointer Register
Instead of passing huge data via the Mailbox, a Pointer register is introduced. The Pointer register contains
the 32-bit address to the payload of the message. A payload could be the raw data to be passed to the
receiving processor for further processing. However, a message could contain zero payload or data for
processing. A write to the Pointer may not be necessary for a message passing.
This register is read-writeable via Avalon-MM Slave (sender). However it is only readable by Avalon-MM
Slave (receiver) interface.
Status Register
The Status register presents the full or empty status of the Mailbox. As the Mailbox can only contain one
message at a time, the full bit status also indicates if there is message pending in the Mailbox. This register
is read only by both Avalon-MM Slave interfaces.
Send Feedback
UG-01085
41-4 Interrupt Masking Register 2017.05.08
Interface
Component Interface
Altera Avalon Mailbox (simple) component consists of two Avalon-MM Slave interfaces, one dedicated for
each processor. The Mailbox also provides active high level interrupt output, which is served as message
arrival notification to the receiving processor. Optionally, a secondary IRQ is created as notification to the
message sender indicating if Mailbox is available for incoming message.
Send Feedback
UG-01085
2017.05.08 Component Parameterization 41-5
Altera Avalon Mailbox (simple) has only one clock domain with one associated reset interface. Require
ment of different clock domains between two processors is handled through the Qsys fabric. The following
table describes the interfaces behavior of the component.
Component Parameterization
Table 41-7: Altera Avalon Mailbox (simple) TCL Component Configuration Parameters
Parameter Name Description Default Value Allowable Range
MSG_SPACE_NOTIFY Boolean true will enable 0 0, 1
interrupt output to message
sending processor for indicating
available space for incoming
message
MSG_ARRIVAL_NOTIFY Boolean true will enable 1 0, 1
interrupt output to message
receiver processor for indicating
a message is pending for
retrieval.
Send Feedback
UG-01085
41-6 HAL Driver 2017.05.08
HAL Driver
This section describes the HAL driver for Altera Avalon Mailbox (simple) soft IP core. Altera Avalon
Mailbox (simple) component provides a medium of communication between processors. It provides a
message passing path between the sending processor and receiving processor. The receiver processor is
notified through an interrupt upon message arrival or the driver will poll the status register if in polling
mode. Altera Avalon Mailbox (simple) provides three 32-bit registers for message passing between
processors, Command (0x0), Pointer (0x4), and Status register (0x8).
The driver code is located at:
/acds/main/ip/altera_avalon_mailbox/hal/src/altera_avalon_mailbox_simple.c
/acds/main/ip/altera_avalon_mailbox/hal/inc/altera_avalon_mailbox_simple.h
/acds/main/ip/altera_avalon_mailbox/inc/altera_avalon_mailbox_simple_regs.h
/acds/main/ip/altera_avalon_mailbox/altera_avalon_mailbox_simple_sw.tcl
Feature Description
The Mailbox driver message delivery depends on how the QSYS design of the sender processor, receiver
processor and Mailbox are interconnected. The Mailbox driver provides the features to send message to
target processor and retrieve message for the receiver processor. The driver include an interrupt service
routine when interrupt mode is used.
Configuration
Interrupt Mode
The figure below is an example of a design using the Altera Avalon Mailbox (simple) in interrupt mode.
The sender CPU(1) will initiate a transfer of the message to the receiver CPU(2) by writing the command
data to the Command register through Mailbox 1. The Command register will send a message pending
interrupt to the receiver. The message pending interrupt is connected to the receiver CPU(2)'s IRQ to
notify that a message has arrived. Once the Command register in Mailbox 1 is read, the message pending
interrupt is cleared and the message is processed. On the sender CPU(1) side, once the message is read, a
message sender interrupt will be flagged signaling that Maibox 1 is free to transmit another message.
Figure 41-2: Example of a Bi-Directional Altera Avalon Mailbox System Using Interrupt Mode
Mailbox 1
NIOS 2 NIOS 2
(CPU1) (CPU2)
Mailbox 2
Send Feedback
UG-01085
2017.05.08 Polling Mode 41-7
Polling Mode
In the case of polling mode, you will always check on the Mailbox Status register if a message has arrived
or free to send. Driver API functions include a timeout parameter, which allows you to specify whether a
read or send operation must be completed within a certain period of time.
Driver Implementation
An opened Mailbox instance will register a sender/receiver interrupt service routine (ISR), if interrupts are
supported with sender/receiver callbacks. When a Mailbox interrupt is disabled, an ISR will not register
and polling mode will need to be used. You must close the Mailbox driver when it is unused.
Send Feedback
UG-01085
41-8 Driver Implementation 2017.05.08
Send Feedback
UG-01085
2017.05.08 Driver Examples 41-9
Driver Examples
The figure below demonstrates writing to a Mailbox. For this example, assume that the hardware system
has two processors communicating via Mailboxes. The system includes two Mailbox cores, which provides
two-way communication between the processors.
Send Feedback
UG-01085
41-10 Driver Examples 2017.05.08
#include <stdio.h>
#include "altera_avalon_mailbox_simple.h"
#include "altera_avalon_mailbox_simple_regs.h"
#include "system.h"
int main_sender()
{
alt_u32 message[2] = {0x00001111, 0xaa55aa55};
int timeout = 50000;
alt_u32 status;
alt_avalon_mailbox_simple_dev* mailbox_sender;
if (!mailbox_sender){
printf ("FAIL: Unable to open mailbox_simple");
return 1;
}
if (status) {
printf (error in transfer);
} else {
printf (Transfer done);
}
#include <stdio.h>
#include "altera_avalon_mailbox_simple.h"
#include "altera_avalon_mailbox_simple_regs.h"
#include "system.h"
Send Feedback
UG-01085
2017.05.08 Document Revision History 41-11
int main_receiver()
{
alt_u32* message[2];
int timeout = 50000;
alt_avalon_mailbox_simple_dev* mailbox_rcv;
altera_avalon_mailbox_close (mailbox_rcv);
return 0;
}
Send Feedback
2017.05.08
Altera I2C Slave to Avalon-MM Master Bridge
Core 42
UG-01085 Subscribe Send Feedback
Core Overview
The Altera I2C Slave to Avalon-MM Master Bridge soft IP core is a solution to connect an I2C interface
with a User Flash Memory (UFM) device. This IP translates an I2C transaction into an Avalon Memory
Mapped (Avalon-MM) transaction.
Supported devices:
Arria II
Arria IV
Arria V
Arria 10
Cyclone V
MAX 10
Supported Devices
The supported devices are:
Arria V
Arria 10
Cyclone V
Cyclone 10 LP
Cyclone 10 GX
MAX 10
Stratix V
Stratix 10
Functional Description
The I2C Slave to Avalon-MM Master Bridge core has the following features:
Up to 4-byte addressing mode
3-bit address stealing
7-bit address I2C slave
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
42-2 Block Diagram 2017.05.08
Block Diagram
Figure 42-1: Altera I2C to Avalon-MM Master Bridge Block Diagram
N-byte Addressing
This IP supports up to a 4 bytes addressing mode. You can select which byte addressing mode you want to
use in Qsys.
The Avalon Address width present at the Avalon master interface is fixed at 32 bits. If you select other than
a 4 bytes addressing mode, zeros are added to the most significant bit(s) (MSB) of the Avalon Address
width. For example in 2 bytes addressing mode, only the lower 16 bits of the address width are used while
the upper 16 bits are zero.
When byte addressing mode = 1, address width in use = 8 + address stealing bit
When byte addressing mode = 2, address width in use = 16 + address stealing bit
When byte addressing mode = 3, address width in use = 24 + address stealing bit
When byte addressing mode = 4, address width in use = 32
There is an address counter inside the I2C to Avalon master interface translator block. The counter rolls
over at the maximum upper address bound according to the byte addressing mode plus one address
stealing bit. It does not continue incrementing up the full address range of the Avalon address size. For
example, the address counter rolls over at 128 K memory size in 2 bytes addressing mode plus one address
stealing bit.
Send Feedback
UG-01085
2017.05.08 N-byte Addressing with N-bit Address Stealing 42-3
Send Feedback
UG-01085
42-4 Read Operation 2017.05.08
Read Operation
The Avalon read data width is 32 bits wide. A 32-bit width limits the bridge to only issue word align
Avalon addresses. It also allows the upstream I2C master to read any sequence of bytes on any address
alignment. The conversion logic which sits between the Avalon interface and I2C interface, translates the
address alignment and returns the correct 8-bit data to the I2C master from the 32-bit Avalon read data.
Read Operation conversion logic flow:
Checks the address alignment issued by the I2C master (first byte, second byte, third byte or forth byte).
Issues a word align Avalon address according to the address sent by the I2C master with the two LSBs
zero.
Returns read data to the I2C master according to the address alignment.
This IP supports three types of read operations:
Random address read
Current address read
Sequential read
Upon receiving of the slave address with the R/W bit set to one, the bridge issues an acknowledge to the
I2C master. The bridge keeps the Avalon read signal high for one clock cycle with the Avalon wait request
signal low, then receives an 8-bit Avalon read data word and upstreams the read data to the I2C master.
Send Feedback
UG-01085
2017.05.08 Current Address Read 42-5
Write Operation
The Avalon write data width interface is 32 bits wide. A 32-bit width limits the bridge to only issue word
align Avalon addresses. It also allows the upstream I2C master to write to any sequence of bytes on any
address alignment. There is a conversion logic which sits between the Avalon interface and the I2C
interface.
Write operation conversion logic flow:
Checks the address alignment issued by the I2C master.
Enables data by setting byteenable high to indicate which byte address the I2C master wants to write
into.
Note: If the address issued by I2C master is 0x03h, the byteenable is 4b1000.
Combines multiple bytes of data into a 32-bit packet if their addresses are sequential.
Note: If the first write is to address 0x04 and the second write is to address 0x05, then byteenable is
4b0011.
Legal byteenable combinations are 4b0001, 4b0010, 4b0100, 4b1000, 4b0011, 4b1100 and 4b1111.
Send Feedback
UG-01085
42-6 Write Operation 2017.05.08
If the write request issued by the I2C master ends up with an illegal byteenable combination such as,
4b0110, 4b0111, or 4b1110, then the bridge generates multiple Avalon byte writes.
Note: If the sequential write request from the I2C master starts from 0x0 and ends at 0x02 (illegal
byteenable, b0111), then the bridge will generate three Avalon write requests with legal
byteenable 4b0001, 4b0010 and 4b0100.
Issues a word align Avalon address according to the address sent by the I2C master with the two LSB set
to zero.
Upon receiving of the slave address with the R/W bit set to zero, the bridge issues an acknowledge to the
I2C master. The next byte transmitted by the master is the byte address. The byte address is written into the
address counter inside the bridge. The bridge acknowledges the I2C master again and the master transmits
the data byte to be written into the addressed memory location. The master keeps sending data bytes to
the bridge and terminates the operation with a Stop condition at the end.
Figure 42-6: Write Operation
Send Feedback
UG-01085
2017.05.08 Interacting with Multi-Master 42-7
Send Feedback
UG-01085
42-8 Qsys Parameters 2017.05.08
Qsys Parameters
Figure 42-7: Altera I2C Slave to Avalon MM Master Bridge Qys Interface
Send Feedback
UG-01085
2017.05.08 Signals 42-9
Signals
Send Feedback
UG-01085
42-10 How to Translate the Bridge's I2C Data and I2C I/O Ports to an I2C Interface 2017.05.08
How to Translate the Bridge's I2C Data and I2C I/O Ports to an I2C
Interface
In order to translate the bridges I2C data and I2C I/O ports to an I2C interface refer to the figure below.
You need to connect a tri-state buffer to the cores I2C data and clock related ports to form SDA and SCL.
Figure 42-8:
ic_data_oe Vcc
1b0 SDA
I/O
ic_data_in_a PAD
ic_clk_oe Vcc
1b0 SCL
I/O
ic_clk_in_a PAD
Example 42-1: Translating the Bridge's I2C Data and I2C I/O Ports to an I2C Interface
module top (
inout tri1 fx2_scl,
inout tri1 fx2_sda
);
wire fx2_sda_in;
wire fx2_scl_in;
wire fx2_sda_oe;
wire fx2_scl_oe;
proj_1 u0 (
.i2cslave_to_avlmm_bridge_0_conduit_end_conduit_data_in
(fx2_sda_in), // i2c_bridge.conduit_data_in
.i2cslave_to_avlmm_bridge_0_conduit_end_conduit_clk_in
(fx2_scl_in), // .conduit_clk_in
.i2cslave_to_avlmm_bridge_0_conduit_end_conduit_data_oe
(fx2_sda_oe), // .conduit_data_oe
.i2cslave_to_avlmm_bridge_0_conduit_end_conduit_clk_oe
(fx2_scl_oe) // .conduit_clk_oe
);
endmodule
Send Feedback
UG-01085
2017.05.08 Document Revision History 42-11
Table 42-3: Altera I2C Slave to Avalon-MM Master Bridge Core Revision History
Date Version Changes
May 2017 2017.05.08 New section:
Supported Devices on page 42-1
Send Feedback
2017.05.08
Avalon-MM DDR Memory Half Rate Bridge Core
43
UG-01085 Subscribe Send Feedback
Core Overview
The Avalon Memory-Mapped (MM) Half-Rate Bridge core is a special-purpose clock-crossing bridge
intended for CPUs that require low-latency access to high-speed memory. The core works under the
assumption that the memory clock is twice the frequency of the CPU clock, with zero phase shift between
the two. It allows high speed memory to run at full rate while providing low-latency interface for a CPU to
access it by using lightweight logic that translates one single-word request into a two-word burst to a
memory running at twice the clock frequency and half the width. For systems with a 8-bit DDR interface,
using the Half-Rate DDR Bridge in conjunction with a DDR SDRAM high-performance memory
controller creates a datapath that matches the throughput of the DDR memory to the CPU. This half-rate
bridge provides the same functionality as the clock crossing bridge, but with significantly lower latency2
cycles instead of 12.
The cores master interface is designed to be connected to a high-speed DDR SDRAM controller and thus
only supports bursting. Because the slave interface is designed to receive single-word requests, it does not
support bursting. The figure below shows a system including an 8-bit DDR memory, a high-performance
memory controller, the Half-Rate DDR Bridge, and a CPU.
Figure 43-1: Qsys Memory System Using a DDR Memory Half-Rate Bridge
PCB
FPGA
DDR2/3 High
DDRn 8 Performance 16 Half-Rate 32
S M S M CPU
Controller Bridge
(full rate)
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
43-2 Resource Usage and Performance 2017.05.08
The Avalon-MM DDR Memory Half-Rate Bridge core has the following features and requirements:
Qsys ready with TimeQuest Timing Analyzer constraints
Requires master clock and slave clock to be synchronous
Handles different bus sizes between CPU and memory
Requires the frequency of the master clock to be double of the slave clock
Has configurable address and data port widths in the master interface
Table 43-1: Resource Utilization Data for Stratix II and Stratix III Devices
Device Family Combinational ALMs Logic Register Embedded Memory
ALUTs
Startix II 61 134 153 0
Stratix III 60 138 153 0
Functional Description
The Avalon MM DDR Memory Half Rate Bridge works under two constraints:
Its memory-side master has a clock frequency that is synchronous (zero phase shift) to, and twice the
frequency of, the CPU-side slave.
Its memory-side master is half as wide as its CPU-side slave.
The bridge leverages these two constraints to provide lightweight, low-latency clock-crossing logic
between the CPU and the memory. These constraints are in contrast with the Avalon-MM Clock-Crossing
Bridge, which makes no assumptions about the frequency/phase relationship between the master- and
slave-side clocks, and provides higher-latency logic that fully-synchronizes all signals that pass between
the two domains.
Send Feedback
UG-01085
2017.05.08 Instantiating the Core in Qsys 43-3
The Avalon MM DDR Memory Half-Rate Bridge has an Avalon-MM slave interface that accepts single-
word (non-bursting) transactions. When the slave interface receives a transaction from a connected CPU,
it issues a two-word burst transaction on its master interface (which is half as wide and twice as fast). If the
transaction is a read request, the bridge's master interface waits for the slaves two-word response, concate
nates the two words, and presents them as a single readdata word on its slave interface to the CPU. Every
time the data width is halved, the clock rate is doubled. As a result, the data throughput is matched
between the CPU and the off-chip memory device.
The figure below shows the latency in the Avalon-MM Half-Rate Bridge core. The core adds two cycles of
latency in the slave clock domain for read transactions. The first cycle is introduced during the command
phase of the transaction and the second cycle, during the response phase of the transaction. The total
latency is 2+<x>, where <x> refers to the latency of the DDR SDRAM high-performance memory
controller. Using the clock crossing bridge for this same purpose would impose approximately 12 cycles of
additional latency.
Figure 43-2: Avalon-MM DDR Memory Half-Rate Bridge Block Diagram
DDR2/3
S M S CPU
Memory
Rsp +1
D Q
Table 43-3: Configurable Parameters for Avalon-MM DDR Memory Half-Rate Bridge Core
Parameters Allowed Values Default Value Description
Data Width 8, 16, 32, 64, 128, 256, 16 The width of the data signal in
512 the master interface.
Address Width 1-32 24 The width of the address signal
in the master interface.
The table below describes the parameters that are derived based on the Data Width and Address Width
settings for the Avalon-MM DDR Memory Half-Rate Bridge core.
Send Feedback
UG-01085
43-4 Example System 2017.05.08
Table 43-4: Derived Parameters for Avalon-MM DDR Memory Half-Rate Bridge Core
Parameter Default Value Description
Master interfaces Byte 2 The width of the byte-enable signal in the
Enable Width master interface.
Slave interfaces Data Width 32 The width of the data signal in the slave
interface.
Slave interfaces Address 22 The width of the address signal in the slave
Width interface.
Slave interfaces Byte Enable 4 The width of the byte-enable signal in the
Width slave interface.
Example System
The following example provides high-level steps showing how the Avalon-MM DDR Memory Half-Rate
Bridge core is connected in a system. This example assumes that you are familiar with the Qsys GUI.
1. Add a Nios II Processor to the system.
2. Add a DDR2 SDRAM High-Performance Controller and configure it to full-rate mode.
3. Add Avalon-MM DDR Memory Half-Rate Bridge to the system.
4. Configure the parameters of the Avalon-MM DDR Memory Half-Rate Bridge based on the memory
controller. For example, for a 32 MByte DDR memory controller in full rate mode with 8 DQ pins (see
Figure 43-1), the parameters should be set as the following:
Data Width = 16
For a memory controller that has 8 DQ pins, its local interface width is 16 bits. The local interface
width and the data width must be the same, therefore data width is set to 16 bits.
Address Width = 25
For a memory capacity of 32 MBytes, the byte address is 25 bits. Because the master address of the
bridge is byte aligned, the address width is set to 25 bits.
5. Connect altmemddr_auxhalf to the slave clock interface (clk_s1) of the Half-Rate Bridge.
6. Connect altmemddr_sysclk to the master clock interface (clk_m1) of the Half-Rate Bridge.
7. Remove all connections between Nios II processor and the memory controller, if there are any.
8. Connect the master interface (m1) of the Avalon-MM DDR Memory Half-Rate Bridge to the memory
controller slave interface.
9. Connect the slave interface (s1) of the Avalon-MM DDR Memory Half-Rate Bridge to the Nios II
processor data_master interface.
10.Connect altmemddr_auxhalf to Nios II processor clock interface.
Table 43-5: Avalon-MM DDR Memory Half Rate Bridge Core Revision History
Send Feedback
2017.05.08
Altera Avalon I2C (Master) Core
44
UG-01085 Subscribe Send Feedback
Core Overview
The Altera Avalon I2C (Master) core (altera_avalon_i2c ) is an IP which implements the I2C protocol. It
supports only master mode with a bit rate (fast mode) of 400 kbits/s and it can also operate in a multi-
master system. It has an Avalon Memory-Mapped (Avalon-MM) slave interface for a host processor to
access its control, status, command and data FIFO. Configure the command and data FIFO to be accessed
by either the Avalon-MM or the Avalon Streaming (Avalon-ST). On the serial interface side, it provides
two data and clock lines to communicate to remote I2C devices.
Supported Devices
The Altera Avalon I2C core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Feature Description
Supported Features
Supports I2C master mode
Supports I2C standard mode (100 kbits/s) and fast mode (400 kbits/s)
Supports multi-master operation
Supports 7 bit or 10 bit addressing
Supports START, repeated START and STOP generation
Run time programmable SCL low and high period
Interrupt or polled-mode of operation
Avalon-MM slave interface for CSR registers access
Avalon-MM or Avalon-ST for command and receive data FIFO access
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
44-2 Unsupported Features 2017.05.08
Unsupported Features
I2C slave mode is not supported at the moment. Refer to Altera I2C Slave to Avalon MM Master Bridge IP
for an I2C slave solution.
Related Information
Altera I2C Slave to Avalon-MM Master Bridge Core on page 42-1
Configuration Parameters
Configure the following parameters through Qsys.
Depth of FIFO 4, 8, 16, 32, 64, 128, 256 4 Specify the Sizes of
both the transfer
command FIFO and
the receive data FIFO
Interface
Figure 44-1: Altera Avalon I2C (Master) Core
clock/reset
Serial Interface
Avalon-MM Slave
Altera Avalon
Avalon-ST Source I2C Core
Interrupt
Avalon-ST Sink
Send Feedback
UG-01085
2017.05.08 Interface 44-3
Avalon-MM Slave
addr 4 Input Avalon-MM address bus.
The address bus is in the unit of word addressing.
For example, addr[2:0] = 0x0 is targeting the first
word of the cores memory map space and
addr[2:0] = 0x1 is targeting the second word.
Send Feedback
UG-01085
44-4 Registers 2017.05.08
Registers
(22)
These signals are not used if Interface for transfer command FIFO and receive data FIFO accesses is set to
Avalon-MM Slave. This setting can be configured through Qsys.
Send Feedback
UG-01085
2017.05.08 Register Descriptions 44-5
Register Descriptions
Send Feedback
UG-01085
44-6 Control Register (CTRL) 2017.05.08
Send Feedback
UG-01085
2017.05.08 Interrupt Status Enable Register (ISER) 44-7
Send Feedback
UG-01085
44-8 Status Register (STATUS) 2017.05.08
Send Feedback
UG-01085
2017.05.08 TFR CMD FIFO Level (TFR CMD FIFO LVL) 44-9
Table 44-9: TFR CMD FIFO Level (TFR CMD FIFO LVL)
Bit Fields Access Default Value Description
log2(FIFO
_DEPTH)
+1
Send Feedback
UG-01085
44-10 SDA Hold Count (SDA HOLD) 2017.05.08
Functional Description
Overview
The core implements I2C master functionality. It can generate all mandatory I2C transfer protocol through
the TFR_CMD register configuration. The core supports a joint data streaming use-cases where the DMA
core can be used for bulk transfer.
Send Feedback
UG-01085
2017.05.08 Configuring TFT_CMD Register Examples 44-11
Host Others
Processor peripherals
Bidirectional
Bidirectional Open Drain
I/O Pad Buffer
I2C Avalon Avalon-MM Bus
Master Core
Serial
control interrupt Interrupt
ports Controller
Send Feedback
UG-01085
44-12 Master Receiver Reads 2 Bytes from Slave Transmitter 2017.05.08
1. Writes TFR_CMD = 0x0A2 -> (STA = 0x0 , STOP = 0x0, AD = 0x51, RW_D = 0x0)
2. Writes TFR_CMD = 0x055 -> (STA = 0x0, STOP = 0x0, AD = 0x2A, RW_D = 0x1)
3. Writes TFR_CMD = 0x156 -> (STA = 0x0, STOP = 0x1, AD = 0x2B, RW_D = 0x0
1. Writes TFR_CMD = 0x0A3 -> (STA = 0x0, STOP = 0x0, AD = 0x51, RW_D = 0x1)
2. Writes TFR_CMD = 0x000 -> (STA = 0x0, STOP = 0x0, AD = 0x00, RW_D = 0x0)
3. Writes TFR_CMD = 0x100 -> (STA = 0x0, STOP = 0x1, AD = 0x00, RW_D = 0x0)
In steps 2 on page 1-12 and 3 on page 1-12, AD and RW_D fields are (dont care) and programmed to 0.
Combine Format (Master Writes 1 Byte and Changes Direction to Read 2 Bytes)
Write data1 = 0x55, read data1 = 0x56 and read data2 = 0x57.
Figure 44-6: Combine Format (Master Writes 1 Byte and change direction to read 2 bytes)
1. Writes TFR_CMD = 0x0A2 -> (STA = 0x0, STOP = 0x0, AD = 0x51, RW_D = 0x0)
2. Writes TFR_CMD = 0x055 -> (STA = 0x0, STOP = 0x0, AD = 0x2A, RW_D = 0x1)
3. Writes TFR_CMD = 0x2A3 -> (STA = 0x1, STOP = 0x0, AD = 0x51, RW_D = 0x1)
4. Writes TFR_CMD = 0x000 -> (STA = 0x0, STOP = 0x0, AD = 0x00, RW_D = 0x0)
5. Writes TFR_CMD = 0x100 -> (STA = 0x0, STOP = 0x1, AD = 0x00, RW_D = 0x0)
1. Writes TFR_CMD = 0x0F6 -> (STA = 0x0, STOP = 0x0, AD = 0x7B, RW_D = 0x0)
2. Writes TFR_CMD = 0x051 -> (STA = 0x0, STOP = 0x0, AD = 0x28, RW_D = 0x1)
3. Writes TFR_CMD = 0x055 -> (STA = 0x0, STOP = 0x0, AD = 0x2A, RW_D = 0x1)
4. Writes TFR_CMD = 0x156 -> (STA = 0x0, STOP = 0x1, AD = 0x2B, RW_D = 0x0)
Send Feedback
UG-01085
2017.05.08 Master Receiver Reads 2 Bytes from Slave Transmitter 44-13
S Slave Address 1 st Byte W A Slave Address 2 nd Byte A Sr Slave Address 1 st Byte R A RDATA1 A RDATA2 N P
1. Writes TFR_CMD = 0x0F6 -> (STA = 0x0, STOP = 0x0, AD = 0x7B, RW_D = 0x0)
2. Writes TFR_CMD = 0x051 -> (STA = 0x0, STOP = 0x0, AD = 0x28, RW_D = 0x1)
3. Writes TFR_CMD = 0x2F7 -> (STA = 0x1, STOP = 0x0, AD = 0x7B, RW_D = 0x1)
4. Writes TFR_CMD = 0x000 -> (STA = 0x0, STOP = 0x0, AD = 0x00, RW_D = 0x0)
5. Writes TFR_CMD = 0x100 -> (STA = 0x0, STOP = 0x1, AD = 0x00, RW_D = 0x0)
In steps 4 on page 1-13 and 5 on page 1-13, AD and RW_D fields are (dont care) and programmed to 0.
Vdd
Send Feedback
UG-01085
44-14 Avalon-MM Slave Interface 2017.05.08
clk
write
read
addr wa0 ra0
writedata wd0
readdata rd0
Avalon-ST Interface
Both ST data source and ST data sink interfaces support a ready latency of zero.
Programming Model
The following flowchart illustrates the recommended programming flow for the core.
Send Feedback
UG-01085
2017.05.08 Document Revision History 44-15
Start
NO
TX_READY ==1 ?
YES
Write to TRF_CMD
register
NO
Write or Read Read
TX_READY ==1
Transfer?
Write Yes
YES
More transfers?
NO
NO
CORE_STATUS == 0
YES
Disable Altera Avalon I2C (Master) core
through CTRL register
Start
Note: When either ARBLOST_DET or NACK_DET occur, you need to clear its respective interrupt status
register bits in their error handling procedure before continuing with a new I2C transfer. A new I2C
transfer can be initiated with or without disabling the core.
Send Feedback
2017.05.08
Altera HPS GMII to TSE 1000BASE-X/SGMII PCS
Bridge Core 45
UG-01085 Subscribe Send Feedback
Core Overview
The Altera Hard Processor System (HPS) provides an Ethernet MAC function through its EMAC
peripherals. The EMAC peripherals provide an RGMII or RMII interface to the HPS dedicated I/O or an
GMII/MII interface to the FPGA I/O. For Serial Gigabit Media Independent Interface (SGMII), it is
supported through the GMII/MII interface to FPGA fabric.
The Altera HPS GMII to TSE 1000BASE-X/SGMII PCS bridge is a soft IP core in FPGA fabric which
provides logic to hook up the HPSs EMAC GMII/MII to the Altera 1000BASE-X/SGMII PCS core for
SGMII interface realization.
Feature Description
Figure 45-1: Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core Block Diagram
FPGA
avalon _slave
Control port
avalon _slave
AXI/Avalon
AXI Bridge CSR
H2F reset _tx_clk
avalon _slave MAC Speed peri _clock
reset _rx_clk
CSR peri _reset Altera HPS
peri _clock tx_clk 1000 BASE -X/
GMII to TSE
rx_clk SGMII PCS SGMII PHY
peri _reset 1000 BASE -X/ 1.25 Gbps
HPS Core SGMII PCS tx_clkena serial link
emac Altera HPS rx_clkena
hps _gmii Bridge
emac _gtx_clk Emac Interface pcs _gmii
emac _tx_reset Splitter Core
pcs _mii
EMAC
Interfaces emac _rx_reset
emac _rx_clk_in
emac _tx_clk_in ptp
mdio
The Altera HPS GMII to TSE 1000BASE-X/SGMII PCS bridge is not directly connected to the HPS
component. Instead an intermediate component called the Altera HPS EMAC Interface Splitter core is
used as a bridge between HPS core and Altera HPS GMII to TSE 1000BASE-X/SGMII PCS bridge. The
intermediate component is responsible to split the EMAC conduit interface output from HPS core into
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
45-2 Supported Features 2017.05.08
several interfaces according to their function (hps_gmii, PTP, MDIO interfaces). It also responsible to
manage differences between EMAC interfaces of the Arria V HPS, Cyclone V HPS, and Arria 10 HPS.
Related Information
Altera HPS EMAC Interface Splitter Core on page 38-7
Supported Features
Features supported by the core:
Enable HPSs EMAC GMII/MII connection to Altera 1000BASE-X/SGMII PCS core
Tri-speed (10/100/1000 Mbps) operation
Dynamic speed switching
Core Architecture
Data Path
Figure 45-2: Transmit Data Path
For transmit path, the GMII/MII data from the HPS goes through the transmit elastic buffer before going
into the PCS GMII and MII port. The transmit elastic buffer is responsible for handling slight frequency
differences between the transmit clock from HPS and the transmit clock generated from the PCSs block.
Figure 45-3: Receive Data Path
Altera Corporation Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core
Send Feedback
UG-01085
2017.05.08 Clock Scheme 45-3
The PCS block has separate GMII and MII ports while the HPS has only single GMII and MII ports.
Therefore a mux is needed in the receive data path. During MII mode, the 4 bits MII receive data bus is
duplicated in order to feed 8 bits to the GMII/MII receive data bus of HPS. The mac_speed information
from the HPS or from the CSR in Altera HPS EMAC Interface Splitter core is used as mux select.
(23)(24)
Clock Scheme
During GMII mode (1000 Mbps), both the HPS and PCS blocks generate a transmit clock. The GMII/MII
data from the HPS is synchronous to the HPSs internal PLL while the PCS block expects transmit data to
be synchronous to its own transmit clock. To solve two different transmit clocks in a transmit data path,
an elastic buffer is used for transmit data transmission.
During MII mode (10/100 Mbps), a transmit clock only comes from the PCS block. The transmit clock
connected to the HPS is the gated version of transmit clock sent from PCS block with the worst duty cycle
of 1% (high: 4 ns, low: 396 ns).
The receive clock comes from the PCS block. The receive clock connected to the HPS is the gated version
of receive clock sent from the PCS block with worst duty cycle of 1% (high: 4 ns, low: 396 ns).
MAC Speed
Mac speed information is used to select different transmit clock sources.
Arria V or Cyclone V HPS cores do not provide mac speed information to the FPGA fabric. Therefore a
control register is defined in the Altera HPS EMAC Interface Splitter corefor software to configure it
correctly according to the speed used by HPS EMAC and PHY device.
The Arria 10 HPS provides mac speed information to the FPGA fabric. The control register in the Altera
HPS EMAC Interface Splitter core is automatically removed.
The two incoming mac_speed bits going into Altera HPS GMII to TSE 1000BASE-X/SGMII PCS bridge is
treated as asynchronous and static. Only 1 bit (mac_speed[1]]) is being used to determine whether the
MAC is operating in GMII or MII mode. Therefore a double synchronizer is enough to synchronize
(mac_speed[1]). No additional filtering logic is needed unless both bits are used.
(23)
Avalible for Cyclone V and Arria V SoC devices.
(24)
Avalible for Arria 10 SoC devices.
Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core Altera Corporation
Send Feedback
UG-01085
45-4 GMII to MII Mode Transition 2017.05.08
TX_BUFFER _DEPTH -1
default read 0
pointer position
Programming Model
Software is required to disable and enable the transmit data path accordingly whenever there is change in
speed mode configuration.
In the case of Cyclone V and Arria V SoC devices, software is required to program the mac_speed register
in Altera HPS EMAC Interface Splitter core as per MAC or PHY device setting.
Refer to the Triple-Speed Ethernet MegaCore Function User Guide for programming sequence of the MAC
and PCS block respectively.
Altera Corporation Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core
Send Feedback
UG-01085
2017.05.08 Configuration Parameters 45-5
Related Information
Triple-Speed Ethernet MegaCore Function User Guide
Configuration Parameters
Interface
Figure 45-5: Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Top Level Interfaces
Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core Altera Corporation
Send Feedback
UG-01085
45-6 Interface 2017.05.08
Altera Corporation Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core
Send Feedback
UG-01085
2017.05.08 Interface 45-7
Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core Altera Corporation
Send Feedback
UG-01085
45-8 Registers 2017.05.08
Registers
Altera Corporation Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core
Send Feedback
UG-01085
2017.05.08 Register Description 45-9
Register Description
Table 45-4: Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core
Altera HPS GMII to TSE 1000BASE-X/SGMII PCS Bridge Core Altera Corporation
Send Feedback
2017.05.08
On-Chip Memory (RAM and ROM) Core
46
UG-01085 Subscribe Send Feedback
Core Overview
Intel FPGAs include on-chip memory blocks that can be used as RAM or ROM in Qsys systems. On-chip
memory has the following benefits for Qsys systems:
On-chip memory has fast access time, compared to off-chip memory.
Qsys automatically instantiates on-chip memory inside the Qsys system, so you do not have to make
any manual connections.
Certain memory blocks can have initialized contents when the FPGA powers up. This feature is useful,
for example, for storing data constants or processor boot code.
On-chip memories support dual port accesses, allowing two master to access the same memory
concurrently.
Supported Devices
The On-Chip Memory (RAM or ROM) core supports the following devices:
Arria 10 GX
Cyclone IV E
Cyclone 10 LP
Cyclone 10 GX
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
46-2 Memory Type 2017.05.08
Memory Type
This options defines the structure of the on-chip memory:
RAM (writable)This setting creates a readable and writable memory.
ROM (read only)This setting creates a read-only memory.
Dual-port accessThis setting creates a memory component with two slaves, which allows two masters
to access the memory simultaneously.
Note: The memory component operates under true dual-port mode where both slave ports have
address ports for read or write operations. If two masters access the same address simultane
ously in a dual-port memory undefined results will occur. Concurrent accesses are only a
problem for two writes. A read and write to the same location will read out the old data and
store the new data.
Single clock operationSingle clock operation setting creates single clock source to clock both slaves
port. If single clock operation is not selected, each of the two slaves port is clocked by different clock
sources.
Note: For Stratix 10 devices, only single clock operation is supported.
Read During Write ModeThis setting determines what the output data of the memory should be
when a simultaneous read and write to the same memory location occurs.
Block typeThis setting directs the Quartus Prime software to use a specific type of memory block
when fitting the on-chip memory in the FPGA.
Note: The MRAM blocks do not allow the contents to be initialized during power up. The M512s
memory type does not support dual-port mode where both ports support both reads and writes.
Because of the constraints on some memory types, it is frequently best to use the Auto setting. Auto allows
the Quartus Prime software to choose a type and the other settings direct the Quartus Prime software to
select a particular type.
Size
This options defines the size and width of the memory.
Enable different width for Dual-port AccessDifferent width for dual-port access status.
Note: A different width for dual-port access is not supported for Stratix 10 devices.
Slave S1 Data widthThis setting determines the data width of the memory. The available choices are
8, 16, 32, 64, 128, 256, 512, or 1024 bits. Assign Data width to match the width of the master that
accesses this memory the most frequently or has the most critical throughput requirements. For
example, if you are connecting the on-chip memory to the data master of a Nios II processor, you
should set the data width of the on-chip memory to 32 bits, the same as the data-width of the Nios II
data master. Otherwise, the access latency could be longer than one cycle because the Avalon intercon
nect fabric performs width translation.
Total memory sizeThis setting determines the total size of the on-chip memory block. The total
memory size must be less than the available memory in the target FPGA.
Minimize memory block usage (may impact fmax)Minimize memory block usage (may impact
fmax)This option is only available for devices that include M4K memory blocks. If selected, the
Quartus Prime software divides the memory by depth rather than width, so that fewer memory blocks
are used. This change may decrease fmax.
Read Latency
On-chip memory components use synchronous, pipelined Avalon-MM slaves. Pipelined access improves
fMAX performance, but also adds latency cycles when reading the memory. The Read latency option
Send Feedback
UG-01085
2017.05.08 ROM/RAM Memory Protection 46-3
allows you to specify either one or two cycles of read latency required to access data. If the Dual-port
access setting is turned on, you can specify a different read latency for each slave. When you have dual-
port memory in your system you can specify different clock frequencies for the ports. You specify this on
the System Contents tab in Qsys.
ECC Parameter
This setting if enabled, extends the data width to support ECC bits. It does not instantiate any ECC
encoder or decoder logic within this component.
Memory Initialization
The memory initialization parameter section contains the following options:
Initialize memory contentOption for user to enable memory content initialization.
Enable non-default initialization fileYou can specify your own initialization file by selecting Enable
non-default initialization file. This option allows the file you specify to be used to initialize the memory
in place of the default initialization file created by Qsys.
Enable Partial Reconfiguartion Initialization ModeThis setting if enabled, automatically instantiates
logic to support Partial Reconfiguration use cases for initialized memory.
Enable In-System Memory Content Editor FeatureEnables a JTAG interface used to read and write to
the RAM while it is operating. You can use this interface to update or read the contents of the memory
from your host PC.
Send Feedback
UG-01085
46-4 Board-Level Design for On-Chip Memory 2017.05.08
To provide memory initialization contents, you must fill in the file <name of memory component>
.hex. The Quartus Prime software recognizes this file during design compilation and incorporates the
contents into the configuration files for the FPGA.
Note: For the memory to be initialized, you then must compile the hardware in the Quartus Prime
software for the SRAM Object File (.sof) to pick up the memory initialization files. All memory
types with the exception of MRAMs support this feature.
onchip_memory2_0
clk1 clock
s1 avalon
reset1 reset
altera_avalon_onchip_memory2
Because the on-chip memory is contained entirely within the Qsys system, qsys_memory_system has no
I/O signals associated with onchip_ram. Therefore, you do not need to make any Quartus Prime project
connections or assignments for the on-chip RAM, and there are no board-level considerations.
Send Feedback
2017.05.08
Document Revision History
A
UG-01085 Subscribe Send Feedback
This section covers the revision history of the entire volume. For details regarding changes to a specific
chapter refer to each chapter revision history.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current ISO
specifications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice. 9001:2008
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly Registered
agreed to in writing by Intel. Intel 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.
*Other names and brands may be claimed as the property of others.
www.altera.com
101 Innovation Drive, San Jose, CA 95134
UG-01085
A-2 Document Revision History 2017.05.08
Send Feedback
UG-01085
2017.05.08 Document Revision History A-3
Send Feedback