The following figure shows the design flow to provide the fastest out-of-the-box experience with the EMIF IP.

The I/O subsystem provides the following features:

• General-purpose I/O registers and I/O buffers
• On-chip termination control (OCT)
• I/O PLLs for external memory interfaces and user logic
• Low-voltage differential signaling (LVDS)
• External memory interface components, as follows:
  • Hard memory controller
  • Hard PHY
  • Hard Nios processor and calibration logic
  • DLL

• A hardened Nios processor with dedicated memory. This Nios block is referred to as the I/O SSM.
• Up to 13 I/O banks. Each I/O bank contains the hardware necessary for an external memory interface.

The I/O SSM includes dedicated memory which stores both the calibration algorithm and calibration run-time data. The hardened Nios II processor and the dedicated memory can be used only by an external memory interface, and cannot be employed for any other use. The I/O SSM can interface with soft logic, such as the debug toolkit, via an Avalon-MM bus.

The I/O SSM is clocked by an on-die oscillator, and therefore does not consume a PLL.

Each I/O bank resides in an I/O column, and contains the following components:

• Hard memory controller
• Sequencer components
• PLL and PHY clock trees
• DLL
• Input DQS clock trees
• 48 pins, organized into four I/O lanes of 12 pins each

I/O Bank Usage

The pins in an I/O bank can serve as address and command pins, data pins, or clock and strobe pins for an external memory interface. You can implement a narrow interface, such as a DDR3 or DDR4 x8 interface, with only a single I/O bank. A wider interface, such as x72 or x144, can be implemented by configuring multiple adjacent banks in a multi-bank interface. Any pins in a bank which are not used by the external memory interface remain available for use as general purpose I/O pins (of the same voltage standard).

Every I/O bank includes a hard memory controller which you can configure for DDR3, DDR4, or LPDDR3. In a multi-bank interface, only the controller of one bank is active; controllers in the remaining banks are turned off to conserve power.

To use a multi-bank Intel^® Stratix^® 10 EMIF interface, you must observe the following rules:

• Designate one bank as the address and command bank.
• The address and command bank must contain all the address and command pins.
• The locations of individual address and command pins within the address and command bank must adhere to the pin map defined in the pin table— regardless of whether you use the hard memory controller or not.
• If you do use the hard memory controller, the address and command bank contains the active hard controller.

All the I/O banks in a column are capable of functioning as the address and command bank. However, for minimal latency, you should select the center-most bank of the interface as the address and command bank.

Each I/O lane can implement one x8/x9 read capture group (DQS group), with two pins functioning as the read capture clock/strobe pair (DQS/DQS#), and up to 10 pins functioning as data pins (DQ and DM pins). To implement x18 and x36 groups, you can use multiple lanes within the same bank.

It is also possible to implement a pair of x4 groups in a lane. In this case, four pins function as clock/strobe pair, and 8 pins function as data pins. DM is not available for x4 groups. There must be an even number of x4 groups for each interface.

For x4 groups, DQS0 and DQS1 must be placed in the same I/O lane as a pair. Similarly, DQS2 and DQS3 must be paired. In general, DQS(x) and DQS(x+1) must be paired in the same I/O lane.

You can configure an input DQS clock tree in x4 mode, x8/x9 mode, x18 mode, or x36 mode.

Within every bank, only certain physical pins at specific locations can drive the input DQS clock trees. The pin locations that can drive the input DQS clock trees vary, depending on the size of the group.

The relatively short span of the PHY clock trees results in low jitter and low duty-cycle distortion, maximizing the data valid window.

The PHY clock tree in Intel^® Stratix^® 10 devices can run as fast as 1.3 GHz. All Intel^® Stratix^® 10 external memory interfaces use the PHY clock trees.

Intel^® Stratix^® 10 external memory interfaces that span multiple banks use the PLL in each bank. The Intel^® Stratix^® 10 architecture allows for relatively short PHY clock networks, reducing jitter and duty-cycle distortion.

The following mechanisms ensure that the clock outputs of individual PLLs in a multi-bank interface remain in phase:

• A single PLL reference clock source feeds all PLLs. The reference clock signal reaches the PLLs by a balanced PLL reference clock tree. The Intel^® Quartus^® Prime software automatically configures the PLL reference clock tree so that it spans the correct number of banks.
• The EMIF IP sets the PLL M and N values appropriately to maintain synchronization among the clock dividers across the PLLs. This requirement restricts the legal PLL reference clock frequencies for a given memory interface frequency and clock rate. The Stratix 10 EMIF IP parameter editor automatically calculates and displays the set of legal PLL reference clock frequencies. If you plan to use an on-board oscillator, you must ensure that its frequency matches the PLL reference clock frequency that you select from the displayed list. The correct M and N values of the PLLs are set automatically based on the PLL reference clock frequency that you select.

The clock phase alignment feature effectively eliminates the clock skew effect in all transfers between the core and the periphery, facilitating timing closure. All Stratix 10 external memory interfaces employ clock phase alignment circuitry.

Figure 11. Effect of Clock Phase Alignment

The stages of calibration vary, depending on the protocol of the external memory interface.

Address and Command Calibration

The goal of address and command calibration is to delay address and command signals as necessary to optimize the address and command window. This stage is not available for all protocols, and cannot compensate for an inefficient board design.

Read Calibration

Read calibration consists of the following parts:

• DQSen calibration— Calibrates the timing of the read capture clock gating and ungating, so that the PHY can gate and ungate the read clock at precisely the correct time—if too early or too late, data corruption can occur. The algorithm for this stage varies, depending on the memory protocol.
• Deskew calibration— Performs per-bit deskew of read data relative to the read strobe or clock.
• VREF-In calibration— Calibrates the VREF level at the FPGA.
• LFIFO calibration: Normalizes differences in read delays between groups due to fly-by, skews, and other variables and uncertainties.

Write Calibration

Write calibration consists of the following parts:

• Leveling calibration— Aligns the write strobe and clock to the memory clock, to compensate for skews, especially those associated with fly-by topology. The algorithm for this stage varies, depending on the memory protocol.
• Deskew calibration— Performs per-bit deskew of write data relative to the write strobe and clock.
• VREF-Out calibration— Calibrates the VREF level at the memory device.

Address and Command Calibration

• Leveling calibration— (DDR3 and DDR4 only) Toggles the CS# and CAS# signals to send read commands while keeping other address and command signals constant. The algorithm monitors for incoming DQS signals, and if the DQS signal toggles, it indicates that the read commands have been accepted. The algorithm then repeats using different delay values, to find the optimal window.

• Deskew calibration— (DDR4, QDR-IV, and LPDDR3 only)
  • (DDR4) Uses the DDR4 address and command parity feature. The FPGA sends the address and command parity bit, and the DDR4 memory device responds with an alert signal if the parity bit is detected. The alert signal from the memory device tells the FPGA that the parity bit was received.

    Deskew calibration requires use of the PAR/ALERT# pins, so you should not omit these pins from your design. One limitation of deskew calibration is that it cannot deskew ODT and CKE pins.

  • (QDR-IV) Uses the QDR-IV loopback mode. The FPGA sends address and command signals, and the memory device sends back the address and command signals which it captures, via the read data pins. The returned signals indicate to the FPGA what the memory device has captured. Deskew calibration can deskew all synchronous address and command signals.
  • (LPDDR3) Uses the LPDDR3 CA training mode. The FPGA sends signals onto the LPDDR3 CA bus, and the memory device sends back those signals that it captures, via the DQ pins. The returned signals indicate to the FPGA what the memory device has captured. Deskew calibration can deskew all signals on the CA bus. The remaining command signals (CS, CKE, and ODT) are calibrated based on the average of the deskewed CA bus.

Read Calibration

• DQSen calibration— (DDR3, DDR4, LPDDR3, RLDRAMx and QDRx) DQSen calibration occurs before Read deskew, therefore only a single DQ bit is required to pass in order to achieve a successful read pass.
  • (DDR3, DDR4,and LPDDR3) The DQSen calibration algorithm searches the DQS preamble using a hardware state machine. The algorithm sends many back-to-back reads with a one clock cycle gap between. The hardware state machine searches for the DQS gap while sweeping DQSen delay values. the algorithm then increments the VFIFO value, and repeats the process until a pattern is found. The process is then repeated for all other read DQS groups.

  • (RLDRAMx and QDRx) The DQSen calibration algorithm does not use a hardware state machine; rather, it calibrates cycle-level delays using software and subcycle delays using DQS tracking hardware. The algorithm requires good data in memory, and therefore relies on guaranteed writes. (Writing a burst of 0s to one location, and a burst of 1s to another; back-to-back reads from these two locations are used for read calibration.)

    The algorithm enables DQS tracking to calibrate the phase component of DQS enable, and then issues a guaranteed write, followed by back-to-back reads. The algorithm sweeps DQSen values cycle by cycle until the read operation succeeds. The process is then repeated for all other read groups.

• Deskew calibration— Read deskew calibration is performed before write leveling, and must be performed at least twice: once before write calibration, using simple data patterns from guaranteed writes, and again after write calibration, using complex data patterns.

  The deskew calibration algorithm performs a guaranteed write, and then sweeps dqs_in delay values from low to high, to find the right edge of the read window. The algorithm then sweeps dq-in delay values low to high, to find the left edge of the read window. Updated dqs_in and dq_in delay values are then applied to center the read window. The algorithm then repeats the process for all data pins.

• Vref-In calibration— Read Vref-In calibration begins by programming Vref-In with an arbitrary value. The algorithm then sweeps the Vref-In value from the starting value to both ends, and measures the read window for each value. The algorithm selects the Vref-In value which provides the maximum read window.

• LFIFO calibration— Read LFIFO calibration normalizes read delays between groups. The PHY must present all data to the controller as a single data bus. The LFIFO latency should be large enough for the slowest read data group, and large enough to allow proper synchronization across FIFOs.

Write Calibration

• Leveling calibration— Write leveling calibration aligns the write strobe and clock to the memory clock, to compensate for skews. In general, leveling calibration tries a variety of delay values to determine the edges of the write window, and then selects an appropriate value to center the window. The details of the algorithm vary, depending on the memory protocol.
  • (DDRx, LPDDR3) Write leveling occurs before write deskew, therefore only one successful DQ bit is required to register a pass. Write leveling staggers the DQ bus to ensure that at least one DQ bit falls within the valid write window.
  • (RLDRAMx) Optimizes for the CK versus DK relationship.
  • (QDR-IV) Optimizes for the CK versus DK relationship. Is covered by address and command deskew using the loopback mode.
  • (QDR II/II+/Xtreme) The K clock is the only clock, therefore write leveling is not required.
• Deskew calibration— Performs per-bit deskew of write data relative to the write strobe and clock. Write deskew calibration does not change dqs_out delays; the write clock is aligned to the CK clock during write leveling.

• VREF-Out calibration— (DDR4) Calibrates the VREF level at the memory device. The VREF-Out calibration algorithm is similar to the VREF-In calibration algorithm.

To facilitate timing closure, you may choose to clock your core user logic at quarter-rate, resulting in easier timing closure at the expense of increased area and latency. To improve efficiency and help reduce overall latency, you can run the hard memory controller and PHY at half rate.

The rate conversion feature converts traffic from the FPGA core to the hard memory controller from quarter-rate to half-rate, and traffic from the hard memory controller to the FPGA core from half-rate to quarter-rate. From the perspective of user logic inside the FPGA core, the effect is the same as if the hard memory controller were running at quarter-rate.

The rate conversion feature is enabled automatically during IP generation whenever all of the following conditions are met:

• The hard memory controller is in use.
• User logic runs at quarter-rate.
• The interface targets either an ES2 or production device.
• Running the hard memory controller at half-rate dpoes not exceed the fMax specification of the hard memory controller and hard PHY.

When the rate conversion feature is enabled, you should see the following info message displayed in the IP generation GUI:

When a column contains multiple memory interfaces, the hard Nios-II processor calibrates each interface serially. Interfaces placed within the same I/O column always share the same I/O SSM. The Intel^® Quartus^® Prime Fitter handles I/O SSM sharing automatically.

Rules for Sharing I/O Banks

• A bank cannot serve as the address and command bank for more than one interface. This means that lanes which implement address and command pins for different interfaces cannot be allocated to the same physical bank.
  Note: An exception to the above rule exists when two interfaces are configured in a Ping-Pong PHY fashion. In such a configuration, two interfaces share the same set of address and command pins, effectively meaning that they share the same address and command tile.
• Pins within a lane cannot be shared by multiple memory interfaces.
• Pins that are not used by EMIF IP can serve as general-purpose I/Os of compatible voltage and termination settings.
• You can configure a bank as LVDS or as EMIF, but not both at the same time.
• Interfaces that share banks must reside at adjacent bank locations.

The following diagram illustrates two x16 interfaces sharing an I/O bank. The two interfaces share the same clock phase alignment block, so that one core clock signal can interact with both interfaces. Without sharing, the two interfaces would occupy a total of four physical banks instead of three.

To share a PLL reference clock, the following requirements must be met:

• Interfaces must expect a reference clock signal of the same frequency.
• Interfaces must be placed in the same column.
• Interfaces must be placed at adjacent bank locations.

You might want to share core clock networks for the following reasons:

• To minimize the area and latency penalty associated with clock domain crossing.
• To minimize consumption of core clock networks.

Multiple memory interfaces can share the same core clock signals under the following conditions:

• The memory interfaces have the same protocol, rate, frequency, and PLL reference clock source.
• The interfaces reside in the same I/O column.
• The interfaces reside in adjacent bank locations.

For multiple memory interfaces to share core clocks, you must specify one of the interfaces as master and the remaining interfaces as slaves. Use the Core clocks sharing setting in the parameter editor to specify the master and slaves.

In your RTL, connect the clks_sharing_master_out signal from the master interface to the clks_sharing_slave_in signal of all the slave interfaces. Both the master and slave interfaces expose their own output clock ports in the RTL (e.g. emif_usr_clk, afi_clk), but the signals are equivalent, so it does not matter whether a clock port from a master or a slave is used.

Core clock sharing necessitates PLL reference clock sharing; therefore, only the master interface exposes an input port for the PLL reference clock. All slave interfaces use the same PLL reference clock signal.

Method for Initiating a User-requested Reset

Step 1 - Precondition

Before asserting local_reset_req, user logic must ensure that the local_reset_done signal is high.

As part of the device power-on sequence, the local_reset_done signal automatically transitions to high upon the completion of the interface calibration sequence, regardless of whether calibration is successful or not.

Step 2 - Reset Request

After the pre-condition is satisfied, user logic can send a reset request by driving the local_cal_req signal from low to high and then low again (that is, by sending a pulse of 1).

• The 0-to-1 and 1-to-0 transitions need not happen in relation to any clock edges (that is, they can occur asynchronously); however, the pulse must meet a minimum pulse width of at least 2 EMIF core clock cycles. For example, if the emif_usr_clk has a period of 4ns, then the local_reset_req pulse must last at least 8ns (that is, two emif_usr_clk periods).
• The reset request is considered complete only after the 1-to-0 transition. The EMIF IP does not initiate the reset sequence when the local_reset_req is simply held high.
• Additional pulses to local_reset_req are ignored until the reset sequence is completed.

Optional - Detecting local_reset_done deassertion and assertion

If you want, you can monitor the status of the local_reset_done signal to to explicitly detect the status of the reset sequence.

• After the EMIF IP receives a reset request, it deasserts the local_reset_done signal. After initial power-up calibration, local_reset_done is de-asserted only in response to a user-requested reset. The reset sequence is imminent when local_reset_done has transitioned to low, although the exact timing depends on the current state of the I/O SSM. As part of the EMIF reset sequence, the core reset signal (emif_usr_reset_n, afi_reset_n) is driven low. Do not use a register reset by the core reset signal to sample local_reset_done.
• After the reset sequence has completed, local_reset_done is driven high again. local_reset_done being driven high indicates the completion of the reset sequence and the readiness to accept a new reset request; however, it does not imply that calibration was successful or that the hard memory controller is ready to accept requests. For these purposes, user logic must check signals such as afi_cal_success, afi_cal_fail, and amm_ready.

To enable connectivity between the Intel^® Stratix^® 10 HPS and the Intel^® Stratix^® 10 EMIF IP, you must create and configure an instance of the Intel^® Stratix^® 10 External Memory Interface for HPS IP core, and use Platform Designer to connect it to the Intel^® Stratix^® 10 Hard Processor Subsystem instance in your system.

Supported Modes

The Intel^® Stratix^® 10 Hard Processor Subsystem is compatible with the following external memory configurations:

The restrictions on I/O bank usage result from the Intel^® Stratix^® 10 HPS having hard-wired connections to the EMIF circuits in the I/O banks closest to the HPS. For any given EMIF configuration, the pin-out of the EMIF-to-HPS interface is fixed.

The following diagram illustrates the use of I/O banks and lanes for various EMIF-HPS data widths:

The HPS EMIF uses the closest located external memory interfaces I/O banks to connect to SDRAM. These banks include:

• Bank 2N—used for data I/Os (Data bits 31:0)
• Bank 2M—used for address, command and ECC data I/Os
• Bank 2L—used for data I/Os (Data bits 63:32)

If no HPS EMIF is used in a system, the entire HPS EMIF bank can be used as FPGA GPIO. If there is a HPS EMIF in a system, the unused HPS EMIF pins can be used as FPGA general I/O with restrictions:

By default, the Intel^® Stratix^® 10 External Memory Interface for HPS IP core together with the Intel^® Quartus^® Prime Fitter automatically implement the correct pin-out for HPS EMIF without you having to apply additional constraints. If you must modify the default pin-out for any reason, you must adhere to the following requirements, which are specific to HPS EMIF:

1. Within a single data lane (which implements a single x8 DQS group):
   • DQ pins must use pins at indices 1, 2, 3, 6, 7, 8, 9, 10. You may swap the locations between the DQ bits (that is, you may swap location of DQ[0] and DQ[3]) so long as the resulting pin-out uses pins at these indices only.
   • DM/DBI pin must use pin at index 11. There is no flexibility.
   • DQS/DQS# must use pins at index 4 and 5. There is no flexibility.
2. Assignment of data lanes must be as illustrated in the above figure. You are allowed to swap the locations of entire byte lanes (that is, you may swap locations of byte 0 and byte 3) so long as the resulting pin-out uses only the lanes permitted by your HPS EMIF configuration, as shown in the above figure.
3. You must not change placement of the address and command pins from the default.
4. You may place the alert# pin at any available pin location in either a data lane or an address and command lane.

To override the default generated pin assignments, comment out the relevant HPS_LOCATION assignments in the .qip file, and add your own location assignments (using set_location_assignment) in the .qsf file.

In Intel^® Stratix^® 10 EMIF, Ping Pong PHY supports both half-rate and quarter-rate interfaces for DDR3, and quarter-rate for DDR4.

With the Ping Pong PHY, address and command signals from two independent controllers are multiplexed onto shared buses by delaying one of the controller outputs by one full-rate clock cycle. The result is 1T timing, with a new command being issued on each full-rate clock cycle. The following figure shows address and command timing for the Ping Pong PHY.

The command signals CS, ODT, and CKE have two signals (one for ping and one for pong); the other address and command signals are shared.

The hard memory controller I/O bank of the primary interface is used for address and command and is always adjacent and above the hard memory controller bank of the secondary interface. All four lanes of the primary hard memory controller bank are used for address and command.

The following example shows a 2x16 Ping Pong PHY bank-lane configuration. The upper bank (I/O bank N) is the address and command bank, which serves both the primary and secondary interfaces. The primary hard memory controller is linked to the secondary interface by the Ping Pong bus. The lower bank (I/O bank N-1) is the secondary interface bank, which carries the data buses for both primary and secondary interfaces. In the 2x16 case a total of four I/O banks are required for data, hence two banks in total are sufficient for the implementation.

The data for the primary interface is routed down to the top two lanes of the secondary I/O bank, and the data for the secondary interface is routed to the bottom two lanes of the secondary I/O bank.

A 2x32 interface can be implemented similarly, with the additional data lanes placed above and below the primary and secondary I/O banks, such that primary data lanes are placed above the primary bank and secondary data lanes are placed below the secondary bank.

Ping Pong PHY uses all lanes of the address and command I/O bank as address and command. For information on the pin allocations of the DDR3 and DDR4 address and command I/O bank, refer to DDR3 Scheme 1 and DDR4 Scheme 3, in External Memory Interface Pin Information for Stratix 10 Devices, on www.altera.com.

An additional limitation is that I/O lanes may be left unused when you instantiate multiple pairs of Ping Pong PHY interfaces. The following diagram shows two pairs of x8 Pin Pong controllers (a total of 4 interfaces). Lanes highlighted in yellow are not driven by any memory interfaces (unused lanes and pins can still serve as general purpose I/Os). Even with some I/O lanes left unused, the Ping Pong PHY approach is still beneficial in terms of resource usage, compared to independent interfaces. Memory widths of 24 bits and 40 bits have a similar situation, while 16 bit, 32 bit, and 64 bit memory widths do not suffer this limitation.

Calibration of a Ping Pong PHY interface incorporates two sequencers, one on the primary hard memory controller I/O bank, and one on the secondary hard memory controller I/O bank. To ensure that the two sequencers issue instructions on the same memory clock cycle, the Nios II processor configures the sequencer on the primary hard memory controller to receive a token from the secondary interface, ignoring any commands from the Avalon bus. Additional delays are programmed on the secondary interface to allow for the passing of the token from the sequencer on the secondary hard memory controller tile to the sequencer on the primary hard memory controller tile. During calibration, the Nios II processor assumes that commands are always issued from the sequencer on the primary hard memory controller I/O bank. After calibration, the Nios II processor adjusts the delays for use with the primary and secondary hard memory controllers.

Functionally, the IP interfaces with user traffic separately, as it would with two independent memory interfaces. You can also generate synthesizable example designs, where the external memory interface IP interfaces with a traffic generator.

The SmartVID controller allows the FPGA to operate at a reduced V_cc, while maintaining performance. Because the SmartVID controller can adjust V_cc up or down in response to power requirements and temperature, it can have an impact on external memory interface performance. When used with the SmartVID controller, the EMIF IP implements a handshake protocol to ensure that EMIF calibration does not begin until after voltage adjustment has completed.

In extended speed grade devices, voltage adjustment occurs once when the FPGA is powered up, and no further voltage adjustments occur. The external memory calibration occurs after this initial voltage adjustment is completed. EMIF specifications are expected to be slightly lower in extended speed grade devices using SmartVID, than in devices not using SmartVID.

In industrial speed grade devices, voltage adjustment occurs at power up, and may also occur during operation, in response to temperature changes. External memory interface calibration does not occur until after the initial voltage adjustment at power up. However, the external memory interface is not recalibrated in response to subsequent voltage adjustments that occur during operation. As a result, EMIF specifications for industrial speed grade devices using SmartVID are expected to be lower than for extended speed grade devices.

Using Intel^® Stratix^® 10 EMIF IP with SmartVID

To employ Intel^® Stratix^® 10 EMIF IP with SmartVID, follow these steps:

1. Ensure that the Intel^® Quartus^® Prime project and Platform Designer system are configured to use VID components. This step exposes the vid_cal_done_persist interface on instantiated EMIF IP, which is required for communicating with the SmartVID controller.
2. Instantiate the SmartVID controller, using an I/O PLL IP core to drive the 125MHz vid_clk and the 25MHz jtag_core_clk inputs of the Smart VID controller.
   Note: Do not connect the emif_usr_clk signal to either the vid_clk or jtag_core_clk inputs. Doing so would hold both the EMIF IP and the SmartVID controller in a perpetual reset condition.
3. Instantiate the Intel^® Stratix^® 10 EMIF IP.
4. Connect the vid_cal_done_persist signal from the EMIF IP with the cal_done_persistent signal on the SmartVID controller. This connection enables handshaking between the EMIF IP and the SmartVID controller, which allows the EMIF IP to delay memory calibration until after voltage levels are stabilized.
   Note: The EMIF vid_cal_done_persist interface becomes available only when a VID-enabled device is selected.