External Memory Interface Handbook Volume 3: Reference Material: For UniPHY-based Device Families

Download PDF
ID 683841
Date 3/06/2023
Public
Document Table of Contents
Document Table of Contents x
1. Functional Description—UniPHY 2. Functional Description— Intel® MAX® 10 EMIF IP 3. Functional Description—Hard Memory Interface 4. Functional Description—HPS Memory Controller 5. Functional Description—HPC II Controller 6. Functional Description—QDR II Controller 7. Functional Description—RLDRAM II Controller 8. Functional Description—RLDRAM 3 PHY-Only IP 9. Functional Description—Example Designs 10. Introduction to UniPHY IP 11. Latency for UniPHY IP 12. Timing Diagrams for UniPHY IP 13. External Memory Interface Debug Toolkit 14. Upgrading to UniPHY-based Controllers from ALTMEMPHY-based Controllers
1. Functional Description—UniPHY x
1.1. I/O Pads 1.2. Reset and Clock Generation 1.3. Dedicated Clock Networks 1.4. Address and Command Datapath 1.5. Write Datapath 1.6. Read Datapath 1.7. Sequencer 1.8. Shadow Registers 1.9. UniPHY Interfaces 1.10. UniPHY Signals 1.11. PHY-to-Controller Interfaces 1.12. Using a Custom Controller 1.13. AFI 3.0 Specification 1.14. Register Maps 1.15. Ping Pong PHY 1.16. Efficiency Monitor and Protocol Checker 1.17. UniPHY Calibration Stages 1.18. Document Revision History
1.5. Write Datapath x
1.5.1. Leveling Circuitry
1.7. Sequencer x
1.7.1. Nios® II-Based Sequencer 1.7.2. RTL-based Sequencer
1.7.1. Nios® II-Based Sequencer x
1.7.1.1. Nios® II-based Sequencer Function 1.7.1.2. Nios® II-based Sequencer Architecture 1.7.1.3. Nios® II-based Sequencer SCC Manager 1.7.1.4. Nios® II-based Sequencer RW Manager 1.7.1.5. Nios® II-based Sequencer PHY Manager 1.7.1.6. Nios® II-based Sequencer Data Manager 1.7.1.7. Nios® II-based Sequencer Tracking Manager 1.7.1.8. Nios® II-based Sequencer Processor 1.7.1.9. Nios® II-based Sequencer Calibration and Diagnostics
1.8. Shadow Registers x
1.8.1. Shadow Registers Operation
1.9. UniPHY Interfaces x
1.9.1. The DLL and PLL Sharing Interface 1.9.2. The OCT Sharing Interface
1.9.1. The DLL and PLL Sharing Interface x
1.9.1.1. Sharing PLLs or DLLs 1.9.1.2. About PLL Simulation
1.9.2. The OCT Sharing Interface x
1.9.2.1. Modifying the Pin Assignment Script for QDR II and RLDRAM II
1.13. AFI 3.0 Specification x
1.13.1. Bus Width and AFI Ratio 1.13.2. AFI Parameters 1.13.3. AFI Signals
1.13.3. AFI Signals x
1.13.3.1. AFI Clock and Reset Signals 1.13.3.2. AFI Address and Command Signals 1.13.3.3. AFI Write Data Signals 1.13.3.4. AFI Read Data Signals 1.13.3.5. AFI Calibration Status Signals 1.13.3.6. AFI Tracking Management Signals
1.14. Register Maps x
1.14.1. UniPHY Register Map 1.14.2. Controller Register Map
1.15. Ping Pong PHY x
1.15.1. Ping Pong PHY Feature Description 1.15.2. Ping Pong PHY Architecture 1.15.3. Ping Pong PHY Operation
1.15.2. Ping Pong PHY Architecture x
1.15.2.1. Ping Pong Gasket 1.15.2.2. Ping Pong PHY Calibration
1.16. Efficiency Monitor and Protocol Checker x
1.16.1. Efficiency Monitor 1.16.2. Protocol Checker 1.16.3. Read Latency Counter 1.16.4. Using the Efficiency Monitor and Protocol Checker 1.16.5. Avalon® CSR Slave and JTAG Memory Map
1.17. UniPHY Calibration Stages x
1.17.1. Calibration Overview 1.17.2. Calibration Stages 1.17.3. Memory Initialization 1.17.4. Stage 1: Read Calibration Part One—DQS Enable Calibration and DQ/DQS Centering 1.17.5. Stage 2: Write Calibration Part One 1.17.6. Stage 3: Write Calibration Part Two—DQ/DQS Centering 1.17.7. Stage 4: Read Calibration Part Two—Read Latency Minimization 1.17.8. Calibration Signals 1.17.9. Calibration Time
1.17.4. Stage 1: Read Calibration Part One—DQS Enable Calibration and DQ/DQS Centering x
1.17.4.1. Guaranteed Write 1.17.4.2. DQS Enable Calibration 1.17.4.3. Centering DQ/DQS
2. Functional Description— Intel® MAX® 10 EMIF IP x
2.1. Intel® MAX® 10 EMIF Overview 2.2. External Memory Protocol Support 2.3. Intel® MAX® 10 Memory Controller 2.4. Intel® MAX® 10 Low Power Feature 2.5. Intel® MAX® 10 Memory PHY 2.6. Calibration 2.7. Sequencer Debug Information 2.8. Register Maps 2.9. Document Revision History
2.5. Intel® MAX® 10 Memory PHY x
2.5.1. Supported Topologies 2.5.2. Read Datapath 2.5.3. Write Datapath 2.5.4. Address and Command Datapath 2.5.5. Sequencer
2.6. Calibration x
2.6.1. Read Calibration 2.6.2. Write Calibration
3. Functional Description—Hard Memory Interface x
3.1. Multi-Port Front End (MPFE) 3.2. Multi-port Scheduling 3.3. MPFE Signal Descriptions 3.4. Hard Memory Controller 3.5. Hard PHY 3.6. Document Revision History
3.2. Multi-port Scheduling x
3.2.1. Port Scheduling 3.2.2. DRAM Burst Scheduling 3.2.3. DRAM Power Saving Modes
3.4. Hard Memory Controller x
3.4.1. Clocking 3.4.2. Reset 3.4.3. DRAM Interface 3.4.4. ECC 3.4.5. Bonding of Memory Controllers
3.5. Hard PHY x
3.5.1. Interconnections 3.5.2. Clock Domains 3.5.3. Hard Sequencer 3.5.4. MPFE Setup Guidelines 3.5.5. Soft Memory Interface to Hard Memory Interface Migration Guidelines 3.5.6. Bonding Interface Guidelines
4. Functional Description—HPS Memory Controller x
4.1. Features of the SDRAM Controller Subsystem 4.2. SDRAM Controller Subsystem Block Diagram 4.3. SDRAM Controller Memory Options 4.4. SDRAM Controller Subsystem Interfaces 4.5. Memory Controller Architecture 4.6. Functional Description of the SDRAM Controller Subsystem 4.7. SDRAM Power Management 4.8. DDR PHY 4.9. Clocks 4.10. Resets 4.11. Port Mappings 4.12. Initialization 4.13. SDRAM Controller Subsystem Programming Model 4.14. Debugging HPS SDRAM in the Preloader 4.15. SDRAM Controller Address Map and Register Definitions 4.16. Document Revision History
4.4. SDRAM Controller Subsystem Interfaces x
4.4.1. MPU Subsystem Interface 4.4.2. L3 Interconnect Interface 4.4.3. CSR Interface 4.4.4. FPGA-to-HPS SDRAM Interface
4.5. Memory Controller Architecture x
4.5.1. Multi-Port Front End 4.5.2. Single-Port Controller
4.5.2. Single-Port Controller x
4.5.2.1. Command Generator 4.5.2.2. Timer Bank Pool 4.5.2.3. Arbiter 4.5.2.4. Rank Timer 4.5.2.5. Write Data Buffer 4.5.2.6. ECC Block 4.5.2.7. AFI Interface 4.5.2.8. CSR Interface
4.6. Functional Description of the SDRAM Controller Subsystem x
4.6.1. MPFE Operation Ordering 4.6.2. MPFE Multi-Port Arbitration 4.6.3. MPFE SDRAM Burst Scheduling 4.6.4. Single-Port Controller Operation
4.6.4. Single-Port Controller Operation x
4.6.4.1. Command and Data Reordering 4.6.4.2. Bank Policy 4.6.4.3. Write Combining 4.6.4.4. Burst Length Support 4.6.4.5. ECC 4.6.4.6. Interleaving Options 4.6.4.7. AXI-Exclusive Support 4.6.4.8. Memory Protection 4.6.4.9. Example of Configuration for TrustZone
4.6.4.5. ECC x
4.6.4.5.1. Byte Writes 4.6.4.5.2. ECC Write Backs 4.6.4.5.3. User Notification of ECC Errors
4.10. Resets x
4.10.1. Taking the SDRAM Controller Subsystem Out of Reset
4.12. Initialization x
4.12.1. FPGA-to-SDRAM Protocol Details
4.12.1. FPGA-to-SDRAM Protocol Details x
4.12.1.1. Avalon-MM Bidirectional Port 4.12.1.2. Avalon-MM Write-Only Port 4.12.1.3. Avalon-MM Read Port 4.12.1.4. AXI Port
4.13. SDRAM Controller Subsystem Programming Model x
4.13.1. HPS Memory Interface Architecture 4.13.2. HPS Memory Interface Configuration 4.13.3. HPS Memory Interface Simulation 4.13.4. Generating a Preloader Image for HPS with EMIF
4.13.4. Generating a Preloader Image for HPS with EMIF x
4.13.4.1. Creating a Project in Platform Designer (Standard) 4.13.4.2. Creating a Top-Level File and Adding Constraints
4.14. Debugging HPS SDRAM in the Preloader x
4.14.1. Enabling UART or Semihosting Printout 4.14.2. Enabling Simple Memory Test 4.14.3. Enabling the Debug Report 4.14.4. Writing a Predefined Data Pattern to SDRAM in the Preloader
4.14.3. Enabling the Debug Report x
4.14.3.1. Analysis of Debug Report
5. Functional Description—HPC II Controller x
5.1. HPC II Memory Interface Architecture 5.2. HPC II Memory Controller Architecture 5.3. HPC II Controller Features 5.4. External Interfaces 5.5. Top-Level Signals Description 5.6. Sequence of Operations 5.7. Document Revision History
5.2. HPC II Memory Controller Architecture x
5.2.1. Backpressure Support 5.2.2. Command Generator 5.2.3. Timing Bank Pool 5.2.4. Arbiter 5.2.5. Rank Timer 5.2.6. Read Data Buffer and Write Data Buffer 5.2.7. ECC Block 5.2.8. AFI and CSR Interfaces
5.3. HPC II Controller Features x
5.3.1. Data Reordering 5.3.2. Pre-emptive Bank Management 5.3.3. Quasi-1T and Quasi-2T 5.3.4. User Autoprecharge Commands 5.3.5. Address and Command Decoding Logic 5.3.6. Low-Power Logic 5.3.7. ODT Generation Logic 5.3.8. Burst Merging 5.3.9. ECC
5.3.9. ECC x
5.3.9.1. Partial Writes 5.3.9.2. Partial Bursts
5.4. External Interfaces x
5.4.1. Clock and Reset Interface 5.4.2. Avalon® -ST Data Slave Interface 5.4.3. AXI Data Slave Interface 5.4.4. Controller-PHY Interface 5.4.5. Memory Side-Band Signals 5.4.6. Controller External Interfaces
5.4.3. AXI Data Slave Interface x
5.4.3.1. Enabling the AXI Interface 5.4.3.2. AXI Interface Parameters 5.4.3.3. AXI Interface Ports
5.5. Top-Level Signals Description x
5.5.1. Clock and Reset Signals 5.5.2. Local Interface Signals 5.5.3. Controller Interface Signals 5.5.4. CSR Interface Signals 5.5.5. Soft Controller Register Map 5.5.6. Hard Controller Register Map
6. Functional Description—QDR II Controller x
6.1. Block Description 6.2. Avalon® -MM and Memory Data Width 6.3. Signal Descriptions 6.4. Document Revision History
6.1. Block Description x
6.1.1. Avalon® -MM Slave Read and Write Interfaces 6.1.2. Command Issuing FSM 6.1.3. AFI
7. Functional Description—RLDRAM II Controller x
7.1. Block Description 7.2. User-Controlled Features 7.3. Avalon® -MM and Memory Data Width 7.4. Signal Descriptions 7.5. Document Revision History
7.1. Block Description x
7.1.1. Avalon® -MM Slave Interface 7.1.2. Write Data FIFO Buffer 7.1.3. Command Issuing FSM 7.1.4. Refresh Timer 7.1.5. Timer Module 7.1.6. AFI
7.2. User-Controlled Features x
7.2.1. Error Detection Parity 7.2.2. User-Controlled Refresh
8. Functional Description—RLDRAM 3 PHY-Only IP x
8.1. Block Description 8.2. Features 8.3. RLDRAM 3 AFI Protocol 8.4. Document Revision History
9. Functional Description—Example Designs x
9.1. UniPHY-Based Example Designs 9.2. Document Revision History
9.1. UniPHY-Based Example Designs x
9.1.1. Synthesis Example Design 9.1.2. Simulation Example Design 9.1.3. Traffic Generator and BIST Engine 9.1.4. Creating and Connecting the UniPHY Memory Interface and the Traffic Generator in Platform Designer
9.1.3. Traffic Generator and BIST Engine x
9.1.3.1. Read and Write Generation 9.1.3.2. Address and Burst Length Generation 9.1.3.3. Traffic Generator Signals 9.1.3.4. Traffic Generator Add-Ons 9.1.3.5. Traffic Generator Timeout Counter
9.1.4. Creating and Connecting the UniPHY Memory Interface and the Traffic Generator in Platform Designer x
9.1.4.1. Notes on Configuring UniPHY IP in Platform Designer
10. Introduction to UniPHY IP x
10.1. Release Information 10.2. Device Support Levels 10.3. Device Family and Protocol Support 10.4. UniPHY-Based External Memory Interface Features 10.5. System Requirements 10.6. Intel® FPGA IP Core Verification 10.7. Resource Utilization 10.8. Document Revision History
10.7. Resource Utilization x
10.7.1. DDR2, DDR3, and LPDDR2 Resource Utilization in Arria V Devices 10.7.2. DDR2 and DDR3 Resource Utilization in Arria II GZ Devices 10.7.3. DDR2 and DDR3 Resource Utilization in Stratix III Devices 10.7.4. DDR2 and DDR3 Resource Utilization in Stratix IV Devices 10.7.5. DDR2 and DDR3 Resource Utilization in Arria V GZ and Stratix V Devices 10.7.6. QDR II and QDR II+ Resource Utilization in Arria V Devices 10.7.7. QDR II and QDR II+ Resource Utilization in Arria II GX Devices 10.7.8. QDR II and QDR II+ Resource Utilization in Arria II GZ, Arria V GZ, Stratix III, Stratix IV, and Stratix V Devices 10.7.9. RLDRAM II Resource Utilization in Arria® V Devices 10.7.10. RLDRAM II Resource Utilization in Arria®  II GZ, Arria® V GZ, Stratix®  III, Stratix®  IV, and Stratix® V Devices
11. Latency for UniPHY IP x
11.1. DDR2 SDRAM LATENCY 11.2. DDR3 SDRAM LATENCY 11.3. LPDDR2 SDRAM LATENCY 11.4. QDR II and QDR II+ SRAM Latency 11.5. RLDRAM II Latency 11.6. RLDRAM 3 Latency 11.7. Variable Controller Latency 11.8. Document Revision History
12. Timing Diagrams for UniPHY IP x
12.1. DDR2 Timing Diagrams 12.2. DDR3 Timing Diagrams 12.3. QDR II and QDR II+ Timing Diagrams 12.4. RLDRAM II Timing Diagrams 12.5. LPDDR2 Timing Diagrams 12.6. RLDRAM 3 Timing Diagrams 12.7. Document Revision History
13. External Memory Interface Debug Toolkit x
13.1. User Interface 13.2. Setup and Use 13.3. Operational Considerations 13.4. Troubleshooting 13.5. Debug Report for Arria V and Cyclone V SoC Devices 13.6. On-Chip Debug Port for UniPHY-based EMIF IP 13.7. Example Tcl Script for Running the Legacy EMIF Debug Toolkit 13.8. Document Revision History
13.1. User Interface x
13.1.1. Communication 13.1.2. Calibration and Report Generation
13.2. Setup and Use x
13.2.1. General Workflow 13.2.2. Linking the Project to a Device 13.2.3. Establishing Communication to Connections 13.2.4. Selecting an Active Interface 13.2.5. Reports
13.5. Debug Report for Arria V and Cyclone V SoC Devices x
13.5.1. Enabling the Debug Report for Arria V and Cyclone V SoC Devices 13.5.2. Determining the Failing Calibration Stage for a Cyclone V or Arria V HPS SDRAM Controller
13.6. On-Chip Debug Port for UniPHY-based EMIF IP x
13.6.1. Access Protocol 13.6.2. Command Codes Reference 13.6.3. Header Files 13.6.4. Generating IP With the Debug Port 13.6.5. Example C Code for Accessing Debug Data
14. Upgrading to UniPHY-based Controllers from ALTMEMPHY-based Controllers x
14.1. Generating Equivalent Design 14.2. Replacing the ALTMEMPHY Datapath with UniPHY Datapath 14.3. Resolving Port Name Differences 14.4. Creating OCT Signals 14.5. Running Pin Assignments Script 14.6. Removing Obsolete Files 14.7. Simulating your Design 14.8. Document Revision History
1. Functional Description—UniPHY
2. Functional Description— Intel® MAX® 10 EMIF IP
3. Functional Description—Hard Memory Interface
4. Functional Description—HPS Memory Controller
5. Functional Description—HPC II Controller
6. Functional Description—QDR II Controller
7. Functional Description—RLDRAM II Controller
8. Functional Description—RLDRAM 3 PHY-Only IP
9. Functional Description—Example Designs
10. Introduction to UniPHY IP
11. Latency for UniPHY IP
12. Timing Diagrams for UniPHY IP
13. External Memory Interface Debug Toolkit
14. Upgrading to UniPHY-based Controllers from ALTMEMPHY-based Controllers

5.5.2. Local Interface Signals

The following table lists the controller local interface signals.
Table 58.  Local Interface Signals

Signal Name

Direction

Description 

avl_addr[] (1)

Input

Memory address at which the burst should start. By default, the IP core maps local address to the bank interleaving scheme. You can change the ordering via the Local-to-Memory Address Mapping option in the Controller Settings page.

This signal must remain stable only during the first transaction of a burst. The constantBurstBehavior property is always false for UniPHY controllers.

The IP core sizes the width of this bus according to the following equations:

  • Full rate controllers:

For one chip select: width = row bits + bank bits + column bits – 1

For multiple chip selects: width = chip bits* + row bits + bank bits + column bits – 1

If the bank address is 2 bits wide, row is 13 bits wide and column is 10 bits wide, the local address is 24 bits wide. To map local_address to bank, row and column address: 

avl_addr  is 24 bits wide
avl_addr[23:11]= row address[12:0]
avl_addr[10:9] = bank address [1:0]
avl_addr[8:0] = column address[9:1]

The IP core ignores the least significant bit (LSB) of the column address (multiples of two) on the memory side, because the local data width is twice that of the memory data bus width.

  • Half rate controllers:

For one chip select: width = row bits + bank bits + column bits – 2

For multiple chip selects: width = chip bits* + row bits + bank bits + column bits – 2

If the bank address is 2 bits wide, row is 13 bits wide and column is 10 bits wide, the local address is 23 bits wide. To map local_address to bank, row and column address: 

avl_addr is 23 bits wide
avl_addr[22:10] = row address[12:0]
avl_addr[9:8] = bank address [1:0]
avl_addr[7:0] = column address[9:2]

The IP core ignores two LSBs of the column address (multiples of four) on the memory side, because the local data width is four times that of the memory data bus width.

  • Quarter rate controllers:

For one chip select: width = row bits + bank bits + column bits – 3

For multiple chip selects: width = chip bits* + row bits + bank bits + column bits – 3

If the bank address is 2 bits wide, row is 13 bits wide and column is 10 bits wide, the local address is 22 bits wide.

(* chip bits is a derived value indicating the number of address bits necessary to uniquely address every memory rank in the system; this value is not user configurable.)

  • Full-rate hard memory controllers (Arria V and Cyclone V):

For one chip select: width = row bits + bank bits + column bits - log2(local avalon data width/memory DQ width)

For multiple chip selects: width = chip bits* + row bits + bank bits + column bits - log2(local avalon data width/memory data width)

If the local Avalon data width is 32, the memory DQ width is 8, the bank address is 3 bits wide, the row is 12 bits wide and the column is 8 bits wide, the local address is 21 bits wide. To map local_address to bank, row and column address:

avl_addr is 21 bits wide

avl_addr[20:9] = row address[11:0]

avl_addr[8:6] = bank address [2:0]

avl_addr[5:0] = column address[7:2]

The IP core ignores the two least significant bits of the column address on the memory side because the local data width is four times that of the memory data bus width (Multi-Port Frontend). 

avl_be[]   (2)

Input

Byte enable signal, which you use to mask off individual bytes during writes. avl_be is active high; mem_dm is active low.

The controller supports any combination of byte enables which translate directly through to the memory interface data mask (DM) signals.

To map avl_wdata and avl_be to mem_dq and mem_dm, consider a full-rate design with 32-bit avl_wdata and 16-bit mem_dq. 

avl_wdata = < 22334455 >< 667788AA >< BBCCDDEE>
avl_be = < 1100 >< 0110 >< 1010  >

These values map to: 

Mem_dq = <4455><2233><88AA><6677><DDEE><BBCC>
Mem_dm = <1 1 ><0 0 ><0 1 ><1 0 ><0 1 ><0 1 >
 
avl_burstbegin (3)

Input

The Avalon burst begin strobe, which indicates the beginning of an Avalon burst. Unlike all other Avalon-MM signals, the burst begin signal is not dependant on avl_ready.

For write transactions, assert this signal at the beginning of each burst transfer and keep this signal high for one cycle per burst transfer, even if the slave deasserts avl_ready. The IP core samples this signal at the rising edge of phy_clk when avl_write_req is asserted. After the slave deasserts the avl_ready signal, the master keeps all the write request signals asserted until avl_ready signal becomes high again.

For read transactions, assert this signal for one clock cycle when read request is asserted and avl_addr from which the data should be read is given to the memory. After the slave deasserts avl_ready (waitrequest_n in Avalon interface), the master keeps all the read request signals asserted until avl_ready becomes high again. 

avl_read_req  (4)

Input

Read request signal. You cannot assert read request and write request signals at the same time. The controller must deassert reset_phy_clk_n before you can assert avl_read_req. 

local_refresh_req

Input

User-controlled refresh request. If Enable User Auto-Refresh Controls option is turned on, local_refresh_req becomes available and you are responsible for issuing sufficient refresh requests to meet the memory requirements. This option allows complete control over when refreshes are issued to the memory including grouping together multiple refresh commands. Refresh requests take priority over read and write requests, unless the IP core is already processing the requests. 

local_refresh_chip

Input

Controls which chip to issue the user refresh to. The IP core uses this active high signal with local_refresh_req. This signal is as wide as the memory chip select. This signal asserts a high value to each bit that represents the refresh for the corresponding memory chip.

For example: If local_refresh_chip signal is assigned with a value of 4’b0101, the controller refreshes the memory chips 0 and 2, and memory chips 1 and 3 are not refreshed. 

avl_size[] (5)

Input

Controls the number of beats in the requested read or write access to memory, encoded as a binary number. In UniPHY, the IP core supports Avalon burst lengths from 1 to 1024. The IP core derives the width of this signal based on the burst count that you specify in the Maximum Avalon-MM burst length option. With the derived width, you specify a value ranging from 1 to the local maximum burst count specified.

This signal must remain stable only during the first transaction of a burst. The constantBurstBehavior property is always false for UniPHY controllers. 

avl_wdata[] (6)

Input

Write data bus. The width of avl_wdata is twice that of the memory data bus for a full-rate controller, four times the memory data bus for a half-rate controller, and eight times the memory data bus for a quarter-rate controller. If Generate power-of-2 data bus widths for Platform Designer and SOPC Builder is enabled, the width is rounded down to the nearest power of 2. 

avl_write_req (7)

Input

Write request signal. You cannot assert read request and write request signal at the same time. The controller must deassert reset_phy_clk_n before you can assert avl_write_req. 

local_autopch_req (8)

Input

User control of autoprecharge. If you turn on Enable Auto- Precharge Control, the local_autopch_req signal becomes available and you can request the controller to issue an autoprecharge write or autoprecharge read command.

These commands cause the memory to issue a precharge command to the current bank at the appropriate time without an explicit precharge command from the controller. This feature is particularly useful if you know the current read or write is the last one you intend to issue to the currently open row. The next time you need to use that bank, the access could be quicker as the controller does not need to precharge the bank before activating the row you wish to access.

Upon receipt of the local_autopch_req signal, the controller evaluates the pending commands in the command buffer and determines the most efficient autoprecharge operation to perform, reordering commands if necessary.

The controller must deassert reset_phy_clk_n before you can assert local_autopch_req. 

local_self_rfsh_chip

Input

Controls which chip to issue the user refresh to. The IP core uses this active high signal with local_self_rfsh_req. This signal is as wide as the memory chip select. This signal asserts a high value to each bit that represents the refresh for the corresponding memory chip.

For example: If local_self_rfsh_chip signal is assigned with a value of 4’b0101, the controller refreshes the memory chips 0 and 2, and memory chips 1 and 3 are not refreshed. 

local_self_rfsh_req

Input

User control of the self-refresh feature. If you turn on Enable Self-Refresh Controls, you can request that the controller place the memory devices into a self-refresh state by asserting this signal. The controller places the memory in the self-refresh state as soon as it can without violating the relevant timing parameters and responds by asserting local_self_rfsh_ack. You can hold the memory in the self-refresh state by keeping this signal asserted. You can release the memory from the self-refresh state at any time by deasserting local_self_rfsh_req and the controller responds by deasserting local__self_rfsh_ack when it has successfully brought the memory out of the self-refresh state. 

local_init_done

Output

When the memory initialization, training, and calibration are complete, the PHY sequencer asserts ctrl_usr_mode_rdy to the memory controller, which then asserts this signal to indicate that the memory interface is ready for use. 

local_cal_success

Output

When the memory initialization, training, and calibration completes successfully, the controller asserts this signal coincident with local_init_done to indicate the memory interface is ready for use. 

local_cal_fail

Output

When the memory initialization, training, or calibration fails, the controller asserts this signal to indicate that calibration failed. The local_init_done signal will not assert when local_cal_fail asserts. 

avl_rdata[] (9)

Output

Read data bus. The width of avl_rdata is twice that of the memory data bus for a full rate controller; four times the memory data bus for a half rate controller. If Generate power-of-2 data bus widths for Platform Designer and SOPC Builder is enabled, the width is rounded down to the nearest power of 2. 

avl_rdata_error (10)

Output

Asserted if the current read data has an error. This signal is only available if you turn on Enable Error Detection and Correction Logic. The controller asserts this signal with the avl_rdata_valid signal.

If the controller encounters double-bit errors, no correction is made and the controller asserts this signal. 

avl_rdata_valid (11)

Output

Read data valid signal. The avl_rdata_valid signal indicates that valid data is present on the read data bus. 

avl_ready (12)

Output

The avl_ready signal indicates that the controller is ready to accept request signals. If controller asserts the avl_ready signal in the clock cycle that it asserts a read or write request, the controller accepts that request. The controller deasserts the avl_ready signal to indicate that it cannot accept any more requests. The controller can buffer eight read or write requests, after which the avl_ready signal goes low.

The avl_ready signal is deasserted when any of the following are true:

  • The Timing bank Pool is full.
  • The FIFO register that stores read data from the memory device is full.
  • The write data FIFO register is full.
  • The controller is waiting for write data when in ECC mode. 
local_refresh_ack

Output

Refresh request acknowledge, which the controller asserts for one clock cycle every time it issues a refresh. Even if you do not turn on Enable User Auto-Refresh Controls, local_refresh_ack still indicates to the local interface that the controller has just issued a refresh command. 

local_self_rfsh_ack

Output

Self refresh request acknowledge signal. The controller asserts and deasserts this signal in response to the local_self_rfsh_req signal. 

local_power_down_ack

Output

Auto power-down acknowledge signal. The controller asserts this signal for one clock cycle every time auto power-down is issued. 

ecc_interrupt (13)

Output

Interrupt signal from the ECC logic. The controller asserts this signal when the ECC feature is turned on, and the controller detects an error.

Notes to Table:

  1. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_addr becomes a per port value, avl_addr_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  2. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_be becomes a per port value, avl_be_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  3. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_burstbegin becomes a per port value, avl_burstbegin_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  4. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_read_req becomes a per port value, avl_read_req_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  5. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_size becomes a per port value, avl_size_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  6. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_wdata becomes a per port value, avl_wdata_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  7. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_write_req becomes a per port value, avl_write_req_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  8. This signal is not applicable to the hard memory controller.
  9. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_rdata becomes a per port value, avl_rdata_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  10. This signal is not applicable to the hard memory controller.
  11. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_rdata_valid becomes a per port value, avl_rdata_valid_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  12. For the hard memory controller with multiport front end available in Arria V and Cyclone V devices, avl_ready becomes a per port value, avl_ready_#, where # is a numeral from 0–5, based on the number of ports selected in the Controller tab.
  13. This signal is not applicable to the hard memory controller.
Level Two Title