cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

Multiple Memory interface Using ALTMEMPHY

Multiple Memory interface Using ALTMEMPHY



Initial Release – December 2011 – Multiple Memory interface Using ALTMEMPHY.

Last Major Update

Overview

This page describes the steps to implement multiple memory interfaces where there are independent memory transactions, but the interfaces are operating at the same frequency. Such implementations require multiple instantiations of the PHY, which in turn may necessitate device resource sharing, such as the delay-locked loops (DLLs) and clock networks, and may require extra steps to create the interfaces in a Quartus II project.

Multiple memory interfaces may also involve different types of memory standards, for example, if you have DDR2 SDRAM and RLDRAM II interfaces in a single Stratix IV device. Width and depth expansion of a memory interface are not covered in this document as they are natively supported by the PHY. There is no design example associated with this tutorial.


Multiple Interface Requirements

 When creating multiple memory interfaces to be fitted in a single device, first ensure that there are enough device resources for the different interfaces. These device resources include the number of pins, DLLs, PLLs, and clock networks, where applicable. The DLLs, PLLs, and clock network resources from the clock and reset management block can be shared between multiple memory interfaces, but there are sharing limitations that you need to pay close attention to.


The following different scenarios exist for the resources sharing DLL and PLL static clocks:

  • Multiple controllers with no sharing. You need to check the number of PLLs and DLLs that available in the targeted device and the number of PLLs and DLLs that needed in your design. If you have enough resources for the controllers, you do not need to share the DLL and PLL static clocks.
  • Multiple controllers sharing DLL only. If you have enough resources on PLL clocks output and only need to share DLL, ensure that the controllers are running at the same memory clock frequency.
  • Multiple controllers sharing PLL static clocks only. Ensure that all the controllers sharing the PLL static clocks are located in the same half of the device, as ALTMEMPHY requires the use of regional and dual-regional clocks, instead of global clocks. Each controller can have their own DLL as the DLL can only access the adjacent sides from its location.
  • Multiple controllers sharing DLL and PLL static clocks. The PLL static clocks and DLL can be shared when the controllers are on the same side or adjacent side of the device and provided they are running at the same memory-clock frequency.

While you may not be able to share one PLL between multiple ALTMEMPHY-based controllers, you may be able to share the static clocks to reduce the number of clock networks used in the design.

You cannot merge dynamic clocks of the ALTMEMPHY megafunction or high-performance controllers. The Quartus II software may not give a warning, but this merging does not work in the hardware.


Creating PHY and Controller in a Quartus II Project

1. SOPC Builder Flow

The SOPC Builder supports sharing static PHY clocks between multiple controllers in the SOPC Builder that are running on the same frequency and sharing the same PLL reference clock.

  • To share the static clocks, you must turn on the Clock source from another controller option in the Controller Settings page of the DDR, DDR2, or DDR3 SDRAM High Performance Controller wizard. This option must be turned on for the slave controllers. Turning on this option adds a new clock input connection point to the slave controller named shared_sys_clk.
  • You must connect the sys_clk signal from the master controller to the shared_sys_clk signal of the slave controller as shown in Figure 1 below.
  • After the system generation, you must add the .sdc file and run the pin assignment Tcl scripts.


Figure 1: Connection Between Master and Slave Controller- Connection_Between_Master_and_Slave_Controller.jpg (Click here for image)


2. MegaWizard Plug-In Manager Flow

  •  If you are creating multiple instances of the same controller with the same parameters (frequency of operation, data width, burst mode, etc.), you only need to generate the controller once. You can then instantiate this controller variation multiple times in your top-level design file.
  • If you are using controllers with different parameters, or you plan on modifying the RTL generated by the MegaWizard Plug-In Manager (as required for resource sharing in some cases), then you need to generate each variation of the memory controller individually.

If the controllers are generated individually Altera recommends you generate each controller's files in a separate directory. However, you may get compilation errors if

you add all the .qip files to the project. You may remove the following line in all the .qip files except for one to remove the compilation error:

set_global_assignment -name VHDL_FILE [file join $::quartus(qip_path) "auk_ddr3_hp_controller.vhd"]


The high-performance memory controller is generated with a top-level design called <variation_name>_example_top.v or .vhd, where variation_name is the name of the memory controller that you entered in the first page of the MegaWizard Plug-In Manager. This example top-level file instantiates the memory controller (<variation_name>.v or .vhd) and an example driver, which performs a comparison test after reading back data that was written to the memory. You can also generate simulation files for each high-performance controller or ALTMEMPHY megafunction.

When creating a multiple memory interface design, you have the option to combine certain aspects of the design flow. For example:

  • You can use one of the top-level designs to instantiate all the memory controllers in the design, or create a new top-level design.
  • You can either modify one of the example drivers to test all the memory interfaces in the design, or instantiate an example driver with each memory controller.
  • You can simulate each memory interface separately, or create a testbench which combines all the memory interfaces in the design.


 

3. Sharing DLL

Turn on Instantiate DLL externally option in the PHY Settings page for every interface that is sharing a DLL.

When you turn on Instantiate DLL externally, the MegaWizard Plug-In Manager generates a file called<variation_name>_phy_alt_mem_phy_dll_<device_family>.v/.vhd, where

<device_family> is:

  • siii when targeting HardCopy® III, HardCopy IV, Stratix III, or Stratix IV devices
  • aii when targeting Arria II GX devices


4. Sharing PLL Clock Outputs or Clock Networks

 

If you use more than one similarly configured ALTMEMPHY in a design, you can share these system clocks, which allows the ALTMEMPHY interfaces to operate synchronously to each other. PLL static clock sharing has the following benefits:

 

  • Although a PLL instance is used for each ALTMEMPHY instance, the static clocks are shared, which uses fewer clocking resources
  • The multiple ALTMEMPHYs operate on the same system clock so can be directly connected to logic on the same clock (for example, Avalon-MM interface) without any clock domain crossing logic required, which causes an increase in logic usage and read latency

 Figure 2 shows a diagram of the connection between the DLL and the PLL for this scheme.

 

Figure 2: Two Controllers Static Clocks with Separate Resynchronization Clocks from Different PLLs- Two_Controllers_Static_Clocks_with_Separate_Resynchronization_Clocks_from_Different_PLLs.png (Click here for image)


 

ALTMEMPHY-based memory interfaces may share static clocks between multiple controllers when the following rules are observed:

  • All ALTMEMPHYs are full-rate or all half-rate designs
  • All ALTMEMPHYs have the same PLL input and output frequencies
  • The ALTMEMPHY memory types are compatible. DDR and DDR2 SDRAM can be mixed in the same system; DDR3 SDRAM controllers may be compatible with DDR or DDR2 SDRAM if the static clock phases are identical. DDR3 with and without levelling implementations have different static clock phases. Check for the ALTMEMPHY static clock phase compatibility in the clocking tables of the appropriate device and memory interface standard.
  • The ref_clk input of each ALTMEMPHY PLL must be connected to a clock signal derived from a single clock source. You can use a clock fanout buffer to create
  • separate PLL reference clocks from a single clock source.
  • All of the memory controller's circuitry is located in the same two device quadrants
  • All of the clocks can be routed as required by their Global Network Clock Type. To see the global clocks, look in the Fitter Report > Resource selection > Global and
  • other fast signals.
  • The general routing rules defined in the relevant memory standard layout section are met.

Static clocks which can be shared are divided into two categories:

  • Static clocks with a fixed phase in the IP (all static clocks except the address and command clock ac_clk_1x)
  • Static clocks where the phase is set in the IP (the address and command clock ac_clk_1x)


Static clocks with a fixed phase in the IP do not require each controller's interface PCB traces to have the same delays. Static clocks with the phase set in the IP have several

options where they may be shared between multiple controllers:

  • The address and command clock traces all have the same respective delays from the FPGA to each device
  • The TPD delay between the address and command signals and the memory clock of each of the interfaces is the same to all devices
  • The TPD delay between the address and command signals and the memory clock of each of the interfaces is similar and the optimal address and command phase for each separate interface is within one to two PLL phase steps. Most designs should be able to use a single ac_clk_1x clock shared between all controllers and accept less margin.

 

When static clocks are to be shared select which controller is to be the master. The slave controllers are made to share the master's static clocks by using the Force Merging of PLL Clock Fanouts assignments. You need to manually add the two PLL merging assignments using the Assignment Editor or directly update the .qsf file.

The Force Merging of PLL Clock Fanouts option requires both the master and slave PLL to have the same input reference clock in the RTL. This option limits the placement of the controllers to be only on the same side where one input clock can provide the reference clock for both center PLLs. If your multiple memory controllers' PLLs cannot share the same input reference clock pin, you need to manually connect the clocks together via RTL, instead of using this assignment.

If you are not sharing the address and command clocks, generate the slave controller address and command clocks from the master controller's PLL spare outputs. Create these in the PLL wizard. Modify the PHY source code to bring these clocks out to the top-level file and then modify the slave controllers to connect in the new address and command clock.

 

 

PLL Merging Assignments
DeviceRateAssignment
Arria II GXHalf

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[0] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[0]

 

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[3] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[3]

Full

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[1] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[1]

 

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[3] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[3]

Cyclone IIIHalf

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[0] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[0]


set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[2] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[2]

Full

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[1] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[1]


set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pll:*:al
tpll_component|*:auto_generated|clk[2] -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_pll:*:
altpll_component|*:auto_generated|clk[2]

Stratix III/IVHalf and full

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|write_clk_2x -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|write_clk_2x


set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from
*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|phy_clk_1x -to
*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|phy_clk_1x

Note:  In these assignments, if you are using the ALTMEMPHY megafunction, you must replace <SLAVE>_phy and <MASTER>_phy by the variation

names of your two variations. If you are using the high performance controller, you must replace <SLAVE> and <MASTER> by the variation names

of your two variations.


To check that the Quartus II software has applied the assignments, read the Compilation Report - PLL Usage (available only if the fitter step is successful), which shows the two clocks merged. This report allows you to compare the PLL usage before PLL merging and after PLL merging.

If the report does not show the clocks merged as expected you should check the FORCE_MERGE_PLL_FANOUTS assignment carefully for incorrect clock names. You can also open your <projectname>_fit.rpt file and look for Merged PLL.

 

Adding Constraints to the Design

  • Add all the .sdc files for each controller if you are using two or more different memory controller variations. If your design consists of multiple instantiations of the same controller, you only need to add the .sdc file once without modification.
  • The High-Performance Memory Controller MegaWizard Plug-In Manager also generates two <variable_name>_pin_assignment.tcl scripts per variation. These .tcl scripts use the default MegaWizard Plug-In Manager names; for example, mem_dq[71..0], local_ready, and mem_ras_n. Every variation of the high-performance memory controller uses this naming convention. However, if there are multiple memory controllers in the design, you must change the names of the interface pins in the top-level file to differentiate each controller. You can add prefixes to the controller pin names in the Quartus II Pin Planner by following these steps:

1. Open the Assignment menu and click on Pin Planner.

2. Right-click in any area under Node Name, and select Create/Import Megafunction (Figure 3).


Figure 3 Create/Import Megafunction Option in the Pin Planner- CreateImport_Megafunction_Option_in_the_Pin_Planner.png (Click here for image)



3. Turn on the Import an existing custom megafunction radio button and choose the <variation_name>.ppf file.

4. Type the prefix that you want to use under the Instance name (Figure 4).


Figure 4: Adding Prefix to the Memory Interface Pin Names- Adding_Prefix_to_the_Memory_Interface_Pin_Names.png (Click here for image)


 

 

 

 

Compiling Design and Verifying Timing

To compile the design, on the Processing menu, click Start Compilation. After successfully compiling the design, the Quartus II software automatically runs the

verified timing script which produces a timing margin report for the design together with the compilation report. The report timing script performs the following tasks:

1. Creates a timing netlist.

2. Reads the <variation_name>.sdc file.

3. Updates the timing netlist. You can also obtain the timing report by running the report timing script in the TimeQuest timing analyzer. To obtain the timing report in the TimeQuest Timing Analyzer window, perform the following steps:

1. In the Quartus II software, on the Tools menu, click TimeQuest Timing Analyzer.

2. On the Tasks pane, double-click Report DDR which automatically runs Update Timing Netlist, Create Timing Netlist, and Read SDC. This command subsequently executes the report timing script to generate the timing margin report. The results are the same as the Quartus II software results.

 

Notes/Comments

For more information about Altera’s current IP offering, refer to Altera’s Intellectual Property website.


Update History

Initial Release – December 2011 – Multiple Memory interface Using ALTMEMPHY 

See Also

1. List of designs using Altera External Memory IP

 



External Links

1. Altera's External Memory Interface Solutions Center 

2. Altera's External Memory Interface Handbook

 

Key Words

ALTMEMPHY, Multiple, Interface, Multiple Interface , Sharing PLL, Sharing DLL, Sharing

Attachments
Version history
Revision #:
1 of 1
Last update:
‎06-25-2019 07:42 PM
Updated by:
 
Contributors