Embedded Peripherals IP User Guide Users

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 520 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Embedded Peripherals IP User Guide
Subscribe
Send Feedback
UG-01085
2016.12.19
101 Innovation Drive
San Jose, CA 95134
www.altera.com
Contents
Embedded Peripherals IP User Guide Introduction.......................................... 1-1
Tool Support................................................................................................................................................. 1-1
Obsolescence.................................................................................................................................................1-2
Device Support............................................................................................................................................. 1-2
Document Revision History....................................................................................................................... 1-2
SDRAM Controller Core.....................................................................................2-1
Core Overview..............................................................................................................................................2-1
Functional Description................................................................................................................................2-1
Avalon-MM Interface...................................................................................................................... 2-2
O-Chip SDRAM Interface............................................................................................................2-2
Board Layout and Pinout Considerations.................................................................................... 2-3
Performance Considerations..........................................................................................................2-4
Conguration............................................................................................................................................... 2-4
Memory Prole Page........................................................................................................................2-5
Timing Page...................................................................................................................................... 2-6
Hardware Simulation Considerations.......................................................................................................2-7
SDRAM Controller Simulation Model..........................................................................................2-7
SDRAM Memory Model.................................................................................................................2-7
Example Congurations..............................................................................................................................2-8
Soware Programming Model................................................................................................................... 2-9
Clock, PLL and Timing Considerations....................................................................................................2-9
Factors Aecting SDRAM Timing.............................................................................................. 2-10
Symptoms of an Untuned PLL..................................................................................................... 2-10
Estimating the Valid Signal Window...........................................................................................2-10
Example Calculation......................................................................................................................2-12
Document Revision History.....................................................................................................................2-14
Tri-State SDRAM Core........................................................................................3-1
Core Overview..............................................................................................................................................3-1
Feature Description......................................................................................................................................3-1
Block Diagram..................................................................................................................................3-2
Conguration Parameter............................................................................................................................ 3-2
Memory Prole Page........................................................................................................................3-2
Timing Page...................................................................................................................................... 3-2
Interface.........................................................................................................................................................3-3
Reset and Clock Requirements...................................................................................................................3-7
Architecture.................................................................................................................................................. 3-7
Avalon-MM Slave Interface and CSR............................................................................................3-8
Block Level Usage Model................................................................................................................ 3-9
Document Revision History.....................................................................................................................3-10
TOC-2
Altera Corporation
Compact Flash Core............................................................................................ 4-1
Core Overview..............................................................................................................................................4-1
Functional Description................................................................................................................................4-1
Required Connections.................................................................................................................................4-2
Soware Programming Model................................................................................................................... 4-3
HAL System Library Support......................................................................................................... 4-3
Soware Files.................................................................................................................................... 4-4
Register Maps....................................................................................................................................4-4
Document Revision History....................................................................................................................... 4-5
EPCS Serial Flash Controller Core..................................................................... 5-1
Core Overview..............................................................................................................................................5-1
Functional Description................................................................................................................................5-2
Avalon-MM Slave Interface and Registers....................................................................................5-3
Conguration.............................................................................................................................................. 5-4
Soware Programming Model................................................................................................................... 5-4
HAL System Library Support......................................................................................................... 5-4
Soware Files.................................................................................................................................... 5-5
Document Revision History....................................................................................................................... 5-5
JTAG UART Core.................................................................................................6-1
Core Overview..............................................................................................................................................6-1
Functional Description................................................................................................................................6-1
Avalon Slave Interface and Registers............................................................................................. 6-2
Read and Write FIFOs..................................................................................................................... 6-2
JTAG Interface..................................................................................................................................6-2
Host-Target Connection..................................................................................................................6-2
Conguration............................................................................................................................................... 6-3
Conguration Page.......................................................................................................................... 6-3
Simulation Settings.......................................................................................................................... 6-4
Hardware Simulation Considerations.......................................................................................................6-5
Soware Programming Model................................................................................................................... 6-5
HAL System Library Support......................................................................................................... 6-5
Soware Files.................................................................................................................................... 6-8
Accessing the JTAG UART Core via a Host PC...........................................................................6-9
Register Map..................................................................................................................................... 6-9
Interrupt Behavior......................................................................................................................... 6-10
Document Revision History.....................................................................................................................6-11
UART Core...........................................................................................................7-1
Core Overview..............................................................................................................................................7-1
Functional Description................................................................................................................................7-1
Avalon-MM Slave Interface and Registers....................................................................................7-2
RS-232 Interface............................................................................................................................... 7-2
TOC-3
Altera Corporation
Transmitter Logic.............................................................................................................................7-2
Receiver Logic...................................................................................................................................7-2
Baud Rate Generation..................................................................................................................... 7-3
Instantiating the Core..................................................................................................................................7-3
Conguration Settings.....................................................................................................................7-3
Simulation Settings.......................................................................................................................... 7-6
Simulation Considerations......................................................................................................................... 7-6
Soware Programming Model................................................................................................................... 7-7
HAL System Library Support......................................................................................................... 7-7
Soware Files.................................................................................................................................... 7-9
Register Map..................................................................................................................................... 7-9
Interrupt Behavior......................................................................................................................... 7-14
Document Revision History.....................................................................................................................7-15
16550 UART Core................................................................................................8-1
Core Overview..............................................................................................................................................8-1
Feature Description......................................................................................................................................8-1
Unsupported Features..................................................................................................................... 8-2
Interface.............................................................................................................................................8-2
General Architecture....................................................................................................................... 8-4
16550 UART General Programming Flow Chart........................................................................ 8-4
Conguration Parameters...............................................................................................................8-6
DMA Support................................................................................................................................... 8-6
FPGA Resource Usage.....................................................................................................................8-7
Timing and Fmax.............................................................................................................................8-8
Avalon-MM Slave.............................................................................................................................8-8
Overrun/Underrun Conditions................................................................................................... 8-10
Hardware Auto Flow-Control...................................................................................................... 8-10
Clock and Baud Rate Selection.................................................................................................... 8-11
Soware Programming Model.................................................................................................................8-11
Overview......................................................................................................................................... 8-12
Supported Features........................................................................................................................ 8-12
Unsupported Features................................................................................................................... 8-12
Conguration................................................................................................................................. 8-12
16550 UART API............................................................................................................................8-13
Driver Examples.............................................................................................................................8-18
Address Map and Register Descriptions ................................................................................................8-22
rbr_thr_dll.......................................................................................................................................8-23
ier_dlh..............................................................................................................................................8-25
iir...................................................................................................................................................... 8-27
fcr......................................................................................................................................................8-28
lcr......................................................................................................................................................8-30
mcr................................................................................................................................................... 8-32
lsr......................................................................................................................................................8-34
msr....................................................................................................................................................8-37
scr..................................................................................................................................................... 8-40
afr..................................................................................................................................................... 8-41
tx_low.............................................................................................................................................. 8-42
TOC-4
Altera Corporation
Document Revision History.....................................................................................................................8-42
SPI Core............................................................................................................... 9-1
Core Overview..............................................................................................................................................9-1
Functional Description................................................................................................................................9-1
Example Congurations..................................................................................................................9-2
Transmitter Logic.............................................................................................................................9-2
Receiver Logic...................................................................................................................................9-3
Master and Slave Modes..................................................................................................................9-3
Conguration............................................................................................................................................... 9-5
Master/Slave Settings.......................................................................................................................9-5
Data Register Settings......................................................................................................................9-6
Timing Settings.................................................................................................................................9-6
Soware Programming Model................................................................................................................... 9-7
Hardware Access Routines..............................................................................................................9-7
Soware Files.................................................................................................................................... 9-8
Register Map..................................................................................................................................... 9-9
Document Revision History.....................................................................................................................9-12
Optrex 16207 LCD Controller Core..................................................................10-1
Core Overview............................................................................................................................................10-1
Functional Description..............................................................................................................................10-1
Soware Programming Model.................................................................................................................10-2
HAL System Library Support....................................................................................................... 10-2
Displaying Characters on the LCD..............................................................................................10-2
Soware Files..................................................................................................................................10-3
Register Map...................................................................................................................................10-3
Interrupt Behavior......................................................................................................................... 10-3
Document Revision History.....................................................................................................................10-3
PIO Core............................................................................................................ 11-1
Core Overview............................................................................................................................................11-1
Functional Description..............................................................................................................................11-1
Data Input and Output..................................................................................................................11-2
Edge Capture.................................................................................................................................. 11-2
IRQ Generation..............................................................................................................................11-2
Example Congurations........................................................................................................................... 11-3
Avalon-MM Interface....................................................................................................................11-3
Conguration............................................................................................................................................. 11-3
Basic Settings.................................................................................................................................. 11-3
Input Options................................................................................................................................. 11-4
Simulation....................................................................................................................................... 11-5
Soware Programming Model.................................................................................................................11-5
Soware Files..................................................................................................................................11-5
Register Map...................................................................................................................................11-5
Interrupt Behavior......................................................................................................................... 11-7
TOC-5
Altera Corporation
Soware Files..................................................................................................................................11-8
Document Revision History.....................................................................................................................11-8
Avalon-ST Serial Peripheral Interface Core......................................................12-1
Core Overview............................................................................................................................................12-1
Functional Description..............................................................................................................................12-1
Interfaces......................................................................................................................................... 12-1
Operation........................................................................................................................................ 12-2
Timing............................................................................................................................................. 12-2
Limitations...................................................................................................................................... 12-3
Conguration............................................................................................................................................. 12-3
Document Revision History.....................................................................................................................12-3
Avalon-ST Single-Clock and Dual-Clock FIFO Cores..................................... 13-1
Core Overview............................................................................................................................................13-1
Functional Description..............................................................................................................................13-1
Interfaces......................................................................................................................................... 13-2
Operating Modes........................................................................................................................... 13-3
Fill Level.......................................................................................................................................... 13-3
resholds.......................................................................................................................................13-3
Parameters...................................................................................................................................................13-4
Register Description.................................................................................................................................. 13-5
Document Revision History.....................................................................................................................13-6
MDIO Core........................................................................................................ 14-1
Core Overview............................................................................................................................................14-1
Functional Description..............................................................................................................................14-1
MDIO Frame Format (Clause 45)............................................................................................... 14-2
MDIO Clock Generation.............................................................................................................. 14-3
Interfaces......................................................................................................................................... 14-3
Operation........................................................................................................................................ 14-3
Parameter.................................................................................................................................................... 14-4
Conguration Registers............................................................................................................................ 14-4
Document Revision History.....................................................................................................................14-5
On-Chip FIFO Memory Core............................................................................15-1
Core Overview............................................................................................................................................15-1
Functional Description..............................................................................................................................15-1
Avalon-MM Write Slave to Avalon-MM Read Slave.................................................................15-1
Avalon-ST Sink to Avalon-ST Source..........................................................................................15-2
Avalon-MM Write Slave to Avalon-ST Source...........................................................................15-2
Avalon-ST Sink to Avalon-MM Read Slave................................................................................15-4
Status Interface............................................................................................................................... 15-5
Clocking Modes..............................................................................................................................15-5
Conguration............................................................................................................................................. 15-5
TOC-6
Altera Corporation
FIFO Settings.................................................................................................................................. 15-5
Interface Parameters...................................................................................................................... 15-6
Soware Programming Model.................................................................................................................15-7
HAL System Library Support....................................................................................................... 15-7
Soware Files..................................................................................................................................15-7
Programming with the On-Chip FIFO Memory...................................................................................15-7
Soware Control............................................................................................................................ 15-8
Soware Example.........................................................................................................................15-11
On-Chip FIFO Memory API..................................................................................................................15-12
altera_avalon_fo_init()............................................................................................................. 15-12
altera_avalon_fo_read_status()............................................................................................... 15-13
altera_avalon_fo_read_ienable()............................................................................................. 15-13
altera_avalon_fo_read_almostfull()........................................................................................15-13
altera_avalon_fo_read_almostempty()...................................................................................15-14
altera_avalon_fo_read_event()................................................................................................ 15-14
altera_avalon_fo_read_level()..................................................................................................15-14
altera_avalon_fo_clear_event()............................................................................................... 15-15
altera_avalon_fo_write_ienable()............................................................................................15-15
altera_avalon_fo_write_almostfull().......................................................................................15-16
altera_avalon_fo_write_almostempty()..................................................................................15-16
altera_avalon_write_fo().......................................................................................................... 15-16
altera_avalon_write_other_info()..............................................................................................15-17
altera_avalon_fo_read_fo()....................................................................................................15-17
Document Revision History...................................................................................................................15-18
Avalon-ST Multi-Channel Shared Memory FIFO Core................................... 16-1
Core Overview............................................................................................................................................16-1
Performance and Resource Utilization................................................................................................... 16-1
Functional Description..............................................................................................................................16-3
Interfaces......................................................................................................................................... 16-3
Operation........................................................................................................................................ 16-4
Parameters...................................................................................................................................................16-4
Soware Programming Model.................................................................................................................16-6
HAL System Library Support....................................................................................................... 16-6
Register Map...................................................................................................................................16-6
Document Revision History.....................................................................................................................16-8
SPI Slave/JTAG to Avalon Master Bridge Cores............................................... 17-1
Core Overview............................................................................................................................................17-1
Functional Description..............................................................................................................................17-1
Parameters...................................................................................................................................................17-3
Document Revision History.....................................................................................................................17-3
Avalon Streaming Channel Multiplexer and Demultiplexer Cores................. 18-1
Core Overview............................................................................................................................................18-1
Resource Usage and Performance................................................................................................18-1
TOC-7
Altera Corporation
Multiplexer..................................................................................................................................................18-2
Functional Description..................................................................................................................18-2
Parameters.......................................................................................................................................18-3
Demultiplexer.............................................................................................................................................18-4
Functional Description..................................................................................................................18-4
Parameters.......................................................................................................................................18-5
Hardware Simulation Considerations.....................................................................................................18-6
Soware Programming Model.................................................................................................................18-6
Document Revision History.....................................................................................................................18-7
Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores................. 19-1
Core Overview............................................................................................................................................19-1
Functional Description..............................................................................................................................19-1
Interfaces......................................................................................................................................... 19-2
Operation—Avalon-ST Bytes to Packets Converter Core........................................................19-2
Operation—Avalon-ST Packets to Bytes Converter Core........................................................19-3
Document Revision History.....................................................................................................................19-3
Avalon Packets to Transactions Converter Core.............................................. 20-1
Core Overview............................................................................................................................................20-1
Functional Description..............................................................................................................................20-1
Interfaces......................................................................................................................................... 20-1
Operation........................................................................................................................................ 20-2
Document Revision History.....................................................................................................................20-3
Avalon-ST Round Robin Scheduler Core......................................................... 21-1
Core Overview............................................................................................................................................21-1
Performance and Resource Utilization................................................................................................... 21-1
Functional Description..............................................................................................................................21-2
Interfaces......................................................................................................................................... 21-2
Operations.......................................................................................................................................21-3
Parameters...................................................................................................................................................21-4
Document Revision History.....................................................................................................................21-4
Avalon-ST Delay Core....................................................................................... 22-1
Core Overview............................................................................................................................................22-1
Functional Description..............................................................................................................................22-1
Reset.................................................................................................................................................22-2
Interfaces......................................................................................................................................... 22-2
Parameters...................................................................................................................................................22-2
Document Revision History.....................................................................................................................22-4
Avalon-ST Splitter Core.....................................................................................23-1
Core Overview............................................................................................................................................23-1
Functional Description..............................................................................................................................23-1
TOC-8
Altera Corporation
Backpressure................................................................................................................................... 23-2
Interfaces......................................................................................................................................... 23-2
Parameters...................................................................................................................................................23-2
Document Revision History.....................................................................................................................23-4
Scatter-Gather DMA Controller Core.............................................................. 24-1
Core Overview............................................................................................................................................24-1
Example Systems............................................................................................................................ 24-1
Comparison of SG-DMA Controller Core and DMA Controller Core................................. 24-2
Resource Usage and Performance............................................................................................................24-2
Functional Description..............................................................................................................................24-3
Functional Blocks and Congurations........................................................................................24-3
DMA Descriptors...........................................................................................................................24-5
Error Conditions............................................................................................................................ 24-7
Parameters...................................................................................................................................................24-9
Simulation Considerations..................................................................................................................... 24-10
Soware Programming Model...............................................................................................................24-10
HAL System Library Support..................................................................................................... 24-10
Soware Files................................................................................................................................24-10
Register Maps............................................................................................................................... 24-10
DMA Descriptors.........................................................................................................................24-14
Timeouts........................................................................................................................................24-16
Programming with SG-DMA Controller............................................................................................. 24-16
Data Structure.............................................................................................................................. 24-16
SG-DMA API............................................................................................................................... 24-17
alt_avalon_sgdma_do_async_transfer()...................................................................................24-18
alt_avalon_sgdma_do_sync_transfer().....................................................................................24-19
alt_avalon_sgdma_construct_mem_to_mem_desc().............................................................24-19
alt_avalon_sgdma_construct_stream_to_mem_desc()..........................................................24-20
alt_avalon_sgdma_construct_mem_to_stream_desc()..........................................................24-21
alt_avalon_sgdma_enable_desc_poll()..................................................................................... 24-22
alt_avalon_sgdma_disable_desc_poll().................................................................................... 24-23
alt_avalon_sgdma_check_descriptor_status().........................................................................24-23
alt_avalon_sgdma_register_callback()......................................................................................24-24
alt_avalon_sgdma_start()........................................................................................................... 24-24
alt_avalon_sgdma_stop()............................................................................................................24-25
alt_avalon_sgdma_open().......................................................................................................... 24-25
Document Revision History...................................................................................................................24-26
Modular Scatter-Gather DMA Core................................................................. 25-1
Core Overview............................................................................................................................................25-1
Feature Description................................................................................................................................... 25-1
mSGDMA Interfaces and Parameters.....................................................................................................25-4
Interface...........................................................................................................................................25-4
mSGDMA Parameter Editor........................................................................................................ 25-8
mSGDMA Descriptors..............................................................................................................................25-8
Read and Write Address Fields.................................................................................................... 25-9
TOC-9
Altera Corporation
Length Field.................................................................................................................................. 25-10
Sequence Number Field.............................................................................................................. 25-10
Read and Write Burst Count Fields...........................................................................................25-10
Read and Write Stride Fields...................................................................................................... 25-10
Control Field.................................................................................................................................25-11
Programming Model............................................................................................................................... 25-12
Stop DMA Operation.................................................................................................................. 25-12
Stop Descriptor Operation......................................................................................................... 25-13
Recovery from Stopped on Error and Stopped on Early Termination................................. 25-13
Register Map of mSGDMA.....................................................................................................................25-13
Status Register.............................................................................................................................. 25-14
Control Register........................................................................................................................... 25-15
Modular Scatter-Gather DMA Prefetcher Core.................................................................................. 25-17
Feature Description..................................................................................................................... 25-17
Functional Description............................................................................................................... 25-17
Driver Implementation........................................................................................................................... 25-33
alt_msgdma_standard_descriptor_async_transfer................................................................. 25-33
alt_msgdma_extended_descriptor_async_transfer.................................................................25-34
alt_msgdma_descriptor_async_transfer...................................................................................25-35
alt_msgdma_standard_descriptor_sync_transfer................................................................... 25-36
alt_msgdma_extended_descriptor_sync_transfer...................................................................25-37
alt_msgdma_descriptor_sync_transfer.....................................................................................25-38
alt_msgdma_construct_standard_st_to_mm_descriptor...................................................... 25-39
alt_msgdma_construct_standard_mm_to_st_descriptor...................................................... 25-40
alt_msgdma_construct_standard_mm_to_mm_descriptor..................................................25-41
alt_msgdma_construct_standard_descriptor.......................................................................... 25-42
alt_msgdma_construct_extended_st_to_mm_descriptor..................................................... 25-43
alt_msgdma_construct_extended_mm_to_st_descriptor..................................................... 25-44
alt_msgdma_construct_extended_mm_to_mm_descriptor................................................. 25-45
alt_msgdma_construct_extended_descriptor..........................................................................25-46
alt_msgdma_register_callback................................................................................................... 25-47
alt_msgdma_open........................................................................................................................25-48
alt_msgdma_write_standard_descriptor..................................................................................25-49
alt_msgdma_write_extended_descriptor................................................................................. 25-50
alt_avalon_msgdma_init.............................................................................................................25-51
alt_msgdma_irq........................................................................................................................... 25-51
Document Revision History...................................................................................................................25-52
DMA Controller Core....................................................................................... 26-1
Core Overview............................................................................................................................................26-1
Functional Description..............................................................................................................................26-1
Setting Up DMA Transactions..................................................................................................... 26-2
e Master Read and Write Ports................................................................................................ 26-2
Addressing and Address Incrementing.......................................................................................26-3
Parameters...................................................................................................................................................26-3
DMA Parameters (Basic).............................................................................................................. 26-3
Advanced Options......................................................................................................................... 26-4
Soware Programming Model.................................................................................................................26-5
TOC-10
Altera Corporation
HAL System Library Support....................................................................................................... 26-5
Soware Files..................................................................................................................................26-6
Register Map...................................................................................................................................26-6
Interrupt Behavior......................................................................................................................... 26-9
Document Revision History...................................................................................................................26-10
Video Sync Generator and Pixel Converter Cores............................................27-1
Core Overview............................................................................................................................................27-1
Video Sync Generator................................................................................................................................27-1
Functional Description..................................................................................................................27-1
Parameters.......................................................................................................................................27-2
Signals..............................................................................................................................................27-3
Timing Diagrams........................................................................................................................... 27-4
Pixel Converter...........................................................................................................................................27-5
Functional Description..................................................................................................................27-5
Parameters.......................................................................................................................................27-5
Signals..............................................................................................................................................27-5
Hardware Simulation Considerations.....................................................................................................27-6
Document Revision History.....................................................................................................................27-6
Interval Timer Core...........................................................................................28-1
Core Overview............................................................................................................................................28-1
Functional Description..............................................................................................................................28-1
Avalon-MM Slave Interface..........................................................................................................28-2
Conguration............................................................................................................................................. 28-2
Timeout Period...............................................................................................................................28-2
Counter Size....................................................................................................................................28-3
Hardware Options..........................................................................................................................28-3
Conguring the Timer as a Watchdog Timer............................................................................ 28-4
Soware Programming Model.................................................................................................................28-4
HAL System Library Support....................................................................................................... 28-4
Soware Files..................................................................................................................................28-5
Register Map...................................................................................................................................28-5
Interrupt Behavior......................................................................................................................... 28-8
Document Revision History.....................................................................................................................28-8
Mutex Core.........................................................................................................29-1
Core Overview............................................................................................................................................29-1
Functional Description..............................................................................................................................29-1
Conguration............................................................................................................................................. 29-2
Soware Programming Model.................................................................................................................29-2
Soware Files..................................................................................................................................29-2
Hardware Access Routines............................................................................................................29-2
Mutex API...................................................................................................................................................29-3
altera_avalon_mutex_is_mine().................................................................................................. 29-3
altera_avalon_mutex_rst_lock()................................................................................................29-4
TOC-11
Altera Corporation
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
Vectored Interrupt Controller Core..................................................................30-1
Core Overview............................................................................................................................................30-1
Functional Description..............................................................................................................................30-2
External Interfaces......................................................................................................................... 30-3
Functional Blocks...........................................................................................................................30-4
Daisy Chaining VIC Cores........................................................................................................... 30-6
Latency Information......................................................................................................................30-6
Register Maps............................................................................................................................................. 30-6
Parameters................................................................................................................................................ 30-12
Altera HAL Soware Programming Model..........................................................................................30-13
Soware Files................................................................................................................................30-13
Macros........................................................................................................................................... 30-13
Data Structure.............................................................................................................................. 30-14
VIC API.........................................................................................................................................30-14
Run-time Initialization................................................................................................................30-16
Board Support Package............................................................................................................... 30-17
Implementing the VIC in Qsys.............................................................................................................. 30-23
Adding VIC Hardware................................................................................................................ 30-23
Soware for VIC.......................................................................................................................... 30-28
Example Designs......................................................................................................................................30-30
Example Description................................................................................................................... 30-30
Example Usage..............................................................................................................................30-32
Soware Description................................................................................................................... 30-32
Positioning the ISR in Vector Table...........................................................................................30-35
Latency Measurement with the Performance Counter...........................................................30-36
Advanced Topics...................................................................................................................................... 30-37
Real Time Latency Concerns......................................................................................................30-37
Soware Interrupt........................................................................................................................30-40
Document Revision History...................................................................................................................30-41
System ID Core.................................................................................................. 31-1
Core Overview............................................................................................................................................31-1
Functional Description..............................................................................................................................31-1
Conguration............................................................................................................................................. 31-2
Soware Programming Model.................................................................................................................31-2
alt_avalon_sysid_test()..................................................................................................................31-2
Document Revision History.....................................................................................................................31-3
Performance Counter Core............................................................................... 32-1
Core Overview............................................................................................................................................32-1
TOC-12
Altera Corporation
Functional Description..............................................................................................................................32-1
Section Counters............................................................................................................................32-1
Global Counter...............................................................................................................................32-2
Register Map...................................................................................................................................32-2
System Reset................................................................................................................................... 32-3
Conguration............................................................................................................................................. 32-3
Dene Counters............................................................................................................................. 32-3
Multiple Clock Domain Considerations.....................................................................................32-3
Hardware Simulation Considerations.....................................................................................................32-3
Soware Programming Model.................................................................................................................32-3
Soware Files..................................................................................................................................32-3
Using the Performance Counter.................................................................................................. 32-4
Interrupt Behavior......................................................................................................................... 32-6
Performance Counter API........................................................................................................................ 32-6
PERF_RESET()...............................................................................................................................32-6
PERF_START_MEASURING()...................................................................................................32-7
PERF_STOP_MEASURING()..................................................................................................... 32-7
PERF_BEGIN().............................................................................................................................. 32-7
PERF_END().................................................................................................................................. 32-8
perf_print_formatted_report().................................................................................................... 32-8
perf_get_total_time().................................................................................................................... 32-9
perf_get_section_time()................................................................................................................32-9
perf_get_num_starts()................................................................................................................ 32-10
alt_get_cpu_freq()........................................................................................................................32-10
Document Revision History...................................................................................................................32-11
Avalon Streaming Test Pattern Generator and Checker Cores........................ 33-1
Core Overview............................................................................................................................................33-1
Resource Utilization and Performance................................................................................................... 33-1
Test Pattern Generator.............................................................................................................................. 33-2
Functional Description..................................................................................................................33-2
Conguration................................................................................................................................. 33-3
Test Pattern Checker..................................................................................................................................33-4
Functional Description..................................................................................................................33-4
Conguration................................................................................................................................. 33-5
Hardware Simulation Considerations.....................................................................................................33-5
Soware Programming Model.................................................................................................................33-5
HAL System Library Support....................................................................................................... 33-5
Soware Files..................................................................................................................................33-6
Register Maps................................................................................................................................. 33-6
Test Pattern Generator API.................................................................................................................... 33-10
data_source_reset()..................................................................................................................... 33-10
data_source_init()........................................................................................................................33-10
data_source_get_id()...................................................................................................................33-11
data_source_get_supports_packets()........................................................................................33-11
data_source_get_num_channels().............................................................................................33-11
data_source_get_symbols_per_cycle()..................................................................................... 33-12
data_source_set_enable()........................................................................................................... 33-12
TOC-13
Altera Corporation
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_ll_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
Document Revision History...................................................................................................................33-21
Avalon Streaming Data Pattern Generator and Checker Cores.......................34-1
Core Overview............................................................................................................................................34-1
Data Pattern Generator.............................................................................................................................34-1
Functional Description..................................................................................................................34-1
Conguration................................................................................................................................. 34-3
Data Pattern Checker................................................................................................................................ 34-3
Functional Description..................................................................................................................34-3
Conguration................................................................................................................................. 34-5
Hardware Simulation Considerations.....................................................................................................34-5
Soware Programming Model.................................................................................................................34-5
Register Maps................................................................................................................................. 34-5
Document Revision History...................................................................................................................34-10
PLL Cores...........................................................................................................35-1
Core Overview............................................................................................................................................35-1
Functional Description..............................................................................................................................35-2
ALTPLL Megafunction..................................................................................................................35-2
Clock Outputs.................................................................................................................................35-2
TOC-14
Altera Corporation
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 Denitions and Bit List.............................................................................................................. 35-5
Status Register.................................................................................................................................35-5
Control Register............................................................................................................................. 35-6
Phase Recong Control Register..................................................................................................35-6
Document Revision History.....................................................................................................................35-7
Altera MSI to GIC Generator Core................................................................... 36-1
Core Overview............................................................................................................................................36-1
Background.................................................................................................................................................36-1
Feature Description................................................................................................................................... 36-1
Interrupt Servicing Process...........................................................................................................36-2
Registers of Component................................................................................................................36-3
Unsupported Feature.....................................................................................................................36-4
Document Revision History.....................................................................................................................36-5
Altera Interrupt Latency Counter Core............................................................37-1
Core Overview............................................................................................................................................37-1
Feature Description................................................................................................................................... 37-2
Avalon-MM Compliant CSR Registers....................................................................................... 37-2
32-bit Counter................................................................................................................................ 37-4
Interrupt Detector..........................................................................................................................37-5
Component Interface.................................................................................................................................37-5
Component Parameterization..................................................................................................................37-5
Soware Access.......................................................................................................................................... 37-6
Routine for Level Sensitive Interrupts.........................................................................................37-6
Routine for Edge/Pulse Sensitive Interrupts.............................................................................. 37-6
Implementation Details.............................................................................................................................37-7
Interrupt Latency Counter Architecture.....................................................................................37-7
IP Caveats....................................................................................................................................................37-8
Document Revision History.....................................................................................................................37-8
Altera GMII to RGMII Converter Core............................................................ 38-1
Core Overview............................................................................................................................................38-1
Feature Description................................................................................................................................... 38-1
Supported Features........................................................................................................................ 38-1
Unsupported Features................................................................................................................... 38-1
Parameters...................................................................................................................................................38-2
IP Conguration Parameter......................................................................................................... 38-2
Altera GMII to RGMII Converter Core Interface................................................................................. 38-2
Functional Description..............................................................................................................................38-5
Architecture.................................................................................................................................... 38-5
TOC-15
Altera Corporation
Altera HPS EMAC Interface Splitter Core..............................................................................................38-7
Parameter........................................................................................................................................ 38-7
Document Revision History...................................................................................................................38-14
Altera Generic Quad SPI Controller Core........................................................39-1
Core Overview............................................................................................................................................39-1
Functional Description..............................................................................................................................39-1
Parameters...................................................................................................................................................39-2
Conguration Device Types......................................................................................................... 39-2
I/O Mode.........................................................................................................................................39-2
Chip Selects.....................................................................................................................................39-2
Interface Signals............................................................................................................................. 39-2
Registers...................................................................................................................................................... 39-5
Register Memory Map...................................................................................................................39-5
Register Descriptions.....................................................................................................................39-6
Valid Sector Combination for Sector Protect and Sector Erase Command.........................39-10
Nios II Tools Support.............................................................................................................................. 39-11
Booting Nios II from Flash.........................................................................................................39-11
Nios II HAL Driver......................................................................................................................39-13
Document Revision History...................................................................................................................39-13
Altera Serial Flash Controller Core.................................................................. 40-1
Core Overview............................................................................................................................................40-1
Functional Description..............................................................................................................................40-1
Parameters...................................................................................................................................................40-2
Conguration Device Types......................................................................................................... 40-2
I/O Mode.........................................................................................................................................40-2
Chip Selects.....................................................................................................................................40-2
Interface Signals............................................................................................................................. 40-2
Registers...................................................................................................................................................... 40-5
Register Memory Map...................................................................................................................40-5
Register Descriptions.....................................................................................................................40-6
Valid Sector Combination for Sector Protect and Sector Erase Command.........................40-10
Nios II Tools Support.............................................................................................................................. 40-11
Booting Nios II from Flash.........................................................................................................40-11
Nios II HAL Driver......................................................................................................................40-13
Document Revision History...................................................................................................................40-13
Altera Avalon Mailbox (simple) Core............................................................... 41-1
Core Overview............................................................................................................................................41-1
Functional Description..............................................................................................................................41-1
Message Sending and Retrieval Process......................................................................................41-2
Registers of Component................................................................................................................41-2
Interface.......................................................................................................................................................41-4
Component Interface.....................................................................................................................41-4
Component Parameterization......................................................................................................41-5
TOC-16
Altera Corporation
HAL Driver................................................................................................................................................. 41-6
Feature Description....................................................................................................................... 41-6
Document Revision History...................................................................................................................41-11
Altera I2C Slave to Avalon-MM Master Bridge Core........................................42-1
Core Overview............................................................................................................................................42-1
Functional Description..............................................................................................................................42-1
Block Diagram................................................................................................................................42-2
N-byte Addressing......................................................................................................................... 42-2
N-byte Addressing with N-bit Address Stealing........................................................................42-2
Read Operation.............................................................................................................................. 42-4
Write Operation............................................................................................................................. 42-5
Interacting with Multi-Master......................................................................................................42-7
Qsys Parameters.........................................................................................................................................42-8
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
Avalon-MM DDR Memory Half Rate Bridge Core...........................................43-1
Core Overview............................................................................................................................................43-1
Resource Usage and Performance............................................................................................................43-2
Functional Description..............................................................................................................................43-2
Instantiating the Core in Qsys..................................................................................................................43-3
Example System..........................................................................................................................................43-4
Document Revision History.....................................................................................................................43-4
Altera Avalon I2C (Master) Core.......................................................................44-1
Core Overview............................................................................................................................................44-1
Feature Description................................................................................................................................... 44-1
Supported Features........................................................................................................................ 44-1
Unsupported Features................................................................................................................... 44-1
Conguration Parameters.........................................................................................................................44-1
Interface.......................................................................................................................................................44-2
Registers...................................................................................................................................................... 44-4
Register Memory Map...................................................................................................................44-4
Register Descriptions.....................................................................................................................44-4
Reset and Clock Requirements.............................................................................................................. 44-10
Functional Description........................................................................................................................... 44-10
Overview....................................................................................................................................... 44-10
Conguring TFT_CMD Register Examples.............................................................................44-11
I2C Serial Interface Connection.................................................................................................44-13
Avalon-MM Slave Interface........................................................................................................44-14
Avalon-ST Interface.....................................................................................................................44-14
Programming Model................................................................................................................... 44-14
Document Revision History...................................................................................................................44-15
TOC-17
Altera Corporation
Document Revision History............................................................................... A-1
TOC-18
Altera Corporation
Embedded Peripherals IP User Guide
Introduction 1
2016.12.19
UG-01085 Subscribe Send Feedback
is user guide describes the IP cores provided by Altera® that are included in the Quartus® Prime design
soware.
e 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, congure the
cores, and specify their connectivity.
Altera's Qsys system integration tool is available in the Quartus Prime soware subcription edition version
15.0.
Before using Qsys, review the (Quartus Prime soware Release Notes) for known issues and limitations.
To submit general feedback or technical support, click Feedback on the Quartus Prime soware 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: Verication
•Quartus Prime Soware and Device Support Release Notes
Tool Support
Qsys is a system-level integration tool which is included as part of the Quartus Prime soware. Qsys saves
signicant time and eort 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.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Obsolescence
e 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 Altera’s current IP oering, refer to Altera’s Intellectual Property website.
Related Information
Altera's Intellectual Property
Device Support
e IP cores described in this user guide support all Altera device families except the cores listed in the
table below.
Table 1-1: Device Support
IP Cores Device Support
O-Chip Interfaces
EPCS Serial Flash Controller Core All device families except HardCopy® series.
On-Chip Interfaces
On-Chip FIFO Memory Core All device families except HardCopy series.
Dierent device families support dierent I/O standards, which may aect 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.
Document Revision History
Table 1-2: Embedded Peripheral IP User Guide Introduction Revision History
Date Version Changes
May 2016 2016.05.03 Maintenance release.
June 2015 2015.06.12 Updated for 15.0.
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys.
1-2 Obsolescence UG-01085
2016.12.19
Altera Corporation Embedded Peripherals IP User Guide Introduction
Send Feedback
Date Version Changes
December 2013 v13.1.0 Removed listing of the DMA Controller core in the Qsys unsupported
list. e DMA controller core is now supported in Qsys.
Removed listing of the MDIO core in Device Support Table. e
MDIO core support all device families that the 10-Gbps Ethernet MAC
MegaCore Function supports.
December 2010 v10.1.0 Initial release.
UG-01085
2016.12.19 Document Revision History 1-3
Embedded Peripherals IP User Guide Introduction Altera Corporation
Send Feedback
SDRAM Controller Core 2
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e SDRAM controller core with Avalon ® interface provides an Avalon Memory-Mapped (Avalon-MM)
interface to o-chip SDRAM. e SDRAM controller allows designers to create custom systems in an
Altera device that connect easily to SDRAM chips. e SDRAM controller supports standard SDRAM as
described in the PC100 specication.
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. e 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 (at address space) to Avalon-MM master
peripherals.
e core can access SDRAM subsystems with various data widths (8, 16, 32, or 64 bits), various memory
sizes, and multiple chip selects. e Avalon-MM interface is latency-aware, allowing read transfers to be
pipelined. e core can optionally share its address and data buses with other o-chip Avalon-MM tri-
state devices. is feature is valuable in systems that have limited I/O pins, yet must connect to multiple
memory chips in addition to SDRAM.
Functional Description
e diagram below shows a block diagram of the SDRAM controller core connected to an external
SDRAM chip.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 2-1: SDRAM Controller with Avalon Interface Block Diagram
Avalon-MM slave
interface
to on-chip
logic
SDRAM Controller Core
data, control
Avalon-MM Slave Port
clock
waitrequest
readdatavalid
dq
dqm
PLL
Phase Shift
Interface to SDRAM pins
Altera FPGA
clk
addr
ras
cas
cs
cke
ba
we
Control
Logic
address
SDRAM Clock
Controller Clock
Clock
Source
SDRAM Chip
(PC100)
e following sections describe the components of the SDRAM controller core in detail. All options are
specied at system generation time, and cannot be changed at runtime.
Related Information
SDRAM Controller Core on page 2-1
Avalon-MM Interface
e Avalon-MM slave port is the user-visible part of the SDRAM controller core. e slave port presents a
at, 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. e Avalon-MM interface behaves as a simple
memory interface. ere are no memory-mapped conguration registers.
e Avalon-MM slave port supports peripheral-controlled wait states for read and write transfers. e
slave port stalls the transfer until it can present valid data. e 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 rst data returns aer 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 Specications.
O-Chip SDRAM Interface
e interface to the external SDRAM chip presents the signals dened by the PC100 standard. ese
signals must be connected externally to the SDRAM chip(s) through I/O pins on the Altera device.
Signal Timing and Electrical Characteristics
e timing and sequencing of signals depends on the conguration of the core. e hardware designer
congures the core to match the SDRAM chip chosen for the system. See the Conguration section for
details. e electrical characteristics of the device pins depend on both the target device family and the
assignments made in the Quartus Prime soware. Some device families support a wider range of electrical
2-2 Avalon-MM Interface UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
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.
Synchronizing Clock and Data Signals
e clock for the SDRAM chip (SDRAM clock) must be driven at the same frequency as the clock for the
Avalon-MM interface on the SDRAM controller (controller clock). As in all synchronous designs, you
must ensure that address, data, and control signals at the SDRAM pins are stable when a clock edge
arrives. As shown in the above SDRAM Controller with Avalon Interface block diagram, you can use an
on-chip phase-locked loop (PLL) to alleviate clock skew between the SDRAM controller core and the
SDRAM chip. At lower clock speeds, the PLL might not be necessary. At higher clock rates, a PLL is
necessary to ensure that the SDRAM clock toggles only when signals are stable on the pins. e PLL block
is not part of the SDRAM controller core. If a PLL is necessary, you must instantiate it manually. You can
instantiate the PLL core interface or instantiate an ALTPLL megafunction outside the Qsys system
module.
If you use a PLL, you must tune the PLL to introduce a clock phase shi so that SDRAM clock edges arrive
aer synchronous signals have stabilized. See Clock, PLL and Timing Considerations sections for details.
For more information about instantiating a PLL, refer to PLL Cores chapter. e Nios® II development
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.
e Nios II development tools are available free for download from www.Altera.com.
Clock Enable (CKE) not Supported
e SDRAM controller does not support clock-disable modes. e SDRAM controller permanently asserts
the CKE signal on the SDRAM.
Sharing Pins with other Avalon-MM Tri-State Devices
If an Avalon-MM tri-state bridge is present, the SDRAM controller core can share pins with the existing
tri-state bridge. In this case, the core’s addr, dq (data) and dqm (byte-enable) pins are shared with other
devices connected to the Avalon-MM tri-state bridge. is feature conserves I/O pins, which is valuable in
systems that have multiple external memory chips (for example, ash, SRAM, and SDRAM), but too few
pins to dedicate to the SDRAM chip. See Performance Considerations section for details about how pin
sharing aects performance.
e SDRAM addresses must connect all address bits regardless of the size of the word so that the low-
order address bits on the tri-state bridge align with the low-order address bits on the memory device. e
Avalon-MM tristate address signal always presents a byte address. It is not possible to drop A0 of the tri-
state bridge for memories when the smallest access size is 16 bits or A0-A1 of the tri-state bridge when the
smallest access size is 32 bits.
Board Layout and Pinout Considerations
When making decisions about the board layout and device pinout, try to minimize the skew between the
SDRAM signals. For example, when assigning the device pinout, group the SDRAM signals, including the
SDRAM clock output, physically close together. Also, you can use the Fast Input Register and Fast
Output Register logic options in the Quartus Prime soware. ese logic options place registers for the
SDRAM signals in the I/O cells. Signals driven from registers in I/O cells have similar timing characteris‐
tics, such as tCO, tSU, and tH.
UG-01085
2016.12.19 Synchronizing Clock and Data Signals 2-3
SDRAM Controller Core Altera Corporation
Send Feedback
Performance Considerations
Under optimal conditions, the SDRAM controller core’s 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 aect the core’s performance, as described in the following sections.
Open Row Management
SDRAM chips are arranged as multiple banks of memory, in which each bank is capable of independent
open-row address management. e SDRAM controller core takes advantage of open-row management
for a single bank. Continuous reads or writes within the same row and bank operate at rates approaching
one word per clock. Applications that frequently access dierent destination banks require extra
management cycles to open and close rows.
Sharing Data and Address Pins
When the controller shares pins with other tri-state devices, average access time usually increases and
bandwidth decreases. When access to the tri-state bridge is granted to other devices, the SDRAM incurs
overhead to open and close rows. Furthermore, the SDRAM controller has to wait several clock cycles
before it is granted access again.
To maximize bandwidth, the SDRAM controller automatically maintains control of the tri-state bridge as
long as back-to-back read or write transactions continue within the same row and bank.
is behavior may degrade the average access time for other devices sharing the Avalon-MM tri-state
bridge.
e SDRAM controller closes an open row whenever there is a break in back-to-back transactions, or
whenever a refresh transaction is required. As a result:
•e controller cannot permanently block access to other devices sharing the tri-state bridge.
•e controller is guaranteed not to violate the SDRAM’s row open time limit.
Hardware Design and Target Device
e target device aects the maximum achievable clock frequency of a hardware design. Certain device
families achieve higher fMAX performance than other families. Furthermore, within a device family, faster
speed grades achieve higher performance. e SDRAM controller core can achieve 100 MHz in Altera’s
high-performance device families, such as Stratix® series. However, the core might not achieve 100 MHz
performance in all Altera device families.
e fMAX performance also depends on the system design. e SDRAM controller clock can also drive
other logic in the system module, which might aect the maximum achievable frequency. For the SDRAM
controller core to achieve fMAX performance of 100 MHz, all components driven by the same clock must
be designed for a 100 MHz clock rate, and timing analysis in the Quartus Prime soware must verify that
the overall hardware design is capable of 100 MHz operation.
Conguration
e SDRAM controller MegaWizard has two pages: Memory Prole and Timing. is section describes
the options available on each page.
e Presets list oers several pre-dened SDRAM congurations as a convenience. If the SDRAM
subsystem on the target board matches one of the preset congurations, you can congure the SDRAM
2-4 Performance Considerations UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
controller core easily by selecting the appropriate preset value. e following preset congurations are
dened:
• 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 conguration automatically changes values on the Memory Prole and Timing tabs
to match the specic conguration. Altering a conguration setting on any page changes the Preset
value to custom.
Memory Prole Page
e Memory Prole page allows you to specify the structure of the SDRAM subsystem such as address
and data bus widths, the number of chip select signals, and the number of banks.
Table 2-1: Memory Prole Page Settings
Settings Allowed Values Default Values Description
Data Width 8, 16, 32, 64 32 SDRAM data bus width. is value
determines the width of the dq bus
(data) and the dqm bus (byte-
enable).
Architecture
Settings
Chip Selects 1, 2, 4, 8 1 Number of independent chip
selects in the SDRAM subsystem.
By using multiple chip selects, the
SDRAM controller can combine
multiple SDRAM chips into one
memory subsystem.
Banks 2, 4 4 Number of SDRAM banks. is
value determines the width of the
ba bus (bank address) that
connects to the SDRAM. e
correct value is provided in the
data sheet for the target SDRAM.
Address
Width
Settings
Row 11, 12, 13, 14 12 Number of row address bits. is
value determines the width of the
addr bus. e Row and Column
values depend on the geometry of
the chosen SDRAM. For example,
an SDRAM organized as 4096
(212) rows by 512 columns has a
Row value of 12.
Column >= 8, and less
than Row value
8 Number of column address bits.
For example, the SDRAM
organized as 4096 rows by 512 (29)
columns has a Column value of 9.
UG-01085
2016.12.19 Memory Prole Page 2-5
SDRAM Controller Core Altera Corporation
Send Feedback
Settings Allowed Values Default Values Description
Share pins via tri-state bridge dq/
dqm/addr I/O pins
On, O O When set to No, all pins are
dedicated to the SDRAM chip.
When set to Yes, the addr, dq, and
dqm pins can be shared with a
tristate bridge in the system. In
this case, select the appropriate
tristate bridge from the pull-down
menu.
Include a functional memory
model in the system testbench
On, O On When on, Qsys functional
simulation model for the SDRAM
chip. is default memory model
accelerates the process of creating
and verifying systems that use the
SDRAM controller. See Hardware
Simulation Considerations
section.
Based on the settings entered on the Memory Prole 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
e Timing page allows designers to enter the timing specications of the SDRAM chip(s) used. e
correct values are available in the manufacturer’s data sheet for the target SDRAM.
Table 2-2: Timing Page Settings
Settings Allowed
Values
Default
Value
Description
CAS latency 1, 2, 3 3 Latency (in clock cycles) from a read command to data
out.
Initialization
refresh cycles
1–8 2 is value species how many refresh cycles the SDRAM
controller performs as part of the initialization sequence
aer reset.
Issue one refresh
command every
— 15.625 µs is value species how oen the SDRAM controller
refreshes the SDRAM. A typical SDRAM requires 4,096
refresh commands every 64 ms, which can be achieved by
issuing one refresh command every 64 ms / 4,096 = 15.625
μs.
Delay aer power
up, before initiali‐
zation
— 100 µs e delay from stable clock and power to SDRAM initiali‐
zation.
Duration of refresh
command (t_rfc)
— 70 ns Auto Refresh period.
2-6 Timing Page UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
Settings Allowed
Values
Default
Value
Description
Duration of
precharge
command (t_rp)
— 20 ns Precharge command period.
ACTIVE to READ
or WRITE delay
(t_rcd)
— 20 ns ACTIVE to READ or WRITE delay.
Access time (t_ac) — 17 ns Access time from clock edge. is value may depend on
CAS latency.
Write recovery
time (t_wr, No
auto precharge)
— 14 ns Write recovery if explicit precharge commands are issued.
is SDRAM controller always issues explicit precharge
commands.
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.
Hardware Simulation Considerations
is section discusses considerations for simulating systems with SDRAM. ree major components are
required for simulation:
• A simulation model for the SDRAM controller.
• A simulation model for the SDRAM chip(s), also called the memory model.
• A simulation testbench that wires the memory model to the SDRAM controller pins.
Some or all of these components are generated by Qsys at system generation time.
SDRAM Controller Simulation Model
e SDRAM controller design les generated by Qsys are suitable for both synthesis and simulation. Some
simulation features are implemented in the HDL using “translate on/o” synthesis directives that make
certain sections of HDL code invisible to the synthesis tool.
e simulation features are implemented primarily for easy simulation of Nios and Nios II processor
systems using the ModelSim® simulator. e SDRAM controller simulation model is not ModelSim
specic. However, minor changes may be required to make the model work with other simulators.
If you change the simulation directives to create a custom simulation ow, be aware that Qsys overwrites
existing les during system generation. Take precautions to ensure your changes are not overwritten.
Refer to AN 351: Simulating Nios II Processor Designs for a demonstration of simulation of the SDRAM
controller in the context of Nios II embedded processor systems.
SDRAM Memory Model
is section describes the two options for simulating a memory model of the SDRAM chip(s).
UG-01085
2016.12.19 Hardware Simulation Considerations 2-7
SDRAM Controller Core Altera Corporation
Send Feedback
Using the Generic Memory Model
If the Include a functional memory model the system testbench option is enabled at system generation,
Qsys generates an HDL simulation model for the SDRAM memory. In the auto-generated system
testbench, Qsys automatically wires this memory model to the SDRAM controller pins.
Using the automatic memory model and testbench accelerates the process of creating and verifying
systems that use the SDRAM controller. However, the memory model is a generic functional model that
does not reect the true timing or functionality of real SDRAM chips. e generic model is always
structured as a single, monolithic block of memory. For example, even for a system that combines two
SDRAM chips, the generic memory model is implemented as a single entity.
Using the SDRAM Manufacturer's Memory Model
If the Include a functional memory model the system testbench option is not enabled, you are
responsible for obtaining a memory model from the SDRAM manufacturer, and manually wiring the
model to the SDRAM controller pins in the system testbench.
Example Congurations
e following examples show how to connect the SDRAM controller outputs to an SDRAM chip or chips.
e bus labeled ctl is an aggregate of the remaining signals, such as cas_n, ras_n, cke and we_n.
e address, data, and control signals are wired directly from the controller to the chip. e result is a 128-
Mbit (16-Mbyte) memory space.
Figure 2-2: Single 128-Mbit SDRAM Chip with 32-Bit Data
data
32
128 Mbits
16 Mbytes
32 data width device
SDRAM
Controller
Altera FPGA
Avalon-MM
interface
to
on-chip
logic
addr
cs_n
ctl
e address and control signals connect in parallel to both chips. e chips share the chipselect (cs_n)
signal. Each chip provides half of the 32-bit data bus. e result is a logical 128-Mbit (16-Mbyte) 32-bit
data memory.
2-8 Using the Generic Memory Model UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
Figure 2-3: Two 64-MBit SDRAM Chips Each with 16-Bit Data
addr
ctl
cs_n
SDRAM
Controller
Altera FPGA
Avalon-MM
interface
to
on-chip
logic
64 Mbits
8 Mbytes
16 data width device
64 Mbits
8 Mbytes
16 data width device
data
16
16
32
e address, data, and control signals connect in parallel to the two chips. e chipselect bus (cs_n[1:0])
determines which chip is selected. e result is a logical 256-Mbit 32-bit wide memory.
Figure 2-4: Two 128-Mbit SDRAM Chips Each with 32-Bit Data
addr
ctl
cs_n [0]
cs_n [1]
SDRAM
Controller
Altera FPGA
Avalon-MM
interface
to
on-chip
logic
data
32
128 Mbits
16 Mbytes
32 data width device
128 Mbits
16 Mbytes
32 data width device
32
32
Software Programming Model
e SDRAM controller behaves like simple memory when accessed via the Avalon-MM interface. ere
are no soware-congurable settings and no memory-mapped registers. No soware driver routines are
required for a processor to access the SDRAM controller.
Clock, PLL and Timing Considerations
is section describes issues related to synchronizing signals from the SDRAM controller core with the
clock that drives the SDRAM chip. During SDRAM transactions, the address, data, and control signals are
valid at the SDRAM pins for a window of time, during which the SDRAM clock must toggle to capture the
UG-01085
2016.12.19 Software Programming Model 2-9
SDRAM Controller Core Altera Corporation
Send Feedback
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. en 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 eort to align the phase shi 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 conguring the PLLs in Altera devices, refer to the ALTPLL Megafunction User Guide.
Factors Aecting SDRAM Timing
e location and duration of the window depends on several factors:
• Timing parameters of the device and SDRAM I/O pins — I/O timing parameters vary based on device
family and speed grade.
• Pin location on the device — I/O pins connected to row routing have dierent timing than pins
connected to column routing.
• Logic options used during the Quartus Prime compilation — Logic options such as the Fast Input
Register and Fast Output Register logic aect the design t. e location of logic and registers inside
the device aects the propagation delays of signals to the I/O pins.
• SDRAM CAS latency
As a result, the valid window timing is dierent for dierent combinations of FPGA and SDRAM
devices. e window depends on the Quartus Prime soware tting results and pin assignments.
Symptoms of an Untuned PLL
Detecting when the PLL is not tuned correctly might be dicult. Data transfers to or from the SDRAM
might not fail universally. For example, individual transfers to the SDRAM controller might succeed,
whereas burst transfers fail. For processor-based systems, if soware can perform read or write data to
SDRAM, but cannot run when the code is located in SDRAM, the PLL is probably tuned incorrectly.
Estimating the Valid Signal Window
is section describes how to estimate the location and duration of the valid signal window using timing
parameters provided in the SDRAM datasheet and the Quartus Prime soware compilation report. Aer
nding the window, tune the PLL so that SDRAM clock edges occur exactly in the middle of the window.
Calculating the window is a two-step process. First, determine by how much time the SDRAM clock can
lag the controller clock, and then by how much time it can lead. Aer nding the maximum lag and lead
values, calculate the midpoint between them.
ese calculations provide an estimation only. e following delays can also aect proper PLL tuning, but
are not accounted for by these calculations.
2-10 Factors Aecting SDRAM Timing UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
• Signal skew due to delays on the printed circuit board — ese calculations assume zero skew.
• Delay from the PLL clock output nodes to destinations — ese 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 signicantly
dierent, you must account for this phase shi in your window calculations.
Lag is a negative time shi, relative to the controller clock, and lead is a positive time shi. e 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
UG-01085
2016.12.19 Estimating the Valid Signal Window 2-11
SDRAM Controller Core Altera Corporation
Send Feedback
Figure 2-6: Calculating the Maximum SDRAM Clock Lead
Example Calculation
is section demonstrates a calculation of the signal window for a Micron MT48LC4M32B2-7 SDRAM
chip and design targeting the Stratix II EP2S60F672C5 device. is 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
soware.
Table 2-3: Timing Parameters for Micron MT48LC4M32B2 SDRAM Device
Parameter Symbol
Value (ns) in -7 Speed Grade
Min. Max.
Access time
from CLK (pos.
edge)
CL = 3 tAC(3) — 5.5
CL = 2 tAC(2) — 8
CL = 1 tAC(1) — 17
Address hold time tAH 1 —
Address setup time tAS 2 —
CLK high-level width tCH 2.75 —
CLK low-level width tCL 2.75 —
Clock cycle
time
CL = 3 tCK(3) 7 —
CL = 2 tCK(2) 10 —
CL = 1 tCK(1) 20 —
CKE hold time tCKH 1 —
2-12 Example Calculation UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
Parameter Symbol
Value (ns) in -7 Speed Grade
Min. Max.
CKE setup time tCKS 2 —
CS#, RAS#, CAS#, WE#, DQM hold
time
tCMH 1 —
CS#, RAS#, CAS#, WE#, DQM
setup time
tCMS 2 —
Data-in hold time tDH 1
Data-in setup time tDS 2
Data-out high-
impedance
time
CL = 3 tHZ(3) 5.5
CL = 2 tHZ(2) — 8
CL = 1 tHZ(1) — 17
Data-out low-impedance time tLZ 1 —
Data-out hold time tOH 2.5
e FPGA I/O Timing Parameters table below shows the relevant timing information, obtained from the
Timing Analyzer section of the Quartus Prime Compilation Report. e values in the table are the
maximum or minimum values among all device pins related to the SDRAM. e 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.
Table 2-4: FPGA I/O Timing Parameters
Parameter Symbol Value (ns)
Clock period tCLK 20
Minimum clock-to-output time tCO_MIN 2.399
Maximum clock-to-output time tCO_MAX 2.477
Maximum hold time aer clock tH_MAX –5.607
Maximum setup time before clock tSU_MAX 5.936
You must compile the design in the Quartus Prime soware 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 specic
design.
e timing values found in the compilation report can change, depending on tting, pin location, and
other Quartus Prime logic settings. When you recompile the design in the Quartus Prime soware, verify
that the I/O timing has not changed signicantly.
e following examples illustrate the calculations from gures Maximum SDRAM Clock Lag and
Maximum Lead also using the values from the Timing Parameters and FPGA I/O Timing Parameters
table.
UG-01085
2016.12.19 Example Calculation 2-13
SDRAM Controller Core Altera Corporation
Send Feedback
e 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
e 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
erefore, for this example you can shi the phase of the SDRAM clock from –8.107 ns to 1.399 ns relative
to the controller clock. Choosing a phase shi in the middle of this window results in the value (–8.107
+ 1.399)/2 = –3.35 ns.
Document Revision History
Table 2-5: SDRAM Controller Core Revision History
Date Version Changes
May 2016 2016.05.03 Maintenance release.
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.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
2-14 Document Revision History UG-01085
2016.12.19
Altera Corporation SDRAM Controller Core
Send Feedback
Tri-State SDRAM Core 3
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Altera SDRAM Tri-State Controller core with Avalon® interface provides an Avalon Memory-Mapped
(Avalon-MM) interface to o-chip SDRAM. e SDRAM controller allows designers to create custom
systems in an Altera device that connect easily to SDRAM chips. e SDRAM controller supports
standard SDRAM dened by the PC100 specication.
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. e SDRAM controller connects to one or more
SDRAM chips, and handles all SDRAM protocol requirements. e SDRAM controller core presents an
Avalon-MM slave port that appears as linear memory (at address space) to Avalon-MM master
peripherals.
e Avalon-MM interface is latency-aware, allowing read transfers to be pipelined. e core can optionally
share its address and data buses with other o-chip Avalon-MM tri-state devices. is feature is valuable
in systems that have limited I/O pins, yet must connect to multiple memory chips in addition to SDRAM.
e 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 Specications
Feature Description
e 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/
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Block Diagram
Figure 3-1: Tri-State SDRAM Block Diagram
Conguration Parameter
e following table shows the conguration parameters available for user to program during generation
time of the IP core.
Memory Prole Page
e Memory Prole page allows you to specify the structure of the SDRAM subsystem such as address and
data bus widths, the number of chip select signals, and the number of banks.
Table 3-1: Conguration Parameters
Parameter GUI Legal Values Default Values Units
Data Width 8, 16, 32, 64 32 (Bit)s
Architecture
Chip Selects 1, 2, 4, 8 1 (Bit)s
Banks 2, 4 4 (Bit)s
Address Widths
Row 11:14 12 (Bit)s
Column 8:14 8 (Bit)s
Timing Page
e Timing page allows designers to enter the timing specications of the Tri-State SDRAM chip(s) used.
e correct values are available in the manufacturer’s data sheet for the target SDRAM.
3-2 Block Diagram UG-01085
2016.12.19
Altera Corporation Tri-State SDRAM Core
Send Feedback
Table 3-2: Conguration Timing Parameters
Parameter GUI Legal Values Default Values Units
CAS latency cycles 1, 2, 3 3 Cycles
Initialization refresh cycles 1:8 2 Cycles
Issue one refresh command
every
0.0:156.25 15.625 us
Delay aer power up, before
initialization
0.0:999.0 100.00 us
Duration of refresh command
(t_rfc)
0.0:700.0 70.0 ns
Duration of precharge
command (t_rp)
0.0:200.0 20.0 ns
ACTIVE to READ or WRITE
delay (t_rcd)
0.0:200.0 20.0 ns
Access time (t_ac) 0.0:999.0 5.5 ns
Write recovery time (t_wr, no
auto precharge)
0.0:140.0 14.0 ns
Interface
e following are top level signals from core
Table 3-3: Clock and Reset Signals
Signal Width Direction Description
clk 1 Input System Clock
rst_n 1 Input System asynchronous reset. e signal is asserted
asynchronously, but is de-asserted synchronously
aer the rising edge of ssi_clk. e synchronization
must be provided external to this component.
UG-01085
2016.12.19 Interface 3-3
Tri-State SDRAM Core Altera Corporation
Send Feedback
Table 3-4: Avalon-MM Slave Interface Signals
Signal Width Direction Description
avs_read 1 Input Avalon-MM read control. Asserted to
indicate a read transfer. If present,
readdata is required.
avs_write 1 Input Avalon-MM write control. Asserted to
indicate a write transfer. If present,
writedata is required.
avs_byteenable dqm_width Input Enables specic byte lane(s) during
transfer. Each bit corresponds to a byte
in avs_writedata and avs_readdata.
avs_address controller_addr_
width Input Avalon-MM address bus.
avs_writedata sdram_data_width Input Avalon-MM write data bus. Driven by
the bus master (bridge unit) during
write cycles.
avs_readdata sdram_data_width Output Avalon-MM readback data. Driven by
the altera_spi during read cycles.
avs_readdatavalid 1 Output Asserted to indicate that the avs_
readdata signals contains valid data in
response to a previous read request.
avs_waitrequest 1 Output Asserted when it is unable to respond to
a read or write request.
Table 3-5: Tristate Conduit Master / SDRAM Interface Signals
Signal Width Direction Description
tcm_grant 1 Input When asserted, indicates that
a tristate conduit master has
been granted access to
perform transactions. tcm_
grant is asserted in
response to the tcm_request
signal and remains asserted
until 1 cycle following the
deassertion of request.
Valid only when pin sharing
mode is enabled.
3-4 Interface UG-01085
2016.12.19
Altera Corporation Tri-State SDRAM Core
Send Feedback
Signal Width Direction Description
tcm_request 1 Output e meaning of tcm_
request depends on the
state of the tcm_grant
signal, as the following rules
dictate:
• When tcm_request is
asserted and tcm_grant is
deasserted, tcm_request
is requesting access for
the current cycle.
• When tcm_request is
asserted and tcm_grant is
asserted, tcm_request is
requesting access for the
next cycle; consequently,
tcm_request should be
deasserted on the nal
cycle of an access.
Because tcm_request is
deasserted in the last cycle of
a bus access, it can be
reasserted immediately
following the nal cycle of a
transfer, making both
rearbitration and continuous
bus access possible if no
other masters are requesting
access.
Once asserted, tcm_request
must remain asserted until
granted; consequently, the
shortest bus access is 2
cycles.
Valid only when pin-sharing
mode is enabled.
sdram_dq_width sdram_data_width Output SDRAM data bus output.
Valid only when pin-sharing
mode is enabled
sdram_dq_in sdram_data_width Input SDRAM data bus output.
Valid only when pin-sharing
mode is enabled.
UG-01085
2016.12.19 Interface 3-5
Tri-State SDRAM Core Altera Corporation
Send Feedback
Signal Width Direction Description
sdram_dq_oen 1 Output SDRAM data bus input.
Valid only when pin-sharing
mode is enabled.
sdram_dq sdram_data_width Input/Output SDRAM data bus.
Valid only when pin-sharing
mode is disabled.
sdram_addr sdram_addr_width Output SDRAM address bus.
sdram_ba sdram_bank_width Output SDRAM bank address.
sdram_dqm dqm_width Output SDRAM data mask. When
asserted, it indicates to the
SDRAM chip that the
corresponding data signal is
suppressed. ere is one
DQM line per 8 bits data
lines
sdram_ras_n 1 Output Row Address Select. When
taken LOW, the value on the
tcm_addr_out bus is used to
select the bank and activate
the required row.
sdram_cas_n 1 Output Column Address Select.
When taken LOW, the value
on the tcm_addr_out bus is
used to select the bank and
required column. A read or
write operation will then be
conducted from that
memory location, depending
on the state of tcm_we_out.
sdram_we_n 1 Output SDRAM Write Enable,
determins whether the
location addressed by tcm_
addr_out is written to or
read from.
0=Read
1=Write
sdram_cs_n Output SDRAM Chip Select. When
taken LOW, will enables the
SDRAM device.
3-6 Interface UG-01085
2016.12.19
Altera Corporation Tri-State SDRAM Core
Send Feedback
Signal Width Direction Description
sdram_cke 1 Output SDRAM Clock Enable. e
SDRAM controller does not
support clock-disable modes.
e SDRAM controller
permanently asserts the tcm_
sdr_cke_out signal on the
SDRAM.
Note: e SDRAM controller does not have any congurable control status registers (CSR).
Reset and Clock Requirements
e main reset input signal to the SDRAM is treated as an asynchronous reset input from the SDRAM
core perspective. A reset synchronizer circuit, as typically implemented for each reset domain in a
complete SOC/ASIC system is not implemented within the SDRAM core. Instead, this reset synchronizer
circuit should be implemented externally to the SDRAM, in a higher hierarchy within the complete system
design, so that the “asynchronous assertion, synchronous de-assertion” rule is fullled.
e SDRAM core accepts an input clock at its clk input with maximum frequency of 100-MHz. e other
requirements for the clock, such as its minimum frequency should be similar to the requirement of the
external SDRAM which the SDRAM is interfaced to.
Architecture
e 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
(at address space) to Avalon-MM master device.
e core can access SDRAM subsystems with:
• Various data widths (8-, 16-, 32- or 64-bits)
• Various memory sizes
• Multiple chip selects
e Avalon-MM interface is latency-aware, allowing read transfers to be pipelined. e core can optionally
share its address and data buses with other o-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. is 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 aer the read command. e SDRAM controller must ensure that the data bus is
never required for a read and a write at the same time.
UG-01085
2016.12.19 Reset and Clock Requirements 3-7
Tri-State SDRAM Core Altera Corporation
Send Feedback
Avalon-MM Slave Interface and CSR
e host processor perform data read and write operation to the external SDRAM devices through the
Avalon-MM interface of the SDRAM core.
Please refer to Avalon Interface Specications for more information on the details of the Avalon-MM Slave
Interface.
Related Information
Avalon Interface Specications
3-8 Avalon-MM Slave Interface and CSR UG-01085
2016.12.19
Altera Corporation Tri-State SDRAM Core
Send Feedback
Block Level Usage Model
Figure 3-2: Shared-Bus System
UG-01085
2016.12.19 Block Level Usage Model 3-9
Tri-State SDRAM Core Altera Corporation
Send Feedback
Document Revision History
Table 3-6: Altera SDRAM Tri-State Controller Core Revision History
Date Version Changes
July 2014 2014.07.24 Initial release.
3-10 Document Revision History UG-01085
2016.12.19
Altera Corporation Tri-State SDRAM Core
Send Feedback
Compact Flash Core 4
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e core supports PIO mode 0.
e 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.
Functional Description
Figure 4-1: System With a CompactFlash Core
Altera FPGA
e
d
i
ctl
data
address
cfctl
idectl
Registers
IRQ
data
address
IRQ
Compact FLash
Device
Avalon-to-
Compact Flash
Avalon-MM Slave PortAvalon-MM Slave Port
System Interconnect Fabric
Avalon-MM
Master
(e.g. CPU)
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
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. ese 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.
e 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 specications available at www.compact-
ash.org.
Required Connections
e table below lists the required connections between the CompactFlash core and the CompactFlash
device.
Table 4-1: Core to Device Required Connections
CompactFlash Interface Signal
Name
Pin Type CompactFlash Pin Number
addr[0] Output 20
addr[1] Output 19
addr[2] Output 18
addr[3] Output 17
addr[4] Output 16
addr[5] Output 15
addr[6] Output 14
addr[7] Output 12
addr[8] Output 11
addr[9] Output 10
addr[10] Output 8
atasel_n Output 9
cs_n[0] Output 7
cs_n[1] Output 32
data[0] Input/Output 21
data[1] Input/Output 22
data[2] Input/Output 23
4-2 Required Connections UG-01085
2016.12.19
Altera Corporation Compact Flash Core
Send Feedback
CompactFlash Interface Signal
Name
Pin Type CompactFlash Pin Number
data[3] Input/Output 2
data[4] Input/Output 3
data[5] Input/Output 4
data[6] Input/Output 5
data[7] Input/Output 6
data[8] Input/Output 47
data[9] Input/Output 48
data[10] Input/Output 49
data[11] Input/Output 27
data[12] Input/Output 28
data[13] Input/Output 29
data[14] Input/Output 30
data[15] Input/Output 31
detect Input 25 or 26
intrq Input 37
iord_n Output 34
iordy Input 42
iowr_n Output 35
power Output CompactFlash power controller, if present
reset_n Output 41
rfu Output 44
we_n Output 46
Software Programming Model
is section describes the soware programming model for the CompactFlash core.
HAL System Library Support
e Altera-provided HAL API functions include a device driver that you can use to initialize the
CompactFlash core. To perform other operations, use the low-level macros provided.
For more information on the macros, refer to the "Soware Files" section.
Related Information
Soware Files on page 4-4
UG-01085
2016.12.19 Software Programming Model 4-3
Compact Flash Core Altera Corporation
Send Feedback
Software Files
e CompactFlash core provides the following soware les. ese les dene the low-level access to the
hardware. Application developers should not modify these les.
•altera_avalon_cf_regs.h—e header le that denes the core's register maps.
•altera_avalon_cf.h, altera_avalon_cf.c—e header and source code for the functions
and variables required to integrate the driver into the HAL system library.
Register Maps
is section describes the register maps for the Avalon-MM slave interfaces.
Ide Registers
e ide port in the CompactFlash core allows you to access the IDE registers on a CompactFlash device.
Table 4-2: Ide Register Map
Oset
Register Names
Read Operation Write Operation
0RD Data WR Data
1Error Features
2Sector Count Sector Count
3Sector No Sector No
4Cylinder Low Cylinder Low
5Cylinder High Cylinder High
6Select Card/Head Select Card/Head
7Status Command
14 Alt Status Device Control
Ctl Registers
e ctl port in the CompactFlash core provides access to the registers which control the core’s operation
and interface.
Table 4-3: Ctl Register Map
Oset Register
Fields
31:4 3 2 1 0
0cfctl Reserved IDET RST PWR DET
1idectl Reserved IIDE
2 Reserved Reserved
4-4 Software Files UG-01085
2016.12.19
Altera Corporation Compact Flash Core
Send Feedback
Oset Register
Fields
31:4 3 2 1 0
3 Reserved Reserved
Cfctl Register
e cfctl register controls the operations of the CompactFlash core. Reading the cfctl register clears the
interrupt.
Table 4-4: cfctl Register Bits
Bit Number Bit Name Read/Write Description
0DET RO Detect. is bit is set to 1 when the core detects a CompactFlash
device.
1PWR RW Power. When this bit is set to 1, power is being supplied to the
CompactFlash device.
2RST RW Reset. When this bit is set to 1, the CompactFlash device is held in
a reset state. Setting this bit to 0 returns the device to its active
state.
3IDET RW Detect Interrupt Enable. When this bit is set to 1, the Compact‐
Flash core generates an interrupt each time the value of the det bit
changes.
idectl Register
e idectl register controls the interface to the CompactFlash device.
Table 4-5: idectl Register
Bit Number Bit Name Read/Write Description
0IIDE RW IDE Interrupt Enable. When this bit is set to 1, the CompactFlash
core generates an interrupt following an interrupt generated by the
CompactFlash device. Setting this bit to 0 disables the IDE
interrupt.
Document Revision History
Table 4-6: Compact Flash Core 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.
UG-01085
2016.12.19 Cfctl Register 4-5
Compact Flash Core Altera Corporation
Send Feedback
Date Version Changes
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
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.
4-6 Document Revision History UG-01085
2016.12.19
Altera Corporation Compact Flash Core
Send Feedback
EPCS Serial Flash Controller Core 5
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e EPCS serial ash controller core with Avalon interface allows Nios II systems to access an Altera EPCS
serial conguration 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 ash devices.
Using the EPCS serial ash controller core, Nios II systems can:
• Store program code in the EPCS device. e EPCS serial ash 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 conguration data. For example, a network-enabled embedded system can receive
new FPGA conguration data over a network, and use the core to program the new data into an EPCS
serial conguration device.
e EPCS serial ash controller core is Qsys-ready and integrates easily into any Qsys-generated
system. e ash 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 conguration device family, refer to the Serial Conguration
Devices Data Sheet.
For details about using the Nios II HAL API to read and write ash memory, refer to the Nios II
Soware 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 ash controller core supersedes the Active Serial Memory
Interface (ASMI) device. New designs should use the EPCS serial ash controller core instead of the
ASMI core.
Related Information
•Serial Conguration Devices (EPCS1, EPCS4, EPCS16, EPCS64 and EPCS128) Data Sheet
•Nios II Classic Soware Developer's Handbook
•Nios II Flash Programmer User Guide
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Functional Description
As shown below, the EPCS device's memory can be thought of as two separate regions:
•FPGA conguration memory—FPGA conguration data is stored in this region.
•General-purpose memory—If the FPGA conguration data does not ll up the entire EPCS device,
any le-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
Other
On-Chip
Peripheral(s)
Nios II CPU
EPCS
Controller Core
Config
Memory
General-
Purpose
Memory
Boot-Loader
ROM
System Interconnect Fabric
• By virtue of the HAL generic device model for ash devices, accessing the EPCS device using the HAL
API is the same as accessing any ash memory. e EPCS device has a special-purpose hardware
interface, so Nios II programs must read and write the EPCS memory using the provided HAL ash
drivers.
e EPCS serial ash 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. e Nios II processor can be congured to boot from the
EPCS serial ash controller core. To do so, set the Nios II reset address to the base address of the EPCS
serial ash controller core. In this case, aer reset the CPU rst executes code from the boot-loader ROM,
which copies data from the EPCS general-purpose memory region into a RAM. en, program control
5-2 Functional Description UG-01085
2016.12.19
Altera Corporation EPCS Serial Flash Controller Core
Send Feedback
transfers to the RAM. e Nios II IDE provides facilities to compile a program for storage in the EPCS
device, and create a programming le 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 conguration data and Nios II program data, use
the Nios II IDE ash programmer utility.
e Altera EPCS conguration 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 ash 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 conguration using the EPCS device (in
other words, active serial conguration mode), no further connection is necessary between the EPCS
serial ash controller core and the EPCS device. When you compile the Qsys system in the Quartus Prime
soware, the EPCS serial ash 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 conguration
mode) by turning o the respective parameters in the MegaWizard interface. When this option is turned
o or when the target device is a Cyclone III or Cyclone IV device, you have the exibility 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 soware 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 conguration 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 conguration 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
Avalon-MM Slave Interface and Registers
e EPCS serial ash controller core has a single Avalon-MM slave interface that provides access to both
boot-loader code and registers that control the core. As shown in below, the rst segment is dedicated to
the boot-loader code, and the next seven words are control and data registers. A Nios II CPU can read the
instruction words, starting from the core's base address as at memory space, which enables the CPU to
reset the core's address space.
UG-01085
2016.12.19 Avalon-MM Slave Interface and Registers 5-3
EPCS Serial Flash Controller Core Altera Corporation
Send Feedback
e EPCS serial ash controller core includes an interrupt signal that can be used to interrupt the CPU
when a transfer has completed.
Table 5-1: EPCS Serial Flash Controller Core Register Map
Oset
(32-bit Word Address) Register Name R/W
Bit Description
31:0
0x00 .. 0xFF Boot ROM Memory R Boot Loader Code
0x100 Read Data R
0x101 Write Data W
0x102 Status R/W
0x103 Control R/W
0x104 Reserved —
0x105 Slave Enable R/W
0x106 End of Packet R/W
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.
Conguration
e core must be connected to a Nios II processor. e 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
congure the core to use general I/O pins instead of dedicated pins by turning o both parameters,
Automatically select dedicated active serial interface, if supported and Use dedicated active serial
interface.
Only one EPCS serial ash controller core can be instantiated in each FPGA design.
Software Programming Model
is section describes the soware programming model for the EPCS serial ash controller core. Altera
provides HAL system library drivers that enable you to erase and write the EPCS memory using the HAL
API functions. Altera does not publish the usage of the cores registers. erefore, you must use the HAL
drivers provided by Altera to access the EPCS device.
HAL System Library Support
e Altera-provided driver implements a HAL ash device driver that integrates into the HAL system
library for Nios II systems. Programs call the familiar HAL API functions to program the EPCS memory.
You do not need to know the details of the underlying drivers to use them.
e driver for the EPCS device is excluded when the reduced device drivers option is enabled in a BSP or
system library. To force inclusion of the EPCS drivers in a BSP with the reduced device drivers option
5-4 Conguration UG-01085
2016.12.19
Altera Corporation EPCS Serial Flash Controller Core
Send Feedback
enabled, you can dene 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>
e HAL API for programming ash, including C-code examples, is described in detail in the Nios II
Classic Soware Developer's Handbook.
For details about managing and programming the EPCS device contents, refer to the Nios II Flash
Programmer User Guide.
Software Files
e EPCS serial ash controller core provides the following soware les. ese les provide low-level
access to the hardware and drivers that integrate into the Nios II HAL system library. Application
developers should not modify these les.
•altera_avalon_epcs_flash_controller.h, altera_avalon_epcs_flash_controller.c
—Header and source les that dene the drivers required for integration into the HAL system library.
•epcs_commands.h, epcs_commands.c—Header and source les that directly control the EPCS
device hardware to read and write the device. ese les also rely on the Altera SPI core drivers.
Document Revision History
Table 5-2: EPCS Serial Flash Controller Core Revision History
Date Version Changes
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2013 v13.1.0 Removed Cyclone and Cyclone II device information in the "EPCS
Serial Flash Controller Core Register Map" table.
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 descriptions of register elds and bits.
Updated the section on HAL System Library Support.
March 2009 v9.0.0 Updated the boot ROM memory oset 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.
May 2008 v8.0.0 Updated the boot rom size.
Added additional steps to perform to connect output pins in
Cyclone III devices.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
UG-01085
2016.12.19 Software Files 5-5
EPCS Serial Flash Controller Core Altera Corporation
Send Feedback
JTAG UART Core 6
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e core
provides an Avalon interface that hides the complexities of the JTAG interface from embedded soware
programmers. Master peripherals (such as a Nios II processor) communicate with the core by reading and
writing control and data registers.
e JTAG UART core uses the JTAG circuitry built in to Altera FPGAs, and provides host access via the
JTAG pins on the FPGA. e host PC can connect to the FPGA via any Altera JTAG download cable, such
as the Intel® FPGA download cable II. Soware 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 soware 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 Soware Developer's Handbook or the Nios II IDE
online help.
For the host PC, Altera provides JTAG terminal soware that manages the connection to the target,
decodes the JTAG data stream, and displays characters on screen.
e JTAG UART core is Qsys-ready and integrates easily into any Qsys-generated system.
Functional Description
e gure below shows a block diagram of the JTAG UART core and its connection to the JTAG circuitry
inside an Altera FPGA. e following sections describe the components of the core.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 6-1: JTAG UART Core Block Diagram
JTAG UART Core
Registers
JTAG
Hub
Interface
IRQ
Write FIFO
Read FIFO
Data
Control
JTAG
Hub
JTAG Connection to Host PC
Altera FPGA
TCK
TDI
TDO
TMS
TRST
JTAG
Controller
Automatically Generated by Quartus Prime Softwawre
Built-In Feature of Altera FPGA
Avalon-MM slave
interface
to on-chip logic
Other Nodes Using JTAG interface
(For example, another JTAG UART
Avalon Slave Interface and Registers
e JTAG UART core provides an Avalon slave interface to the JTAG circuitry on an Altera FPGA. e
user-visible interface to the JTAG UART core consists of two 32-bit registers, data and control, that are
accessed through an Avalon slave port. An Avalon master, such as a Nios II processor, accesses the
registers to control the core and transfer data over the JTAG connection. e core operates on 8-bit units
of data at a time; eight bits of the data register serve as a one-character payload.
e JTAG UART core provides an active-high interrupt output that can request an interrupt when read
data is available, or when the write FIFO is ready for data. For further details see the Interrupt Behavior
section.
Read and Write FIFOs
e JTAG UART core provides bidirectional FIFOs to improve bandwidth over the JTAG connection. e
FIFO depth is parameterizable to accommodate the available on-chip memory. e FIFOs can be
constructed out of memory blocks or registers, allowing you to trade o logic resources for memory
resources, if necessary.
JTAG Interface
Altera FPGAs contain built-in JTAG control circuitry between the device's JTAG pins and the logic inside
the device. e JTAG controller can connect to user-dened 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 tting, the Quartus Prime soware automatically
generates the JTAG hub logic. No manual design eort 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.
6-2 Avalon Slave Interface and Registers UG-01085
2016.12.19
Altera Corporation JTAG UART Core
Send Feedback
Figure 6-2: Example System Using the JTAG UART Core
PC
Interface
Host PC
JTAG
Server
Download
Cable Altera
Downlo
Debugger
Debugger
C
Debug Data
PC
Interface JTAG
Host PC
Altera FPGA
JTAG
Controller
JTAG
Hub
JTAG
Server
Download
Cable
Driver
Altera
Download
Cable
JTAG
Debug
Module
JTAG
UART
System Interconnect Fabric
Character Stream
Debugger
Debugger
C
JTAG Terminal
JTAG Terminal
Nios II
Processor
On-Chip
Memory
M
SS
M
S
Avalon-MM master port
Avalon-MM slave port
e 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 soware on the host PC controls and decodes the JTAG data stream, and
maintains distinct connections with nodes inside the FPGA.
e example system in the gure above contains one JTAG UART core and a Nios II processor. Both
agents communicate with the host PC over a single Altera download cable. anks to the JTAG server
soware, each host application has an independent connection to the target. Altera provides the JTAG
server drivers and host soware 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.
Conguration
e following sections describe the available conguration options.
Conguration Page
e options on this page control the hardware conguration of the JTAG UART core. e default settings
are pre-congured to behave optimally with the Altera-provided device drivers and JTAG terminal
soware. Most designers should not change the default values, except for the Construct using registers
instead of memory blocks option.
UG-01085
2016.12.19 Conguration 6-3
JTAG UART Core Altera Corporation
Send Feedback
Write FIFO Settings
e write FIFO buers data owing from the Avalon interface to the host. e following settings are
available:
•Depth—e write FIFO depth can be set from 8 to 32,768 bytes. Only powers of two are allowed.
Larger values consume more on-chip memory resources. A depth of 64 is generally optimal for
performance, and larger values are rarely necessary.
•IRQ reshold—e write IRQ threshold governs how the core asserts its IRQ in response to the FIFO
emptying. As the JTAG circuitry empties data from the write FIFO, the core asserts its IRQ when the
number of characters remaining in the FIFO reaches this threshold value. For maximum bandwidth, a
processor should service the interrupt by writing more data and preventing the write FIFO from
emptying completely. A value of 8 is typically optimal. See the Interrupt Behavior section for further
details.
•Construct using registers instead of memory blocks—Turning on this option causes the FIFO to be
constructed out of on-chip logic resources. is option is useful when memory resources are limited.
Each byte consumes roughly 11 logic elements (LEs), so a FIFO depth of 8 (bytes) consumes roughly 88
LEs.
Read FIFO Settings
e read FIFO buers data owing from the host to the Avalon interface. Settings are available to control
the depth of the FIFO and the generation of interrupts.
•Depth—e read FIFO depth can be set from 8 to 32,768 bytes. Only powers of two are allowed.
Larger values consume more on-chip memory resources. A depth of 64 is generally optimal for
performance, and larger values are rarely necessary.
•IRQ reshold—e IRQ threshold governs how the core asserts its IRQ in response to the FIFO
lling up. As the JTAG circuitry lls up the read FIFO, the core asserts its IRQ when the amount of
space remaining in the FIFO reaches this threshold value. For maximum bandwidth, a processor
should service the interrupt by reading data and preventing the read FIFO from lling up completely. A
value of 8 is typically optimal. See the Interrupt Behavior section for further details.
•Construct using registers instead of memory blocks—Turning on this option causes the FIFO to be
constructed out of logic resources. is option is useful when memory resources are limited. Each byte
consumes roughly 11 LEs, so a FIFO depth of 8 (bytes) consumes roughly 88 LEs.
Simulation Settings
At system generation time, when Qsys generates the logic for the JTAG UART core, a simulation model is
also constructed. e simulation model oers features to simplify simulation of systems using the JTAG
UART core. Changes to the simulation settings do not aect the behavior of the core in hardware; the
settings aect only functional simulation.
Simulated Input Character Stream
You can enter a character stream that will be simulated entering the read FIFO upon simulated system
reset. e MegaWizard Interface accepts an arbitrary character string, which is later incorporated into the
test bench. Aer reset, this character string is pre-initialized in the read FIFO, giving the appearance that
an external JTAG terminal program is sending a character stream to the JTAG UART core.
Prepare Interactive Windows
At system generation time, the JTAG UART core generator can create ModelSim® macros to open interac‐
tive windows during simulation. ese windows allow the user to send and receive ASCII characters via a
6-4 Write FIFO Settings UG-01085
2016.12.19
Altera Corporation JTAG UART Core
Send Feedback
console, giving the appearance of a terminal session with the system executing in hardware. e following
options are available:
•Do not generate ModelSim aliases for interactive windows—is option does not create any
ModelSim macros for character I/O.
•Create ModelSim alias to open a window showing output as ASCII text—is 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 window—is 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.
Hardware Simulation Considerations
e simulation features were created for easy simulation of Nios II processor systems when using the
ModelSim simulator. e simulation model is implemented in the JTAG UART core's top-level HDL le.
e synthesizable HDL and the simulation HDL are implemented in the same le. Some simulation
features are implemented using translate on/off synthesis directives that make certain sections of HDL
code visible only to the synthesis tool.
For complete details about simulating the JTAG UART core in Nios II systems, refer to AN 351:
Simulating Nios II Processor Designs.
Other simulators can be used, but require user eort to create a custom simulation process. You can use
the auto-generated ModelSim scripts as references to create similar functionality for other simulators.
Note: Do not edit the simulation directives if you are using Altera’s recommended simulation procedures.
If you change the simulation directives to create a custom simulation ow, be aware that Qsys
overwrites existing les during system generation. Take precautions to ensure your changes are not
overwritten.
Software Programming Model
e following sections describe the soware programming model for the JTAG UART core, including the
register map and soware declarations to access the hardware. For Nios II processor users, Altera provides
HAL system library drivers that enable you to access the JTAG UART using the ANSI C standard library
functions, such as printf() and getchar().
HAL System Library Support
e Altera-provided driver implements a HAL character-mode device driver that integrates into the HAL
system library for Nios II systems. HAL users should access the JTAG UART via the familiar HAL API and
the ANSI C standard library, rather than accessing the JTAG UART registers. ioctl() requests are dened
that allow HAL users to control the hardware-dependent aspects of the JTAG UART.
Note: If your program uses the Altera-provided HAL device driver to access the JTAG UART hardware,
accessing the device registers directly will interfere with the correct behavior of the driver.
For Nios II processor users, the HAL system library API provides complete access to the JTAG UART
core's features. Nios II programs treat the JTAG UART core as a character mode device, and send and
receive data using the ANSI C standard library functions, such as getchar() and printf().
UG-01085
2016.12.19 Hardware Simulation Considerations 6-5
JTAG UART Core Altera Corporation
Send Feedback
e "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 congured to use this JTAG UART device for stdout.
Table 6-1: Example: Printing Characters to a JTAG UART Core as stdout
#include <stdio.h>
int main ()
{
printf("Hello world.\n");
return 0;
}
e 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 congured as the stdout device. In
this case, the program treats the device like any other node in the HAL le system.
6-6 HAL System Library Support UG-01085
2016.12.19
Altera Corporation JTAG UART Core
Send Feedback
Table 6-2: Example: Transmitting Characters to a JTAG UART Core
/* A simple program that recognizes the characters 't' and 'v' */
#include <stdio.h>
#include <string.h>
int main ()
{
char* msg = "Detected the character 't'.\n";
FILE* fp;
char prompt = 0;
fp = fopen ("/dev/jtag_uart", "r+"); //Open le for reading and writing
if (fp)
{
while (prompt != 'v')
{ // Loop until we receive a 'v'.
prompt = getc(fp); // Get a character from the JTAG UART.
if (prompt == 't')
{ // Print a message if character is 't'.
fwrite (msg, strlen (msg), 1, fp);
}
if (ferror(fp)) // Check if an error occurred with the le
pointer clearerr(fp); // If so, clear it.
}
fprintf(fp, "Closing the JTAG UART le handle.\n");
fclose (fp);
}
return 0;
}
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 Soware Developer's
Handbook.
e Nios II Embedded Design Suite (EDS) provides a number of soware example designs that use the
JTAG UART core.
UG-01085
2016.12.19 HAL System Library Support 6-7
JTAG UART Core Altera Corporation
Send Feedback
Driver Options: Fast vs. Small Implementations
To accommodate the requirements of dierent types of systems, the JTAG UART driver has two variants, a
fast version and a small version. e fast behavior is used by default. Both the fast and small drivers fully
support the C standard library functions and the HAL API.
e fast driver is an interrupt-driven implementation, which allows the processor to perform other tasks
when the device is not ready to send or receive data. Because the JTAG UART data rate is slow compared
to the processor, the fast driver can provide a large performance benet for systems that could be
performing other tasks in the interim. In addition, the fast version of the Altera Avalon JTAG UART
monitors the connection to the host. e driver discards characters if no host is connected, or if the host is
not running an application that handles the I/O stream.
e small driver is a polled implementation that waits for the JTAG UART hardware before sending and
receiving each character. e performance of the small driver is poor if you are sending large amounts of
data. e small version assumes that the host is always connected, and will never discard characters.
erefore, the small driver will hang the system if the JTAG UART hardware is ever disconnected from the
host while the program is sending or receiving data. ere are two ways to enable the small footprint
driver:
• Enable the small footprint setting for the HAL system library project. is option aects device drivers
for all devices in the system.
• Specify the preprocessor option -DALTERA_AVALON_JTAG_UART_SMALL. Use this option if you want the
small, polled implementation of the JTAG UART driver, but you do not want to aect the drivers for
other devices.
ioctl() Operations
e fast version of the JTAG UART driver supports the ioctl() function to allow HAL-based programs to
request device-specic operations. Specically, you can use the ioctl() operations to control the timeout
period, and to detect whether or not a host is connected. e fast driver denes 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) aer 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.
e ioctl arg parameter passed in must be a pointer to an integer.
TIOCGCON-
NECTED
Sets the integer arg parameter to a value that indicates whether the host is connected
and acting as a terminal (1), or not connected (0). e ioctl arg parameter passed in
must be a pointer to an integer.
For details about the ioctl() function, refer to the Nios II Classic Soware Developer's Handbook.
Software Files
e JTAG UART core is accompanied by the following soware les. ese les dene the low-level
interface to the hardware, and provide the HAL drivers. Application developers should not modify these
les.
6-8 Driver Options: Fast vs. Small Implementations UG-01085
2016.12.19
Altera Corporation JTAG UART Core
Send Feedback
•altera_avalon_jtag_uart_regs.h—is le denes the core's register map, providing symbolic
constants to access the low-level hardware. e symbols in this le are used only by device driver
functions.
•altera_avalon_jtag_uart.h, altera_avalon_jtag_uart.c—ese les implement the HAL
system library device driver.
Accessing the JTAG UART Core via a Host PC
Host soware is necessary for a PC to access the JTAG UART core. e Nios II IDE supports the JTAG
UART core, and displays character I/O in a console window. Altera also provides a command-line utility
called nios2-terminal that opens a terminal session with the JTAG UART core.
For further details, refer to the Nios II Soware Developer's Handbook and Nios II IDE online help.
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: e 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 conict and fail to
operate.
e 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.
Table 6-4: JTAG UART Core Register Map
Ose
t
Regis
ter
Nam
e
R/
W
Bit Description
31 .. 16 15 14 .. 11 10 9 8 7 .. 2 1 0
0data R
W
RAVAIL RVA
LID
Reserved DATA
1cont
rol
R
W
WSPACE Reserved AC WI RI Reserved WE RE
Note: Reserved elds—Read values are undened. Write zero.
Data Register
Embedded soware accesses the read and write FIFOs via the data register. e table below describes the
function of each bit.
Table 6-5: data Register Bits
Bit(s) Name Access Description
[7:0] DATA R/W e value to transfer to/from the JTAG core. When writing, the
DATA eld holds a character to be written to the write FIFO.
When reading, the DATA eld holds a character read from the
read FIFO.
UG-01085
2016.12.19 Accessing the JTAG UART Core via a Host PC 6-9
JTAG UART Core Altera Corporation
Send Feedback
Bit(s) Name Access Description
[15] RVALID R Indicates whether the DATA eld is valid. If RVALID=1, the DATA
eld is valid, otherwise DATA is undened.
[32:16] RAVAIL Re number of characters remaining in the read FIFO (aer the
current read).
A read from the data register returns the rst character from the FIFO (if one is available) in the DATA
eld. Reading also returns information about the number of characters remaining in the FIFO in the
RAVAIL eld. A write to the data register stores the value of the DATA eld in the write FIFO. If the write
FIFO is full, the character is lost.
Control Register
Embedded soware controls the JTAG UART core's interrupt generation and reads status information via
the control register. e Control Register Bits table below describes the function of each bit.
Table 6-6: Control Register Bits
Bit(s) Name Access Description
0RE R/W Interrupt-enable bit for read interrupts.
1WE R/W Interrupt-enable bit for write interrupts.
8RI R Indicates that the read interrupt is pending.
9WI R Indicates that the write interrupt is pending.
10 AC R/C Indicates that there has been JTAG activity since the bit was
cleared. Writing 1 to AC clears it to 0.
[32:16] WSPACE Re number of spaces available in the write FIFO.
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.
e RE and WE bits enable interrupts for the read and write FIFOs, respectively. e WI and RI bits indicate
the status of the interrupt sources, qualied by the values of the interrupt enable bits (WE and RE).
Embedded soware can examine RI and WI to determine the condition that generated the IRQ. See the
Interrupt Behavior section for further details.
e 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 soware can examine the AC bit to determine if a connection exists to a host PC. If
no connection exists, the soware 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 soware using the JTAG download cable could cause delays of up to 10 seconds
between polls.
Interrupt Behavior
e JTAG UART core generates an interrupt when either of the individual interrupt conditions is pending
and enabled.
6-10 Control Register UG-01085
2016.12.19
Altera Corporation JTAG UART Core
Send Feedback
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-congured with optimal interrupt behavior.
e JTAG UART core has two kinds of interrupts: write interrupts and read interrupts. e WE and RE
bits in the control register enable/disable the interrupts.
e core can assert a write interrupt whenever the write FIFO is nearly empty. e nearly empty threshold,
write_threshold, is specied at system generation time and cannot be changed by embedded soware.
e write interrupt condition is set whenever there are write_threshold or fewer characters in the write
FIFO. It is cleared by writing characters to ll the write FIFO beyond the write_threshold. Embedded
soware should only enable write interrupts aer lling the write FIFO. If it has no characters remaining
to send, embedded soware should disable the write interrupt.
e core can assert a read interrupt whenever the read FIFO is nearly full. e nearly full threshold value,
read_threshold, is specied at system generation time and cannot be changed by embedded soware.
e read interrupt condition is set whenever the read FIFO has read_threshold or fewer spaces
remaining. e read interrupt condition is also set if there is at least one character in the read FIFO and no
more characters are expected. e 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 soware. 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 suers. If it is too short, interrupts occurs too oen.
For Nios II processor systems, read and write thresholds of 8 are an appropriate default.
Document Revision History
Table 6-7: JTAG UART Core 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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
For previous versions of this chapter, refer to the Quartus Handbook Archive.
UG-01085
2016.12.19 Document Revision History 6-11
JTAG UART Core Altera Corporation
Send Feedback
UART Core 7
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e core implements the RS-232
protocol timing, and provides adjustable baud rate, parity, stop, and data bits. e feature set is congu‐
rable, allowing designers to implement just the necessary functionality for a given system.
e 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.
Functional Description
Figure 7-1: Block Diagram of the UART Core in a Typical System
Altera FPGA
UART Core
baud rate divisor
shift register
RXD
RTS
CTS
TXD
Level
Shifter
RS - 232
Connector
Avalon-MM
signals
connected
to on-chip
logic
data
IRQ
dataavailable
readyfordata
endofpacket
address
clock
rxdata
status
control
txdata
endofpacket
shift register
divisor
e core has two user-visible parts:
•e register le, which is accessed via the Avalon-MM slave port
•e RS-232 signals, RXD, TXD, CTS, and RTS
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Avalon-MM Slave Interface and Registers
e UART core provides an Avalon-MM slave interface to the internal register le. e user interface to
the UART core consists of six, 16-bit registers: control, status, rxdata, txdata, divisor, and
endofpacket. A master peripheral, such as a Nios II processor, accesses the registers to control the core
and transfer data over the serial connection.
e UART core provides an active-high interrupt request (IRQ) output that can request an interrupt when
new data has been received, or when the core is ready to transmit another character. For further details,
refer to the Interrupt Behavior section.
For more information, refer to Interval Timer Core section.
For details about the Avalon-MM interface, refer to the Avalon Interface Specications.
RS-232 Interface
e UART core implements RS-232 asynchronous transmit and receive logic. e UART core sends and
receives serial data via the TXD and RXD ports. e I/O buers 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 specications, an external level-shiing buer is
required (for example, Maxim MAX3237) between the FPGA I/O pins and the external RS-232 connector.
e 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.
Transmitter Logic
e UART transmitter consists of a 7-, 8-, or 9-bit txdata holding register and a corresponding 7-, 8-, or
9-bit transmit shi register. Avalon-MM master peripherals write the txdata holding register via the
Avalon-MM slave port. e transmit shi register is loaded from the txdata register automatically when a
serial transmit shi operation is not currently in progress. e transmit shi register directly feeds the TXD
output. Data is shied out to TXD LSB rst.
ese two registers provide double buering. A master peripheral can write a new value into the txdata
register while the previously written character is being shied out. e master peripheral can monitor the
transmitter's status by reading the status register's transmitter ready (TRDY), transmitter shi register
empty (tmt), and transmitter overrun error (TOE) bits.
e 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 specication.
Receiver Logic
e UART receiver consists of a 7-, 8-, or 9-bit receiver-shi 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. e rxdata holding register is loaded from the receiver shi register automatically every
time a new character is fully received.
ese two registers provide double buering. e rxdata register can hold a previously received character
while the subsequent character is being shied into the receiver shi 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. e
receiver logic automatically detects the correct number of start, stop, and parity bits in the serial RXD
stream as required by the RS-232 specication. e receiver logic checks for four exceptional conditions,
7-2 Avalon-MM Slave Interface and Registers UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
frame error, parity error, receive overrun error, and break, in the received data and sets corresponding
status register bits.
Baud Rate Generation
e UART core's internal baud clock is derived from the Avalon-MM clock input. e internal baud clock
is generated by a clock divider. e divisor value can come from one of the following sources:
• A constant value specied at system generation time
•e 16-bit value stored in the divisor register
e divisor register is an optional hardware feature. If it is disabled at system generation time, the divisor
value is xed and the baud rate cannot be altered.
Instantiating the Core
Instantiating the UART in hardware creates at least two I/O ports for each UART core: An RXD input, and
a TXD output. e following sections describe the available options.
Conguration Settings
is section describes the conguration settings.
Baud Rate Options
e UART core can implement any of the standard baud rates for RS-232 connections. e baud rate can
be congured in one of two ways:
•Fixed rate—e baud rate is xed at system generation time and cannot be changed via the Avalon-
MM slave port.
•Variable rate—e baud rate can vary, based on a clock divisor value held in the divisor register. A
master peripheral changes the baud rate by writing new values to the divisor register.
e baud rate is calculated based on the clock frequency provided by the Avalon-MM interface.
Changing the system clock frequency in hardware without regenerating the UART core hardware
results in incorrect signaling.
e baud rate is calculated based on the clock frequency provided by the Avalon-MM interface. Changing
the system clock frequency in hardware without regenerating the UART core hardware results in incorrect
signaling.
Baud Rate (bps) Setting
e Baud Rate setting determines the default baud rate aer reset. e Baud Rate option oers standard
preset values.
e baud rate value is used to calculate an appropriate clock divisor value to implement the desired baud
rate. Baud rate and divisor values are related as shown in the follow two equations:
Divisor Formula:
divisor int clock frequency
baud rate
----------------------------------------- 0.5 +
(
=)
UG-01085
2016.12.19 Baud Rate Generation 7-3
UART Core Altera Corporation
Send Feedback
Baud rate Formula:
baud rate clock frequency
divisor 1+
-----------------------------------------=
Baud Rate Can Be Changed By Software Setting
When this setting is on, the hardware includes a 16-bit divisor register at address oset 4. e divisor
register is writable, so the baud rate can be changed by writing a new value to this register.
When this setting is o, the UART hardware does not include a divisor register. e UART hardware
implements a constant baud divisor, and the value cannot be changed aer system generation. In this case,
writing to address oset 4 has no eect, and reading from address oset 4 produces an undened result.
Data Bits, Stop Bits, Parity
e UART core's parity, data bits and stop bits are congurable. ese settings are xed at system
generation time; they cannot be altered via the register le.
Table 7-1: Data Bits Settings
Setting Legal Values Description
Data Bits 7, 8, 9 is setting determines the widths of the
txdata, rxdata, and endofpacket
registers.
Stop Bits 1, 2 is setting determines whether the core
transmits 1 or 2 stop bits with every
character. e core always terminates a
receive transaction at the rst stop bit, and
ignores all subsequent stop bits, regardless
of this setting.
7-4 Baud Rate Can Be Changed By Software Setting UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
Setting Legal Values Description
Parity None, Even, Odd is setting determines whether the UART
core transmits characters with parity
checking, and whether it expects received
characters to have parity checking.
When Parity is set to None, the transmit
logic sends data without including a parity
bit, and the receive logic presumes the
incoming data does not include a parity bit.
e PE bit in the status register is not
implemented; it always reads 0.
When Parity is set to Odd or Even, the
transmit logic computes and inserts the
required parity bit into the outgoing TXD
bitstream, and the receive logic checks the
parity bit in the incoming RXD bitstream. If
the receiver nds data with incorrect parity,
the PE bit in the status register is set to 1.
When Parity is Even, the parity bit is 0 if
the character has an even number of 1 bits;
otherwise the parity bit is 1. Similarly, when
parity is Odd, the parity bit is 0 if the
character has an odd number of 1 bits.
Synchronizer Stages
e option Synchronizer Stages allows you to specify the length of synchronization register chains. ese
register chains are used when a metastable event is likely to occur and the length specied determines the
meantime before failure. e register chain length, however, aects 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.
Streaming Data (DMA) Control
e UART core can also optionally include the end-of-packet register.
Include End-of-Packet Register
When this setting is on, the UART core includes:
• A 7-, 8-, or 9-bit endofpacket register at address-oset 5. e data width is determined by the Data
Bits setting.
• EOP bit in the status register.
• IEOP bit in the control register.
•endofpacket signal.
EOP detection can be used with a DMA controller, for example, to implement a UART that automatically
writes received characters to memory until a specied character is encountered in the incoming RXD
stream. e terminating (EOP) character's value is determined by the endofpacket register.
UG-01085
2016.12.19 Synchronizer Stages 7-5
UART Core Altera Corporation
Send Feedback
When the EOP register is disabled, the UART core does not include the EOP resources. Writing to the
endofpacket register has no eect, and reading produces an undened value.
Simulation Settings
When the UART core's logic is generated, a simulation model is also created. e simulation model oers
features to simplify and accelerate simulation of systems that use the UART core. Changes to the
simulation settings do not aect the behavior of the UART core in hardware; the settings aect 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.
Simulated RXD-Input Character Stream
You can enter a character stream that is simulated entering the RXD port upon simulated system reset. e
UART core's MegaWizard™ interface accepts an arbitrary character string, which is later incorporated into
the UART simulation model. Aer reset in reset, the string is input into the RXD port character-by-
character as the core is able to accept new data.
Prepare Interactive Windows
At system generation time, the UART core generator can create ModelSim macros that facilitate interac‐
tion with the UART model during simulation. You can turn on the following options:
•Create ModelSim alias to open streaming output window to create a ModelSim macro that opens a
window to display all output from the TXD port.
•Create ModelSim alias to open interactive stimulus window to create a ModelSim macro that opens
a window to accept stimulus for the RXD port. e window sends any characters typed in the window to
the RXD port.
Simulated Transmitter Baud Rate
RS-232 transmission rates are oen slower than any other process in the system, and it is seldom useful to
simulate the functional model at the true baud rate. For example, at 115,200 bps, it typically takes
thousands of clock cycles to transfer a single character. e UART simulation model has the ability to run
with a constant clock divisor of 2, allowing the simulated UART to transfer bits at half the system clock
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
e simulation features were created for easy simulation of Nios II processor systems when using the
ModelSim simulator. e documentation for the processor documents the suggested usage of these
features. Other usages may be possible, but will require additional user eort to create a custom simulation
process.
e simulation model is implemented in the UART core's top-level HDL le; the synthesizable HDL and
the simulation HDL are implemented in the same le. e simulation features are implemented using
7-6 Simulation Settings UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
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 ow, be aware that Qsys overwrites
existing les 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.
Software Programming Model
e following sections describe the soware programming model for the UART core, including the
register map and soware declarations to access the hardware. For Nios II processor users, Altera provides
hardware abstraction layer (HAL) system library drivers that enable you to access the UART core using the
ANSI C standard library functions, such as printf() and getchar().
HAL System Library Support
e Altera-provided driver implements a HAL character-mode device driver that integrates into the HAL
system library for Nios II systems. HAL users should access the UART via the familiar HAL API and the
ANSI C standard library, rather than accessing the UART registers. ioctl() requests are dened that
allow HAL users to control the hardware-dependent aspects of the UART.
Note: If your program uses the HAL device driver to access the UART hardware, accessing the device
registers directly interferes with the correct behavior of the driver.
For Nios II processor users, the HAL system library API provides complete access to the UART core's
features. Nios II programs treat the UART core as a character mode device, and send and receive data
using the ANSI C standard library functions.
e driver supports the CTS/RTS control signals when they are enabled in Qsys. Refer to Driver Options:
Fast Versus Small Implementations section.
e following code demonstrates the simplest possible usage, printing a message to stdout using
printf(). In this example, the system contains a UART core, and the HAL system library has been
congured to use this device for stdout.
Example 7-1: Example: Printing Characters to a UART Core as stdout
#include <stdio.h>
int main ()
{
printf("Hello world.\n");
return 0;
}
e 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 congured as the stdout device. In this case, the program treats the device like any other node in the
HAL le system.
For more information about the HAL system library, refer to the Nios II Classic Soware Developer's
Handbook.
UG-01085
2016.12.19 Software Programming Model 7-7
UART Core Altera Corporation
Send Feedback
Example 7-2: Example: Sending and Receiving Characters
/* A simple program that recognizes the characters 't' and 'v' */
#include <stdio.h>
#include <string.h>
int main ()
{
char* msg = "Detected the character 't'.\n";
FILE* fp;
char prompt = 0;
fp = fopen ("/dev/uart1", "r+"); //Open file for reading and writing
if (fp)
{
while (prompt != 'v')
{ // Loop until we receive a 'v'.
prompt = getc(fp); // Get a character from the UART.
if (prompt == 't')
{ // Print a message if character is 't'.
fwrite (msg, strlen (msg), 1, fp);
}
}
fprintf(fp, "Closing the UART file.\n");
fclose (fp);
}
return 0;
}
Driver Options: Fast vs Small Implementations
To accommodate the requirements of dierent types of systems, the UART driver provides two variants: a
fast version and a small version. e fast version is the default. Both fast and small drivers fully support
the C standard library functions and the HAL API.
e fast driver is an interrupt-driven implementation, which allows the processor to perform other tasks
when the device is not ready to send or receive data. Because the UART data rate is slow compared to the
processor, the fast driver can provide a large performance benet for systems that could be performing
other tasks in the interim.
e small driver is a polled implementation that waits for the UART hardware before sending and
receiving each character. ere are two ways to enable the small footprint driver:
• Enable the small footprint setting for the HAL system library project. is option aects 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 aect 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
e UART driver supports the ioctl() function to allow HAL-based programs to request device-specic
operations. e table below denes operation requests that the UART driver supports.
7-8 Driver Options: Fast vs Small Implementations UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
Table 7-2: UART ioctl() Operations
Request Description
TIOCEXCL Locks the device for exclusive access. Further calls to open() for this device will fail until
either this le descriptor is closed, or the lock is released using the TIOCNXCL ioctl
request. For this request to succeed there can be no other existing le descriptors for this
device. e parameter arg is ignored.
TIOCNXCL Releases a previous exclusive access lock. e parameter arg is ignored.
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 conguration of the device by lling 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 conguration 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: e termios structure is dened by the Newlib C standard library. You can nd the denition in the
le <Nios II EDS install path>/components/altera_hal/HAL/inc/sys/termios.h.
For details about the ioctl() function, refer to the Nios II Classic Soware Developer's Handbook.
Limitations
e HAL driver for the UART core does not support the endofpacket register. Refer to the Register map
section for details.
Software Files
e UART core is accompanied by the following soware les. ese les dene the low-level interface to
the hardware, and provide the HAL drivers. Application developers should not modify these les.
•altera_avalon_uart_regs.h—is le denes the core's register map, providing symbolic
constants to access the low-level hardware. e symbols in this le are used only by device driver
functions.
•altera_avalon_uart.h, altera_avalon_uart.c—ese les 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.
e 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 conict and fail to operate.
UG-01085
2016.12.19 Limitations 7-9
UART Core Altera Corporation
Send Feedback
e 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.
Table 7-4: UART Core Register Map
Oset Register
Name R/W
Description/Register Bits
15:13 12 11 10 9 8 7 6 5 4 3 2 1 0
0rxdata RO Reserved (2) (2) Receive Data
1txdata WO Reserved (2) (2) Transmit Data
2status (1) RW Reserved eop cts dcts e rrdy trdy tmt toe roe brk fe pe
3control RW Reserved ieop rts idct
s
trbk ie irrd
y
itrd
y
itmt itoe iroe ibrk ife ipe
4divisor (3) RW Baud Rate Divisor
5endof-
packet (3) RW Reserved (2) (2) End-of-Packet Value
Some registers and bits are optional. ese 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
e 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. e
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 eect.
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. e TRDY bit is set to 0 when a character is written into the txdata register. e
TRDY bit is set to 1 when the character is transferred from the txdata register into the transmitter shi
register. If a character is written to the txdata register when TRDY is 0, the result is undened. Reading the
txdata register returns an undened value.
For example, assume the transmitter logic is idle and an Avalon-MM master peripheral writes a rst
character into the txdata register. e TRDY bit is set to 0, then set to 1 when the character is transferred
into the transmitter shi register. e master can then write a second character into the txdata register,
(1) Writing zero to the status register clears the dcts, e, toe, roe, brk, fe, and pe bits.
(2) ese 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 eect.
(3) is register may or may not exist, depending on hardware conguration options. If it does not exist, reading
returns an undened value and writing has no eect.
7-10 rxdata Register UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
and the TRDY bit is set to 0 again. However, this time the shi register is still busy shiing out the rst
character to the TXD output. e TRDY bit is not set to 1 until the rst character is fully shied out and the
second character is automatically transferred into the transmitter shi register.
status Register
e 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. e 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.
Table 7-5: status Register Bits
Bit Name Access Description
0 (4) PE RC Parity error. A parity error occurs when the received parity bit has an
unexpected (incorrect) logic level. e PE bit is set to 1 when the core
receives a character with an incorrect parity bit. e PE bit stays set to 1
until it is explicitly cleared by a write to the status register. When the PE
bit is set, reading from the rxdata register produces an undened value.
If the Parity hardware option is not enabled, no parity checking is
performed and the PE bit always reads 0. Refer to Data Bits, Stop, Bits,
Parity section.
1FE RC Framing error. A framing error occurs when the receiver fails to detect a
correct stop bit. e FE bit is set to 1 when the core receives a character
with an incorrect stop bit. e 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 undened value.
2BRK RC Break detect. e receiver logic detects a break when the RXD pin is held
low (logic 0) continuously for longer than a full-character time (data
bits, plus start, stop, and parity bits). When a break is detected, the BRK
bit is set to 1. e BRK bit stays set to 1 until it is explicitly cleared by a
write to the status register.
3ROE RC Receive overrun error. A receive-overrun error occurs when a newly
received character is transferred into the rxdata holding register before
the previous character is read (in other words, while the RRDY bit is 1). In
this case, the ROE bit is set to 1, and the previous contents of rxdata are
overwritten with the new character. e ROE bit stays set to 1 until it is
explicitly cleared by a write to the status register.
4TOE RC Transmit overrun error. A transmit-overrun error occurs when a new
character is written to the txdata holding register before the previous
character is transferred into the shi register (in other words, while the
TRDY bit is 0). In this case the TOE bit is set to 1. e TOE bit stays set to 1
until it is explicitly cleared by a write to the status register.
UG-01085
2016.12.19 status Register 7-11
UART Core Altera Corporation
Send Feedback
Bit Name Access Description
5TMT R Transmit empty. e TMT bit indicates the transmitter shi register’s
current state. When the shi register is in the process of shiing a
character out the TXD pin, TMT is set to 0. When the shi register is idle
(in other words, a character is not being transmitted) the TMT bit is 1. An
Avalon-MM master peripheral can determine if a transmission is
completed (and received at the other end of a serial link) by checking the
TMT bit.
6TRDY R Transmit ready. e TRDY bit indicates the txdata holding register’s
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.
7RRDY R Receive character ready. e RRDY bit indicates the rxdata holding
register’s 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.
8ERC Exception. e E bit indicates that an exception condition occurred. e
E bit is a logical-OR of the TOE, ROE, BRK, FE, and PE bits. e 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.
e 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. e 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). is bit is set by both falling
and rising transitions on CTS_N. e DCTS bit stays set to 1 until it is
explicitly cleared by a write to the status register.
11 (4) CTS R Clear-to-send (CTS) signal. e CTS bit reects the CTS_N input’s
instantaneous state (sampled synchronously to the Avalon-MM clock).
e CTS_N input has no eect on the transmit or receive processes. e
only visible eect of the CTS_N input is the state of the CTS and DCTS bits,
and an IRQ that can be generated when the control register’s idcts bit is
enabled.
7-12 status Register UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
Bit Name Access Description
12 (4) EOP R(4) End of packet encountered. e 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
e EOP character is determined by the contents of the endofpacket
register. e 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
e control register consists of individual bits, each controlling an aspect of the UART core's operation.
e 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.
Table 7-6: control Register Bits
Bit Name Access Description
0IPE RW Enable interrupt for a parity error.
1IFE RW Enable interrupt for a framing error.
2IBRK RW Enable interrupt for a break detect.
3IROE RW Enable interrupt for a receiver overrun error.
4ITOE RW Enable interrupt for a transmitter overrun error.
5ITMT RW Enable interrupt for a transmitter shi register empty.
6ITRDY RW Enable interrupt for a transmission ready.
7IRRDY RW Enable interrupt for a read ready.
8IE RW Enable interrupt for an exception.
9TRBK RW Transmit break. e TRBK bit allows an Avalon-MM master peripheral to
transmit a break character over the TXD output. e TXD signal is forced
to 0 when the TRBK bit is set to 1. e TRBK bit overrides any logic level
that the transmitter logic would otherwise drive on the TXD output. e
TRBK bit interferes with any transmission in process. e Avalon-MM
master peripheral must set the TRBK bit back to 0 aer an appropriate
break period elapses.
(4) is bit is optional and may not exist in hardware.
UG-01085
2016.12.19 control Register 7-13
UART Core Altera Corporation
Send Feedback
Bit Name Access Description
10 IDCTS RW Enable interrupt for a change in CTS signal.
11(5) RTS RW Request to send (RTS) signal. e RTS bit directly feeds the RTS_N output.
An Avalon-MM master peripheral can write the RTS bit at any time. e
value of the RTS bit only aects the RTS_N output; it has no eect on the
transmitter or receiver logic. Because the RTS_N output is logic negative,
when the RTS bit is 1, a low logic-level (0) is driven on the RTS_N output.
12 IEOP RW Enable interrupt for end-of-packet condition.
divisor Register (Optional)
e value in the divisor register is used to generate the baud rate clock. e eective baud rate is
determined by the formula:
Baud Rate = (Clock frequency) / (divisor + 1)
e divisor register is an optional hardware feature. If the Baud Rate Can Be Changed By Soware
hardware option is not enabled, the divisor register does not exist. In this case, writing divisor has no
eect, and reading divisor returns an undened value. For more information, refer to the Baud Rate
Options section.
endofpacket Register (Optional)
e value in the endofpacket register determines the end-of-packet character for variable-length DMA
transactions. Aer reset, the default value is zero, which is the ASCII null character (\0). For more
information, refer to status Register bits for the description for the EOP bit.
e endofpacket register is an optional hardware feature. If the Include end-of-packet register hardware
option is not enabled, the endofpacket register does not exist. In this case, writing endofpacket has no
eect, and reading returns an undened value.
Interrupt Behavior
e 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. e 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. e 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.
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.
(5) is bit is optional and may not exist in hardware.
7-14 divisor Register (Optional) UG-01085
2016.12.19
Altera Corporation UART Core
Send Feedback
Document Revision History
Table 7-7: UART Core Revision History
Date and Document
Version
Version Changes
June 2016 2016.06.17 Removed content regarding Avalon-MM ow control.
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 No change from previous release.
March 2009 v9.0.0 Added description of a new parameter, Synchronizer stages.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
UG-01085
2016.12.19 Document Revision History 7-15
UART Core Altera Corporation
Send Feedback
16550 UART Core 8
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Altera 16550 UART (Universal Asynchronous Receiver/Transmitter) so IP core with Avalon
interface is designed to be register space compatible with the de-facto standard 16550 found in the PC
industry. e core provides RS-232 Signaling interface, False start detection, Modem control signal and
registers, Receiver error detection and Break character generation/detection. e 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.
e 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
e 16550 So-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
Table 8-1: UART Features and Congurability
Features Run Time Congurable Generate Time Congurable
FIFO/FIFO-less mode Yes Yes
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Features Run Time Congurable Generate Time Congurable
FIFO Depth - Yes
5-9 bit character length Yes -
1, 1.5, 2 character stop bit Yes -
Parity enable Yes -
Even/Odd parity Yes -
Baud rate selection Yes -
Memory Block Type - Yes
Priority based interrupt with congu‐
rable enable
Yes -
Hardware Auto Flow Control (cts_n/
rts_n signals)
Yes Yes
DMA Extra (congurable support for
extra DMA sideband signal)
Yes Yes
Stick parity/Force parity Yes -
Note: When a feature is both Generate time and Run time congurable, the feature must be enabled
during Generate time before Run time conguration can be used. erefore, 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
e So UART will have the following signal interface, exposed using _hw.tcl through Qsys soware.
Table 8-2: Clock and Reset Signal Interface
Pin Name Direction Description
clk Input Avalon clock sink
Clockrate: 24 MHz (minimum)
8-2 Unsupported Features UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Pin Name Direction Description
rst_n Input Avalon reset sink
Asynchronous assert, Synchronous
deassert active low reset.
Interconnect fabric expected to
perform synchronization – UART
and interconnect is expected to be
placed in the same reset domain to
simplify system design
Table 8-3: Avalon-MM Slave
Pin Name Width Direction Description
addr 9 Input Avalon-MM Address bus
Highest addressable byte
address is 0x118 so a 9-bit
width is required
read Input Avalon-MM Read indication
readdata 32 Output Avalon-MM Read Data
Response from the slave
write Input Avalon-MM Write indication
writedata 32 Input Avalon-MM Write Data
Table 8-4: Interrupt Interface
Pin Name Direction Description
intr Output Interrupt signal
Table 8-5: Flow Control
Pin Name Direction Description
sin Input Serial Input from external link.
sout Output Serial Output to external link.
sout_oe Output Output enable for Serial Output to external link.
sout_oe signal will be high when the UART is
transmitting and low when the UART is IDLE.
Table 8-6: Modem Control and Status
Pin Name Direction Description
cts_n Input Clear to Send
UG-01085
2016.12.19 Interface 8-3
16550 UART Core Altera Corporation
Send Feedback
Pin Name Direction Description
rts_n Output Request to Send
dsr_n Input Data Set Ready
dcd_n Input Data Carrier Detect
ri_n Input Ring Indicator
dtr_n Output Data Terminal Ready
out1_n Output User Designated Output1
out2_n Output User Designated Output2
Table 8-7: DMA Sideband Signals
Pin Name Direction Description
dma_tx_ack_n Input TX DMA acknowledge
dma_rx_ack_n Input RX DMA acknowledge
dma_tx_req_n Output TX DMA request
dma_rx_req_n Output RX DMA request
dma_tx_single_n Output TX DMA single request
dma_rx_single_n Output RX DMA single request
General Architecture
Figure 8-1: Soft-UART High Level Architecture
TX Fifo TX Shifter
TX Flow Control RX Flow Control
RX Shifter
RX Fifo
Clock Generator DMA Controller
CSR
Interface
16550 UART Core
Clock and Reset
Avalon MM
Slave Interface
RS-232 Serial
Interface
RS-232 Modem
Interface
DMA_Handshaking_tx
DMA_Handshaking_rx
IRQ
e gure 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.
16550 UART General Programming Flow Chart
e 16550 UART general programming ow chart is the recommended ow for setting up the UART for
error free operation.
8-4 General Architecture UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Note: You are free to change this ow to t your own usage model but the changes might cause undened
results.
Figure 8-2: 16550 UART Conguration Flow
Setup Flow Register Targets
Write to FCR
Write to LCR
Write to IER
Write to LCR
Write to DLH &
DLL
Write to LCR
Change Baud
Rate?
Write to MCR
Tx Transaction:
Write to THR
Rx Transaction: Read
from RBR
FIFO Enable
Transmit Empty Trigger
Receive Trigger
Data Length
Stop Bits
Parity Enable
Odd/Even parity
Receive Data Interrupt
Transmit Data Interrupt
Receive Line Status
Modern Status
Transmit Holding Register
Set DLAB = 1
Set divisor value according
to baud rate desired
Set DLAB = 0
Auto Flow Control Enable
Request to send
For more information on the register descriptions used in the ow chart, refer to the "Address Map and
Register Descriptions" section.
Related Information
Address Map and Register Descriptions on page 8-22
UG-01085
2016.12.19 16550 UART General Programming Flow Chart 8-5
16550 UART Core Altera Corporation
Send Feedback
Conguration Parameters
e table below shows all the parameters that can be used to congure the UART. (_hw.tcl) is the
mechanism used to enforce and validate correct parameter settings.
Table 8-8: Conguration Parameters
Parameter Name Description Default
MEM_BLOCK_TYPE Set memory block type of
FIFO. Available memory
block depend on device
family used. FIFO_MODE
must be 1
AUTO
FIFO_MODE 1 = FIFO mode enabled
0 = FIFO mode disabled
1
FIFO_DEPTH Set depth of FIFO
Values limited to 32, 64
and 128
FIFO_MODE must be 1
128
FIFO_HWFC 1 = Enabled hardware ow
control
0 = Disabled hardware
ow control
Mutually exclusive with
FIFO_SWFC
FIFO_MODE must be 1
1
DMA_EXTRA 1 = Additional DMA
interface enabled
0 = Additional DMA
interface disabled
0
DMA Support
e 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. e 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. e DMA handshaking interfaces are connected to the HPS through the f2h DMA request
lines.
8-6 Conguration Parameters UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
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
FPGA Resource Usage
In order to optimize resource usage, in terms of register counts, the UART IP design specically targets
MLABs to be used as FIFO storage element. e following table lists the FPGA resources required for one
UART with 128 Byte Tx and Rx FIFO.
Table 8-9: UART Resource Usage
Resource Number
ALMS needed 362
Total LABs 54
Combinational ALUT usage for logic 436
Combinational ALUT usage for route-throughs 17
Dedicated logic registers 311
Design implementation registers 294
Routing optimization registers 17
Global Signals 2
M10k blocks 0
UG-01085
2016.12.19 FPGA Resource Usage 8-7
16550 UART Core Altera Corporation
Send Feedback
Resource Number
Total MLAB memory bits 2432
Timing and Fmax
Figure 8-4: Maximum Delays on UART
External Pin
UART IP Core
D Q
Avalon Master
D Q D Q
4 ns
2 ns
8 ns7 ns
COMBI COMBI COMBI
e diagram above shows worst case combinatorial delays throughout the UART IP Core. ese 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.
e UART has combinatorial logic on both the Input and Output side, with system level implications on
the Input side.
e 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.
e Output side combinatorial logic (with 2ns delay) goes through the RS-232 Serial Output. ere 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. is 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
e Avalon-MM Slave has the following conguration:
Table 8-10: Avalon-MM Slave Conguration
Feature Conguration
Bus Width 32-bit
8-8 Timing and Fmax UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Feature Conguration
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: e 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
addr1 addrF addrF addrF
data1 data2 data3 data4
addr
read
readdata
Polling Status Reading from
RX FIFO
0 1 2 3 4 5 6 7 8 9
Reads are expected to have 2 types of behavior:
• When status registers are being polled, Reads are expected to be done in singles
• When data needs to be read out from the Rx FIFO, Reads are expected as back-to-back cycles to the
same address (these back-to-back reads are likely generated as Fixed Bursts in AXI – but translated into
INCR with length of 1 by FPGA interconnect)
Write behavior
Figure 8-6: Writing to UART over Avalon-MM
addr1 addrF addrF addrF
data1 data2 data3 data4
addr
read
readdata
Configuration Writing to
TX FIFO
0 1 2 3 4 5 6 7 8 9
UG-01085
2016.12.19 Read behavior 8-9
16550 UART Core Altera Corporation
Send Feedback
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 lled.
Overrun/Underrun Conditions
Consistent with UART implementation in PC16550D, the so 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 buer 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 buer.
On transmit path, soware driver is expected to know the Tx FIFO depth and not overrun the UART.
Receive Overrun Behavior
When receive overrun does happen, the So-UART handles it dierently depending on FIFO mode. With
FIFO enabled, the newly receive data at the shi register is lost. With FIFO disabled, the newly received
data from the shi register is written onto the Receive Buer. e existing data in the Receive Buer is
overwritten. is is consistent with published PC16550D UART behavior.
Transmit Overrun Behavior
When the host CPU forcefully triggers a transmit Overrun, the So-UART handles it dierently
depending on FIFO mode. With FIFO enabled, the newly written data is lost. With FIFO disabled, the
newly written data will overwrite the existing data in the Transmit Holding Register.
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 soware driver is expected to read from the UART receive buer (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 Buer Register is triggered with data ready register being zero,
undened read data is returned.
Hardware Auto Flow-Control
Hardware based auto ow-control uses 2 signals (cts_n & rts_n) from the Modem Control/Status group.
With Hardware auto ow-control disabled, these signals will directly drive the Modem Status register
(cts_n) or be driven by the Modem Control register (rts_n).
With auto ow-control enabled, these signals perform ow-control duty with another UART at the other
end.
e cts_n input is, when active (low state), will allow the Tx FIFO to send data to the transmit buer.
When cts_n is inactive (high state), the Tx FIFO stops sending data to the transmit buer. cts_n is
expected to be connected to the rts_n output of the other UART.
8-10 Overrun/Underrun Conditions UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
e 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. e 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 aer cts_n is
sampled active low. For the same reason, the Rx FIFO will accommodate up to 1 additional character aer
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 overow/underow between UARTs.
Figure 8-7: Hardware Auto Flow-Control Between two UARTs
TX
FIFO
Transmit Buffer
Flow Control
RX
FIFO
Receive Buffer
Flow Control
RX
FIFO
Receive Buffer
Flow Control
TX
FIFO
Transmit Buffer
Flow Control
sout
cts_n
sin
rts_n
sin
rts_n
sout
cts_n
UART 1 UART 2
Clock and Baud Rate Selection
e So-UART supports only one clock. e same clock is used on the Avalon-MM interface and will be
used to generate the baud clock that drives the serial UART interface.
e baud rate on the serial UART interface is set using the following equation:
Baud Rate = Clock/(16 x Divisor)
e table below shows how several typical baud rates can be achieved by programming the divisor values
in Divisor Latch High and Divisor Latch Low register.
Table 8-11: UART Clock Frequency, Divider value and Baud Rate Relationship
18.432 MHz 24 MHz 50 MHz
Baud Rate Divisor for
16x clock
% Error
(baud)
Divisor for
16x clock
% Error
(baud)
Divisor for
16x clock
% Error (baud)
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%
Software Programming Model
UG-01085
2016.12.19 Clock and Baud Rate Selection 8-11
16550 UART Core Altera Corporation
Send Feedback
Overview
e following describes the programming model for the Altera compatible 16550 So-UART.
Supported Features
For the following features, the 16550 So-UART HAL driver can be congurable in run time or generate
time. For run-time conguration, users can use “altera_16550_uart_cong” API . Generate time is during
Qsys generation, that is to say once FIFO Depth is selected the depth for the FIFO can’t be change
anymore.
Table 8-12: Supported Features
Features Run Time Generate Time
FIFO/ FIFO-less mode Yes Yes
FIFO Depth - Yes
Programmable Tx/Rx FIFO
reshold
Yes -
5-9 bit character length Yes -
1, 1.5, 2 character stop bit Yes -
Parity enable Yes -
Even/Odd parity Yes -
Stick parity Yes -
Baud rate selection Yes -
Priority based interrupt with congu‐
rable enable
Yes -
Hardware Auto Flow Control Yes Yes
Unsupported Features
e 16550 UART driver does not support Soware ow control.
Conguration
e gure below shows the Qsys setup on the 16550 So-UART's FIFO Depth
8-12 Overview UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Figure 8-8: Qsys Setting to Congure FIFO Depth
16550 UART API
Public APIs
Table 8-13: altera_16550_uart_open
Prototype: altera_16550_uart_dev * altera_16550_uart_
open(const char* name);
Include: <altera_16550_uart.h>
Parameters: name—the 16550 UART device name to open.
Returns: Pointer to 16550 UART or NULL if fail to open
Description Open 16550 UART device.
Table 8-14: altera_16550_uart_close
Prototype: void alt_16550_uart_close (const char* name)
Include: <altera_16550_uart.h>
Parameters: name—the 16550 UART device name to close.
Returns: None
Description: Closes 16550 UART device.
Table 8-15: alt_16550_uart_read
Prototype: alt_u32 altera_16550_uart_read(altera_16550_uart_
dev* dev, const char * ptr, alt_u16 len, alt_u16 ags);
UG-01085
2016.12.19 16550 UART API 8-13
16550 UART Core Altera Corporation
Send Feedback
Include: <altera_16550_uart.h>
Parameters: dev - e UART device
ptr – destination address
len – maximum length of the data
ags – for indicating blocking/non-blocking access
for single/multi threaded
Returns: Number of bytes read
Description: Read data to the UART receiver buer. UART
required to be in a known settings prior executing
this function
Table 8-16: alt_16550_uart_write
Prototype: alt_u32 alt_16550_uart_write(altera_16550_uart_
dev* dev, const char * ptr, alt_u16 ags, int len);
Include: <altera_16550_uart.h>
Parameters: dev - e UART device
ptr – source address
len – maximum length of the data
ags – for indicating blocking/non-blocking access
for single/multi threaded
Returns: Number of bytes written
Description: Writes data to the UART transmitter buer. UART
required to be in a known settings prior executing
this function
Table 8-17: alt_16550_uart_cong
Prototype: alt_u32 alt_16550_uart_config(altera_16550_uart_
dev* dev, UartCong *cong);
Include: dev - e UART device
Parameters: cong – UART conguration structure to congure
UART (refer to UART device structure
Returns: Return 0 for success otherwise fail
8-14 Public APIs UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Description: Congure UART per user input before initiating read
or Write
Private APIs
Table 8-18: alt_16550_irq
Prototype: static void altera_16550_uart_irq (void* context)
Include: <altera_16550_uart.h>
Parameters: context – device of the UART
Returns: none
Description: Interrupt handler to process UART interrupts to
process receiver/transmit interrupts.
Table 8-19: alt_16550_uart_rxirq
Prototype: static void altera_16550_uart_rxirq (altera_16550_
uart_dev* dev, alt_u32
Include: <altera_16550_uart.h>
Parameters: context – device of the UART
Returns: none
Description: Process a receive interrupt. It transfers the incoming
character into the receiver circular buer, and sets
the appropriate ags to indicate that there is data
ready to be processed.
Table 8-20: alt_16550_uart_txirq
Prototype: static void altera_16550_uart_txirq (altera_16550_
uart_dev* dev, alt_u32 status
Include: <altera_16550_uart.h>
Parameters: context – device of the UART
Returns: none
UG-01085
2016.12.19 Private APIs 8-15
16550 UART Core Altera Corporation
Send Feedback
Description: Process a transmit interrupt. It transfers data from
the transmit buer to the device, and sets the
appropriate ags to indicate that there is data ready
to be processed.
UART Device Structure
Example 8-1: UART Device Structure 1
typedef enum stopbit { STOPB_1 = 0,STOPB_2 } StopBit;
typedef enum paritybit { ODD_PARITY = 0, EVEN_PARITY, MARK_PARITY,
SPACE_PARITY, NO_PARITY } ParityBit;
typedef enum databit { CS_5 = 0, CS_6, CS_7, CS_8, CS_9 = 256} DataBit;
typedef enum baud
{
BR9600 = B9600,
BR19200 = B19200,
BR38400 = B38400,
BR57600 = B57600,
BR115200 = B115200
} Baud;
typedef enum rx_fifo_level_e { RXONECHAR = 0, RXQUARTER, RXHALF, RXFULL }
Rx_FifoLvl;
typedef enum tx_fifo_level_e { TXEMPTY = 0, TXTWOCHAR, TXQUARTER, TXHALF }
Tx_FifoLvl;
typedef struct uart_config_s
{
StopBit stop_bit;
ParityBit parity_bit;
DataBit data_bit;
Baud baudrate;
alt_u32 fifo_mode;
Rx_FifoLvl rx_fifo_level;
Tx_FifoLvl tx_fifo_level;
alt_u32 hwfc;
} UartConfig;
Example 8-2: UART Device Structure 2
typedef struct altera_16550_uart_state_s
{
alt_dev dev;
void* base; /* The base address of the device */
alt_u32 clock;
alt_u32 hwfifomode;
alt_u32 ctrl; /* Shadow value of the LSR register */
volatile alt_u32 rx_start; /* Start of the pending receive data */
volatile alt_u32 rx_end; /* End of the pending receive data */
volatile alt_u32 tx_start; /* Start of the pending transmit data */
volatile alt_u32 tx_end; /* End of the pending transmit data */
alt_u32 freq; /* Current clock freq rate */
UartConfig config; /* Uart setting */
#ifdef ALTERA_16550_UART_USE_IOCTL
struct termios termios;
#endif
alt_u32 flags; /* Configuration flags */
ALT_FLAG_GRP (events) /* Event flags used for
8-16 UART Device Structure UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
* 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;
UG-01085
2016.12.19 UART Device Structure 8-17
16550 UART Core Altera Corporation
Send Feedback
Driver Examples
Below is a simple test program to verify that the Altera 16550 UART driver support is functional.
e test reads, validates, and writes a modied 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).
is also tests the FIFO and FIFO-less mode as well as the HW ow 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
e test will print "PASS: . . ." from the UART to indicate success.
Example 8-3: Verifying Altera 16550 UART Driver Support functionality
#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 UARTDefaultConfig(UartConfig *Config)
{
Config->stop_bit = STOPB_1;
Config->parity_bit = NO_PARITY;
Config->data_bit = CS_8;
Config->baudrate = BR115200;
Config->fifo_mode = 0;
Config->hwfc = 0;
Config->rx_fifo_level= RXFULL;
Config->tx_fifo_level= TXEMPTY;
return 0;
}
int UARTBaudRateTest()
{
UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));
int i=0, j=0, direction=0, Match=0;
8-18 Driver Examples UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
const int nBaud = 5;
int BaudRateCoverage[]= {BR9600, BR19200, BR38400, BR57600, BR115200};
altera_16550_uart_state* uart_0;
altera_16550_uart_state* uart_1;
printf("================================ UART Baud Rate Test Starts Here
=======================================\n");
uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");
for (direction=0; direction<2; direction++)
{
for (i=0; i<nBaud; i++)
{
UARTDefaultConfig(UART0_Config);
UARTDefaultConfig(UART1_Config);
UART0_Config->baudrate=BaudRateCoverage[i];
UART1_Config->baudrate=BaudRateCoverage[i];
printf("Testing Baud Rate: %d\n", UART0_Config->baudrate);
if(ERROR == alt_16550_uart_config (uart_0, UART0_Config)) return
ERROR;
if(ERROR == alt_16550_uart_config (uart_1, UART1_Config)) return
ERROR;
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()
{
UG-01085
2016.12.19 Driver Examples 8-19
16550 UART Core Altera Corporation
Send Feedback
UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));
int x=0, y=0, z=0, Match=0;
const int nDataBit = 2, nParityBit=3, nStopBit=2;
int DataBitCoverage[]= { /*CS_5, CS_6,*/ CS_7, CS_8};
int ParityBitCoverage[]= {ODD_PARITY, EVEN_PARITY, NO_PARITY};
int StopBitCoverage[]= {STOPB_1, STOPB_2};
altera_16550_uart_state* uart_0;
altera_16550_uart_state* uart_1;
printf("================================ UART Line Control Test Starts
Here =======================================\n");
uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");
for(x=0; x<nStopBit; x++)
{
for (y=0; y<nParityBit; y++)
{
for (z=0; z<nDataBit; z++)
{
UARTDefaultConfig(UART0_Config);
UARTDefaultConfig(UART1_Config);
UART0_Config->stop_bit=StopBitCoverage[x];
UART1_Config->stop_bit=StopBitCoverage[x];
UART0_Config->parity_bit=ParityBitCoverage[y];
UART1_Config->parity_bit=ParityBitCoverage[y];
UART0_Config->data_bit=DataBitCoverage[z];
UART1_Config->data_bit=DataBitCoverage[z];
printf("Testing : Stop Bit=%d, Data Bit=%d, Parity Bit=%d
\n", UART0_Config->stop_bit, UART0_Config->data_bit, UART0_Config-
>parity_bit);
if(ERROR == alt_16550_uart_config (uart_0, UART0_Config))
return ERROR;
if(ERROR == alt_16550_uart_config (uart_1, UART1_Config))
return ERROR;
altera_16550_uart_write(uart_0, &TXMessage[0], 1, 0);
usleep(1000);
if(ERROR== altera_16550_uart_read(uart_1, RXMessage, 1, 0))
return ERROR;
if(TXMessage[0]==RXMessage[0]) Match=1; else
{
printf("Sent:'%c', Received:'%c', Match:%d\n",
TXMessage[0], RXMessage[0], Match);
return ERROR;
}
printf("Sent:'%c', Received:'%c', Match:%d\n", TXMessage[0],
RXMessage[0], Match);
}
}
}
free(UART0_Config);
free(UART1_Config);
return SUCCESS;
}
int UARTFIFOModeTest()
{
UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));
int i=0, direction=0, CharCounter=0, Match=0;
const int nBaud = 2;
int BaudRateCoverage[]= {BR115200, /*BR19200, BR38400, BR57600,*/ BR9600};
8-20 Driver Examples UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
altera_16550_uart_state* uart_0;
altera_16550_uart_state* uart_1;
printf("================================ UART FIFO Mode Test Starts Here
=======================================\n");
uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");
for (direction=0; direction<2; direction++)
{
for (i=0; i<nBaud; i++)
{
UARTDefaultConfig(UART0_Config);
UARTDefaultConfig(UART1_Config);
UART0_Config->baudrate=BaudRateCoverage[i];
UART1_Config->baudrate=BaudRateCoverage[i];
UART0_Config->fifo_mode = 1;
UART1_Config->fifo_mode = 1;
UART0_Config->hwfc = 0;
UART1_Config->hwfc = 0;
if(ERROR == alt_16550_uart_config (uart_0, UART0_Config)) return
ERROR;
if(ERROR == alt_16550_uart_config (uart_1, UART1_Config)) return
ERROR;
printf("Testing Baud Rate: %d\n", UART0_Config->baudrate);
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;
UG-01085
2016.12.19 Driver Examples 8-21
16550 UART Core Altera Corporation
Send Feedback
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;
}
Address Map and Register Descriptions
Table 8-21: altr_uart_csr Address Map
Register Oset Width Access Reset Value Description
rbr_thr_dll 0x0 32 RW 0x00000000 Rx Buer, Tx Holding, and
Divisor Latch Low
ier_dlh 0x4 32 RW 0x00000000 Interrupt Enable and Divisor
Latch High
iir 0x8 32 R 0x00000001 Interrupt Identity Register
(when read)
fcr 0x8 32 W 0x00000000 FIFO Control (when written)
lcr 0xC 32 RW 0x00000000 Line Control Register
mcr 0x10 32 RW 0x00000000 Modem Control Register
lsr 0x14 32 R 0x00000060 Line Status Register
msr 0x18 32 R 0x00000000 Modem Status Register
scr 0x1C 32 RW 0x00000000 Scratchpad Register
afr 0x100 32 RW 0x00000000 Additional Features Register
tx_low 0x104 32 RW 0x00000000 Transmit FIFO Low Watermark
Register
Note: RC-Read to Clear
8-22 Address Map and Register Descriptions UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
rbr_thr_dll
Identier Title Oset Access Reset
Value
Description
rbr_thr_dll Rx Buer, Tx
Holding, and
Divisor
Latch Low
0x0 RW 0x000000
0
is is a multi-function register. is
register holds receives and transmit
data and controls the least-signcant 8
bits of the baud rate divisor.
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
Table 8-22: rbr_thr_dll Fields
Bit Name/Identier Description Access Reset
[31:8] - Reserved R 0x0
UG-01085
2016.12.19 rbr_thr_dll 8-23
16550 UART Core Altera Corporation
Send Feedback
Bit Name/Identier Description Access Reset
[7:0] rbr_thr_dll • Receive Buer Register:
is register contains the data byte received on
the serial input port (sin). e data in this
register is valid only if the Data Ready (LSR[0] is
set to 1). If FIFOs are disabled (FCR[0] is cleared
to 0) the data in the RBR must be read before the
next data arrives, otherwise it will be
overwritten, resulting in an overrun error. If
FIFOs are enabled (FCR[0] set to 1) this register
accesses the head of the receive FIFO. If the
receive FIFO is full, and this register is not read
before the next data character arrives, then the
data already in the FIFO will be preserved but
any incoming data will be lost. An overrun error
will also occur.
• Transmit Holding Register:
is register contains data to be transmitted on
the serial output port (sout). Data should only be
written to the THR when the THR Empty bit
(LSR[5] is set to 1). If FIFOs are disabled
(FCR[0] is set to 0) and THRE is set to 1, writing
a single character to the THR clears the THRE.
Any additional writes to the THR before the
THRE is set again causes the THR data to be
overwritten. If FIFO's are enabled (FCR[0] is set
to 1) and THRE is set, the FIFO can be lled up
to a pre-congured depth (FIFO_DEPTH). Any
attempt to write data when the FIFO is full
results in the write data being lost.
• Divisor Latch Low:
is register makes up the lower 8-bits of a 16-
bit, Read/write, Divisor Latch register that
contains the baud rate divisor for the UART. is
register may only be accessed when the DLAB bit
(LCR[7] is set to 1). e output baud rate is equal
to the system clock (clk) frequency divided by
sixteen times the value of the baud rate divisor,
as follows:
baud rate = (system clock freq) / (16 * divisor)
Note: With the Divisor Latch Registers (DLL
and DLH) set to zero, the baud clock is
disabled and no serial communications
will occur. Also, once the DLL is set, at
least 8 system clock cycles should be
allowed to pass before transmitting or
receiving data.
RW 0x00
8-24 rbr_thr_dll UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
ier_dlh
Identier Title Oset Access Reset
Value
Description
ier_dlh Interrupt
Enable and
Divisor
Latch High
0x4 RW 0x000000
00 e ier_dlh (Interrupt Enable
Register) may only be accessed when
the DLAB bit [7] of the LCR Register is
set to 0. Allows control of the Interrupt
Enables for transmit and receive
functions.is is a multi-function
register. is register enables/disables
receive and transmit interrupts and
also controls the most-signicant 8-bits
of the baud rate divisor.
e Divisor Latch High Register is
accessed when the DLAB bit (LCR[7] is
set to 1). Bits[7:0] contain the high
order 8-bits of the baud rate divisor.
e output baud rate is equal to the
system clock (clk) frequency divided by
sixteen times the value of the baud rate
divisor, as follows:
baud rate = (system clock freq) / (16 *
divisor)
Note: With the Divisor Latch
Registers (DLL and DLH)
set to zero, the baud clock is
disabled and no serial
communications will occur.
Also, once the DLL is set, at
least 8 system clock cycles
should be allowed to pass
before transmitting or
receiving data.
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
- dlh7_4 edssi_
dhl3
elsi_
dhl2
etbei_
dlh1
erb_dlh0
UG-01085
2016.12.19 ier_dlh 8-25
16550 UART Core Altera Corporation
Send Feedback
Table 8-23: ier_dlh Fields
Bit Name/Identier Description Access Reset
[31:8] - Reserved R 0x0
[7:4] DLH[7:4] (dlh7_4)• Divisor Latch High Register:
Bit 4, 5, 6 and 7 of DLH value.
RW 0x0
[3] DLH[3] and Enable
Modem Status Interrupt
(edssi_dhl3)
• Divisor Latch High Register:
Bit 3 of DLH value.
• Interrupt Enable Register:
is is used to enable/disable the generation of
Modem Status Interrupts. is is the fourth
highest priority interrupt.
RW 0x0
[2] DLH[2] and Enable
Receiver Line Status
(elsi_dhl2)
• Divisor Latch High Register:
Bit 2 of DLH value.
• Interrupt Enable Register:
is is used to enable/disable the generation of
Receiver Line Status Interrupt. is is the highest
priority interrupt
RW 0x0
[1] DLH[1] and Transmit
Data Interrupt Control
(etbei_dlh1)
• Divisor Latch High Register:
Bit 1 of DLH value.
• Interrupt Enable Register:
Enable Transmit Holding Register Empty
Interrupt. is is used to enable/disable the
generation of Transmitter Holding Register
Empty Interrupt. is is the third highest
priority interrupt.
RW 0x0
[0] DLH[0] and Receive
Data Interrupt Enable
(erbfi_dlh0)
• Divisor Latch High Register:
Bit 0 of DLH value.
• Interrupt Enable Register:
is is used to enable/disable the generation of
the Receive Data Available Interrupt and the
Character Timeout Interrupt (if FIFO's enabled).
ese are the second highest priority interrupts.
RW 0x0
8-26 ier_dlh UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
iir
Identier Title Oset Access Reset
Value
Description
iir Interrupt
Identity
Register
0x8 R 0x000000
01
Returns interrupt identication and
FIFO enable/disable when read.
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
-fose - id
Table 8-24: iir Fields
Bit Name/Identier Description Access Reset
[31:8] - Reserved R 0x0
[7:6] FIFOs Enabled (fifose)e FIFOs Enabled is used to indicate whether the
FIFO's are enabled or disabled.
R 0x0
[5:4] - Reserved R 0x0
[3:0] Interrupt ID (id)e Interrupt ID indicates the highest priority
pending interrupt. Refer to the Table 8-25 table
below for more details.
R 0x1
Table 8-25: Interrupt Priority
IIR ID Interrupt Priority
4'b0000 Modem status 5th
4'b0001 No interrupt pending 6th
4'b0010 THR empty (reect TX_Low
empty threshold if ARF[0] is
'1)
4th
4'b0100 Received data available 2nd
4'b0110 Reciever line status 1st
4'b1100 Character timeout 3rd
UG-01085
2016.12.19 iir 8-27
16550 UART Core Altera Corporation
Send Feedback
fcr
Identier Title Oset Access Reset
Value
Description
fcr FIFO
Control
0x8 W 0x000000
00
Controls FIFO operation when written.
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
- rt - dmam xfor rfor foe
Table 8-26: fcr Fields
Bit Name/Identier Description Access Reset
[31:8] - Reserved R 0x0
[7:6] Rx Trigger Level (rt)is register is congured to implement FIFOs
RxTrigger (or RT). is is used to select the trigger
level in the receiver FIFO at which the Received
Data Available Interrupt will be generated. In auto
ow control mode it is used to determine when the
rts_n signal will be de-asserted
e following trigger levels are supported:
• 00 - One character in FIFO
• 01 - FIFO 1/4 full
• 10 - FIFO 1/2 ful
• 11 - FIFO two less than full
W0x0
[5:4] - Reserved R 0x0
8-28 fcr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Bit Name/Identier Description Access Reset
[3] DMA Mode (dmam)is determines the DMA signalling mode used for
the uart_dma_tx_req_n and uart_dma_rx_req_n
output signals when additional DMA handshaking
signals are not selected. DMA mode 0 supports
single DMA data transfers at a time. In mode 0, the
uart_dma_tx_req_n signal goes active low under
the following conditions:
• When the Transmitter Holding Register is empty
in non-FIFO mode.
• When the transmitter FIFO is empty in FIFO
mode.
It goes inactive under the following conditions:
• When a single character has been written into
the Transmitter Holding Register or transmitter
FIFO.
• When the transmitter FIFO is above the
threshold.
DMA mode 1 supports multi-DMA data transfers,
where multiple transfers are made continuously
until the receiver FIFO has been emptied or the
transmit FIFO has been lled. In mode 1 the uart_
dma_tx_req_n signal is asserted under the following
condition:
• When the transmitter FIFO is empty.
W0x0
[2] Tx FIFO Reset (xfifor)is bit resets the control portion of the transmit
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 aer
changing this register bit before reading from RBR
or writing to THR.
W 0x0
[1] Rx FIFO Reset (rfifor)Resets the control portion of the receive FIFO and
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 aer changing this
register bit before reading from RBR or writing to
THR.
W 0x0
[0] FIFO Enable (fifoe)is bit enables/disables the transmit (Tx) and
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 aer changing this register bit
before reading from RBR or writing to THR.
W 0x0
UG-01085
2016.12.19 fcr 8-29
16550 UART Core Altera Corporation
Send Feedback
lcr
Identier Title Oset Access Reset
Value
Description
lcr Line Control
Register
0xC RW 0x000000
00
Formats serial data.
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
- dls9 dlab break sp eps pen stop dls
Table 8-27: lcr Fields Description
Bit Name/Identier Description Access Reset
[31:9] - Reserved R 0x0
[8] Data Length Select
(dls9)
Issue 1'b1 to LCR[8] and 2'b00 to LCR[1:0] to turn
on 9 data bits per character that the peripheral will
transmit and receive.
RW 0x0
[7] Divisor Latch Access Bit
(dlab)is is used to enable reading and writing of the
Divisor Latch register (DLL and DLH) to set the
baud rate of the UART. is bit must be cleared aer
initial baud rate setup in order to access other
registers.
RW 0x0
[6] Break Control Bit
(break)is is used to cause a break condition to be
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.
RW 0x0
[5] Stick Parity (sp)e SP bit works in conjunction with the EPS and
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.
RW 0x0
[4] Even Parity Select (eps)is is used to select between even and odd parity,
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.
RW 0x0
[3] Parity Enable (pen)is bit is used to enable and disable parity
generation and detection in a transmitted and
received data character.
RW 0x0
8-30 lcr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Bit Name/Identier Description Access Reset
[2] Stop Bits (stop)Number of stop bits. is is used to select the
number of stop bits per character that the peripheral
will transmit and receive. Note that regardless of the
number of stop bits selected the receiver will only
check the rst stop bit.
RW 0x0
[1:0] Data Length Select (dls)Selects the number of data bits per character that
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
RW 0x0
UG-01085
2016.12.19 lcr 8-31
16550 UART Core Altera Corporation
Send Feedback
mcr
Identier Title Oset Access Reset
Value
Description
mcr Modem
Control
Register
0x10 RW 0x000000
00
Reports various operations of the
modem signals.
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
- afce loopba
ck
out2 out1 rts dtr
Table 8-28: mcr Fields Descriptions
Bit Name/Identier Description Access Reset
[31:6] - Reserved R 0x0
[5] Hardware Auto Flow
Control Enable ( afce)When FIFOs are enabled (FCR[0]), the Auto Flow
Control enable bits are active. is enabled UART to
dynamically assert and deassert rts_n based on
Receive FIFO trigger level
RW 0x0
[4] LoopBack Bit
(loopback)is is used to put the UART into a diagnostic mode
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.
RW 0x0
[3] Out2 (out2)is is used to directly control the user-designated
out2_n output. e value written to this location is
inverted and driven out on out2_n
RW 0x0
[2] Out1 (out1)is is used to directly control the user-designated
out1_n output. e value written to this location is
inverted and driven out on out1_n pin.
RW 0x0
8-32 mcr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Bit Name/Identier Description Access Reset
[1] Request to Send (rts)is is used to directly control the Request to Send
(rts_n) output. e Request to Send (rts_n) output
is used to inform the modem or data set that the
UART is ready to exchange data. When Auto RTS
Flow Control is not enabled (MCR[5] set to zero),
the rts_n signal is set low by programming this
register to a high. If Auto Flow Control is active
(MCR[5] set to 1) and FIFO's enable (FCR[0] set to
1), the rts_n output is controlled in the same way,
but is also gated with the receiver FIFO threshold
trigger (rts_n is inactive high when above the
threshold). e rts_n signal will be de-asserted
when this register is set low.
RW 0x0
[0] Data Terminal Ready
(dtr)is is used to directly control the Data Terminal
Ready output. e value written to this location is
inverted and driven out on uart_dtr_n. e Data
Terminal Ready output is used to inform the
modem or data set that the UART is ready to
establish communications.
RW 0x0
UG-01085
2016.12.19 mcr 8-33
16550 UART Core Altera Corporation
Send Feedback
lsr
Identier Title Oset Access Reset
Value
Description
lsr Line Status
Register
0x14 R 0x000000
60
Reports status of transmit and receive.
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
- rfe temt thre bi fe pe oe dr
Table 8-29: lsr Fields
Bit Name/ Identier Description Access Reset
[31:8] - Reserved R 0x0
[7] Receiver FIFO Error bit
(rfe)is bit is only relevant when FIFO's are enabled
(FCR[0] set to one). is is used to indicate if there
is at least one parity error, framing error, or break
indication in the FIFO. is bit is cleared when the
LSR is read and the character with the error is at the
top of the receiver FIFO and there are no
subsequent errors in the FIFO.
R 0x0
[6] Transmitter Empty bit
(temt)If in FIFO mode and FIFO's enabled (FCR[0] set to
one), this bit is set whenever the Transmitter Shi
Register and the FIFO are both empty. If FIFO's are
disabled, this bit is set whenever the Transmitter
Holding Register and the Transmitter Shi Register
are both empty. Indicator is cleared when new data
is written into the THR or Transmit FIFO.
R 0x1
[5] Transmit Holding
Register Empty bit
(thre)
is bit indicates that the THR or Tx FIFO is empty.
is bit is set when data is transferred from the
THR or Tx FIFO to the transmitter shi register and
no new data has been written to the THR or Tx
FIFO. is also causes a THRE Interrupt to execute,
if the THRE Interrupt is enabled.
R 0x1
8-34 lsr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Bit Name/ Identier Description Access Reset
[4] Break Interrupt (bi)is is used to indicate the detection of a break
sequence on the serial input data. Set whenever the
serial input, sin, is held in a logic 0 state for longer
than the sum of start time + data bits + parity + stop
bits. A break condition on serial input causes one
and only one character, consisting of all zeros, to be
received by the UART. e character associated with
the break condition is carried through the FIFO and
is revealed when the character is at the top of the
FIFO. is 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 BI bit.
RC 0x0
[3] Framing Error (fe)is is used to indicate the occurrence of a framing
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]). is 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.
RC 0x0
[2] Parity Error (pe)is is used to indicate the occurrence of a parity
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]). is 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.
RC 0x0
UG-01085
2016.12.19 lsr 8-35
16550 UART Core Altera Corporation
Send Feedback
Bit Name/ Identier Description Access Reset
[1] Overrun error bit (oe)is is used to indicate the occurrence of an overrun
error. is occurs if a new data character was
received before the previous data was read. In the
non-FIFO mode, the OE bit is set when a new
character arrives in the receiver before the previous
character was read from the RBR. When this
happens, the data in the RBR is overwritten. In the
FIFO mode, an overrun error occurs when the FIFO
is full and new character arrives at the receiver. e
data in the FIFO is retained and the data in the
receive shi register is lost.Reading the LSR clears
the OE bit.
RC 0x0
[0] Data Ready bit (dr)is is used to indicate that the receiver contains at
least one character in the RBR or the receiver FIFO.
is bit is cleared when the RBR is read in the non-
FIFO mode, or when the receiver FIFO is empty, in
the FIFO mode.
R 0x0
8-36 lsr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
msr
Identier Title Oset Access Reset
Value
Description
msr Modem
Status
Register
0x18 R 0x000000
00
It should be noted that whenever bits 0,
1, 2 or 3 are set to logic one, to indicate
a change on the modem control inputs,
a modem status interrupt will be
generated if enabled via the IER
regardless of when the change
occurred. Since the delta bits (bits 0, 1,
3) can get set aer a reset if their
respective modem signals are active
(see individual bits for details), a read
of the MSR aer reset can be
performed to prevent unwanted
interrupts.
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
- dcd ri dsr cts ddcd teri ddsr dcts
Table 8-30: msr Fields
Bit Name/Identier Description Access Reset
[31:8] - Reserved R 0x0
[7] Data Carrier Detect
(dcd)is bit is the complement of the modem
control line (dcd_n). is bit is used to
indicate the current state of dcd_n. When the
Data Carrier Detect input (dcd_n) is asserted
it is an indication that the carrier has been
detected by the modem or data set.
R 0x0
[6] Ring Indicator (ri)is bit is the complement of modem control
line (ri_n). is 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.
R 0x0
UG-01085
2016.12.19 msr 8-37
16550 UART Core Altera Corporation
Send Feedback
Bit Name/Identier Description Access Reset
[5] Data Set Ready (dsr)is bit is the complement of modem control
line dsr_n. is bit is used to indicate the
current state of dsr_n. When the Data Set
Ready input (dsr_n) is asserted it is an
indication that the modem or data set is
ready to establish communications with the
uart.
R 0x0
[4] Clear to Send (cts)is bit is the complement of modem control
line cts_n. is 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.
R 0x0
[3] Delta Data Carrier
Detect (ddcd)is is used to indicate that the modem
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 (soware or otherwise),
then the DDCD bit will get set when
the reset is removed if the dcd_n
signal remains asserted.
RC 0x0
[2] Trailing Edge of Ring
Indicator (teri)is is used to indicate that a change on the
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.
RC 0x0
[1] Delta Data Set Ready
(ddsr)is is used to indicate that the modem
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 (soware or otherwise), then
the DDSR bit will get set when the
reset is removed if the dsr_n signal
remains asserted.
RC 0x0
8-38 msr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Bit Name/Identier Description Access Reset
[0] Delta Clear to Send
(dcts)is is used to indicate that the modem
control line cts_n has changed since the last
time the MSR was read. Reading the MSR
clears the DCTS bit.
Note: If the DCTS bit is not set and the
cts_n signal is asserted (low) and a
reset occurs (soware or otherwise),
then the DCTS bit will get set when
the reset is removed if the cts_n
signal remains asserted.
RC 0x0
UG-01085
2016.12.19 msr 8-39
16550 UART Core Altera Corporation
Send Feedback
scr
Identier Title Oset Access Reset
Value
Description
scr Scratchpad
Register
0x1C RW 0x000000
0
Scratchpad Register
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
Table 8-31: scr Fields
Bit Name Description Access Reset
[31:8] - Reserved R 0x0
[7:0] Scratchpad Register
(scr)is register is for programmers to use as a
temporary storage space.
RW 0x0
8-40 scr UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
afr
Identier Title Oset Access Reset
Value
Description
afr Additional
Features
Register
0x100 RW 0x000000
00
ese registers enable additional
features in the so UART controller.
ese features are specic to Altera.
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
Table 8-32: rbr_thr_dll Fields
Bit Name/Identier Description Access Reset
[31:1] - Reserved R 0x0
[0] Transmit FIFO Low
Watermark Enable
Register (tx_low_en)
is bit controls the Tx FIFO Low Watermark
feature. is feature requires FIFO to be enabled
(FCR[0]). When enabled, the UART will send a
Transmit Holding Register Empty status interrupt
when the Transmit FIFO level is at or below the
value stored in tx_low. Legal values for tx_low can
range from zero up to depth of FIFO minus two.
UART behavior is undened when tx_low is set to
illegal values.
• 1 - Transmit FIFO Low Watermark is set by tx_
low
• 0 - Transmit FIFO Low Watermark is unset
is value must only be changed when the Transmit
FIFO is empty or before FIFO is enabled (FCR[0]).
is register is meant to be changed during UART
initialization before active trac is sent. e
Transmit FIFO should be reset using FCR[2] aer
any changes to this value.
RW 0x0
UG-01085
2016.12.19 afr 8-41
16550 UART Core Altera Corporation
Send Feedback
tx_low
Identier Title Oset Access Reset
Value
Description
tx_low Transmit
FIFO Low
Watermark
Register
ox104 RW 0x000000
00
is register is used to set the value of
the Transmit FIFO Low Watermark.
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
Table 8-33: rbr_thr_dll Fields
Bit Name/Identier Description Access Reset
[31:9] - Reserved R 0x0
[8:0] Transmit FIFO Low
Watermark (value)
Set the Transmit FIFO Low Watermark Value.
e lowest legal value is zero
e highest legal value is two less than the FIFO
Depth
is value must only be changed when the Transmit
FIFO is empty or before FIFO is enabled (FCR[0]).
RW 0x00
Document Revision History
Table 8-34: 16550 UART Core Revision History
Date Version Changes
October 2016 2016.10.28 Two new registers:
•afr on page 8-41
•tx_low on page 8-42
Updated:
•lsr on page 8-34 Bit [5]
•fcr on page 8-28 Bit [7:6]
• New table added to iir on page 8-27 section
8-42 tx_low UG-01085
2016.12.19
Altera Corporation 16550 UART Core
Send Feedback
Date Version Changes
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
•Conguration Parameters
•Table 8-8
•DMA Support on page 8-6
• Supported Features
•Table 8-12
•Conguration
•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 Congurability" table in the "Feature Description" section
• Updated "Interface" section with sout_oe signal details in the "Flow
Control" table
• Updated "Underrun" section
July 2014 2014.07.24 Initial Release.
UG-01085
2016.12.19 Document Revision History 8-43
16550 UART Core Altera Corporation
Send Feedback
SPI Core 9
2016.12.19
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 o-chip sensor, conversion, memory, and control devices. e SPI core
with Avalon interface implements the SPI protocol and provides an Avalon Memory-Mapped (Avalon-
MM) interface on the back end.
e SPI core can implement either the master or slave protocol. When congured as a master, the core can
control up to 32 independent SPI slaves. e width of the receive and transmit registers are congurable
between 1 and 32 bits. Longer transfer lengths can be supported with soware routines. e core provides
an interrupt output that can ag an interrupt whenever a transfer completes.
Functional Description
e 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
e SPI core has the following user-visible features:
• A memory-mapped register space comprised of ve registers: rxdata, txdata, status, control, and
slaveselect
• Four SPI interface ports: sclk, ss_n, mosi, and miso
e registers provide an interface to the SPI core and are visible via the Avalon-MM slave port. e
sclk, ss_n, mosi, and miso ports provide the hardware interface to other SPI devices. e behavior of
sclk, ss_n, mosi, and miso depends on whether the SPI core is congured as a master or slave.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 9-1: SPI Core Block Diagram (Master Mode)
clo ck
control
control
baud rate divisor*
IRQ
sclk
mosi
miso
ss_n0
ss_n1
ss_n15
*Not present on SPI slave
txdata
shift register
status
rxdata shift register
data
Avalon-MM
slave
interface
to on-chip
logic
slave select*
e SPI core logic is synchronous to the clock input provided by the Avalon-MM interface. When
congured as a master, the core divides the Avalon-MM clock to generate the SCLK output. When
congured as a slave, the core's receive logic is synchronized to SCLK input.
For more details, refer to the "Interval Timer Core" chapter.
Example Congurations
e core block diagram and the SPI core congured as a slave diagram show two possible congurations.
In Figure 9-2 the core provides a slave interface to an o-chip SPI master.
Figure 9-2: SPI Core Congured as a Slave
Altera FPGA
sclk
ss_n
mosi
miso
miso
mosi
ss
sclk
SPI
Master
Device
SPI component
(configured as slave)
Avalon-MM
interface
to on-chip
logic
In the SPI core block diagram, the SPI core provides a master interface driving multiple o-chip slave
devices. Each slave device in Figure 9-2 must tristate its miso output whenever its select signal is not
asserted.
e 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
e core transmitter logic consists of a transmit holding register (txdata) and transmit shi register, each
n bits wide. e register width n is specied at system generation time, and can be any integer value from 8
9-2 Example Congurations UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
to 32. Aer a master peripheral writes a value to the txdata register, the value is copied to the shi register
and then transmitted when the next operation starts.
e shi register and the txdata register provide double buering during data transmission. A new value
can be written into the txdata register while the previous data is being shied out of the shi register. e
transmitter logic automatically transfers the txdata register to the shi register whenever a serial shi
operation is not currently in process.
In master mode, the transmit shi register directly feeds the mosi output. In slave mode, the transmit shi
register directly feeds the miso output. Data shis out LSB rst or MSB rst, depending on the congura‐
tion of the SPI core.
Receiver Logic
e core receive logic consists of a receive holding register (rxdata) and receive shi register, each n bits
wide. e register width n is specied at system generation time, and can be any integer value from 8 to
32. A master peripheral reads received data from the rxdata register aer the shi register has captured a
full n-bit value of data.
e shi register and the rxdata register provide double buering while receiving data. e rxdata
register can hold a previously received data value while subsequent new data is shiing into the shi
register. e receiver logic automatically transfers the shi register content to the rxdata register when a
serial shi operation completes.
In master mode, the shi register is fed directly by the miso input. In slave mode, the shi register is fed
directly by the mosi input. e receiver logic expects input data to arrive LSB rst or MSB rst, depending
on the conguration of the SPI core.
Master and Slave Modes
At system generation time, the designer congures the SPI core in either master mode or slave mode. e
mode cannot be switched at runtime.
Master Mode Operation
In master mode, the SPI ports behave as shown in the table below.
Table 9-1: Master Mode Port Congurations
Name Direction Description
mosi output Data output to slave(s)
miso input Data input from slave(s)
sclk output Synchronization clock to all slaves
ss_nM output Slave select signal to slave M, where M is a number between 0 and 31.
In master mode, an intelligent host (for example, a microprocessor) congures the SPI core using the
control and slaveselect registers, and then writes data to the txdata buer 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 buer is ready for new data.
e SPI protocol is full duplex, so every transaction both sends and receives data at the same time. e
master transmits a new data bit on the mosi output and the slave drives a new data bit on the miso input
UG-01085
2016.12.19 Receiver Logic 9-3
SPI Core Altera Corporation
Send Feedback
for each active edge of sclk. e SPI core divides the Avalon-MM system clock using a clock divider to
generate the sclk signal.
When the SPI core is congured 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 specied 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. e number of slave devices is specied at system generation time.
Slave Mode Operation
In slave mode, the SPI ports behave as shown in the table below.
Table 9-2: Slave Mode Port Congurations
Name Direction Description
mosi input Data input from the master
miso output Data output to the master
sclk input Synchronization clock
ss_n input Select signal
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 shi register contents to the miso output. e slave logic also
captures data on the mosi input, and lls the receive shi register simultaneously. Aer 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 buer 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. e provided
SPI slave core drives an undened 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 o-chip SPI master device with multiple slaves. In this case, the ss_n input should be used
to control a tristate buer on the miso signal.
9-4 Slave Mode Operation UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
Figure 9-3: SPI Core in a Multi-Slave Environment
SPI
Master
Device
sclk
mosi
miso
ss_n0
ss_01
sclk
mosi
miso
ss_n0
SPI
Slave
Device
SS_n
miso
mosi
sclk
SPI component
(configured as slave)
Conguration
e following sections describe the available conguration options.
Master/Slave Settings
e 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.
Number of Select (SS_n) Signals
is setting species the number of slaves the SPI master connects to. e range is 1 to 32. e SPI master
core presents a unique ss_n signal for each slave.
SPI Clock (sclk) Rate
is setting determines the rate of the sclk signal that synchronizes data between master and slaves. e
target clock rate can be specied in units of Hz, kHz or MHz. e SPI master core uses the Avalon-MM
system clock and a clock divisor to generate sclk.
e actual frequency of sclk may not exactly match the desired target clock rate. e achievable clock
values are:
<Avalon-MM system clock frequency> / [2, 4, 6, 8, ...]
e actual frequency achieved will not be greater than the specied target value.
Specify Delay
Turning on this option causes the SPI master to add a time delay between asserting the ss_n signal and
shiing the rst bit of data. is 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.
UG-01085
2016.12.19 Conguration 9-5
SPI Core Altera Corporation
Send Feedback
Figure 9-4: Time Delay Between Asserting ss_n and Toggling sclk
e delay generation logic uses a granularity of half the period of sclk. e 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)
Data Register Settings
e data register settings aect the size and behavior of the data registers in the SPI core. ere are two
data register settings:
•Width—is setting species the width of rxdata, txdata, and the receive and transmit shi registers.
e range is from 1 to 32.
•Shi direction—is setting determines the direction that data shis (MSB rst or LSB rst) into and
out of the shi registers.
Timing Settings
e timing settings aect 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. ere are two timing settings:
•Clock polarity—is 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 phase—is 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.
e following four clock polarity gures demonstrate the behavior of signals in all possible cases of
clock polarity and clock phase.
Figure 9-5: Clock Polarity = 0, Clock Phase = 0
9-6 Data Register Settings UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
Figure 9-6: Clock Polarity = 0, Clock Phase = 1
Figure 9-7: Clock Polarity = 1, Clock Phase = 0
Figure 9-8: Clock Polarity = 1, Clock Phase = 1
Software Programming Model
e following sections describe the soware programming model for the SPI core, including the register
map and soware constructs used to access the hardware. For Nios II processor users, Altera provides the
HAL system library header le that denes the SPI core registers. e SPI 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. Altera provides a routine to access the SPI hardware that is specic to the SPI core.
Hardware Access Routines
Altera provides one access routine, alt_avalon_spi_command(), that provides general-purpose access to
the SPI core that is congured as a master.
alt_avalon_spi_command()
Prototype: int alt_avalon_spi_command(alt_u32 base, alt_u32 slave,
alt_u32 write_length,
const alt_u8* wdata,
alt_u32 read_length,
alt_u8* read_data,
alt_u32 flags)
UG-01085
2016.12.19 Software Programming Model 9-7
SPI Core Altera Corporation
Send Feedback
read-safe: No.
Available from ISR: No.
Include: <altera_avalon_spi.h>
Description: is 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 buer of arbitrary length to the mosi port, and then
reads back an arbitrary amount of data from the miso port. e function
performs the following actions:
(1) Asserts the slave select output for the specied slave. e rst 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 buer
pointed to by read_data. e mosi port is set to zero during the read transac‐
tion.
(4) De-asserts the slave select output, unless the ags eld contains the value
ALT_AVALON_SPI_COMMAND_MERGE. If you want to transmit from
scattered buers, call the function multiple times and specify the merge ag
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.
Returns: e number of bytes stored in the read_data buer.
Software Files
e core is accompanied by the following soware les. ese les provide a low-level interface to the
hardware.
•altera_avalon_spi.h—is le denes the core's register map, providing symbolic constants to
access the low-level hardware.
•altera_avalon_spi.c—is le implements low-level routines to access the hardware.
9-8 Software Files UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
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 gure. e table assumes an n-bit data width
for rxdata and txdata.
Table 9-5: Register Map for SPI Master Device
Internal
Address
Register Name Type
[R/W]
32-
11
10 9 8 7 6 5 4 3 2-0
0rxdata (8) RRXDATA (n-1..0)
1txdata (8) WTXDATA (n-1..0)
2status (6) R/W EOP E RRDY TRDY TMT TOE ROE
3control R/W SSO (7) IEOP IE IRRD
Y
ITRD
Y
ITOE IROE
4 Reserved —
5slaveselect (7) R/W Slave Select Mask
6eop_value(8) R/W End of Packet Value (n-1..0)
Reading undened bits returns an undened value. Writing to undened bits has no eect.
rxdata Register
A master peripheral reads received data from the rxdata register. When the receive shi 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 eect.
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 undened.
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. e TRDY bit is set to 0 whenever
the txdata register is written. e TRDY bit is set to 1 aer data is transferred from the txdata register into
the transmitter shi 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 undened when n is less than 32.
UG-01085
2016.12.19 Register Map 9-9
SPI Core Altera Corporation
Send Feedback
As an example, assume that the SPI core is idle (that is, the txdata register and transmit shi register are
empty), when a CPU writes a data value into the txdata holding register. e TRDY bit is set to 0
momentarily, but aer the data in txdata is transferred into the transmitter shi register, TRDY returns to
1. e CPU writes a second data value into the txdata register, and again the TRDY bit is set to 0. is time
the shi register is still busy transferring the original data value, so the TRDY bit remains at 0 until the shi
operation completes. When the operation completes, the second data value is transferred into the
transmitter shi register and the TRDY bit is again set to 1.
status Register
e 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.
Table 9-6: status Register Bits
# Name Description
3ROE Receive-overrun error
e ROE bit is set to 1 if new data is received while the rxdata register is full (that is, while the
RRDY bit is 1). In this case, the new data overwrites the old. Writing to the status register
clears the ROE bit to 0.
4TOE Transmitter-overrun error
e TOE bit is set to 1 if new data is written to the txdata register while it is still full (that is,
while the TRDY bit is 0). In this case, the new data is ignored. Writing to the status register
clears the TOE bit to 0.
5TMT Transmitter shi-register empty
In master mode, the TMT bit is set to 0 when a transaction is in progress and set to 1 when the
shi register is empty.
In slave mode, the TMT bit is set to 0 when the slave is selected (SS_n is low) or when the SPI
Slave register interface is not ready to receive data.
6TRDY Transmitter ready
e TRDY bit is set to 1 when the txdata register is empty.
7RRDY Receiver ready
e RRDY bit is set to 1 when the rxdata register is full.
8EError
e E bit is the logical OR of the TOE and ROE bits. is is a convenience for the programmer to
detect error conditions. Writing to the status register clears the E bit to 0.
9-10 status Register UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
# Name Description
9EOP End of Packet
e EOP bit is set when the End of Packet condition is detected. e 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
e 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. e SPI core asserts an
interrupt request when the corresponding bits in status and control are both 1.
Table 9-7: control Register Bits
# Name Description
3IROE Setting IROE to 1 enables interrupts for receive-overrun errors.
4ITOE Setting ITOE to 1 enables interrupts for transmitter-overrun errors.
6ITRDY Setting ITRDY to 1 enables interrupts for the transmitter ready condition.
7IRRDY Setting IRRDY to 1 enables interrupts for the receiver ready condition.
8IE Setting IE to 1 enables interrupts for any error condition.
9IEOP Setting IEOP to 1 enables interrupts for the End of Packet condition.
10 SSO Setting SSO to 1 forces the SPI core to drive its ss_n outputs, regardless of whether a serial
shi operation is in progress or not. e slaveselect register controls which ss_n outputs are
asserted. SSO can be used to transmit or receive data of arbitrary size, for example, greater
than 32 bits.
Aer reset, all bits of the control register are set to 0. All interrupts are disabled and no ss_n signals are
asserted.
slaveselect Register
e slaveselect register is a bit mask for the ss_n signals driven by an SPI master. During a serial shi
operation, the SPI master selects only the slave device(s) specied in the slaveselect register.
e slaveselect register is only present when the SPI core is congured in master mode. ere is one bit
in slaveselect for each ss_n output, as specied 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.
UG-01085
2016.12.19 control Register 9-11
SPI Core Altera Corporation
Send Feedback
Upon reset, bit 0 is set to 1, and all other bits are cleared to 0. us, aer a device reset, slave device 0 is
automatically selected.
end of packet value Register
e end of packet value register allows you to specify the value of the SPI data word. e SPI data word
acts as the end of packet word.
Document Revision History
Table 9-8: SPI Core Document Revision History
Date Version Changes
June 2016 2016.06.17 Updates:
• Removed content regarding Avalon-MM ow control
•Table 9-5: eop_value added
•Table 9-6: EOP added
•Table 9-7: IEOP added
•end of packet value Register on page 9-12: New topic
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 ow control option.
Added R/W column in Table 9-5 .
March 2009 v9.0.0 No change from previous release.
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.
9-12 end of packet value Register UG-01085
2016.12.19
Altera Corporation SPI Core
Send Feedback
Optrex 16207 LCD Controller Core 10
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Optrex 16207 LCD controller core with Avalon® Interface (LCD controller core) provides the
hardware interface and soware driver required for a Nios® II processor to display characters on an
Optrex 16207 (or equivalent) 16×2-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(). e LCD controller is Qsys-ready, and
integrates easily into any Qsys-generated system.
e 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
e LCD controller core consists of two user-visible components:
• Eleven signals that connect to pins on the Optrex 16207 LCD panel—ese signals are dened in the
Optrex 16207 data sheet.
•E—Enable (output)
•RS—Register Select (output)
•R/W—Read or Write (output)
•DB0 through DB7—Data Bus (bidirectional)
• An Avalon Memory-Mapped (Avalon-MM) slave interface that provides access to 4 registers.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 10-1: LCD Controller Block Diagram
address
data
control DB0 .. DB7
R/W
RS
E
Optrex 16207
LCD Module
LCD
Controller
Avalon-MM slave
interface to
on-chip logic
Altera FPGA
Software Programming Model
is section describes the soware programming model for the LCD controller.
HAL System Library Support
Altera provides HAL system library drivers for the Nios II processor that enable you to access the LCD
controller using the ANSI C standard library functions. e Altera-provided drivers integrate into the
HAL system library for Nios II systems. e LCD driver is a standard character-mode device, as described
in the Nios II Soware Developer’s Handbook. erefore, using printf() is the easiest way to write
characters to the display.
e LCD driver requires that the HAL system library include the system clock driver.
Displaying Characters on the LCD
e driver implements VT100 terminal-like behavior on a miniature scale for the 16×2 screen. Characters
written to the LCD controller are stored to an 80-column × 2-row buer maintained by the driver. As
characters are written, the cursor position is updated. Visible characters move the cursor position to the
right. Any visible characters written to the right of the buer are discarded. e line feed character (\n)
moves the cursor down one line and to the le-most column.
e buer is scrolled up as soon as a printable character is written onto the line below the bottom of the
buer. Rows do not scroll as soon as the cursor moves down to allow the maximum useful information in
the buer to be displayed.
If the visible characters in the buer t on the display, all characters are displayed. If the buer is wider
than the display, the display scrolls horizontally to display all the characters. Dierent lines scroll at
dierent speeds, depending on the number of characters in each line of the buer.
e LCD driver supports a small subset of ANSI and VT100 escape sequences that can be used to control
the cursor position, and clear the display as shown below.
Table 10-1: Escape Sequence Supported by the LCD Controller
Sequence Meaning
BS (\b) Moves the cursor to the le by one character.
10-2 Software Programming Model UG-01085
2016.12.19
Altera Corporation Optrex 16207 LCD Controller Core
Send Feedback
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 specied – positions are
counted from the top le which is 1;1.
ESC [ K Clears from current cursor position to end of line.
ESC [ 2 J Clears the whole screen.
e LCD controller is an output-only device. erefore, attempts to read from it returns immediately
indicating that no characters have been received.
e 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 option—DALT_USE_LCD_16207 to the preprocessor options.
Software Files
e LCD controller is accompanied by the following soware les. ese les dene the low-level interface
to the hardware and provide the HAL drivers. Application developers should not modify these les.
•altera_avalon_lcd_16207_regs.h — is le denes the core's register map, providing
symbolic constants to access the low-level hardware.
•altera_avalon_lcd_16207.h, altera_avalon_lcd_16207.c — ese les implement the
LCD controller device drivers for the HAL system library.
Register Map
e HAL device drivers make it unnecessary for you to access the registers directly. erefore, Altera does
not publish details about the register map. For more information, the altera_avalon_lcd_16207_
regs.h le describes the register map, and the Dot Matrix Character LCD Module User's Manual from
Optrex describes the register usage.
Interrupt Behavior
e 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.
Document Revision History
Table 10-2: Optrex 16207 LCD Controller Core 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.
UG-01085
2016.12.19 Software Files 10-3
Optrex 16207 LCD Controller Core Altera Corporation
Send Feedback
Date Version Changes
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
10-4 Document Revision History UG-01085
2016.12.19
Altera Corporation Optrex 16207 LCD Controller Core
Send Feedback
PIO Core 11
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e I/O ports
connect either to on-chip user logic, or to I/O pins that connect to devices external to the FPGA.
e PIO core provides easy I/O access to user logic or external devices in situations where a “bit banging”
approach is sucient. Some example uses are:
• Controlling LEDs
• Acquiring data from switches
• Controlling display devices
•Conguring and communicating with o-chip devices, such as application-specic standard products
(ASSP)
e PIO core interrupt request (IRQ) output can assert an interrupt based on input signals.
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. e 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 o-chip LCD display.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 11-1: System Using Multiple PIO Cores
System Interconnect Fabric
CPU
PIO core
(output only)
Program
and Data
Memory
PIO
core
(bidirectional)
IRQ
LEDs
Edge
Capture
PIO
core
(input
only)
Reset
request
logic
Altera FPGA
4
11 LCD
display
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
e I/O ports can be connected to logic inside the FPGA, or to device pins that connect to o-chip
devices. e 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.
Data Input and Output
e PIO core I/O ports can connect to either on-chip or o-chip logic. e core can be congured with
inputs only, outputs only, or both inputs and outputs. If the core is used to control bidirectional I/O pins
on the device, the core provides a bidirectional mode with tristate control.
e hardware logic is separate for reading and writing the data register. Reading the data register returns
the value present on the input ports (if present). Writing data aects the value driven to the output ports
(if present). ese ports are independent; reading the data register does not return previously-written data.
Edge Capture
e PIO core can be congured 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. e types of edges detected is specied at system generation time, and cannot be
changed via the registers.
IRQ Generation
e PIO core can be congured to generate an IRQ on certain input conditions. e IRQ conditions can
be either:
11-2 Data Input and Output UG-01085
2016.12.19
Altera Corporation PIO Core
Send Feedback
•Level-sensitive—e PIO core hardware can detect a high level. A NOT gate can be inserted external to
the core to provide negative sensitivity.
•Edge-sensitive—e core's edge capture conguration determines which type of edge causes an IRQ
Interrupts are individually maskable for each input port. e interrupt mask determines which input
port can generate interrupts.
Example Congurations
Figure 11-2: PIO Core with Input Ports, Output Ports, and IRQ Support
data in
out
address
data
control
IRQ
32
interruptmask
edgecapture
Avalon-MM
interface
to on-chip
logic
e block diagram below shows the PIO core congured in bidirectional mode, without support for IRQs.
Figure 11-3: PIO Cores with Bidirectional Ports
direction
data in
out
address
data
control
32
Avalon-MM
interface
to on-chip
logic
Avalon-MM Interface
e PIO core's Avalon-MM interface consists of a single Avalon-MM slave port. e slave port is capable
of fundamental Avalon-MM read and write transfers. e Avalon-MM slave port provides an IRQ output
so that the core can assert interrupts.
Conguration
e following sections describe the available conguration options.
Basic Settings
e Basic Settings page allows you to specify the width, direction and reset value of the I/O ports.
UG-01085
2016.12.19 Example Congurations 11-3
PIO Core Altera Corporation
Send Feedback
Width
e 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.
Table 11-1: Direction Settings
Setting Description
Bidirectional (tristate) ports In this mode, each PIO bit shares one device pin for driving and
capturing data. e direction of each pin is individually
selectable. To tristate an FPGA I/O pin, set the direction to
input.
Input ports only In this mode the PIO ports can capture input only.
Output ports only In this mode the PIO ports can drive output only.
Both input and output ports In this mode, the input and output ports buses are separate,
unidirectional buses of n bits wide.
Output Port Reset Value
You can specify the reset value of the output ports. e range of legal values depends on the port width.
Output Register
e 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 registers—outset and outclear—are
implemented. You can use these registers to specify the output bit to set and clear.
Input Options
e Input Options page allows you to specify edge-capture and IRQ generation settings. e Input
Options page is not available when Output ports only is selected on the Basic Settings page.
11-4 Width UG-01085
2016.12.19
Altera Corporation PIO Core
Send Feedback
Edge Capture Register
Turn on Synchronously capture to include the edge capture register, edgecapture, in the core. e edge
capture register allows the core to detect and generate an optional interrupt when an edge of the specied
type occurs on an input port. e user must further specify the following features:
• Select the type of edge to detect:
•Rising Edge
•Falling Edge
•Either Edge
• Turn on Enable bit-clearing for edge capture register to clear individual bit in the edge capture
register. To clear a given bit, write 1 to the bit in the edge capture register.
Interrupt
Turn on Generate IRQ to assert an IRQ output when a specied event occurs on input ports. e user
must further specify the cause of an IRQ event:
•Level— e core generates an IRQ whenever a specic input is high and interrupts are enabled for that
input in the interruptmask register.
•Edge— e core generates an IRQ whenever a specic bit in the edge capture register is high and
interrupts are enabled for that bit in the interruptmask register.
When Generate IRQ is o, the interruptmask register does not exist.
Simulation
e 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 eld.
Software Programming Model
is section describes the soware programming model for the PIO core, including the register map and
soware constructs used to access the hardware. For Nios® II processor users, Altera provides the HAL
system library header le that denes the PIO core registers. e 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.
e 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
e PIO core is accompanied by one soware le, altera_avalon_pio_regs.h. is le denes 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. e table assumes that the PIO core's I/O ports are congured to a
width of n bits.
UG-01085
2016.12.19 Edge Capture Register 11-5
PIO Core Altera Corporation
Send Feedback
Table 11-2: Register Map for the PIO Core
Oset Register Name R/W (n-1) ... 2 1 0
0data read access R Data value currently on PIO inputs
write access W New value to drive on PIO outputs
1direction (1) R/W Individual direction control for each I/O
port. A value of 0 sets the direction to input;
1 sets the direction to output.
2interruptmask (1) R/W IRQ enable/disable for each input port.
Setting a bit to 1 enables interrupts for the
corresponding port.
3edgecapture (1) , (2) R/W Edge detection for each input port.
4outset WSpecies which bit of the output port to set.
Outset value is not stored into a physical
register in the IP core. Hence it's value is not
reserve for future use.
5outclear WSpecies which output bit to clear. Outclear
value is not stored into a physical register in
the IP core. Hence it's value is not reserve for
future use.
Table 11-2 :
1. is register may not exist, depending on the hardware conguration. If a register is not
present, reading the register returns an undened value, and writing the register has no eect.
2. If the option Enable bit-clearing for edge capture register is turned o, 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.
data Register
Reading from data returns the value present at the input ports if the PIO core hardware is congured to
input, or inout mode only. If the PIO core hardware is congured to output-only mode, reading from the
data register returns the value present at the output ports. Whereas, if the PIO core hardware is
congured 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 undened value.
Writing to data stores the value to a register that drives the output ports. If the PIO core hardware is
congured in input-only mode, writing to data has no eect. 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
e 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.
e direction register only exists when the PIO core hardware is congured in bidirectional mode. In
input-only, output-only and inout mode, the direction register does not exist. In this case, reading
11-6 data Register UG-01085
2016.12.19
Altera Corporation PIO Core
Send Feedback
direction returns an undened value, writing direction has no eect. e mode (input, output, inout
or bidirectional) is specied at system generation time, and cannot be changed at runtime.
Aer reset, all direction register bits are 0, so that all bidirectional I/O ports are congured 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 conguration of the PIO core. See the Interrupt Behavior
section.
e interruptmask register only exists when the hardware is congured to generate IRQs. If the core
cannot generate IRQs, reading interruptmask returns an undened value, and writing to interruptmask
has no eect.
Aer 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 o, 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.
e type of edge(s) to detect is xed in hardware at system generation time. e edgecapture register
only exists when the hardware is congured to capture edges. If the core is not congured to capture
edges, reading from edgecapture returns an undened value, and writing to edgecapture has no eect.
outset and outclear Register
You can use the outset and outclear registers to set and clear individual bits of the output port. For
example, to set bit 6 of the output port, write 0x40 to the outset register. Writing 0x08 to the outclear
register clears bit 3 of the output port.
ese registers are only present when the option Enable individual bit set/clear output register is turned
on. Outset and outclear registers are not physical registers inside the IP core, hence the output port value
will only be aected by the current update outset value or current update outclear value only.
Interrupt Behavior
e PIO core outputs a single IRQ signal that can connect to any master peripheral in the system. e
master can read either the data register or the edgecapture register to determine which input port caused
the interrupt.
When the hardware is congured for level-sensitive interrupts, the IRQ is asserted whenever
corresponding bits in the data and interruptmask registers are 1. When the hardware is congured for
edge-sensitive interrupts, the IRQ is asserted whenever corresponding bits in the edgecapture and
interruptmask registers are 1. e IRQ remains asserted until explicitly acknowledged by disabling the
appropriate bit(s) in interruptmask, or by writing to edgecapture.
UG-01085
2016.12.19 interruptmask Register 11-7
PIO Core Altera Corporation
Send Feedback
Software Files
e PIO core is accompanied by the following soware le. is le provide low-level access to the
hardware. Application developers should not modify the le.
•altera_avalon_pio_regs.h—is le denes the core's register map, providing symbolic
constants to access the low-level hardware. e symbols in this le are used by device driver functions.
Document Revision History
Table 11-3: PIO Core Revision History
Date Version Changes
December 2015 2015.12.16 Updated "edgecapture Register" section
June 2015 2015.06.12 • Updated "Register Map" section
• Updated "data Register" section
• Updated "direction Register" section
• Updated "outset and outclear Register" section
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2013 v13.1.0 Updated note (2) in Register map for PIO Core Table
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 No change from previous release
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
11-8 Software Files UG-01085
2016.12.19
Altera Corporation PIO Core
Send Feedback
Avalon-ST Serial Peripheral Interface Core 12
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon® Streaming (Avalon-ST) Serial Peripheral Interface (SPI) core is an SPI slave that allows data
transfers between Qsys systems and o-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.
e 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
Avalon-ST
Source
Avalon-ST
Sink
Avalon-ST
Serial
Peripheral
Interface
Core
SPI
a
F
t
c
e
n
n
o
c
r
e
t
n
I
m
e
t
s
y
Sbc
i
r
Rest of the
System
data_out
data_in
SPI
Master
mosi
miso
sclk
nSS
Altera FPGA
SPI
Clock System
Clock
Interfaces
e 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.
Table 12-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Not supported.
Data Width Data width = 8 bits; Bits per symbol = 8.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Feature Property
Channel Not supported.
Error Not used.
Packet Not supported.
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specications.
Operation
e Avalon-ST SPI core waits for the nSS signal to be asserted low, signifying that the SPI master is
initiating a transaction. e core then starts shiing in bits from the input signal mosi. e core packs the
bits received on the SPI to bytes and checks for the following special characters:
•0x4a—Idle character. e core drops the idle character.
•0x4d—Escape character. e 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 shis data out from the Avalon-ST sink to the output signal miso beginning
with from the most signicant bit. If there is no data to shi out, the core shis out idle characters
(0x4a). If the data is a special character, the core inserts an escape character (0x4d) and XORs the data
with 0x20.
e data shis into and out of the core in the direction of MSB rst.
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
SPI Transfer Protocol Notes:
• TL = e worst recovery time of sclk with respect with nSS.
• TT = e worst hold time for MOSI and MISO data.
• TI = e minimum width of a reset pulse required by Altera FPGA families.
Timing
e 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. e nSS signal must be deasserted
for a minimum idling time (TI) of one SPI clock between byte transfers. A TimeQuest SDC le (.sdc) is
12-2 Operation UG-01085
2016.12.19
Altera Corporation Avalon-ST Serial Peripheral Interface Core
Send Feedback
provided to remove false timing paths. e frequency of the SPI master’s clock must be equal to or lower
than the frequency of the core’s clock.
Limitations
Daisy-chain conguration, where the output line miso of an instance of the core is connected to the input
line mosi of another instance, is not supported.
Conguration
e parameter Number of synchronizer stages: Depth allows you to specify the length of
synchronization register chains. ese register chains are used when a metastable event is likely to occur
and the length specied determines the meantime before failure. e register chain length, however,
aects 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.
Document Revision History
Table 12-2: Avalon-ST Serial Peripheral Interface Core 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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 Added a description to specify the shi direction.
March 2009 v9.0.0 Added description of a new parameter, Number of synchronizer
stages: Depth.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Initial release.
UG-01085
2016.12.19 Limitations 12-3
Avalon-ST Serial Peripheral Interface Core Altera Corporation
Send Feedback
Avalon-ST Single-Clock and Dual-Clock FIFO
Cores 13
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon® Streaming (Avalon-ST) Single-Clock and Avalon-ST Dual-Clock FIFO cores are FIFO buers
which operate with a common clock and independent clocks for input and output ports respectively. e
FIFO cores are congurable, SOPC Builder-ready, and integrate easily into any SOPC Builder-generated
systems.
Functional Description
e following two gures 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
Avalon-ST
Single-Clock
FIFO
Avalon-MM
Slave
almost_full almost_empty
csr
Avalon-ST
Status
Source
Avalon-ST
Status
Source
out
in Avalon-ST
Data
Sink
Avalon-ST
Data
Source
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 13-2: Avalon-ST Dual Clock FIFO Core
Avalon-MM
Slave
orsc_ni ut_csr
Avalon-MM
Slave
out
in
Clock A Clock B
Avalon-ST
Dual-Clock
FIFO
Avalon-ST
Data
Sink
Avalon-ST
Data
Source
Interfaces
is section describes the interfaces implemented in the FIFO cores.
RL**For more information about Avalon interfaces, refer to the Avalon Interface Specications.
Avalon-ST Data Interface
Each FIFO core has an Avalon-ST data sink and source interfaces. e data sink and source interfaces in
the dual-clock FIFO core are driven by dierent clocks.
Table 13-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Ready latency = 0.
Data Width Congurable.
Channel Supported, up to 255 channels.
Error Congurable.
Packet Congurable.
Avalon-MM Control and Status Register Interface
You can congure the single-clock FIFO core to include an optional Avalon-MM interface, and the dual-
clock FIFO core to include an Avalon-MM interface in each clock domain. e Avalon-MM interface
provides access to 32-bit registers, which allows you to retrieve the FIFO buer ll level and congure the
almost-empty and almost-full thresholds. In the single-clock FIFO core, you can also congure the packet
and error handling modes.
Avalon-ST Status Interface
e single-clock FIFO core has two optional Avalon-ST status source interfaces from which you can
obtain the FIFO buer almost-full and almost empty statuses.
13-2 Interfaces UG-01085
2016.12.19
Altera Corporation Avalon-ST Single-Clock and Dual-Clock FIFO Cores
Send Feedback
Operating Modes
e following lists the FIFO operating modes:
• Default mode—e core accepts incoming data on the in interface (Avalon-ST data sink) and forwards
it to the out interface (Avalon-ST data source). e core asserts the valid signal on the Avalon-ST
source interface to indicate that data is available at the interface.
• Store and forward mode—is mode only applies to the single-clock FIFO core. e 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— is mode only applies to the single-clock FIFO core. e core asserts the valid
signal on the out interface to indicate that data is available for consumption when the number of
entries specied in the cut_through_threshold register are available in the FIFO buer.
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. e non-zero value species 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 ll level of the FIFO buer via the optional Avalon-MM control and status interface.
Turn on the Use ll level parameter (Use sink ll level and Use source ll level in the dual-clock FIFO
core) and read the fill_level register.
e dual-clock FIFO core has two ll levels, one in each clock domain. Due to the latency of the clock
crossing logic, the ll levels reported in the input and output clock domains may be dierent at any given
instance. In both cases, the ll level is pessimistic for the clock domain; the ll level is reported high in the
input clock domain and low in the output clock domain.
e dual-clock FIFO has an output pipeline stage to improve fMAX. is output stage is accounted for
when calculating the output ll level, but not when calculating the input ll level. Hence, the best measure
of the amount of data in the FIFO is given by the ll level in the output clock domain, while the ll level in
the input clock domain represents the amount of space available in the FIFO (Available space = FIFO
depth – input ll level).
Thresholds
You can use almost-full and almost-empty thresholds as a mechanism to prevent FIFO overow and
underow. is feature is only available in the single-clock FIFO core.
To use the thresholds, turn on the Use ll 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). e core asserts the almost_full signal when the ll level is equal to
or higher than the almost-full threshold. Likewise, the core asserts the almost_empty signal when the ll
level is equal to or lower than the almost-empty threshold.
UG-01085
2016.12.19 Operating Modes 13-3
Avalon-ST Single-Clock and Dual-Clock FIFO Cores Altera Corporation
Send Feedback
Parameters
Table 13-2: Congurable Parameters
Parameter Legal Values Description
Bits per symbol 1–32 ese parameters determine the width of the FIFO.
FIFO width = Bits per symbol * Symbols per beat, where:
Bits per symbol is the number of bits in a symbol, and
Symbols per beat is the number of symbols transferred in a beat.
Symbols per
beat
1–32
Error width 0–32 e width of the error signal.
FIFO depth 1–32 e FIFO depth. An output pipeline stage is added to the FIFO
to increase performance, which increases the FIFO depth by
one.
Use packets — Turn on this parameter to enable packet support on the Avalon-
ST data interfaces.
Channel width 1–32 e width of the channel signal.
Avalon-ST Single Clock FIFO Only
Use ll level — Turn on this parameter to include the Avalon-MM control and
status register interface.
Avalon-ST Dual Clock FIFO Only
Use sink ll
level
— Turn on this parameter to include the Avalon-MM control and
status register interface in the input clock domain.
Use source ll
level
— Turn on this parameter to include the Avalon-MM control and
status register interface in the output clock domain.
Write pointer
synchronizer
length
2–8 e length of the write pointer synchronizer chain. Setting this
parameter to a higher value leads to better metastability while
increasing the latency of the core.
Read pointer
synchronizer
length
2–8 e length of the read pointer synchronizer chain. Setting this
parameter to a higher value leads to better metastability.
Use Max
Channel
— Turn on this parameter to specify the maximum channel
number.
Max Channel 1–255 Maximum channel number.
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.
13-4 Parameters UG-01085
2016.12.19
Altera Corporation Avalon-ST Single-Clock and Dual-Clock FIFO Cores
Send Feedback
Register Description
e csr interface in the Avalon-ST Single Clock FIFO core provides access to registers. e table below
describes the registers.
Table 13-3: Register Description for Avalon-ST Single-Clock FIFO
32-Bit
Word
Oset
Name Access Reset Description
0fill_level R 0 24-bit FIFO ll level. Bits 24 to 31 are
unused.
1 Reserved — — Reserved for future use.
2 almost_full_threshold RW FIFO
depth–1
Set this register to a value that indicates the
FIFO buer is getting full.
3 almost_empty_threshold RW 0 Set this register to a value that indicates the
FIFO buer is getting empty.
4 cut_through_threshold RW 0 0—Enables store and forward mode.
>0—Enables cut-through mode and
species the minimum of entries in the
FIFO buer before the valid signal on the
Avalon-ST source interface is asserted.
Once the FIFO core starts sending the data
to the downstream component, it
continues to do so until the end of the
packet.
is register applies only when the Use
store and forward parameter is turned on.
5 drop_on_error RW 0 0—Disables drop-on error.
1—Enables drop-on error.
is register applies only when the Use
packet and Use store and forward
parameters are turned on.
e in_csr and out_csr interfaces in the Avalon-ST Dual Clock FIFO core reports the FIFO ll level. e
table below describes the ll level.
Table 13-4: Register Description for Avalon-ST Dual-Clock FIFO
32-Bit
Word
Oset
Name Access Reset
Value
Description
0fill_level R 0 24-bit FIFO ll level. Bits 24 to 31 are unused.
UG-01085
2016.12.19 Register Description 13-5
Avalon-ST Single-Clock and Dual-Clock FIFO Cores Altera Corporation
Send Feedback
32-Bit
Word
Oset
Name Access Reset
Value
Description
1 threshold RW Almost-full threshold in the input port domain;
almost-empty threshold in the output port
domain.
Document Revision History
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.
November 2009 v9.1.0 No change from previous release.
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.
May 2008 v8.0.0 Initial release.
13-6 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon-ST Single-Clock and Dual-Clock FIFO Cores
Send Feedback
MDIO Core 14
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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 conguration and management purposes. e 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. e PHY register addresses are mapped in the MDIO core’s register space and can be
accessed by the host processor via the Avalon® Memory-Mapped (Avalon-MM) interface. is IP core can
also be used with the Altera 10-Gbps Ethernet MAC to realize a fully manageable system.
Functional Description
e 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. e system interconnect fabric connects the Avalon-MM
master and slave interface while a buer 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
csr_address mdio_in
MDIO Core mdio_out
clk
Avalon-MM
Slave
Interface
csr_waitrequest
MDIO
Ports
External PHY
mdc
mdio
csr_read
csr_write
csr_writedata
csr_readdata
reset
mdio_oen
MDIO Buffer
Connection
Altera FPGA
32
32
6
System
Inter-
connect
Fabric
User
Logic
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
MDIO Frame Format (Clause 45)
e MDIO core communicates with the external PHY device using frames. A complete frame is 64 bits
long and consists of 32-bit preamble, 14-bit command, 2-bit bus direction change, and 16-bit data. Each
bit is transferred on the rising edge of the management data clock (MDC). e PHY management
interface supports the standard MDIO specication (IEEE802.3 Ethernet Standard Clause 45).
Figure 14-2: MDIO Frame Format (Clause 45)
Z0 Read
10 Address/Write
PRE ST OP PRTAD DEVAD TA REGAD/Data Idle
00 Address
01 Write
11 Read
32 bits 2 bits 2 bits 5 bits 5 bits 2 bits 16 bits 1 bit
Table 14-1: MDIO Frame Field Descriptions—Clause 45
Field
Name
Description
PRE Preamble. 32 bits of logical 1 sent prior to every transaction.
ST e start of frame for indirect access cycles is indicated by the <00> pattern. is pattern assures
a transition from the default one and identies the frame as an indirect access.
OP e operation code eld indicates the following transaction types:
00 indicates that the frame payload contains the address of the register to access.
01 indicates that the frame payload contains data to be written to the register whose address was
provided in the previous address frame.
11 indicates that the frame is a read operation.
e post-read-increment-address operation <10> is not supported in this frame.
PRTAD e 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 e device address (DEVAD) is 5 bits, allowing 32 unique MDIO manageable devices (MMDs) per
port. Transmission is MSB to LSB.
TA e turnaround time is a 2-bit time spacing between the device address eld and the data eld 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
rst bit time of the turnaround. e 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 rst bit time of the turnaround and a
0 for the second bit time of the turnaround.
14-2 MDIO Frame Format (Clause 45) UG-01085
2016.12.19
Altera Corporation MDIO Core
Send Feedback
Field
Name
Description
REGAD/
Data
e register address (REGAD) or data eld 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 eld contains
the data to be written to the register. For a read frame, the eld contains the contents of the
register. e rst bit transmitted and received is bit 15.
Idle e 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.
MDIO Clock Generation
e MDIO core’s MDC is generated from the Avalon-MM interface clock signal, clk. e MDC_DIVISOR
parameter species the division parameter. For more information about the parameter, refer to the
Parameter section.
e division factor must be dened such that the MDC frequency does not exceed 2.5 MHz.
Interfaces
e MDIO core consists of a single Avalon-MM slave interface. e slave interface performs Avalon-MM
read and write transfers initiated by an Avalon-MM master in the client application logic. e 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 Specications.
Operation
e 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 oset 0x21 to congure the device, port, and register
addresses of the PHY.
2. Issue a write to the MDIO_ACCESS register at address oset 0x20 to generate an MDIO frame and write
the data to the selected PHY device’s register.
Read Operation
Follow the steps below to perform a read operation.
UG-01085
2016.12.19 MDIO Clock Generation 14-3
MDIO Core Altera Corporation
Send Feedback
1. Issue a write to the device register at address oset 0x21 to congure the device, port, and register
addresses of the PHY.
2. Issue a read to the MDIO_ACCESS register at address oset 0x20 to read the selected PHY device’s
register.
Parameter
Table 14-2: Congurable Parameter
Parameter Legal Values Default Value Description
MDC_
DIVISOR
8-64 32 e host clock divisor provides the division factor for the
clock on the Avalon-MM interface to generate the preferred
MDIO clock (MDC). e division factor must be dened
such that the MDC frequency does not exceed 2.5 MHz.
Formula:
For example, if the Avalon-MM interface clock source is
100 MHz and the desired MDC frequency is 2.5 MHz, specify
a value of 40 for the MDC_DIVISOR.
Conguration 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.
Table 14-3: Register Map
Address
Oset
Bit(s) Name Access
Mode
Description
0x00-
0x1F
31:0 Reserved RW Reserved for future use.
0x20 (1) 31:0 MDIO_ACCESS RW Performs a read or write of 32-bit data to the external
PHY device. e addresses of the external PHY device’s
register, device, and port are specied in address oset
0x21.
0x21 (2)
4:0 MDIO_DEVAD RW Contains the device address of the PHY.
7:5 Reserved RW Unused.
12:8 MDIO_PRTAD RW Contains the port address of the PHY.
15:13 Reserved RW Unused.
31:16 MDIO_REGAD RW Contains the register address of the PHY.
14-4 Parameter UG-01085
2016.12.19
Altera Corporation MDIO Core
Send Feedback
Address
Oset
Bit(s) Name Access
Mode
Description
Table 14-3 :
1. e byte address for this register is 0x84.
2. e byte address for this register is 0x80.
Document Revision History
Table 14-4: MDIO Core Revision History
Date Version Changes
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2010 v10.1.0 Revised the register map address oset.
July 2010 v10.0.0 Initial release.
UG-01085
2016.12.19 Document Revision History 14-5
MDIO Core Altera Corporation
Send Feedback
On-Chip FIFO Memory Core 15
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e on-chip FIFO memory core buers data and provides ow control in an Qsys system. e 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.
e 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. e output interface can be an Avalon-ST source or
an Avalon-MM read slave. e 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 ll level of the FIFO core. In dual-clock mode, separate, optional status interfaces
can be included for the input and output interfaces. e status interface also includes registers to set and
control interrupts.
Device drivers are provided in the HAL system library allowing soware to access the core using ANSI C.
Functional Description
e on-chip FIFO memory core has four congurations:
• 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 congurations, the input and output interfaces can use the optional backpressure signals to
prevent underow and overow 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.
Avalon-MM Write Slave to Avalon-MM Read Slave
In this conguration, the input is a zero-address-width Avalon-MM write slave. An Avalon-MM write
master pushes data into the FIFO core by writing to the input interface, and a read master (possibly the
same master) pops data by reading from its output interface. e input and output data must be the same
width.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
If Allow backpressure is turned on, the waitrequest signal is asserted whenever the data_in master tries
to write to a full FIFO buer. waitrequest is only deasserted when there is enough space in the FIFO
buer for a new transaction to complete. waitrequest is asserted for read operations when there is no
data to be read from the FIFO buer, and is deasserted when the FIFO buer has data.
Figure 15-1: FIFO with Avalon-MM Input and Output Interfaces
SAvalon-MM Slave Po rt
On-Chip FIFO
Memory
S S
SS
Wr Rd
Input S tatus I/F
(optiona l) Output Statu s I/F
(optiona l)
sys tem interconne ct fabric
Input dat a Output dat a
Avalon-ST Sink to Avalon-ST Source
is conguration has streaming input and output interfaces as illustrated in the gure below. You can
parameterize most aspects of the Avalon-ST interfaces including the bits per symbol, symbols per beat,
and the width of error and channel signals. e input and output interfaces must be the same width. If
Allow backpressure is turned on, both interfaces use the ready and valid signals to indicate when space
is available in the FIFO core and when valid data is available.
For more information about the Avalon-ST interface protocol, refer to the Avalon Interface Specica‐
tions.
Figure 15-2: FIFO with Avalon-ST Input and Output Interfaces
SNK Avalon-ST Sink
On-Chip FIFO
Memory
S S
SNK SRC
Input S tatu s I/F
(optiona l) Output Statu s I/F
(optiona l)
System Interconn ect Fab ric
Streaming
Output Dat a
SRC Avalon-ST Sou rce
SAvalon-MM Slave Port
Avalon-MM Write Slave to Avalon-ST Source
In this conguration, the input is an Avalon-MM write slave with a width of 32 bits as shown in the FIFO
with Avalon-MM Input Interface and Avalon-ST Output Interface gure below. e Avalon-ST output
15-2 Avalon-ST Sink to Avalon-ST Source UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
(source) data width must also be 32 bits. You can congure output interface parameters, including: bits
per symbol, symbols per beat, and the width of the channel and error signals. e FIFO core performs
the endian conversion to conform to the output interface protocol.
e 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
On-Chip FIFO
Memory
S S
SSRC
Input Statu s I/F
(optional) Output Status I/F
(optional)
system inte rconne ct fabric
Input Da ta Strea ming
Output Data
SRC Avalon-ST Source
SAvalon-MM Slave Port
Table 15-1: Bit Field
Oset 31 24 23 19 18 16 15 13 12 8 7 4 3 2 1 0
base
+ 0
Symbol 3 Symbol 2 Symbol 1 Symbol 0
base
+ 1
reserved reserved error reserve
d
channel reserve
d
empt
y
E
O
P
S
O
P
Table 15-2: Memory Map
Oset Bits Field Description
0 31:0 SYMBOL_0,
SYMBOL_1,
SYMBOL_2 ..
SYMBOL_n
Packet data. e value of the Symbols per beat parameter species
the number of elds in this register; Bits per symbol species the
width of each eld.
UG-01085
2016.12.19 Avalon-MM Write Slave to Avalon-ST Source 15-3
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Oset Bits Field Description
1
0 SOP e value of the startofpacket signal.
1 EOP e value of the endofpacket signal.
6:2 EMPTY e value of the empty signal.
7 — Reserved.
15:8 CHANNEL e value of the channel signal. e number of bits occupied
corresponds to the width of the signal. For example, if the width of
the channel signal is 5, bits 8 to 12 are occupied and bits 13 to 15 are
unused.
23:16 ERROR e value of the error signal. e number of bits occupied
corresponds to the width of the signal. For example, if the width of
the error signal is 3, bits 16 to 18 are occupied and bits 19 to 23 are
unused.
31:24 — Reserved.
If Enable packet data is turned o, the Avalon-MM write master writes all data at address oset 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 oset 1. Writing to
address oset 1 does not push data into the FIFO core. e Avalon-MM master then writes packet data to
address oset 0 repeatedly, pushing 8-bit symbols into the FIFO core. Whenever a valid write occurs at
address oset 0, the data and its respective packet information is pushed into the FIFO core. Subsequent
data is written at address oset 0 without the need to clear the SOP eld. Rewriting to address oset 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 oset 1 to set the EOP bit to 1,
before writing the last symbol of the packet at oset 0. e write master uses the empty eld 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 eld 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 eld will
be 1, indicating that one symbol (the least signicant symbol in the memory map) is empty.
Avalon-ST Sink to Avalon-MM Read Slave
In this conguration seen in the gure below, the input is an Avalon-ST sink and the output is an Avalon-
MM read slave with a width of 32 bits. e Avalon-ST input (sink) data width must also be 32 bits. You
can congure input interface parameters, including: bits per symbol, symbols per beat, and the width of
the channel and error signals. e FIFO core performs the endian conversion to conform to the output
interface protocol.
An Avalon-MM master reads the data from the FIFO core. e signals are mapped into bits in the Avalon
address space. If Allow backpressure is turned on, the input (sink) interface uses the ready and valid
signals to indicate when space is available in the FIFO core and when valid data is available. For the output
interface, waitrequest is asserted for read operations when there is no data to be read from the FIFO
core. It is deasserted when the FIFO core has data to send. e memory map for this conguration is
exactly the same as for the Avalon-MM to Avalon-ST FIFO core. See the for Memory Map table for more
information.
15-4 Avalon-ST Sink to Avalon-MM Read Slave UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Figure 15-4: FIFO with Avalon-ST Input and Avalon-MM Output
On-Chip FIFO
Memory
S S
SNK S
Inpu t Status I/F
(optiona l) Output Sta tus I/F
(opt io na l)
syste m interconnect fabric
Output Data
Strea ming
Input Data
SNK Avalon-ST Sink
SAvalon-MM Slave Port
If Enable packet data is turned o, read data repeatedly at address oset 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 oset 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. e packet status information is obtained by reading at address oset 1. Reading from
address oset 1 does not pop data from the FIFO core. e ERROR, CHANNEL, SOP, EOP and EMPTY elds are
available at address oset 1 to determine the status of the packet data read from address oset 0.
e EMPTY eld indicates the number of empty symbols in the data eld. For example, if the Avalon-ST
interface has symbols-per-beat of 4, and the last packet data only has 1 symbol, the empty eld is 3 to
indicate that 3 symbols (the 3 least signicant symbols in the memory map) are empty.
Status Interface
e 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 sucient 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.
Conguration
e following sections describe the available conguration options.
FIFO Settings
e following sections outline the settings that pertain to the FIFO core as a whole.
UG-01085
2016.12.19 Status Interface 15-5
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Depth
Depth indicates the depth of the FIFO buer, in Avalon-ST beats or Avalon-MM words. e default depth
is 16. When dual clock mode is used, the actual FIFO depth is equal to depth-3. is is due to clock
crossing and to avoid FIFO overow.
Clock Settings
e 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
e 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
is option determines if the FIFO core is built from registers or embedded memory blocks. e default is
to construct the FIFO core from embedded memory blocks.
Interface Parameters
e 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 buer or reading from an empty FIFO buer. An
Avalon-ST interface includes the ready and valid signals to prevent underow and overow conditions.
Avalon-MM Port Settings
Valid Data widths are 8, 16, and 32 bits.
If Avalon-MM is selected for one interface and Avalon-ST for the other, the data width is xed at 32 bits.
e Avalon-MM interface accesses data 4 bytes at a time. For data widths other than 32 bits, be careful of
potential overow and underow conditions.
15-6 Interface Parameters UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Avalon-ST Port Settings
e following parameters allow you to specify the size and error handling of the Avalon-ST port or ports:
•Bits per symbol
•Symbols per beat
•Channel width
•Error width
If the symbol size is not a power of two, it is rounded up to the next power of two. For example, if the
bits per symbol is 10, the symbol will be mapped to a 16-bit memory location. With 10-bit symbols,
the maximum number of symbols per beat is two.
Enable packet data provides an option for packet transmission.
Software Programming Model
e following sections describe the soware programming model for the on-chip FIFO memory core,
including the register map and soware declarations to access the hardware. For Nios II processor users,
Altera provides HAL system library drivers that enable you to access the on-chip FIFO memory core using
its HAL API.
HAL System Library Support
e Altera-provided driver implements a HAL device driver that integrates into the HAL system library
for Nios II systems. HAL users should access the on-chip FIFO memory via the familiar HAL API, rather
than accessing the registers directly.
Software Files
Altera provides the following soware les for the on-chip FIFO memory core:
•altera_avalon_fifo_regs.h—is le denes the core's register map, providing symbolic
constants to access the low-level hardware.
•altera_avalon_fifo_util.h—is le denes functions to access the on-chip FIFO memory
core hardware. It provides utilities to initialize the FIFO, read and write status, enable ags and read
events.
•altera_avalon_fifo.h—is le provides the public interface to the on-chip FIFO memory
•altera_avalon_fifo_util.c—is le implements the utilities listed in altera_avalon_
fifo_util.h.
Programming with the On-Chip FIFO Memory
is section describes the low-level soware constructs for manipulating the on-chip FIFO memory core
hardware. e table below lists all of the available functions.
Table 15-3: On-Chip FIFO Memory Functions
Function Name Description
altera_avalon_fifo_init() Initializes the FIFO.
UG-01085
2016.12.19 Software Programming Model 15-7
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Function Name Description
altera_avalon_fifo_read_status() Returns the integer value of the specied bit of the
status register. To read all of the bits at once, use
the ALTERA_AVALON_FIFO_STATUS_ALL mask.
altera_avalon_fifo_read_ienable() Returns the value of the specied bit of the
interrupt enable register. To read all of the bits at
once, use the ALTERA_AVALON_FIFO_EVENT_ALL
mask.
altera_avalon_fifo_read_almostfull() Returns the value of the almostfull register.
altera_avalon_fifo_read_almostempty() Returns the value of the almostempty register.
altera_avalon_fifo_read_event() Returns the value of the specied bit of the event
register. All of the event bits can be read at once
by using the ALTERA_AVALON_FIFO_STATUS_ALL
mask.
altera_avalon_fifo_read_level() Returns the ll level of the FIFO.
altera_avalon_fifo_clear_event() Clears the specied bits and the event register and
performs error checking.
altera_avalon_fifo_write_ienable() Writes the specied bits of the interruptenable
register and performs error checking.
altera_avalon_fifo_write_almostfull() Writes the specied value to the almostfull
register and performs error checking.
altera_avalon_fifo_write_
almostempty()
Writes the specied value to the almostempty
register and performs error checking.
altera_avalon_fifo_write_fifo() Writes the specied data to the write_address.
altera_avalon_fifo_write_other_info() Writes the packet status information to the
write_address. Only valid when the Enable
packet data option is turned on.
altera_avalon_fifo_read_fifo() Reads data from the specied read_address.
altera_avalon_fifo_read__other_info() Reads the packet status information from the
specied read_address. Only valid when the
Enable packet data option is turned on.
Software Control
e table below provides the register map for the status register. e layout of status register for the
input and output interfaces is identical.
Table 15-4: FIFO Status Register Memory Map
oset 31 24 23 16 15 8 7 6 5 4 3 2 1 0
base fill_level
base + 1 i_status
base + 2 event
15-8 Software Control UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
base + 3 interrupt
enable
base + 4 almostfull
base + 5 almostempty
e table below outlines the use of the various elds of the
Table 15-5: FIFO Status Field Descriptions
Field Type Description
fill_level RO e instantaneous ll level of the FIFO, provided in units of symbols for
a FIFO with an Avalon-ST FIFO and words for an Avalon-MM FIFO.
i_status RO A 6-bit register that shows the FIFO’s instantaneous status. See Status
Bit Field Description Table for the meaning of each bit eld.
event RW1
C
A 6-bit register with exactly the same elds as i_status. When a bit in
the i_status register is set, the same bit in the event register is set. e
bit in the event register is only cleared when soware writes a 1 to that
bit.
interrupten-
able
RW A 6-bit interrupt enable register with exactly the same elds as the event
and i_status registers. When a bit in the event register transitions from
a 0 to a 1, and the corresponding bit in interruptenable is set, the
master Is interrupted.
almostfull RW A threshold level used for interrupts and status. Can be written by the
Avalon-MM status master at any time. e default threshold value for
DCFIFO is Depth-4. e default threshold value for SCFIFO is Depth-1.
e valid range of the threshold value is from 1 to the default. 1 is used
when attempting to write a value smaller than 1. e default is used
when attempting to write a value larger than the default.
almostempty RW A threshold level used for interrupts and status. Can be written by the
Avalon-MM status master at any time. e default threshold value for
DCFIFO is 1. e default threshold value for SCFIFO is 1. e valid
range of the threshold value is from 1 to the maximum allowable
almostfull threshold. 1 is used when attempting to write a value
smaller than 1. e maximum allowable is used when attempting to
write a value larger than the maximum allowable.
status register.
Table 15-6: Status Bit Field Descriptions
Bit(s) Name Description
0FULL Has a value of 1 if the FIFO is currently full.
1EMPTY Has a value of 1 if the FIFO is currently empty.
2ALMOSTFULL Has a value of 1 if the ll level of the FIFO is equal or greater than the
almostfull value.
UG-01085
2016.12.19 Software Control 15-9
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Bit(s) Name Description
3ALMOSTEMPTY Has a value of 1 if the ll level of the FIFO is less or equal than the
almostempty value.
4OVERFLOW Is set to 1 for 1 cycle every time the FIFO overows. e FIFO overows
when an Avalon write master writes to a full FIFO. OVERFLOW is only
valid when Allow backpressure is o.
5UNDERFLOW Is set to 1 for 1 cycle every time the FIFO underows. e FIFO
underows when an Avalon read master reads from an empty FIFO.
UNDERFLOW is only valid when Allow backpressure is o.
ese elds are identical to those in the status register and are set at the same time; however, these elds
are only cleared when soware writes a one to clear (W1C). e event elds can be used to determine if a
particular event has occurred.
Table 15-7: Event Bit Field Descriptions
Bit(s) Name Description
0E_FULL Has a value of 1 if the FIFO has been full and the bit has not been
cleared by soware.
1E_EMPTY Has a value of 1 if the FIFO has been empty and the bit has not been
cleared by soware.
2E_ALMOSTFULL Has a value of 1 if the ll level of the FIFO has been greater than the
almostfull threshold value and the bit has not been cleared by
soware.
3E_ALMOSTEMPTY Has a value of 1 if the ll level of the FIFO has been less than the
almostempty value and the bit has not been cleared by soware.
4E_OVERFLOW Has a value of 1 if the FIFO has overowed and the bit has not been
cleared by soware.
5E_UNDERFLOW Has a value of 1 if the FIFO has underowed and the bit has not been
cleared by soware.
e table below provides a mask for the six STATUS elds. 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.
Table 15-8: InterruptEnable Bit Field Descriptions
Bit(s) Name Description
0IE_FULL Enables an interrupt if the FIFO is currently full.
1IE_EMPTY Enables an interrupt if the FIFO is currently empty.
2IE_ALMOSTFULL Enables an interrupt if the ll level of the FIFO is greater than the value
of the almostfull register.
3IE_ALMOSTEMPTY Enables an interrupt if the ll level of the FIFO is less than the value of
the almostempty register.
15-10 Software Control UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Bit(s) Name Description
4IE_OVERFLOW Enables an interrupt if the FIFO overows. e FIFO overows when
an Avalon write master writes to a full FIFO.
5IE_UNDERFLOW Enables an interrupt if the FIFO underows. e FIFO underows
when an Avalon read master reads from an empty FIFO.
6ALL Enables all 6 status conditions to interrupt.
Macros to access all of the registers are dened in altera_avalon_fo_regs.h. For example, this le
includes the following macros to access the status register.
#dene ALTERA_AVALON_FIFO_LEVEL_REG 0
#dene ALTERA_AVALON_FIFO_STATUS_REG 1
#dene ALTERA_AVALON_FIFO_EVENT_REG 2
#dene ALTERA_AVALON_FIFO_IENABLE_REG 3
#dene ALTERA_AVALON_FIFO_ALMOSTFULL_REG 4
#dene ALTERA_AVALON_FIFO_ALMOSTEMPTY_REG 5
For a complete list of predened 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_fo
\HAL\inc\
alatera_avalon_fo_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. */
UG-01085
2016.12.19 Software Example 15-11
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
*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;
}
On-Chip FIFO Memory API
is section describes the application programming interface (API) for the on-chip FIFO memory core.
altera_avalon_fo_init()
Prototype:int altera_avalon_fifo_init(alt_u32 address, alt_u32 ienable, alt_
u32 emptymark, alt_u32 fullmark)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
ienable—the value to write to the interruptenable register
emptymark—the value for the almost empty threshold level
fullmark—the value for the almost full threshold level
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_
EVENT_CLEAR_ERROR for clear errors, ALTERA_AVALON_FIFO_IENABLE_WRITE_
ERROR for interrupt enable write errors, ALTERA_AVALON_FIFO_THRESHOLD_
WRITE_ERROR for errors writing the almostfull and almostempty registers.
15-12 On-Chip FIFO Memory API UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Description: Clears the event register, writes the interruptenable register, and sets the
almostfull register and almostempty registers.
altera_avalon_fo_read_status()
Prototype: int altera_avalon_fifo_read_status(alt_u32 address, alt_u32 mask)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
mask—masks the read value from the status register
Returns: Returns the masked bits of the addressed register.
Description: Gets the addressed register bits—the AND of the value of the addressed register
and the mask.
altera_avalon_fo_read_ienable()
Prototype: int altera_avalon_fifo_read_ienable(alt_u32 address, alt_u32 mask)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
mask—masks the read value from the interruptenable register
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_fo_read_almostfull()
Prototype: int altera_avalon_fifo_read_almostfull(alt_u32 address)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
UG-01085
2016.12.19 altera_avalon_fo_read_status() 15-13
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Parameters: address—the base address of the FIFO control slave
Returns: Returns the value of the almostfull register.
Description: Gets the value of the almostfull register.
altera_avalon_fo_read_almostempty()
Prototype: int altera_avalon_fifo_read_almostempty(alt_u32 address)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
Returns: Returns the value of the almostempty register.
Description: Gets the value of the almostempty register.
altera_avalon_fo_read_event()
Prototype: int altera_avalon_fifo_read_event(alt_u32 address, alt_u32 mask)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
mask—masks the read value from the event register
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_fo_read_level()
Prototype: int altera_avalon_fifo_read_level(alt_u32 address)
read-safe: No.
15-14 altera_avalon_fo_read_almostempty() UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
Returns: Returns the ll level of the FIFO.
Description: Gets the ll level of the FIFO.
altera_avalon_fo_clear_event()
Prototype: int altera_avalon_fifo_clear_event(alt_u32 address, alt_u32 mask)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
mask—the mask to use for bit-clearing (1 means clear this bit, 0 means do not
clear)
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_
EVENT_CLEAR_ERROR if unsuccessful.
Description: Clears the specied bits of the event register.
altera_avalon_fo_write_ienable()
Prototype: int altera_avalon_fifo_write_ienable(alt_u32 address, alt_u32
mask)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
mask—the value to write to the interruptenable register. See altera_avalon_
fo_regs.h for individual interrupt bit masks.
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_
IENABLE_WRITE_ERROR if unsuccessful.
Description: Writes the specied bits of the interruptenable register.
UG-01085
2016.12.19 altera_avalon_fo_clear_event() 15-15
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
altera_avalon_fo_write_almostfull()
Prototype: int altera_avalon_fifo_write_almostfull(alt_u32 address, alt_u32
data)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
data—the value for the almost full threshold level
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_
THRESHOLD_WRITE_ERROR if unsuccessful.
Description: Writes data to the almostfull register.
altera_avalon_fo_write_almostempty()
Prototype: int altera_avalon_fifo_write_almostempty(alt_u32 address, alt_u23
data)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: address—the base address of the FIFO control slave
data—the value for the almost empty threshold level
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_
THRESHOLD_WRITE_ERROR if unsuccessful.
Description: Writes data to the almostempty register.
altera_avalon_write_fo()
Prototype: int altera_avalon_write_fifo(alt_u32 write_address, alt_u32 ctrl_
address, alt_u32 data)
read-safe: No.
Available from
ISR:
No.
15-16 altera_avalon_fo_write_almostfull() UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: write_address—the base address of the FIFO write slave
ctrl_address—the base address of the FIFO control slave
data—the value to write to address oset 0 for Avalon-MM to Avalon-ST
transfers, the value to write to the single address available for Avalon-MM to
Avalon-MM transfers. See the Avalon Interface Specications section for the
data ordering.
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_FULL
if unsuccessful.
Description: Writes data to the specied address if the FIFO is not full.
altera_avalon_write_other_info()
Prototype: int altera_avalon_write_other_info(alt_u32 write_address, alt_u32
ctrl_address, alt_u32 data)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: write_address—the base address of the FIFO write slave
ctrl_address—the base address of the FIFO control slave
data—the packet status information to write to address oset 1 of the Avalon
interface. See the Avalon Interface Specications section for the ordering of the
packet status information.
Returns: Returns 0 (ALTERA_AVALON_FIFO_OK) if successful, ALTERA_AVALON_FIFO_FULL
if unsuccessful.
Description: Writes the packet status information to the write_address. Only valid when
Enable packet data is on.
altera_avalon_fo_read_fo()
Prototype: int altera_avalon_fifo_read_fifo(alt_u32 read_address, alt_u32
ctrl_address)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
UG-01085
2016.12.19 altera_avalon_write_other_info() 15-17
On-Chip FIFO Memory Core Altera Corporation
Send Feedback
Parameters: read_address—the base address of the FIFO read slave
ctrl_address—the base address of the FIFO control slave
Returns: Returns the data from address oset 0, or 0 if the FIFO is empty.
Description: Gets the data addressed by read_address.
R**altera_avalon_fo_read_other_info()
Prototype: int altera_avalon_fifo_read_other_info(alt_u32 read_address)
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_fo_regs.h>, <altera_avalon_fo_utils.h>
Parameters: read_address—the base address of the FIFO read slave
Returns: Returns the packet status information from address oset 1 of the Avalon
interface. See the Avalon Interface Specications section for the ordering of the
packet status information.
Description: Reads the packet status information from the specied read_address. Only
valid when Enable packet data is on.
Document Revision History
Table 15-9: On-Chip FIFO Memory Core 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.
July 2010 v10.0.0 Revised the description of the memory map.
November 2009 v9.1.0 Added description to the core overview.
March 2009 v9.0.0 Updated the description of the function altera_avalon_fifo_read_
status().
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
15-18 Document Revision History UG-01085
2016.12.19
Altera Corporation On-Chip FIFO Memory Core
Send Feedback
Avalon-ST Multi-Channel Shared Memory FIFO
Core 16
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon Streaming (Avalon-ST) Multi-Channel Shared Memory FIFO core is a FIFO buer with
Avalon-ST data interfaces. e 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.
e example below shows an example of how the core is used in a system. In this example, the core is used
to buer 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 System—An Example
a
F
t
c
e
n
n
o
c
r
e
t
n
I
m
e
t
s
y
Sbc
i
r
Rest of the
System
Altera
FPGA
Mux
Port 0
Port 1
Port 2
Port 3
Channel 0
Channel 1
Channel 2
Channel 3
Processor/
Scheduler
Multi-port
Triple Speed Ethernet
Multi-Channel
Shared Memory FIFO
(Receive FIFO buffer)
From
Network
Demux
Performance and Resource Utilization
is section lists the resource utilization and performance data for various Altera device families. e
estimates are obtained by compiling the core using the Quartus Prime soware.
e table below shows the resource utilization and performance data for a Stratix II GX device
(EP2SGX130GF1508I4).
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Table 16-1: Memory Utilization and Performance Data for Stratix II GX Devices
Channels ALUTs Logic
Registers
Memory Blocks fMAX
(MHz)
M512 M4K M-RAM
4 559 382 0 0 1 > 125
12 1617 1028 0 0 6 > 125
e table below shows the resource utilization and performance data for a Stratix III device
(EP3SL340F1760C3). e 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
Channels ALUTs Logic
Registers
Memory Blocks fMAX
(MHz)
M9K M144K MLAB
4 557 345 37 0 0 > 125
12 1741 1028 0 24 0 > 125
e 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
Elements
Total Registers Memory
M9K
fMAX
(MHz)
4 711 346 37 > 125
12 2284 1029 412 > 125
16-2 Performance and Resource Utilization UG-01085
2016.12.19
Altera Corporation Avalon-ST Multi-Channel Shared Memory FIFO Core
Send Feedback
Functional Description
Figure 16-2: Avalon-ST Multi-Channel Shared Memory FIFO Core
Avalon-ST
Status Source Avalon-ST
Status Source
Multi-Channel Shared FIFO
lluf_tsomlaytpme_tsomla
out
contro l fill_level request
in
Avalon-MM
Slave Avalon-MM
Status Avalon-MM
Status
Avalon-ST
Data Sink Avalon-ST
Data Source
Interfaces
is section describes the core's interfaces.
Avalon-ST Interfaces
e core includes Avalon-ST interfaces for transferring data and almost-full status.
Table 16-4: Properties of Avalon-ST Interfaces
Feature
Property
Data Interfaces Status Interfaces
Backpressure Ready latency = 0. Not supported.
Data Width Congurable. Data width = 2 bits.
Symbols per beat = 1.
Channel Supported, up to 16 channels. Supported, up to 16 channels.
Error Congurable. Not used.
Packet Supported. Not supported.
UG-01085
2016.12.19 Functional Description 16-3
Avalon-ST Multi-Channel Shared Memory FIFO Core Altera Corporation
Send Feedback
Avalon-MM Interfaces
e core can have up to three Avalon-MM interfaces:
•Avalon-MM control interface—Allows master peripherals to set and access almost-full and almost-
empty thresholds. e same set of thresholds is used by all channels. See Control Interface Register
Map gure for the description of the threshold registers.
•Avalon-MM ll-level interface—Allows master peripherals to retrieve the ll level of the FIFO buer
for a given channel. e ll level represents the amount of data in the FIFO buer at any given time.
e read latency on this interface is one. See the Fill-level Interface Register Map table for the descrip‐
tion of the ll-level registers.
•Avalon-MM request interface—Allows master peripherals to request data for a given channel. is
interface is implemented only when the Use Request parameter is turned on. e 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 Specications.
Operation
e 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. e
parameter FIFO depth determines the depth of each memory segment.
e 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. e 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 congure 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 congure almost-full thresholds to manage FIFO overow. e 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
Table 16-5: Congurable Parameters
Parameter Legal Values Description
Number of channels 1, 2, 4, 8, and
16
e total number of channels supported on the Avalon-
ST data interfaces.
Symbols per beat 1–32 e number of symbols transferred in a beat on the
Avalon-ST data interfaces
Bits per symbol 1–32 e symbol width in bits on the Avalon-ST data
interfaces.
16-4 Operation UG-01085
2016.12.19
Altera Corporation Avalon-ST Multi-Channel Shared Memory FIFO Core
Send Feedback
Parameter Legal Values Description
Error width 0–32 e width of the error signal on the Avalon-ST data
interfaces.
FIFO depth 2–232 e depth of each memory segment allocated for a
channel. e value must be a multiple of 2.
Use packets 0 or 1 Setting this parameter to 1 enables packet support on the
Avalon-ST data interfaces.
Use ll level 0 or 1 Setting this parameter to 1 enables the Avalon-MM status
interface.
Number of almost-full
thresholds
0 to 2 e number of almost-full thresholds to enable. Setting
this parameter to 1 enables Use almost-full threshold 1.
Setting it to 2 enables both Use almost-full threshold 1
and Use almost-full threshold 2.
Number of almost-
empty thresholds
0 to 2 e number of almost-empty thresholds to enable.
Setting this parameter to 1 enables Use almost-empty
threshold 1. Setting it to 2 enables both Use almost-
empty threshold 1 and Use almost-empty threshold 2.
Section available
threshold
0 to 2 Address
Width
Specify the amount of data to be delivered to the output
interface. is parameter applies only when packet
support is disabled.
Packet buer mode 0 or 1 Setting this parameter to 1 causes the core to deliver only
full packets to the output interface. is parameter
applies only when Use packets is set to 1.
Drop on error 0 or 1 Setting this parameter to 1 causes the core to drop
packets at the Avalon-ST data sink interface if the error
signal on that interface is asserted. Otherwise, the core
accepts the packet and sends it out on the Avalon-ST data
source interface with the same error. is parameter
applies only when packet buer mode is enabled.
Address width 1–32 e width of the FIFO address. is parameter is
determined by the parameter FIFO depth; FIFO depth =
2 Address Width.
Use request — Turn on this parameter to implement the Avalon-MM
request interface. If the core is congured to support
more than one channel and the request interface is
disabled, only channel 0 is accessible.
UG-01085
2016.12.19 Parameters 16-5
Avalon-ST Multi-Channel Shared Memory FIFO Core Altera Corporation
Send Feedback
Parameter Legal Values Description
Use almost-full
threshold 1
—
Turn on these parameters to implement the optional
Avalon-ST almost-full and almost-empty interfaces and
their corresponding registers. See Control Interface
Register Map for the description of the threshold
registers.
Use almost-full
threshold 2
—
Use almost-empty
threshold 1
—
Use almost-empty
threshold 2
—
Use almost-full
threshold 1
0 or 1 is threshold indicates that the FIFO is almost full. It is
enabled when the parameter Number of almost-full
threshold is set to 1 or 2.
Use almost-full
threshold 2
0 or 1 is threshold is an initial indication that the FIFO is
getting full. It is enabled when the parameter Number of
almost-full threshold is set to 2.
Use almost-empty
threshold 1
0 or 1 is threshold indicates that the FIFO is almost empty. It
is enabled when the parameter Number of almost-empty
threshold is set to 1 or 2.
Use almost-empty
threshold 2
0 or 1 is threshold is an initial indication that the FIFO is
getting empty. It is enabled when the parameter Number
of almost-empty threshold is set to 2.
Software Programming Model
e following sections describe the soware programming model for the Avalon-ST Multi-Channel
Shared FIFO core.
HAL System Library Support
e Altera-provided driver implements a HAL device driver that integrates into the HAL system library
for Nios II systems. HAL users should access the Avalon-ST Multi-Channel Shared FIFO core via the
familiar HAL API and the ANSI C standard library.
Register Map
You can congure the thresholds and retrieve the ll-level for each channel via the Avalon-MM control
and ll-level interfaces respectively. Subsequent sections describe the registers accessible via each interface.
16-6 Software Programming Model UG-01085
2016.12.19
Altera Corporation Avalon-ST Multi-Channel Shared Memory FIFO Core
Send Feedback
Control Register Interface
Table 16-6: Control Interface Register Map
Byte
Oset
Name Access Reset
Value
Description
0ALMOST_FULL_THRESHOLD RW 0 Primary almost-full threshold. e bit Almost_
full_data[0] on the Avalon-ST almost-full status
interface is set to 1 when the FIFO level is equal to
or greater than this threshold.
4 ALMOST_EMPTY_
THRESHOLD
RW 0 Primary almost-empty threshold. e bit Almost_
empty_data[0] on the Avalon-ST almost-empty
status interface is set to 1 when the FIFO level is
equal to or less than this threshold.
8ALMOST_FULL2_THRESHOLD RW 0 Secondary almost-full threshold. e bit Almost_
full_data[1] on the Avalon-ST almost-full status
interface is set to 1 when the FIFO level is equal to
or greater than this threshold.
12 ALMOST_EMPTY2_
THRESHOLD
RW 0 Secondary almost-empty threshold. e bit
Almost_empty_data[1] on the Avalon-ST almost-
empty status interface is set to 1 when the FIFO
level is equal to or less than this threshold.
Base
+ 8
Almost_Empty_Threshold RW e value of the primary almost-empty threshold.
e bit Almost_empty_data[0] on the Avalon-ST
almost-empty status interface is set to 1 when the
FIFO level is greater than or equal to this
threshold.
Base
+ 12
Almost_Empty2_Threshold RW e value of the secondary almost-empty
threshold. e bit Almost_empty_data[1] Avalon-
ST almost-empty status interface is set to 1 when
the FIFO level is greater than or equal to this
threshold.
Fill-Level Register Interface
e table below shows the register map for the ll-level interface.
Table 16-7: Fill-level Interface Register Map
Byte
Oset
Name Access Reset
Value
Description
0ll_level_0 RO 0
Fill level for each channel. Each register is dened
for each channel. For example, if the core is
congured to support four channel, four ll-level
registers are dened.
4ll_level_1 RO 0
8ll_level_2 RO 0
(n*4
)
ll_level_n RO 0
UG-01085
2016.12.19 Register Map 16-7
Avalon-ST Multi-Channel Shared Memory FIFO Core Altera Corporation
Send Feedback
Document Revision History
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 ll-level
registers. Revised the Operation section.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Initial release.
16-8 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon-ST Multi-Channel Shared Memory FIFO Core
Send Feedback
SPI Slave/JTAG to Avalon Master Bridge Cores 17
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e cores support reads and writes, but not burst transactions.
Functional Description
Figure 17-1: System with a SPI Slave to Avalon Master Bridge Core
a
F
t
c
e
n
n
o
c
r
e
t
n
I
m
e
t
s
y
Sbc
i
r
Rest of the
System
SPI
Master
(Example:
Po wer PC
Processor)
Altera FPGA
SPI to Transaction Bridge
src
k
n
i
s
Avalon-ST
Bytes to
Packets
Converter
src
k
n
i
s
Avalon-ST
Packets to
Transactions
Converter
Avalon-MM Master
src
Avalon-ST
Source
sink
Avalon-ST
Sink
src
k
n
i
s
Avalon-ST
P
ackets to
Bytes
Converter
Avalon-ST
SPI Core
SPI
src
k
n
i
s
SPI
ClockClock System
Clock
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 17-2: System with a JTAG to Avalon Master Bridge Core
a
F
t
c
e
n
n
o
c
r
e
t
n
I
m
e
t
s
y
Sbc
i
r
Rest of the
System
Host
PC
Altera FPGA
JTAG to Transaction Bridge
src
k
n
i
s
Avalon-ST
Bytes to
Packets
Converter
src
k
n
i
s
Avalon-ST
Packets to
Transactions
Converter
Avalon-MM
src
Avalon-ST
Source
sink
Avalon-ST
Sink
src
k
n
i
s
Avalon-ST
Single Clock
FIFO
(64 bytes)
src
k
n
i
s
Avalon-ST
Packets to
Bytes
Converter
Avalon-ST
JTAG
Interface
Core
G
A
T
J
src
k
n
i
s
JTAG
Clock
JTAG
Clock System
Clock
e 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 Interface—Accepts incoming data in bits
and packs them into bytes.
•Avalon-ST Bytes to Packets Converter—Transforms packets into encoded stream of bytes, and a
likewise encoded stream of bytes into packets.
•Avalon-ST Packets to Transactions Converter—Transforms packets with data encoded according to a
specic protocol into Avalon-MM transactions, and encodes the responses into packets using the same
protocol.
•Avalon-ST Single Clock FIFO—Buers data from the Avalon-ST JTAG Interface core. e 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.
e following example shows how a bytestream changes as it is transferred through the dierent layers
in the bridges.
Figure 17-3: Bits to Avalon-MM Transaction
00 00 00 047A 7C 00 02 4B 5A 407D 6A FF 03 5F7B4A 4A 4A 4D
00 00 00 04 02 4B 7A 40 4A FF 03 5F
Comma nd Addres s Data
Writes four bytes of data (4A, FF, 03 an d
5F) to add ress 0x024 B7A40
Packet Layer
Input: Bytes
Outp ut: Avalon-ST
Packet s
Trans action Layer
Input: Avalon-ST
Pack ets
Output: Avalon-MM
Tran saction
00 00 00 047A 7C 00 02 4B 5A 407D 4A FF 03 5F7B
LSB MSB
Idle Idle Idle Esca pe
Dropp ed
Esca pe is droppe d.
Next byte is XORe d
with 0x20.
Phys ical Layer
Input: Bits
Output: Bytes
SO P Ch 0 Escap e
Esc ape is dropped.
Next byte is XORed
with 0x20.
EOP
Bytes ca rried over
the physical interface
after idles and esc apes
have been inse rted.
The p acket enc ode d
as byt e s.
The trans action
en caps ulated as a
pack et.
The Avalon-MM
transact ion.
17-2 Functional Description UG-01085
2016.12.19
Altera Corporation SPI Slave/JTAG to Avalon Master Bridge Cores
Send Feedback
When the transaction is complete, the bridges send a response to the host system using the same protocol.
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. ese register chains are used when a
metastable event is likely to occur and the length specied determines the meantime before failure. e
register chain length, however, aects 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.
Document Revision History
Table 17-1: SPI Slave/JTAG to Avalon Master Bridge 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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 Added description of a new parameter Number of synchronizer
stages: Depth.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Initial release.
UG-01085
2016.12.19 Parameters 17-3
SPI Slave/JTAG to Avalon Master Bridge Cores Altera Corporation
Send Feedback
Avalon Streaming Channel Multiplexer and
Demultiplexer Cores 18
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e 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.
e multiplexer and demultiplexer can transfer data between interfaces on cores that support the unidirec‐
tional ow of data. e multiplexer and demultiplexer allow you to create multiplexed or de-multiplexer
datapaths without having to write custom HDL code to perform these functions. e multiplexer includes
a round-robin scheduler. Both cores are SOPC Builder-ready and integrate easily into any SOPC Builder-
generated system. is chapter contains the following sections:
Resource Usage and Performance
Resource utilization for the cores depends upon the number of input and output interfaces, the width of
the datapath and whether the streaming data uses the optional packet protocol. For the multiplexer, the
parameterization of the scheduler also eects resource utilization.
Table 18-1: Multiplexer Estimated Resource Usage and Performance
No. of
Inputs
Data
Width
Schedulin
g Size
(Cycles)
Stratix® II and
Stratix II GX
(Approximate LEs)
Cyclone® II Stratix
fMAX
(MHz)
ALM
Count
fMAX
(MHz)
Logic
Cells
fMAX
(MHz)
Logic Cells
2 Y 1 500 31 420 63 422 80
2 Y 2 500 36 417 60 422 58
2 Y 32 451 43 364 68 360 49
8 Y 2 401 150 257 233 228 298
8 Y 32 356 151 219 207 211 123
16 Y 2 262 333 174 533 170 284
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
No. of
Inputs
Data
Width
Schedulin
g Size
(Cycles)
Stratix® II and
Stratix II GX
(Approximate LEs)
Cyclone® II Stratix
fMAX
(MHz)
ALM
Count
fMAX
(MHz)
Logic
Cells
fMAX
(MHz)
Logic Cells
16 Y 32 310 337 161 471 157 277
2 N 1 500 23 400 48 422 52
2 N 9 500 30 420 52 422 56
11 N 9 292 275 197 397 182 287
16 N 9 262 295 182 441 179 224
e core operating frequency varies with the device, the number of interfaces and the size of the datapath.
Table 18-2: Demultiplexer Estimated Resource Usage
No. of Inputs
Data Width
(Symbols
per Beat)
Stratix II
(Approximate LEs)
Cyclone II Stratix II GX
(Approximate LEs)
fMAX
(MHz)
ALM Count fMAX
(MHz)
Logic Cells fMAX
(MHz)
Logic Cells
2 1 500 53 400 61 399 44
15 1 349 171 235 296 227 273
16 1 363 171 233 294 231 290
2 2 500 85 392 97 381 71
15 2 352 247 213 450 210 417
16 2 328 280 218 451 222 443
Multiplexer
is section describes the hardware structure and functionality of the multiplexer component.
Functional Description
e Avalon-ST multiplexer takes data from a number of input data interfaces, and multiplexes the data
onto a single output interface. e 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 dierent
input interface.
e 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
18-2 Multiplexer UG-01085
2016.12.19
Altera Corporation Avalon Streaming Channel Multiplexer and Demultiplexer Cores
Send Feedback
(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. ese bits are appended to either the most or least signicant bits of the output channel signal as
specied in the SOPC Builder MegaWizard™ interface.
Figure 18-1: Multiplexer
src
sink
da ta_ in_n
sink
data_in0
da ta_o ut
. . .
Round Robin, Burst
Aware Sche duler
(optiona l)
sink
sink
. . .
channe l
e 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:
•e specied number of cycles have elapsed.
•e 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. e input interfaces
are identical; they have the same symbol and data widths, error widths, and channel widths.
Output Interface
e output interface carries the multiplexed data stream with data from all of the inputs. e symbol, data,
and error widths are the same as the input interfaces. e 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
e following sections list the available options in the MegaWizard™ interface.
UG-01085
2016.12.19 Parameters 18-3
Avalon Streaming Channel Multiplexer and Demultiplexer Cores Altera Corporation
Send Feedback
Functional Parameters
You can congure the following options for the multiplexer:
•Number of Input Ports—e number of input interfaces that the multiplexer supports. Valid values
are 2–16.
•Scheduling Size (Cycles)—e number of cycles that are sent from a single channel before changing to
the next channel.
•Use Packet Scheduling—When 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 port—When 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 congure the following options for the output interface:
•Data Bits Per Symbol—e number of bits per symbol for the input and output interfaces. Valid values
are 1–32 bits.
•Data Symbols Per Beat—e number of symbols (words) that are transferred per beat (transfer). Valid
values are 1–32.
•Include Packet Support—Indicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
•Channel Signal Width (bits)—e 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. e input channel can have a width between 0–31 bits. A value
of 0 means that the optional channel signal is not used.
•Error Signal Width (bits)—e width of the error signal for input and output interfaces. A value of 0
means the error signal is not used.
Demultiplexer
is section describes the hardware structure and functionality of the demultiplexer component.
Functional Description
at 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 specied by the
input channel signal. e 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 dierent output interface. e 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.
18-4 Demultiplexer UG-01085
2016.12.19
Altera Corporation Avalon Streaming Channel Multiplexer and Demultiplexer Cores
Send Feedback
Figure 18-2: Demultiplexer
sink
da ta_ou t_n
da ta_ou t0
sink
sink
data_in
src
src
. . .
. . .
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. e
symbol, data, and error widths are the same as the input interface. e width of the channel signal is the
same as the input interface, without the bits that were used to select the output interface.
Parameters
e following sections list the available options in the MegaWizard Interface.
Functional Parameters
You can congure the following options for the demultiplexer as a whole:
•Number of Output Ports—e number of output interfaces that the multiplexer supports Valid values
are 2–16.
•High channel bits select output—When 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 o, the low order bits are used and the high order bits are passed through.
e following example illustrates the signicance of the location of these signals. In the Select Bits for
Demltiplexer gure 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 0–7 goes to channel 0 and channels 8–15 goes to channel 1.
UG-01085
2016.12.19 Parameters 18-5
Avalon Streaming Channel Multiplexer and Demultiplexer Cores Altera Corporation
Send Feedback
Figure 18-3: Select Bits for Demultiplexer
sink
data _out1
data_out0
sink
sink
da ta_in
src
src
cha nne l<4..0>
cha nne l<3..0>
cha nne l<3..0>
Input Interface
You can congure the following options for the input interface:
•Data Bits Per Symbol—e number of bits per symbol for the input and output interfaces. Valid values
are 1 to 32 bits.
•Data Symbols Per Beat—e number of symbols (words) that are transferred per beat (transfer). Valid
values are 1 to 32.
•Include Packet Support—Indicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
•Channel Signal Width (bits)—e 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)—e width of the error signal for input and output interfaces. A value of 0
means the error signal is not unused.
Hardware Simulation Considerations
e multiplexer and demultiplexer components do not provide a simulation testbench for simulating a
stand-alone instance of the component. However, you can use the standard SOPC Builder simulation ow
to simulate the component design les inside an SOPC Builder system.
Software Programming Model
e multiplexer and demultiplexer components do not have any user-visible control or status registers.
erefore, soware cannot control or congure any aspect of the multiplexer or de-multiplexer at run-
time. e components cannot generate interrupts.
18-6 Hardware Simulation Considerations UG-01085
2016.12.19
Altera Corporation Avalon Streaming Channel Multiplexer and Demultiplexer Cores
Send Feedback
Document Revision History
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 2009 v9.1.0 No change from previous release.
March 2009 v9.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.
UG-01085
2016.12.19 Document Revision History 18-7
Avalon Streaming Channel Multiplexer and Demultiplexer Cores Altera Corporation
Send Feedback
Avalon-ST Bytes to Packets and Packets to
Bytes Converter Cores 19
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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.e Avalon-ST Packets to Bytes Converter
core encodes packet control and payload as a stream of bytes. e Avalon-ST Bytes to Packets Converter
core accepts an encoded stream of bytes, and converts it into a stream of packets.
e 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
Functional Description
e following two gures 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
Sink
Avalon-ST
Bytes to Packets
Converter
data_in
(bytes)
T
S
-
n
o
l
a
v
Ae
c
r
u
o
S
data_out
(packet)
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 19-2: Avalon-ST Packets to Bytes Converter Core
Avalon-ST
Source
Avalon-ST
Packets to Bytes
Converter
data_in
(packet)
T
S
-
n
o
l
a
v
ASink
data_out
(bytes)
Interfaces
Table 19-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Ready latency = 0.
Data Width Data width = 8 bits; Bits per symbol = 8.
Channel Supported, up to 255 channels.
Error Not used.
Packet Supported only on the Avalon-ST Bytes to Packet Converter core’s source interface and the
Avalon-ST Packet to Bytes Converter core’s sink interface.
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specications.
Operation—Avalon-ST Bytes to Packets Converter Core
e Avalon-ST Bytes to Packets Converter core receives streams of bytes and transforms them into
packets. When parsing incoming bytestreams, the core decodes special characters in the following manner,
with higher priority operations listed rst:
• Escape (0x7d)—e core drops the byte. e next byte is XOR'ed with 0x20.
• Start of packet (0x7a)—e core drops the byte and marks the next payload byte as the start of a packet
by asserting the startofpacket signal on the Avalon-ST source interface.
• End of packet (0x7b)—e core drops the byte and marks the following byte as the end of a packet by
asserting the endofpacket signal on the Avalon-ST source interface. For single beat packets, both the
startofpacket and endofpacket signals are asserted in the same clock cycle.
ere are two possible cases if the payload is a special character:
•e byte sent aer end of packet is ESC'ed and XOR'ed with 0x20.
•e byte sent aer end of packet is assumed to be the last byte regardless of whether or not it is a
special character.
Note: e escape character should be used aer an end of packet if the next character requires it.
• Channel number indicator (0x7c)—e core drops the byte and takes the next non-special character as
the channel number.
19-2 Interfaces UG-01085
2016.12.19
Altera Corporation Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores
Send Feedback
Figure 19-3: Examples of Bytestreams
0x7c 0x01 0x7a 0x7d 0x5a 0x01 0xff 0x7b 0x3a...
Channel 1 SOP Data = 0x7a Data byte s EOP Las t
Data
byte
Singl e-channel packet for Channel 1:
0x7c 0x02 0x7a 0x7b 0x3a
Channel 2 SOP EOP Da ta
byte
Single -beat packet:
0x7c 0x00 0x7a 0x10 0x1 1 0x30 0x31 0x7b 0x14
Channel 0 SOP
(Ch 0) Data
(Ch 0) EOP
(Ch 0) Data
(Ch 0)
Interleaved channel s in a pack et:
0x7c 0x01 0x7c 0x00 0x12 0x13
Channel 1 Data
(Ch 1) Cha nnel 0 Data
(Ch 0)
Operation—Avalon-ST Packets to Bytes Converter Core
e Avalon-ST Packets to Bytes Converter core receives packetized data and transforms the packets to
bytestreams. e core constructs outgoing bytestreams by inserting appropriate special characters in the
following manner and sequence:
• If the startofpacket signal on the core's source interface is asserted, the core inserts the following
special characters:
• Channel number indicator (0x7c).
• Channel number, escaping it if required.
• Start of packet (0x7a).
• If the endofpacket signal on the core's source interface is asserted, the core inserts an end of packet
(0x7b) before the last byte of data.
• If the channel signal on the core’s source interface changes to a new value within a packet, the core
inserts a channel number indicator (0x7c) followed by the new channel number.
• If a data byte is a special character, the core inserts an escape (0x7d) followed by the data XORed with
0x20.
Document Revision History
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.
UG-01085
2016.12.19 Operation—Avalon-ST Packets to Bytes Converter Core 19-3
Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores Altera Corporation
Send Feedback
Date Version Changes
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change
to content.
May 2008 v8.0.0 Initial release.
19-4 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores
Send Feedback
Avalon Packets to Transactions Converter Core 20
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon® Packets to Transactions Converter core receives streaming data from upstream components
and initiates Avalon Memory-Mapped (Avalon-MM) transactions. e core then returns Avalon-MM
transaction responses to the requesting components.
e 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
Functional Description
Figure 20-1: Avalon Packets to Transactions Converter Core
Avalon-ST
Sink
Avalon
Packets to
Transactions
Converter
data_out
r
e
t
s
a
M
M
M
-
n
o
l
a
v
A
data_in
Avalon-ST
Source
Avalon-MM
Slave
Component
Interfaces
Table 20-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Ready latency = 0.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Feature Property
Data Width Data width = 8 bits; Bits per symbol = 8.
Channel Not supported.
Error Not used.
Packet Supported.
e Avalon-MM master interface supports read and write transactions. e data width is set to 32 bits and
burst transactions are not supported.
For more information about Avalon-ST interfaces, refer to Avalon Interface Specications.
Operation
e 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. e core does not report Avalon-ST errors.
Packet Formats
e core expects incoming data streams to be in the format shown in the table below. A response packet is
returned for every write transaction. e 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.
Table 20-2: Packet Formats
Byte Field Description
Transaction Packet Format
0Transaction code Type of transaction. See Properties of Avalon-ST Interfaces table.
1 Reserved Reserved for future use.
[3:2] Size Transaction size in bytes. For write transactions, the size indicates the
size of the data eld. For read transactions, the size indicates the total
number of bytes to read.
[7:4] Address 32-bit address for the transaction.
[n:8] Data Transaction data; data to be written for write transactions.
Response Packet Format
0Transaction code e transaction code with the most signicant bit inversed.
1 Reserved Reserved for future use.
[4:2] Size Total number of bytes read/written successfully.
Supported Transactions
e table below lists the Avalon-MM transactions supported by the core.
20-2 Operation UG-01085
2016.12.19
Altera Corporation Avalon Packets to Transactions Converter Core
Send Feedback
Table 20-3: Transaction Supported
Transaction
Code
Avalon-MM Transaction Description
0x00 Write, non-incrementing
address.
Writes data to the given address until the total number of
bytes written to the same word address equals to the
value specied in the size eld.
0x04 Write, incrementing address. Writes transaction data starting at the given address.
0x10 Read, non-incrementing
address.
Reads 32 bits of data from the given address until the
total number of bytes read from the same address equals
to the value specied in the size eld.
0x14 Read, incrementing address. Reads the number of bytes specied in the size eld
starting from the given address.
0x7f No transaction. No transaction is initiated. You can use this transaction
type for testing purposes. Although no transaction is
initiated on the Avalon-MM interface, the core still
returns a response packet for this transaction code.
e core can handle only a single transaction at a time. e ready signal on the core's Avalon-ST sink
interface is asserted only when the current transaction is completely processed.
No internal buer 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 eld. Whether or not both values agree, the
core always uses the EOP to determine the end of data.
Malformed Packets
e 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. is eectively handles packets
without an end of packet(EOP).
• Unsupported transaction codes—e core treats unsupported transactions as a no transaction.
Document Revision History
Table 20-4: Avalon Packets to Transactions Converter Core Revision History
Date Version Changes
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
UG-01085
2016.12.19 Document Revision History 20-3
Avalon Packets to Transactions Converter Core Altera Corporation
Send Feedback
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 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Initial release.
20-4 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon Packets to Transactions Converter Core
Send Feedback
Avalon-ST Round Robin Scheduler Core 21
2016.12.19
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. e most basic of the schedulers is the
Avalon-ST Round Robin Scheduler core.
e Avalon-ST Round Robin Scheduler core is SOPC Builder-ready and can integrate easily into any
SOPC Builder-generated systems.
Performance and Resource Utilization
is section lists the resource utilization and performance data for various Altera® device families. e
estimates are obtained by compiling the core using the Quartus Prime soware.
e 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
Channels
ALUTs Logic Registers Memory M512/
M4K/
M-RAM
fMAX
(MHz)
4 7 7 0/0/0 > 125
12 25 17 0/0/0 > 125
24 62 30 0/0/0 > 125
e table below shows the resource utilization and performance data for a Stratix III device
(EP3SL340F1760C3). e performance of the MegaCore® function in Stratix IV devices is similar to
Stratix III devices.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Table 21-2: Resource Utilization and Performance Data for Stratix III Devices
Number of
Channels
ALUTs Logic Registers Memory M9K/
M144K/ MLAB
fMAX
(MHz)
4 7 7 0/0/0 > 125
12 25 17 0/0/0 > 125
24 67 30 0/0/0 > 125
e 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
Channels
Total Logic
Elements
Total Registers Memory M9K fMAX
(MHz)
4 12 7 0 > 125
12 32 17 0 > 125
24 71 30 0 > 125
Functional Description
e Avalon-ST Round Robin Scheduler core controls the read operations from a multi-channel Avalon-ST
component that buers 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.
Figure 21-1: Avalon-ST Round Robin Scheduler Block Diagram
Request
(Channel_select) Almost Full Status
Avalon-ST
Round-Robin
Scheduler
M
M
-
n
o
l
a
v
Ar
e
t
s
a
M
e
t
i
r
W
k
n
i
S
T
S
-
n
o
l
a
v
A
Interfaces
e following interfaces are available in the Avalon-ST Round Robin Scheduler core:
21-2 Functional Description UG-01085
2016.12.19
Altera Corporation Avalon-ST Round Robin Scheduler Core
Send Feedback
• Almost-Full Status Interface
• Request Interface
Almost-Full Status Interface
e Almost-Full Status interface is an Avalon-ST sink interface.
Table 21-4: Avalon-ST Interface Feature Support
Feature Property
Backpressure Not supported
Data Width Data width = 1; Bits per symbol = 1
Channel Maximum channel = 32; Channel width = 5
Error Not supported
Packet Not supported
e interface collects the almost-full status from the sink components for all the channels in the sequence
provided.
Request Interface
e Request Interface is an Avalon Memory-Mapped (MM) Write Master interface. is interface requests
data from a specic channel. e 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.
e 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.
erefore, if the Avalon-ST Round Robin Scheduler starts requesting from channel 1, at the next clock
cycle, it requests from channel 2. e 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.
e Avalon-ST Round Robin Scheduler cannot determine if the requested component is able to service the
request transaction. e component asserts waitrequest when it cannot accept new requests.
Table 21-5: Ports for the Avalon-ST Round Robin Scheduler
Signal Direction Description
Clock and Reset
clk In Clock reference.
reset_n In Asynchronous active low reset.
UG-01085
2016.12.19 Operations 21-3
Avalon-ST Round Robin Scheduler Core Altera Corporation
Send Feedback
Signal Direction Description
Avalon-MM Request Interface
request_address (log2
Max_Channels–1:0)
Out e write address used to signal the channel the request is
for.
request_write Out Write enable signal.
request_writedata Out e amount of data requested from the particular
channel.
is value is always xed at 1.
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_channel
(Channel_Width–1:0)
In Indicates the channel for the current status indication.
almost_full_data (log2
Max_Channels–1:0)
In A 1-bit signal that is asserted high to indicate that the
channel indicated by almost_full_channel is almost
full.
Parameters
Table 21-6: Parameters for Avalon-ST Round Robin Scheduler Component
Parameters Values Description
Number of
channels
2–32 Species the number of channels the Avalon-ST Round Robin Scheduler
supports.
Use almost-full
status
0–1 Species whether the almost-full interface is used. If the interface is not
used, the core always requests data from the next channel at the next
clock cycle.
Document Revision History
Table 21-7: Avalon-ST Round Robin Scheduler 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 No change from previous release.
21-4 Parameters UG-01085
2016.12.19
Altera Corporation Avalon-ST Round Robin Scheduler Core
Send Feedback
Date Version Changes
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Initial release.
UG-01085
2016.12.19 Document Revision History 21-5
Avalon-ST Round Robin Scheduler Core Altera Corporation
Send Feedback
Avalon-ST Delay Core 22
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon® Streaming (Avalon-ST) Delay core provides a solution to delay Avalon-ST transactions by a
constant number of clock cycles. is core supports up to 16 clock cycle delays.
e Avalon-ST Delay core is SOPC Builder-ready and integrates easily into any SOPC Builder-generated
system.
Functional Description
Figure 22-1: Avalon-ST Delay Core
Out_Data
In_Data
Clock
Avalon-ST
Delay Core
Av
k
n
i
S
T
S
-
n
o
l
a
Avo
S
T
S
-
n
o
l
aurce
e Avalon-ST Delay core adds a delay between the input and output interfaces. e core accepts all
transactions presented on the input interface and reproduces them on the output interface N cycles later
without changing the transaction.
e 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. e Number Of Delay Clocks parameter denes the
constant (N) number, which must be between 0 and 16. e change of the In_Valid signal is reected on
the Out_Valid signal exactly N cycles later.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Reset
e 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. Aer the reset signal is deasserted, the output signals
are held at 0 for N clock cycles. e delayed values of the input signals are then reected at the output
signals aer N clock cycles.
Interfaces
e Avalon-ST Delay core supports packetized and non-packetized interfaces with optional channel and
error signals. is core does not support backpressure.
Table 22-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Not supported.
Data Width Congurable.
Channel Supported (optional).
Error Supported (optional).
Packet Supported (optional).
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specications.
Parameters
Table 22-2: Congurable Parameters
Parameter Legal
Values
Default
Value
Description
Number Of Delay
Clocks
0 to 16 1 Species the delay the core introduces, in clock cycles.
e value of 0 is supported for some cases of parameter‐
ized systems in which no delay is required.
Data Width 1–512 8 e width of the data on the Avalon-ST data interfaces.
Bits Per Symbol 1–512 8 e number of bits per symbol for the input and output
interfaces. For example, byte-oriented interfaces have 8-
bit symbols.
Use Packets 0 or 1 0 Indicates whether or not packet transfers are supported.
Packet support includes the startofpacket,
endofpacket, and empty signals.
Use Channel 0 or 1 0 e option to enable or disable the channel signal.
Channel Width 0-8 1 e width of the channel signal on the data interfaces.
is parameter is disabled when Use Channel is set to 0.
22-2 Reset UG-01085
2016.12.19
Altera Corporation Avalon-ST Delay Core
Send Feedback
Parameter Legal
Values
Default
Value
Description
Max Channels 0-255 1 e maximum number of channels that a data interface
can support. is parameter is disabled when Use
Channel is set to 0.
Use Error 0 or 1 0 e option to enable or disable the error signal.
Error Width 0–31 1 e width of the error signal on the output interfaces. A
value of 0 indicates that the error signal is not in use. is
parameter is disabled when Use Error is set to 0.
Use packets 0 or 1 Setting this parameter to 1 enables packet support on the
Avalon-ST data interfaces.
Use ll level 0 or 1 Setting this parameter to 1 enables the Avalon-MM status
interface.
Number of almost-full
thresholds
0 to 2 e number of almost-full thresholds to enable. Setting
this parameter to 1 enables Use almost-full threshold 1.
Setting it to 2 enables both Use almost-full threshold 1
and Use almost-full threshold 2.
Number of almost-
empty thresholds
0 to 2 e number of almost-empty thresholds to enable.
Setting this parameter to 1 enables Use almost-empty
threshold 1. Setting it to 2 enables both Use almost-
empty threshold 1 and Use almost-empty threshold 2.
Section available
threshold
0 to 2
Address
Width
Specify the amount of data to be delivered to the output
interface. is parameter applies only when packet
support is disabled.
Packet buer mode 0 or 1 Setting this parameter to 1 causes the core to deliver only
full packets to the output interface. is parameter
applies only when Use packets is set to 1.
Drop on error 0 or 1 Setting this parameter to 1 causes the core to drop
packets at the Avalon-ST data sink interface if the error
signal on that interface is asserted. Otherwise, the core
accepts the packet and sends it out on the Avalon-ST data
source interface with the same error. is parameter
applies only when packet buer mode is enabled.
Use almost-full
threshold 1
0 or 1 is threshold indicates that the FIFO is almost full. It is
enabled when the parameter Number of almost-full
threshold is set to 1 or 2.
Use almost-full
threshold 2
0 or 1 is threshold is an initial indication that the FIFO is
getting full. It is enabled when the parameter Number of
almost-full threshold is set to 2.
Use almost-empty
threshold 1
0 or 1 is threshold indicates that the FIFO is almost empty. It
is enabled when the parameter Number of almost-empty
threshold is set to 1 or 2.
UG-01085
2016.12.19 Parameters 22-3
Avalon-ST Delay Core Altera Corporation
Send Feedback
Parameter Legal
Values
Default
Value
Description
Use almost-empty
threshold 2
0 or 1 is threshold is an initial indication that the FIFO is
getting empty. It is enabled when the parameter Number
of almost-empty threshold is set to 2.
Document Revision History
Table 22-3: Avalon-ST Delay 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 No change from previous release.
January 2010 v9.1.1 Initial release.
22-4 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon-ST Delay Core
Send Feedback
Avalon-ST Splitter Core 23
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Avalon® Streaming (Avalon-ST) Splitter core allows you to replicate transactions from an Avalon-ST
source interface to multiple Avalon-ST sink interfaces. is core can support from 1 to 16 outputs.
e Avalon-ST Splitter core is SOPC Builder-ready and integrates easily into any SOPC Builder-generated
system.
Functional Description
Figure 23-1: Avalon-ST Splitter Core
Output 0
In_Data
Out_Data
Avalon-ST
Splitter Core
Output N
Clock
Av
k
n
i
S
T
S
-
n
o
l
a
AvT
S
-
n
o
l
a
o
Surce 0 AvT
S
-
n
o
l
a
o
Surce N
e 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. is include all signals except for
the ready signal.
e 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.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Backpressure
e 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. is way, if any output interface deasserts the
ready signal, the input interface receives the deasserted ready signal as well. is 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 aected.
Because the logic is purely combinational, the core introduces no latency.
Interfaces
e Avalon-ST Splitter core supports packetized and non-packetized interfaces with optional channel and
error signals. e core propagates backpressure from any output interface to the input interface.
Table 23-1: Properties of Avalon-ST Interfaces
Feature Property
Backpressure Ready latency = 0.
Data Width Congurable.
Channel Supported (optional).
Error Supported (optional).
Packet Supported (optional).
For more information about Avalon-ST interfaces, refer to the Avalon Interface Specications.
Parameters
Table 23-2: Congurable Parameters
Parameter Legal
Values
Default
Value
Description
Number Of
Outputs
1 to 16 2 e number of output interfaces. e value of 1 is supported for
some cases of parameterized systems in which no duplicated
output is required.
Qualify Valid Out 0 or 1 1 Determines whether the Out_Valid signal is gated or non-
gated when backpressure is applied.
Data Width 1–512 8 e width of the data on the Avalon-ST data interfaces.
23-2 Backpressure UG-01085
2016.12.19
Altera Corporation Avalon-ST Splitter Core
Send Feedback
Parameter Legal
Values
Default
Value
Description
Bits Per Symbol 1–512 8 e number of bits per symbol for the input and output
interfaces. For example, byte-oriented interfaces have 8-bit
symbols.
Use Packets 0 or 1 0 Indicates whether or not packet transfers are supported. Packet
support includes the startofpacket, endofpacket, and empty
signals.
Use Channel 0 or 1 0 e option to enable or disable the channel signal.
Channel Width 0-8 1 e width of the channel signal on the data interfaces. is
parameter is disabled when Use Channel is set to 0.
Max Channels 0-255 1 e maximum number of channels that a data interface can
support. is parameter is disabled when Use Channel is set to
0.
Use Error 0 or 1 0 e option to enable or disable the error signal.
Error Width 0–31 1 e width of the error signal on the output interfaces. A value
of 0 indicates that the error signal is not used. is parameter is
disabled when Use Error is set to 0.
Use packets 0 or 1 Setting this parameter to 1 enables packet support on the
Avalon-ST data interfaces.
Use ll level 0 or 1 Setting this parameter to 1 enables the Avalon-MM status
interface.
Number of
almost-full
thresholds
0 to 2 e number of almost-full thresholds to enable. Setting this
parameter to 1 enables Use almost-full threshold 1. Setting it
to 2 enables both Use almost-full threshold 1 and Use almost-
full threshold 2.
Number of
almost-empty
thresholds
0 to 2 e number of almost-empty thresholds to enable. Setting this
parameter to 1 enables Use almost-empty threshold 1. Setting
it to 2 enables both Use almost-empty threshold 1 and Use
almost-empty threshold 2.
Section available
threshold
0 to 2
Address
Width
Specify the amount of data to be delivered to the output
interface. is parameter applies only when packet support is
disabled.
Packet buer
mode
0 or 1 Setting this parameter to 1 causes the core to deliver only full
packets to the output interface. is parameter applies only
when Use packets is set to 1.
UG-01085
2016.12.19 Parameters 23-3
Avalon-ST Splitter Core Altera Corporation
Send Feedback
Parameter Legal
Values
Default
Value
Description
Drop on error 0 or 1 Setting this parameter to 1 causes the core to drop packets at
the Avalon-ST data sink interface if the error signal on that
interface is asserted. Otherwise, the core accepts the packet and
sends it out on the Avalon-ST data source interface with the
same error. is parameter applies only when packet buer
mode is enabled.
Use almost-full
threshold 1
0 or 1 is threshold indicates that the FIFO is almost full. It is
enabled when the parameter Number of almost-full threshold
is set to 1 or 2.
Use almost-full
threshold 2
0 or 1 is threshold is an initial indication that the FIFO is getting
full. It is enabled when the parameter Number of almost-full
threshold is set to 2.
Use almost-
empty threshold
1
0 or 1 is threshold indicates that the FIFO is almost empty. It is
enabled when the parameter Number of almost-empty
threshold is set to 1 or 2.
Use almost-
empty threshold
2
0 or 1 is threshold is an initial indication that the FIFO is getting
empty. It is enabled when the parameter Number of almost-
empty threshold is set to 2.
Document Revision History
Table 23-3: Avalon-ST Splitter 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 No change from previous release.
January 2010 v9.1.1 Initial release.
23-4 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon-ST Splitter Core
Send Feedback
Scatter-Gather DMA Controller Core 24
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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
e SG-DMA controller core transfers and merges non-contiguous memory to a continuous address
space, and vice versa. e 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 soware 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 soware to access the core using the provided driver.
Example Systems
e block diagram below shows a SG-DMA controller core for the DMA subsystem of a printed circuit
board. e 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
SOPC Builder Syste m
S
Sc atter Gather DMA Controller Core
Nios II
Proc e s s o r
Rd
SNK
De s cripto r
Proce ssor
Blo ck
DDR2
SDRAM
Memo ry
Controller
M
Rd
M
DMA Write
Block
M
Wr
M
Wr
M
Control
&
Status
Registe rs
System Interco nne ct Fa bric
Memo ry
De sc riptor
Table
SAvalon-MM Slave Port
SNK Avalon-S T Sink P ort
MAvalon-MM Master Port
Stream ing
Com ponent
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
e gure below shows a dierent use of the SG-DMA controller core, where the core transfers data
between an internal and external memory. e 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
Process or
Bus
Altera FP GA
SOPC Builder Syste m
S
Host Process or
Internal
Memo ry
M M
System Interconnec t Fa bric
S
Rd
M
Des criptor
Proces sor
Block
Rd
M
DMA Read/
Write
Blo ck
Wr
M
Wr
M
Con trol
&
Stat us
Registe rs
Scatter Gather DMA Controller Core
Avalon-MM Bridge
MS
IOB
Main Memory
De sc riptor
Table
SAvalon-MM Slave Por t
MAvalon-MM Master P ort
IOB IO Breakout
Comparison of SG-DMA Controller Core and DMA Controller Core
e SG-DMA controller core provides a signicant performance enhancement over the previously
available DMA controller core, which could only queue one transfer at a time. Using the DMA Controller
core, a CPU had to wait for the transfer to complete before writing a new descriptor to the DMA slave
port. Transfers to non-contiguous memory could not be linked; consequently, the CPU overhead was
substantial for small transfers, degrading overall system performance. In contrast, the SG-DMA controller
core reads a series of descriptors from memory that describe the required transactions and performs all of
the transfers without additional intervention from the CPU.
Resource Usage and Performance
Resource utilization for the core is 600–1400 logic elements, depending upon the width of the datapath,
the parameterization of the core, the device family, and the type of data transfer. e table below provides
the estimated resource usage for a SG-DMA controller core used for memory to memory transfer. e
core is congurable and the resource utilization varies with the conguration specied.
Table 24-1: SG-DMA Estimated Resource Usage
Datapath Cyclone® II Stratix®
(LEs)
Stratix II
(ALUTs)
8-bit datapath 850 650 600
32-bit datapath 1100 850 700
64-bit datapath 1250 1250 800
e core operating frequency varies with the device and the size of the datapath. e table below provides
an example of expected performance for SG-DMA cores instantiated in several dierent device families.
24-2 Comparison of SG-DMA Controller Core and DMA Controller Core UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Table 24-2: SG-DMA Peak Performance
Device Datapath fMAX Throughput
Cyclone II 64 bits 150 MHz 9.6 Gbps
Cyclone III 64 bits 160 MHz 10.2 Gbps
Stratix II/Stratix II
GX
64 bits 250 MHz 16.0 Gbps
Stratix III 64 bits 300 MHz 19.2 Gbps
Functional Description
e SG-DMA controller core comprises three major blocks: descriptor processor, DMA read, and DMA
write. ese blocks are combined to create three dierent congurations:
• Memory to memory
• Memory to stream
• Stream to memory
e type of devices you are transferring data to and from determines the conguration to implement.
Examples of memory-mapped devices are PCI, PCIe and most memory devices. e 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 conguration of the SG-DMA controller core.
Functional Blocks and Congurations
e following sections describe each functional block and conguration.
Descriptor Processor
e 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 elds to specify a transfer:
• Source address
• Destination address
• Number of bytes to transfer
• Increment read address aer each transfer
• Increment write address aer each transfer
• Generate start of packet (SOP) and end of packet (EOP)
Aer 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 elds in the descriptor.
UG-01085
2016.12.19 Functional Description 24-3
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
DMA Read Block
e DMA read block is used in memory-to-memory and memory-to-stream congurations. e block
performs the following operations:
• Reads commands from the input command FIFO.
• Reads a block of memory via the Avalon-MM read master port for each command.
• Pushes data into the data FIFO.
If burst transfer is enabled, an internal read FIFO with a depth of twice the maximum read burst size is
instantiated. e DMA read block initiates burst reads only when the read FIFO has sucient space to
buer the complete burst.
DMA Write Block
e DMA write block is used in memory-to-memory and stream-to-memory congurations. e block
reads commands from its input command FIFO. For each command, the DMA write block reads data
from its Avalon-ST sink port and writes it to the Avalon-MM master port.
If burst transfer is enabled, an internal write FIFO with a depth of twice the maximum write burst size is
instantiated. Each burst write transfers a xed amount of data equals to the write burst size, except for the
last burst. In the last burst, the remaining data is transferred even if the amount of data is less than the
write burst size.
Memory-to-Memory Conguration
Memory-to-memory congurations include all three blocks: descriptor processor, DMA read, and DMA
write. An internal FIFO is also included to provide buering and ow control for data transferred between
the DMA read and write blocks.
e example below illustrates one possible memory-to-memory conguration with an internal Nios II
processor and descriptor list.
Figure 24-3: Example of Memory-to-Memory Conguration
MAva lon -MM Ma ster P o rt
SAvalo n-MM S lave Port
Avalo n-ST Source Port
SRC
Ava lon-S T S ink P ort
SNK
S OPC Build er Sys te m
Altera FPG A
De s cripto r
Proc e ss o r
Blo ck
S ca tter Ga ther DMA C on troller Core
Rd
SM
Wr
co mmand
st atus
M M
co mmand
st atus
M
Con trol
&
Status
Re gist e rs
DMA Write Blo ck
SN K
DMA Re ad Blo ck
SR C
Data
FIFO
Nio s II
Proc es s o r
DDR2
SDRA M
Memo ry
Con tro ller
S ys te m Inte rconn e ct Fabric
Memo ry
De s c ript or
Ta ble
Memory-to-Stream Conguration
Memory-to-stream congurations 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.
24-4 Functional Blocks and Congurations UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Figure 24-4: Example of Memory-to-Stream Conguration
SNK
MAvalon-MM Mas ter Port
SAvalon-MM Slave Port
Avalon-ST S ource P ort
Avalon-ST Sink Port
S OPC Builder S yste m
Altera FP GA
Sc atter Gat her DMA Controller Core
Rd
SM
Wr
MM
command
s tatu s
SRC
Contro l
&
Status
Regis ters
Nios II
Process or
DDR2
SDR AM
Memory
Controller
Memory
Descriptor
Tab le
DMA Rea d Block
Descr iptor
Processo r
Bloc k
SRC
Streaming
Component
SNK
System Interconnec t Fab ric
Stream-to-Memory Conguration
Stream-to-memory congurations include the descriptor processor and DMA write blocks. is congu‐
ration is similar to the memory-to-stream conguration as the gure below illustrates.
Figure 24-5: Example of Stream-to-Memory Conguration
SRC
SRC
MAvalon-MM Master P ort
SAvalon-MM S lave P ort
Avalon-ST So urce Port
Avalon-ST S ink Port
SO PC Builder Syst em
Alte ra FPG A
Scatter Gather DMA Controlle r Core
Rd
SM
Wr
MM
comma nd
st atus
SNK
Con trol
&
Sta tus
Regis ters
Nios II
Pro ce s s or
DDR2
SDRAM
Memo ry
Con trolle r
System Inte rconnect Fabric
Memo ry
Descriptor
Table
Des criptor
Proc e s s or
Block
SNK
DMA Write Blo ck
Streaming
Co mpon e nt
SR C
DMA Descriptors
DMA descriptors specify data transfers to be performed. e SG-DMA core uses a dedicated interface to
read and write the descriptors. ese descriptors, which are stored as a linked list, can be stored on an on-
chip or o-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.
e 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.
e descriptors must be initialized and aligned on a 32-bit boundary. e 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.
UG-01085
2016.12.19 DMA Descriptors 24-5
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Descriptor Processing
e following steps describe how the DMA descriptors are processed:
1. Soware 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. Soware writes the address of the rst descriptor to the next_descriptor_pointer register and
initiates the transfer by setting the RUN bit in the control register to 1. See the Soware 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. e descriptor processor block reads the address of the rst 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 rst 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. e core performs the data transfer.
• In memory-to-memory congurations, the DMA read block receives the source address from its
command FIFO and starts reading data to ll the FIFO on its stream port until the specied
number of bytes are transferred. e DMA read block pauses when the FIFO is full until the FIFO
has enough space to accept more data.
e DMA write block gets the destination address from its command FIFO and starts writing until
the specied 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 congurations, the DMA read block reads from the source address and
transfers the data to the core’s streaming port until the specied number of bytes are transferred or
the end of packet is reached. e 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 congurations, the DMA write block reads from the core’s streaming port
and writes to the destination address. e block continues reading until the specied number of
bytes are transferred.
5. e descriptor processor block receives a status from the DMA read or write block and updates the
DESC_CONTROL, DESC_STATUS, and ACTUAL_BYTES_TRANSFERRED elds in the descriptor. e
OWNED_BY_HW bit in the DESC_CONTROL eld is cleared unless the PARK bit is set to 1.
Once the core starts processing the descriptors, soware must not update descriptors with
OWNED_BY_HW bit set to 1. It is only safe for soware to update a descriptor when its OWNED_BY_HW bit is
cleared.
e 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.
24-6 DMA Descriptors UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Building and Updating Descriptor List
Altera recommends the following method of building and updating the descriptor list:
1. Build the descriptor list and terminate the list with a non-hardware owned descriptor (OWNED_BY_HW =
0). e list can be arbitrarily long.
2. Set the interrupt IE_CHAIN_COMPLETED.
3. Write the address of the rst descriptor in the rst list to the next_descriptor_pointer register and
set the RUN bit to 1 to initiate transfers.
4. While the core is processing the rst list, build a second list of descriptors.
5. When the SD-DMA controller core nishes processing the rst list, an interrupt is generated. Update
the next_descriptor_pointer register with the address of the rst descriptor in the second list. Clear
the RUN bit and the status register. Set the RUN bit back to 1 to resume transfers.
6. If there are new descriptors to add, always add them to the list which the core is not processing. For
example, if the core is processing the rst list, add new descriptors to the second list and so forth.
is method ensures that the descriptors are not updated when the core is processing them. Because
the method requires a response to the interrupt, a high-latency interrupt may cause a problem in
systems where stalling data movement is not possible.
Error Conditions
e SG-DMA core has a congurable error width. Error signals are connected directly to the Avalon-ST
source or sink to which the SG-DMA core is connected.
UG-01085
2016.12.19 Error Conditions 24-7
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
e list below describes how the error signals in the SG-DMA core are implemented in the folowing
congurations:
• Memory-to-memory conguration
No error signals are generated. e error eld in the register and descriptor is hardcoded to 0.
• Memory-to-stream conguration
If you specied the usage of error bits in the core, the error bits are generated in the Avalon-ST source
interface. ese error bits are hardcoded to 0 and generated in compliance with the Avalon-ST slave
interfaces.
• Stream-to-memory conguration
If you specied the usage of error bits in the core, error bits are generated in the Avalon-ST sink
interface. ese error bits are passed from the Avalon-ST sink interface and stored in the registers and
descriptor.
e table below lists the error signals when the core is operating in the memory-to-stream congura‐
tion and connected to the transmit FIFO interface of the Altera Triple-Speed Ethernet MegaCore®
function.
Table 24-3: Avalon-ST Transmit Error Types
Signal Type Description
TSE_transmit_error[0] Transmit Frame Error. Asserted to indicate that the transmitted
frame should be viewed as invalid by the Ethernet MAC. e
frame is then transferred onto the GMII interface with an error
code during the frame transfer.
e table below lists the error signals when the core is operating in the stream-to-memory congura‐
tion and connected to the transmit FIFO interface of the Triple-Speed Ethernet MegaCore function.
Table 24-4: Avalon-ST Receive Error Types
Signal Type Description
TSE_receive_error[0] Receive Frame Error. is signal indicates that an error has
occurred. It is the logical OR of receive errors 1 through 5.
TSE_receive_error[1] Invalid Length Error. Asserted when the received frame has an
invalid length as dened by the IEEE 802.3 standard.
TSE_receive_error[2] CRC Error. Asserted when the frame has been received with a
CRC-32 error.
TSE_receive_error[3] Receive Frame Truncated. Asserted when the received frame
has been truncated due to receive FIFO overow.
TSE_receive_error[4] Received Frame corrupted due to PHY error. (e PHY has
asserted an error on the receive GMII interface.)
TSE_receive_error[5] Collision Error. Asserted when the frame was received with a
collision.
Each streaming core has a dierent set of error codes. Refer to the respective user guides for the codes.
24-8 Error Conditions UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Parameters
Table 24-5: Congurable Parameters
Parameter Legal Values Description
Transfer mode Memory To
Memory
Memory To
Stream
Stream To
Memory
Conguration to use. For more information about these congu‐
rations, see the Memory-to-Memory Conguration section.
Enable bursting
on descriptor read
master
On/O If this option is on, the descriptor processor block uses Avalon-
MM bursting when fetching descriptors and writing them back in
memory. With 32-bit read and write ports, the descriptor
processor block can fetch the 256-bit descriptor by performing 8-
word burst as opposed to eight individual single-word transac‐
tions.
Allow unaligned
transfers
On/O If this option is on, the core allows accesses to non-word-aligned
addresses. is option doesn’t apply for burst transfers.
Unaligned transfers require extra logic that may negatively impact
system performance.
Enable burst
transfers
On/O Turning on this option enables burst reads and writes.
Read burstcount
signal width
1–16 e width of the read burstcount signal. is value determines
the maximum burst read size.
Write burstcount
signal width
1–16 e width of the write burstcount signal. is value determines
the maximum burst write size.
Data width 8, 16, 32, 64 e data width in bits for the Avalon-MM read and write ports.
Source error
width
0–7 e width of the error signal for the Avalon-ST source port.
Sink error width 0 – 7 e width of the error signal for the Avalon-ST sink port.
Data transfer
FIFO depth
2, 4, 8, 16, 32, 64 e depth of the internal data FIFO in memory-to-memory
congurations with burst transfers disabled.
e 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.
UG-01085
2016.12.19 Parameters 24-9
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Simulation Considerations
Signals for hardware simulation are automatically generated as part of the Nios II simulation process
available in the Nios II IDE.
Software Programming Model
e following sections describe the soware programming model for the SG-DMA controller core.
HAL System Library Support
e Altera-provided driver implements a HAL device driver that integrates into the HAL system library
for Nios II systems. HAL users should access the SG-DMA controller core via the familiar HAL API and
the ANSI C standard library.
Software Files
e SG-DMA controller core provides the following soware les. ese les provide low-level access to
the hardware and drivers that integrate into the Nios II HAL system library. Application developers should
not modify these les.
•altera_avalon_sgdma_regs.h—denes the core's register map, providing symbolic constants to
access the low-level hardware
•altera_avalon_sgdma.h—provides denitions for the Altera Avalon SG-DMA buer control and
status ags.
•altera_avalon_sgdma.c—provides function denitions for the code that implements the SG-
DMA controller core.
•altera_avalon_sgdma_descriptor.h—denes the core's descriptor, providing symbolic
constants to access the low-level hardware.
Register Maps
e SG-DMA controller core has three registers accessible from its Avalon-MM interface; status,
control and next_descriptor_pointer. Soware can congure the core and determines its current
status by accessing the registers.
e 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.
Table 24-6: Register Map
32-bit
Word
Oset
Register Name Reset
Value
Description
base
+ 0
status 0is register indicates the core’s current status
such as what caused the last interrupt and if the
core is still processing descriptors. See the
status Register Map table for the status
register map.
24-10 Simulation Considerations UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
32-bit
Word
Oset
Register Name Reset
Value
Description
base
+ 1
version 1 Indicate the hardware version number. Only
being used by soware driver for soware
backward compatibility purpose.
base
+ 4
control 0is register species the core’s behavior such as
what triggers an interrupt and when the core is
started and stopped. e host processor can
congure the core by setting the register bits
accordingly. See the Control Register Bit Map
table for the control register map.
base
+ 8
next_descriptor_pointer 0is register contains the address of the next
descriptor to process. Set this register to the
address of the rst descriptor as part of the
system initialization sequence.
Altera recommends that user applications clear
the RUN bit in the control register and wait
until the BUSY bit of the status register is set to
0 before reading this register.
Table 24-7: Control Register Bit Map
Bit Bit Name Access Description
0IE_ERROR R/W When this bit is set to 1, the core generates an
interrupt if an Avalon-ST error occurs during
descriptor processing. (1)
1IE_EOP_ENCOUNTERED R/W When this bit is set to 1, the core generates an
interrupt if an EOP is encountered during
descriptor processing. (1)
2IE_DESCRIPTOR_COMPLETED R/W When this bit is set to 1, the core generates an
interrupt aer each descriptor is processed. (1)
3IE_CHAIN_COMPLETED R/W When this bit is set to 1, the core generates an
interrupt aer the last descriptor in the list is
processed, that is when the core encounters a
descriptor with a cleared OWNED_BY_HW bit. (1)
4IE_GLOBAL R/W When this bit is set to 1, the core is enabled to
generate interrupts.
UG-01085
2016.12.19 Register Maps 24-11
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Bit Bit Name Access Description
5RUN R/W Set this bit to 1 to start the descriptor processor
block which subsequently initiates DMA transac‐
tions. Prior to setting this bit to 1, ensure that the
register next_descriptor_pointer is updated with
the address of the rst descriptor to process. e
core continues to process descriptors in its queue as
long as this bit is 1.
Clear this bit to stop the core from processing the
next descriptor in its queue. If this bit is cleared in
the middle of processing a descriptor, the core
completes the processing before stopping. e host
processor can then modify the remaining descrip‐
tors and restart the core.
6STOP_DMA_ER R/W Set this bit to 1 to stop the core when an Avalon-ST
error is encountered during a DMA transaction.
is bit applies only to stream-to-memory congu‐
rations.
7IE_MAX_DESC_PROCESSED R/W Set this bit to 1 to generate an interrupt aer the
number of descriptors specied by MAX_DESC_
PROCESSED are processed.
8 ..
15
MAX_DESC_PROCESSED R/W Species the number of descriptors to process
before the core generates an interrupt.
16 SW_RESET R/W Soware can reset the core by writing to this bit
twice. Upon the second write, the core is reset. e
logic which sequences the soware reset process
then resets itself automatically.
Executing a soware reset when a DMA transfer is
active may result in permanent bus lockup until the
next system reset. Hence, Altera recommends that
you use the soware reset as your last resort.
17 PARK R/W Seting this bit to 0 causes the SG-DMA controller
core to clear the OWNED_BY_HW bit in the descriptor
aer each descriptor is processed. If the PARK bit is
set to 1, the core does not clear the OWNED_BY_HW bit,
thus allowing the same descriptor to be processed
repeatedly without soware intervention. You also
need to set the last descriptor in the list to point to
the rst one.
18 DESC_POLL_EN R/W Set this bit to 1 to enable polling mode. When you
set this bit to 1, the core continues to poll for the
next descriptor until the OWNED_BY_HW bit is set. e
core also updates the descriptor pointer to point to
the current descriptor.
19 Reserved
24-12 Register Maps UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Bit Bit Name Access Description
20.
.30
TIMEOUT_COUNTER RW Species the number of clocks to wait before polling
again. e valid range is 1 to 255. e core also
updates the next_desc_ptr eld so that it points to
the next descriptor to read.
31 CLEAR_INTERRUPT R/W Set this bit to 1 to clear pending interrupts.
Table 24-7 :
1. All interrupts are generated only aer the descriptor is updated.
Altera recommends that you read the status register only aer the RUN bit in the control register is
cleared.
Table 24-8: Status Register Bit Map
Bit Bit Name Access Description
0ERROR R/C (1) (2) A value of 1 indicates that an Avalon-ST error
was encountered during a transfer.
1EOP_ENCOUNTERED R/C A value of 1 indicates that the transfer was
terminated by an end-of-packet (EOP) signal
generated on the Avalon-ST source interface.
is condition is only possible in stream-to-
memory congurations.
2DESCRIPTOR_COMPLETED R/C (1) (2) A value of 1 indicates that a descriptor was
processed to completion.
3CHAIN_COMPLETED R/C (1) (2) A value of 1 indicates that the core has
completed processing the descriptor chain.
4BUSY R (1) (3) A value of 1 indicates that descriptors are being
processed. is bit is set to 1 on the next clock
cycle aer the RUN bit is asserted and does not
get cleared until one of the following event
occurs:
Descriptor processing completes and the RUN bit
is cleared.
An error condition occurs, the STOP_DMA_ER bit
is set to 1 and the processing of the current
descriptor completes.
5 ..
31
Reserved
Table 24-8 :
1. is bit must be cleared aer a read is performed. Write one to clear this bit.
2. is bit is updated by hardware aer each DMA transfer completes. It remains set until
soware writes one to clear.
3. is bit is continuously updated by the hardware.
UG-01085
2016.12.19 Register Maps 24-13
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
DMA Descriptors
See the Data Structure section for the structure denition.
Table 24-9: DMA Descriptor Structure
Byte Oset
Field Names
31 24 23 16 15 8 7 0
base source
base + 4 Reserved
base + 8 destination
base
+ 12
Reserved
base
+ 16
next_desc_ptr
base
+ 20
Reserved
base
+ 24
Reserved bytes_to_transfer
base
+ 28
desc_control desc_status actual_bytes_transferred
Table 24-10: DMA Descriptor Field Description
Field Name Access Description
source R/W Species the address of data to be read. is address is
set to 0 if the input interface is an Avalon-ST interface.
destination R/W Species the address to which data should be written.
is address is set to 0 if the output interface is an
Avalon-ST interface.
next_desc_ptr R/W Species the address of the next descriptor in the linked
list.
bytes_to_transfer R/W Species the number of bytes to transfer. If this eld is
0, the SG-DMA controller core continues transferring
data until it encounters an EOP.
read_ R/W Species the burst length in bytes for a burst read from
Avalon devices (memory).
write_ R/W Species the burst length in bytes for a burst write to
Avalon devices (memory).
actual_bytes_
transferred
RSpecies the number of bytes that are successfully
transferred by the core. is eld is updated aer the
core processes a descriptor.
24-14 DMA Descriptors UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Field Name Access Description
desc_status R/W is eld is updated aer the core processes a
descriptor. See DESC_STATUS Bit Map for the bit map
of this eld.
desc_control R/W Species the behavior of the core. is eld is updated
aer the core processes a descriptor. See the DESC_
CONTROL Bit Map table for descriptions of each bit.
Table 24-11: DESC_CONTROL Bit Map
Bit (s) Field Name Access Description
0GENERATE_EOP W When this bit is set to 1,the DMA read block asserts
the EOP signal on the nal word.
1READ_FIXED_ADDRESS R/W is bit applies only to Avalon-MM read master
ports. When this bit is set to 1, the DMA read block
does not increment the memory address. When this
bit is set to 0, the read address increments aer each
read.
2WRITE_FIXED_ADDRESS R/W is bit applies only to Avalon-MM write master
ports. When this bit is set to 1, the DMA write block
does not increment the memory address. When this
bit is set to 0, the write address increments aer each
write.
In memory-to-stream congurations, the DMA read
block generates a start-of-packet (SOP) on the rst
word when this bit is set to 1.
[6:
3]
Reserved — —
3 .
. 6
AVALON-ST_CHANNEL_
NUMBER
R/W e DMA read block sets the channel signal to this
value for each word in the transaction. e DMA
write block replaces this value with the channel
number on its sink port.
7OWNED_BY_HW R/W is bit determines whether hardware or soware has
write access to the current register.
When this bit is set to 1, the core can update the
descriptor and soware should not access the
descriptor due to the possibility of race conditions.
Otherwise, it is safe for soware to update the
descriptor.
Aer completing a DMA transaction, the descriptor processor block updates the desc_status eld to
indicate how the transaction proceeded.
UG-01085
2016.12.19 DMA Descriptors 24-15
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Table 24-12: DESC_STATUS Bit Map
Bit Bit Name Access Description
[7:0] ERROR_0 .. ERROR_
7
R Each bit represents an error that occurred on the
Avalon-ST interface. e context of each error is dened
by the component connected to the Avalon-ST interface.
Timeouts
e SG-DMA controller does not implement internal counters to detect stalls. Soware can instantiate a
timer component if this functionality is required.
Programming with SG-DMA Controller
is section describes the device and descriptor data structures, and the application programming
interface (API) for the SG-DMA controller core.
Data Structure
Table 24-13: Device Data Structure
typedef struct alt_sgdma_dev
{
alt_llist llist; // Device linked-list entry
const char *name; // Name of SGDMA in SOPC System
void *base; // Base address of SGDMA
alt_u32 *descriptor_base; // reserved
alt_u32 next_index; // reserved
alt_u32 num_descriptors; // reserved
alt_sgdma_descriptor *current_descriptor; // reserved
alt_sgdma_descriptor *next_descriptor; // reserved
alt_avalon_sgdma_callback callback; // Callback routine pointer
void *callback_context; // Callback context pointer
alt_u32 chain_control; // Value OR'd into control reg
} alt_sgdma_dev;
24-16 Timeouts UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Table 24-14: Descriptor Data Structure
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 eld. Set to 0. */
alt_u8 write_burst;/* Reserved eld. Set to 0. */
alt_u16 actual_bytes_transferred;
alt_u8 status;
alt_u8 control;
} alt_avalon_sgdma_packed alt_sgdma_descriptor;
SG-DMA API
Table 24-15: Function List
Name Description
alt_avalon_sgdma_do_async_
transfer()
Starts a non-blocking transfer of a descriptor chain.
alt_avalon_sgdma_do_sync_
transfer()
Starts a blocking transfer of a descriptor chain. is function
blocks both before transfer if the controller is busy and until the
requested transfer has completed.
alt_avalon_sgdma_construct_mem_
to__mem_desc()
Constructs a single SG-DMA descriptor in the specied
memory for an Avalon-MM to Avalon-MM transfer.
alt_avalon_sgdma_construct_
stream_to_mem_desc()
Constructs a single SG-DMA descriptor in the specied
memory for an Avalon-ST to Avalon-MM transfer. e
function automatically terminates the descriptor chain with a
NULL descriptor.
alt_avalon_sgdma_construct_mem_
to_stream_desc()
Constructs a single SG-DMA descriptor in the specied
memory for an Avalon-MM to Avalon-ST transfer.
alt_avalon_sgdma_enable_desc_
poll()
Enables descriptor polling mode. To use this feature, you need
to make sure that the hardware supports polling.
alt_avalon_sgdma_disable_desc_
poll()
Disables descriptor polling mode.
UG-01085
2016.12.19 SG-DMA API 24-17
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Name Description
alt_avalon_sgdma_check_
descriptor_status()
Reads the status of a given descriptor.
alt_avalon_sgdma_register_
callback()
Associates a user-specic callback routine with the SG-DMA
interrupt handler.
alt_avalon_sgdma_start() Starts the DMA engine. is is not required when alt_avalon_
sgdma_do_async_transfer()and alt_avalon_sgdma_do_
sync_transfer() are used.
alt_avalon_sgdma_stop() Stops the DMA engine. is is not required when alt_avalon_
sgdma_do_async_transfer()and alt_avalon_sgdma_do_
sync_transfer() are used.
alt_avalon_sgdma_open() Returns a pointer to the SG-DMA controller with the given
name.
alt_avalon_sgdma_do_async_transfer()
Prototype: int alt_avalon_do_async_transfer(alt_sgdma_dev *dev, alt_sgdma_descriptor
*desc)
read-safe: No.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to an SG-DMA device structure.
*desc—a pointer to a single, constructed descriptor. e descriptor must have its
“next” descriptor eld initialized either to a non-ready descriptor, or to the next
descriptor in the chain.
Returns: Returns 0 success. Other return codes are dened in errno.h.
Description: Set up and begin a non-blocking transfer of one or more descriptors or a
descriptor chain. If the SG-DMA controller is busy at the time of this call, the
routine immediately returns EBUSY; the application can then decide how to
proceed without being blocked. If a callback routine has been previously
registered with this particular SG-DMA controller, the transfer is set up to issue
an interrupt on error, EOP, or chain completion. Otherwise, no interrupt is
registered and the application developer must check for and handle errors and
completion. e run bit is cleared before the begining of the transfer and is set to
1 to restart a new descriptor chain.
24-18 alt_avalon_sgdma_do_async_transfer() UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
alt_avalon_sgdma_do_sync_transfer()
Prototype: alt_u8 alt_avalon_sgdma_do_sync_transfer(alt_sgdma_dev *dev, alt_sgdma_
descriptor *desc)
read-safe: No.
Available from
ISR:
Not recommended.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to an SG-DMA device structure.
*desc—a pointer to a single, constructed descriptor. e descriptor must have its
“next” descriptor eld initialized either to a non-ready descriptor, or to the next
descriptor in the chain.
Returns: Returns the contents of the status register.
Description: Sends a fully formed descriptor or list of descriptors to the SG-DMA controller
for transfer. is function blocks both before transfer, if the SG-DMA controller
is busy, and until the requested transfer has completed. If an error is detected
during the transfer, it is abandoned and the controller’s status register contents
are returned to the caller. Additional error information is available in the status
bits of each descriptor that the SG-DMA processed. e user application
searches through the descriptor or list of descriptors to gather specic error
information. e run bit is cleared before the begining of the transfer and is set
to 1 to restart a new descriptor chain.
alt_avalon_sgdma_construct_mem_to_mem_desc()
Prototype: void alt_avalon_sgdma_construct_mem_to_mem_desc(alt_sgdma_descriptor
*desc, alt_sgdma_descriptor *next, alt_u32 *read_addr, alt_u32 *write_addr, alt_
u16 length, int read_xed, int write_xed)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
UG-01085
2016.12.19 alt_avalon_sgdma_do_sync_transfer() 24-19
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Parameters: *desc—a pointer to the descriptor being constructed.
*next—a pointer to the “next” descriptor. is does not need to be a complete or
functional descriptor, but must be properly allocated.
*read_addr—the rst read address for the SG-DMA transfer.
*write_addr—the rst write address for the SG-DMA transfer.
length—the number of bytes for the transfer.
read_xed—if non-zero, the SG-DMA reads from a xed address.
write_xed—if non-zero, the SG-DMA writes to a xed address.
Returns: void
Description: is function constructs a single SG-DMA descriptor in the memory specied in
alt_avalon_sgdma_descriptor *desc for an Avalon-MM to Avalon-MM
transfer. e function sets the OWNED_BY_HW bit in the descriptor's control
eld, marking the completed descriptor as ready to run. e descriptor is
processed when the SG-DMA controller receives the descriptor and the RUN bit
is 1.
e next eld of the descriptor being constructed is set to the address in *next.
e 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 controller’s
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()
Prototype: void alt_avalon_sgdma_construct_stream_to_mem_desc(alt_sgdma_descriptor
*desc, alt_sgdma_descriptor *next, alt_u32 *write_addr, alt_u16 length_or_eop,
int write_xed)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
24-20 alt_avalon_sgdma_construct_stream_to_mem_desc() UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Parameters: *desc—a pointer to the descriptor being constructed.
*next—a pointer to the “next” descriptor. is does not need to be a complete or
functional descriptor, but must be properly allocated.
*write_addr—the rst write address for the SG-DMA transfer.
length_or_eop—the number of bytes for the transfer. If set to zero (0x0), the
transfer continues until an EOP signal is received from the Avalon-ST interface.
write_xed—if non-zero, the SG-DMA will write to a xed address.
Returns: void
Description: is function constructs a single SG-DMA descriptor in the memory specied in
alt_avalon_sgdma_descriptor *desc for an Avalon-ST to Avalon-MM transfer.
e source (read) data for the transfer comes from the Avalon-ST interface
connected to the SG-DMA controller's streaming read port.
e function sets the OWNED_BY_HW bit in the descriptor's control eld,
marking the completed descriptor as ready to run. e descriptor is processed
when the SG-DMA controller receives the descriptor and the RUN bit is 1.
e next eld of the descriptor being constructed is set to the address in *next.
e 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 controller’s
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()
Prototype: void alt_avalon_sgdma_construct_mem_to_stream_desc(alt_sgdma_descriptor
*desc, alt_sgdma_descriptor *next, alt_u32 *read_addr, alt_u16 length, int read_
xed, int generate_sop, int generate_eop, alt_u8 atlantic_channel)
read-safe: Yes.
Available
from ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
UG-01085
2016.12.19 alt_avalon_sgdma_construct_mem_to_stream_desc() 24-21
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Parameters: *desc—a pointer to the descriptor being constructed.
*next—a pointer to the “next” descriptor. is does not need to be a complete or
functional descriptor, but must be properly allocated.
*read_addr—the rst read address for the SG-DMA transfer.
length—the number of bytes for the transfer.
read_xed—if non-zero, the SG-DMA reads from a xed address.
generate_sop—if non-zero, the SG-DMA generates a SOP on the Avalon-ST
interface when commencing the transfer.
generate_eop—if non-zero, the SG-DMA generates an EOP on the Avalon-ST
interface when completing the transfer.
atlantic_channel—an 8-bit Avalon-ST channel number. Channels are currently
not supported. Set this parameter to 0.
Returns: void
Description: is function constructs a single SG-DMA descriptor in the memory specied in
alt_avalon_sgdma-descriptor *desc for an Avalon-MM to Avalon-ST transfer.
e destination (write) data for the transfer goes to the Avalon-ST interface
connected to the SG-DMA controller's streaming write port. e function sets
the OWNED_BY_HW bit in the descriptor's control eld, marking the
completed descriptor as ready to run. e descriptor is processed when the SG-
DMA controller receives the descriptor and the RUN bit is 1.
e next eld of the descriptor being constructed is set to the address in *next.
e 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 controller’s 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()
Prototype: void alt_avalon_sgdma_enable_desc_poll(alt_sgdma_dev *dev, alt_u32
frequency)
read-safe: Yes.
Available from
ISR:
Yes.
24-22 alt_avalon_sgdma_enable_desc_poll() UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
*dev—a pointer to an SG-DMA device structure.
Parameters: frequency—the 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 specic frequency. ere is no eect if
the hardware does not support this mode.
alt_avalon_sgdma_disable_desc_poll()
Prototype: void alt_avalon_sgdma_disable_desc_poll(alt_sgdma_dev *dev)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to an SG-DMA device structure.
Returns: void
Description: Disables descriptor polling mode.
alt_avalon_sgdma_check_descriptor_status()
Prototype: int alt_avalon_sgdma_check_descriptor_status(alt_sgdma_descriptor *desc)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *desc—a pointer to the constructed descriptor to examine.
Returns: Returns 0 if the descriptor is error-free, not owned by hardware, or a previously
requested transfer completed normally. Other return codes are dened in
errno.h.
Description: Checks a descriptor previously owned by hardware for any errors reported in a
previous transfer. e routine reports: errors reported by the SG-DMA
controller, the buer in use.
UG-01085
2016.12.19 alt_avalon_sgdma_disable_desc_poll() 24-23
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
alt_avalon_sgdma_register_callback()
Prototype: void alt_avalon_sgdma_register_callback(alt_sgdma_dev *dev, alt_avalon_
sgdma_callback callback, alt_u16 chain_control, void *context)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to the SG-DMA device structure.
callback—a pointer to the callback routine to execute at interrupt level.
chain_control—the SG-DMA control register contents.
*context—a pointer used to pass context-specic information to the ISR. context
can point to any ISR-specic information.
Returns: void
Description: Associates a user-specic 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. e 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 Soware Developer’s
Handbook.
To disable callbacks aer registering one, call this routine with 0x0 as the
callback argument.
alt_avalon_sgdma_start()
Prototype: void alt_avalon_sgdma_start(alt_sgdma_dev *dev)
read-safe: No.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to the SG-DMA device structure.
Returns: void
Description: Starts the DMA engine and processes the descriptor pointed to in the controller's
next descriptor pointer and all subsequent descriptors in the chain. It is not
necessary to call this function when do_sync or do_async is used.
24-24 alt_avalon_sgdma_register_callback() UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
alt_avalon_sgdma_stop()
Prototype: void alt_avalon_sgdma_stop(alt_sgdma_dev *dev)
read-safe: No.
Available from
ISR:
Yes.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: *dev—a pointer to the SG-DMA device structure.
Returns: void
Description: Stops the DMA engine following completion of the current buer descriptor. It is
not necessary to call this function when do_sync or do_async is used.
alt_avalon_sgdma_open()
Prototype: alt_sgdma_dev* alt_avalon_sgdma_open(const char* name)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_sgdma.h>, <altera_avalon_sgdma_descriptor.h>, <altera_
avalon_sgdma_regs.h>
Parameters: name—the name of the SG-DMA device to open.
Returns: A pointer to the SG-DMA device structure associated with the supplied name, or
NULL if no corresponding SG-DMA device structure was found.
Description: Retrieves a pointer to a hardware SG-DMA device structure.
UG-01085
2016.12.19 alt_avalon_sgdma_stop() 24-25
Scatter-Gather DMA Controller Core Altera Corporation
Send Feedback
Document Revision History
Table 24-16: Scatter-Gather DMA Controller Core Revision History
Date Version Changes
October 2015 2015.10.30 Updated sections:
• Register Maps: "Control Register Bit Map" table
• SG-DMA API: "Function List" table
Added sections:
• alt_avalon_sgdma_enable_desc_poll()
• alt_avalon_sgdma_disable_desc_poll()
July 2014 2014.07.24 Updated Register Maps table, included version register
December 2010 v10.1.0 Updated gure 19-4 and gure 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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 Revised descriptions of register elds and bits.
Added description to the memory-to-stream congurations.
Added descriptions to alt_avalon_sgdma_do_sync_transfer() and alt_
avalon_sgdma_do_async_transfer() API.
Added a list on error signals implementation.
March 2009 v9.0.0 Added description of Enable bursting on descriptor read master.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size.
Added section DMA Descriptors in Functional Specications
Revised descriptions of register elds and bits.
Reorganized sections Soware Programming Model and Programming
with SG-DMA Controller Core.
May 2008 v8.0.0 Added sections on burst transfers.
24-26 Document Revision History UG-01085
2016.12.19
Altera Corporation Scatter-Gather DMA Controller Core
Send Feedback
Modular Scatter-Gather DMA Core 25
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
In a processor subsystem, data transfers between two memory spaces can happen frequently. In order to
ooad the processor from moving data around a system, a Direct Memory Access (DMA) engine is
introduced to perform this function instead. e Modular Scatter-Gather DMA (mSGDMA) is capable of
performing data movement operations with preloaded instructions, called descriptors. Multiple descrip‐
tors with dierent transfer sizes, and source and destination addresses have the option to trigger
interrupts.
e mSGDMA core has a modular design that facilitates easy integration with the FPGA fabric. e core
consists of a dispatcher block with optional read master and write master blocks. e descriptor block
receives and decodes the descriptor, and dispatches instructions to the read master and write master
blocks for further operation. e block is also congured 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.
Feature Description
e mSGDMA provides three conguration structures for handling data transfers between the Avalon-
MM to Avalon-MM, Avalon-MM to Avalon-ST, and Avalon-ST to Avalon-MM modes. e sub-core of
the mSGDMA is instantiated automatically according to the structure congured for the mSGDMA use
model.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 25-1: mSGDMA Module Conguration with support for Memory-Mapped Reads and Writes
25-2 Feature Description UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Figure 25-2: mSGDMA Module Conguration with Support for Memory-Mapped Streaming Reads to the
Avalon-ST data bus
UG-01085
2016.12.19 Feature Description 25-3
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Figure 25-3: mSGDMA Module Conguration with Support for Avalon-ST Data Write Streaming to the
Memory-Mapped Bus
e 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 identication for executed descriptor.
mSGDMA Interfaces and Parameters
Interface
e mSGDMA consists of the following:
• One Avalon-MM CSR slave port.
• One congurable Avalon-MM Slave or Avalon-ST Source Response port.
• Source and destination data path ports, which can be Avalon-MM or Avalon-ST.
e mSGDMA also provides an active-high-level interrupt output.
Only one clock domain can drive the mSGDMA. e requirement of dierent clock domains between
source and destination data paths are handled by the Qsys fabric.
A hardware reset resets the whole system. Soware reset resets the registers and FIFOs of the dispatchers
of the dispatcher and master modules. For a soware reset, read the resetting bit of the status register to
determine when a full reset cycle completes.
25-4 mSGDMA Interfaces and Parameters UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Descriptor Slave Port
e descriptor slave port is write only and congurable to either 128 or 256 bits wide. e width is
dependent on the descriptor format you choose for your system. When writing descriptors to this port,
you must set the last bit high so the descriptor can be completely written to the dispatcher module. You
can access the byte lanes of this port in any order, as long as the last bit is written to during the last write
access.
Control and Status Register Slave Port
e control and status register (CSR) port is read/write accessible and is 32-bits wide. When the dispatcher
response port is disabled or set to memory-mapped mode then the CSR port is responsible for sending
interrupts to the host.
Response Port
e 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. e 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
buer in the dispatcher module. As a result, always make sure that your soware reads from the last
response address last.
When you congure the response port to an Avalon Streaming source interface, connect it to a module
capable of pre-fetching descriptors from memory. e following table shows the ST data bits and their
description.
Table 25-1: Response Source Port Bit Fields
ST Data Bits Description
31 - 0 Actual bytes transferred [31:0]
39 - 32 Error [7:0]
40 Early termination
41 Transfer complete IRQ mask
49 - 42 Error IRQ mask(9)
50 Early termination IRQ mask(9)
51 Descriptor buer full(10)
255 - 52 Reserved
(9) Interrupt masks are buered 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).
UG-01085
2016.12.19 Descriptor Slave Port 25-5
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Parameters
Table 25-2: Component Parameters
Parameter Name Description Allowable Range
DMA Mode Transfer mode of mSGDMA. is
parameter determines sub-cores
instantiation to construct the mSGDMA
structure.
Memory-Mapped to Memory-
Mapped, Memory-Mapped to
Streaming, Streaming to
Memory-Mapped
Data Width Data path width. is parameter aects
both read master and write master data
widths.
8, 16, 32, 64, 128, 256, 512, 1024
Use pre-determined
master address width
Use pre-determined master address width
instead of automatically-determined master
address width.
Enable, Disable
Pre-determined master
address width
Minimum master address width that is
required to address memory slave.
32
Expose mSGDMA read
and write master's
streaming ports
When enabled, mSGDMA read master's
data source port and mSGDMA write
master's data sink port will be exposed for
connection outside mSGDMA core.
Enable, Disable
Data Path FIFO Depth Depth of internal data path FIFO. 16, 32, 64, 128, 256, 512, 1024,
2048, 4096
Descriptor FIFO Depth FIFO size to store descriptor count. 8, 16, 32, 64, 128, 256, 512, 1024
Response Port Option to enable response port and its port
interface type
Memory-Mapped, Streaming,
Disabled
Maximum Transfer Legth Maximum transfer length. With shorter
length width being congured, the faster
frequency of mSGDMA can operate in
FPGA.
1KB, 2KB, 4KB, 8KB, 16KB,
32KB, 64KB, 128KB,256KB,
512KB, 1MB, 2MB, 4MB, 8MB,
16MB, 32MB, 64MB, 128MB,
256MB, 512MB, 1GB, 2GB
Transfer Type Supported transaction type Full Word Accesses Only,
Aligned Accesses, Unaligned
Accesses
Burst Enable Enable burst transfer Enable, Disable
Maximum Burst Count Maximum burst count 2, 4, 8, 16, 32, 64, 128, 256, 512,
1024
Force Burst Alignment
Enable
Disable force burst aligment. Force burst
alignment forces the masters to post bursts
of length 1 until the address is aligned to a
burst boundary.
Enable, Disable
25-6 Parameters UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Parameter Name Description Allowable Range
Enable Extended Feature
Support
Enable extended features. In order to use
stride addressing, programmable burst
lengths, 64-bit addressing, or descriptor
tagging the enhanced features support must
be enabled.
Enable, Disable
Stride Addressing Enable Enable stride addressing. Stride addressing
allows the DMA to read or write data that is
interleaved in memory. Stride addressing
cannot be enabled if the burst transfer
option is enabled.
Enable, Disable
Maximum Stride Words Maximum stride amount (in words) 1 – 2G
Programmable Burst
Enable
Enable dynamic burst programming Enable, Disable
Packet Support Enable Enable packetized transfer
Note: When PACKET_ENABLE
parameter is disabled and
TRANSFER_TYPE is not "Full Word
Accesses Only", any unaligned
transfer length will cause additional
bytes to be written during the last
transfer beat of the Avalon
streaming data source port of the
read master core. Only with this
parameter set TRUE, actual bytes
transferred is meaningful for the
transaction. PACKET_ENABLE only
applys for ST-to-MM and MM-to-
ST DMA operation mode.
Enable, Disable
Error Enable Enable error eld of ST interface Enable, Disable
Error Width Error eld width 1, 2, 3, 4, 5, 6, 7, 8
Channel Enable Enable channel eld of ST interface Enable, Disable
Channel Width Channel eld width 1, 2, 3, 4, 5, 6, 7, 8
Enable Pre-Fetching
module
Enables prefetcher modules, a hardware
core which fetches descriptors from
memory.
Enable, Disable
Enable bursting on
descriptor read master
Enable read burst will turn on the bursting
capabilities of the prefetcher's read
descriptor interface.
Enable, Disable
Data Width of Descriptor
read/write master data
path
Width of the Avalon-MM descriptor read/
write data path.
32, 64, 128, 256
Maximum Burst Count on
descriptor read master
Maximum burst count. Enable, Disable
UG-01085
2016.12.19 Parameters 25-7
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
mSGDMA Parameter Editor
Figure 25-4: Modular Scatter-Gather DMA Parameter Editor
mSGDMA Descriptors
e descriptor slave port is 128-bits for standard descriptors and 256-bits for extended descriptors. e
tables below show acceptable standard and extended descriptor formats.
25-8 mSGDMA Parameter Editor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Table 25-3: Standard Descriptor Format
Byte Lanes
Oset 3 2 1 0
0x0 Read Address[31:0]
0x4 Write Address[31:0]
0x8 Length[31:0]
0xC Control[31:0]
Table 25-4: Extended Descriptor Format
Byte Lanes
Oset 3 2 1 0
0x0 Read Address[31:0]
0x4 Write Address[31:0]
0x8 Length[31:0]
0xC Write Burst
Count[7:0]
Read Burst
Count [7:0]
Sequence Number[15:0]
0x10 Write Stride[15:0] Read Stride[15:0]
0x14 Read Address[63:32]
0x18 Write Address[63:32]
0x1C Control[31:0]
All descriptor elds 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: e location of the control eld is dependent on the descriptor format you used. e last bit of the
control eld commits the descriptor to the dispatcher buer when it is asserted. As a result, the
control eld is located at the end of a descriptor. is allows you to write the descriptor sequentially
to the dispatcher block.
Read and Write Address Fields
e read and write address elds correspond to the source and destination address for each buer transfer.
Depending on the transfer type, you do not need to provide the read or write address. When performing
memory-mapped to transfers, the write address must not be written as there is no destination address.
ere is no destination address since the data is being transfer to a streaming port. Likewise, when
performing streaming to memory-mapped transfers, the read address must not be written as the data
source is a streaming port.
If a read or write address descriptor is written in a conguration that does not require it, the mSGDMA
ignores the unnecessary address. If a standard descriptor is used and an attempt to write a 64-bit address is
made, the upper 32 bits are lost and can cause the hardware to alias a lower address space. 64-bit
addressing requires the use of the extended descriptor format.
UG-01085
2016.12.19 Read and Write Address Fields 25-9
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Length Field
e length eld is used to specify the number of bytes to transfer per descriptor. e length eld is also
used for streaming to memory-mapped packet transfers. is 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 eld.
If you do not wish to limit packet based transfers in the case of Avalon-ST to Avalon-MM transfers,
program the length eld with the largest possible value of 0xFFFFFFFF. is method allows you to specify
a maximum packet size for each descriptor that has packet support enabled.
Sequence Number Field
e sequence number eld is available only when using extended descriptors.e sequence number is an
arbitrary value that you assign to a descriptor, so that you can determine which descriptor is being
operated on by the read and write masters. When performing memory-mapped to memory-mapped
transfers, this value is tracked independently for masters since each can be operating on a dierent
descriptor. To use this functionality, program the descriptors with unique sequence numbers. en, access
the dispatcher CSR slave port to determine which descriptor is operated on.
Read and Write Burst Count Fields
e programmable read and write burst counts are only available when using the extended descriptor
format. e programmable burst count is optional and can be disabled in the read and write masters.
Because the programmable burst count is an eight bit eld for each master, the maximum that you can
program burst counts of 1 to 128. Programming a value of zero or anything larger than 128 beats will be
converted to the maximum burst count specied for each master automatically.
e maximum programmable burst count is 128 but when you instantiate the DMA, you can have
dierent selections up to 1024. Refer to the MAX_BURST_COUNT parameter in the parameter table. You
will still have a burst count of 128 if you program for greater than 128. Programing to 0, gets the
maximum burst count selected during instantiation time.
Related Information
Parameters on page 25-6
For more information, refer to the MAX_BURST_COUNT parameter.
Read and Write Stride Fields
e read and write stride elds are optional and only available when using the extended descriptor format.
e stride value determines how the read and write masters increment the address when accessing
memory. e stride value is in terms of words, so the address incrementing is dependent on the master
data width.
When stride is enabled, the master defaults to sequential accesses, which is the equivalent to a stride
distance of one. A stride of zero instructs the master to continuously access the same address. A stride of
two instructs the master to skip every other word in a sequential transfer. You can use this feature to
perform interleaved data accesses, or to perform a frame buer row and column transpose. e read and
write stride distances are stored independently allowing, you to use dierent address incrementing for
read and write accesses in memory-to-memory transfers. For example, to perform a 2:1 data decimation
transfer, you would simply congure the read master for a stride distance of two and the write master for a
stride distance of one. To complete the decimation operation you could also insert a lter between the two
masters.
25-10 Length Field UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Control Field
e control eld is available for both the standard and extended descriptor formats. is eld can be
programmed to congure parked descriptors, error handling, and interrupt masks. e interrupt masks
are programmed into the descriptor so that interrupt enables are unique for each transfer.
Table 25-5: Descriptor Control Field Bit Denition
Bit Sub-Field Name Denition
31 Go Commits all the descriptor information into the descriptor
FIFO.
As the host writes dierent elds in the descriptor, FIFO byte
enables are asserted to transfer the write data to appropriate
byte locations in the FIFO.
However, the data written is not committed until the go bit has
been written.
As a result, ensure that the go bit is the last bit written for each
descriptor.
Writing '1' to the go bit commits the entire descriptor into the
descriptor FIFO(s).
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.
is bit is most eective for hiding high read latency. For
example, it reads from SDRAM, PCIe, and SRIO.
23:16 Transmit Error / Error IRQ
Enable For for Avalon-MM to Avalon-ST transfers, this eld is used to
specify a transmit error.
is eld 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 eld 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.
UG-01085
2016.12.19 Control Field 25-11
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Bit Sub-Field Name Denition
15 Early Termination IRQ
Enable Signals an interrupt to the host when a Avalon-ST to Avalon-
MM transfer completes early.
For example, if you set this bit and set the length eld to 1MB
for Avalon-ST to Avalon-MM transfers, this interrupt asserts
when more than 1MB of data arrives to the write master
without the end of packet being seen.
14 Transfer Complete IRQ
Enable Signals an interrupt to the host when a transfer completes.
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.
is bit is commonly set for packet-based trac 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
buered.
10 Park Reads When set, the dispatcher continues to reissue the same
descriptor to the read master when no other descriptors are
buered. is is commonly used for video frame buering.
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 rst 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
e stop DMA operation is also referring to stop dispatcher. Once the “stop DMA” 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. e command buer in both the read master and write master must
25-12 Programming Model UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
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 DMA” 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.
Stop Descriptor Operation
e Stop Descriptor temporary stops the dispatcher core from continuing to issue commands to the read
master and write master. e dispatcher core operates in the sense that it can accept a descriptor sent by
the host up to its descriptor FIFO limit. Proceed with the follwing steps for the stop descriptor operation:
1. Set “Stop Descriptor” bit of Control Register.
2. Check if “Stopped” bit of Status Register is asserted.
To resume DMA from its previously stop descriptor operation, do the following:
1. Unset the “Stop Descriptor” bit of Control Register.
2. Check if “Stopped” bit of Status Register is deasserted.
Recovery from Stopped on Error and Stopped on Early Termination
When stopped on error or stopped on early termination occurs, mSGDMA requires a soware reset to
continue operation.
1. When the “Stopped” bit of the Status register is asserted, reset the DMA by setting the “Reset
Dispatcher” bit of Control register.
2. Check if the “Resetting” bit of Status register is deasserted. If it is, DMA is now back in normal
operation.
Register Map of mSGDMA
e following table illustrates the Altera mSGDMA register map under observation by host processor
from its Avalon-MM CSR interfaces.
Table 25-6: CSR Registers Map
Byte Lanes
Oset Attribute 3 2 1 0
0x0 Read/Clear Status
0x4 Read/Write Control
0x8 Read Write Fill Level[15:0] Read Fill Level[15:0]
0xC Read <reserved>(11) Response Fill Level[15:0]
(11) Writing to reserved bits will have no impact on the hardware, reading will return unknown data.
UG-01085
2016.12.19 Stop Descriptor Operation 25-13
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Byte Lanes
0x10 Read Write Sequence
Number[15:0](12)
Read Sequence Number[15:0]2
0x14 N/A <reserved>1
0x18 N/A <reserved>1
0x1C N/A <reserved>1
Status Register
Table 25-7: Status Register Bit Denition
Bit Name Description
31:10 <reserved> N/A
9 IRQ Set when an interrupt condition occurs.
8 Stopped on Early
Termination
When the dispatcher is programmed to stop on early termination, this bit is set.
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 eld. 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 soware reset register and the SGDMA is in the
middle of a reset cycle. is 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 aer the master completes any
read or write operations that were already in progress.
4 Response Buer
Full
Set when the response buer is full.
3 Response Buer
Empty
Set when the response buer is empty.
2 Descriptor Buer
Full
Set when either the read or write command buers are full.
1 Descriptor Buer
Empty
Set when both the read and write command buers are empty.
0 Busy Set when the dispatcher still has commands buered, or one of the masters is
still transferring data.
(12) Sequence numbers will only be present when dispatcher enhanced features are enabled.
25-14 Status Register UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Control Register
Table 25-8: Control Register Bit Denition
Bit Name Description
31:10 <reserved> N/A
5 Stop Descriptors Setting this bit stops the SGDMA dispatcher from issuing more descriptors to
the read or write masters. Read the stopped status register to determine when
the dispatcher stopped issuing commands and the read and write masters are
idle.
4 Global Interrupt
Enable Mask
Setting this bit allows interrupts to propagate to the interrupt sender port. is
mask occurs aer the register logic so that interrupts are not missed when the
mask is disabled.
3 Stop on Early
Termination
Setting this bit stops the SGDMA from issuing more read/write commands to
the master modules if the write master attempts to write more data than the
user species in the length eld for packet transactions. e length eld is used
to limit how much data can be sent and is always enabled for packet based
writes.
2 Stop on Error Setting this bit stops the SGDMA from issuing more read/write commands to
the master modules if an error enters the write master module sink port.
1 Reset Dispatcher Setting this bit resets the registers and FIFOs of the dispatcher and master
modules. Since resets can take multiple clock cycles to complete due to
transfers being in ight on the fabric, you should read the resetting status
register to determine when a full reset cycle has completed.
0 Stop Dispatcher Setting this bit stops the SGDMA in the middle of a transaction. If a read or
write operation is occurring, then the access is allowed to complete. Read the
stopped status register to determine when the SGDMA has stopped. Aer reset,
the dispatcher core defaults to a start mode of operation.
e response slave port of mSGDMA contains registers providing information of the executed transaction.
is 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 buers responses. When
setup as a memory-mapped slave port, reading byte oset 0x7 outputs the response. If the response FIFO
becomes full the dispatcher stops issuing transfer commands to the read and write masters. e following
describes the registers denition.
Table 25-9: Response Registers Map
Byte Lanes
Oset Access 3 2 1 0
0x0 Read Actual Bytes Transferred[31:0]
UG-01085
2016.12.19 Control Register 25-15
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Byte Lanes
Oset Access 3 2 1 0
0x4 Read <reserved>(13) <reserved> Early
Termination(14
)
Error[7:0]
e following list explains each of the elds:
•Actual bytes transferred determines how many bytes transferred when the mSGDMA is congured in
Avalon-ST to Avlaon-MM mode with packet support enabled. Since packet transfers are terminated by
the IP providing the data, this eld counts the number of bytes between the start-of-packet (SOP) and
end-of-packet (EOP) received by the write master. If the early termination bit of the response is set,
then the actual bytes transferred is an underestimate if the transfer is unaligned.
•Error Determines if any errors were issued when the mSGDMA is congured in Avalon-ST to Avlaon-
MM mode with error support enabled. Each error bit is persistent so that errors can accumulate
throughout the transfer.
•Early Termination determines if a transfer terminates because the transfer length is exceeded when
the SGDMA is congured in Avalon-ST to Avalon-MM mode with packet support enabled. is bit is
set when the number of bytes transferred exceeds the transfer length set in the descriptor before the
end-of-packet is received by the write master.
(13) Reading from byte 7 outputs the response FIFO.
(14) Early Termination is a single bit located at bit 8 of oset 0x4.
25-16 Control Register UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Modular Scatter-Gather DMA Prefetcher Core
e mSGDMA Prefetcher core is an additional micro core to the existing mSGDMA core. e Prefetcher
core provides extra functionality through the Avalon-MM and dispatcher core. e Avalon-MM fetches a
series of descriptors from memory that describes the required data transfers before passing them to
dispatcher core for data transfer execution. e series of descriptors in memory can be linked together to
form a descriptor list. is allows the DMA core to execute multiple descriptors in single run, thus
enabling transfer to a non-contiguous memory space and improves system performance.
Feature Description
Supported Features
• Descriptor linked list
• Data transfer to non-contiguous memory space
• Descriptor write back
• Hardware descriptor polling
• 64-bit address spaces
Functional Description
Architecture Overview
e Prefetcher core supports all the three existing Modular SGDMA congurations:
• 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 conguration
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.
UG-01085
2016.12.19 Modular Scatter-Gather DMA Prefetcher Core 25-17
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Figure 25-5: Memory-Mapped to Memory-Mapped Conguration with Prefetcher Enabled
Read MasterM
SRC
SRC
SNK
Write MasterM
SRC
SNK
SNK
Dispatcher
S
SNK SRC
SNK
SRC
SNK SRC
Read Response Read Command
Write Response Write Command
ST Data
MM Read Data
MM Write Data
Prefetcher
S
M
MSNK
SRC
Host
Descriptors
Response
CSR
CSR
MM Read
Descriptors
MM Write
Descriptors
IRQ
25-18 Architecture Overview UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Figure 25-6: Memory-Mapped to Streaming Conguration with Prefetcher Enabled
Read MasterM
SRC
SRC
SNK
Dispatcher
S
SNK SRC
SNK
SRC
Read Response Read Command
MM Read Data
Prefetcher
S
M
MSNK
SRC
Host
Descriptors
Response
CSR
CSR
MM Read
Descriptors
MM Write
Descriptors
ST Data
IRQ
UG-01085
2016.12.19 Architecture Overview 25-19
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Figure 25-7: Streaming to Memory-Mapped Conguration with Prefetcher Enabled
Write MasterM
SRC
SNK
SNK
Dispatcher
S
SNK
SRC
SNK SRC
Write Response Write Command
MM Write Data
Prefetcher
S
M
MSNK
SRC
Host
Descriptors
Response
CSR
CSR
MM Read
Descriptors
MM Write
Descriptors
ST Data
IRQ
Descriptor Format
e mSGDMA without the Prefetcher core denes 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.
Table 25-10: Standard Descriptor Format when Prefetcher is Enabled
Byte Lanes
Oset 3 2 1 0
0x0 Read Address [31-0]
0x4 Write Address [31-0]
0x8 Length [31-0]
0xC Next Desc Ptr [31-0]
0x10 Actual Bytes Trasferred [31-0]
0x14 Reserved [15-0] Status [15-0]
0x18 Reserved [31-0]
25-20 Descriptor Format UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
0x1C Control [31, 30, 29..0]
Table 25-11: Extended Descriptor Format when Prefetcher is Enabled
Byte Lanes
Oset 3 2 1 0
0x0 Read Address [31-0]
0x4 Write Address [31-0]
0x8 Length [31-0]
0xC Next Desc Ptr [31-0]
0x10 Actual Bytes Trasferred [31-0]
0x14 Reserved [15-0] Status [15-0]
0x18 Reserved [31-0]
0x1C Write Burst Count
[7-0]
Read Burst Count
[7-0]
Sequence Number [15-0]
0x20 Write Stride [15-0] Read Stride [15-0]
0x24 Read Address [63-32]
0x28 Write Address [63-32]
0x2C Next Desc Ptr [63-32]
0x30 Reserved [31-0]
0x34 Reserved [31-0]
0x38 Reserved [31-0]
0x3C Control [31, 30, 29..0]
Descriptor Fields Denition
Next Descriptor Pointer
e next descriptor pointer eld species the address of the next descriptor in the linked list.
Actual Bytes Transferred
Species the actual number of bytes that has been transferred. is eld is not applicable if Modular
SGDMA is congured as Memory-Mapped to Streaming transfer.
Table 25-12: Status
Bits Fields Description
15:9 Reserved Reserved elds
UG-01085
2016.12.19 Descriptor Fields Denition 25-21
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Bits Fields Description
8 Early Termination Indicates early termination condition where write master is
performing a packet transfer and does not receive EOP before pre-
determined amount of bytes are transferred. is status bit is
similar to status register bit 8 of the dispatcher core. For more
details refer to dispatcher core CSR denition.
is eld is not applicable if Modular SGDMA is congured as
Memory-Mapped to Streaming transfer.
7:0 Error Indicates an error has arrived at the write master streaming sink
port.
is eld is not applicable if Modular SGDMA is congured as
Memory-Mapped to Streaming transfer.
Table 25-13: Control
Bits Fields Description
30 Owned by Hardware is eld determines whether hardware or soware has write
access to the current descriptor.
When this eld is set to 1, the Modular SGDMA can update the
descriptor and soware should not access the descriptor due to the
possibility of race conditions. Otherwise, it is safe for soware to
update the descriptor.
For bit 31 and 29:0, refer to descriptor control eld bit 31 and 29:0 dened in dispatcher core. Table 25-5
Descriptor Processing
e 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. e mSGDMA has an internal FIFO to store descriptors read from memory. is
FIFO is located in the dispatcher’s core. e descriptors must be initialized and aligned on a descriptor
read/write data width boundary. e 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 elds of the descriptor in memory (descriptor write back). e Owned by Hardware bit in the
descriptor control eld is cleared by the core during descriptor write back. Refer to soware 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 buered in Prefetcher core. is buer depth will be similar
to descriptor FIFO depth in dispatcher core. is information is taken out from buer each time a
response is received from dispatcher.
25-22 Descriptor Processing UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Registers
Register Map
Table 25-14: Register Map
Name Address Oset Description
Control 0x0 Species the Prefetcher core behavior such
as when to start the core.
Next Descriptor Pointer
Low
0x1 Contains the address [31:0] of the next
descriptor to process. Soware sets this
register to the address of the rst descriptor
as part of the system initialization sequence.
If descriptor polling is enabled, this register
is also updated by hardware to store the
latest next descriptor address. e latest
next descriptor address is used by the
Prefetcher core to perform descriptor
polling.
Next Descriptor Pointer
High
0x2 Contains the address [63:32] of the next
descriptor to process. Soware set this
register to the address of the rst descriptor
as part of the system initialization sequence.
is eld is used only when higher than 32-
bit addressing is used when mSGDMA’s
extended feature is enabled.
If descriptor polling is enabled, this register
is also updated by hardware to store the
latest next descriptor address. e latest
next descriptor address is used by the
Prefetcher core to perform descriptor
polling.
Descriptor Polling
Frequency
0x3 Descriptor Polling Frequency
Status 0x4 Status Register
Control Register
e address oset for the Control Register table is 0x0.
Table 25-15: Control Register
Bit Fields Access Default Value Description
31:5 Reserved R 0x0 Reserved elds
UG-01085
2016.12.19 Registers 25-23
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
4 Park Mode R/W 0x0 is bit enables the mSGDMA to
repeatedly execute the same linked
list over and over again. In order for
this to work, soware need to setup
the last descriptor to point back to
the rst descriptor.
1: Park mode is enabled. Pefetcher
will not clear the owned by
hardware eld during descriptor
write back
0: Park mode is disabled. Prefetcher
will clear the owned by hardware
eld during descriptor write back.
Soware can terminate the park
mode operation by clearing this
eld. Since this eld is in CSR and
not in descriptor eld itself, this
termination event is asynchronous
to current descriptor in progress
(user can’t deterministically choose
which descriptor in the linked list to
stop).
Park mode feature is not intended
to be used on the y. User must not
enable this bit when the Prefetcher
is already in operation. is bit shall
be set during initialization/congu‐
ration phase of the control register.
3Global Interrupt Enable
Mask
R/W 0x0 Setting this bit will allow interrupts
to propagate to the interrupt sender
port. is mask occurs aer the
register logic so that interrupts are
not missed when the mask is
disabled.
Note: ere is an equivalent
global interrupt enable
mask bit in dispatcher
core CSR. When the
Prefetcher is enabled,
soware shall use this
bit. When the Prefetcher
is disabled, soware shall
use equivalent global
interrupt enable mask bit
in dispatcher core CSR.
25-24 Control Register UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Bit Fields Access Default Value Description
2 Reset_Prefetcher R/W1S(15) 0x0 is bit is used when soware
intends to stop the Prefetcher core
when it is in the middle of data
transfer. When this bit is 1, the
Prefetcher core begin its reset
sequence.
is bit is automatically cleared by
hardware when the reset sequence
has completed. erefore, soware
need to poll for this bit to be cleared
by hardware to ensure the reset
sequence has nished.
is function is intended to be used
along with reset dispatcher function
in dispatcher core. Once the reset
sequence in the Prefetcher core has
completed, soware is expected to
reset the dispatcher core, polls for
dispatcher’s reset sequence to be
completed by reading dispatcher
core status register.
UG-01085
2016.12.19 Control Register 25-25
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
1 Desc_Poll_En R/W 0x0 Descriptor polling enable bit.
1: When the last descriptor in
current linked list has been
processed, the Prefetcher core polls
the Owned By Hardware bit of next
descriptor to be set and automati‐
cally resumes data transfer without
the need for soware to set the Run
bit. e polling frequency is
specied in Desc_Poll_Freq register.
0: When the last descriptor in
current linked list has been
processed, the Prefetcher stops
operation and clears the run bit. In
order to restart the DMA engine,
soware need to set the Run bit
back to 1.
In case soware intends to disable
polling operation in the middle of
transfer, soware can write this eld
to 0. In this case, the whole
mSGDMA operation is stopped
when the Prefetcher core encounter
owned by hardware bit = 0.
Note: is bit should be set
during initialization or
conguration of the
control register.
25-26 Control Register UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Bit Fields Access Default Value Description
0 Run R/W1S 0x0 Soware sets this bit to 1 to start the
descriptor fetching operation which
subsequently initiates the DMA
transaction.
When descriptor polling is disabled,
this bit is automatically cleared by
hardware when the last descriptor
in the descriptor list has been
processed or when the Prefetcher
core read owned by hardware bit =
0.
When descriptor polling is enabled,
mSGDMA operation is continu‐
ously run. us the run bit stays 1.
is eld is also cleared by
hardware when reset sequence
process triggered by Reset_
Prefetcher bit completes.
Descriptor Polling Frequency
Table 25-16: Desc_Poll_Freq
Bit Fields Access Default Description
31:16 Reserved R 0x0 Reserved elds
15:0 Poll_Freq R/W 0x0 Species the frequency of
descriptor polling
operation. e polling
frequency is in term of
number of clock cycles.
e poll period is counted
from the point where read
data is received by the
Prefetcher core.
Status
Table 25-17: Status
Bit Fields Access Default Value Description
31:1 Reserved R 0x0 Reserved elds
(15) W1S register attribute means, soware can write 1 to set the eld. Soware write 0 to this eld has no eect.
UG-01085
2016.12.19 Descriptor Polling Frequency 25-27
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
0 IRQ R/W1C(16) 0x0 Set by hardware when an
interrupt condition
occurs. Soware must
perform a write 1 to this
eld in order to clear it.
ere is an equivalent
IRQ status bit in the
dispatcher core CSR.
When the Prefetcher is
enabled, soware uses this
bit as an IRQ status
indication. When the
Prefetcher is disabled,
soware uses equivalent
IRQ status bit in
dispatcher core CSR.
Interfaces
Avalon-MM Read Descriptor
is interface is used to fetch descriptors in memory. It supports non-burst or burst mode which congu‐
rable during generation time.
Table 25-18: Avalon-MM Read Descriptor
Signal Role Width Description
Address 32 to 64-bit Avalon-MM read address.
32-bits if extended feture is disabled.
32- to 64-bits if extended feature is enabled.
Read 1 Avalon-MM read control
Read data 32, 64, 128, 256, 512 Avalon-MM read data bus. Data width is
congurable during IP generation.
Wait request 1 Avalon-MM wait request for backpressure
control.
Read data valid 1 Avalon-MM read data valid indication.
(16) W1C register attribute means, soware write 1 to clear the eld. Soware write 0 to this eld has no eect.
25-28 Interfaces UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Signal Role Width Description
Burstcount 1/2/3/4/5 Avalon-MM burst count. e maximum
burst count is congurable during IP
generation.
is signal role is applicable only when the
Enable Bursting on the descriptor read
master is turned on.
Avalon-MM Write Descriptor
is interface is used to access the Prefetcher CSR registers. It has xed write and read wait time of 0 cycles
and read latency of 1 cycle.
Table 25-19: Avalon-MM Write Descriptor
Signal Role Width Description
Address 32 to 64 Avalon-MM write address
Write 1 Avalon-MM read control
Wait request 1 Avalon-MM waitrequest for backpressure
control
Write data 32, 64, 128, 256, 512 Avalon-MM write data bus
Byte enable 4, 8, 16, 32, 64 Avalon-MM write byte enable control. Its
width is automatically derived from selected
data width
Avalon-MM CSR
is interface is used to access the Prefetcher CSR registers. It has xed write and read wait time of 0 cycles
and read latency of 1 cycle.
Table 25-20: Avalon-MM CSR
Signal Role Width Description
Address 3 Avalon-MM write address
Write 1 Avalon-MM read control
Read 1 Avalon-MM write control
Write data 32 Avalon-MM write data bus
Read data 32 Avalon-MM read data bus
Avalon-ST Descriptor Source
is interface is used by the Prefetcher to write descriptor information into the dispatcher core.
UG-01085
2016.12.19 Avalon-MM Write Descriptor 25-29
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Table 25-21: Avalon-ST Descriptor Source
Signal Role Width Description
Valid 1 Avalon-ST valid control
Ready 1 Avalon-ST ready control with ready latency
of 0. Refer to dispatcher's descriptor format
for wrtie data denition.
Data 128/256 Avalon-ST data bus
Avalon-ST Response
is interface is used by the Prefetcher core to retrieve response information from dispatcher’s core upon
each transfer completion.
Table 25-22: Avalon-ST Response
Signal Role Width Description
Valid 1 Avalon-ST valid control.
Prefetcher core expects valid signal to
remain high while the bus is being back
pressured.
Ready 1 Avalon-ST ready control. Used by the
Prefetcher core to back pressure the external
ST response source.
Data 256 Avalon-ST data bus. Refer to dispatcher’s
response source format for ST data
denition.
Prefetcher core expects data signals to
remain constant while the bus is being back
pressured.
Streaming interface (ST) data bus format and denition are similar to the dispatcher’s response source
format:
Table 25-23: Avalon-ST Response Data Format and Denition
Bits Signal Information
[31:0] Acutal bytes transferred [31:0]
[39:32] Error [7:0]
40 Early termination
41 Transfer complete IRQ mask
[49:42] Error IRQ mask
50 Early termination IRQ mask
25-30 Avalon-ST Response UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
Bits Signal Information
51 Descriptor buer full
[255:52] Reserved
IRQ Interface
When the Prefetcher is enabled, IRQ generation no longer outputs from the dispatcher’s core. It will be
outputted from the Prefetcher core. e 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. is 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 dened in
dispatcher core are now dened in the Prefetcher core as well. ese two bits need to be dened in the
Prefetcher core since the actual IRQ register is now located in the Prefetcher core.
Software Programming Model
Setting up Descriptor and mSGDMA Conguration Flow
e following is the recommended soware ow to setup the descriptor and conguring the mSGDMA.
1. Build the descriptor list and terminate the list with a non-hardware owned descriptor (Owned By
Hardware = 0).
2. Congure mSGDMA by accessing dispatcher core control register (for example: to congure Stop on
Error, Stop on Early Termination, etc…)
3. Congure mSGDMA by accessing the Prefetcher core conguration register (for example: to write the
address of the rst descriptor in the rst list to the next descriptor pointer register and set the Run bit
to 1 to initiate transfers).
4. While the core is processing the rst list, your soware may build a second list of descriptors.
5. An IRQ can be generated each time a descriptor transfer is completed (depends whether transfer
complete IRQ mask is set for that particular descriptor). If you only need an IRQ to be generated when
mSGDMA nishes processing the rst list, you only need to set transfer complete IRQ mask for the last
descriptor in the rst list.
6. When the last descriptor in the rst linked list has been processed, an IRQ will be generated if the
descriptor polling is disabled. Following this, your soware needs to update the next descriptor pointer
register with the address of the rst descriptor in the second linked list before setting the run bit back
to 1 to resume transfers. If descriptor polling is enabled, soware does not need to update the next
descriptor pointer register (for second descriptor linked list onwards) and set the run bit back to 1.
ese 2 steps are automatically done by hardware. e address of the new list is indicated by next
descriptor pointer elds of the previous list. e Prefetcher core polls for the Owned by Hardware bit to
be 1 in order to resume transfers. Soware only needs to ip the Owned by Hardware bit of the rst
descriptor in second linked list to 1 to indicate to the Prefetcher core that the second linked list is ready.
7. If there are new descriptors to add, always add them to the list which the core is not processing
(indicated by Owned By Hardware = 0). For example, if the core is processing the rst list, add new
descriptors to the second list and so forth. is method ensures that the descriptors are not updated
when the core is processing them. Your soware can read the descriptor in the memory to know the
status of the transfer (for example; to know the actual bytes being transferred, any error in the transfer).
UG-01085
2016.12.19 IRQ Interface 25-31
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Resetting Prefetcher Core Flow
e following is the recommended ow for soware to stop the mSGDMA when it is in the middle of
operation.
1. Write 1 to the Prefetcher control register bit 2 (Reset_Prefetcher bit set to 1).
2. Poll for control register bit 2 to be 0 (Reset_Prefetcher bit cleared by hardware).
3. Trigger soware reset condition in the dispatcher core.
4. Poll for soware reset condition in the dispatcher core to be completed by reading the dispatcher core
status register.
5. e whole reset ow has completed, soware can recongure the mSGDMA.
Parameters
Table 25-24: Prefetcher Parameters
Name Legal Value Description
Enable Pre-fetching
Module
1 or 0 1: Pre-fetching is enabled
0: Pre-fetching is disabled
Enable bursting on
descriptor read master
1 or 0 1: Pre-fetching module uses Avalon-MM
bursting when fetching descriptors.
Data Width (Avalon-MM
Read/Write Descriptor)
32, 64, 128, 256, 512 Species the read and write data width of
Avalon-MM read and write descriptor
master.
Maximum Burst Count
(Avalon-MM Read
Descriptor)
1, 2, 4, 8, 16 Species the maximum read burst count of
Avalon-MM read descriptor master.
Enable Extended Feature
Support
1 or 0 is is a derived parameter from the
mSGDMA top level composed. is is
needed by this core to determine descriptor
length (dierent length for standard/
extended descriptor).
FIFO Depth 8, 16, 32, 64, 128, 256, 512,
1024
is is a derived parameter from the
mSGDMA top level composed. is is
needed by this core to determine its buer
depth to store next descriptor pointer
information for descriptor write back.
25-32 Resetting Prefetcher Core Flow UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
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 dene
your own specic 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
Table 25-25: alt_msgdma_standard_descriptor_async_transfer
Prototype: int alt_msgdma_standard_descriptor_async_transfer(alt_msgdma_dev *dev, alt_
msgdma_standard_descriptor *desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to msgdma instance.
*desc — a pointer to a standard descriptor structure
Returns: “0” for success, –ENOSPC indicates FIFO buer is full, –EPERM indicates
operation not permitted due to descriptor type conict, -ETIME indicates Time out
and skipping the looping aer 5 msec.
Description: A descriptor needs to be constructed and passing as a parameter pointer to *desc
when calling this function. is 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 buer 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 the descriptor to the dispatcher takes longer than 5 msec. You are advised to
refer to 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.
UG-01085
2016.12.19 Driver Implementation 25-33
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_extended_descriptor_async_transfer
Table 25-26: alt_msgdma_extended_descriptor_async_transfer
Prototype: int alt_msgdma_extended_descriptor_async_transfer(alt_msgdma_dev *dev, alt_
msgdma_extended_descriptor *desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to mSGDMA instance.
*desc — a pointer to an extended descriptor structure
Returns: “0” for success, –ENOSPC indicates FIFO buer is full, –EPERM indicates
operation not permitted due to descriptor type conict, -ETIME indicates time out
and skipping the looping aer 5 msec.
Description: A descriptor needs to be constructed and passing as a parameter pointer to the *desc
when calling this function. is 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 buer 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.
25-34 alt_msgdma_extended_descriptor_async_transfer UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_descriptor_async_transfer
Table 25-27: alt_msgdma_descriptor_async_transfer
Prototype: static int alt_msgdma_descriptor_async_transfer(alt_msgdma_dev *dev, alt_
msgdma_standard_descriptor *standard_desc, alt_msgdma_extended_descriptor
*extended_desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to mSGDMA instance.
*standard_desc — Pointer to single standard descriptor.
*extended_desc — Pointer to single extended descriptor.
Returns: “0” for success, –ENOSPC indicates FIFO buer is full, –EPERM indicates
operation not permitted due to descriptor type conict, -ETIME indicates Time out
and skipping the looping aer 5 msec.
Description: Helper functions for both “alt_msgdma_standard_descriptor_async_transfer” and
“alt_msgdma_extended_descriptor_async_transfer”.
Note: Either one of both *standard_desc and *extended_desc must be assigned
with NULL, another with proper pointer value. Failing to do so can cause
the function return with "-EPERM ".
If a callback routine has been previously registered with this particular mSGDMA
controller, the transfer will be set up to enable interrupt generation. It is the
responsibility of the application developer to check source interruption, status
completion and creating suitable interrupt handling.
Note: "stop on error" of the CSR control register is always masking within this
function. e CSR control can be set by user through calling "alt_
register_callback" with user dened control setting.
UG-01085
2016.12.19 alt_msgdma_descriptor_async_transfer 25-35
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_standard_descriptor_sync_transfer
Table 25-28: alt_msgdma_standard_descriptor_sync_transfer
Prototype: int alt_msgdma_standard_descriptor_sync_transfer(alt_msgdma_dev *dev, alt_
msgdma_standard_descriptor *desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to mSGDMA instance.
*desc — a pointer to a standard descriptor structure
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 conict.
“-ETIME” indicates Time out and skipping the looping aer 5 msec.
Description: A standard descriptor needs to be constructed and passing as a parameter pointer to
*desc when calling this function. is function will call helper function “alt_
msgdma_descriptor_sync_transfer” to start a blocking transfer of one standard
descriptor at a time. If the FIFO buer for a read or write is full at the time of this
call, the routine will wait until a free FIFO buer is available to continue processing
or a 5 msec time out. e function will return “error” if errors or conditions causing
the dispatcher to stop issuing the commands to both the read and write masters
before both the read and write command buers are empty. It is the responsibility of
the application developer to check errors and completion status.
25-36 alt_msgdma_standard_descriptor_sync_transfer UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_extended_descriptor_sync_transfer
Table 25-29: alt_msgdma_extended_descriptor_sync_transfer
Prototype: int alt_msgdma_extended_descriptor_sync_transfer(alt_msgdma_dev *dev, alt_
msgdma_extended_descriptor *desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to msgdma instance.
*desc — a pointer to an extended descriptor structure
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 conict.
“-ETIME” indicates Time out and skipping the looping aer 5 msec.
Description: An extended descriptor needs to be constructed and passing as a parameter pointer
to *desc when calling this function. is function will call helper function “alt_
msgdma_descriptor_sync_transfer” to startcommencing a blocking transfer of one
extended descriptor at a time. If the FIFO buer for one of read or write is full at the
time of this call, the routine will wait until free FIFO buer available for continue
processing or 5 msec time out. e function will return “error” if errors or
conditions causing the dispatcher stop issuing the commands to both read and write
masters before both read and write command buers are empty. It is the responsi‐
bility of the application developer to check errors and completion status. -ETIME
will be returned if the time spending for waiting the FIFO buer, writing descriptor
to the dispatcher and any pending transfer to complete take longer than 5msec.
UG-01085
2016.12.19 alt_msgdma_extended_descriptor_sync_transfer 25-37
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_descriptor_sync_transfer
Table 25-30: alt_msgdma_descriptor_sync_transfer
Prototype: int alt_msgdma_descriptor_sync_transfer(alt_msgdma_dev *dev, alt_msgdma_
standard_descriptor *standard_desc, alt_msgdma_extended_descriptor *extended_
desc)
Include: < modular_sgdma_dispatcher.h >, < altera_msgdma_csr_regs.h>, <altera_msgdma_
descriptor_regs.h>, <sys/alt_errno.h>, <sys/alt_irq.h>, <io.h>
Parameters: *dev — a pointer to msgdma instance.
*standard_desc — Pointer to single standard descriptor.
*extended_desc — Pointer to single extended descriptor.
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 conict.
“-ETIME” indicates Time out and skipping the looping aer 5 msec.
Description: Helper functions for both “alt_msgdma_standard_descriptor_sync_transfer” and
“alt_msgdma_extended_descriptor_sync_transfer”.
Note: Either one of both *standard_desc and *extended_desc must be assigned
with NULL, another with proper pointer value. Failing to do so can cause
the function return with "-EPERM .
Note: "stop on error" of CSR control register is always being masked and the
interrupt is always disabled within this function. e CSR control can be
set by user through calling "alt_register_callback" with user dened
control setting.
25-38 alt_msgdma_descriptor_sync_transfer UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_construct_standard_st_to_mm_descriptor
Table 25-31: alt_msgdma_construct_standard_st_to_mm_descriptor
Prototype: int alt_msgdma_construct_standard_st_to_mm_descriptor (alt_msgdma_dev *dev,
alt_msgdma_standard_descriptor *descriptor, alt_u32 *write_address, alt_u32
length, alt_u32 control)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to a standard descriptor structure.
*write_address – a pointer to the base address of the destination memory.
length - is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
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.
UG-01085
2016.12.19 alt_msgdma_construct_standard_st_to_mm_descriptor 25-39
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_construct_standard_mm_to_st_descriptor
Table 25-32: alt_msgdma_construct_standard_mm_to_st_descriptor
Prototype: int alt_msgdma_construct_standard_mm_to_st_descriptor (alt_msgdma_dev *dev,
alt_msgdma_standard_descriptor *descriptor, alt_u32 *read_address, alt_u32
length, alt_u32 control)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to a standard descriptor structure.
*read_address – a pointer to the base address of the source memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
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.
25-40 alt_msgdma_construct_standard_mm_to_st_descriptor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_construct_standard_mm_to_mm_descriptor
Table 25-33: alt_msgdma_construct_standard_mm_to_mm_descriptor
Prototype: int alt_msgdma_construct_standard_mm_to_mm_descriptor (alt_msgdma_dev
*dev, alt_msgdma_standard_descriptor *descriptor, alt_u32 *read_address, alt_u32
*write_address, alt_u32 length, alt_u32 control)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to a standard descriptor structure.
*read_address – a pointer to the base address of the source memory.
*write_address – a pointer to the base address of the destination memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
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.
UG-01085
2016.12.19 alt_msgdma_construct_standard_mm_to_mm_descriptor 25-41
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_construct_standard_descriptor
Table 25-34: alt_msgdma_construct_standard_descriptor
Prototype: static int alt_msgdma_construct_standard_descriptor (alt_msgdma_dev *dev, alt_
msgdma_standard_descriptor *descriptor, alt_u32 *read_address, alt_u32 *write_
address, alt_u32 length, alt_u32 control)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to a standard descriptor structure.
*read_address – a pointer to the base address of the source memory.
*write_address – a pointer to the base address of the destination memory.
length - is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
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.
25-42 alt_msgdma_construct_standard_descriptor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_construct_extended_st_to_mm_descriptor
Table 25-35: alt_msgdma_construct_extended_st_to_mm_descriptor
Prototype: int alt_msgdma_construct_extended_st_to_mm_descriptor (alt_msgdma_dev *dev,
alt_msgdma_extended_descriptor *descriptor, alt_u32 *write_address, alt_u32
length, alt_u32 control, alt_u16 sequence_number, alt_u8 write_burst_count, alt_
u16 write_stride)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to an extended descriptor structure.
*write_address – a pointer to the base address of the destination memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
sequence number – programmable sequence number to identify which descriptor
has been sent to the master block.
write_burst_count – programmable burst count between 1 and 128 and a power of
2. Setting to 0 will cause the master to use the maximum burst count instead.
write_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, every other word it is 2, etc…power of 2. Setting to 0 will
cause the master to use the maximum burst count instead.
write_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, every other word it is 2, etc…
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.
UG-01085
2016.12.19 alt_msgdma_construct_extended_st_to_mm_descriptor 25-43
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_construct_extended_mm_to_st_descriptor
Table 25-36: alt_msgdma_construct_extended_mm_to_st_descriptor
Prototype: int alt_msgdma_construct_extended_mm_to_st_descriptor (alt_msgdma_dev *dev,
alt_msgdma_extended_descriptor *descriptor, alt_u32 *read_address, alt_u32
length, alt_u32 control, alt_u16 sequence_number, alt_u8 read_burst_count, alt_u16
read_stride)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to an extended descriptor structure.
*read_address – a pointer to the base address of the source memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
sequence_number – programmable sequence number to identify which descriptor
has been sent to the master block.
read_burst_count – programmable burst count between 1 and 128 and a power of 2.
Setting to 0 will cause the master to use the maximum burst count instead.
read_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, every other word it is 2, etc…
Returns: “0” for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function call helper function “alt_msgdma_construct_extended_descriptor” for
constructing mm_to_st extended descriptors. Unnecessary elements are set to 0 for
completeness and will be ignored by the hardware.
25-44 alt_msgdma_construct_extended_mm_to_st_descriptor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_construct_extended_mm_to_mm_descriptor
Table 25-37: alt_msgdma_construct_extended_mm_to_mm_descriptor
Prototype: int alt_msgdma_construct_extended_mm_to_mm_descriptor (alt_msgdma_dev
*dev, alt_msgdma_extended_descriptor *descriptor, alt_u32 *read_address, alt_u32
*write_address, alt_u32 length, alt_u32 control, alt_u16 sequence_number, alt_u8
read_burst_count, alt_u8 write_burst_count, alt_u16 read_stride, alt_u16 write_
stride)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to an extended descriptor structure.
*read_address – a pointer to the base address of the source memory.
*write_address – a pointer to the base address of the destination memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
sequence_number – programmable sequence number to identify which descriptor
has been sent to the master block.
read_burst_count – programmable burst count between 1 and 128 and a power of 2.
Setting to 0 will cause the master to use the maximum burst count instead.
write_burst_count – programmable burst count between 1 and 128 and a power of
2. Setting to 0 will cause the master to use the maximum burst count instead.
read_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, ever other word it is 2, etc…
write_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, every other word it is 2, etc…
Returns: “0” for success, -EINVAL for invalid argument, could be due to argument which has
larger value than hardware setting value.
Description: Function call helper function “alt_msgdma_construct_extended_descriptor” for
constructing mm_to_mm extended descriptors. Unnecessary elements are set to 0
for completeness and will be ignored by the hardware.
UG-01085
2016.12.19 alt_msgdma_construct_extended_mm_to_mm_descriptor 25-45
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_construct_extended_descriptor
Table 25-38: alt_msgdma_construct_extended_descriptor
Prototype: static int alt_msgdma_construct_descriptor (alt_msgdma_dev *dev, alt_msgdma_
extended_descriptor *descriptor, alt_u32 *read_address, alt_u32 *write_address, alt_
u32 length, alt_u32 control, alt_u16 sequence_number, alt_u8 read_burst_count,
alt_u8 write_burst_count,
alt_u16 read_stride, alt_u16 write_stride)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev-a pointer to msgdma instance.
*descriptor – a pointer to an extended descriptor structure.
*read_address – a pointer to the base address of the source memory.
*write_address – a pointer to the base address of the destination memory.
length – is used to specify the number of bytes to transfer per descriptor. e largest
possible value can be lled in is “0X”.
control – control eld.
sequence_number – programmable sequence number to identify which descriptor
has been sent to the master block.
read_burst_count – programmable burst count between 1 and 128 and a power of 2.
Setting to 0 will cause the master to use the maximum burst count instead.
write_burst_count – programmable burst count between 1 and 128 and a power of
2. Setting to 0 will cause the master to use the maximum burst count instead.
read_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, ever other word it is 2, etc…
write_stride – programmable transfer stride. e stride value determines by how
many words the master will increment the address. For xed addresses the stride
value is 0, sequential it is 1, every other word it is 2, etc…
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 extended
descriptors. Unnecessary elements are set to 0 for completeness and will be ignored
by the hardware.
25-46 alt_msgdma_construct_extended_descriptor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_register_callback
Table 25-39: alt_msgdma_register_callback
Prototype: void alt_msgdma_register_callback(alt_msgdma_dev *dev, alt_msgdma_callback
callback, alt_u32 control, void *context)
Include: < modular_sgdma_dispatcher.h >
Parameters: *dev — a pointer to msgdma instance.
callback — Pointer to callback routine to execute at interrupt level
control — Setting control register and OR with other control bits in the non_
blocking and blocking transfer function.
*context — pointer to user dene context
Returns: N/A
Description: Associate a user-specic 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. e 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 Soware Developer's
Handbook. However, user can change some of the CSR control setting in blocking
transfer by calling this function.
UG-01085
2016.12.19 alt_msgdma_register_callback 25-47
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_open
Table 25-40: alt_msgdma_open
Prototype: alt_msgdma_dev* alt_msgdma_open (const char* name)
Include: < modular_sgdma_dispatcher.h >
Parameters: *name — Character pointer to name of msgdma peripheral as registered with the
HAL. For example, an mSGDMA in Qsys would be opened by asking for
“MSGDMA_0_DISPATCHER_INTERNAL".
Returns: Pointer to msgdma device instance struct, or null if the device.
* could not be opened.
Description: Retrieves a pointer to the mSGDMA instance.
25-48 alt_msgdma_open UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_msgdma_write_standard_descriptor
Table 25-41: alt_msgdma_write_standard_descriptor
Prototype: int alt_msgdma_write_standard_descriptor (alt_u32 csr_base, alt_u32 descriptor_
base, alt_msgdma_standard_descriptor *descriptor)
Include: < modular_sgdma_dispatcher.h >, <altera_msgdma_descriptor_regs.h>
Parameters: csr_base – base address of the dispatcher CSR slave port.
descriptor_base – base address of the dispatcher descriptor slave port.
*descriptor – a pointer to a standard descriptor structure.
Returns: Returns 0 upon success. Other return codes are dened in "alt_errno.h".
Description: Sends a fully formed standard descriptor to the dispatcher module. If the dispatcher
descriptor buer is full, “-ENOSPC” is returned. is function is not reentrant since
it must complete writing the entire descriptor to the dispatcher module and cannot
be pre-empted.
UG-01085
2016.12.19 alt_msgdma_write_standard_descriptor 25-49
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
alt_msgdma_write_extended_descriptor
Table 25-42: alt_msgdma_write_extended_descriptor
Prototype: int alt_msgdma_write_extended_descriptor (alt_u32 csr_base, alt_u32 descriptor_
base, alt_msgdma_extended_descriptor *descriptor)
Include: < modular_sgdma_dispatcher.h >, <altera_msgdma_descriptor_regs.h>
Parameters: csr_base – base address of the dispatcher CSR slave port.
descriptor_base – base address of the dispatcher descriptor slave port.
*descriptor – a pointer to an extended descriptor structure.
Returns: Returns 0 upon success. Other return codes are dened in "alt_errno.h".
Description: Sends a fully formed extended descriptor to the dispatcher module. If the dispatcher
descriptor buer is full an error is returned. is function is not reentrant since it
must complete writing the entire descriptor to the dispatcher module and cannot be
pre-empted.
25-50 alt_msgdma_write_extended_descriptor UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
alt_avalon_msgdma_init
Table 25-43: alt_avalon_msgdma_init
Prototype: void alt_msgdma_init (alt_msgdma_dev *dev, alt_u32 ic_id, alt_u32 irq)
Include: < modular_sgdma_dispatcher.h >, <altera_msgdma_descriptor_regs.h>, <altera_
msgdma_csr_regs.h>
Parameters: *dev – a pointer to mSGDMA instance.
ic_id – id of irq interrupt controller
irq – irq number that belonged to mSGDMA instance
Returns: N/A
Description: Initializes the mSGDMA controller. is routine is called from the ALTERA_
AVALON_MSGDMA_INIT macro and is called automatically by "alt_sys_init.c".
alt_msgdma_irq
Table 25-44: alt_msgdma_irq
Prototype: void alt_msgdma_irq(void *context)
Include: < modular_sgdma_dispatcher.h >, <sys/alt_irq.h>, <altera_msgdma_csr_regs.h>
Parameters: *context – a pointer to mSGDMA instance.
Returns: N/A
Description: Interrupt handler for mSGDMA. is function will call the user dened interrupt
handler if user registers their own interrupt handler with calling “alt_register_
callback”.
UG-01085
2016.12.19 alt_avalon_msgdma_init 25-51
Modular Scatter-Gather DMA Core Altera Corporation
Send Feedback
Document Revision History
Table 25-45: Modular Scatter-Gather DMA Core Revision History
Date Version Changes
May 2016 2016.05.03 Updated tables:
•Table 25-2
December 2015 2015.12.16 Added "alt_msgdma_irq" section.
November 2015 2015.11.06 Updated sections:
• Response Port
• Component Parameters
Sections added:
• Programming Model
• Stop DMA Operation
• Stop Descriptor Operation
• Recovery from Stopped on Error and Stopped on Early
Termination
• Modular Scatter-Gather DMA Prefetcher Core
• Driver Implementation
Section removed:
• Unsupported Feature
July 2014 2014.07.24 Initial release
25-52 Document Revision History UG-01085
2016.12.19
Altera Corporation Modular Scatter-Gather DMA Core
Send Feedback
DMA Controller Core 26
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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 dierent address range. An Avalon
Memor-Mapped (Avalon-MM) master peripheral, such as a CPU, can ooad memory transfer tasks to the
DMA controller. While the DMA controller performs memory transfers, the master is free to perform
other tasks in parallel.
e DMA controller transfers data as eciently as possible, reading and writing data at the maximum
pace allowed by the source or destination. e DMA controller is capable of performing Avalon transfers
with ow control, enabling it to automatically transfer data to or from a slow peripheral with ow 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. e
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 Soware
Programming Model section for details of HAL support.
Functional Description
You can use the DMA controller to perform data transfers from a source address-space to a destination
address-space. e controller has no concept of endianness and does not interpret the payload data. e
concept of endianness only applies to a master that interprets payload data.
e source and destination may be either an Avalon-MM slave peripheral (for example, a constant
address) or an address range in memory. e DMA controller can be used in conjunction with peripherals
with ow control, which allows data transactions of xed or variable length. e 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.
e DMA controller has two Avalon-MM master ports—a master read port and a master write port—and
one Avalon-MM slave port for controlling the DMA as shown in the gure below.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 26-1: DMA Controller Block Diagram
Avalon-MM
Save Port
Addr,
data,
control
IRQ
Separate
Avalon-MM
Master Ports
Register File
status
readaddress
writeaddress
length
control
Read
Master
Port
Write
Master
Port
Control
Port
A typical DMA transaction proceeds as follows:
1. A CPU prepares the DMA controller for a transaction by writing to the control port.
2. e CPU enables the DMA controller. e DMA controller then begins transferring data without
additional intervention from the CPU. e DMA’s master read port reads data from the read address,
which may be a memory or a peripheral. e master write port writes the data to the destination
address, which can also be a memory or peripheral. A shallow FIFO buers data between the read and
write ports.
3. e DMA transaction ends when a specied number of bytes are transferred (a xed-length transac‐
tion) or an end-of-packet signal is asserted by either the sender or receiver (a variable-length transac‐
tion). At the end of the transaction, the DMA controller generates an interrupt request (IRQ) if it was
congured by the CPU to do so.
4. During or aer the transaction, the CPU can determine if a transaction is in progress, or if the transac‐
tion ended (and how) by examining the DMA controller’s status register.
Setting Up DMA Transactions
An Avalon-MM master peripheral sets up and initiates DMA transactions by writing to registers via the
control port. e Avalon-MM master programs the DMA engine using byte addresses which are byte
aligned. e master peripheral congures the following options:
• Read (source) address location
• Write (destination) address location
• Size of the individual transfers: Byte (8-bit), halfword (16-bit), word (32-bit), doubleword (64-bit) or
quadword (128-bit)
• Enable interrupt upon end of transaction
• Enable source or destination to end the DMA transaction with end-of-packet signal
• Specify whether source and destination are memory or peripheral
e master peripheral then sets a bit in the control register to initiate the DMA transaction.
The Master Read and Write Ports
e DMA controller reads data from the source address through the master read port, and then writes to
the destination address through the master write port. You program the DMA controller using byte
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 dierent slave devices are of dierent 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
26-2 Setting Up DMA Transactions UG-01085
2016.12.19
Altera Corporation DMA Controller Core
Send Feedback
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.
ere is a shallow FIFO buer between the master read and write ports. e 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 ow control, which allows the
slave peripheral to control the ow of data and terminate the DMA transaction.
For details about ow control in Avalon-MM data transfers and Avalon-MM peripherals, refer to Avalon
Interface Specications.
Addressing and Address Incrementing
When accessing memory, the read (or write) address increments by 1, 2, 4, 8, or 16 aer each access,
depending on the width of the data. On the other hand, a typical peripheral device (such as UART) has
xed register locations. In this case, the read/write address is held constant throughout the DMA
transaction.
e rules for address incrementing are, in order of priority:
• If the control register’s RCON (or WCON) bit is set, the read (or write) increment value is 0.
• Otherwise, the read and write increment values are set according to the transfer size specied in the
control register, as shown below.
Table 26-1: Address Increment Values
Transfer Width Increment
byte 1
halfword 2
word 4
doubleword 8
quadword 16
In systems with heterogeneous data widths, care must be taken to present the correct address or oset
when conguring 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_width—2 in this example.
Parameters
is section describes the parameters you can congure.
DMA Parameters (Basic)
e DMA Parameters page includes the following parameters.
UG-01085
2016.12.19 Addressing and Address Incrementing 26-3
DMA Controller Core Altera Corporation
Send Feedback
Transfer Size
e parameter Width of the DMA Length Register species the minimum width of the DMA’s transac‐
tion length register, which can be between 1 and 32. e 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. e 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 congured maximum burst size.
Otherwise, the transaction must be performed as multiple transactions.
FIFO Depth
e parameter Data Transfer FIFO Depth species the depth of the FIFO buer used for data transfers.
Altera recommends that you set the depth of the FIFO buer 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
is option determines the implementation of the FIFO buer between the master read and write ports.
Select Construct FIFO from Registers to implement the FIFO using one register per storage bit. is
option has a strong impact on logic utilization when the DMA controller’s 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
e Advanced Options page includes the following parameters.
Allowed Transactions
You can choose the transfer datawidth(s) supported by the DMA controller hardware. e 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.
26-4 Advanced Options UG-01085
2016.12.19
Altera Corporation DMA Controller Core
Send Feedback
Software Programming Model
is section describes the programming model for the DMA controller, including the register map and
soware declarations to access the hardware. For Nios II processor users, Altera provides HAL system
library drivers that enable you to access the DMA controller core using the HAL API for DMA devices.
HAL System Library Support
e Altera-provided driver implements a HAL DMA device driver that integrates into the HAL system
library for Nios II systems. HAL users should access the DMA controller via the familiar HAL API, rather
than accessing the registers directly.
If your program uses the HAL device driver to access the DMA controller, accessing the device registers
directly interferes with the correct behavior of the driver.
e HAL DMA driver provides both ends of the DMA process; the driver registers itself as both a receive
channel (alt_dma_rxchan) and a transmit channel (alt_dma_txchan). e Nios II Soware Develope’s
Handbook provides complete details of the HAL system library and the usage of DMA devices.
ioctl() Operations
ioctl() operation requests are dened for both the receive and transmit channels, which allows you to
control the hardware-dependent aspects of the DMA controller. Two ioctl() functions are dened for
the receiver driver and the transmitter driver: alt_dma_rxchan_ioctl() and alt_dma_txchan_ioctl().
e table below lists the available operations. ese are valid for both the transmit and receive channels.
Table 26-2: Operations for alt_dma_rxchan_ioctl() and alt_dma_txchan_ioctl()
Request Meaning
ALT_DMA_SET_MODE_8 Transfers data in units of 8 bits. e parameter arg is ignored.
ALT_DMA_SET_MODE_16 Transfers data in units of 16 bits. e parameter arg is ignored.
ALT_DMA_SET_MODE_32 Transfers data in units of 32 bits. e parameter arg is ignored.
ALT_DMA_SET_MODE_64 Transfers data in units of 64 bits. e parameter arg is ignored.
ALT_DMA_SET_MODE_128 Transfers data in units of 128 bits. e parameter arg is ignored.
ALT_DMA_RX_ONLY_ON
(1)
Sets a DMA receiver into streaming mode. In this case, data is read continuously
from a single location. e parameter arg species the address to read from.
ALT_DMA_RX_ONLY_OFF
(1)
Turns o streaming mode for a receive channel. e parameter arg is ignored.
ALT_DMA_TX_ONLY_ON
(1)
Sets a DMA transmitter into streaming mode. In this case, data is written
continuously to a single location. e parameter arg species the address to
write to.
ALT_DMA_TX_ONLY_OFF
(1)
Turns o streaming mode for a transmit channel. e parameter arg is ignored.
Table 26-2 :
1. ese macro names changed in version 1.1 of the Nios II Embedded Design Suite (EDS). e 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.
UG-01085
2016.12.19 Software Programming Model 26-5
DMA Controller Core Altera Corporation
Send Feedback
Limitations
Currently the Altera-provided drivers do not support 64-bit and 128-bit DMA transactions.
is 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
e DMA controller is accompanied by the following soware les. ese les dene the low-level
interface to the hardware. Application developers should not modify these les.
•altera_avalon_dma_regs.h—is le denes the core’s register map, providing symbolic
constants to access the low-level hardware. e symbols in this le are used only by device driver
functions.
•altera_avalon_dma.h, altera_avalon_dma.c—ese les implement the DMA controller’s
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.
e 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 conict and fail to operate.
Device drivers control and communicate with the hardware through ve memory-mapped 32-bit
registers.
Table 26-3: DMA Controller Register Map
Os
et
Regi
ster
Na
me
Rea
d/
Writ
e
31 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0sta
tus
(1)
RW (2) LEN WEO
P
REO
P
BUS
Y
DON
E
1rea
dad
dre
ss
RW Read master start address
2wri
tea
ddr
ess
RW Write master start address
3len
gth
RW DMA transaction length (in bytes)
4 — — Reserved (3)
5 — — Reserved (3)
26-6 Software Files UG-01085
2016.12.19
Altera Corporation DMA Controller Core
Send Feedback
Os
et
Regi
ster
Na
me
Rea
d/
Writ
e
31 13 12 11 10 9 8 7 6 5 4 3 2 1 0
6con
tro
l
RW (2) SOF
TWA
RER
ESE
T
QUA
DWO
RD
DOU
BLE
WOR
D
WCO
N
RCO
N
LEE
N
WEE
N
REE
N
I_
EN
GO WOR
D
HW BYT
E
7 — — Reserved (3)
Table 26-3 :
1. Writing zero to the status register clears the LEN, WEOP, REOP, and DONE bits.
2. ese bits are reserved. Read values are undened. Write zero.
3. is register is reserved. Read values are undened. e result of a write is undened.
status Register
e status register consists of individual bits that indicate conditions inside the DMA controller. e
status register can be read at any time. Reading the status register does not change its value.
Table 26-4: status Register Bits
Bit
Number
Bit
Name
Read/Write/
Clear
Description
0DONE R/C A DMA transaction is complete. e DONE bit is set to 1 when an end of
packet condition is detected or the specied transaction length is
completed. Write zero to the status register to clear the DONE bit.
1BUSY Re BUSY bit is 1 when a DMA transaction is in progress.
2REOP Re REOP bit is 1 when a transaction is completed due to an end-of-
packet event on the read side.
3WEOP Re WEOP bit is 1 when a transaction is completed due to an end of
packet event on the write side.
4LEN Re LEN bit is set to 1 when the length register decrements to zero.
readaddress Register
e readaddress register species the rst location to be read in a DMA transaction. e 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
e writeaddress register species the rst location to be written in a DMA transaction. e 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.
UG-01085
2016.12.19 Register Map 26-7
DMA Controller Core Altera Corporation
Send Feedback
length Register
e length register species the number of bytes to be transferred from the read port to the write port.
e length register is specied in bytes. For example, the value must be a multiple of 4 for word transfers,
and a multiple of 2 for halfword transfers.
e length register is decremented as each data value is written by the write master port. When length
reaches 0 the LEN bit is set. e length register does not decrement below 0.
e 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
e control register is composed of individual bits that control the DMA’s internal operation. e control
register’s value can be read at any time. e control register bits determine which, if any, conditions of the
DMA transaction result in the end of a transaction and an interrupt request.
Table 26-5: Control Register Bits
Bit
Number
Bit Name Read/
Write/
Clear
Description
0BYTE RW Species byte transfers.
1HW RW Species halfword (16-bit) transfers.
2WORD RW Species word (32-bit) transfers.
3GO RW Enables DMA transaction. When the GO bit is set to 0 during idle
stage (before execution starts), the DMA is prevented from executing
transfers. When the GO bit is set to 1 during idle stage and the length
register is non-zero, transfers occur.
If go bit is de-asserted low before write transaction complete, done
bit will never go high. It is advisable that GO bit is modied during
idle stage (no execution happened) only.
4I_EN RW Enables interrupt requests (IRQ). When the I_EN bit is 1, the DMA
controller generates an IRQ when the status register’s DONE bit is set
to 1. IRQs are disabled when the I_EN bit is 0.
5REEN RW Ends transaction on read-side end-of-packet. When the REEN bit is
set to 1, a slave port with ow control on the read side may end the
DMA transaction by asserting its end-of-packet signal.
6WEEN RW Ends transaction on write-side end-of-packet. WEEN bit shoudl be set
to 0.
7LEEN 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.
26-8 Register Map UG-01085
2016.12.19
Altera Corporation DMA Controller Core
Send Feedback
Bit
Number
Bit Name Read/
Write/
Clear
Description
8RCON RW Reads from a constant address. When RCON is 0, the read address
increments aer every data transfer. is is the mechanism for the
DMA controller to read a range of memory addresses. When RCON is
1, the read address does not increment. is 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.
9WCON RW Writes to a constant address. Similar to the RCON bit, when WCON is 0
the write address increments aer every data transfer; when WCON is 1
the write address does not increment. For details, see Addressing
and Address Incrementing.
10 DOUBLEWORD RW Species doubleword transfers.
11 QUADWORD RW Species quadword transfers.
12 SOFTWARERESET RW Soware 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. e logic which
sequences the soware reset process then resets itself automatically.
e data width of DMA transactions is specied 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 undened. e 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 ash 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.
To successfully perform transactions of a specic width, that width must be enabled in hardware using the
Allowed Transaction hardware option. For example, the DMA controller behavior is undened if
quadword transfers are disabled in hardware, but the QUADWORD bit is set during a DMA transaction.
Executing a DMA soware reset when a DMA transfer is active may result in permanent bus lockup (until
the next system reset). e SOFTWARERESET bit should therefore not be written except as a last resort.
Interrupt Behavior
e DMA controller has a single IRQ output that is asserted when the status register’s DONE bit equals 1
and the control register’s 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 nished by checking the LEN, REOP, and
WEOP bits.
UG-01085
2016.12.19 Interrupt Behavior 26-9
DMA Controller Core Altera Corporation
Send Feedback
Document Revision History
Table 26-6: DMA Controller Core Revision History
Date Version Changes
December 2015 2015.12.12 Updated LEEN and WEEN in Control Register table.
June 2015 2015.06.12 Updated the GO bit description in the "Control Register Bits" table
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 Added a new parameter, FIFO Depth.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Updated the Functional Description of the core.
26-10 Document Revision History UG-01085
2016.12.19
Altera Corporation DMA Controller Core
Send Feedback
Video Sync Generator and Pixel Converter
Cores 27
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e video sync generator core accepts a continuous stream of pixel data in RGB format, and outputs the
data to an o-chip display controller with proper timing. You can congure the video sync generator core
to support dierent display resolutions and synchronization timings.
e pixel converter core transforms the pixel data to the format required by the video sync generator. e
Typical Placement in a System gure shows a typical placement of the video sync generator and pixel
converter cores in a system.
In this example, the video buer stores the pixel data in 32-bit unpacked format. e 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
Video
Buffer SGDMA FIFO Pixel
Converter
Data
Format
Adapter
Video
Sync
Generator
32 bits 32 bits 32 bits 24 bits 8 bits 8 bits
0RGB BGR0 BGR0 BGR B,G,R B,G,R
TS-nolavAMM-nolavA
Video
Buffer SGDMA FIFO Pixel
Converter
Data
Format
Adapter
Video
Sync
Generator
32 bits 32 bits 32 bits 24 bits 8 bits 8 bits
0RGB BGR0 BGR0 BGR B,G,R B,G,R
TS-nolavAMM-nolavA
ese cores are deployed in the Nios II Embedded Soware Evaluation Kit (NEEK), which includes an
LCD display daughtercard assembly attached via an HSMC connector.
Video Sync Generator
is section describes the hardware structure and functionality of the video sync generator core.
Functional Description
e 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 o-chip display
controller. No processing or validation is performed on the pixel data.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 27-2: Video Sync Generator Block Diagram
clk
reset
data
ready
valid
sop
eop
rgb_out
hd
vd
den
VIDEO SYNC GENERATOR
You can congure 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 rst pixel in a frame. e rst active pixel is indicated by an
sop pulse.
e 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
Table 27-1: Video Sync Generator Parameters
Parameter Name Description
Horizontal Sync
Pulse Pixels
e width of the h-sync pulse in number of pixels.
Total Vertical Scan
Lines
e total number of lines in one video frame. e value is the sum of the following
parameters: Number of Rows, Vertical Blank Lines, and Vertical Front Porch
Lines.
Number of Rows e number of active scan lines in each video frame.
Horizontal Sync
Pulse Polarity
e polarity of the h-sync pulse; 0 = active low and 1 = active high.
Horizontal Front
Porch Pixels
e number of blanking pixels that follow the active pixels. During this period,
there is no data ow from the Avalon-ST sink port to the LCD output data port.
Vertical Sync Pulse
Polarity
e polarity of the v-sync pulse; 0 = active low and 1 = active high.
27-2 Parameters UG-01085
2016.12.19
Altera Corporation Video Sync Generator and Pixel Converter Cores
Send Feedback
Parameter Name Description
Vertical Sync Pulse
Lines
e width of the v-sync pulse in number of lines.
Vertical Front Porch
Lines
e number of blanking lines that follow the active lines. During this period, there
is no data ow from the Avalon-ST sink port to the LCD output data port.
Number of Columns e number of active pixels in each line.
Horizontal Blank
Pixels
e number of blanking pixels that precede the active pixels. During this period,
there is no data ow from the Avalon-ST sink port to the LCD output data port.
Total Horizontal
Scan Pixels
e total number of pixels in one line. e value is the sum of the following
parameters: Number of Columns, Horizontal Blank Pixel, and Horizontal Front
Porch Pixels.
Beats Per Pixel e number of beats required to transfer one pixel. Valid values are 1 and 3. is
parameter, when multiplied by Data Stream Bit Width must be equal to the total
number of bits in one pixel. is parameter aects the operating clock frequency,
as shown in the following equation:
Operating clock frequency = (Beats per pixel) * (Pixel_rate), where
Pixel_rate (in MHz) = ((Total Horizontal Scan Pixels) * (Total Vertical Scan
Lines) * (Display refresh rate in Hz))/1000000.
Vertical Blank Lines e number of blanking lines that proceed the active lines. During this period,
there is no data ow from the Avalon-ST sink port to the LCD output data port.
Data Stream Bit
Width
e width of the inbound and outbound data.
Signals
Table 27-2: Video Sync Generator Core Signals
Signal Name Width (Bits) Direction Description
Global Signals
clk 1 Input System clock.
reset 1 Input System reset.
Avalon-ST Signals
data Variable-
width
Input Incoming pixel data. e datawidth is determined by the parameter
Data Stream Bit Width.
ready 1 Output is signal is asserted when the video sync generator is ready to
receive the pixel data.
valid 1 Input is signal is not used by the video sync generator core because the
core always expects valid pixel data on the next clock cycle aer the
ready signal is asserted.
UG-01085
2016.12.19 Signals 27-3
Video Sync Generator and Pixel Converter Cores Altera Corporation
Send Feedback
Signal Name Width (Bits) Direction Description
sop 1 Input Start-of-packet. is signal is asserted when the rst pixel is
received.
eop 1 Input End-of-packet. is signal is asserted when the last pixel is received.
LCD Output Signals
rgb_out Variable-
width
Output Display data. e datawidth is determined by the parameter Data
Stream Bit Width.
hd 1 Output Horizontal synchronization pulse for display.
vd 1 Output Vertical synchronization pulse for display.
den 1 Output is signal is asserted when the video sync generator core outputs
valid data for display.
Timing Diagrams
e horizontal and vertical synchronization timings are determined by the parameters setting. e 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 Timing—8 Bits DataWidth and 3 Beats Per Pixel
clk
hd
den
rgb_out R G B R G B
Horizontal sync pulse
Horizontal front porch
1 pixel
Horizontal blank pixels
Horizontal synchronization width
e 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.
Figure 27-4: Horizontal Synchronization Timing—24 Bits DataWidth and 1 Beat Per Pixel
clk
hd
den
rgb_out RGB
Horizontal synchronization pulse
Horizontal blank pixels Horizontal front porch
1 pixel
RGBRGB RGBRGBRGB
Horizontal synchronization width
27-4 Timing Diagrams UG-01085
2016.12.19
Altera Corporation Video Sync Generator and Pixel Converter Cores
Send Feedback
Figure 27-5: Vertical Synchronization Timing—8 Bits DataWidth and 3 Beats Per Pixel / 24 Bits DataWidth
and 1 Beat Per Pixel
hd
den
Vertical blank lines
Horizontal synchronization width
vd
Vertical synchronization width
Vertical front porch
Vertical synchronization pulse
Pixel Converter
is section describes the hardware structure and functionality of the pixel converter core.
Functional Description
e 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. e least signicant 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 congure the following parameter:
•Source symbols per beat—e number of symbols per beat on the Avalon-ST source interface.
Signals
Table 27-3: Pixel Converter Input Interface Signals
Signal Name Width (Bits) Direction Description
Global Signals
clk 1 Input Not in use.
reset_n 1 Input
Avalon-ST Signals
data_in 32 Input Incoming pixel data. Contains four 8-bit symbols that are
transferred in 1 beat.
data_out 24 Output Output data. Contains three 8-bit symbols that are transferred in 1
beat.
UG-01085
2016.12.19 Pixel Converter 27-5
Video Sync Generator and Pixel Converter Cores Altera Corporation
Send Feedback
Signal Name Width (Bits) Direction Description
sop_in 1 Input
Wired directly to the corresponding output signals.
eop_in 1 Input
ready_in 1 Input
valid_in 1 Input
empty_in 1 Input
sop_out 1 Output
Wired directly from the input signals.
eop_out 1 Output
ready_
out
1 Output
valid_
out
1 Output
empty_
out
1 Output
Hardware Simulation Considerations
For a typical 60 Hz refresh rate, set the simulation length for the video sync generator core to at least 16.7
μs to get a full video frame. Depending on the size of the video frame, simulation may take a very long
time to complete.
Document Revision History
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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Added new parameters for both cores.
27-6 Hardware Simulation Considerations UG-01085
2016.12.19
Altera Corporation Video Sync Generator and Pixel Converter Cores
Send Feedback
Interval Timer Core 28
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Interval Timer core with Avalon® interface is an interval timer for Avalon-based processor systems,
such as a Nios® II processor system. e core provides the following features:
• 32-bit and 64-bit counters.
• Controls to start, stop, and reset the timer.
• Two count modes: count down once and continuous count-down.
• Count-down period register.
• Option to enable or disable the interrupt request (IRQ) when timer reaches zero.
• Optional watchdog timer feature that resets the system if timer ever reaches zero.
• Optional periodic pulse generator feature that outputs a pulse when timer reaches zero.
• Compatible with 32-bit and 16-bit processors.
Device drivers are provided in the HAL system library for the Nios II processor.
Functional Description
Figure 28-1: Interval Timer Core Block Diagram
Register File
status
control
period_
n
snap_
n
IRQ
Address &
Data
Avalon-MM
slave interface
to on-chip
logic Control
Logic
resetrequest
(watchdog)
timeout_pulse
Counter
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
e interval timer core has two user-visible features:
•e Avalon Memory-Mapped (Avalon-MM) interface that provides access to six 16-bit registers
• An optional pulse output that can be used as a periodic pulse generator
All registers are 16-bits wide, making the core compatible with both 16-bit and 32-bit processors.
Certain registers only exist in hardware for a given conguration. For example, if the core is congured
with a xed period, the period registers do not exist in hardware.
e following sequence describes the basic behavior of the interval timer core:
• An Avalon-MM master peripheral, such as a Nios II processor, writes the core's control register to
perform the following tasks:
• Start and stop the timer
• Enable/disable the IRQ
• Specify count-down once or continuous count-down mode
• A processor reads the status register for information about current timer activity.
• A processor can specify the timer period by writing a value to the period registers.
• An internal counter counts down to zero, and whenever it reaches zero, it is immediately reloaded from
the period registers.
• A processor can read the current counter value by rst writing to one of the snap registers to request a
coherent snapshot of the counter, and then reading the snap registers for the full value.
• When the count reaches zero, one or more of the following events are triggered:
• If IRQs are enabled, an IRQ is generated.
•e optional pulse-generator output is asserted for one clock period.
•e optional watchdog output resets the system.
Avalon-MM Slave Interface
e interval timer core implements a simple Avalon-MM slave interface to provide access to the register
le. e Avalon-MM slave port uses the resetrequest signal to implement watchdog timer behavior. is
signal is a non-maskable reset signal, and it drives the reset input of all Avalon-MM peripherals. When the
resetrequest signal is asserted, it forces any processor connected to the system to reboot. For more
information, refer to Conguring the Timer as a Watchdog Timer.
Conguration
is section describes the options available in the MegaWizard Interace.
Timeout Period
e 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 o, the period is xed and cannot be updated at runtime. See the
Hardware Options section for information on register options.
e Timeout Period is an integer multiple of the Timer Frequency. e Timer Frequency is xed at the
frequency setting of the system clock associated with the timer. e Timeout Period setting can be
specied in units of µs (microseconds), ms (milliseconds), seconds , or clocks (number of cycles of the
system clock associated with the timer). e actual period depends on the frequency of the system clock
associated with the timer. If the period is specied in µs, ms, or seconds, the true period will be the
smallest number of clock cycles that is greater or equal to the specied Timeout Period value. For
28-2 Avalon-MM Slave Interface UG-01085
2016.12.19
Altera Corporation Interval Timer Core
Send Feedback
example, if the associated system clock has a frequency of 30 ns, and the specied Timeout Period value is
1 µs, the true timeout period will be 1.020 microseconds.
Counter Size
e 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. is option
applies to the snap registers as well.
Hardware Options
e following options aect the hardware structure of the interval timer core. As a convenience, the Preset
Congurations list oers several pre-dened hardware congurations, such as:
•Simple periodic interrupt—is conguration is useful for systems that require only a periodic IRQ
generator. e period is xed and the timer cannot be stopped, but the IRQ can be disabled.
•Full-featured—is conguration is useful for embedded processor systems that require a timer with
variable period that can be started and stopped under processor control.
•Watchdog—is conguration is useful for systems that require watchdog timer to reset the system in
the event that the system has stopped responding. Refer to the Conguring the Timer as a Watchdog
Timer section.
Register Options
Table 28-1: Register Options
Option Description
Writeable
period
When this option is enabled, a master peripheral can change the count-down period by
writing to the period registers. When disabled, the count-down period is xed at the
specied Timeout Period, and the period registers do not exist in hardware.
Readable
snapshot
When this option is enabled, a master peripheral can read a snapshot of the current count-
down. When disabled, the status of the counter is detectable only via other indicators, such
as the status register or the IRQ signal. In this case, the snap registers do not exist in
hardware, and reading these registers produces an undened value.
Start/Stop
control bits
When this option is enabled, a master peripheral can start and stop the timer by writing the
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.
Output Signal Options
Table 28-2: Output Signal Options
Option Description
Timeout
pulse
(1 clock
wide)
When this option is on, the core outputs a signal timeout_pulse. is signal pulses high
for one clock cycle whenever the timer reaches zero. When this option is o, the timeout_
pulse signal does not exist.
UG-01085
2016.12.19 Counter Size 28-3
Interval Timer Core Altera Corporation
Send Feedback
Option Description
System reset
on timeout
(watchdog)
When this option is on, the core’s Avalon-MM slave port includes the resetrequest signal.
is signal pulses high for one clock cycle whenever the timer reaches zero resulting in a
system-wide reset. e internal timer is stopped at reset. Explicitly writing the START bit of
the control register starts the timer.
When this option is o, the resetrequest signal does not exist.
Refer to the Conguring the Timer as a Watchdog Timer section.
Conguring the Timer as a Watchdog Timer
To congure the core for use as a watchdog, in the MegaWizard Interface select Watchdog in the Preset
Congurations list, or choose the following settings:
• Set the Timeout Period to the desired "watchdog" period.
• Turn o Writeable period.
• Turn o Readable snapshot.
• Turn o Start/Stop control bits.
• Turn o Timeout pulse.
• Turn on System reset on timeout (watchdog).
A watchdog timer wakes up (comes out of reset) stopped. A processor later starts the timer by writing a
1 to the control register's START bit. Once started, the timer can never be stopped. If the internal
counter ever reaches zero, the watchdog timer resets the system by generating a pulse on its resetre-
quest output. e resetrequest pulse will last for two cycles before the incoming reset signal
deasserts the pulse. To prevent an indenite resetrequest pulse, you are required to connect the
resetrequest signal back to the reset input of the timer.
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, soware stopped executing normally, the watchdog timer resets the
system and returns the system to a dened state.
Software Programming Model
e following sections describe the soware programming model for the interval timer core, including the
register map and soware declarations to access the hardware. For Nios II processor users, Altera provides
hardware abstraction layer (HAL) system library drivers that enable you to access the interval timer core
using the HAL application programming interface (API) functions.
HAL System Library Support
e Altera-provided drivers integrate into the HAL system library for Nios II systems. When possible,
HAL users should access the core via the HAL API, rather than accessing the core's registers directly.
Altera provides a driver for both the HAL timer device models: system clock timer, and timestamp timer.
System Clock Driver
When congured as the system clock, the interval timer core runs continuously in periodic mode, using
the default period set. e system clock services are then run as a part of the interrupt service routine for
28-4 Conguring the Timer as a Watchdog Timer UG-01085
2016.12.19
Altera Corporation Interval Timer Core
Send Feedback
this timer. e driver is interrupt-driven, and therefore must have its interrupt signal connected in the
system hardware.
e Nios II integrated development environment (IDE) allows you to specify system library properties
that determine which timer device will be used as the system clock timer.
Timestamp Driver
e interval timer core may be used as a timestamp device if it meets the following conditions:
•e timer has a writeable period register, as congured in Qsys.
•e timer is not selected as the system clock.
e 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 congured 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 Soware Developer’s Handbook. e Nios II Embedded Design Suite (EDS) also
provides several example designs that use the interval timer core.
Limitations
e HAL driver for the interval timer core does not support the watchdog reset feature of the core.
Software Files
e interval timer core is accompanied by the following soware les. ese les dene the low-level
interface to the hardware, and provide the HAL drivers. Application developers should not modify these
les.
•altera_avalon_timer_regs.h—is le denes 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.c—ese les 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.
e 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 conict and fail to operate
correctly.
e table below shows the register map for the 32-bit timer. e interval timer core uses native address
alignment. For example, to access the control register value, use oset 0x4.
UG-01085
2016.12.19 Software Files 28-5
Interval Timer Core Altera Corporation
Send Feedback
Table 28-3: Register Map—32-bit Timer
Oset Name R/W
Description of Bits
15 ... 4 3 2 1 0
0status RW (1) RUN TO
1control RW (1) STOP START CONT IT
O
2periodl RW Timeout Period – 1 (bits [15:0])
3periodh RW Timeout Period – 1 (bits [31:16])
4snapl RW Counter Snapshot (bits [15:0])
5snaph RW Counter Snapshot (bits [31:16])
Table 28-3 :
1. Reserved. Read values are undened. Write zero.
For more information about native address alignment, refer to the System Interconnect Fabric for
Memory-Mapped Interfaces.
Table 28-4: Register Map—64-bit Timer
Oset Name R/W
Description of Bits
15 ... 4 3 2 1 0
0status RW (1) RUN TO
1control RW (1) STOP START CONT IT
O
2period_0 RW Timeout Period – 1 (bits [15:0])
3period_1 RW Timeout Period – 1 (bits [31:16])
4period_2 RW Timeout Period – 1 (bits [47:32])
5period_3 RW Timeout Period – 1 (bits [63:48])
6snap_0 RW Counter Snapshot (bits [15:0])
7snap_1 RW Counter Snapshot (bits [31:16])
8snap_2 RW Counter Snapshot (bits [47:32])
9snap_3 RW Counter Snapshot (bits [63:48])
Table 28-4 :
1. Reserved. Read values are undened. Write zero.
status Register
e status register has two dened bits.
28-6 Register Map UG-01085
2016.12.19
Altera Corporation Interval Timer Core
Send Feedback
Table 28-5: status Register Bits
Bit Name R/W/C Description
0TO R/WC e TO (timeout) bit is set to 1 when the internal counter reaches zero.
Once set by a timeout event, the TO bit stays set until explicitly cleared by a
master peripheral. Write 0 or 1 to the status register to clear the TO bit.
1RUN Re RUN bit reads as 1 when the internal counter is running; otherwise this
bit reads as 0. e RUN bit is not changed by a write operation to the
status register.
control Register
e control register has four dened bits.
Table 28-6: control Register Bits
Bit Name R/W/C Description
0ITO RW If the ITO bit is 1, the interval timer core generates an IRQ when the
status register’s TO bit is 1. When the ITO bit is 0, the timer does not
generate IRQs.
1CONT RW e CONT (continuous) bit determines how the internal counter behaves
when it reaches zero. If the CONT bit is 1, the counter runs continuously
until it is stopped by the STOP bit. If CONT is 0, the counter stops aer it
reaches zero. When the counter reaches zero, it reloads with the value
stored in the period registers, regardless of the CONT bit.
2START
(1)
W Writing a 1 to the START bit starts the internal counter running (counting
down). e START bit is an event bit that enables the counter when a
write operation is performed. If the timer is stopped, writing a 1 to the
START bit causes the timer to restart counting from the number currently
stored in its counter. If the timer is already running, writing a 1 to START
has no eect. Writing 0 to the START bit has no eect.
3 STOP (1) W Writing a 1 to the STOP bit stops the internal counter. e STOP bit is an
event bit that causes the counter to stop when a write operation is
performed. If the timer is already stopped, writing a 1 to STOP has no
eect. Writing a 0 to the stop bit has no eect.
If the timer hardware is congured with Start/Stop control bits o,
writing the STOP bit has no eect.
Table 28-6 :
1. Writing 1 to both START and STOP bits simultaneously produces an undened result.
UG-01085
2016.12.19 Register Map 28-7
Interval Timer Core Altera Corporation
Send Feedback
period_n Registers
e period_n registers together store the timeout period value. e 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
•e internal counter reaches 0
e 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
congured with Start/Stop control bits o. If Start/Stop control bits is o, writing either register does
not stop the counter. When the hardware is congured with Writeable period disabled, writing to one
of the period_n registers causes the counter to reset to the xed Timeout Period specied at system
generation time.
Note: A timeout period value of 0 is not a supported use case. Soware congures 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. e snapshot occurs whether or not the counter is running.
Requesting a snapshot does not change the internal counter's operation.
Interrupt Behavior
e 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:
• Clear the TO bit of the status register
• Disable interrupts by clearing the ITO bit of the control register
Failure to acknowledge the IRQ produces an undened result.
Document Revision History
Table 28-7: Interval Timer Core Revision History
Date Version Changes
June 2015 2015.06.12 Updated "status Register Bits" table.
July 2014 2014.07.24 Removed mention of SOPC Builder, updated to Qsys
December 2013 v13.1.0 Updated the reset pulse description in the Conguring the Timer as a
Watchdog Timer section.
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.
28-8 Interrupt Behavior UG-01085
2016.12.19
Altera Corporation Interval Timer Core
Send Feedback
Date Version Changes
November 2009 v9.1.0 Revised descriptions of register elds and bits.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. Updated the core’s name to reect the
name used in SOPC Builder.
May 2008 v8.0.0 Added a new parameter and register map for the 64-bit timer.
UG-01085
2016.12.19 Document Revision History 28-9
Interval Timer Core Altera Corporation
Send Feedback
Mutex Core 29
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
Multiprocessor environments can use the mutex core with Avalon® interface to coordinate accesses to a
shared resource. e mutex core provides a protocol to ensure mutually exclusive ownership of a shared
resource.
e mutex core provides a hardware-based atomic test-and-set operation, allowing soware in a
multiprocessor environment to determine which processor owns the mutex. e mutex core can be used
in conjunction with shared memory to implement additional interprocessor coordination features, such as
mailboxes and soware mutexes.
e 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.
Functional Description
e mutex core has a simple Avalon Memory-Mapped (Avalon-MM) slave interface that provides access
to two memory-mapped, 32-bit registers.
Table 29-1: Mutex Core Register Map
Oset Register Name R/W
Bit Description
31 16 15 1 0
0mutex RW OWNER VALUE
1reset RW Reserved RESET
e mutex core has the following basic behavior. is description assumes there are multiple processors
accessing a single mutex core, and each processor has a unique identier (ID).
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
• When the VALUE eld is 0x0000, the mutex is unlocked and available. Otherwise, the mutex is locked
and unavailable.
•e mutex register is always readable. Avalon-MM master peripherals, such as a processor, can read the
mutex register to determine its current state.
•e mutex register is writable only under specic conditions. A write operation changes the mutex
register only if one or both of the following conditions are true:
•e VALUE eld of the mutex register is zero.
•e OWNER eld of the mutex register matches the OWNER eld in the data to be written.
• A processor attempts to acquire the mutex by writing its ID to the OWNER eld, and writing a non-zero
value to the VALUE eld. e processor then checks if the acquisition succeeded by verifying the OWNER
eld.
•Aer system reset, the RESET bit in the reset register is high. Writing a one to this bit clears it.
Conguration
e MegaWizard™ Interface provides the following options:
•Initial Value—the initial contents of the VALUE eld aer reset. If the Initial Value setting is non-zero,
you must also specify Initial Owner.
•Initial Owner—the initial contents of the OWNER eld aer reset. When Initial Owner is specied, this
owner must release the mutex before it can be acquired by another owner.
Software Programming Model
e following sections describe the soware programming model for the mutex core. For Nios II
processor users, Altera provides routines to access the mutex core hardware. ese functions are specic to
the mutex core and directly manipulate low-level hardware. e mutex core cannot be accessed via the
HAL API or the ANSI C standard library. In Nios II processor systems, a processor locks the mutex by
writing the value of its cpuid control register to the OWNER eld of the mutex register.
Software Files
Altera provides the following soware les accompanying the mutex core:
•altera_avalon_mutex_regs.h—Denes the core's register map, providing symbolic constants to
access the low-level hardware.
•altera_avalon_mutex.h—Denes data structures and functions to access the mutex core
hardware.
•altera_avalon_mutex.c—Contains the implementations of the functions to access the mutex core
Hardware Access Routines
is section describes the low-level soware constructs for manipulating the mutex core. e le
altera_avalon_mutex.h declares a structure alt_mutex_dev that represents an instance of a mutex
device. It also declares routines for accessing the mutex hardware structure, listed in the table below.
29-2 Conguration UG-01085
2016.12.19
Altera Corporation Mutex Core
Send Feedback
Table 29-2: Hardware Access Routines
Function Name Description
altera_avalon_mutex_open() Claims a handle to a mutex, enabling all the other functions to
access the mutex core.
altera_avalon_mutex_trylock() Tries to lock the mutex. Returns immediately if it fails to lock
the mutex.
altera_avalon_mutex_lock() Locks the mutex. Will not return until it has successfully
claimed the mutex.
altera_avalon_mutex_unlock() Unlocks the mutex.
altera_avalon_mutex_is_mine() Determines if this CPU owns the mutex.
altera_avalon_mutex_first_lock() Tests whether the mutex has been released since reset.
ese routines coordinate access to the soware mutex structure using a hardware mutex core. For a
complete description of each function, see section the Mutex API section.
e code shown in below demonstrates opening a mutex device handle and locking a mutex.
#include <altera_avalon_mutex.h>
/* get the mutex device handle */
alt_mutex_dev* mutex = altera_avalon_mutex_open( “/dev/mutex” );
/* acquire the mutex, setting the value to one */
altera_avalon_mutex_lock( mutex, 1 );
/*
* Access a shared resource here.
*/
/* release the lock */
altera_avalon_mutex_unlock( mutex );
Mutex API
is section describes the application programming interface (API) for the mutex core.
altera_avalon_mutex_is_mine()
Prototype: int altera_avalon_mutex_is_mine(alt_mutex_dev* dev)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: dev—the mutex device to test.
Returns: Returns non zero if the mutex is owned by this CPU.
UG-01085
2016.12.19 Mutex API 29-3
Mutex Core Altera Corporation
Send Feedback
Description: altera_avalon_mutex_is_mine() determines if this CPU owns the mutex.
altera_avalon_mutex_rst_lock()
Prototype: int altera_avalon_mutex_first_lock(alt_mutex_dev* dev)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: dev—the 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()
Prototype: void altera_avalon_mutex_lock(alt_mutex_dev* dev, alt_u32 value)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: dev—the mutex device to acquire.
value—the new value to write to the mutex.
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()
Prototype: alt_mutex_dev* alt_hardware_mutex_open(const char* name)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: name—the name of the mutex device to open.
29-4 altera_avalon_mutex_rst_lock() UG-01085
2016.12.19
Altera Corporation Mutex Core
Send Feedback
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()
Prototype: int altera_avalon_mutex_trylock(alt_mutex_dev* dev, alt_u32
value)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: dev—the mutex device to lock.
value—the new value to write to the mutex.
Returns: 0 = e mutex was successfully locked.
Others = e mutex was not locked.
Description: altera_avalon_mutex_trylock() tries once to lock the hardware mutex, and
returns immediately.
altera_avalon_mutex_unlock()
Prototype: void altera_avalon_mutex_unlock(alt_mutex_dev* dev)
read-safe: Yes.
Available from
ISR:
No.
Include: <altera_avalon_mutex.h>
Parameters: dev—the 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 undened.
UG-01085
2016.12.19 altera_avalon_mutex_trylock() 29-5
Mutex Core Altera Corporation
Send Feedback
Document Revision History
Table 29-3: Mutex Core 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.
July 2010 v10.0.0 No change from previous release.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
29-6 Document Revision History UG-01085
2016.12.19
Altera Corporation Mutex Core
Send Feedback
Vectored Interrupt Controller Core 30
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e ability to process interrupt events quickly and to handle large numbers of interrupts can be critical to
many embedded systems. e Vectored Interrupt Controller (VIC) is designed to address these require‐
ments. e VIC can provide interrupt performance four to ve times better than the Nios II processor’s
default internal interrupt controller (IIC). e VIC also allows expansion to a virtually unlimited number
of interrupts, through daisy chaining.
e 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
e VIC oers high-performance, low-latency interrupt handling. e 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.
e 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
e Sample System Layout Figure below outlines the basic layout of a system containing two VIC
components.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 30-1: Sample System Layout
e VIC core provides the following features:
Avalon-MM Interconnect Fa bric
VIC
CPU
IRQ
Core
Avalon-ST
...
...
IRQ
VIC
IRQ
Core
...
...
IRQ
Avalon-ST
Cor oCe re
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.
e characteristics of each interrupt port are congured 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) ag for each interrupt, to control
whether each interrupt is maskable or non-maskable
•Soware-controlled priority arbitration scheme
e 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 Soware Programming Model section for HAL support details.
Functional Description
Figure 30-2: VIC Block Diagram
Control Status Registers
csr_access
(Avalon-MM slave
from processor)
Interrupt
Request
Block
interrupt_controller_in
(optional Avalon-ST
VIC daisy chain input)
Vector
Generation
Block
Priority
Processing
Block
interrupt_controller_out
(Avalon-ST to processor or
to inter rupt_controller_in
of another VIC)
clk
(clock)
irq_input
(external inter rupt input)
30-2 Functional Description UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
External Interfaces
e following sections describe the external interfaces for the VIC core.
clk
clk is a system clock interface. is interface connects to your system’s main clock source. e interface’s
signals are clk and reset_n.
irq_input
irq_input comprises up to 32 single-bit, level-sensitive Avalon interrupt receiver interfaces. ese
interfaces connect to interrupt sources. ere is one irq signal for each interface.
interrupt_controller_out
interrupt_controller_out is an Avalon-ST output interface, as dened in the VIC Avalon-ST Interface
Fields, congured with a ready latency of 0 cycles. is interface connects to your processor or to the
interrupt_controller_in interface of another VIC. e interface’s signals are valid and data.
Table 30-1: interrupt_controller_out and interrupt_controller_in Parameters
Parameter Value
Symbol width 45 bits
Ready latency 0 cycles
interrupt_controller_in
interrupt_controller_in is an optional Avalon-ST input interface, as dened in VIC Avalon-ST
Interface Fields, congured with a ready latency of 0 cycles. Include this interface in the second, third, etc,
VIC components of a daisy-chained multiple VIC system. is interface connects to the
interrupt_controller_out interface of the immediately-preceding VIC in the chain. e interface’s
signals are valid and data.
e interrupt_controller_out and interrupt_controller_in interfaces have identical Avalon-ST
formats so you can daisy chain VICs together in Qsys when you need more than 32 interrupts.
interrupt_controller_out always provides valid data and cannot be back-pressured.
Table 30-2: VIC Avalon-ST Interface Fields
44 ... ... 13 12-7 6 5-0
RHA(17) RRS #iga1401399661499/
fn6868
RNMI #ig
a14013996
61499/
fn6868
RIL#iga1401399661499/fn6868
(17) RHA contains the 32-bit address of the interrupt handling routine.
(18) Refer to e INT_CONFIG Register Map Table for a description of this eld.
UG-01085
2016.12.19 External Interfaces 30-3
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
csr_access
csr_access is a VIC CSR interface consisting of an Avalon-MM slave interface. is interface connects to
the data master of your processor. e interface’s signals are read, write, address, readdata, and
writedata.
Table 30-3: csr_access Parameters
Parameter Value
Read wait 1 cycle
Write wait 0 cycles
Ready latency 1 cycles
For information about the Avalon-MM slave and Avalon-ST interfaces, refer to the Avalon Interface
Specications.
Related Information
Avalon Interface Specications
Functional Blocks
e following main design blocks comprise the VIC core:
• Interrupt request block
• Priority processing block
• Vector generation block
Interrupt Request Block
e interrupt request block controls the input interrupts, providing functionality such as setting interrupt
levels, setting the per-interrupt programmable registers, masking interrupts, and managing soware-
controlled interrupts. You congure the number of interrupt input ports when you create the component.
Refer to Parameters section for conguration options.
is block contains the majority of the VIC CSRs. e 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 soware trigger controlled by a CSR (even when there is no interrupt source
connected to the irq_input signal).
30-4 csr_access UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Figure 30-3: Interrupt Request Block
irq_input
(external interrupt input)
INT_RAW_STATUS INT_ENABLE INT_PENDING
SW_INTERRUPT
RIL
per port
PortId[5:0]
x32
RRS[5:0]
x32
RNMI
x32
RIL[5:0]
x32
RRS
per port
RNMI
per port
Priority Processing Block
e priority processing block chooses the interrupt with the highest priority. e block receives informa‐
tion for each interrupt from the interrupt request block and passes information for the highest priority
interrupt to the vector generation block.
e interrupt request with the numerically-largest requested interrupt level eld (RIL) has priority. If
multiple interrupts are pending with the same numerically-largest RIL, the numerically-lowest IRQ index
of those interrupts has priority.
e RIL is a programmable interrupt level per port. An RIL value of zero disables the interrupt. You
congure the bit width of the RIL when you create the component. Refer to the Parameters section for
conguration options.
For more information about the RIL, refer to the INT_CONFIG register in the "Register Map" section of this
chapter.
Related Information
Register Maps on page 30-6
Vector Generation Block
e vector generation block receives information for the highest priority interrupt from the priority
processing block. e vector generation block uses the port identier passed from the priority processing
block along with the vector base address and bytes per vector programmed in the CSRs during soware
initialization to compute the RHA.
Table 30-4: RHA Calculation
RHA = (port identier x bytes per vector) + vector base address
e 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. e output
from the VIC typically connects to a processor or another VIC, depending on the design.
UG-01085
2016.12.19 Priority Processing Block 30-5
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Daisy Chaining VIC Cores
You can create a system with more than 32 interrupts by daisy chaining multiple VIC cores together. is
is done by connecting the interrupt_controller_out interface of one VIC to the optional
interrupt_controller_in interface of another VIC. For information about enabling the optional input
interface, refer to the Parameters section.
For performance reasons, always directly connect VIC components. Do not include other components
between VICs.
When daisy chain input comes into the VIC, the priority processing block considers the daisy chain input
along with the hardware and soware interrupt inputs from the interrupt request block to determine the
highest priority interrupt. If the daisy chain input has the highest RIL value, then the vector generation
block passes the daisy chain port values unchanged directly out of the VIC.
You can daisy chain VICs with fewer than 32 interrupt ports. e number of daisy chain connections is
only limited to the hardware and soware resources. Refer to the Latency Information section for details
about the impact of multiple VICs.
Altera recommends setting the RIL width to the same value in all daisy-chained VIC components. If your
RIL widths are dierent, wider RILs from upstream VICs are truncated.
Latency Information
e 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. e
clock delay in the priority processing block varies depending on the total number of interrupt ports.
Table 30-5: Default Interrupt Latencies
Number of
Interrupt Ports
Interrupt Request
Block Delay
Priority Processing
Block Delay
Vector Generation
Block Delay
Total Interrupt Latency
1 1 cycle 0 cycles 1 cycle 2 cycles
2 – 4 1 cycle 1 cycle 1 cycle 3 cycles
5 – 16 1 cycle 2 cycles 1 cycle 4 cycles
17 – 32 1 cycle 3 cycles 1 cycle 5 cycles
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.
Register Maps
e VIC core CSRs are accessible through the Avalon-MM interface. Soware can congure 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.
30-6 Daisy Chaining VIC Cores UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Table 30-6: Control Status Registers
Oset Register Name Access Reset
Value
Description
0 – 31 INT_CONFIG<n> R/W 0 ere are 32 interrupt conguration registers (INT_
CONFIG0 – INT_CONFIG31). Each register contains elds
to congure the behavior of its corresponding interrupt.
If an interrupt input does not exist, reading the
corresponding register always returns zero, and writing is
ignored. Refer to the INT_CONFIG Register Map table
for the INT_CONFIG register map.
32 INT_ENABLE R/W 0 e interrupt enable register. INT_ENABLE holds the
enabled status of each interrupt input. e 32 bits of the
register map to the 32 interrupts available in the VIC
core. For example, bit 5 corresponds to IRQ5. (19)
Interrupt that are not enabled are never considered by the
priority processing block, even when the interrupt input
is asserted. is applies to both maskable and non-
maskable interrupts.
33 INT_ENABLE_SET W 0 e interrupt enable set register. Writing a 1 to a bit in
INT_ENABLE_SET sets the corresponding bit in INT_
ENABLE. Writing a 0 to a bit has no eect. Reading from
this register always returns 0. (19)
34 INT_ENABLE_CLR W 0 e interrupt enable clear register. Writing a 1 to a bit in
INT_ENABLE_CLR clears corresponding bit in INT_ENABLE.
Writing a 0 to a bit has no eect. Reading from this
register always returns 0. (19)
35 INT_PENDING R 0 e interrupt pending register. INT_PENDING shows the
pending interrupts. Each bit corresponds to one interrupt
input.
If an interrupt does not exist, reading its corresponding
INT_PENDING bit always returns 0, and writing is ignored.
Bits in INT_PENDING are set in the following ways:
An external interrupt is asserted at the VIC interface and
the corresponding INT_ENABLE bit is set.
An SW_INTERRUPT bit is set and the corresponding INT_
ENABLE bit is set.
INT_PENDING bits remain set as long as either condition
applies. Refer to the Interrupt Request Block for
details. (19)
UG-01085
2016.12.19 Register Maps 30-7
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Oset Register Name Access Reset
Value
Description
36 INT_RAW_STATUS R 0 e interrupt raw status register. INT_RAW_STATUS shows
the unmasked state of the interrupt inputs.
If an interrupt does not exist, reading the corresponding
INT_RAW_STATUS bit always returns 0, and writing is
ignored.
A set bit indicates an interrupt is asserted at the interface
of the VIC. e interrupt is asserted to the processor only
when the corresponding bit in the interrupt enable
register is set. (19)
37 SW_INTERRUPT R/W 0 e soware interrupt register. SW_INTERRUPT drives the
soware interrupts. Each interrupt is ORed with its
external hardware interrupt and then enabled with INT_
ENABLE. Refer to the Interrupt Request Block for
details. (19)
38 SW_INTERRUPT_SET W 0 e soware interrupt set register. Writing a 1 to a bit in
SW_INTERRUPT_SET sets the corresponding bit in SW_
INTERRUPT. Writing a 0 to a bit has no eect. Reading
from this register always returns 0. (19)
39 SW_INTERRUPT_CLR W 0 e soware interrupt clear register. Writing a 1 to a bit in
SW_INTERRUPT_CLR clears the corresponding bit in SW_
INTERRUPT. Writing a 0 to a bit has no eect. Reading
from this register always returns 0.
40 VIC_CONFIG R/W 0 e VIC conguration register. VIC_CONFIG allows
soware to congure settings that apply to the entire VIC.
Refer to the VIC_CONFIG Register Map table for the
VIC_CONFIG register map.
41 VIC_STATUS R 0 e VIC status register. VIC_STATUS shows the current
status of the VIC. Refer to the VIC_STATUS Register
Map table for the VIC_STATUS register map.
42 VEC_TBL_BASE R/W 0 e vector table base register. VEC_TBL_BASE holds the
base address of the vector table in the processor’s memory
space. Because the table must be aligned on a 4-byte
boundary, bits 1:0 must always be 0.
(19) is register contains a 1-bit eld for each of the 32 interrupt inputs. When the VIC is congured for less
than 32 interrupts, the corresponding 1-bit eld 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 0x to the register and then read the register contents. Any bits that return zero do not have an
interrupt present.
30-8 Register Maps UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Oset Register Name Access Reset
Value
Description
43 VEC_TBL_ADDR R 0 e vector table address register. VEC_TBL_ADDR provides
the RHA for the IRQ value with the highest priority
pending interrupt. If no interrupt is active, the value in
this register is 0.
If daisy chain input is enabled and is the highest priority
interrupt, the vector table address register contains the
RHA value from the daisy chain input interface.
Table 30-7: The INT_CONFIG Register Map
Bits Field Name Access Reset
Value
Description
0:5 RIL R/W 0 e requested interrupt level eld. RIL contains the interrupt level
of the interrupt requesting service. e processor can use the
value in this eld to determine if the interrupt is of higher priority
than what the processor is currently doing.
6RNMI R/W 0 e requested non-maskable interrupt eld. 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 e requested register set eld. RRS contains the number of the
processor register set that the processor should use for processing
the interrupt. Soware must ensure that only register values
supported by the processor are used.
13:31 Reserved
For expanded denitions of the terms in the INT_CONFIG Register Map table, refer to the Exception
Handling chapter of the Nios II Soware Developer’s Handbook.
UG-01085
2016.12.19 Register Maps 30-9
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Table 30-8: The VIC_CONFIG Register Map
Bits Field Name Access Reset
Value
Description
0:2 VEC_SIZE R/W 0 e vector size eld. VEC_SIZE species the number of bytes in each
vector table entry. VEC_SIZE is encoded as log2 (number of words) - 2.
Namely:
0—4 bytes per vector table entry
1—8 bytes per vector table entry
2—16 bytes per vector table entry
3—32 bytes per vector table entry
4—64 bytes per vector table entry
5—128 bytes per vector table entry
6—256 bytes per vector table entry
7—512 bytes per vector table entry
3DC R/W 0 e daisy chain eld. DC serves the following purposes:
Enables and disables the daisy chain input interface, if present. Write a
1 to enable the daisy chain interface; write a 0 to disable it.
Detects the presence of the daisy chain input interface. To detect, write
a 1 to DC and then read DC. A return value of 1 means the daisy chain
interface is present; 0 means the daisy chain interface is not present.
4:31 Reserved
Table 30-9: The VIC_STATUS Register Map
Bits Field
Name
Access Reset
Value
Description
0
:
5
HI_PRI_
IRQ
R 0 e highest priority interrupt eld. HI_PRI_IRQ contains the IRQ
number of the active interrupt with the highest RIL. When there is no
active interrupt (IP is 0), reading from this eld returns 0.
When the daisy chain input is enabled and it is the highest priority
interrupt, then the value read from this eld is 32.
Bit 5 always reads back 0 when the daisy chain input is not present.
6
:
3
0
Reserved
3
1
IP R 0 e interrupt pending eld. IP indicates when there is an interrupt ready
to be serviced. A 1 indicates an interrupt is pending; a 0 indicates no
interrupt is pending.
30-10 Register Maps UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Related Information
•Exception Handling
•Priority Processing Block on page 30-5
UG-01085
2016.12.19 Register Maps 30-11
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Parameters
Generation-time parameters control the features present in the hardware.e table below lists and
describes the parameters you can congure.
Table 30-10: Parameters for VIC Core
Parameter Legal Values Defaul
t
Description
Number of
interrupts
1 – 32 8 Species the number of irq_input interrupt interfaces.
RIL width 1 – 6 4 Species the bit width of the requested interrupt level.
Daisy chain
enable
True / False False Species whether or not to include an input interface for
daisy chaining VICs together.
Override Default
Interrupt Signal
Latency
True/False False Allows manual specication of the interrupt signal
latency.
Manual Interrupt
Signal Latency
2 – 5 2 Species the number of cycles it takes to process
incoming interrupt signals.
Because multiple VICs can exist in a single system, Qsys assigns a unique interrupt controller identica‐
tion number to each VIC generated.
Keep the following considerations in mind when connecting the core in your Qsys system:
•e CSR access interface (csr_access) connects to a data master port on your processor.
•e daisy chain input interface (interrupt_controller_in) is only visible when the daisy chain
enable option is on.
•e interrupt controller output interface (interrupt_controller_out) connects either to the EIC
port of your processor, or to another VIC’s daisy chain input interface (interrupt_controller_in).
• For Qsys interoperability, the VIC core includes an Avalon-MM master port. is master interface is
not used to access memory or peripherals. Its purpose is to allow peripheral interrupts to connect to
the VIC in Qsys. e port must be connected to an Avalon-MM slave to create a valid Qsys system.
en at system generation time, the unused master port is removed during optimization. e 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.
30-12 Parameters UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Altera HAL Software Programming Model
e Altera-provided driver implements a HAL device driver that integrates with a HAL board support
package (BSP) for Nios II systems. HAL users should access the VIC core via the familiar HAL API.
Software Files
e VIC driver includes the following soware les. ese les provide low-level access to the hardware
and drivers that integrate with the Nios II HAL BSP. Application developers should not modify these les.
•altera_vic_regs.h—Denes the core’s 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
—Dene 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.S—Provide the code that
implements the VIC driver.
•altera_<name>_vector_tbl.S—Provides a vector table le for each VIC in the system. e BSP
generator creates these les.
Macros
Macros to access all of the registers are dened in altera_vic_regs.h. For example, this le includes macros
to access the INT_CONFIG register, including the following macros:
#define IOADDR_ALTERA_VIC_INT_CONFIG(base, irq)
__IO_CALC_ADDRESS_NATIVE(base, irq)
#define IORD_ALTERA_VIC_INT_CONFIG(base, irq) IORD(base, irq)
#define IOWR_ALTERA_VIC_INT_CONFIG(base, irq, data) IOWR(base, irq,
data)
#define ALTERA_VIC_INT_CONFIG_RIL_MSK (0x3f)
#define ALTERA_VIC_INT_CONFIG_RIL_OFST (0)
#define ALTERA_VIC_INT_CONFIG_RNMI_MSK (0x40)
#define ALTERA_VIC_INT_CONFIG_RNMI_OFST (6)
#define ALTERA_VIC_INT_CONFIG_RRS_MSK (0x1f80)
#define ALTERA_VIC_INT_CONFIG_RRS_OFST (7)
For a complete list of predened macros and utilities to access the VIC hardware, refer to the following
les:
• <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
UG-01085
2016.12.19 Altera HAL Software Programming Model 30-13
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Data Structure
Example 30-1: Device Data Structure
#define ALT_VIC_MAX_INTR_PORTS (32)
typedef struct alt_vic_dev
{
void *base; /* Base address of VIC */
alt_u32 intr_controller_id; /* Interrupt controller ID */
alt_u32 num_of_intr_ports; /* Number of interrupt ports */
alt_u32 ril_width; /* RIL width */
alt_u32 daisy_chain_present; /* Daisy-chain input present */
alt_u32 vec_size; /* Vector size */
void *vec_addr; /* Vector table base address */
alt_u32 int_config[ALT_VIC_MAX_INTR_PORTS]; /* INT_CONFIG settings
for each interrupt */
} alt_vic_dev;
VIC API
e VIC device driver provides all the routines required of an Altera HAL external interrupt controller
(EIC) device driver. e 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()
ese 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 Soware Developer’s Handbook.
e table below lists the API functions specic to the VIC core and briey describes each. Details of
each function follow the table.
Table 30-11: Function List
Name Description
alt_vic_sw_interrupt_set() Sets the corresponding bit in the SW_INTERRUPT register to
enable a given interrupt via soware.
alt_vic_sw_interrupt_clear() Clears the corresponding bit in the SW_INTERRUPT register to
disable a given interrupt via soware.
alt_vic_sw_interrupt_status() Reads the status of the SW_INTERRUPT register for a given
interrupt.
alt_vic_irq_set_level() Sets the interrupt level for a given interrupt.
Related Information
HAL API Reference
30-14 Data Structure UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
alt_vic_sw_interrupt_set()
Prototype: int alt_vic_sw_interrupt_set(alt_u32 ic_id, alt_u32 irq)
read-safe: No
Available
from ISR:
No
Include: altera_vic_irq.h, altera_vic_regs.h
Parameters: ic_id—the interrupt controller identication number as dened in system.h
irq—the interrupt value as dened in system.h
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
e value in ic_id is invalid
e value in irq is invalid
Description: Triggers a single soware interrupt
alt_vic_sw_interrupt_clear()
Prototype: int alt_vic_sw_interrupt_clear(alt_u32 ic_id, alt_u32 irq)
read-safe: No
Available
from ISR:
Yes; if interrupt preemption is enabled, disable global interrupts before calling this routine.
Include: altera_vic_irq.h, altera_vic_regs.h
Parameters: ic_id—the interrupt controller identication number as dened in system.h
irq—the interrupt value as dened in system.h
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
e value in ic_id is invalid
e value in irq is invalid
Description: Clears a single soware interrupt
alt_vic_sw_interrupt_status()
Prototype: alt_u32 alt_vic_sw_interrupt_status(alt_u32 ic_id, alt_u32 irq)
read-safe: No
Available
from ISR:
Yes; if interrupt preemption is enabled, disable global interrupts before calling this routine.
UG-01085
2016.12.19 alt_vic_sw_interrupt_set() 30-15
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Include: altera_vic_irq.h, altera_vic_regs.h
Parameters: ic_id—the interrupt controller identication number as dened in system.h
irq—the interrupt value as dened in system.h
Returns: Returns non-zero if the corresponding soware trigger interrupt is active; otherwise zero
for one or more of the following reasons:
e corresponding soware trigger interrupt is disabled
e value in ic_id is invalid
e value in irq is invalid
Description: Checks the soware interrupt status for a single interrupt
alt_vic_irq_set_level()
Prototype: int alt_vic_irq_set_level(alt_u32 ic_id, alt_u32 irq, alt_u32 level)
read-safe: No
Available
from ISR:
No
Include: altera_vic_irq.h, altera_vic_regs.h
Parameters: ic_id—the interrupt controller identication number as dened in system.h
irq—the interrupt value as dened in system.h
level—the interrupt level to set
Returns: Returns zero if successful; otherwise non-zero for one or more of the following reasons:
e value in ic_id is invalid
e value in irq is invalid
e value in level is invalid
Description: Sets the interrupt level for a single interrupt.
Altera recommends setting the interrupt level only to zero to disable the interrupt or to the
original value specied in your BSP. Writing any other value could violate the overlapping
register set, priority level, and other design rules. Refer to the VIC BSP Design Rules for
Altera Hal Implementation section for more information.
Run-time Initialization
During system initialization, soware congures the each VIC instance's control registers using settings
specied in the BSP. e RIL, RRS, and RNMI elds are written into the interrupt conguration register of
each interrupt port in each VIC. All interrupts are disabled until other soware registers a handler using
the alt_ic_isr_register() API.
30-16 alt_vic_irq_set_level() UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Board Support Package
e BSP you generate for your Nios II system provides access to the hardware in your system, including
the VIC. e VIC driver includes scripts that the BSP generator calls to get default interrupt settings and
to validate settings during BSP generation. e Nios II BSP Editor provides a mechanism to edit these
settings and generate a BSP for your Qsys design.
e generator produces a vector table le for each VIC in the system, named
altera_<name>_vector_tbl.S. e vector table's source path is added to the BSP Makele for compilation
along with other VIC driver source code. Its contents are based on the BSP settings for each VIC's
interrupt ports.
e VIC does not support runtime stack checking feature (hal.enable_runtime_stack_checking) in the
BSP setting.
VIC BSP Settings
e VIC driver scripts provide settings to the BSP. e number and naming of these settings depends on
your hardware system's conguration, specically, the number of optional shadow register sets in the
Nios II processor, the number of VIC controllers in the system, and the number of interrupt ports each
VIC has.
Certain settings apply to all VIC instances in the system, while others apply to a specic VIC instance.
Settings that apply to each interrupt port apply only to the specied interrupt port number on that VIC
instance.
e remainder of this section lists details and descriptions of each VIC BSP setting.
altera_vic_driver.enable_preemption
Identier: ALTERA_VIC_DRIVER_ISR_PREEMPTION_ENABLED
Type: BooleanDeneOnly
Default value: 1 when all components connected to the VICs support
preemption. 0 when any of the connected components don’t
support preemption.
Destination le: system.h
Description: Enables global interrupt preemption (nesting). When enabled
(set to 1), the macro ALTERA_VIC_DRIVER_ISR_PREEMPTION_
ENABLED is dened in system.h.
Two types of ISR preemption are available. is setting must be
enabled along with other settings to enable specic types of
preemption.
All preemption settings are dependant on whether the device
drivers in your BSP support interrupt preemption. For more
information about preemption, refer to the Exception
Handling chapter of the Nios II Soware Developer’s
Handbook.
Occurs: Once per VIC
UG-01085
2016.12.19 Board Support Package 30-17
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
altera_vic_driver.enable_preemption_into_new_register_set
Identier: ALTERA_VIC_DRIVER_PREEMPTION_INTO_NEW_
REGISTER_SET_ENABLED
Type: BooleanDeneOnly
Default value: 0
Destination le: 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 dierent 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 dened in system.h and the Nios II config.ANI (automatic
nested interrupts) bit is asserted during system soware initiali‐
zation.
Use this setting to limit interrupt preemption to higher priority
(RIL) interrupts that use a dierent register set than a lower
priority interrupt that might be executing. is 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.
Occurs: Once per VIC
altera_vic_driver.enable_preemption_rs_<n>
Identier: ALTERA_VIC_DRIVER_ENABLE_PREEMPTION_RS_<n>
Type: Boolean
Default value: 0
Destination le: system.h
30-18 altera_vic_driver.enable_preemption_into_new_register_set UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Description: Enables interrupt preemption (nesting) if a higher priority
interrupt is asserted while a lower priority ISR is executing, for
all interrupts that target the specied register set number.
When this setting is enabled (set to 1), the vector table for each
VIC utilizes a special interrupt funnel that manages
preemption. All interrupts on all VIC instances assigned to that
register set then use this funnel.
When a higher priority interrupt preempts a lower priority
interrupt running in the same register set, the interrupt funnel
detects this condition and saves the processor registers to the
stack before calling the higher priority ISR. e funnel code
restores registers and allows the lower priority ISR to continue
running once the higher priority ISR completes.
Because this funnel contains additional overhead, enabling this
setting increases interrupt response time substantially for all
interrupts that target a register set where this type of
preemption is enabled.
Use this setting if you must guarantee that a higher priority
interrupt preempts a lower priority interrupt, and you assigned
multiple interrupts at dierent priorities to the same Nios II
shadow register set.
Occurs: Per register set; <n> refers to the register set number.
altera_vic_driver.linker_section
Identier: ALTERA_VIC_DRIVER_LINKER_SECTION
Type: UnquotedString
Default value: .text
Destination le: system.h
UG-01085
2016.12.19 altera_vic_driver.linker_section 30-19
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Description: Species the linker section that each VIC's generated vector
table and each interrupt funnel link to. e memory device that
the specied 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 Soware Developer’s Handbook.
Occurs: Once per VIC
altera_vic_driver.<name>.vec_size
Identier: <name>_VEC_SIZE
Type: DecimalNumber
Default value: 16
Destination le: system.h
Description: Species the number of bytes in each vector table entry. Legal
values are 16, 32, 64, 128, 256, and 512.
e 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.
e vector table's total size is equal to the number of interrupt
ports on the VIC instance multiplied by the vector table entry
size specied in this setting.
Occurs: Per instance; <name> refers to the component name you assign
in Qsys.
altera_vic_driver.<name>.irq<n>_rrs
Identier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RRS
Type: DecimalNumber
Default value: Refer to the Default Settings for RRS and RIL section.
30-20 altera_vic_driver.<name>.vec_size UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Destination le: system.h
Description: Species the RRS for the interrupt connected to the
corresponding port. Legal values are 1 to the number of shadow
register sets dened for the processor.
Occurs: Per IRQ per instance; <name> refers to the VIC’s 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>_ril
Identier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RIL
Type: DecimalNumber
Default value: Refer to Default Settings for RRS and RIL section.
Destination le: system.h
Description: Species 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 VIC’s 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
Identier: ALTERA_VIC_DRIVER_<name>_IRQ<n>_RNMI
Type: Boolean
Default value: 0
Destination le: system.h
Description: Species 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 VIC’s 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.
UG-01085
2016.12.19 altera_vic_driver.<name>.irq<n>_ril 30-21
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Default Settings for RRS and RIL
e default assignment of RRS and RIL values for each interrupt assumes interrupt port 0 on the VIC
instance attached to your processor is the highest priority interrupt, with successively lower priorities as
the interrupt port number increases. Interrupt ports on other VIC instances connected through the rst
VIC's daisy chain interface are assigned successively lower priorities.
To make eective use of the VIC interrupt setting defaults, assign your highest priority interrupts to low
interrupt port numbers on the VIC closest to the processor. Assign lower priority interrupts and interrupts
that do not need exclusive access to a shadow register set, to higher interrupt port numbers, or to another
daisy-chained VIC.
e following steps describe the algorithm for default RIL assignment:
1. e formula 2RIL width -1 is used to calculate the maximum RIL value.
2. interrupt port 0 on the VIC connected to the processor is assigned the highest possible RIL.
3. e RIL value is decremented and assigned to each subsequent interrupt port in succession until the
RIL value is 1.
4. e RILs for all remaining interrupt ports on all remaining VICs in the chain are assigned 1.
e following steps describe the algorithm for default RRS assignment:
5. e highest register set number is assigned to the interrupt with the highest priority.
6. Each subsequent interrupt is assigned using the same method as the default RIL assignment.
For example, consider a system with two VICs, VIC0 and VIC1. Each VIC has an RIL width of 3, and
each has 4 interrupt ports. VIC0 is connected to the processor and VIC1 to the daisy chain interface on
VIC0. e processor has 3 shadow register sets.
Table 30-12: Default RRS and RIL Assignment Example
VIC IRQ RRS RIL
0 0 3 7
0 1 2 6
0 2 1 5
0 3 1 4
1 0 1 3
1 1 1 2
1 2 1 1
1 3 1 1
VIC BSP Design Rules for Altera Hal Implementation
e VIC BSP settings allow for a large number of combinations. is list describes some basic design rules
to follow to ensure a functional BSP:
30-22 Default Settings for RRS and RIL UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
• Each component’s interrupt interface in your system should only be connected to one VIC instance per
processor.
•e 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: e 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.
•e 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 congured to use a real time operating system (RTOS) might have additional soware linked into the
HAL interrupt funnel code using the ALT_OS_INT_ENTER and ALT_OS_INT_EXIT macros. e exact nature
and overhead of this code is RTOS-specic. Additional code adds to interrupt response and recovery time.
Refer to your RTOS documentation to determine if such code is necessary.
Implementing the VIC in Qsys
is section describes how to incorporate one or more VICs in your Qsys system, and how to support the
VIC in soware.
Adding VIC Hardware
When you add a VIC to your Qsys system, you must perform the following high-level tasks:
1. Add the EIC interface to your Nios II processor core
2. Optionally add shadow register sets to your Nios II processor core (required if you intend to use HAL
interrupt support)
3. Add and parameterize one or more VIC components
4. Connect interrupt sources to the VIC component(s)
Adding the EIC Interface Shadow Register Set
is section describes how to add the EIC interface and shadow register sets to a Nios II processor core in
Qsys, through the parameter editor interface.
UG-01085
2016.12.19 RTOS Considerations 30-23
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
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 gure below.
ere 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 gure below.
Figure 30-4: Conguring the Interrupt Controller and Shadow Register Sets
Figure 30-5: Nios II Processor with EIC Interface
Shadow register sets reduce the context switching overhead associated with saving and restoring registers,
which can otherwise be signicant. If possible, add one shadow register set for each interrupt that requires
high performance.
30-24 Adding the EIC Interface Shadow Register Set UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
VIC Instantiation, Parameterization, and Connection
Aer you add the EIC interface and shadow register set(s) to the Nios II processor, you must instantiate
and parameterize the VIC in your Qsys system.
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. e interface hides all components except the VIC, as shown in the
gure below.
3. Double click the Vectored Interrupt Controller component to add this component to your Qsys System.
Figure 30-6: Vectored Interrupt Controller Component
UG-01085
2016.12.19 VIC Instantiation, Parameterization, and Connection 30-25
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
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
e VIC interface allows you to specify the following options:
•Number of Interrupts—e number of interrupts your VIC must support.
•Requested Interrupt Level (RIL) Width—e number of bits allocated to represent the interrupt level
for each interrupt.
•DAISY_CHAIN_ENABLE—Allows the VIC to daisy chain to another EIC. Turn on this option if you
want to support multiple VICs in your system.
Note: Study the VIC Daisy-Chain example that accompanies this document for a usage example.
•Override Default Interrupt Signal Latency—Allows manual specication of the interrupt signal
latency.
•Manual Interrupt Signal Latency—Species the number of cycles it takes to process the incoming
interrupt signals.
When you have nished parameterizing the VIC, click Finish to instantiate the component in your Qsys
system.
30-26 Parameterization UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
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.
Figure 30-8: VIC Interfaces
Aer adding a VIC to the Qsys system, you must parameterize the VIC and the EIC interface at the system
level. Immediately aer you add the VIC, several error messages appear. Resolve these error messages by
executing the following actions in any order:
• Connect the VIC’s 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 conguration.
• 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. is
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
UG-01085
2016.12.19 VIC Connections 30-27
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
When you use the HAL VIC driver, the driver makes a default assignment from register sets to interrupts.
e default assignment makes some assumptions about interrupt priorities, based on how devices are
connected to the VIC.
Note: To make eective use of the VIC interrupt setting defaults, assign your highest priority interrupts to
low interrupt port numbers on the VIC closest to the processor.
Software for VIC
If you write an interrupt handler for a system based on the VIC component, you must use the HAL
enhanced interrupt API to register the handler and control its runtime environment. e enhanced
interrupt API provides a number of functions for use with EICs, including the VIC. is section describes
a subset of the functions in the enhanced interrupt API.
For information about the enhanced interrupt API, refer to “Interrupt Service Routines” in the Exception
Handling chapter of the Nios II Soware Developer’s Handbook.
In particular, this section shows how to code a driver so that it supports both the enhanced API and the
legacy API. is must include testing for the presence of the enhanced API, and conditionally calling the
appropriate function.
Related Information
Interrupt Service Routines
alt_ic_isr_register() versus alt_irq_register()
e enhanced API function alt_ic_isr_register() is very similar to the legacy function
alt_irq_register(), with a few important dierences. e dierences between these two functions are
best understood by examining the code in Example 30-2. is example registers a timer interrupt in either
the legacy API or the enhanced API, whichever is implemented in the board support package (BSP). e
example is taken directly from the example code accompanying this document.
Example 30-2: Registering an ISR with Both APIs
#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
30-28 Software for VIC UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
e rst 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 Soware Build Tools select which API to implement in a BSP, refer
to “Interrupt Service Routines” in the Exception Handling chapter of the Nios II Soware Developer’s
Handbook.
Example 30-3 shows the function prototype for alt_ic_isr_register(), which registers an ISR in the
enhanced API. e interrupt controller identier (for argument ic_id) and the interrupt port number (for
argument irq) are dened in system.h.
Example 30-3: Enhanced Function alt_ic_isr_register()
extern int alt_ic_isr_register(alt_u32 ic_id,
alt_u32 irq,
alt_isr_func isr,
void *isr_context,
void *flags);
For comparison, Example 30-4 shows the function prototype for alt_irq_register(), which
registers an ISR in the legacy API.
Example 30-4: Legacy Function alt_irq_register()
extern int alt_irq_register (alt_u32 id,
void* context,
alt_isr_func handler);
e arguments passed into alt_ic_isr_register() are slightly dierent from those passed into
alt_irq_register(). e table below compares the arguments to the two functions.
Table 30-13: Arguments to alt_ic_isr_register() versus alt_irq_register()
alt_ic_isr_register() Argument Purpose alt_irq_register() Argument
alt_u32 ic_id Unique interrupt controller ID
as dened in system.h.
—
alt_u32 irq Interrupt request (IRQ)
number as dened in
system.h.
alt_u32 id
alt_isr_func isr Interrupt service routine (ISR)
function pointer
handler
void* isr_context Optional pointer to a
component-specic data
structure.
context
void* flags Reserved. Other EIC
implementations might use
this argument.
None
UG-01085
2016.12.19 alt_ic_isr_register() versus alt_irq_register() 30-29
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
ere are other signicant dierences between the legacy interrupt API and the enhanced interrupt API.
Some of these dierences impact the ISR body itself. Notably, the two APIs employ completely dierent
interrupt preemption models. e example code accompanying this document illustrates many of the
dierences.
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 Soware Developer’s Handbook.
Related Information
•Exception Handling
•HAL API Reference
Example Designs
is 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 soware
examples on the Cyclone V SoC development kit.
Related Information
VIC_collateral_cv.zip
Example Description
e example designs are provided in a le 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.
Table 30-14: Example Designs in VIC_collateral_cv.zip
Example Name Folder Name Description
VIC Basic VIC_Example A single VIC
VIC Daisy-Chain VIC_DaisyChain_Example Two daisy-chained VICs
VIC Table-Resident VIC_ISRnVectorTable_
Example
VIC with ISR located in vector table
IIC VIC_noVIC_Example IIC example, for comparison with the VIC
examples
e top-level folder in VIC_collateral_cv.zip, called VIC_collateral_cv, contains the following les:
•run_sw.sh—Shell script to run one, several or all of the examples
•README.txt—Describes the .zip le contents
30-30 Example Designs UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Figure 30-10: VIC Basic Example
Figure 30-11: VIC Daisy-Chain Example
UG-01085
2016.12.19 Example Description 30-31
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
e IIC design is the same as the VIC Basic design, with the VIC and the EIC interface replaced by the
IIC. e VIC Table-Resident design is identical to the VIC Basic design.
In each example, the soware uses timers in conjunction with performance counters to measure the
interrupt performance. Each example’s soware 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 example’s
performance on your own hardware. ereaer, you can modify any of the examples to investigate the
VIC’s 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 le to a working directory, expanding folder names.
Note: e 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
e script shows a list of options.
6. Run run_sw.sh again, using a command-line option that species the example you would like to run,
or to run all of the examples. Example 30-5 shows a sample session.
e run_sw.sh script performs the following steps:
a. Parses the command line argument(s) to determine which example(s) to run
b. Downloads the .sof for the selected example
c. Downloads the .elf for the selected example
d. Starts nios2-terminal to capture the soware’s output
Software Description
e soware for the various example designs is very similar. For example, the dierence between the
soware for the VIC Basic example and the soware for the IIC example is the printf() call that
generates the output to the terminal.
30-32 Example Usage UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
All of the soware performs the following steps:
1. Congures the timer used for measurement purposes
2. Registers an interrupt service routine (ISR)
3. Sets a global variable to 0xfeedface
4. Starts the performance counter to measure the interrupt time
5. Waits for the ISR to set the global variable to 0xfacefeed
6. Stops the performance counter and computes the interrupt time
e VIC Daisy-Chain example performs the measurement for both VICs connected in the daisy chain,
shown in Figure 30-11.
In all these design examples, the GCC compiler in Nios II SBT tool is set to optimization level 2. Also,
some settings are modied during BSP generation in order to reduce the code size. All these setting can be
found in the create-this-bsp script included in the design example. Note that the number of clock cycles
shows in these design examples will be dier from this document if the setting is dierent.
For details about how the VIC Table-Resident example code works, refer to “Positioning the ISR in the
Vector Table”. For details about performance counter usage in the example soware, refer to “Latency
Measurement with the Performance Counter”.
UG-01085
2016.12.19 Software Description 30-33
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Example 30-5: VIC Example
Related Information
•Positioning the ISR in Vector Table on page 30-35
•Latency Measurement with the Performance Counter on page 30-36
30-34 Software Description UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Positioning the ISR in Vector Table
If have a critical ISR of small size, you can achieve the best performance by positioning the ISR code
directly in the vector table. In this way, you eliminate the overhead of branching from the vector table
through the HAL funnel to your ISR.is section describes how to modify the VIC Basic example soware
to create the VIC Table-Resident example. Use this example to ensure that you understand the steps. en
you can make the equivalent changes in your custom code.
Positioning an ISR in a vector table is an advanced and error-prone technique, not directly supported by
the HAL. You must exercise great caution to ensure that the ISR code ts in the vector table entry. If your
ISR overows the vector table entry, it corrupts other entries in the vector table, and your entire interrupt
handling system.
When locate your ISR in the vector table, it does not need to be registered. Do not call
alt_ic_isr_register(), because it overwrites the contents of the vector table.
When the ISR is in the vector table, the HAL does not provide funnel code. erefore, 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 ISR’s 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.
e VIC Table-Resident example requires modifying a BSP-generated le, altera_vic1_vector_tbl.S. If you
regenerate the BSP aer making these modications, the Nios II Soware Build Tools regenerate
altera_vic1_vector_tbl.S, and your changes are overwritten.
Related Information
Soware Description on page 30-32
Increase the Vector Table Entry Size
To insert the ISR in the vector table, you must increase the size of the vector entries so that your entire ISR
ts in a vector table entry. Use the altera_vic_driver.<vic_instance>.vec_size BSP setting to adjust
the vector table entry size. On the Nios II Soware Build Tools command line, you can manipulate this
setting with the --set command-line option. You can also modify this setting in the Nios II BSP Editor.
In the VIC Table-Resident example, <vic_instance> is VIC1 and <size> is set to 256 bytes.
Do Not Register the ISR
Remove the call to alt_ic_isr_register() for the interrupt that you place in the vector table. Replace it
with an alt_ic_irq_enable() call. You must not call alt_ic_isr_register(), because it overwrites the
contents of the vector table, destroying the body of your ISR.
UG-01085
2016.12.19 Positioning the ISR in Vector Table 30-35
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Insert ISR in Vector Table
In the VIC Table-Resident example included with this document, the ISR code is in a le called vector.h in
the BSP folder.
To insert this code in the vector table, execute the following steps:
1. Generate the BSP by running the create-this-bsp script.
2. Modify altera_vic1_vector_tbl.S as shown in the example below.
Example 30-6: Modications to altera_vic1_vector_tbl.S
#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
Aer completion of these steps, build the soware, run it, and observe the reported interrupt time. is
example is about 18 clock cycles faster than the unmodied 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
Latency Measurement with the Performance Counter
e Altera Complete Design Suite provides tools that enable you to make fast, accurate performance
measurements. All examples included with this document use the Performance Counter component to
measure interrupt latency.
e examples execute the following steps to measure the total time spent to service an interrupt:
1. Initialize a global variable, interrupt_watch_value, to a known value, 0xfeedface.
2. Set up a timer interrupt, registering an ISR that sets interrupt_watch_value to 0xfacefeed.
3. Start the timer.
4. Wait in a while() loop until interrupt_watch_value becomes 0xfacefeed.
5. Immediately aer exiting the while() loop, stop the performance counter, compute clock cycles and
display the calculated value on stdout.
You can use similar methods to determine the real-time interrupt latencies in your system.
Related Information
•Soware Description on page 30-32
•Real Time Latency Concerns on page 30-37
30-36 Insert ISR in Vector Table UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Advanced Topics
is section presents several topics that are useful for advanced interrupt handling.
Real Time Latency Concerns
is section presents an overview of interrupt latency, the elements that combine to determine interrupt
latency, and methods for measuring it. e following elements comprise interrupt latency:
• Pipeline latency
• Cause latency
• Selection latency
• Funnel latency
• Compiler-related latency
Figure 30-12: The Elements of Interrupt Latency
Interrupt Request
Pipeline Latency
Interrupt Recovery
(Back-end Funnel)
Interrupt Latency
Cause,
Selection
&
Funnel
Latency
Background Background
ISR Code
Time
is section summarizes each element of latency and describes how to measure latency. e 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
UG-01085
2016.12.19 Advanced Topics 30-37
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
Pipeline Latency
Pipeline latency is dened as the number of clock cycles between an interrupt signal being asserted and
the execution of the rst 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. eoreti‐
cally, this time could be innite 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 soware 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. e selection latency with the VIC component depends on the
number of interrupts that it services. e table below outlines selection latency on a single VIC as a
function of the number of interrupts.
Table 30-15: The Components of VIC Latency
Total Number of
Interrupts
Interrupt Request
Clock Delay
(clocks)
Priority Processing
Clock Delay
(clocks)
Vector Generation
Clock Delay
(clocks)
Total Interrupt Latency
(clocks)
1 2 0 1 3
2—4 2 1 1 4
5—16 2 2 1 5
17—32 2 3 1 6
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
•e number of clock cycles required for load and store instructions
• Whether the interrupt requires switching to a dierent 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. e 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 driver’s
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.
30-38 Pipeline Latency UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Table 30-16: Single Stack HAL latency
Funnel Type Clock Cycles Required for Load or Store
1 2
Shadow register set,
preemption within the
register set disabled
10 13
Shadow register set,
preemption within the
register set enabled
42
Same register set
(sstatus.SRS=0)
64
Same register set (sstatus.SRS=0)
26
Dierent register set
(sstatus.SRS=1)
32
Dierent register set (sstatus.SRS=1)
Table 30-17: Separate Interrupt Stack HAL Latency
Funnel Type Clock Cycles Required for Load or Store
1 2
Shadow register set,
preemption within the
register set disabled
11
Not preempting another
interrupt (sstatus.IH=0)
14
Not preempting another interrupt
(sstatus.IH=0)
12
Preempting another interrupt
(sstatus.IH=1)
15
Preempting another interrupt
(sstatus.IH=1)
Shadow register set,
preemption within the
register set enabled
42
Same register set
(sstatus.SRS=0)
64
Same register set (sstatus.SRS=0)
27
•Dierent register set
(sstatus.SRS=1)
• Not preempting another
interrupt (sstatus.IH=0)
33
•Dierent register set (sstatus.SRS=1)
• Not preempting another interrupt
(sstatus.IH=0)
28
•Dierent register set
(sstatus.SRS=1)
• Preempting another
interrupt (sstatus.IH=1)
34
•Dierent register set (sstatus.SRS=1)
• Preempting another interrupt
(sstatus.IH=1)
UG-01085
2016.12.19 Funnel Latency 30-39
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
In the tables above, notice that the lowest latencies occur under the following conditions:
• A dierent register set—Shadow register set switch; the ISR runs in a dierent 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:
•e same register set—No 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 dierence in latencies. With preemption
disabled, much lower latencies occur regardless of other factors.
Compiler-Related Latency
e GNU C compiler creates a prologue and epilogue for many C functions, including ISRs. e prologue
and epilogue are code sequences that take care of housekeeping tasks, such as saving and restoring context
for the C runtime environment. e time required for the prologue and epilogue is called compiler-related
latency.
e 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 function’s 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
Soware can trigger any VIC interrupt by writing to the appropriate VIC control and status register (CSR).
Soware can trigger the interrupt connected to any hardware interrupt source, as well as interrupts that
are not connected to hardware (soware-only interrupts).
Triggering an interrupt from soware is useful for debugging. Soware can control exactly when an
interrupt is triggered, and measure the system’s interrupt response.
You can use a soware-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
soware-only interrupt at a lower priority level to complete the interrupt processing.
e following functions are available for managing soware interrupts:
•alt_vic_sw_interrupt_set()
•alt_vic_sw_interrupt_clear()
•alt_vic_sw_interrupt_status()
e implementations of these functions are in bsp/hal/drivers/src/altera_vic_sw_intr.c aer you generate
the BSP.
Note: You must dene a value for the interrupt number in SOFT_IRQ.
30-40 Compiler-Related Latency UG-01085
2016.12.19
Altera Corporation Vectored Interrupt Controller Core
Send Feedback
Example 30-7: Registering a Software Interrupt
alt_ic_isr_register(
VIC1_INTERRUPT_CONTROLLER_ID,
SOFT_IRQ,
soft_interrupt_latency_irq,
NULL, NULL)
Example 30-8: Registering a Timer Interrupt (for Comparison)
alt_ic_isr_register(
LATENCY_TIMER_IRQ_INTERRUPT_CONTROLLER_ID,
LATENCY_TIMER_IRQ,
timer_interrupt_latency_irq,
LATENCY_TIMER_BASE,
NULL);
e following code generates a soware interrupt:
alt_vic_sw_interrupt_set(VIC1_INTERRUPT_CONTROLLER_ID, SOFT_IRQ);
Document Revision History
Table 30-18: Vectored Interrupt Controller Core History
Date Version Changes
May 2016 2016.05.03 Sections Added:
• Implementing VIC in Qsys
• Example Designs
• Advanced Topics
Novemeber 2015 2015.11.06 Updated:
•Table 30-3
•Table 30-5
•Table 30-10
December 2013 v13.1.0 Updated the INT_ENABLE register description.
December 2010 v10.1.0 Added a note to to state that the VIC does not support the runtime
stack checking feature in BSP setting.
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 Initial release.
UG-01085
2016.12.19 Document Revision History 30-41
Vectored Interrupt Controller Core Altera Corporation
Send Feedback
System ID Core 31
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e system ID core with Avalon® interface is a simple read-only device that provides Qsys systems with a
unique identier. Nios® II processor systems use the system ID core to verify that an executable program
was compiled targeting the actual hardware image congured 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 soware will not execute
correctly.
Functional Description
e system ID core provides a read-only Avalon Memory-Mapped (Avalon-MM) slave interface. is
interface has two 32-bit registers, as shown in the table below. e value of each register is determined at
system generation time, and always returns a constant value.
Table 31-1: System ID Core Register Map
Oset Register Name R/W Description
0id R A unique 32-bit value that is based on the contents of the
Qsys system. e id is similar to a check-sum value; Qsys
systems with dierent components, dierent congura‐
tion options, or both, produce dierent id values.
1timestamp R A unique 32-bit value that is based on the system
generation time. e value is equivalent to the number of
seconds aer Jan. 1, 1970.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
ere are two basic ways to use the system ID core:
• Verify the system ID before downloading new soware to a system. is method is used by soware
development tools, such as the Nios II integrated development environment (IDE). ere is little point
in downloading a program to a target hardware system, if the program is compiled for dierent
hardware. erefore, the Nios II IDE checks that the system ID core in hardware matches the expected
system ID of the soware before downloading a program to run or debug.
• Check system ID aer reset. If a program is running on hardware other than the expected Qsys system,
the program may fail to function altogether. If the program does not crash, it can behave erroneously in
subtle ways that are dicult to debug. To protect against this case, a program can compare the expected
system ID against the system ID core, and report an error if they do not match.
Conguration
e id and timestamp register values are determined at system generation time based on the
conguration 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.
Aer 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 le each time you generate the Qsys
system, the Quartus Prime soware recompiles the entire system if you have added the system as a design
partition.
Software Programming Model
is section describes the soware programming model for the system ID core. For Nios II processor
users, Altera provides the HAL system library header le that denes the System ID core registers.
e System ID core comes with the following soware les. ese les provide low-level access to the
hardware. Application developers should not modify these les.
•alt_avalon_sysid_regs.h—Denes the interface to the hardware registers.
•alt_avalon_sysid.c, alt_avalon_sysid.h—Header and source les dening the hardware
access functions.
Altera provides one access routine, alt_avalon_sysid_test(), that returns a value indicating
whether the system ID expected by soware matches the system ID core.
alt_avalon_sysid_test()
Prototype: alt_32 alt_avalon_sysid_test(void)
read-safe: No.
Available
from ISR:
Yes.
Include: <altera_avalon_sysid.h>
31-2 Conguration UG-01085
2016.12.19
Altera Corporation System ID Core
Send Feedback
Description: Returns 0 if the values stored in the hardware registers match the values expected by
soware. Returns 1 if the hardware timestamp is greater than the soware timestamp.
Returns -1 if the soware timestamp is greater than the hardware timestamp.
Document Revision History
Table 31-2: System ID Core 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.
July 2010 v10.0.0 No change from previous release.
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.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
UG-01085
2016.12.19 Document Revision History 31-3
System ID Core Altera Corporation
Send Feedback
Performance Counter Core 32
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e performance counter core with Avalon® interface enables relatively unobtrusive, real-time proling of
soware 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.
e main benet of using the performance counter core is the accuracy of the proling results. Alterna‐
tives include the following approaches:
• GNU proler, gprof—gprof provides broad low-precision timing information about the entire
soware 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 peripheral—e interval timer is less intrusive than gprof. It can provide good results
for narrowly targeted sections of code.
e performance counter core is unobtrusive, requiring only a single instruction to start and stop
proling, and no RAM. It is appropriate for high-precision measurements of narrowly targeted sections
of code.
For further discussion of all three proling methods, refer to AN 391: Proling Nios II Systems.
e 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.
Functional Description
e performance counter core is a set of counters which track clock cycles, timing multiple sections of
your soware. You can start and stop these counters in your soware, individually or as a group. You can
read cycle counts from hardware registers.
e core contains two counters for every section:
• Time: A 64-bit clock cycle counter.
• Events: A 32-bit event counter.
Section Counters
Each 64-bit time counter records the aggregate number of clock cycles spent in a section of code. e 32-
bit event counter records the number of times the section executes.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
e performance counter core can have up to seven section counters.
Global Counter
e global counter controls all section counters. e section counters are enabled only when the global
counter is running.
e 64-bit global clock cycle counter tracks the aggregate time for which the counters were enabled. e
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
e 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.
Table 32-1: Performance Counter Core Register Map
Oset Register Name
Bit Description
Read Write
31 ... 0 31 ... 1 0
0T[0]lo global clock cycle counter [31: 0] (1) 0 = STOP
1 = RESET
1T[0]hi global clock cycle counter [63:32] (1) 0 = START
2Ev[0] global event counter (1) (1)
3 — (1) (1) (1)
4T[1]lo section 1 clock cycle counter [31:0] (1) 1 = STOP
5T[1]hi section 1 clock cycle counter [63:32] (1) 0 = START
6Ev[1] section 1 event counter (1) (1)
7 — (1) (1) (1)
8T[2]lo section 2 clock cycle counter [31:0] (1) 1 = STOP
9T[2]hi section 2 clock cycle counter [63:32] (1) 0 = START
10 Ev[2] section 2 event counter (1) (1)
11 — (1) (1) (1)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4n + 0 T[n]lo section n clock cycle counter [31:0] (1) 1 = STOP
4n + 1 T[n]hi section n clock cycle counter [63:32] (1) 0 = START
4n + 2 Ev[n] section n event counter (1) (1)
32-2 Global Counter UG-01085
2016.12.19
Altera Corporation Performance Counter Core
Send Feedback
Oset Register Name
Bit Description
Read Write
31 ... 0 31 ... 1 0
4n + 3 — (1) (1) (1)
Table 32-1 :
1. Reserved. Read values are undened. When writing, set reserved bits to zero.
System Reset
Aer a system reset, the performance counter core is stopped and disabled, and all counters are set to zero.
Conguration
e following sections list the available options in the MegaWizard™ interface.
Dene Counters
Choose the number of section counters you want to generate by selecting from the Number of
simultaneously-measured sections list. e performance counter core may have up to seven sections. If
you require more that seven sections, you can instantiate multiple performance counter cores.
Multiple Clock Domain Considerations
If your Qsys system uses multiple clocks, place the performance counter core in the same clock domain as
the CPU. Otherwise, it is not possible to convert cycle counts to seconds correctly.
Hardware Simulation Considerations
You can use this core in simulation with no special considerations.
Software Programming Model
e following sections describe the soware programming model for the performance counter core.
Software Files
Altera provides the following soware les for Nios II systems. ese les dene the low-level access to the
hardware and provide control and reporting functions. Do not modify these les.
•altera_avalon_performance_counter.h, altera_avalon_performance_counter.c—
e header and source code for the functions and macros needed to control the performance counter
core and retrieve raw results.
•perf_print_formatted_report.c—e source code for simple prole reporting.
UG-01085
2016.12.19 System Reset 32-3
Performance Counter Core Altera Corporation
Send Feedback
Using the Performance Counter
In a Nios II system, you can control the performance counter core with a set of highly ecient C macros,
and extract the results with C functions.
API Summary
e Nios II application program interface (API) for the performance counter core consists of functions,
macros and constants.
Table 32-2: Performance Counter Macros and Functions
Name Summary
PERF_RESET() Stops and disables all counters, resetting them to 0.
PERF_START_MEASURING() Starts the global counter and enables section counters.
PERF_STOP_MEASURING() Stops the global counter and disables section counters.
PERF_BEGIN() Starts timing a code section.
PERF_END() Stops timing a code section.
perf_print_formatted_report() Sends a formatted summary of the proling results to stdout.
perf_get_total_time() Returns the aggregate global proling time in clock cycles.
perf_get_section_time() Returns the aggregate time for one section in clock cycles.
perf_get_num_starts() Returns the number of counter events.
alt_get_cpu_freq() Returns the CPU frequency in Hz.
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 dened in system.h. e
constant names are based on the performance counter instance name, specied on the System Contents
tab in Qsys.
Table 32-3: Performance Counter Constants
Name (1) Meaning
PERFORMANCE_COUNTER_BASE Base address of core
PERFORMANCE_COUNTER_SPAN Number of hardware registers
PERFORMANCE_COUNTER_HOW_
MANY_SECTIONS
Number of section counters
Table 32-3 :
1. Example based on instance name performance_counter.
32-4 Using the Performance Counter UG-01085
2016.12.19
Altera Corporation Performance Counter Core
Send Feedback
Startup
Before using the performance counter core, invoke PERF_RESET to stop, disable and zero all counters.
Global Counter Usage
Use the global counter to enable and disable the entire performance counter core. For example, you might
choose to leave proling disabled until your soware has completed its initialization.
Section Counter Usage
To measure a section in your code, surround it with the macros PERF_BEGIN() and PERF_END(). ese
macros consist of a single write to the performance counter core.
You can simultaneously measure as many code sections as you like, up to the number specied in Qsys.
See the Dene Counters section for details. You can start and stop counters individually, or as a group.
Typically, you assign one counter to each section of code you intend to prole. However, in some situations
you may wish to group several sections of code in a single section counter. As an example, to measure
general interrupt overhead, you can measure all interrupt service routines (ISRs) with one counter.
To avoid confusion, assign a mnemonic symbol for each section number.
Viewing Counter Values
Library routines allow you to retrieve and analyze the results. Use perf_print_formatted_report() to
list the results to stdout, as shown below.
Table 32-4: Example 1:
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");
e example below creates a table similar to this result.
UG-01085
2016.12.19 Using the Performance Counter 32-5
Performance Counter Core Altera Corporation
Send Feedback
Table 32-5: Example 2:
--Performance Counter Report--
Total Time: 2.07711 seconds (103855534 clock-cycles)
+-----------------+--------+-----------+---------------+-----------+
| Section | % | Time (sec)| Time (clocks) |Occurrences|
+-----------------+--------+-----------+---------------+-----------+
|1st checksum_test| 50 | 1.03800 | 51899750 | 1 |
+-----------------+--------+-----------+---------------+-----------+
| pc_overhead |1.73e-05| 0.00000 | 18 | 1 |
+-----------------+--------+-----------+---------------+-----------+
| ts_overhead |4.24e-05| 0.00000 | 44 | 1 |
+-----------------+--------+-----------+---------------+-----------+
For full documentation of perf_print_formatted_report(), see the Performance and Counter API
section.
Interrupt Behavior
e 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. e same applies to context
switches in a multithreaded environment. Your soware must take appropriate measures to avoid or
handle these situations.
Performance Counter API
is section describes the application programming interface (API) for the performance counter core.
For Nios II processor users, Altera provides routines to access the performance counter core hardware.
ese functions are specic to the performance counter core and directly manipulate low level hardware.
e performance counter core cannot be accessed via the HAL API or the ANSI C standard library.
PERF_RESET()
Prototype: PERF_RESET(p)
read-safe: Yes.
Available
from ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
32-6 Interrupt Behavior UG-01085
2016.12.19
Altera Corporation Performance Counter Core
Send Feedback
Parameters: p—performance counter core base address.
Returns: —
Description: Macro PERF_RESET() stops and disables all counters, resetting them to 0.
PERF_START_MEASURING()
Prototype: PERF_START_MEASURING(p)
read-safe: Yes.
Available
from ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: p—performance counter core base address.
Returns: —
Description: Macro PERF_START_MEASURING() starts the global counter, enabling the
performance counter core. e behavior of individual section counters is
controlled by PERF_BEGIN() and PERF_END(). PERF_START_MEASURING() denes
the start of a global event, and increments the global event counter. is macro is
a single write to the performance counter core.
PERF_STOP_MEASURING()
Prototype: PERF_STOP_MEASURING(p)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: p—performance counter core base address.
Returns: —
Description: Macro PERF_STOP_MEASURING() stops the global counter, disabling the perform‐
ance counter core. is macro is a single write to the performance counter core.
PERF_BEGIN()
Prototype: PERF_BEGIN(p,n)
read-safe: Yes.
UG-01085
2016.12.19 PERF_START_MEASURING() 32-7
Performance Counter Core Altera Corporation
Send Feedback
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: p—performance counter core base address.
n—counter section number. Section counter numbers start at 1. Do not refer to
counter 0 in this macro.
Returns: —
Description: Macro PERF_BEGIN() starts the timer for a code section, dening 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. is macro is a
single write to the performance counter core.
PERF_END()
Prototype: PERF_END(p,n)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: p—performance counter core base address.
n—counter section number. Section counter numbers start at 1. Do not refer to
counter 0 in this macro.
Returns: —
Description: Macro PERF_END() stops timing a code section. e section counter does not
run, regardless whether the core is enabled or not. is macro is a single write to
the performance counter core.
perf_print_formatted_report()
Prototype: int perf_print_formatted_report (
void* perf_base,
alt_u32 clock_freq_hertz,
int num_sections,
char* section_name_1, ...
char* section_name_n)
32-8 PERF_END() UG-01085
2016.12.19
Altera Corporation Performance Counter Core
Send Feedback
read-safe: No.
Available from
ISR:
No.
Include: <altera_avalon_performance_counter.h>
Parameters: perf_base—Performance counter core base address.
clock_freq_hertz—Clock frequency.
num_sections—e number of section counters to display. is must not exceed
<instance_name>_HOW_MANY_SECTIONS.
section_name_1 ... section_name_n—e section names to display. e
number of section names varies depending on the number of sections to display.
Returns: 0
Description: Function perf_print_formatted_report() reads the proling results from the
performance counter core, and prints a formatted summary table.
is 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()
Prototype: alt_u64 perf_get_total_time(void* hw_base_address)
read-safe: No.
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: hw_base_address—base address of performance counter core.
Returns: Aggregate global time in clock cycles.
Description: Function perf_get_total_time() reads the raw global time. is is the
aggregate time, in clock cycles, that the performance counter core has been
enabled. is function has the side eect of stopping the counters.
perf_get_section_time()
Prototype: alt_u64 perf_get_section_time
(void* hw_base_address, int which_section)
read-safe: No.
UG-01085
2016.12.19 perf_get_total_time() 32-9
Performance Counter Core Altera Corporation
Send Feedback
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: hw_base_address—performance counter core base address.
which_section—counter section number.
Returns: Aggregate section time in clock cycles.
Description: Function perf_get_section_time() reads the raw time for a given section.
is is the time, in clock cycles, that the section has been running. is function
has the side eect of stopping the counters.
perf_get_num_starts()
Prototype: alt_u32 perf_get_num_starts
(void* hw_base_address, int which_section)
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters: hw_base_address—performance counter core base address.
which_section—counter section number.
Returns: Number of counter events.
Description: Function perf_get_num_starts() retrieves the number of counter events (or
times a counter has been started). If which_section = 0, it retrieves the number
of global events (times the performance counter core has been enabled). is
function does not stop the counters.
alt_get_cpu_freq()
Prototype: alt_u32 alt_get_cpu_freq()
read-safe: Yes.
Available from
ISR:
Yes.
Include: <altera_avalon_performance_counter.h>
Parameters:
Returns: CPU frequency in Hz.
32-10 perf_get_num_starts() UG-01085
2016.12.19
Altera Corporation Performance Counter Core
Send Feedback
Description: Function alt_get_cpu_freq() returns the CPU frequency in Hz.
Document Revision History
Table 32-6: Performance Counter Core Revision History
Date Version Changes
June 2015 2015.06.12 Updated "Performance Counter Core Register Map" table.
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 Updated perf_print_formatted_report() to remove the restriction
on using small C library.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Updated the parameter description of the function perf_print_
formatted_report().
UG-01085
2016.12.19 Document Revision History 32-11
Performance Counter Core Altera Corporation
Send Feedback
Avalon Streaming Test Pattern Generator and
Checker Cores 33
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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.
e test pattern generator core can insert dierent error conditions, and the test pattern checker reports
these error conditions to the control interface, each via an Avalon Memory-Mapped (Avalon-MM) slave.
Resource Utilization and Performance
Resource utilization and performance for the test pattern generator and checker cores depend on the data
width, number of channels, and whether the streaming data uses the optional packet protocol.
Table 33-1: Test Pattern Generator Estimated Resource Utilization and Performance
No. of
Channe
ls
Datawi
dth
(No. of
8-bit
Symbol
s Per
Beat)
Packet
Suppor
t
Stratix® II and Stratix II GX Cyclone® II Stratix
fMAX
(MHz)
ALM
Count
Memor
y (bits)
fMAX
(MHz)
Logic
Cells
Memor
y (bits)
fMAX
(MHz)
Logic
Cells
Memory
(bits)
1 4 Yes 284 233 560 206 642 560 202 642 560
1 4 No 293 222 496 207 572 496 245 561 496
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
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Table 33-2: Test Pattern Checker Estimated Resource Utilization and Performance
No. of
Channe
ls
Datawi
dth
(No. of
8-bit
Symbol
s Per
Beat)
Packet
Suppor
t
Stratix II and Stratix II GX Cyclone II Stratix
fMAX
(MHz)
ALM
Count
Memor
y (bits)
fMAX
(MHz)
Logic
Cells
Memor
y (bits)
fMAX
(MHz)
Logic
Cells
Memory
(bits)
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
Test Pattern Generator
is section describes the hardware structure and functionality of the test pattern generator core.
Functional Description
e 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 dierent interfaces.
Test Pattern Generator Core Block Diagram
TEST PATTERN
GENERATOR
command data_out
control & status
M
M
-
n
o
l
a
v
At
r
o
P
e
v
a
l
S
Avalon-MM
Slave Port
T
S
-
n
o
l
a
v
Ae
c
r
u
o
S
e data pattern is determined by the following equation:
Symbol Value = Symbol Position in Packet XOR Data Error Mask. Non-packetized data is one long stream
with no beginning or end.
e test pattern generator core has a throttle register that is set via the Avalon-MM control interface. e
value of the throttle register is used in conjunction with a pseudo-random number generator to throttle
the data generation rate.
33-2 Test Pattern Generator UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Command Interface
e 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.
e command interface maps to the following registers: cmd_lo and cmd_hi. e 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). e
errors are only cleared when 0 is written to this register or its respective elds. See page the Test Pattern
Generator Command Registers section for more information on the register elds.
Control and Status Interface
e control and status interface is a 32-bit Avalon-MM slave that allows you to enable or disable the data
generation as well as set the throttle.
is interface also provides useful generation-time information such as the number of channels and
whether or not packets are supported.
Output Interface
e output interface is an Avalon-ST interface that optionally supports packets. You can congure the
output interface to suit your requirements.
Depending on the incoming stream of commands, the output data may contain interleaved packet
fragments for dierent channels. To keep track of the current symbol’s position within each packet, the test
pattern generator core maintains an internal state for each channel.
Conguration
e following sections list the available options in the MegaWizard™ interface.
Functional Parameter
e functional parameter allows you to congure the test pattern generator as a whole: rottle Seed—
e 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 congure the output interface of the test pattern generator core using the following parameters:
•Number of Channels—e number of channels that the test pattern generator core supports. Valid
values are 1 to 256.
•Data Bits Per Symbol—e number of bits per symbol for the input and output interfaces. Valid values
are 1 to 256. Example—For typical systems that carry 8-bit bytes, set this parameter to 8.
•Data Symbols Per Beat—e number of symbols (words) that are transferred per beat. Valid values
are 1 to 256.
•Include Packet Support—Indicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
•Error Signal Width (bits)—e 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.
UG-01085
2016.12.19 Conguration 33-3
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Test Pattern Checker
is section describes the hardware structure and functionality of the test pattern checker core.
Functional Description
e 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 dierent interfaces.
e test pattern checker has a throttle register that is set via the Avalon-MM control interface. e value of
the throttle register controls the rate at which data is accepted.
Figure 33-1: Test Pattern Checker
TEST PATTERN
CHECKER
data_in
control & status
Avalon-MM
Slave Port
T
S
-
n
o
l
a
v
Ak
n
i
S
e 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 aer they are read by the
control and status interface.
Input Interface
e input interface is an Avalon-ST interface that optionally supports packets. You can congure the input
interface to suit your requirements.
Incoming data may contain interleaved packet fragments. To keep track of the current symbol’s position,
the test pattern checker core maintains an internal state for each channel.
Control and Status Interface
e control and status interface is a 32-bit Avalon-MM slave that allows you to enable or disable data
acceptance as well as set the throttle. is interface provides useful generation-time information such as
the number of channels and whether the test pattern checker supports packets.
33-4 Test Pattern Checker UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
e control and status interface also provides information on the exceptions detected by the test pattern
checker core. e interface obtains this information by reading from the exception FIFO.
Conguration
e following sections list the available options in the MegaWizard™ interface.
Functional Parameter
e functional parameter allows you to congure the test pattern checker as a whole: rottle Seed—e
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 congure the input interface of the test pattern checker core using the following parameters:
•Data Bits Per Symbol—e number of bits per symbol for the input interface. Valid values are 1 to
256.
•Data Symbols Per Beat—e number of symbols (words) that are transferred per beat. Valid values
are 1 to 32.
•Include Packet Support—Indicates whether or not packet transfers are supported. Packet support
includes the startofpacket, endofpacket, and empty signals.
•Number of Channels—e number of channels that the test pattern checker core supports. Valid
values are 1 to 256.
•Error Signal Width (bits)—e 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.
Hardware Simulation Considerations
e test pattern generator and checker cores do not provide a simulation testbench for simulating a stand-
alone instance of the component. However, you can use the standard SOPC Builder simulation ow to
simulate the component design les inside an SOPC Builder system.
Software Programming Model
is section describes the soware programming model for the test pattern generator and checker cores.
HAL System Library Support
For Nios II processor users, Altera provides HAL system library drivers that enable you to initialize and
access the test pattern generator and checker cores. Altera recommends you to use the provided drivers to
access the cores instead of accessing the registers directly.
For Nios II IDE users, copy the provided drivers from the following installation folders to your soware
application directory:
• <IP installation directory> /ip /sopc_builder_ip /altera_avalon_data_source/HAL
• <IP installation directory>/ip/sopc_builder_ip/ altera_avalon_data_sink/HAL
is instruction does not apply if you use the Nios II command-line tools.
UG-01085
2016.12.19 Conguration 33-5
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Software Files
e following soware les dene the low-level access to the hardware, and provide the routines for the
HAL device drivers. Application developers should not modify these les.
•Soware les provided with the test pattern generator core:
•data_source_regs.h—e header le that denes the test pattern generator's register maps.
•data_source_util.h, data_source_util.c—e header and source code for the functions
and variables required to integrate the driver into the HAL system library.
•Soware les provided with the test pattern checker core:
•data_sink_regs.h—e header le that denes the core’s register maps.
•data_sink_util.h, data_sink_util.c—e header and source code for the functions and
variables required to integrate the driver into the HAL system library.
Register Maps
is section describes the register maps for the test pattern generator and checker cores.
Test Pattern Generator Control and Status Registers
e table below shows the oset 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
Oset Register Name
base + 0 status
base + 1 control
base + 2 fill
Table 33-4: Status Field Descriptions
Bit(s) Name Access Description
[15:0] ID RO A constant value of 0x64.
[23:16] NUMCHANNELS RO e congured number of channels.
[30:24] NUMSYMBOLS RO e congured number of symbols per beat.
[31] SUPPORTPACKETS RO A value of 1 indicates packet support.
Table 33-5: Control Field Descriptions
Bit(s) Name Access Description
[0] ENABLE RW Setting this bit to 1 enables the test pattern generator core.
[7:1] Reserved
33-6 Software Files UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Bit(s) Name Access Description
[16:8] THROTTLE RW Species the throttle value which can be between 0–256, inclusively.
is value is used in conjunction with a pseudorandom number
generator to throttle the data generation rate.
Setting THROTTLE to 0 stops the test pattern generator core. Setting
it to 256 causes the test pattern generator core to run at full throttle.
Values between 0–256 result in a data rate proportional to the
throttle value.
[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
Table 33-6: Fill Field Descriptions
Bit(s) Name Access Description
[0] BUSY RO A value of 1 indicates that data transmission is in progress, or that
there is at least one command in the command queue.
[6:1] Reserved
[15:7] FILL RO e number of commands currently in the command FIFO.
[31:16] Reserved
Test Pattern Generator Command Registers
e table below shows the oset for the command registers. Each register is 32 bits wide.
Table 33-7: Test Pattern Command Register Map
Oset Register Name
base + 0 cmd_lo
base + 1 cmd_hi
e command is pushed into the FIFO only when the cmd_lo register is written to.
Table 33-8: cmd_lo Field Descriptions
Bit(s) Name Access Description
[15:0] SIZE RW e segment size in symbols. Except for the last segment in a packet,
the size of all segments must be a multiple of the congured number of
symbols per beat. If this condition is not met, the test pattern generator
core inserts additional symbols to the segment to ensure the condition
is fullled.
[29:16] CHANNEL RW e channel to send the segment on. If the channel signal is less than
14 bits wide, the low order bits of this register are used to drive the
signal.
UG-01085
2016.12.19 Register Maps 33-7
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Bit(s) Name Access Description
[30] SOP RW Set this bit to 1 when sending the rst segment in a packet. is bit is
ignored when packets are not supported.
[31] EOP RW Set this bit to 1 when sending the last segment in a packet. is bit is
ignored when packets are not supported.
Table 33-9: cmd_hi Field Descriptions
Bit(s) Name Access Description
[15:0] SIGNALLED
ERROR
RW Species the value to drive the error signal. A non-zero value
creates a signalled error.
[23:16] DATA ERROR RW e output data is XORed with the contents of this register to create
data errors. To stop creating data errors, set this register to 0.
[24] SUPRESS SOP RW Set this bit to 1 to suppress the assertion of the startofpacket
signal when the rst segment in a packet is sent.
[25] SUPRESS EOP RW Set this bit to 1 to suppress the assertion of the endofpacket signal
when the last segment in a packet is sent.
Test Pattern Checker Control and Status Registers
e table below shows the oset for the control and status registers. Each register is 32 bits wide.
Table 33-10: Test Pattern Checker Control and Status Register Map
Oset Register Name
base + 0 status
base + 1 control
base + 2
Reservedbase + 3
base + 4
base + 5 exception_descriptor
base + 6 indirect_select
base + 7 indirect_count
Table 33-11: Status Field Descriptions
Bit(s) Name Access Description
[15:0] ID RO Contains a constant value of 0x65.
[23:16] NUMCHANNELS RO e congured number of channels.
[30:24] NUMSYMBOLS RO e congured number of symbols per beat.
[31] SUPPORTPACKETS RO A value of 1 indicates packet support.
33-8 Register Maps UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Table 33-12: Control Field Descriptions
Bit(s) Name Access Description
[0] ENABLE RW Setting this bit to 1 enables the test pattern checker.
[7:1] Reserved
[16:8] THROTTLE RW Species the throttle value which can be between 0–256, inclusively.
is value is used in conjunction with a pseudorandom number
generator to throttle the data generation rate.
Setting THROTTLE to 0 stops the test pattern generator core. Setting
it to 256 causes the test pattern generator core to run at full throttle.
Values between 0–256 result in a data rate proportional to the
throttle value.
[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
e table below describes the exception_descriptor register bits. If there is no exception, reading this
register returns 0.
Table 33-13: exception_descriptor Field Descriptions
Bit(s) Name Access Description
[0] DATA ERROR RO A value of 1 indicates that an error is detected in the incoming data.
[1] MISSINGSOP RO A value of 1 indicates missing start-of-packet.
[2] MISSINGEOP RO A value of 1 indicates missing end-of-packet.
[7:3] Reserved
[15:8] SIGNALLED
ERROR
RO e value of the error signal.
[23:16] Reserved
[31:24] CHANNEL RO e channel on which the exception was detected.
Table 33-14: indirect_select Field Descriptions
Bit Bits Name Access Description
[7:0] INDIRECT
CHANNEL
RW Species the channel number that applies to the INDIRECT PACKET
COUNT, INDIRECT SYMBOL COUNT, and INDIRECT ERROR COUNT
registers.
[15:8] Reserved
[31:16] INDIRECT
ERROR
RO e number of data errors that occurred on the channel specied by
INDIRECT CHANNEL.
UG-01085
2016.12.19 Register Maps 33-9
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Table 33-15: indirect_count Field Descriptions
Bit Bits Name Access Description
[15:0] INDIRECT
PACKET COUNT
RO e number of packets received on the channel specied by
INDIRECT CHANNEL.
[31:16] INDIRECT
SYMBOL COUNT
RO e number of symbols received on the channel specied by
INDIRECT CHANNEL.
Test Pattern Generator API
is section describes the application programming interface (API) for the test pattern generator core. All
API functions are currently not available from the interrupt service routine (ISR).
data_source_reset()
Prototype: void data_source_reset(alt_u32 base);
read-safe: No.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: void.
Description: is function resets the test pattern generator core including all internal counters
and FIFOs. e control and status registers are not reset by this function.
data_source_init()
Prototype: int data_source_init(alt_u32 base, alt_u32 command_base);
read-safe: No.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
command_base—e base address of the command slave.
Returns: 1—Initialization is successful.
0—Initialization is unsuccessful.
33-10 Test Pattern Generator API UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Description: is 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()
Prototype: int data_source_get_id(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e test pattern generator core’s identier.
Description: is function retrieves the test pattern generator core’s identier.
data_source_get_supports_packets()
Prototype: int data_source_init(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: 1—Packets are supported.
0—Packets are not supported.
Description: is function checks if the test pattern generator core supports packets.
data_source_get_num_channels()
Prototype: int data_source_get_num_channels(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e number of channels supported.
UG-01085
2016.12.19 data_source_get_id() 33-11
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Description: is function retrieves the number of channels supported by the test pattern
generator core.
data_source_get_symbols_per_cycle()
Prototype: int data_source_get_symbols(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e number of symbols transferred in a beat.
Description: is function retrieves the number of symbols transferred by the test pattern
generator core in each beat.
data_source_set_enable()
Prototype: void data_source_set_enable(alt_u32 base, alt_u32 value);
read-safe: No.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
value—e ENABLE bit is set to the value of this parameter.
Returns: void.
Description: is 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()
Prototype: int data_source_get_enable(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e value of the ENABLE bit.
Description: is function retrieves the value of the ENABLE bit.
33-12 data_source_get_symbols_per_cycle() UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
data_source_set_throttle()
Prototype: void data_source_set_throttle(alt_u32 base, alt_u32 value);
read-safe: No.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
value—e throttle value.
Returns: void.
Description: is function sets the throttle value, which can be between 0–256 inclusively. e
throttle value, when divided by 256 yields the rate at which the test pattern
generator sends data.
data_source_get_throttle()
Prototype: int data_source_get_throttle(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e throttle value.
Description: is function retrieves the current throttle value.
data_source_is_busy()
Prototype: int data_source_is_busy(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: 1—e test pattern generator core is busy.
0—e core is not busy.
Description: is function checks if the test pattern generator is busy. e test pattern
generator core is busy when it is sending data or has data in the command FIFO
to be sent.
UG-01085
2016.12.19 data_source_set_throttle() 33-13
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
data_source_ll_level()
Prototype: int data_source_fill_level(alt_u32 base);
read-safe: Yes.
Include: <data_source_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e number of commands in the command FIFO.
Description: is function retrieves the number of commands currently in the command
FIFO.
data_source_send_data()
Prototype: int data_source_send_data(alt_u32 cmd_base, alt_u16 channel, alt_
u16 size, alt_u32 flags, alt_u16 error, alt_u8 data_error_mask);
read-safe: No.
Include: <data_source_util.h>
Parameters: cmd_base—e base address of the command slave.
channel—e channel to send the data on.
size—e data size.
flags—Species 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.
error—e value asserted on the error signal on the output interface.
data_error_mask—is parameter and the data are XORed together to produce
erroneous data.
Returns: Always returns 1.
33-14 data_source_ll_level() UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Description: is function sends a data fragment to the specied channel.
If packets are supported, user applications must ensure the following conditions
are met:
SOP and EOP are used consistently in each channel.
Except for the last segment in a packet, the length of each segment is a multiple of
the data width.
If packets are not supported, user applications must ensure the following
conditions are met:
No SOP and EOP indicators in the data.
e length of each segment in a packet is a multiple of the data width.
Test Pattern Checker API
is section describes the API for the test pattern checker core. e API functions are currently not
available from the ISR.
data_sink_reset()
Prototype: void data_sink_reset(alt_u32 base);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: void.
Description: is function resets the test pattern checker core including all internal counters.
data_sink_init()
Prototype: int data_source_init(alt_u32 base);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: 1—Initialization is successful.
0—Initialization is unsuccessful.
UG-01085
2016.12.19 Test Pattern Checker API 33-15
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Description: is 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()
Prototype: int data_sink_get_id(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e test pattern checker core’s identier.
Description: is function retrieves the test pattern checker core’s identier.
data_sink_get_supports_packets()
Prototype: int data_sink_init(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: 1—Packets are supported.
0—Packets are not supported.
Description: is function checks if the test pattern checker core supports packets.
data_sink_get_num_channels()
Prototype: int data_sink_get_num_channels(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e number of channels supported.
Description: is function retrieves the number of channels supported by the test pattern
checker core.
33-16 data_sink_get_id() UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
data_sink_get_symbols_per_cycle()
Prototype: int data_sink_get_symbols(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e number of symbols received in a beat.
Description: is function retrieves the number of symbols received by the test pattern
checker core in each beat.
data_sink_set enable()
Prototype: void data_sink_set_enable(alt_u32 base, alt_u32 value);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
value—e ENABLE bit is set to the value of this parameter.
Returns: void.
Description: is function enables the test pattern checker core.
data_sink_get_enable()
Prototype: int data_sink_get_enable(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e value of the ENABLE bit.
Description: is function retrieves the value of the ENABLE bit.
data_sink_set_throttle()
Prototype: void data_sink_set_throttle(alt_u32 base, alt_u32 value);
read-safe: No.
Include: <data_sink_util.h>
UG-01085
2016.12.19 data_sink_get_symbols_per_cycle() 33-17
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Parameters: base—e base address of the control and status slave.
value—e throttle value.
Returns: void.
Description: is function sets the throttle value, which can be between 0–256 inclusively. e
throttle value, when divided by 256 yields the rate at which the test pattern
checker receives data.
data_sink_get_throttle()
Prototype: int data_sink_get_throttle(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e throttle value.
Description: is function retrieves the throttle value.
data_sink_get_packet_count()
Prototype: int data_sink_get_packet_count(alt_u32 base, alt_u32 channel);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
channel—Channel number.
Returns: e number of packets received on the given channel.
Description: is function retrieves the number of packets received on a given channel.
data_sink_get_symbol_count()
Prototype: int data_sink_get_symbol_count(alt_u32 base, alt_u32 channel);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
channel—Channel number.
33-18 data_sink_get_throttle() UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
Returns: e number of symbols received on the given channel.
Description: is function retrieves the number of symbols received on a given channel.
data_sink_get_error_count()
Prototype: int data_sink_get_error_count(alt_u32 base, alt_u32 channel);
read-safe: No.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
channel—Channel number.
Returns: e number of errors received on the given channel.
Description: is function retrieves the number of errors received on a given channel.
data_sink_get_exception()
Prototype: int data_sink_get_exception(alt_u32 base);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: base—e base address of the control and status slave.
Returns: e rst exception descriptor in the exception FIFO.
0—No exception descriptor found in the exception FIFO.
Description: is function retrieves the rst exception descriptor in the exception FIFO and
pops it o the FIFO.
data_sink_exception_is_exception()
Prototype: int data_sink_exception_is_exception(int exception);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor
Returns: 1—Indicates an exception.
0—No exception.
Description: is function checks if a given exception descriptor describes a valid exception.
UG-01085
2016.12.19 data_sink_get_error_count() 33-19
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
data_sink_exception_has_data_error()
Prototype: int data_sink_exception_has_data_error(int exception);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor.
Returns: 1—Data has errors.
0—No errors.
Description: is function checks if a given exception indicates erroneous data.
data_sink_exception_has_missing_sop()
Prototype: int data_sink_exception_has_missing_sop(int exception);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor.
Returns: 1—Missing SOP.
0—Other exception types.
Description: is function checks if a given exception descriptor indicates missing SOP.
data_sink_exception_has_missing_eop()
Prototype: int data_sink_exception_has_missing_eop(int exception);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor.
Returns: 1—Missing EOP.
0—Other exception types.
Description: is function checks if a given exception descriptor indicates missing EOP.
data_sink_exception_signalled_error()
Prototype: int data_sink_exception_signalled_error(int exception);
33-20 data_sink_exception_has_data_error() UG-01085
2016.12.19
Altera Corporation Avalon Streaming Test Pattern Generator and Checker Cores
Send Feedback
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor.
Returns: e signalled error value.
Description: is function retrieves the value of the signalled error from the exception.
data_sink_exception_channel()
Prototype: int data_sink_exception_channel(int exception);
read-safe: Yes.
Include: <data_sink_util.h>
Parameters: exception—Exception descriptor.
Returns: e channel number on which the given exception occurred.
Description: is function retrieves the channel number on which a given exception occurred.
Document Revision History
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.
November 2009 v9.1.0 No change from previous release.
March 2009 v9.0.0 No change from previous release.
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 Updated the section on HAL System Library Support.
UG-01085
2016.12.19 data_sink_exception_channel() 33-21
Avalon Streaming Test Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Avalon Streaming Data Pattern Generator and
Checker Cores 34
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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.
Data Pattern Generator
is section describes the hardware structure and functionality of the data pattern generator core.
Functional Description
e data pattern generator core accepts commands to generate and drive data onto a parallel Avalon-ST
source interface.
Figure 34-1: Data Pattern Generator Core Block Diagram
DATA PATTERN
GENERATOR
data_out
control & status
T
S
-
n
o
l
a
v
Ae
c
r
u
o
S
Avalon-MM
Slave Port
You can congure the width of the output data signal to either 32-bit or 40-bit when instantiating the core.
You can congure 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. e core’s data
format endianness is the most signicant symbol rst within a beat and the most signicant bit rst within
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
a symbol. For example, when you congure the output data to 32-bit, bit 31 is the rst data bit, followed by
bit 30, and so forth. is interface’s 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. e
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.
Control and Status Interface
e control and status interface is an Avalon-MM slave that allows you to enable or disable the data
generation. is interface also provides the run-time ability to choose data pattern and inject an error into
the data stream.
Output Interface
e output interface is a parallel Avalon-ST interface. You can congure the data width at the output
interface to suit your requirements.
Supported Data Patterns
e following data patterns are supported in the following manner, per beat. When the core is disabled or
in idle state, the default pattern generated on the data output is 0×5555 (for 32-bit data width) or 0×55555
(for 40-bit data width).
Table 34-1: Supported Data Patterns (Binary Encoding)
Pattern 32-bit 40-bit
PRBS-7 PRBS in parallel PRBS in parallel
PRBS-15 PRBS in parallel PRBS in parallel
PRBS-23 PRBS in parallel PRBS in parallel
PRBS-31 PRBS in parallel PRBS in parallel
High Frequency 10101010 x 4 1010101010 x 4
Low Frequency 11110000 x 4 1111100000 x 4
Note to Table 34-1 :
1. All PRBS patterns are seeded with 11111111.
is core does not support custom data patterns.
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
rst output cycle.
34-2 Functional Description UG-01085
2016.12.19
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
e Inject Error register bit is automatically reset aer the error is introduced in the pipeline, so that
the next error can be injected.
Preamble Mode
e preamble mode is used for synchronization or word alignment. When the preamble mode is set, the
preamble control register sends the preamble character a specied 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.
e 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. e default
setting is 0 and the maximum value is 255 beats. is mode can only be set when the data pattern
generation core is disabled.
Conguration
e following section lists the available option in the MegaWizard™ interface.
Output Parameter
You can congure the output interface of the data pattern generator core using the following parameter:
•ST_DATA_W — e width of the output data signal that the data pattern generator core supports.
Valid values are 32 and 40.
Data Pattern Checker
is section describes the hardware structure and functionality of the data pattern checker core.
Functional Description
e 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
DATA PATTERN
CHECKER
data_in
control & status
T
S
-
n
o
l
a
v
Ak
n
i
S
Avalon-MM
Slave Port
You can congure the width of the output data signal to either 32-bit or 40-bit when instantiating the core.
e chosen data width is not congurable during run time.
You can congure 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. e core’s data
UG-01085
2016.12.19 Conguration 34-3
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
format endianness is the most signicant symbol rst within a beat and the most signicant bit rst within
a symbol. For example, when you congure the output data to 32-bit, bit 31 is the rst data bit, followed by
bit 30, and so forth. is interface’s endianness may change in future versions of the core.
If you congure 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 congure the width of the output data to 40-bit, the core inputs four 10-bit wide symbols
per beat. e 10-bit and 20-bit input can be achieved by switching from 4 symbols per beat to 1 and 2
symbols per beat.
Control and Status Interface
e control and status interface is an Avalon-MM slave that allows you to enable or disable the pattern
checking. is interface also provides the run-time ability to choose the data pattern and read the status
signals.
Input Interface
e input interface is a parallel Avalon-ST interface. You can congure the data width at this interface to
suit your requirements.
Supported Data Patterns
e following data patterns are supported in the following manner, per beat. When the core is disabled or
in idle state, the default pattern generated on the data output is 0×5555 (for 32-bit data width) or 0×55555
(for 40-bit data width).
Table 34-2: Supported Data Patterns (Binary Encoding)
Pattern 32-bit 40-bit
PRBS-7 PRBS in parallel PRBS in parallel
PRBS-15 PRBS in parallel PRBS in parallel
PRBS-23 PRBS in parallel PRBS in parallel
PRBS-31 PRBS in parallel PRBS in parallel
High Frequency 10101010 x 4 1010101010 x 4
Low Frequency 11110000 x 4 1111100000 x 4
Lock
e lock bit in the status register is asserted when 40 consecutive beats of correct data are received. e
lock bit is deasserted and the receiver loses the lock when 40 consecutive beats of incorrect data are
received.
Bit and Error Counters
e core has two 64-bit internal counters to keep track of the number of bits and number of error bits
received. A snapshot has to be executed to update the NumBits and NumErrors registers with the current
value from the internal counters.
34-4 Functional Description UG-01085
2016.12.19
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
A counter reset can be executed to reset both the registers and internal counters. If the counters are not
being reset and the core is enabled, the internal counters continues the increment base on their current
value.
e internal counters only start to increment aer a lock has been acquired.
Conguration
e following section lists the available option in the MegaWizard™ interface.
Input Parameter
You can congure the input interface of the data pattern checker core using the following parameter:
•ST_DATA_W — e width of the input data signal that the data pattern checker core supports. Valid
values are 32 and 40.
Hardware Simulation Considerations
e data pattern generator and checker cores do not provide a simulation testbench for simulating a
stand-alone instance of the component. However, you can use the standard SOPC Builder simulation ow
to simulate the component design les inside an SOPC Builder system.
Software Programming Model
is section describes the soware programming model for the data pattern generator and checker cores.
Register Maps
is section describes the register maps for the data pattern generator and checker cores.
Data Pattern Generator Control Registers
Table 34-3: Data Pattern Generator Register Map
Oset Register Name
base + 0 Enable
base + 1 Pattern Select
base + 2 Inject Error
base + 3 Preamble Control
base + 4 Preamble Character (Lower Bits)
base + 5 Preamble Character (Higher Bits)
Table 34-4: Enable Field Descriptions
Bit(s) Name Access Description
[0] EN RW Setting this bit to 1 enables the data pattern generator core.
UG-01085
2016.12.19 Conguration 34-5
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Bit(s) Name Access Description
[31:1] Reserved
Note to Table 34-4 :
1. When the core is enabled, only the Enable register and the Inject Error register have write access.
Write access to all other registers are ignored.e rst valid data is observed from the Avalon-ST
Source interface at the fourth cycle aer the Enable bit is set. When the core is disabled, the nal
output is observed at the next clock cycle.
Table 34-5: Pattern Select Field Descriptions
Bit(s) Name Access Description
[0] PRBS7 RW Setting this bit to 1 outputs a PRBS 7 pattern with T [7, 6].
[1] PRBS15 RW Setting this bit to 1 outputs a PRBS 15 pattern with T [15, 14].
[2] PRBS23 RW Setting this bit to 1 outputs a PRBS 23 pattern with T [23, 18].
[3] PRBS31 RW Setting this bit to 1 outputs a PRBS 31 pattern with T [31, 28].
[4] HF RW Setting this bit to 1 outputs a constant pattern of 0101010101… bits.
[5] LF RW Setting this bit to 1 outputs a constant word pattern of 1111100000
for 10-bit words, or 11110000 for 8-bit words.
[31:8] Reserved
Note to Table 34-5 :
1. is register is one-hot encoded where only one of the pattern selector bits should be set to 1. For all
other settings, the behaviors are undened.
is register allows you to set the error inject bit and insert one bit of error into the stream.
Table 34-6: Inject Error Field Descriptions (Note 1)
Bit(s) Name Access Description
[0] IJ RW Setting this bit to 1 injects error into the stream. If the IJ bit is set to
1 when the core is enabled, the bit resets itself to 0 at the next clock
cycle when the error is injected.
[31:1] Reserved
Note to Table 34-6 :
1. e LSB of the data beat is ipped at the fourth clock cycle aer the IJ bit is set (if not being backpres‐
sured by the sink when it is valid). e data beat that is injected with error might not be observed from
the source if the core is disabled within the next two cycles aer IJ bit is set to 1.
is register enables preamble and set the number of cycles to output the preamble character.
34-6 Register Maps UG-01085
2016.12.19
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
Table 34-7: Preamble Control Field Descriptions
Bit(s) Name Access Description
[0] EP RW Setting this bit to 1, at the start of pattern generation, enables the
preamble character to be sent for NumBeats cycles before switching
over to the selected pattern.
[7:1] Reserved
[15:8] NumBeats RW e number of beats to repeat the preamble character.
[31:16] Reserved
is register is for the user-dened preamble character (bit 0-31).
Table 34-8: Preamble Character Low Bits Field Descriptions
Bit(s) Name Access Description
[31:0] Preamble Character
(Lower Bits)
RW Sets bit 31-0 for the preamble character to output.
is register is for the user-dened preamble character (bit 32-39) but is ignored if the ST_DATA_W value is
set to 32.
Table 34-9: Preamble Character High Bits Field Descriptions
Bit(s) Name Access Description
[7:0] Preamble Character
(Higher Bits)
RW Sets bit 39-32 for the preamble character. is is ignored
when the ST_DATA_W value is set to 32.
[31:8] Reserved
Data Pattern Checker Control and Status Registers
Table 34-10: Data Pattern Checker Control and Status Register Map
Oset Register Name
base + 0 Status
base + 1 Pattern Set
base + 2 Counter Control
base + 3 NumBits (Lower Bits)
base + 4 NumBits (Higher Bits)
base + 5 NumErrors (Lower Bits)
base + 6 NumErrors (Higher Bits)
UG-01085
2016.12.19 Register Maps 34-7
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Table 34-11: Status Field Descriptions
Bit(s) Name Access Description
[0] EN RW Setting this bit to 1 enables pattern checking.
[1] LK R Indicate lock status (writing to this bit has no eect).
[31:2] Reserved
Note to Table 34-11 :
1. When the core is enabled, only the Status register’s EN bit and the counter control register have
write access. Write access to all other registers are ignored.
Table 34-12: Pattern Select Field Descriptions
Bit(s) Name Access Description
[0] PRBS7 RW Setting this bit to 1 compares the data to a PRBS 7 pattern with T [7,
6].
[1] PRBS15 RW Setting this bit to 1 compares the data to a PRBS 15 pattern with T
[15, 14].
[2] PRBS23 RW Setting this bit to 1 compares the data to a PRBS 23 pattern with T
[23, 18].
[3] PRBS31 RW Setting this bit to 1 compares the data to a PRBS 31 pattern with T
[31, 28].
[4] HF RW Setting this bit to 1 compares the data to a constant pattern of
0101010101… bits.
[5] LF RW Setting this bit to 1 compares the data to a constant word pattern of
1111100000 for 10-bit words, or 11110000 for 8-bit words.
[31:8] Reserved
Note to Table 34-12 :
1. is register is one-hot encoded where only one of the pattern selector bits should be set to 1. For all
other settings, the behaviors are undened.
is register snapshots and resets the NumBits, NumErrors, and also the internal counters.
Table 34-13: Counter Control Field Descriptions
Bit(s) Name Access Description
[0] SN W Writing this bit to 1 captures the number of bits received and
number of error bits received from the internal counters to the
respective NumBits and NumErrors registers within the same clock
cycle.
Writing this bit to 1 aer disabling the core will still capture the
correct values from the internal counters to the NumBits and
NumErrors registers.
34-8 Register Maps UG-01085
2016.12.19
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
Bit(s) Name Access Description
[17] RST W Writing this bit to 1 resets all internal counters and statistics. is
bit resets itself automatically aer 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
is register is the lower word of the 64-bit bit counter snapshot value. e register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Table 34-14: NumBits (Lower Word) Field Descriptions
Bit(s) Name Access Description
[31:0] NumBits (Lower
Bits)
R Sets bit 31-0 for the NumBits (number of bits received).
is register is the higher word of the 64-bit bit counter snapshot value. e register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Table 34-15: NumBits (Higher Word) Field Descriptions
Bit(s) Name Access Description
[31:0] NumBits (Higher
Bits)
R Sets bit 63-32 for the NumBits (number of bits received).
is register is the lower word of the 64-bit error counter snapshot value. e register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Table 34-16: NumErrors (Lower Word) Field Descriptions
Bit(s) Name Access Description
[31:0] NumErrors
(Lower Bits)
R Sets bit 31-0 for the NumErrors (number of error bits received).
is register is the higher word of the 64-bit error counter snapshot value. e register is reset when the
component-reset is asserted or when the RST bit is set to 1.
Table 34-17: NumErrors (Higher Word) Field Descriptions
Bit(s) Name Access Description
[31:0] NumErrors
(Higher Bits)
R Sets bit 63-32 for the NumErrors (number of error bits received).
UG-01085
2016.12.19 Register Maps 34-9
Avalon Streaming Data Pattern Generator and Checker Cores Altera Corporation
Send Feedback
Document Revision History
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.
January 2010 v9.1.1 Initial release.
34-10 Document Revision History UG-01085
2016.12.19
Altera Corporation Avalon Streaming Data Pattern Generator and Checker Cores
Send Feedback
PLL Cores 35
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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
wrapper around the Altera ALTPLL megafunction.
e PLL core is scheduled for product obsolescence and discontinued support. erefore, Altera
recommends that you use the Avalon ALTPLL core in your designs.
e core takes an SOPC Builder system clock as its input and generates PLL output clocks locked to that
reference clock.
e PLL cores support the following features:
• All PLL features provided by Altera's ALTPLL megafunction. e exact feature set depends on the
device family.
• Access to status and control signals via Avalon Memory-Mapped (Avalon-MM) registers or top-level
signals on the SOPC Builder system module.
• Dynamic phase reconguration in Stratix III and Stratix IV device families.
e PLL output clocks are made available in two ways:
• As sources to system-wide clocks in your SOPC Builder system.
• As output signals on your SOPC Builder system module.
For details about the ALTPLL megafunction, refer to the ALTPLL Megafunction User Guide.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Functional Description
Figure 35-1: PLL Core Block Diagram
Status
Control
areset
pfdena
pllena
inclk
e1
e0
c1
c0
locked PLL Locked
Avalon-MM
Slave Interface
PLL Reset
PFD Enable
PLL Enable
Reference
Clock
Registers
PLL Core
ALTPLL Megafunction
PLL Clock
Outputs
ALTPLL Megafunction
e PLL cores consist of an ALTPLL megafunction instantiation and an Avalon-MM slave interface. is
interface can optionally provide access to status and control registers within the cores. e 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. ey cannot be used as on-chip
clock sources. External clock outputs are not available on all device families.
e Avalon ALTPLL core, however, does not dierentiate 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.
PLL Status and Control Signals
Depending on how the ALTPLL megafunction is parameterized, there can be a variable number of status
and control signals. You can choose to export certain status and control signals to the top-level SOPC
Builder system module. Alternatively, Avalon-MM registers can provide access to the signals. Any status or
35-2 Functional Description UG-01085
2016.12.19
Altera Corporation PLL Cores
Send Feedback
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.
System Reset Considerations
At FPGA conguration, the PLL cores reset automatically. PLL-specic reset circuitry guarantees that the
PLL locks before releasing reset for the overall SOPC Builder system module.
Resetting the PLL resets the entire SOPC Builder system module.
Instantiating the Avalon ALTPLL Core
When you instantiate the Avalon ALTPLL core, the MegaWizard Plug-In Manager is automatically
launched for you to parameterize the ALTPLL megafunction. ere are no additional parameters that you
can congure in SOPC Builder.
e pfdena signal of the ALTPLL megafunction is not exported to the top level of the SOPC Builder
module. You can drive this port by writing to the PFDENA bit in the control register.
e locked, pllena/extclkena, and areset signals of the megafunction are always exported to the top
level of the SOPC Builder module. You can read the locked signal and reset the core by manipulating
respective bits in the registers. See the Register Denitions and Bit List section for more information on
the registers.
For details about using the ALTPLL MegaWizard Plug-In Manager, refer to the ALTPLL Megafunction
User Guide.
Instantiating the PLL Core
is section describes the options available in the MegaWizard™ interface for the PLL core in SOPC
Builder.
PLL Settings Page
e PLL Settings page contains a button that launches the ALTPLL MegaWizard Plug-In Manager. Use
the MegaWizard Plug-In Manager to parameterize the ALTPLL megafunction. e set of available
parameters depends on the target device family.
You cannot click Finish in the PLL wizard nor congure the PLL interface until you parameterize the
ALTPLL megafunction.
Interface Page
e Interface page congures the access modes for the optional advanced PLL status and control signals.
UG-01085
2016.12.19 System Reset Considerations 35-3
PLL Cores Altera Corporation
Send Feedback
For each advanced signal present on the ALTPLL megafunction, you can select one of the following access
modes:
•Export—Exports the signal to the top level of the SOPC builder system module.
•Register—Maps the signal to a bit in a status or control register.
e 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. e ALTPLL core signals,
not displayed in this table, are automatically exported to the top level of the SOPC Builder system
module.
Table 35-1: ALTPLL Advanced Signal
ALTPLL
Name
Input /
Outpu
t
Avalon-MM PLL
Wizard Name
Default Behavior Description
ares
et
input PLL Reset Input e PLL is reset only
at device congura‐
tion.
is signal resets the entire SOPC Builder
system module, and restores the PLL to its
initial settings.
plle
na
input PLL Enable Input e PLL is enabled. is signal enables the PLL.
pllena is always exported.
pfde
na
input PFD Enable Input e phase-frequency
detector is enabled.
is signal enables the phase-frequency
detector in the PLL, allowing it to lock on to
changes in the clock reference.
lock
ed
output PLL Locked Output — is signal is asserted when the PLL is locked
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. e 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.
e SOPC Builder automatically connects the PLL's reference clock input to the rst 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.
35-4 Instantiating the PLL Core UG-01085
2016.12.19
Altera Corporation PLL Cores
Send Feedback
Hardware Simulation Considerations
e HDL les generated by SOPC Builder for the PLL cores are suitable for both synthesis and simulation.
e PLL cores support the standard SOPC Builder simulation ow, so there are no special considerations
for hardware simulation.
Register Denitions and Bit List
Device drivers can control and communicate with the cores through two memory-mapped registers,
status and control. e width of these registers are 32 bits in the Avalon ALTPLL core but only 16 bits
in the PLL core.
In the PLL core, the status and control bits shown in the PLL Cores Register map below are present
only if they have been created in the ALTPLL MegaWizard Plug-In Manager, and set to Register on the
Interface page in the PLL wizard. ese registers are always created in the Avalon ALTPLL core.
Table 35-2: PLL Cores Register Map
Ose
t
Register
Name R/W
Bit Description
31/
15
(2)
30 29 ... 9 8 7 6 5 4 3 2 1 0
0status R/O (1) phasedone lock
ed
1control R/
W
(1) pfdena ares
et
2 phase
recong
control
R/
W
phase (1) counter_number
3 — — Undened
Table 35-2 :
1. Reserved. Read values are undened. When writing, set reserved bits to zero.
2. e registers are 32-bit wide in the Avalon ALTPLL core and 16-bit wide in the PLL core.
Status Register
Embedded soware can access the PLL status via the status register. Writing to status has no eect.
Table 35-3: Status Register Bits
Bit Number Bit Name Value after
reset
Description
0locked
(2)
1 Connects to the locked signal on the ALTPLL megafunction.
e locked bit is high when valid clocks are present on the
output of the PLL.
UG-01085
2016.12.19 Hardware Simulation Considerations 35-5
PLL Cores Altera Corporation
Send Feedback
Bit Number Bit Name Value after
reset
Description
1phasedone
(2)
0 Connects to the phasedone signal on the ALTPLL megafunc‐
tion. e phasedone output of the ALTPLL is synchronized to
the system clock.
2:15/31
(1)
— — Reserved. Read values are undened.
Table 35-3 :
1. e status register is 32-bit wide in the Avalon ALTPLL core and 16-bit wide in the PLL core.
2. Both the locked and phasedone outputs from the Avalon ALTPLL component are available as
conduits and reect the non-synchronized outputs from the ALTPLL.
Control Register
Embedded soware can control the PLL via the control register. Soware can also read back the status of
control bits.
Table 35-4: Control Register Bits
Bit Number Bit Name Value after
reset
Description
0areset 0 Connects to the areset signal on the ALTPLL megafunction.
Writing a 1 to this bit initiates a PLL reset.
1pfdena 1 Connects to the pfdena signal on the ALTPLL megafunction.
Writing a 0 to this bit disables the phase frequency detection.
2:15/31
(1)
— — Reserved. Read values are undened. When writing, set reserved
bits to zero.
Table 35-4 :
1. e controlregister is 32-bit wide in the Avalon ALTPLL core and 16-bit wide in the PLL core.
Phase Recong Control Register
Embedded soware can control the dynamic phase reconguration via the phase reconfig control
register.
Table 35-5: Phase Recong Control Register Bits
Bit
Number
Bit Name Value after
reset
Description
0:8 counter_number — A binary 9-bit representation of the counter that needs to be
recongured. Refer to the Counter_Number Bits and Selection
table for the counter selection.
9:29 — — Reserved. Read values are undened. When writing, set
reserved bits to zero.
35-6 Control Register UG-01085
2016.12.19
Altera Corporation PLL Cores
Send Feedback
Bit
Number
Bit Name Value after
reset
Description
30:31 phase (1) — 01: Step up phase of counter_number
10: Step down phase of counter_number
00 and 11: No operation
Table 35-5 :
1. Phase step up or down when set to 1 (only applicable to the Avalon ALTPLL core).
e table below lists the counter number and selection. For example, 100 000 000 selects counter C0 and
100 000 001 selects counter C1.
Table 35-6: Counter_Number Bits and Selection
Counter_Number [0:8] Counter Selection
0 0000 0000 All output counters
0 0000 0001 M counter
> 0 0000 0001 Undened
1 0000 0000 C0
1 0000 0001 C1
1 0000 0010 C2
... ...
1 0000 1000 C8
1 0000 1001 C9
> 1 0000 1001 Undened
Document Revision History
Table 35-7: PLL 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 2009 v9.1.0 Revised descriptions of register elds and bits.
March 2009 v9.0.0 Added information on the new Avalon ALTPLL core.
UG-01085
2016.12.19 Document Revision History 35-7
PLL Cores Altera Corporation
Send Feedback
Date Version Changes
November 2008 v8.1.0 Changed to 8-1/2 x 11 page size. No change to content.
May 2008 v8.0.0 No change from previous release.
35-8 Document Revision History UG-01085
2016.12.19
Altera Corporation PLL Cores
Send Feedback
Altera MSI to GIC Generator Core 36
2016.12.19
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-specied data value to a system-specied message address (using a PCI
DWORD memory write transaction). System soware initializes the message address and message data
during device conguration, allocating one or more system-specied data and system-specied 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-specied message data value to the system-specied
message address of a MSI TLP received. is 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-
specied message address in order to acknowledge the interrupt request and service the MSI interrupt.
is polling mechanism may overwhelm the processor cycles and it is not ecient.
e 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.
Background
e 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.
Feature Description
e Altera MSI-to-GIC Generator provides storage for the MSI system-specied data value. It also
generates level interrupt output when there is an unread entry. e following gure illustrates the
connection of the MSI-to-GIC Generator module in a PCIe subsystem.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 36-1: MSI-to-GIC Generator in PCIe RP system
is module is connected to RP_Master of PCIe RootPort HIP issuing memory map write transaction
upon MSI TLP arrival. System-specied data value carried by the MSI TLP is written into the module
storage. e 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.
ere 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. e Interrupt Mask register provides exibility for the host processor to
disregard the incoming interrupt.
e base address assigned for Altera MSI-to-GIC Generator module in the subsystem should cover the
system-specied message address of MSI capable functions during device conguration. Multiple Altera
MSI-to-GIC Generator modules could be instantiated in a subsystem to cover dierent system-specied
message addresses.
Avalon-MM Slave interfaces of this module honors xed latency of access to ensure the connected master
(in this case, the RP_Master) can successfully write into the module without back pressure. is avoids the
PCIe upstream trac 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-specied message address receives more than one MSI message data
before the host processor is able to service the MSI request. e Component is congurable to have each
data word address to receive up to 32 entries, before any data value is retrieved. When you reach the
maximum data value entry of 32, subsequent write transactions are dropped and logged. is ensures
every write transaction to the storage has no back pressure which may lead to system lock up.
Interrupt Servicing Process
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 red. e host processor that
36-2 Interrupt Servicing Process UG-01085
2016.12.19
Altera Corporation Altera MSI to GIC Generator Core
Send Feedback
receives this interrupt output is required to service the MSI request, as indicated in the following
procedure:
1. e host processor reads the Status Register to recognize which data word location of its storage is
causing the interrupt.
2. e host processor reads the ring data word location for its system-specied 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. e host processor services either the MSI sender or the function who calls for the MSI.
4. Upon completing the interrupt service for the rst 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. e host processor may run through the Status Register and service each ring Status bit in any order.
Registers of Component
e following table illustrates the Altera MSI-to-GIC Generator registers map as observed by the host
processor from its Avalon-MM CSR interfaces. e bit size of each register is numbered according to the
congured number of data word storage for MSI message of the component. e maximum width of each
register should be 32 bits because the congurable value range is from 1 to 32.
Table 36-1: CRA registers map
Word Address Oset Register/ Queue Name Attribute
0x0 Status register R
0x1 Error register RW
Note: Write '1' to clear
0x2 Interrupt Mask register RW
Status Register
e status register contains individual bits representing each of the data words location entry status. An
unread entry sets the Status bit. e Status bit is cleared automatically when entry is empty. e value of
the register is defaulted to ‘0’ upon reset.
e following table illustrates the Status register eld.
Table 36-2: Status Register elds
Field Name Bit Location
Status bit for message data word location [31:1] 31:1
Status bit for message data word location [0] 0
Error Register
UG-01085
2016.12.19 Registers of Component 36-3
Altera MSI to GIC Generator Core Altera Corporation
Send Feedback
e 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. e Error bit
indicates the possibility of the MSI TLP targeting the associated system-specied address. is condition
should not happen as each MSI capable function is only allowed to send up to 32 MSI even with multiple
vector supported.
e 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’.
e following table illustrates the Pending register eld.
Table 36-3: Error Register elds
Field Name Bit Location
Error bit for message data word location [31:1] 31:1
Error bit for message data word location [0] 0
Interrupt Mask Register
e 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’.
e following table illustrates the Interrupt Mask register eld.
Table 36-4: Interrupt Mask Register elds
Field Name Bit Location
Masking bit for Status [31:1] 31:1
Masking bit for Status [0] 0
Unsupported Feature
e message data entry Avalon-MM Slave represents the system-specied address for MSI function. e
oset seen by MSI function should be similar to the oset 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 oset address (system-specied 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.
36-4 Interrupt Mask Register UG-01085
2016.12.19
Altera Corporation Altera MSI to GIC Generator Core
Send Feedback
Document Revision History
Table 36-5: Altera MSI to GIC Generator Core Revision History
Date Version Changes
July 2014 2014.07.24 Initial release
UG-01085
2016.12.19 Document Revision History 36-5
Altera MSI to GIC Generator Core Altera Corporation
Send Feedback
Altera Interrupt Latency Counter Core 37
2016.12.19
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 rmware that is currently being executed. e
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.
Altera’s® 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. e data from the ILC can also be
used to help the general rmware debugging exercise.
e ILC sits as a parallel to any interrupt receiver that will consume and perform an interrupt service
routine. e following gure shows the orientation of a ILC in a system design.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 37-1: Usage model of Interrupt Latency Calculator
Processor Interrupt Latency
Calculator
Peripheral
Data
Master
IRQ
Receiver
CSR
Slave
IRQ
Receiver
IRQ
Sender
Feature Description
e ILC is made up of three sub functional blocks. e top level interface is Avalon Memory Mapped
(Avalon-MM) protocol compliant. e interrupt detector block will be activated by the rising edge of the
interrupt signal or pulse, determined by a parameter during component generation. e 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 aecting previous stored latency data register value. e latency data register is
updated aer the counter is stopped.
Each counter can be congured to host up to 32 identical counters to monitor separate IRQ channels.
Each counter only observes one interrupt input. e 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.
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.
Avalon-MM Compliant CSR Registers
Each ILC has rows of status registers each being 32 bits in length. e last four rows of CSR registers
corresponding to address 0x20 to 0x23 are xed regardless of the number of IRQ port count congured
through the Qsys GUI Stop Address 0x0 to 0x1F. e Qsys GUI Stop Address is reserved to store the
latency value which depends on the number of IRQ port congured. For example, if you congure the
37-2 Feature Description UG-01085
2016.12.19
Altera Corporation Altera Interrupt Latency Counter Core
Send Feedback
instance to have only ve counters, then only addressess 0x0 to 0x4 return a valid value when you try to
read from it. When the IP user tries to read from an invalid address, the IP returns binary ‘0’ value.”.
Table 37-1: ILC Register Mapping
Word Address Oset Register/ Queue Name Attribute
0x0 IRQ_0 Latency Data
Registers
Read access only
0x1 IRQ_1 Latency Data
Registers
Read access only
... ... ...
0x1F IRQ_31 Latency Data
Registers
Read access only
0x20 Control Registers Read and Write access on LSB and Read only for
the remaining bits
0x21 Frequency Registers Read access only
0x22 Counter Stop Registers Read and Write access
0x23 Read data Valid Registers Read access only
0x24 IRQ Active Registers Read access only
Control Register
Table 37-2: ILC Control Register Fields
Field Name ILC Version IRQ Port Count IRQ TYPE Global Enable
Bit Location 31 8 7 2 1 0
e control registers of the Interrupt Latency Counter is divided into four elds. e 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’. e next
bit denotes the IRQ type the IP is congured 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. e next six bits
stores the number of IRQ port count congured through the Qsys GUI. Bit 8 through bit 31 stores the
revision value of the ILC instance.
Frequency Register
Table 37-3: Frequency Register
Field Name System Frequency
Bit Location 31 0
e frequency registers stores the clock frequency supplied to the IP. is 32-bit read only register holds
system frequency data in Hz. For example, a 50 MHz clock signal is represented by hexadecimal
0x2FAF080.
UG-01085
2016.12.19 Control Register 37-3
Altera Interrupt Latency Counter Core Altera Corporation
Send Feedback
Counter Stop Registers
Table 37-4: Counter Stop Registers
Field Name Counter Stop Registers
Bit Location 31 0
If the ILC is congured to support the pulse IRQ signal, then the counter stop registers are utilized by
running soware 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 aect 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.
Latency Data Registers
Table 37-5: Latency Data Registers
Field Name Latency Data Registers
Bit Location 31 0
e latency data registers holdthe latency value in terms of clock cycle from the moment the interrupt
signal is red until the IRQ signal goes low for level conguration or counter stop register being set for
pulse conguration. is is a 32-bit read only register with each address corresponding to one IRQ port.
e latency data registers can only be read three clock cycles aer the IRQ signal goes low or when the
counter stop registers are set to high in the level and pulse operating mode, respectively.
Data Valid Registers
Table 37-6: Data Valid Registers
Field Name Data Valid Registers
Bit Location 31 0
e 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
the latency data register, the corresponding bit within the data valid register is set to binary '1'. It reverts
back to binary ‘0’ aer a read operation has been consumed by the ILC.
32-bit Counter
e 32-bit positive edge triggered D-op 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
o.
37-4 Counter Stop Registers UG-01085
2016.12.19
Altera Corporation Altera Interrupt Latency Counter Core
Send Feedback
Interrupt Detector
e interrupt detector can be customized to detect either signal edges or pulse using the Qsys interface.
e 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.
e table below shows the component interface that is available on the Altera Interrupt Latency Counter
IP.
Table 37-7: Available Component Interfaces
Interface Port Description Remarks
Avalon-MM Slave (address , write,
waitrequest , writedata[31:0], read,
readdata[31:0])
Avalon-MM Slave
interface for processor to
talk to the IP.
is Avalon-MM slave interface
observes zero cycles read latency with
waitrequest signal. e waitrequest
signal defaults to binary ‘1’ if there is
no ongoing operation. If the Avalon-
MM Read or Write signal goes high,
the waitrequest signal only goes low if
the readdata_valid_register goes high.
Clock Clock input of component. Clock signal to feed the latecy counter
logics.
Reset_n Active LOW reset input/s. Support asynchronous reset assertion.
De-assertion of reset has to be
synchronized to the input clock.
IRQ IRQ signal from the
interrupt signal initiator
Interrupt assertion and deassertion is
synchronized to input clock.
Component Parameterization
e table below shows the conguration parameters available on the Altera Interrupt Latency Counter IP.
Table 37-8: Available Component Parameterizations
Parameter Name Description Default Value Allowable Range
INTERRUPT_TYPE Value 0: level
sensitive interrupt
input
Value 1: edge/pulse
interrupt input
0 0,1
UG-01085
2016.12.19 Interrupt Detector 37-5
Altera Interrupt Latency Counter Core Altera Corporation
Send Feedback
Parameter Name Description Default Value Allowable Range
CLOCK_RATE Frequency of the
clock signal that is
connected to the IP
0 0 – 2^32
IRQ_PORT_COUNT Congure number of
IRQ PORT to use
32 1 - 32
Software Access
Since the component supports two types of incoming interrupts - level and edge/pulse, the soware access
routine for supporting each of the interrupt types has slightly dierent expectations.
Routine for Level Sensitive Interrupts
e soware access routine for level sensitive interrupts is as follows:
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.
e value presented is in the amount of clock cycle associated with the clock connected to Interrupt
Latency Counter.
Routine for Edge/Pulse Sensitive Interrupts
e soware access routine for edge/pulse sensitive interrupts is as follows:
1. Upon completion of ISR, or at the end of ISR, soware needs to write binary ‘1’ to one of the 32-bit
registers of the Counter Stop Register to stop the internal counter from counting. e LSB represents
counter 0 and the MSB represents counter 31. is 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. e counter stop bit
only needs clearing when the IP is congured to accept pulse IRQ. If level IRQ is employed. e
counter stop bit is ignored.
37-6 Software Access UG-01085
2016.12.19
Altera Corporation Altera Interrupt Latency Counter Core
Send Feedback
Implementation Details
Interrupt Latency Counter Architecture
Figure 37-2: Interrupt Latency Calculator Architecture
e interrupt latency calculator operates on a single clock domain which is determined by which clock it
is receiving at the CLK interface. e interrupt detector circuit is made up of a positive-edge triggered op
which delays the IRQ signal to be XORed with the original signal. e pulse resulted from the previous
operation is then fed to an enable register where it will switch its state from logic ‘low’ to ‘high’. is will
trigger the counter to start its operation. Prior to this, the reset signal is assumed to be triggered through
the rmware. Once the Interrupt service routine has been completed, the IRQ signal drops to logic low.
is 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 congured 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 counter’s operation, you have to write a
Boolean ‘1’ to the counter stop bit. Only the rst 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.
UG-01085
2016.12.19 Implementation Details 37-7
Altera Interrupt Latency Counter Core Altera Corporation
Send Feedback
IP Caveats
ere are limitations in the Altera interrupt latency which the user needs to be aware of. is limitation
arises due to the nature of state machines which incurs a period of clock cycle for state transitions.
1. e data latency registers cannot be read before a rst IRQ is red in any of the 32 channels. is
causes the Waitrequest signal to be perpetually high which would lead to a system stall.
2. e data registers can only be read three clock cycles aer the counter registers stop counting. ese
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 aer channel 0 is halted,
then the minimum dierence you see in the registered values is 2.
4. e interrupt latency counter will not notify you if an overow occurs but the counter can count up to
very huge numbers before an overow happens. e magnitude of the delay numbers reported will
suggest that the system has hung indenitely.
Document Revision History
Table 37-9: Altera Interrupt Latency Counter Core Revision History
Date Version Changes
June 2016 2016.06.17 Updated:
•Table 37-1 Added word address oset 0x24
•Data Valid Registers on page 37-4 Updated description
•Table 37-8 Parameter name change
•IP Caveats on page 37-8 Added limitation 4
July 2014 2014.07.24 Initial Release
37-8 IP Caveats UG-01085
2016.12.19
Altera Corporation Altera Interrupt Latency Counter Core
Send Feedback
Altera GMII to RGMII Converter Core 38
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Altera GMII to RGMII converter core is an available so 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 oers 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
e following is the list of features supported by the core.
• Perform GMII/MII interface to RGMII interface conversion
• Supports tri-speed (10/100/1000 Mbps) operation
• Supports dynamic speed switching
• Supports generation time option to enable pipeline registers for the transmit and receive paths
Unsupported Features
e 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 buer. is 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
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Parameters
IP Conguration Parameter
ese parameters are congurable by user during generation time.
Parameter Legal
Values
Default
Values
Description
Transmit Pipeline
Register Depth
0 - 10 0 TX_PIPELINE_DEPTH - Number of register
stages between HPS transmit output and FPGA I/O
buer.
Receive Pipeline
Register Depth
0 - 10 0 RX_PIPELINE_DEPTH - Number of register
stages between FPGA I/O buer and HPS receive
input.
Altera GMII to RGMII Converter Core Interface
Figure 38-1: Altera GMII to RGMII Converter Core Top Level Interfaces
Altera GMII to RGMII
Converter Core
peri_clock
peri_reset
pll_25m_clock
pll_2_5m_clock
hps_gmii
phy_rgmii
Note: For more information and a detailed list of the interfaces denoted on this gure, refer to the
corresponding interface name in the following tables.
Table 38-1: peri_clock
Interface Name: peri_clock
Description: Peripheral clock interface.
Signal Width Direction Description
clk 1 Input Peripheral clock source.
38-2 Parameters UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Table 38-2: peri_reset
Interface Name: peri_reset
Description: Peripheral reset interface.
Signal Width Direction Description
rst_n 1 Input Active low peripheral
asynchronous reset source.
is signal is asynchronously
asserted and synchronously
de-asserted. e synchro‐
nous de-assertion must be
provided external to this
core.
Table 38-3: pll_25m_clock
Interface Name: pll_25m_clock
Description: 25MHz clock from FPGA PLL output.
Signal Width Direction Description
pll_25m_clk 1 Input 25MHz input clock from
FPGA PLL.
Table 38-4: pll_2_5m_clock
Interface Name: pll_2_5m_clock
Description: 2.5MHz clock from FPGA PLL output.
Signal Width Direction Description
pll_2_5m_clk 1 Input 2.5MHz input clock from
FPGA PLL.
Table 38-5: hps_gmii
Interface Name: hps_gmii
Description: GMII/MII interface facing Altera HPS Emac Interface Splitter core
Signal Width Direction Description
mac_tx_clk_o 1 Input GMII/MII transmit clock
from HPS
mac_tx_clk_i 1 Output GMII/MII transmit clock to
HPS
mac_rx_clk 1 Output GMII/MII receive clock to
HPS
UG-01085
2016.12.19 Altera GMII to RGMII Converter Core Interface 38-3
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
Interface Name: hps_gmii
Description: GMII/MII interface facing Altera HPS Emac Interface Splitter core
Signal Width Direction Description
mac_rst_tx_n 1 Input GMII/MII transmit reset
source from HPS. Active low
reset
mac_rst_rx_n 1 Input GMII/MII receive reset
source from HPS. Active low
reset
mac_txd 8 Input GMII/MII transmit data
from HPS
mac_txen 1 Input GMII/MII transmit enable
from HPS
mac_txer 1 Input GMII/MII transmit error
from HPS
mac_rxdv 1 Output GMII/MII receive data valid
to HPS
mac_rxer 1 Output GMII/MII receive data error
to HPS
mac_rxd 8 Output GMII/MII receive data to
HPS
mac_col 1 Output GMII/MII collision detect to
HPS
mac_crs 1 Output GMII/MII carrier sense to
HPS
mac_speed 2 Input MAC speed indication from
HPS
Table 38-6: phy_rgmii
Interface Name: phy_rgmii
Description: RGMII interface facing PHY device.
Signal Width Direction Description
rgmii_tx_clk 1 Output RGMII transmit clock to
PHY
rgmii_rx_clk 1 In RGMII receive clock from
PHY
rgmii_txd 4 Output RGMII transmit data to PHY
rgmii_tx_ctl 1 Output RGMII transmit control to
PHY
38-4 Altera GMII to RGMII Converter Core Interface UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Interface Name: phy_rgmii
Description: RGMII interface facing PHY device.
Signal Width Direction Description
rgmii_rxd 4 Input RGMII receive data from
PHY
rgmii_rx_ctl 1 Input RGMII receive control from
PHY
Functional Description
Figure 38-2: System Level Block Diagram
Altera HPS Emac
Interface Splitter
core
peri_reset
avalon_slave
emac
ptp
mdio
emac_tx_clk_in
emac_rx_clk_in
emac_gtx_clk
emac_tx_reset
emac_rx_reset
peri_clock
HPS core
AXI/Avalon
Bridge Altera GMII to
RGMII Converter
core
H2F AXI
peri_reset
hps_gmii
pll_25m_clock
peri_clock
RGMII
PHY
phy_rgmii
FPGA
MAC Speed
CSR pll_2_5m_clock
EMAC
Interfaces
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. is 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 dierences 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
UG-01085
2016.12.19 Functional Description 38-5
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
Figure 38-3: Data Path Diagram
mac_txd[7:0],
mac _txen,
mac __txer
mac_tx_clk_o
mac_rst_tx_n
RX Path
rxd_i[7:0],
rxdv_i,
rxerr_i
mac_rst_rx_n
mac_rx_clk
mac_rxd[7:0],
mac _rxdv,
mac _rxerr
Soft pipeline with
configurable deep
Soft pipeline with
configurable deep
TX Path
SDR/DDR
Converter
rgmii_txd[3:0],
rgmii_txctl
rgmii_rxd[3:0],
rgmii_rctl
txd_o[7:0],
txen _o,
txer_o
mac_col,
mac _crs
For transmit path, the GMII/MII data goes through the transmit pipeline register stage before going into
the SDR/DDR converter block. e pipeline logic can be optionally enabled or disabled by the user during
generation time.
For receive path, the GMII/MII data right aer 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.
e 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. is 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).
38-6 Clock Scheme UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Figure 38-4: Transmit Clocking Scheme
HPS
Clock
Manager
Clock Mux in EMAC
Divider and
Muxing
FPGA
To the rest of Altera
Ethernet Interface
Converter TX
Sequential Logic RGMII
PHY
clk_tx_i
GMII
MII
FPGA
PLL
25MHz
2.5MHz
rgmii_txc
phy_txclk_o
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).
Altera HPS EMAC Interface Splitter Core
e 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 dierences 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.
Parameter
System Info Parameter
e following parameter is not congurable by the user:
Parameter Description
DEVICE_FAMILY Name: DEVICE_FAMILY
Indicates the device family type of the current selected device in QSYS.
is parameter is used to determine the version of HPS (Arria V, Cyclone
V, and Arria 10 HPS) supported by the current selected device. is
information is used to enable or disable certain logic; or to terminate
certain interfaces of this core.
HDL Parameter
UG-01085
2016.12.19 Receive 38-7
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
is parameter is not congurable 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: e 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: e MAC Speed CSR block is instantiated in this core. In this case, the
Mac Speed information is determined by the control register dened in
this core.
Altera HPS EMAC Interface Splitter Core Interface
Figure 38-5: Altera HPS EMAC Interface Splitter Core Top Level Interfaces
Altera HPS Emac
Interface Splitter
Core
peri_reset
avalon_slave
emac
ptp
mdio
emac_tx_clk_in
emac_rx_clk_in
emac_gtx_clk
emac_tx_reset
emac_rx_reset
peri_clock
hps_gmii
MAC Speed
CSR
Table 38-7: peri_clock
Interface Name: peri_clock
Description: Peripheral clock interface. This interface exists only when the selected device is Arria V or Cyclone V.
Signal Width Direction Description
clk 1 Input Peripheral clock source used for
Avalon-MM slave interface.
38-8 Altera HPS EMAC Interface Splitter Core Interface UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Table 38-8: peri_reset
Interface Name: peri_reset
Description: Peripheral reset interface. This interface exists only when the selected device is Arria V or Cyclone V.
Signal Width Direction Description
rst_n 1 Input Active low peripheral asynchro‐
nous reset source used to reset
the Avalon-MM slave interface.
is signal is asynchronously
asserted and synchronously de-
asserted. e synchronous de-
assertion must be provided
external to this core.
Table 38-9: avalon_slave
Interface Name: avalon_slave
Description: This interface exists only when the selected device is Arria V or Cyclone V.
Signal Width Direction Description
addr 1 Input Avalon-MM address bus. (20)
read 1 Input Avalon-MM read control
write 1 Input Avalon-MM write control
writedata 32 Input Avalon-MM write data bus
readdata 32 Output Avalon-MM read data bus
Table 38-10: emac
Interface Name: emac
Description: Conduit interface connected to HPS EMAC interface
Signal Width Direction Description
phy_txd_o 8 Input GMII/MII transmit data from
HPS
phy_txen_o 1 Input GMII/MII transmit enable from
HPS
phy_txer_o 1 Input GMII/MII transmit error from
HPS
phy_rxdv_i 1 Output GMII/MII receive data valid to
HPS
(20) e address bus is in the unit of Word addressing.
UG-01085
2016.12.19 Altera HPS EMAC Interface Splitter Core Interface 38-9
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
Interface Name: emac
Description: Conduit interface connected to HPS EMAC interface
Signal Width Direction Description
phy_rxer_i 1 Output GMII/MII receive data error to
HPS
phy_rxd_i 8 Output GMII/MII receive data to HPS
phy_col_i 1 Output GMII/MII collision detect to
HPS
phy_crs_i 1 Output GMII/MII carrier sense to HPS
phy_mac_speed_o 2 Input MAC speed indication from HPS
(21)
mdo_o 1 Input MDIO data output from HPS
mdo_o_e 1 Input MDIO data output enable from
HPS
mdi_i 1 Output MDIO data input to HPS
ptp_pps_o 1 Input PTP pulse per second from HPS
ptp_aux_ts_trig_i 1 Output PTP auxiliary timestamp trigger
to HPS
Table 38-11: emac_gtx_clk
Interface Name: emac_gtx_clk
Description: GMII/MII transmit clock from HPS
Signal Width Direction Description
phy_txclk_o 1 Input GMII/MII transmit clock from
HPS
Table 38-12: emac_tx_reset
Interface Name: emac_tx_reset
Description: GMII/MII transmit reset source synchronous to phy_txclk_o from HPS
Signal Width Direction Description
rst_tx_n_o 1 Input GMII/MII transmit reset source
from HPS. Active low reset.
(21) ese bits exist only when the selected device is Arria 10.
38-10 Altera HPS EMAC Interface Splitter Core Interface UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Table 38-13: emac_rx_reset
Interface Name: emac_rx_reset
Description: GMII/MII receive reset source synchronous to clk_rx_i from HPS
Signal Width Direction Description
rst_rx_n_o 1 Input GMII/MII receive reset source
from HPS. Active low reset.
Table 38-14: emac_rx_clk_in
Interface Name: emac_rx_clk_in
Description: GMII/MII receive clock to HPS
Signal Width Direction Description
clk_rx_i 1 Output GMII/MII receive clock to HPS
Table 38-15: emac_tx_clk_in
Interface Name: emac_tx_clk_in
Description: GMII/MII transmit clock to HPS
Signal Width Direction Description
clk_tx_i 1 Output GMII/MII transmit clock to HPS
Table 38-16: hps_gmii
Interface Name: hps_gmii
Description: GMII/MII interface facing FPGA fabric
Signal Width Direction Description
mac_tx_clk_o 1 Output GMII/MII transmit clock from
HPS
mac_tx_clk_i 1 Input GMII/MII transmit clock to HPS
mac_rx_clk 1 Input GMII/MII receive clock to HPS
mac_rst_tx_n 1 Output GMII/MII transmit reset source
from HPS
mac_rst_rx_n 1 Output GMII/MII receive reset source
from HPS
mac_txd 8 Output GMII/MII transmit data from
HPS
mac_txen 1 Output GMII/MII transmit enable from
HPS
UG-01085
2016.12.19 Altera HPS EMAC Interface Splitter Core Interface 38-11
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
Interface Name: hps_gmii
Description: GMII/MII interface facing FPGA fabric
Signal Width Direction Description
mac_txer 1 Output GMII/MII transmit error from
HPS
mac_rxdv 1 Input GMII/MII receive data valid to
HPS
mac_rxer 1 Input GMII/MII receive data error to
HPS
mac_rxd 8 Input GMII/MII receive data to HPS
mac_col 1 Input GMII/MII collision detect to
HPS
mac_crs 1 Input GMII/MII carrier sense to HPS
mac_speed 2 Output MAC speed indication from HPS
Table 38-17: ptp
Interface Name: ptp
Description: PTP interface facing FPGA fabric
Signal Width Direction Description
ptp_pps_out 1 Output PTP pulse per second to FPGA
so logic
ptp_aux_ts_trig_in 1 Input PTP auxiliary timestamp trigger
from FPGA so logic
ptp_tstmp_data_out 1 Output PTP timestamp data from HPS
to FPGA so logic
ptp_tstmp_en_out 1 Output PTP timestamp enable from HPS
to FPGA so logic
Table 38-18: mdio
Interface Name: mdio
Description: MDIO interface facing PHY device
Signal Width Direction Description
mdo_out 1 Output MDIO data output to FPGA
bidirectional I/O buer
mdo_out_en 1 Output MDIO data output enable to
FPGA bidirectional I/O buer
38-12 Altera HPS EMAC Interface Splitter Core Interface UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Interface Name: mdio
Description: MDIO interface facing PHY device
Signal Width Direction Description
mdi_in 1 Input MDIO data input from FPGA
bidirectional I/O buer
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
Register Memory Map
is register block exists only when the selected device is Arria V or Cyclone V. Each address oset
represents one word of memory address space.
Name Address Oset Width Attribute Description
CTRL 0x0 2 R/W Control Register
Register Description
Control Register
Table 38-19: Control Registers
Bit Fields Access Default Value Description
31:2 Reserved N/A 0x0 Reserved
UG-01085
2016.12.19 Register 38-13
Altera GMII to RGMII Converter Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
1:0 MAC_SPEED R/W 0x0 is eld indicates the
speed mode used by
HPS EMAC and PHY
device. HPS soware is
required to write to this
eld once it has set the
MAC Speed in the HPS
EMAC register space
aer the auto-negotia‐
tion process.
0x0-0x1: 1000 Mbps
(GMII)
0x2: 10 Mbps (MII)
0x3: 100 Mbps (MII)
Avalon-MM Slave Interface
e 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
Document Revision History
Table 38-20: Altera GMII to RGMII Converter Core Revision History
Date Version Changes
November 2015 2015.11.06 • Updated "Altera HPS EMAC Interface Splitter Core Interface" PTP
table
• Updated "Unsupported Features"
July 2014 2014.07.24 Initial release
38-14 Avalon-MM Slave Interface UG-01085
2016.12.19
Altera Corporation Altera GMII to RGMII Converter Core
Send Feedback
Altera Generic Quad SPI Controller Core 39
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Generic Quad SPI controller wraps around the Altera ASMI PARALLEL IP, and a so ASMI block.
e ash interface is exported to the top wrapper.
Functional Description
e 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
Altera Generic Quad SPI Controller
Altera ASMI
Parallel IP Core
ASMI Soft Block
Altera EPCQ Controller IP
Serial
Flash
Memory
clk
reset_n
avl_csr
avl_mem
IRQ
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Parameters
Figure 39-2: Qsys Parameters
Conguration Device Types
e following device types can be selected through the conguration device type drop down menu. Here
you can specify the EPCQ or Micron ash type you want to use.
• EPCQ16
• EPCQ32
• EPCQ64
• EPCQ128
• EPCQ256
• EPCQ512
• EPCQL512
• EPCQL1024
• N25Q016A13ESF40
• N25Q032A13ESF40
• N25Q064A13ESF40
• N25Q128A13ESF40
• N25Q256A13ESF40
• N25Q256A13ESF40 (low voltage)
• MT25QL512ABA
• N25Q512A11G1240 (low voltage)
• N25Q00AA11G1240 (low voltage)
• N25Q512A83GSF40F
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 ash chips from the parameters menu.
Note: is feature is only for Arria 10 devices.
Interface Signals
39-2 Parameters UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
Table 39-1: Quad SPI 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. e
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_
waitrequest
1 Output Avalon-MM waitrequest control
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_
valid
1 Output Avalon-MM read data 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)
UG-01085
2016.12.19 Interface Signals 39-3
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
Signal Width Direction Description
avl_mem_addr * Input Avalon-MM address bus. e
address bus is in word
addressing. e width of the
address will depends on the ash
memory density minus 2.
If you are using Arria 10, then
the MSB bits will be used for
chip select information. User is
allowed to select the number of
chip select needed in the GUI.
If user selects 1 chip select, there
will be no extra bit added to avl_
mem_addr.
If user select 2 chip selects, there
will be one extra bit added to
avl_mem_addr.
Chip 1 – b’0
Chip 2 – b’1
If user select 3 chip selects, there
will be two extra bit added to
avl_mem_addr.
Chip 1 – b’00
Chip 2 – b’01
Chip 3 – b’10
avl_mem_read 1 Input Avalon-MM read control to
memory
avl_mem_write 1 Input Avalon-MM write control to
memory
avl_mem_wrdata 32 Input Avalon-MM write data bus to
memory
avl_mem_
byteenble
4 Input Avalon-MM write data enable bit
to memory. During bursting
mode, byteenable bus bit will be
all high always, 4’b1111.
avl_mem_
burstcount
7 Input Avalon-MM burst count for
memory. Value range from 1 to
64
avl_mem_
waitrequest
1 Output Avalon-MM waitrequest control
from memory
avl_mem_rddata 32 Output Avalon-MM read data bus from
memory
39-4 Interface Signals UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
Signal Width Direction Description
avl_mem_rddata_
valid
1 Output Avalon-MM read data valid
which indicates that memory
read data is available
Conduit Interface
flash_dataout 4 Input/Output Input/output port to feed data
from ash device
flash_dclk_out 1 Output Provides clock signal to the ash
device
flash_ncs 1/3 Output Provides the ncs signal to the
ash device
Registers
Register Memory Map
Each address oset in the table below represents 1 word of memory address space.
Table 39-2: Register Memory Map
Register Oset Width Access Description
FLASH_RD_STATUS 0x0 8 R Perform read operation on ash
device status register and store the
read back data.
FLASH_RD_SID 0x1 8 R Perform read operation to extract
ash device silicon ID and store the
read back data. Only support in
EPCS16 and EPCS64 ash devices.
FLASH_RD_RDID 0x2 8 R Perform read operation to extract
ash device memory capacity and
store the read back data.
FLASH_MEM_OP 0x3 24 W To protect and erase memory
FLASH_ISR 0x4 2 RW Interrupt status register
FLASH_IMR 0x5 2 RW To mask of interrupt status register
FLASH_CHIP_SELECT 0x6 3 W Chip select values:
•B’000/b’001 -chip 1
•B'010 - chip 2
•B'100 - chip 3
UG-01085
2016.12.19 Registers 39-5
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
Register Descriptions
FLASH_RD_STATUS
Table 39-3: FLASH_RD_STATUS
Bit Fields
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
Table 39-4: FLASH_RD_STATUS Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_status is 8 bits data contain the information from
read status register operation. It keeps the
information from the ash status register.
R 0x0
FLASH_RD_SID
Table 39-5: FLASH_RD_SID
Bit Fields
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
Table 39-6: FLASH_RD_SID Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_sid is 8 bits data contain the information from
read silicon ID operation.
R 0x0
39-6 Register Descriptions UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
FLASH_RD_RDID
Table 39-7: FLASH_RD_RDID
Bit Fields
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
Table 39-8: FLASH_RD_RDID Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_rdid is 8 bits data contain the information from
read memory capacity operation. It keeps the
information of the ash manufacturing ID.
R 0x0
FLASH_MEM_OP
Table 39-9: FLASH_MEM_OP
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved Sector value
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sector value Reserved Memory protect/erase
operation
Table 39-10: FLASH_MEM_OP Fields
Bit Name Description Access Default Value
31:18 Reserved Reserved - 0x0
23:8 Sector value Set the sector value of the ash device so that a
particular memory sector can be erasing or
protecting from erase or written. Please refer
to the "Valid Sector Combination for Sector
Protect and Sector Erase Command" section
for more detail.
W 0x0
7:2 Reserved Reserved - 0x0
UG-01085
2016.12.19 FLASH_RD_RDID 39-7
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
Bit Name Description Access Default Value
1:0 Memory protect/erase
operation •2’b11 – Sector protect:
Active-high port that executes the sector
protect operation. If asserted, the IP takes
the value of FLASH_MEM_OP[23:8] and
writes to the FLASH status register. e
status register contains the block protection
bits that represent the memory sector to be
protected from write or erase.
•2’b10 – Sector erase:
Active-high port that executes the sector
erase operation. If asserted, the IP starts
erasing the memory sector on the ash
device based on FLASH_MEM _OP[23:8]
value.
•2’b01 – Bulk erase
Active-high port that executes the bulk
erase operation. If asserted, the IP
performs a full-erase operation that sets all
memory bits of the ash device to ‘1’, which
includes the general purpose memory of
the ash device. (Bulk erase is not
supported in stack-die such as EPCQ512-L
and EPCQ1024-L)
•2’b00 – N/A
W0x0
Related Information
Valid Sector Combination for Sector Protect and Sector Erase Command on page 39-10
FLASH_ISR
Table 39-11: FLASH_ISR
Bit Fields
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 Illegal
write
Illegal erase
Table 39-12: FLASH_ISR Fields
Bit Name Description Access Default Value
31:2 Reserved Reserved - 0x0
39-8 FLASH_ISR UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
Bit Name Description Access Default Value
1 Illegal write Indicates that a write instruction is targeting a
protected sector on the ash memory. is bit
is set to indicate that the IP has cancelled a
write instruction.
RW 1C 0x0
0 Illegal erase Indicates that an erase instruction has been set
to a protected sector on the ash memory.
is bit is set to indicate that the IP has
cancelled the erase instruction.
RW 1C 0x0
FLASH_IMR
Table 39-13: FLASH_IMR
Bit Fields
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_
illegal_
write
M_illegal_
erase
Table 39-14: FLASH_IMR Fields
Bit Name Description Access Default Value
31:2 Reserved Reserved - 0x0
1 M_illegal_write Mask bit for illegal write interrupt
• 0: e corresponding interrupt is disabled
• 1: e corresponding interrupt is enabled
RW 0x0
0 M_illegal_erase Mask bit for illegal erase interrupt
• 0: e corresponding interrupt is disabled
• 1: e corresponding interrupt is enabled
RW 0x0
FLASH_CHIP_SELECT
Table 39-15: FLASH_CHIP_SELECT
Bit Fields
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
UG-01085
2016.12.19 FLASH_IMR 39-9
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
Bit Fields
Reserved Chip_
select
bit 3
Chip_
select
bit 2
Chip_select
bit 1
Table 39-16: FLASH_CHIP_SELECT Fields
Bit Name Description Access Default Value
31:3 Reserved Reserved - 0x0
2 Chip_select bit 3 In order to select ash chip 3, issue 1 to this bit
while the rest of the bit to 0.
W 0x0
1 Chip_select bit 2 In order to select ash chip 2, issue 1 to this bit
while the rest of the bit to 0.
W 0x0
0 Chip_select bit 1 In order to select ash chip 1, issue 1 or 0 to
this bit while the rest of the bit to 0.
W 0x0
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] .
ere are only 5 bits needed to provide the sector combination value. Bit 13 to bit 23 are reserved and
should be set to zero.
Table 39-17: FLASH_MEM_OP bits for Sector Value
23 ... ... 13 12 11 10 9 8
Reserved TB BP3 BP2 BP1 BP0
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 ash 256, you will need to assign ’b0000 0000 0111 1111 to FLASH_MEM_OP[23:8] .
Table 39-18: Number of sectors for dierent Flash Devices
EPCQ16 EPCQ32 EPCQ64 EPCQ128 EPCQ256 EPCQ512 EPCQ1024
Valid
sector
range
0 to 31 0 to 63 0 to 127 0 to 255 0 to 511 0 to 1023 0 to 2047
39-10 Valid Sector Combination for Sector Protect and Sector Erase Command UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
Nios II Tools Support
Booting Nios II from Flash
Booting the Nios II from an ash will use a ow similar to Compact Flash Interface (CFI). e boot copier
used will be the same one used for CFI ash.
e boot copier will be located in ash. is has a potential performance impact on the bootcopying
process, which can be mitigated by using a ash cache.
ere are two main scenarios when booting from ash:
• Executing in place
In this scenario, boot copier will not be required. NIOS II will directly execute customer code which
located in ash.
• Boot copying the code to volatile memory
In this scenario, boot copier is required. NIOS II will run the boot copier code where the boot copier
will copy customer code to volatile memory. is is normally used when customer concern about their
code run time performance.
Flash Memory Map and Setting Nios II Reset Vector when Using a Boot Copier
e gure below shows what the ash memory map will look like when using a boot copier. is memory
map assumes a FPGA image is stored at the start.
Figure 39-3: EPCQ Flash Layout When Using Boot Copier
Customer Data (*.hex)
FPGA Image (*.sof)
0x00000000
0x0000E400
Boot Copier
Application Code
0x01E0E400
UG-01085
2016.12.19 Nios II Tools Support 39-11
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
At the start of the memory map is the FPGA image, followed by the boot copier, the application and then
customer data. e size of the FPGA image is unknown and the exact size can only be known aer the
Quartus compile. However, the Nios II Reset Vector must be set in Qsys and must point to right aer the
FPGA image (i.e. the start of the boot copier).
e 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 aer the FPGA image(s).
Boot Copier File
e boot copier that will be used is the CFI boot copier, also known as memcpy-based boot copier. We will
provide the boot copier in one or more of the following formats: Intel HEX, Quartus HEX or SREC.
When Nios II SBT will Append a Boot Copier
e Nios II SBT tools know whether to append a boot copier based on the .text linker section location. If
the .text linker section is located in a dierent memory than where the reset vector points, it indicates a
code copy is required. At this scenario a boot copier is required. You can use the existing logic to generate
a programming le with or without a boot copier depending on the scenario.
Creating HEX Programming File
e Nios II Soware Build Tools (SBT) application Makele “make mem_init_generate” target is
responsible for generating memory initialization les. is includes generating programming les (SREC,
HEX) used for ashing a ash memory and les for initializing memory (DAT, HEX) in simulation.
In boot scenario 1 (Executing in place), “make mem_init_generate” should generate a HEX le containing
ELF loadable sections
In boot scenario 2 (Boot copying the code to volatile memory), “make mem_init_generate” should
generate a HEX le containing both the boot copier and ELF payload. “make mem_init_generate” is
callable from SBT.
Programming Flash
Programming the ash is done by using quartus_cpf to combine a compiled FPGA image (SOF) with an
application image (HEX le generated by Nios II SBT). e result of this combination is a (POF) which
can be programmed to the ash using the Quartus Prime Programmer.
In the Quartus Prime soware, "Convert Programming File tool" (quartus_cpf) can be called by selecting
File >> Convert Programming Files.
Custom Boot Copiers
Custom boot copiers can be used. “make mem_init_generate” calls conversion tools under the hood for
creating programming les from compiled ELFs. ese tools have a boot option to specify a custom boot
copier. A user will need to call these underlying conversion tools to generate a programming le with a
custom boot copier.
Executing in Place
Executing in place shouldn’t be any dierent than executing in place with an On-chip RAM. As long as
both the Nios II reset and exception vectors point to the ash memory, execution will happen in place.
e 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 ash memory.
39-12 Boot Copier File UG-01085
2016.12.19
Altera Corporation Altera Generic Quad SPI Controller Core
Send Feedback
Nios II HAL Driver
A Nios II HAL driver will be developed similar to the driver’s currently available for CFI
(altera_avalon_c_ash) and EPCS (altera_avalon_epcs_ash_controller).
Nios II HAL supports a number of generic device model classes including one for device ashes.
Developing against these generic classes gives a consistent interface for driver functions so that the HAL
can access the driver functions uniformly.
Please refer to the Flash Device Drivers section in the Developing Device Drivers for the Hardware Abstrac‐
tion Layer for more information.
Related Information
Developing Device Drivers for the Hardware Abstraction Layer
Document Revision History
Table 39-19: Altera Generic Quad SPI Controller Core Revision History
Date Version Changes
June 2015 2015.06.12 Initial release.
UG-01085
2016.12.19 Nios II HAL Driver 39-13
Altera Generic Quad SPI Controller Core Altera Corporation
Send Feedback
Altera Serial Flash Controller Core 40
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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.
Functional Description
e core supports the following devices:
• Arria V
• Arria 10
• Cyclone V
• MAX 10
• Stratix V
Figure 40-1: Altera Serial Flash Controller Block Diagram
Altera Serial Flash Controller
Altera ASMI
Parallel IP Core
Altera EPCQ Controller IP
clk
reset_n
avl_csr
avl_mem
IRQ
Serial
Flash
Memory
ASMI Hard Block
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Parameters
Figure 40-2: Qsys Parameters
Conguration Device Types
e following device types can be selected through the conguration device type drop down menu. Here
you can specify the EPCQ or Micron ash type you want to use.
• EPCS16
• EPCS64
• EPCS128
• EPCQ16
• EPCQ32
• EPCQ64
• EPCQ128
• EPCQ256
• EPCQ512
• 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 ash chips from the parameters menu.
Note: is feature is only for Arria 10 devices.
Interface Signals
40-2 Parameters UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
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. e
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_
waitrequest
1 Output Avalon-MM waitrequest control
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_
valid
1 Output Avalon-MM read data 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)
UG-01085
2016.12.19 Interface Signals 40-3
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
Signal Width Direction Description
avl_mem_addr * Input Avalon-MM address bus. e
address bus is in word
addressing. e width of the
address will depends on the ash
memory density minus 2.
If you are using Arria 10, then
the MSB bits will be used for
chip select information. User is
allowed to select the number of
chip select needed in the GUI.
If user selects 1 chip select, there
will be no extra bit added to avl_
mem_addr.
If user select 2 chip selects, there
will be one extra bit added to
avl_mem_addr.
Chip 1 – b’0
Chip 2 – b’1
If user select 3 chip selects, there
will be two extra bit added to
avl_mem_addr.
Chip 1 – b’00
Chip 2 – b’01
Chip 3 – b’10
avl_mem_read 1 Input Avalon-MM read control to
memory
avl_mem_write 1 Input Avalon-MM write control to
memory
avl_mem_wrdata 32 Input Avalon-MM write data bus to
memory
avl_mem_
byteenble
4 Input Avalon-MM write data enable bit
to memory. During bursting
mode, byteenable bus bit will be
all high always, 4’b1111.
avl_mem_
burstcount
7 Input Avalon-MM burst count for
memory. Value range from 1 to
64
avl_mem_
waitrequest
1 Output Avalon-MM waitrequest control
from memory
avl_mem_rddata 32 Output Avalon-MM read data bus from
memory
40-4 Interface Signals UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
Signal Width Direction Description
avl_mem_rddata_
valid
1 Output Avalon-MM read data valid
which indicates that memory
read data is available
Conduit Interface
flash_dataout 4 Input/Output Input/output port to feed data
from ash device
flash_dclk_out 1 Output Provides clock signal to the ash
device
flash_ncs 1/3 Output Provides the ncs signal to the
ash device
Registers
Register Memory Map
Each address oset in the table below represents 1 word of memory address space.
Table 40-2: Register Memory Map
Register Oset Width Access Description
FLASH_RD_STATUS 0x0 8 R Perform read operation on ash
device status register and store the
read back data.
FLASH_RD_SID 0x1 8 R Perform read operation to extract
ash device silicon ID and store the
read back data. Only support in
EPCS16 and EPCS64 ash devices.
FLASH_RD_RDID 0x2 8 R Perform read operation to extract
ash device memory capacity and
store the read back data.
FLASH_MEM_OP 0x3 24 W To protect and erase memory
FLASH_ISR 0x4 2 RW Interrupt status register
FLASH_IMR 0x5 2 RW To mask of interrupt status register
FLASH_CHIP_SELECT 0x6 3 W Chip select values:
•B’000/b’001 -chip 1
•B'010 - chip 2
•B'100 - chip 3
UG-01085
2016.12.19 Registers 40-5
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
Register Descriptions
FLASH_RD_STATUS
Table 40-3: FLASH_RD_STATUS
Bit Fields
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
Table 40-4: FLASH_RD_STATUS Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_status is 8 bits data contain the information from
read status register operation. It keeps the
information from the ash status register.
R 0x0
FLASH_RD_SID
Table 40-5: FLASH_RD_SID
Bit Fields
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
Table 40-6: FLASH_RD_SID Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_sid is 8 bits data contain the information from
read silicon ID operation.
R 0x0
40-6 Register Descriptions UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
FLASH_RD_RDID
Table 40-7: FLASH_RD_RDID
Bit Fields
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
Table 40-8: FLASH_RD_RDID Fields
Bit Name Description Access Default Value
31:8 Reserved Reserved - 0x0
7:0 Read_rdid is 8 bits data contain the information from
read memory capacity operation. It keeps the
information of the ash manufacturing ID.
R 0x0
FLASH_MEM_OP
Table 40-9: FLASH_MEM_OP
Bit Fields
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Reserved Sector value
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sector value Reserved Memory protect/erase
operation
Table 40-10: FLASH_MEM_OP Fields
Bit Name Description Access Default Value
31:24 Reserved Reserved - 0x0
23:8 Sector value Set the sector value of the ash device so that a
particular memory sector can be erasing or
protecting from erase or written. Please refer
to the "Valid Sector Combination for Sector
Protect and Sector Erase Command" section
for more detail.
W 0x0
7:2 Reserved Reserved - 0x0
UG-01085
2016.12.19 FLASH_RD_RDID 40-7
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
Bit Name Description Access Default Value
1:0 Memory protect/erase
operation •2’b11 – Sector protect:
Active-high port that executes the sector
protect operation. If asserted, the IP takes
the value of FLASH_MEM_OP[23:8] and
writes to the FLASH status register. e
status register contains the block protection
bits that represent the memory sector to be
protected from write or erase.
•2’b10 – Sector erase:
Active-high port that executes the sector
erase operation. If asserted, the IP starts
erasing the memory sector on the ash
device based on FLASH_MEM _OP[23:8]
value.
•2’b01 – Bulk erase
Active-high port that executes the bulk
erase operation. If asserted, the IP
performs a full-erase operation that sets all
memory bits of the ash device to ‘1’, which
includes the general purpose memory of
the ash device. (Bulk erase is not
supported in stack-die such as EPCQ512-L
and EPCQ1024-L)
•2’b00 – N/A
W0x0
Related Information
Valid Sector Combination for Sector Protect and Sector Erase Command on page 40-10
FLASH_ISR
Table 40-11: FLASH_ISR
Bit Fields
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 Illegal
write
Illegal erase
Table 40-12: FLASH_ISR Fields
Bit Name Description Access Default Value
31:2 Reserved Reserved - 0x0
40-8 FLASH_ISR UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
Bit Name Description Access Default Value
1 Illegal write Indicates that a write instruction is targeting a
protected sector on the ash memory. is bit
is set to indicate that the IP has cancelled a
write instruction.
RW 1C 0x0
0 Illegal erase Indicates that an erase instruction has been set
to a protected sector on the ash memory.
is bit is set to indicate that the IP has
cancelled the erase instruction.
RW 1C 0x0
FLASH_IMR
Table 40-13: FLASH_IMR
Bit Fields
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_
illegal_
write
M_illegal_
erase
Table 40-14: FLASH_IMR Fields
Bit Name Description Access Default Value
31:2 Reserved Reserved - 0x0
1 M_illegal_write Mask bit for illegal write interrupt
• 0: e corresponding interrupt is disabled
• 1: e corresponding interrupt is enabled
RW 0x0
0 M_illegal_erase Mask bit for illegal erase interrupt
• 0: e corresponding interrupt is disabled
• 1: e corresponding interrupt is enabled
RW 0x0
FLASH_CHIP_SELECT
Table 40-15: FLASH_CHIP_SELECT
Bit Fields
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
UG-01085
2016.12.19 FLASH_IMR 40-9
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
Bit Fields
Reserved Chip_
select
bit 3
Chip_
select
bit 2
Chip_select
bit 1
Table 40-16: FLASH_CHIP_SELECT Fields
Bit Name Description Access Default Value
31:3 Reserved Reserved - 0x0
2 Chip_select bit 3 In order to select ash chip 3, issue 1 to this bit
while the rest of the bit to 0.
W 0x0
1 Chip_select bit 2 In order to select ash chip 2, issue 1 to this bit
while the rest of the bit to 0.
W 0x0
0 Chip_select bit 1 In order to select ash chip 1, issue 1 or 0 to
this bit while the rest of the bit to 0.
W 0x0
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] .
ere are only 5 bits needed to provide the sector combination value. Bit 13 to bit 23 are reserved and
should be set to zero.
Table 40-17: FLASH_MEM_OP bits for Sector Value
23 ... ... 13 12 11 10 9 8
Reserved TB BP3 BP2 BP1 BP0
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 ash 256, you will need to assign ’b0000 0000 0111 1111 to FLASH_MEM_OP[23:8] .
Table 40-18: Number of sectors for dierent Flash Devices
EPCQ16 EPCQ32 EPCQ64 EPCQ128 EPCQ256 EPCQ512 EPCQ1024
Valid
sector
range
0 to 31 0 to 63 0 to 127 0 to 255 0 to 511 0 to 1023 0 to 2047
40-10 Valid Sector Combination for Sector Protect and Sector Erase Command UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
Nios II Tools Support
Booting Nios II from Flash
Booting the Nios II from an ash will use a ow similar to Compact Flash Interface (CFI). e boot copier
used will be the same one used for CFI ash.
e boot copier will be located in ash. is has a potential performance impact on the bootcopying
process, which can be mitigated by using a ash cache.
ere are two main scenarios when booting from ash:
• Executing in place
In this scenario, boot copier will not be required. NIOS II will directly execute customer code which
located in ash.
• Boot copying the code to volatile memory
In this scenario, boot copier is required. NIOS II will run the boot copier code where the boot copier
will copy customer code to volatile memory. is is normally used when customer concern about their
code run time performance.
Flash Memory Map and Setting Nios II Reset Vector when Using a Boot Copier
e gure below shows what the ash memory map will look like when using a boot copier. is memory
map assumes a FPGA image is stored at the start.
Figure 40-3: EPCQ Flash Layout When Using Boot Copier
Customer Data (*.hex)
FPGA Image (*.sof)
0x00000000
0x0000E400
Boot Copier
Application Code
0x01E0E400
UG-01085
2016.12.19 Nios II Tools Support 40-11
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
At the start of the memory map is the FPGA image, followed by the boot copier, the application and then
customer data. e size of the FPGA image is unknown and the exact size can only be known aer the
Quartus compile. However, the Nios II Reset Vector must be set in Qsys and must point to right aer the
FPGA image (i.e. the start of the boot copier).
e 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 aer the FPGA image(s).
Boot Copier File
e boot copier that will be used is the CFI boot copier, also known as memcpy-based boot copier. We will
provide the boot copier in one or more of the following formats: Intel HEX, Quartus HEX or SREC.
When Nios II SBT will Append a Boot Copier
e Nios II SBT tools know whether to append a boot copier based on the .text linker section location. If
the .text linker section is located in a dierent memory than where the reset vector points, it indicates a
code copy is required. At this scenario a boot copier is required. You can use the existing logic to generate
a programming le with or without a boot copier depending on the scenario.
Creating HEX Programming File
e Nios II Soware Build Tools (SBT) application Makele “make mem_init_generate” target is
responsible for generating memory initialization les. is includes generating programming les (SREC,
HEX) used for ashing a ash memory and les for initializing memory (DAT, HEX) in simulation.
In boot scenario 1 (Executing in place), “make mem_init_generate” should generate a HEX le containing
ELF loadable sections
In boot scenario 2 (Boot copying the code to volatile memory), “make mem_init_generate” should
generate a HEX le containing both the boot copier and ELF payload. “make mem_init_generate” is
callable from SBT.
Programming the Flash
Programming the ash is done by using quartus_cpf to combine a compiled FPGA image (SOF) with an
application image (HEX le generated by Nios II SBT). e result of this combination is a (POF) which
can be programmed to the ash using the Quartus Prime Programmer.
In the Quartus Prime soware, "Convert Programming File tool" (quartus_cpf) can be called by selecting
File >> Convert Programming Files.
Custom Boot Copiers
Custom boot copiers can be used. “make mem_init_generate” calls conversion tools under the hood for
creating programming les from compiled ELFs. ese tools have a boot option to specify a custom boot
copier. A user will need to call these underlying conversion tools to generate a programming le with a
custom boot copier.
Executing in Place
Executing in place shouldn’t be any dierent than executing in place with an On-chip RAM. As long as
both the Nios II reset and exception vectors point to the ash memory, execution will happen in place.
e 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 ash memory.
40-12 Boot Copier File UG-01085
2016.12.19
Altera Corporation Altera Serial Flash Controller Core
Send Feedback
Nios II HAL Driver
A Nios II HAL driver will be developed similar to the driver’s currently available for CFI
(altera_avalon_c_ash) and EPCS (altera_avalon_epcs_ash_controller).
Nios II HAL supports a number of generic device model classes including one for device ashes.
Developing against these generic classes gives a consistent interface for driver functions so that the HAL
can access the driver functions uniformly.
Please refer to the Flash Device Drivers section in the Developing Device Drivers for the Hardware Abstrac‐
tion Layer for more information.
Related Information
•Nios II Processor Booting From Altera Serial Flash (EPCQ)
•Developing Device Drivers for the Hardware Abstraction Layer
Document Revision History
Table 40-19: Altera Serial Flash Controller Core Revision History
Date Version Changes
June 2015 2015.06.12 Initial release.
UG-01085
2016.12.19 Nios II HAL Driver 40-13
Altera Serial Flash Controller Core Altera Corporation
Send Feedback
Altera Avalon Mailbox (simple) Core 41
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
In a multiprocessor design, each processor may be dedicated to perform a specic 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.
e 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. e receiving processor is notied upon a message arrival. e notication 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.
Functional Description
Altera Avalon Mailbox (simple) provides two 32-bit registers for message passing between processors,
Command register (0x0) and Pointer register (0x1). e 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. e status register (0x2) is used to
indicate if the Mailbox is full or empty.
e Mailbox Avalon-MM interface which receives messages, or identied as sender interface, will back
pressure the sender if there is message pending in the Mailbox. is will ensure every single message
passed into the Mailbox is not overwritten. Upon message arrival, the receiving processor will then receive
a level interrupt by the Mailbox. e 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 o the
message pending interrupt generated by Mailbox. Meanwhile, sender interface will be able to set the mask
bit to mask o the message space interrupt output.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Figure 41-1: Altera Avalon Mailbox (simple) Block Diagram
Status Register 0x2
Pointer Register 0x1
Command Register 0x0
AvMM 1 AvMM 2
IRQ_space
IRQ_msg
Decoder and Combi logic Decoder and Combi logic
if (write && addr == 0x0) then
pending bit = 1, full bit = 1
if (((full == 1) && write req) II
~rst_n) then waitrequest = 0
if (read && addr == 0x0) then
pending bit = 0, full bit = 1
IRQ_msg = pending bit
IRQ spave = !(full bit)
clk
Rst_n
e 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. e 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.
Message Sending and Retrieval Process
e following are steps needed to send and receive messages through the Altera Avalon Mailbox (simple)
component:
1. A process or master that intends to send a message will write to the Mailbox’s Pointer register at
address oset 0x1, then only to the Command register at address oset 0x0. Writing to the Command
register indicates the completion of a message passing into the Mailbox.
2. When there is a message pending in the Mailbox, a level interrupt signal is issued to the processor that
should receive the message. Optionally, the receiver processor may choose to poll the Status register at
address oset 0x2 to determine if any message has arrived, if the interrupt signal is not used.
3. e process or master that needs to receive the message reads the Mailbox’s Pointer register and then
the Command register through the connected Avalon-MM interface. Upon reading of Command
register, the message is considered delivered, and the Mailbox is empty.
Registers of Component
e following table illustrates the Mailbox registers map that is observed by each processor from its
Avalon-MM interfaces.
Table 41-1: Mailbox Register Map
Word Address Oset Register/ Queue Name Attribute
0x0 Command register R/W for sender, RO for receiver
0x1 Pointer register R/W for sender, RO for receiver
0x2 Status register RO
41-2 Message Sending and Retrieval Process UG-01085
2016.12.19
Altera Corporation Altera Avalon Mailbox (simple) Core
Send Feedback
Word Address Oset Register/ Queue Name Attribute
0x3 Interrupt Masking register Read (R) for both sender and receiver.
Sender can only write to Message Space
Interrupt Mask bit, Receiver can only write
to Message Pending Interrupt bit.
Command Register
e Command register is a 32-bit register which contains a user dened command to be passed between
processors. is 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. e 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.
is register is read-writeable via Avalon-MM Slave (sender). However it is only readable by Avalon-MM
Slave (receiver) interface.
Status Register
e 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. is register
is read only by both Avalon-MM Slave interfaces.
Table 41-2: status Register Field
Bit Fields
31 ... ... ... ... ... 2 1 0
Reserved Mailbox full Message pending
Table 41-3: Mailbox status Register Descriptions
Filed Name Description Reset Value
Message pending Value ‘0’ indicates the Mailbox
has no message. Value ‘1’
indicates the Mailbox has
message pending for retrieval.
0
Mailbox full Value ‘1’ indicates the Mailbox
is full. Value ‘0’ indicates
Mailbox has space for
incoming message.
0
Reserved - 0
UG-01085
2016.12.19 Command Register 41-3
Altera Avalon Mailbox (simple) Core Altera Corporation
Send Feedback
Interrupt Masking Register
e Interrupt Masking Register provides a masking bit to the Message Pending Interrupt and Message
Space Interrupt. is register is accessible by both the sender and receiver of the Avalon-MM Slave
interface. However, the editable bit is only applicable for its conresponded interrupt. is means the
sender Avalon-MM Slave can only modify the masking bit of Message Space Interrupt, whereas receiver
Avalon-MM Slave can only modify the masking bit of Message Pending Interrupt. Read access of the
whole register is available to both Avalon-MM Slave Interfaces.
Table 41-4: Interrupt Masking Register Field
Bit Fields
31 ... ... ... ... ... 2 1 0
Reserved Message space
mask
Message pending mask
Table 41-5: Interrupt Masking Register Descriptions
Filed Name Description Reset Value
Message pending mask Value ‘0’ to mask o the
Message Pending Interrupt
output. Value ‘1’ enable
Message Pending Interrupt
upon triggered.
0
Mailbox space mask Value ‘0’ to mask o the
Message Space Interrupt
output. Value ‘1’ enable
Message Space Interrupt upon
triggered.
0
Reserved - 0
Interface
Component Interface
Altera Avalon Mailbox (simple) component consists of two Avalon-MM Slave interfaces, one dedicated for
each processor. e Mailbox also provides active high level interrupt output, which is served as message
arrival notication to the receiving processor. Optionally, a secondary IRQ is created as notication to the
message sender indicating if Mailbox is available for incoming message.
Altera Avalon Mailbox (simple) has only one clock domain with one associated reset interface. Require‐
ment of dierent clock domains between two processors is handled through the Qsys fabric. e following
table describes the interfaces behavior of the component.
41-4 Interrupt Masking Register UG-01085
2016.12.19
Altera Corporation Altera Avalon Mailbox (simple) Core
Send Feedback
Table 41-6: Component Interface Behavior
Interface Port Description Details
Avalon MM Slave (sender) Avalon-MM Slave interface for
processor of message sender.
is interface apply wait request signal for
back pressuring the Avalon-MM Master if
Mailbox is already full.
Avalon MM Slave
(receiver)
Avalon-MM Slave interface for
processor of message receiver.
is interface only has read capability with
readWaitTime=1.
Clock Clock input of component. It supports maximum frequency up to
400MHz on CycloneIV and 600MHz in
StratixIV devices.
Reset_n Active LOW reset input/s. Support asynchronous reset assertion. De-
assertion of reset has to be synchronized to
the input clock.
IRQ_msg Message Pending Interrupt
output to processor of message
receiver upon message arrival.
e signal will remain high
until the message is retrieved.
Interrupt assertion and deassertion is
synchronized to input clock.
IRQ_space Message Space Interrupt
output processor of message
sender whenever Mailbox has
space for incoming message.
e signal will assert high as
long as the Mailbox is yet full.
Interrupt assertion and deassertion is
synchronized to input clock. e
connection of this interrupt port to the top
level is depends on conguration parameter
of MSG_SPACE_NOTIFY.
Component Parameterization
Table 41-7: Altera Avalon Mailbox (simple) TCL Component Conguration Parameters
Parameter Name Description Default Value Allowable Range
MSG_SPACE_NOTIFY Boolean ‘true’ will enable
interrupt output to message
sending processor for indicating
available space for incoming
message
0 0, 1
MSG_ARRIVAL_NOTIFY Boolean ‘true’ will enable
interrupt output to message
receiver processor for indicating
a message is pending for
retrieval.
1 0, 1
UG-01085
2016.12.19 Component Parameterization 41-5
Altera Avalon Mailbox (simple) Core Altera Corporation
Send Feedback
HAL Driver
is section describes the HAL driver for Altera Avalon Mailbox (simple) so 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. e receiver processor is
notied 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).
e 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
e Mailbox driver message delivery depends on how the QSYS design of the sender processor, receiver
processor and Mailbox are interconnected. e Mailbox driver provides the features to send message to
target processor and retrieve message for the receiver processor. e driver include an interrupt service
routine when interrupt mode is used.
Conguration
Interrupt Mode
e gure below is an example of a design using the Altera Avalon Mailbox (simple) in interrupt mode.
e 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. e Command register will send a message pending
interrupt to the receiver. e 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 agged 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
NIOS 2
(CPU1)
NIOS 2
(CPU2)
Mailbox 1
Mailbox 2
message sender intr
message sender intr
message pending intr
message pending intr
41-6 HAL Driver UG-01085
2016.12.19
Altera Corporation Altera Avalon Mailbox (simple) Core
Send Feedback
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.
Table 41-8: Mailbox APIs
Function Name Description
altera_avalon_mailbox_send Send message to Mailbox
altera_avalon_mailbox_status Query current state of Mailbox
altera_avalon_mailbox_retrieve_poll Read from Mailbox pointer register to retrieve messages
altera_avalon_mailbox_open Claims a handle to a Mailbox, enabling all the other functions
to access the Mailbox core
altera_avalon_mailbox_close Close the handle to a Mailbox
Table 41-9: altera_avalon_mailbox_open
Prototype: altera_avalon_mailbox_dev* altera_avalon_mailbox_open (const char* name, altera_
mailbox_tx_cb tx_callback, altera_mailbox_rx_cb rx_callback)
Include: <altera_avalon_mailbox_simple.h>
Parameters: Name — e Mailbox device name to open.
tx_callback – User to provide callback function to notify when a sending message is
completed.
rx_callback – User to provide callback function to notify when a receive a message.
Returns: Pointer to mailbox
Description: altera_avalon_mailbox_open() nd and register the Mailbox device pointer. is
function also registers the interrupt handler and user callback function for a interrupt
enabled Mailbox.
Table 41-10: altera_avalon_mailbox_close
Prototype: void altera_avalon_mailbox_close (altera_avalon_mailbox_dev* dev);
Include: <altera_avalon_mailbox_simple.h>
Parameters: dev—e Mailbox to close.
Returns: Null
Description: alt_avalon_mailbox_close() closes the mailbox de-registering interrupt handler and
callback functions and masking Mailbox interrupt.
UG-01085
2016.12.19 Polling Mode 41-7
Altera Avalon Mailbox (simple) Core Altera Corporation
Send Feedback
Table 41-11: altera_avalon_mailbox_send
Prototype: int altera_avalon_mailbox_send (altera_avalon_mailbox_dev* dev, void* message, int
timeout, EventType event)
Include: <altera_avalon_mailbox_simple.h>
Parameters: *message – Pointer to message command and pointer structure.
Timeout – Species number of loops before sending a message. Give a ‘0’ value to wait
until the message is transferred.
EventType – set ‘POLL’ or ‘ISR’.
Returns: Return 0 on success and 1 for fail.
Description: altera_avalon_mailbox_send () sends a message to the mailbox. is is a blocking
function when the sender interrupt is disabled.
is function is in non-blocking when interrupt is enabled.
Table 41-12: altera_avalon_mailbox_retrieve_poll
Prototype: int altera_avalon_mailbox_retrieve_poll (altera_avalon_mailbox_dev* dev,alt_u32* msg_
ptr, alt_u32 timeout)
Include: <altera_avalon_mailbox_simple.h>
Parameters: dev - e Mailbox device to read message from.
timeout – Species number loops before sending a message. Give a ‘0’ value to wait until
a message is retrieved.
msg_ptr – A pointer to an array of two Dwords which are for the command and message
pointer. is pointer will be populated with a receive message if successful or NULL if
error.
Returns: Return pointer to message and command. Return ‘NULL’ in messages if timeout. is is a
blocking function.
Description: altera_avalon_mailbox_retrieve_poll () reads a message pointer and command to
Mailbox structure from the Mailbox and noties through callback.
Table 41-13: altera_avalon_mailbox_status
Prototype: alt_u32 altera_avalon_mailbox_status (altera_avalon_mailbox_dev* dev)
Include: <altera_avalon_mailbox_simple.h>
Parameters: dev -e Mailbox device to read status from
41-8 Driver Implementation UG-01085
2016.12.19
Altera Corporation Altera Avalon Mailbox (simple) Core
Send Feedback
Returns: For a receiving Mailbox:
- 0 for no message pending
- 1 for message pending
For a sending Mailbox:
- 0 for Mailbox empty (ready to send)
- 1 for Mailbox full (not ready to send)
Description: Indicates to sender Mailbox it is full or empty for transfer.
Indicates to receiver Mailbox has a message pending or not.
Example 41-1: Device structure
// Callback routine type definition
typedef void(*altera_mailbox_rx_cb)(void *message);
typedefvoid (*altera_mailbox_tx_cb)(void *message,int status);
typedef enum mbox_type { MBOX_TX = 0,MBOX_RX } MboxType;
typedef enum event_type { ISR = 0, POLL } EventType;
typedef struct altera_avalon_mailbox_dev
{
alt_dev dev; /* Device linke-list entry
*/
alt_u32 base; /* Base address of Mailbox
*/
alt_u32 mailbox_irq; /* Mailbox IRQ */
alt_u32 mailbox_intr_ctrl_id; /* Mailbox IRQ ID */
altera_mailbox_tx_cb tx_cb; /* Callback routine
pointer */
altera_mailbox_rx_cb rx_cb; /* Callback routine
pointer */
MboxType mbox_type; /* Mailbox direction */
alt_u32* mbox_msg; /* a pointer to message
array to be
* received or sent */
alt_u8 lock; /* Token to indicate
mbox_msg already taken */
ALT_SEM (write_lock) /* Semaphore used to
control access to the
* write in multi-threaded mode */
} altera_avalon_mailbox_dev;
Driver Examples
e gure below demonstrates writing to a Mailbox. For this example, assume that the hardware system
has two processors communicating via Mailboxes. e system includes two Mailbox cores, which provides
two-way communication between the processors.
UG-01085
2016.12.19 Driver Examples 41-9
Altera Avalon Mailbox (simple) Core Altera Corporation
Send Feedback
Example 41-2: Sender Processor Using Mailbox to Send a Message.
#include <stdio.h>
#include "altera_avalon_mailbox_simple.h"
#include "altera_avalon_mailbox_simple_regs.h"
#include "system.h"
/* example callback function from users*/
void tx_cb (void* report, int status) {
if (!status) {
printf (“Transfer done”);
} else {
printf (“error in transfer”);
}
int main_sender()
{
alt_u32 message[2] = {0x00001111, 0xaa55aa55};
int timeout = 50000;
alt_u32 status;
alt_avalon_mailbox_simple_dev* mailbox_sender;
/* Open mailbox on sender processor */
mailbox_sender = alt_avalon_mailbox_open("/dev/mailbox_simple_0", tx_cb,
NULL);
if (!mailbox_sender){
printf ("FAIL: Unable to open mailbox_simple");
return 1;
}
/* Send a message to the other processor using interrupt */
altera_avalon_mailbox_send (mailbox_sender, message, 0, ISR);
/* Using polling method to send a message, with infinite timeout */
timeout = 0;
status = altera_avalon_mailbox_send (mailbox_sender, message,
timeout, POLL);
if (status) {
printf (“error in transfer”);
} else {
printf (“Transfer done”);
}
/* Closing mailbox device and de-registering interrupt handler and
callback */
altera_avalon_mailbox_close (mailbox_sender);
return 0;
}
Example 41-3: Receiver Processor Waiting for Message.
#include <stdio.h>
#include "altera_avalon_mailbox_simple.h"
#include "altera_avalon_mailbox_simple_regs.h"
#include "system.h"
void rx_cb (void* message) {
/* Get message read from mailbox */
41-10 Driver Examples UG-01085
2016.12.19
Altera Corporation Altera Avalon Mailbox (simple) Core
Send Feedback
alt_u32* data = alt_u32* message;
if (message!= NULL) {
printf (“Message received”);
} else {
printf (“Incomplete receive”);
}
int main_receiver()
{
alt_u32* message[2];
int timeout = 50000;
alt_avalon_mailbox_simple_dev* mailbox_rcv;
/* This example is running on receiver processor */
mailbox_rcv = alt_avalon_mailbox_open("/dev/mailbox_simple_1", NULL,
rx_cb);
if (!mailbox_rcv){
printf ("FAIL: Unable to open mailbox_simple");
return 1;
}
/* For interrupt disable system */
altera_avalon_mailbox_retrieve_poll (mailbox_rcv,message, timeout)
if (message == NULL) {
printf (“Receive Error”);
} else {
printf (“Message received with Command 0x%x and Message 0x%x\n”,
message[0], message[1]);
}
altera_avalon_mailbox_close (mailbox_rcv);
return 0;
}
Document Revision History
Table 41-14: Altera Avalon Mailbox (simple) Core Revision History
Date Version Changes
November 2015 2015.11.06 Added HAL Driver section.
June 2015 2015.06.12 Initial release.
UG-01085
2016.12.19 Document Revision History 41-11
Altera Avalon Mailbox (simple) Core Altera Corporation
Send Feedback
Altera I2C Slave to Avalon-MM Master Bridge
Core 42
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e Altera I2C Slave to Avalon-MM Master Bridge so IP core is a solution to connect an I2C interface
with a User Flash Memory (UFM) device. is 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
Functional Description
e 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
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Block Diagram
Figure 42-1: Altera I2C to Avalon-MM Master Bridge Block Diagram
Avalon-MM Master Interface
I2C slave interface
Condition
detector
Slave
FSM
Clock
counter
Spike
suppresion
TX out TX shifter TX data buffer
RX
shifter
RX data
buffer
I2C to Avalon master
interface translator
N-byte Addressing
is IP supports up to a 4 bytes addressing mode. You can select which byte addressing mode you want to
use in Qsys.
e Avalon Address width present at the Avalon master interface is xed at 32 bits. If you select other than
a 4 bytes addressing mode, zeros are added to the most signicant 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
ere is an address counter inside the I2C to Avalon master interface translator block. e 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.
N-byte Addressing with N-bit Address Stealing
is IP supports up to 3-bit address stealing. In Qsys, you can congure which address stealing mode to
use. e address stealing bits (A0, A1, A2) are added into the second, third, and forth bits of the control
byte to expand the contiguous address space. If no address stealing bits are used, then the second, third,
and forth bits of the control byte are used as slave address bits.
Note: When in 3-bit address stealing mode, you must make sure the three least signicant bits (LSB) of
the slave address are zero.
e maximum upper bound of the internal address counter is:
BYTEADDRWIDTH + address stealing bit(s)
42-2 Block Diagram UG-01085
2016.12.19
Altera Corporation Altera I2C Slave to Avalon-MM Master Bridge Core
Send Feedback
Figure 42-2: 8-bit Control Byte Example
UG-01085
2016.12.19 N-byte Addressing with N-bit Address Stealing 42-3
Altera I2C Slave to Avalon-MM Master Bridge Core Altera Corporation
Send Feedback
Read Operation
e 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. e 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 ow:
• Checks the address alignment issued by the I2C master (rst 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.
is 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. e 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.
Random Address Read
Random read operations allow the upstream I2C master to access any memory location in a random
manner. To perform this type of read operation, you must rst set the byte address. e I2C master issues a
byte address to the bridge as part of a write operation then followed by a read command. Aer the read
command is issued, the internal address counter points to the address location following the one that was
just read. e upper address bits are transferred rst, followed by the LSB(s).
Figure 42-3: Random Address Read
Sequential Address Read
Sequential reads are initiated in the same way as a random read except aer the bridge has received the
rst data byte, the upstream I2C master issues an acknowledge as opposed to a Stop condition. is directs
the bridge to keep the Avalon read signal high for the next sequential address. e internal address counter
increments by one at the completion of each read operation and allows the entire memory contents to be
serially read during one operation.
42-4 Read Operation UG-01085
2016.12.19
Altera Corporation Altera I2C Slave to Avalon-MM Master Bridge Core
Send Feedback
Figure 42-4: Sequential Address Read
Current Address Read
is IP contains an internal address counter that maintains the address of the last word accessed
incremented by one. erefore, if the previous access was to address n, the next current address read
operation would access data from address n + 1.
Figure 42-5: Current Address Read
Write Operation
e 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. ere is a conversion logic which sits between the Avalon interface and the I2C
interface.
Write operation conversion logic ow:
• 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 4’b1000.
• Combines multiple bytes of data into a 32-bit packet if their addresses are sequential.
Note: If the rst write is to address 0x04 and the second write is to address 0x05, then byteenable is
4’b0011.
Legal byteenable combinations are 4’b0001, 4’b0010, 4’b0100, 4’b1000, 4’b0011, 4’b1100 and 4’b1111.
UG-01085
2016.12.19 Current Address Read 42-5
Altera I2C Slave to Avalon-MM Master Bridge Core Altera Corporation
Send Feedback
• If the write request issued by the I2C master ends up with an illegal byteenable combination such as,
4’b0110, 4’b0111, or 4’b1110, 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, b’0111), then the bridge will generate three Avalon write requests with legal
byteenable 4’b0001, 4’b0010 and 4’b0100.
• 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. e next byte transmitted by the master is the byte address. e byte address is written into the
address counter inside the bridge. e bridge acknowledges the I2C master again and the master transmits
the data byte to be written into the addressed memory location. e master keeps sending data bytes to
the bridge and terminates the operation with a Stop condition at the end.
Figure 42-6: Write Operation
42-6 Write Operation UG-01085
2016.12.19
Altera Corporation Altera I2C Slave to Avalon-MM Master Bridge Core
Send Feedback
Interacting with Multi-Master
is IP core is able to integrate multiple I2C masters provided the I2C masters support the arbitration
feature. e masters which support arbitration always compares the data value it drives into the bus with
the actual value observed on the bus. If both sets of data do not match, then the master loses arbitration.
e I2C slave core in the bridge does not observe the bus.
For example, let’s say Master 1 is writing to the bridge while Master 2 is performing a read. Master 1 will
win the arbitration during the R/W bit because Master 1 is pulling down the bus, while Master 2 is driving
high to the bus. e eective value of the bus during the R/W bit cycle is zero. In this case, Master 2 knows
it loses the arbitration because it observes a dierent value on the bus than what is being driven.
If both masters are performing a write, then the arbitration process checks the dierent data value driven
by both masters to determine which one wins the arbitration.
If both masters are performing a read, then no one loses the arbitration since the single slave is driving the
bus to both masters (no collision).
UG-01085
2016.12.19 Interacting with Multi-Master 42-7
Altera I2C Slave to Avalon-MM Master Bridge Core Altera Corporation
Send Feedback
Qsys Parameters
Figure 42-7: Altera I2C Slave to Avalon MM Master Bridge Qys Interface
Table 42-1: Qsys Parameters
Parameter Legal Values Default
Values
Description
I2C Slave Address 0:127 127 is parameter represents the target address of the
I2C slave which sits in the bridge.
Byte Addressing mode 1, 2, 3, 4 2 is parameter allows you to select the number of
address bytes you want to congure according to
the ash capacity used.
• 1=8 address bit
• 2=16 address bit
• 3=24 address bit
• 4=32 address bit
Number of Address
Stealing bit
0, 1, 2, 3 0 is parameter allows you to select the number of
address stealing bits to expand the contiguous
address space.
Enable Read only mode ON, OFF OFF Enables read only support where the write
operation is removed to improve resource count.
42-8 Qsys Parameters UG-01085
2016.12.19
Altera Corporation Altera I2C Slave to Avalon-MM Master Bridge Core
Send Feedback
Signals
Table 42-2: Altera I2C Slave to Avalon-MM Master Bridge Signals
Signal Width Direction Description
Avalon-MM interface
clk 1 Input Clock signal
rst_n 1 Input Reset signal
address 32 Output Avalon-MM address bus. e address bus is
in word addressing.
byteenable 4 Output Avalon-MM byteenable signal.
read 1 Output Avalon-MM read request signal.
readdata 32 Input Avalon-MM read data bus.
readdatavalid 1 Input Avalon-MM read data valid signal.
waitrequest 1 Input Avalon-MM wait request signal
write 1 Output Avalon-MM write request signal.
writedata 32 Output Avalon-MM write data bus.
Serial conduit interface for I2C
i2c_data_in 1 Input I2C slave conduit data input signal.
i2c_clk_in 1 Input I2C slave conduit clock input signal.
i2c_data_oe 1 Output I2C slave conduit data output signal.
i2c_clk_oe 1 Output I2C slave conduit clock output signal.
UG-01085
2016.12.19 Signals 42-9
Altera I2C Slave to Avalon-MM Master Bridge Core Altera Corporation
Send Feedback
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 gure below.
You need to connect a tri-state buer to the cores I2C data and clock related ports to form SDA and SCL.
Figure 42-8:
On chip Off chip
SDA
SCL
Vcc
Vcc
I/O
PAD
I/O
PAD
ic_data_oe
ic_clk_oe
1’b0
1’b0
ic_data_in_a
ic_clk_in_a
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;
assign fx2_scl_in = fx2_scl;
assign fx2_sda_in = fx2_sda;
assign fx2_scl = fx2_scl_oe ? 1'b0 : 1'bz;
assign fx2_sda = fx2_sda_oe ? 1'b0 : 1'bz;
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
42-10 How to Translate the Bridge's I2C Data and I2C I/O Ports to an I2C Interface UG-01085
2016.12.19
Altera Corporation Altera I2C Slave to Avalon-MM Master Bridge Core
Send Feedback
Document Revision History
Table 42-3: Altera I2C Slave to Avalon-MM Master Bridge Core Revision History
Date Version Changes
Ocotober 2016 2016.10.28 Updates:
•Table 42-2
•address direction updated
•waitrequest added
June 2016 2016.06.17 New topic:
•How to Translate the Bridge's I2C Data and I2C I/O Ports to an
I2C Interface on page 42-10
May 2016 2016.05.03 Initial release.
UG-01085
2016.12.19 Document Revision History 42-11
Altera I2C Slave to Avalon-MM Master Bridge Core Altera Corporation
Send Feedback
Avalon-MM DDR Memory Half Rate Bridge Core 43
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. e core works under the
assumption that the memory clock is twice the frequency of the CPU clock, with zero phase shi 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. is half-rate
bridge provides the same functionality as the clock crossing bridge, but with signicantly lower latency—2
cycles instead of 12.
e core’s 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. e gure 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
8
DDR Clk <-----------> Controller Clk <-----------> Controller Clk/2
16
DDR2/3 High
Performance
Controller
(full rate)
FPGA
PCB
32
DDR
n
burst count = 4 burst count = 2 burst count = 1
Half-Rate
Bridge SS MMCPU
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
e 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 dierent bus sizes between CPU and memory
• Requires the frequency of the master clock to be double of the slave clock
• Has congurable address and data port widths in the master interface
Resource Usage and Performance
is section lists the resource usage and performance data for supported devices when operating the Half-
Rate Bridge with a full-rate DDR SDRAM high-performance memory controller.
Using the Half-Rate Bridge with a full-rate DDR SDRAM high-performance memory controller results an
average of 48% performance improvement over a system using a half-rate DDR SDRAM high-perform‐
ance memory controller in a series of embedded applications. e performance improvement is 62.2%
based on the Dhrystone benchmark, and 87.7% when accessing memory bypassing the cache. For memory
systems that use the Half-Rate bridge in conjunction with DDR2/3 High Performance Controller, the data
throughput is the same on the Half-Rate Bridge master and slave interfaces. e decrease in memory
latency on the Half-Rate Bridge slave interface results in higher performance for the processor.
e table below shows the resource usage for Stratix II and Stratix III devices in the Quartus Prime
soware with a data width of 16 bits, an address span of 24 bits.
Table 43-1: Resource Utilization Data for Stratix II and Stratix III Devices
Device Family Combinational
ALUTs
ALMs Logic Register Embedded Memory
Startix II 61 134 153 0
Stratix III 60 138 153 0
Table 43-2: Resource Utilization Data for Cyclone III Devices
Logic Cells (LC) Logic Register LUT-only LC Register-only LC LUT/Register
LCs
Embedded Memory
233 152 33 84 121 0
Functional Description
e Avalon MM DDR Memory Half Rate Bridge works under two constraints:
• Its memory-side master has a clock frequency that is synchronous (zero phase shi) to, and twice the
frequency of, the CPU-side slave.
• Its memory-side master is half as wide as its CPU-side slave.
e bridge leverages these two constraints to provide lightweight, low-latency clock-crossing logic
between the CPU and the memory. ese 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.
43-2 Resource Usage and Performance UG-01085
2016.12.19
Altera Corporation Avalon-MM DDR Memory Half Rate Bridge Core
Send Feedback
e 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 slave’s 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 o-chip memory device.
e gure below shows the latency in the Avalon-MM Half-Rate Bridge core. e core adds two cycles of
latency in the slave clock domain for read transactions. e rst cycle is introduced during the command
phase of the transaction and the second cycle, during the response phase of the transaction. e 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 High
Performance
Controller
(full rate)
Half-Rate Bridge
Cmd +1
Rsp +1
Q D
D Q
SSM
DDR2/3
Memory CPU
Instantiating the Core in Qsys
Use the IP Catalog in Qsys to nd the Avalon-MM DDR Memory Half-Rate Bridge core. In the parameter
editor window you can specify the core’s conguration. e table below describes the parameters that can
be congured for the Avalon-MM Half-Rate Bridge core.
Table 43-3: Congurable Parameters for Avalon-MM DDR Memory Half-Rate Bridge Core
Parameters Allowed Values Default Value Description
Data Width 8, 16, 32, 64, 128, 256,
512
16 e width of the data signal in
the master interface.
Address Width 1-32 24 e width of the address signal
in the master interface.
e 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.
UG-01085
2016.12.19 Instantiating the Core in Qsys 43-3
Avalon-MM DDR Memory Half Rate Bridge Core Altera Corporation
Send Feedback
Table 43-4: Derived Parameters for Avalon-MM DDR Memory Half-Rate Bridge Core
Parameter Default Value Description
Master interface’s Byte
Enable Width
2e width of the byte-enable signal in the
master interface.
Slave interface’s Data Width 32 e width of the data signal in the slave
interface.
Slave interface’s Address
Width
22 e width of the address signal in the slave
interface.
Slave interface’s Byte Enable
Width
4e width of the byte-enable signal in the
slave interface.
Example System
e following example provides high-level steps showing how the Avalon-MM DDR Memory Half-Rate
Bridge core is connected in a system. is 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 congure it to full-rate mode.
3. Add Avalon-MM DDR Memory Half-Rate Bridge to the system.
4. Congure 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. e 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.
Document Revision History
Table 43-5: Avalon-MM DDR Memory Half Rate Bridge Core Revision History
Date Version Changes
June 2016 2016.06.17 Initial release
43-4 Example System UG-01085
2016.12.19
Altera Corporation Avalon-MM DDR Memory Half Rate Bridge Core
Send Feedback
Altera Avalon I2C (Master) Core 44
2016.12.19
UG-01085 Subscribe Send Feedback
Core Overview
e 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. Congure 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.
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
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
Conguration Parameters
Congure the following parameters through Qsys.
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Table 44-1: Qsys Parameters
Parameter Legal Values Default Values Description
Interface for transfer
command FIFO and
receive data FIFO
accesses
0 or 1 0 0: Avalon-MM
interface access
command and receive
data FIFO
1: Avalon-ST interface
access command and
receive data FIFO
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
Avalon-MM Slave
Avalon-ST Source
Avalon-ST Sink
Serial Interface
Interrupt
Altera Avalon
I2C Core
Table 44-2: Altera Avalon I2C (Master) Core Signals
Signal Width Direction Description
Clock/Reset
clk 1 Input System clock source
rst_n 1 Input System asynchronous reset source
Note: is signal is asynchronously asserted
and synchronously de-asserted. e
synchronous de-assertion must be
provided externally to this peripheral.
Avalon-MM Slave
44-2 Interface UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Signal Width Direction Description
addr 4 Input Avalon-MM address bus.
e address bus is in the unit of word addressing.
For example, addr[2:0] = 0x0 is targeting the rst
word of the cores memory map space and
addr[2:0] = 0x1 is targeting the second word.
read 1 Input Avalon-MM read control
write 1 Input Avalon-MM write control
readdata 32 Output Avalon-MM read data bus
writedata 32 Input Avalon-MM write data bus
Avalon-ST Source (22)
src_data 8 Output I2C data from receive data FIFO (RX_DATA)
src_valid 1 Output Indicates src_data bus is valid
src_ready 1 Input Indication from sink port that it is ready to
consume src_data
Avalon-ST Sink(22)
snk_data 10 Input 10-bit value driven by source port to transfer
command FIFO (TFR_CMD)
snk_valid 1 Input Indication from source port that snk_data is
valid
snk_ready 1 Output Indication from sink port that it is ready to
consume snk_data
Serial Interface
scl_oe 1 Output Output enable for open drain buer that drives
SCL pin
1: SCL line pulled low
0: Open drain buer is tri-stated and SCL line is
externally pulled high
sda_oe 1 Output Output enable for open drain buer that drives
SDA pin
1: SDA line pulled low
0: Open drain buer is tri-stated and SDA line is
externally pulled high
scl_in 1 Input Input path of I2C’s open drain buer
sda_in 1 Input It is from input path of I2C’s open drain buer
Interrupt
intr 1 Output Active high level interrupt output to host
processor
UG-01085
2016.12.19 Interface 44-3
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Registers
Register Memory Map
Note: Each address oset represent 1 word of memory address space.
Table 44-3: Register Memory Map
Name Address oset Description
TFR_CMD 0x0 Transfer command FIFO
RX_DATA 0x1 Receive data FIFO
CTRL 0x2 Control register
ISER 0x3 Interrupt status enable register
ISR 0x4 Interrupt status register
STATUS 0x5 Status register
TFR_CMD_FIFO_LVL 0x6 TFR_CMD FIFO level register
RX_DATA_FIFO_LVL 0x7 RX_DATA FIFO level register
SCL_LOW 0x8 SCL low count register
SCL_HIGH 0x9 SCL high count register
SDA_HOLD 0xA SDA hold count register
Register Descriptions
Transfer Command FIFO (TFR_CMD)
Table 44-4: Transfer Command FIFO (TFR_CMD)
Bit Fields Access Default Value Description
31:10 Reserved N/A 0x0 Reserved
9STA W N/A 1: Requests a repeated START
condition to be generated before
current byte transfer
8STO W N/A 1: Requests a STOP condition to be
generated aer current byte transfer
(22) ese signals are not used if “Interface for transfer command FIFO and receive data FIFO accesses” is set to
Avalon-MM Slave. is setting can be congured through Qsys.
44-4 Registers UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Bit Fields Access Default Value Description
7:1 AD W N/A When in address phase, these elds act
as address bits
When in data phase with the core is
congured as a master transmitter,
these elds represent I2C data bit [7:1]
of the data byte to be transmitted by
the core.
When in data phase and the core acts
as master receiver, this eld is not used
0RW_D W N/A When transfer is in address phase, this
eld is used to specify the direction of
I2C transfer
0: Species I2C write transfer request
1: Species I2C read transfer request
When transfer is in data phase wtih
core is congured as a master
transmitter, this eld represents I2C
data bit 0 of the data byte to be
transmitted by the core.
When transfer is in data phase and the
core acts as master receiver, this eld is
not used
Receive Data FIFO (RX_DATA)
Table 44-5: Receive Data FIFO (RX_DATA)
Bit Fields Access Default Value Description
31:8 Reserved N/A 0x0 Reserved
7:0 RXDATA R N/A Byte received from I2C transfer
Control Register (CTRL)
Bit Fields Access Default Value Description
31:6 Reserved N/A 0x0 Reserved
UG-01085
2016.12.19 Receive Data FIFO (RX_DATA) 44-5
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
5:4 RX_DATA_FIFO_THD R/W 0x0 reshold level of the receive data
FIFO
Note: If the actual level is equal or
more than the threshold
level, RX_READY interrupt
status bit is asserted.
0x3: RX_DATA FIFO is full
0x2: RX_DATA FIFO is ½ full
0x1: RX_DATA FIFO is ¼ full
0x0: 1 valid entry
3:2 TFR_CMD_FIFO_THD R/W 0x0 reshold level of the transfer
command FIFO
Note: If the actual level is equal or
less than the threshold level,
TX_READY interrupt status
bit is asserted.
0x3: TFR_CMD FIFO is not full (has at
least one empty entry)
0x2: TFR_CMD FIFO is ½ full
0x1: TFR_CMD FIFO is ¼ full
0x0: TFR_CMD FIFO is empty
1BUS_SPEED R/W 0x0 Bus speed
1: Fast mode (up to 400 kbits/s)
0: Standard mode (up to 100 kbits/s)
0EN R/W 0x0 e core enable bit
1: Core is enabled
0: Core is disabled
Interrupt Status Enable Register (ISER)
Table 44-6: Interrupt Status Enable Register (ISER)
Bit Fields Access Default Value Description
31:5 Reserved N/A 0x0 Reserved
4RX_OVER_EN R/W 0x0 1: Enable interrupt for RX_OVER
condition
44-6 Interrupt Status Enable Register (ISER) UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Bit Fields Access Default Value Description
3ARBLOST_DET_EN R/W 0x0 1: Enable interrupt for ARBLOST_DET
condition
2NACK_DET_EN R/W 0x0 1: Enable interrupt for NACK_DET
condition
1RX_READY_EN R/W 0x0 1: Enable interrupt for RX_READY
condition
0TX_READY_EN R/W 0x0 1: Enable interrupt for TX_READY
condition
Interrupt Status Register (ISR)
Table 44-7: Interrupt Status Register (ISR)
Bit Fields Access Default Value Description
31:5 Reserved N/A 0x0 Reserved
4RX_OVER R/W1C 0x0 Receive overrun
1: Indicates receive data FIFO has
overrun condition, new data is lost.
Note: Writing 1 to this eld clears
the content of the eld to 0.
3ARBLOST_DET R/W1C 0x0 Arbitration lost detected
1: Indicates core has lost the bus
arbitration
Note: Writing 1 to this eld clears
the content of this eld to 0.
2NACK_DET R/W1C 0x0 No acknowledgement detected
1: Indicates NACK is received by the
core
Note: Writing 1 to this eld clears
the content of this eld to 0.
UG-01085
2016.12.19 Interrupt Status Register (ISR) 44-7
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
1RX_READY R 0x0 Receive ready
1: Indicates receive data FIFO contains
data sent by the remote I2C device.
is bit is asserted when RX_DATA
FIFO level is equal or more than RX_
DATA FIFO threshold.
Note: is eld is automatically
cleared by the core's
hardware once the receive
data FIFO level is less than
RX_DATA FIFO threshold.
0TX_READY R 0x0 Transmit ready
1: Indicates transfer command FIFO is
ready for data transmission. is bit is
asserted when transfer command FIFO
level is equal or less than TFR_CMD
FIFO threshold.
Note: is eld is automatically
cleared by the core's
hardware once transfer
command FIFO level is
more than TFR_CMD FIFO
threshold.
Status Register (STATUS)
Table 44-8: Status Register (STATUS)
Bit Fields Access Default Value Description
31:1 Reserved N/A 0x0 Reserved
0CORE_STATUS R 0x0 Status of the core's state machine
1: State machine is not idle
0: State machine is idle
44-8 Status Register (STATUS) UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
TFR CMD FIFO Level (TFR CMD FIFO LVL)
Table 44-9: TFR CMD FIFO Level (TFR CMD FIFO LVL)
Bit Fields Access Default Value Description
31:
log2(FIFO
_DEPTH)
+ 1
Reserved N/A 0x0 Reserved
log2(FIFO
_DEPTH)
:0
LVL R 0x0 Current level of TFR_CMD FIFO
RX Data FIFO Level (RX Data FIFO LVL)
Table 44-10: RX Data FIFO Level (RX Data FIFO LVL)
Bit Fields Access Default Value Description
31:log2(FI
FO_
DEPTH)
+ 1
Reserved N/A 0x0 Reserved
log2(FIFO
_DEPTH):
0
LVL R 0x0 Current level of RX_DATA FIFO
SCL Low Count (SCL LOW)
Table 44-11: SCL Low Count (SCL LOW)
Bit Fields Access Default Value Description
31:16 Reserved N/A 0x0 Reserved
15:0 COUNT_PERIOD R/W 0x1 Low period of SCL in terms of number
of clock cycles
SCL High Count (SCL HIGH)
Table 44-12: SCL High Count (SCL HIGH)
Bit Fields Access Default Value Description
31:16 Reserved N/A 0x0 Reserved
UG-01085
2016.12.19 TFR CMD FIFO Level (TFR CMD FIFO LVL) 44-9
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Bit Fields Access Default Value Description
15:0 COUNT_PERIOD R/W 0x1 High period of SCL in term of number
of clock cycles
SDA Hold Count (SDA HOLD)
Table 44-13: SDA Hold Count (SDA HOLD)
Bit Fields Access Default Value Description
31:16 Reserved N/A 0x0 Reserved
15:0 COUNT_PERIOD R/W 0x1 Hold period of SDA in term of number
of clock cycles
Reset and Clock Requirements
e core is a single clock domain design. e frequency of the single clock source must be maintained
throughout the run time period. is requirement is needed because the implementation of SCL low, SCL
high, and SDA hold period is based on the frequency of the single clock source. If the frequency of the
clock changes in the middle of the run time, the initial conguration of SCL low, SCL high and SDA hold
period will be unable to produce the correct timing. On the next run, the system recongures those
options to ensure correct timing is produced.
e core has a single reset input which is used to reset the entire core. e single reset input is required to
be asynchronously asserted and synchronously de-asserted. e de-assertion of the reset must be synchro‐
nous to the single input clock source of the core. e reset synchronizer is should be implemented
externally.
Functional Description
Overview
e core implements I2C master functionality. It can generate all mandatory I2C transfer protocol through
the TFR_CMD register conguration. e core supports a joint data streaming use-cases where the DMA
core can be used for bulk transfer.
44-10 SDA Hold Count (SDA HOLD) UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Figure 44-2: Altera Avalon I2C Master Core without DMA
Bidirectional
Open Drain
Buffer
Host
Processor
Others
peripherals
Interrupt
Controller
Avalon-MM Bus
interrupt
Serial
control
ports
Bidirectional
I/O Pad
I2C Avalon
Master Core
Figure 44-3: Altera Avalon I2C Master Core with DMA
Bidirectional
Open Drain
Buffer
Host
Processor
Others
peripherals
Interrupt
Controller
interrupt
Serial
control
ports
Bidirectional
I/O Pad DMA TX
DMA RX
I2C Avalon
Master Core
Avalon-MM Bus
Avalon-ST
Avalon-ST
On-Chip
Memory
Conguring TFT_CMD Register Examples
7-bit Addressing Mode
Note: Assume the slave has a 7-bit address of 0x51.
Master Transmitter Writes 2 Bytes to Slave Receiver
Write data1 = 0x55 and write data2 = 0x56.
Figure 44-4: Master Transmitter Writes 2 Bytes to Slave Receiver
S Slave Address W A WDATA1 A WDATA2 A P
from master to slave
from slave to master
A = acknowledge
N = not acknowledge
S = START condition
P = STOP condition
Sr = Repeated START condition
UG-01085
2016.12.19 Conguring TFT_CMD Register Examples 44-11
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
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
Master Receiver Reads 2 Bytes from Slave Transmitter
Read data1 = 0x55 and read data2 = 0x56.
Figure 44-5: Master Receiver Reads 2 Bytes from Slave Transmitter
S Slave Address R A RDATA1 A RDATA2 N P
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 elds are (don’t 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)
S Slave Address W A WDATA1 A Sr Slave Address R A RDATA1 A RDATA2 N P
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)
10-bit Addressing Mode
Note: Assume slave 10-bit address = 0x351.
Master Transmitter Writes 2 Bytes to Slave Receiver
Write data1 = 0x55 and write data2 = 0x56.
Figure 44-7: Master Transmitter Writes 2 Bytes to Slave Receiver
S Slave Address 1 st Byte W A Slave Address 2 nd Byte A WDATA1
WDATA2
A
AP
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)
44-12 Master Receiver Reads 2 Bytes from Slave Transmitter UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Master Receiver Reads 2 Bytes from Slave Transmitter
Read data1 = 0x55 and read data2 = 0x56.
Figure 44-8: Master Receiver Reads 2 Bytes from Slave Transmitter
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 elds are (don’t care) and programmed to 0.
I2C Serial Interface Connection
e core provides four ports for I2C serial connections. For external I2C serial connections, both sda_in
and sda_oe are connected to a bidirectional open drain I2C data line buer. Both scl_in and scl_oe are
connected to another bidirectional open drain I2C clock line buer. It is recommended to use the I/O
megafunction to generate the bidirectional open drain buer. You can then instantiates the generated
buer primitives from the megafunction into their system top level design le.
Figure 44-9: I2C Serial Interface Connection
Vdd
External pull
up resistor
Vdd
External pull
up resistor
sda_oe
sda_in
scl_oe
scl_in
1’b0
1’b0
Open drain bidirectional I/O buffer
Open drain bidirectional I/O buffer
I2C data Pad
I2C clock Pad
On chip Off chip
I2C data line
I2C clock line
UG-01085
2016.12.19 Master Receiver Reads 2 Bytes from Slave Transmitter 44-13
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Avalon-MM Slave Interface
e Avalon-MM slave interface is congured as follows:
• Bus width: 32-bit
• Burst support: No
• Fixed read & write wait time: 0 cycles
• Fixed read latency: 2 cycles
• Lock support: No
Figure 44-10: Write and Read Timing of Avalon-MM Slave Interface
clk
write
read
addr
writedata
readdata
wa0 ra0
wd0
rd0
Avalon-ST Interface
Both ST data source and ST data sink interfaces support a ready latency of zero.
Programming Model
e following owchart illustrates the recommended programming ow for the core.
44-14 Avalon-MM Slave Interface UG-01085
2016.12.19
Altera Corporation Altera Avalon I2C (Master) Core
Send Feedback
Figure 44-11: Programming Model Flowchart
Start
Start
Read RX_DATA register
Read
Write Yes
Disable Altera Avalon I2C (Master)
core through CTRL register
Configure ISER, SCL_LOW,
SCL_HIGH, SDA_HOLD register
Configure control bits and enable the Altera
Avalon I2C (Master) core through CTRL register
NO
YES
NO
YES
NO
NO
YES
TX_READY ==1 ?
TX_READY ==1
More transfers?
Write or Read
Transfer?
CORE_STATUS == 0
Disable Altera Avalon I2C (Master) core
through CTRL register
Write to TRF_CMD
register
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.
Document Revision History
Table 44-14: Altera Avalon I2C (Master) Core Revision History
Date Version Changes
October 2016 2016.10.28 Initial release
UG-01085
2016.12.19 Document Revision History 44-15
Altera Avalon I2C (Master) Core Altera Corporation
Send Feedback
Document Revision History A
2016.12.19
UG-01085 Subscribe Send Feedback
is section covers the revision history of the entire volume. For details regarding changes to a specic
chapter refer to each chapter revision history.
Table A-1: Embedded Peripherals IP User Guide Volume Revision History
Date Version Changes
December 2016 2016.12.19 Maintenance release.
October 2016 2016.10.28 New chapters:
• Altera Avalon I2C (Master) Core
Updated:
• 16550 UART Core
• Altera I2C Slave to Avalon-MM Master Bridge Core
June 2016 2016.06.17 New chapters:
• Avalon-MM DDR Memory Half Rate Bridge Core
Updated chapters:
• UART Core
• SPI Core
• Altera Interrupt Latency Counter Core
• Altera I2C Slave to Avalon-MM Master Bridge Core
May 2016 2016.05.03 New chapters:
• Altera I2C Slave to Avalon-MM Master Bridge Core
Updated chapters:
• Vectored Interrupt Controller Core
© 2016 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 in the US and/or other countries. Other marks and brands may be claimed as the property of others. Intel warrants
performance of its FPGA and semiconductor products to current specications in accordance with Intel's standard warranty, but reserves the right to make
changes to any products and services at any time without notice. Intel assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Intel. Intel customers are advised to obtain the latest version of
device specications before relying on any published information and before placing orders for products or services.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134
Date Version Changes
December 2015 2015.12.16 Removed chapters:
• PCI Lite Core
• Avalon-ST JTAG Interface Core
Updated chapters:
• 16550 UART Core
• PIO Core
• Altera Modular Scatter-Gather DMA Core
November 2015 2015.11.06 Removed chapters:
• Mailbox Core-Replaced with Altera Avalon Mailbox (simple)
Core on page 41-1
Updated chapters:
• 16550 UART Core
• Avalon-ST Bytes to Packets and Packets to Bytes Converter Cores
• Altera Modular Scatter-Gather DMA Core
• Vectored Interrupt Controller Core
• Altera GMII to RGMII Adapter Core
• Altera Avalon Mailbox (simple) Core
A-2 Document Revision History UG-01085
2016.12.19
Altera Corporation Document Revision History
Send Feedback
Date Version Changes
June 2015 2015.06.12 New chapters:
• Altera Quad SPI Controller Core
• Altera Serial Flash Controller Core
• Altera Avalon Mailbox Core
• Altera GMII to RGMII Adapter Core
Updated chapters:
• 16550 UART Core
• Performance Counter Core
• DMA Controller Core
• PIO Core
• Interval Timer Core
e following chapters have been reinserted:
• Avalon-ST Single-Clock and Dual-Clock FIFO Cores
• Avalon Streaming Channel Multiplexer and Demultiplexer Cores
• Avalon-ST Round Robin Scheduler Core
• Avalon-ST Delay Core
• Avalon-ST Splitter Core
• Avalon Streaming Test Pattern Generator and Checker Cores
• Avalon Streaming Data Pattern Generator and Checker Cores
e following chapters have been removed:
• Common Flash Interface Controller Core
• Cyclone III Remote Update Controller Core (No longer available
starting from V14.0)
UG-01085
2016.12.19 Document Revision History A-3
Document Revision History Altera Corporation
Send Feedback

Navigation menu