AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

AN 462: Implementing Multiple Memory

Interfaces Using the ALTMEMPHY

Megafunction

AN-462-1.3

© April 2009

Introduction

Many systems and applications use external memory interfaces as data storage or buffer mechanisms. As system applications require increasing bandwidth, become more complex, and devices get more expensive, designers prefer to have multiple memory interfaces in a single device to save cost and space on the board, along with removing partitioning complexity. To implement multiple memory interfaces on the same device that are efficient and optimized for the device architecture, designers must pay attention to the device and the physical interface (PHY) features.

This application note describes the steps to implement multiple memory interfaces in which 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), phase-locked loops (PLLs), 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

®

II device. Width and depth expansion of a memory interface are not covered in this document as they are natively supported by the PHY. The memory interfaces described in this document use the ALTMEMPHY megafunction that is available for Arria

®

GX, Arria II GX, Cyclone

®

III, HardCopy

®

II,

HardCopy III, HardCopy IV, Stratix II, Stratix II GX, Stratix III, and Stratix IV devices.

1

The ALTMEMPHY megafunction supports DDR3/DDR2/DDR SDRAM and

QDRII+/QDRII SRAM interfaces depending on the target device family. The

ALTMEMPHY megafunction creates all the logic needed to calibrate the resynchronization clock dynamically during initialization to remove process (P) variation, and to track voltage and temperature (VT) variation when the system is running. This scheme ensures that the resynchronization data has the optimal setup and hold time margins in any PVT condition of the system. You can also use the

ALTMEMPHY megafunction with your own memory controller. Arria GX,

Arria II GX, Cyclone III, HardCopy II, HardCopy III, HardCopy IV, Stratix III, and

Stratix IV memory interfaces require the use of the ALTMEMPHY megafunction.

A design example (top.qar) demonstrating multiple memory interfaces in a Stratix II device is downloadable along with this application note.

© April 2009 Altera Corporation AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 2 Introduction

f

If you are targeting HardCopy II, Stratix II, or Stratix II GX devices and are unsure whether you can use a memory controller that uses the ALTMEMPHY megafunction as a data path, as in the DDR and DDR2 SDRAM High-Performance Controller, refer to

Technical Brief 091: External Memory Interface Options for Stratix II Devices

.

f

For information on multiple memory interfaces using the legacy integrated static data path and controller, refer to

AN 392: Implementing Multiple DDR/DDR2 SDRAM

Controller Interfaces

. f

Designs targeting the Stratix II devices are migrated to HardCopy II devices. Any discussion referring to Stratix II devices in this application note also applies Arria GX,

HardCopy II, or Stratix II GX devices. However, for additional requirements imposed by HardCopy II devices, refer to

AN 463: Using ALTMEMPHY Megafunction with

HardCopy II Structured ASICs

.

f

If the multiple memory interfaces in your design do not share any resources, you can treat them as independent modules in your design. For more information on creating your own memory controller, refer to the

ALTMEMPHY Megafunction User Guide.

For more information on using the Altera

®

MegaCore

®

function as your memory controller, refer to the

DDR and DDR2 SDRAM High-Performance Controller User Guide

.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Introduction Page 3

Figure 1

shows the design flow for implementing external memory interfaces in

FPGA devices. This application note covers the steps that are shaded in Figure 1 , from

creating a Quartus II project to verifying timing for multiple memory interface designs, assuming that the memory devices and FPGA have been chosen. This document prepares you by reviewing the device resources and creating a topology for your design prior to creating a multiple memory interface design in the Quartus II software using the DDR and DDR2 High-Performance Controller MegaCore function as an example.

Figure 1. Design Flow for Implementing External Memory Interfaces in Altera Devices

Start Design

Select Device

Perform RTL/

Functional Simulation

Does

Simulation Give

Expected Results?

Yes

No

Debug Design

Instantiate PHY and

Controller in a Quartus II Project

Add Constraints

Optional

Compile Design and

Verify Timing

Adjust Constraints

Adjust Termination

Drive Strength

Determine Board

Design Constraints

Perform Board Level

Simulations

Does the

Design Have Positive

Margin?

Yes

No

Verify Design

Functionality on Board

No

Do Signals

Meet Electrical

Requirements?

Yes

Is Design Working?

No

Yes

Debug Design

Design Done

Note to Figure 1

:

(1) Altera recommends performing this step to ensure design functionality.

1

This application note assumes that you are familiar with the ALTMEMPHY megafunction and Altera FPGA resources.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 4 Before Creating a Design in the Quartus II Software

Before Creating a Design in the Quartus II Software

Figure 2

shows a single memory interface using the ALTMEMPHY megafunction. The interface consists of user logic connected to a memory controller that connects to the

ALTMEMPHY megafunction, which connects with the memory devices via the read data, address/command, and write data path modules. These modules are unique per memory interface and cannot be shared.

Figure 2. Block Diagram of a Memory Controller Using ALTMEMPHY Megafunction Data Path

Altera Device

External

Memory

Device

ALTMEMPHY

Write Path

Address and Command Path

Clock and Reset

Management

DLL PLL

Read Path

Sequencer

Memory

Controller

User

Logic

The sequencer block displayed in

Figure 2

is used to calibrate and adjust the resynchronization clock. The ALTMEMPHY megafunction in version 9.0 of the

Quartus II software does not allow this block to be shared.

The clock and reset management block generates all the clock and reset signals for the

ALTMEMPHY megafunction. This block instantiates the DLL, the PLL, the PLL reconfiguration circuit, and the reset signals which may be shared between memory interfaces.

1

Note that the controllers have to be running at the same frequency when DLL, PLL, or clock networks are shared.

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 are shared between multiple memory interfaces, but there are sharing limitations that you must pay close attention to. These limitations are

discussed in “Getting to Know Your Altera Device” on page 5 .

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Before Creating a Design in the Quartus II Software Page 5

Getting to Know Your Altera Device

Knowing the target device means:

■ Comparing the requirement for the multiple interface design with the resources available on the device.

Determining which resources limit multiple interfaces.

Deciding which resources are shared in order to fit more memory interfaces in the device.

The following sections discuss the device resources to be considered for your multiple memory interface design:

“I/O Banks” on page 5

“I/O Pins” on page 8

“DLLs” on page 9

“PLLs and Clock Network Resources” on page 10

“Other Resources” on page 14

Once you have compared the required and available resources, you can start defining resources to be shared. This in turn determines the topology of your system. If no resources are to be shared, you can create the memory controllers as two different modules in the device. If you are sharing resources, the following sections offer guidance for sharing the DLL or PLL clock outputs, or both.

I/O Banks

You must determine the I/O bank placement of your memory interface. Arria GX,

Stratix II, and Stratix II GX devices only support ALTMEMPHY-based memory interfaces on the top and bottom I/O banks (I/O banks 3, 4, 7, and 8). You can have multiple memory interfaces in a Stratix II I/O bank, provided that you are able to share the DLL and you have enough pins and clock networks for those interfaces. If you do not have enough clock networks, you must be able to share some of the clocks between the interfaces.

Stratix III and Stratix IV devices support memory interfaces in all I/O banks. These two device families have up to 24 I/O banks, as shown in

Figure 3 . You can also have

multiple memory interfaces in a Stratix III or Stratix IV I/O banks, provided that you have enough pins and clock network resources. However, Stratix III and Stratix IV devices have a restriction whereby you can only have one memory interface in each

I/O sub-bank (for example, I/O sub-banks 1A, 1B, and 1C) if you are using leveling delay chain. This is because there is only one leveling delay chain per I/O sub-bank.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 6 Before Creating a Design in the Quartus II Software

Figure 3

shows the Stratix III and Stratix IV device families that have up to 24 I/O banks.

Figure 3. Stratix III and Stratix IV External Memory Support

(Note 1)

PLL_L1

DLL1

8A 8B 8C PLL_T1 PLL_T2 7C 7B 7A

DLL4

PLL_R1

1A

6A

1B 6B

1C

PLL_L2

PLL_L3

2C

2B

Stratix III and Stratix IV Device

6C

PLL_R2

PLL_R3

5C

5B

2A

5A

PLL_L4

DLL2

3A 3B

3C

PLL_B1 PLL_B2

4C 4B 4A

DLL3

PLL_R4

Note to Figure 3

:

(1) The number of I/O banks and PLLs available depends on the device density. For more information on the availability of the I/O bank and PLL for each device, refer to Stratix III or Stratix IV pin-out files at www.altera.com/literature/lit-dp.jsp

.

Arria II GX devices support memory interfaces in top, bottom, and right sides of the

I/O banks. This device family has up to 12 I/O banks, as shown in

Figure 4 . You can

have multiple memory interfaces in an Arria II GX I/O bank, provided that you have enough pins and clock network resources.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Before Creating a Design in the Quartus II Software

Figure 4

shows the Arria II GX device family that has up to 12 I/O banks.

Figure 4. Arria II GX External Memory Support

(Note 1)

DLL1

PLL 1

8B

8A 7A 7B

PLL_2

6B

Page 7

Arria II GX Device

6A

PLL_5

PLL_6

5A

PLL 4 3B 3A 4A

5B

4B

DLL2

PLL_3

Note for

Figure 4

:

(1) The number of I/O banks and PLLs available depends on the device density. For more information on the availability of I/O banks and PLLs for each device, refer to the Arria II GX pin-out file at www.altera.com/literature/lit-dp.jsp

.

After deciding which I/O banks to use, ensure that you have enough I/O pins in the chosen I/O banks for your memory interfaces.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 8 Before Creating a Design in the Quartus II Software

I/O Pins

DQS and DQ pins are listed in the device pin-outs and fixed at specific locations in the device. These locations are optimized in routing to minimize skew and maximize margin. Altera recommends you to always check the pin table and the external memory interfaces chapters for the number of DQS/DQ groups supported in a particular device.

1

You cannot share any I/O pins for multiple memory interfaces described in this document.

To check if the memory interfaces fit in the FPGA, compare the number of pins available in the FPGA with the number of pins required for the memory interfaces.

Table 1

shows a summary of the number of pins required for various memory interfaces.

1

Table 1

assumes that series on-chip termination (OCT) with calibration, parallel OCT with calibration, or dynamic calibrated OCT are used. The type of OCT selected is shown by the usage of R

UP

and R

DN

pins.

Table 1. Example of Pin Counts for Various Memory Interfaces

(Note 1)

,

(2)

(Part 1 of 2)

(4)

(7)

(5)

,

Memory

Interface

DDR3 SDRAM

(5)

DDR2 SDRAM

DDR SDRAM

QDRII+ SRAM

QDRII SRAM

FPGA

Bus

Width

×

18

×

36

×

9

× 18

×

36

×

8

×

16

×

72

× 9

×

8

×

16

×

72

× 4

× 4

×

8

×

16

×

72

× 4

Number of DQ

Pins

Number of DQS

Pins

Number of

DM/BWSn

Pins

Number of

Address

Pins

(3)

Number of

Command

Pins

Number of

Clock

Pins

R

UP

/R

DN

Pins

(10)

18

36

72

18

4

8

16

72

36

72

4

8

16

72

4

8

16

72

2

2

2

2

2

2

2

9

1

1

2

9

1

1

2

2

4

18

0

(6)

0

(6)

0

1

2

9

1

2

9

(6)

1

2

9

1

2

4

1

2

4

14

14

14

16

15

15

14

14

14

14

14

13

19

18

17

19

18

17

3

(8)

3

(8)

3

(8)

2

2

2

7

9

7

7

9

9

9

12

10

10

10

15

4

4

4

4

4

4

2

6

2

2

2

6

2

2

2

4

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

Total

Pins

49

67

104

48

28

33

43

118

66

103

33

38

47

124

34

39

50

136

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Before Creating a Design in the Quartus II Software Page 9

Table 1. Example of Pin Counts for Various Memory Interfaces

(Note 1)

,

(2)

(Part 2 of 2)

Memory

Interface

FPGA

Bus

Width

Number of DQ

Pins

Number of DQS

Pins

Number of

DM/BWSn

Pins

Number of

Address

Pins

(3)

Number of

Command

Pins

Number of

Clock

Pins

R

UP

/R

DN

Pins

(10)

Total

Pins

RLDRAMII CIO

(9)

RLDRAM II SIO

(9)

× 9

×

18

×

36

×

9

× 18

×

36

9

18

36

18

36

72

2

2

2

2

2

2

1

1

1

1

1

1

22

21

20

22

21

20

7

7

7

7

7

7

(8)

(8)

(8)

(8)

(8)

(8)

4

6

8

4

6

8

2

2

2

2

2

2

47

57

76

56

75

112

Notes to Table 1 :

(1) These example pin counts are derived from memory vendor data sheets. Check the exact number of addresses and command pins of the memory devices in the configuration that you are using.

(2) PLL and DLL input reference clock pins are not counted in this calculation.

(3) The number of address pins depend on the memory device density.

(4) The TDQS and TDQS# pins are not counted in this calculation, as these pins are not used in the memory controller.

(5) Numbers are based on 1-GB memory devices.

(6) Altera FPGAs do not support DM pins in

×

4 mode.

(7) Numbers are based on 2-GB memory devices without using differential DQS, RDQS, and RDQS# pin support.

(8) The QVLD pin, used to indicate read data valid from the QDRII+ SRAM or RLDRAM II device, is included in this number.

(9) The ALTMEMPHY megafunction in version 8.0 of the Quartus II software does not support RLDRAM II interfaces.

(10) Some DQ/DQS pins are dual purpose and can also be used as RUP, RDN, or configuration pins. A DQ/DQS group is lost if you use these pins for configuration or as RUP or RDN pins for calibrated OCT. Pick RUP/RDN pins in a DQS/DQ group that is not being used for memory interface purposes. You may need to place the DQS and DQ pins manually if you place the RUP and RDN pins in the same

DQS/DQ group pins.

f

For the device DQS/DQ pin count, refer to the External Memory Interfaces chapter of the respective device family handbook.

1

When using the ALTMEMPHY megafunction for Arria GX, HardCopy II,

Stratix II, and Stratix II GX devices, you can only target the top and bottom of the I/O banks (I/O banks 3, 4, 7, and 8).

1

Arria II GX, HardCopy III, HardCopy IV, Stratix III, and Stratix IV devices support external memory interfaces in every I/O bank.

DLLs

A single DLL can support any number of interfaces (limited by pins, PLLs, clock networks, and logic element resources) running at the same frequency and using the same DLL frequency mode. For information on the DLL in each device family and to decide whether you must share the DLLs for your multiple memory controllers based on your frequency and memory data width requirements, refer to

“HardCopy III,

HardCopy IV, Stratix III, and Stratix IV Devices” on page 10

,

“Arria II GX Devices” on page 10 , and “Arria GX, HardCopy II, Stratix II, and Stratix II GX Devices” on page 10 .

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 10 Before Creating a Design in the Quartus II Software

HardCopy III, HardCopy IV, Stratix III, and Stratix IV Devices

HardCopy III, HardCopy IV, Stratix III, and Stratix IV device DLLs are located in each corner of the device, allowing them to shift any DQS pins located on the adjacent sides to the DLLs. There are a total of four DLLs per device, so HardCopy III,

HardCopy IV, Stratix III, and Stratix IV devices can have a maximum of four memory interfaces with unique frequencies. For information on the method to share DLLs in

these devices, refer to “Sharing DLLs” on page 18

.

Arria II GX Devices

There are two DLLs in an Arria II GX device, located in the top-left and bottom-right corners of the device. These two DLLs can support a maximum of two unique frequencies, with each DLL running at one frequency. Each DLL can access the top, bottom, and right side of the device. This means that each I/O bank is accessible by two DLLs, giving more flexibility to create multiple frequencies and multiple-type interfaces. The DLL outputs the same DQS delay settings for the different sides of the device. For information on the method to share DLLs in the Arria II GX device, refer to

“Sharing DLLs” on page 18

.

1

Version 9.0 of the Quartus II software only supports the hybrid mode for top and right sides and bottom and right sides of the device. The hybrid mode for top, bottom and right sides of the device will be supported in the future version of the Quartus II software.

Arria GX, HardCopy II, Stratix II, and Stratix II GX Devices

For Arria GX, HardCopy II, Stratix II, and Stratix II GX devices, there is one DLL on the top and one DLL on the bottom of each device. Each DLL can only shift the DQS pins located on the same side as the DLL. Since there are only two DLLs, the Stratix II device can have a maximum of two memory interfaces with unique frequencies. For

information on the method to share DLLs in these devices, refer to “Sharing DLLs” on page 18 .

Cyclone III Devices

Cyclone III devices do not use a DLL to interface with memory devices.

PLLs and Clock Network Resources

The ALTMEMPHY megafunction uses a PLL that is instantiated in the ALTMEMPHY

MegaWizard

®

Plug-In Manager. The PLL is responsible for generating the various clocks needed in the memory interface data path and controller.

Table 2 shows a summary of the clocks used in the ALTMEMPHY megafunction. All the clocks run at the same frequency as the I/O frequency, except for the phy_clk_1x

clock, which runs at half the frequency of the interface if the controller is in half-rate mode, or at the same frequency as that of the memory interface in full-rate mode. The resynch_clk_2x and measure_clk_2x clocks use the PLL reconfiguration ability to change the phase shift at run-time to adjust for voltage and temperature (VT) variations.

1

Half-rate DDR/DDR2 ALTMEMPHY megafunction for Stratix III devices cannot interleave memory controller within each other due to the half-rate resynchronization clock (resynch_clk_1x) which is cascaded from DQ group to DQ group.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Before Creating a Design in the Quartus II Software Page 11

Table 2. Clocks Used in the ALTMEMPHY Megafunction

(Note 1)

,

(2)

Clock Name

phy_clk_1x mem_clk_2x mem_clk_1x write_clk_2x mem_clk_ext_2x resynch_clk_2x

Usage Description

Static system clock for the half-rate data path and controller.

Static DQS output clock used to generate DQS, CK/CK# signals, the input reference clock to the DLL, and the system clock for the full-rate datapath and controller.

This clock drives the aux_clk output or clocking DQS and as a reference clock for the memory devices.

Static DQ output clock used to generate DQ signals at 90 o

earlier than DQS signals. Also may be used to generate the address and command signals.

This clock is only used if the memory clock generation uses dedicated output pins. Applicable only in HardCopy II or Stratix II prototyping for HardCopy II designs.

Dynamic-phase clock used for resynchronization and postamble paths. Currently, this clock cannot be shared by multiple interfaces.

Dynamic-phase clock used for VT tracking purposes. Currently, this clock cannot be shared by multiple interfaces.

measure_clk_2x/ measure_clk_1x

(3)

ac_clk_2x

Dedicated static clock for address and command signals.

ac_clk_1x scan_clk seq_clk

Static clock to reconfigure the PLL

Static clock for the sequencer logic

Notes to Table 2 :

(1) For more information on the clocks used in the ALTMEMPHY megafunction, refer to the Clock Networks and PLL chapter of the respective device family handbook for more details.

(2) For more information on the clock usage and clock network type, refer to the

ALTMEMPHY Megafunction User Guide

.

(3) This clock should be of the same clock network clock as the resync_clk_2x clock.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 12 Before Creating a Design in the Quartus II Software

Table 3 and Table 4 show a comparison of the number of PLLs and dedicated clock

outputs available respectively in Arria GX, Arria II GX, Cyclone III, HardCopy II,

HardCopy III, HardCopy IV, Stratix II, Stratix II GX, Stratix III, and Stratix IV devices.

Table 3. Number of PLLs Available in Altera Device Families

(Note 1)

Device Family Fast PLL

(2)

Enhanced PLL

Arria GX

Arria II GX

Cyclone III

HardCopy II

HardCopy III

HardCopy IV

Stratix II

Stratix II GX

Stratix III

Stratix IV

2-4

N/A

N/A

2-8

N/A

N/A

4-8

2-4

N/A

N/A

2-4

4-6

2-4

2-4

4-12

4-12

2-4

2-4

4-12

3-12

(3)

(3)

(3)

(3)

(3)

(3)

Notes to Table 3 :

(1) For more details, refer to the Clock Networks and PLL chapter of the respective device family handbook.

(2) You cannot use Stratix II and Stratix II GX Fast PLLs in the ALTMEMPHY megafunction, as they do not have enough clock outputs to meet the requirements of the ALTMEMPHY megafunction.

(3) Arria II GX, Cyclone III, HardCopy III, Stratix IV, HardCopy IV, and Stratix III PLLs are not the same as Stratix II

Enhanced PLLs, but compared with Stratix II PLLs, they are more similar to the Enhanced PLLs than to the Fast

PLLs.

Table 4. Number of Enhanced PLL Clock Outputs and Dedicated Clock Outputs Available in Altera

Device Families

(Note 1)

(Part 1 of 2)

Arria GX

Arria II GX

Cyclone III

(2)

HardCopy II

HardCopy III

Device Family

Number of Enhanced PLL

Clock Outputs

6 clock outputs each

7 clock outputs each

5 clock outputs each

6 clock outputs each

Left/right: 7 clock outputs

Top/bottom: 10 clock outputs

Number Dedicated Clock

Outputs

Three differential or six single-ended total (top and bottom I/O banks only)

Single-ended or 1 differential pair

3 single-ended or 3 differential pairs

(3)

1 single-ended or 1 differential pair total (not for memory interface use)

Three differential or six single-ended total (top and bottom I/O banks only)

Left/right: 2 single-ended or 1 differential pair

Top/bottom: 6 single-ended or 4 single-ended and 1 differential pair

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Before Creating a Design in the Quartus II Software Page 13

Table 4. Number of Enhanced PLL Clock Outputs and Dedicated Clock Outputs Available in Altera

Device Families

(Note 1)

(Part 2 of 2)

HardCopy IV

Stratix II

Stratix II GX

Stratix III

Stratix IV

Device Family

Number of Enhanced PLL

Clock Outputs

Left/right: 7 clock outputs

Top/bottom: 10 clock outputs

6 clock outputs each

6 clock outputs each

Left/right: 7 clock outputs

Top/bottom: 10 clock outputs

Left/right: 7 clock outputs

Top/bottom: 10 clock outputs

Number Dedicated Clock

Outputs

Left/right: 2 single-ended or 1 differential pair

Top/bottom: 6 single-ended or 4 single-ended and 1 differential pair

Three differential or six single-ended total (top and bottom I/O banks only)

Three differential or six single-ended total (top and bottom I/O banks only)

Left/right: 2 single-ended or 1 differential pair

Top/bottom: 6 single-ended or 4 single-ended and 1 differential pair

Left/right: 2 single-ended or 1 differential pair

Top/bottom: 6 single-ended or 4 single-ended and 1 differential pair

Note to Table 4

:

(1) For more details, refer to the Clock Networks and PLL chapter of the respective device family handbook.

(2) PLL_5 and PLL_6 of Arria II GX device do not have dedicated clock outputs.

(3) The same PLL clock output drives 3 single-ended or 3 differential I/O pairs. This is only supported in PLL_1 and

PLL_3

of the EP2AGX95, EP2AGX125, EP2AGX190, and EP2AGX260 devices.

Table 5

shows the number of clock networks available in the Altera device families.

Table 5. Number of Clock Networks Available in Altera Device Families

(Note 1)

(Part 1 of 2)

Arria GX

Device Family

Arria II GX

Cyclone III

HardCopy II

HardCopy III

HardCopy IV

Global Clock Network Regional Clock Network

16

16

10-20

16

16

16

32

48

N/A

32

88

88

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 14 Before Creating a Design in the Quartus II Software

Table 5. Number of Clock Networks Available in Altera Device Families

(Note 1)

(Part 2 of 2)

Stratix II

Device Family

Stratix II GX

Stratix III

Stratix IV

Global Clock Network

16

16

16

16

Regional Clock Network

32

32

64-88

64-88

Note to Table 5

:

(1) For more information on the number of available clock network resources per device quadrant to better understand the number of clock networks available for your interface, refer to the Clock

Networks and PLL chapter of the respective device family handbook.

1

You must decide whether you need to share clock networks, PLL clock outputs, or

PLLs for your multiple memory interfaces.

Other Resources

You must pay attention to other device resources that are used in an external memory interface, for example the TriMatrix

embedded memory blocks. If your design requires many TriMatrix embedded memory blocks for other modules in the design, ensure that there are enough for the memory interfaces as well.

Resources Planning for DLL and PLL Static Clocks

Below are the different scenarios for the resources sharing for 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 with 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 with Sharing PLL Static Clocks only — If the controllers are on the opposite device edge, you can only share the PLL static clocks. Each controller has their own DLL as the DLL can only access the adjacent sides from its location. Cyclone III devices do not use DLL to interface with memory devices, thus only PLL static clocks are shared.

■ Multiple Controllers with Sharing DLL and PLL Static Clocks — The PLL static clocks and DLL are 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. Arria GX, Stratix II, and Stratix II GX devices only support memory interfaces on the top and bottom I/O banks. Only Arria II GX, Stratix III, and

Stratix IV devices can support hybrid mode as the DLL for these devices families can access the adjacent side from its location in the device.

1

It is recommended to use dedicated clock input pin for the PLL reference clock input.

If you do not use dedicated clock input pin, Quartus II software will give critical warning due to increased jitter and worse timing margin.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project Page 15

For Stratix III and Stratix IV devices, the adjacent PLLs on the same side of the device can share a dedicated input clock for their PLL reference clock input. If LVDS is used on the left/right side of the device (which must be powered by 2.5 V), you can also use a 2.5-V LVDS input clock for PLL reference input clock for PLL at top or bottom side of the device.

Creating the Project Topology

After understanding the device resource limitations, you must determine the resources to share for your multiple controller design. You can use this as a framework for your Quartus II design constraints. For example, Stratix II external memory interfaces with an ALTMEMPHY megafunction data path are supported only on the top and bottom side of the device. If you also have a PCI interface in your design, you must leave at least one bank (either on the top or the bottom of the device) for the PCI interface. For this particular example interface, you may need to share a

DLL.

Creating PHY and Controller in a Quartus II Project

You can instantiate multiple controllers using either one of the following flows:

“SOPC Builder Flow”

“MegaWizard Plug-in Manager Flow”

The SOPC Builder flow provides useful validation and automatically generates all the wiring in SOPC Builder system and assignment. For the MegaWizard Plug-in

Manager flow, you must manually set the assignment for the PLL sharing but this flow gives you more flexibility.

There are some regulations that you must follow when you want to share the clock between controllers:

■ The controllers must be configured to have the same local interface clock frequency, either in full-rate or half-rate mode

The controllers must have the same PLL input and output frequencies

The controllers must have compatible memory types (DDR SDRAM and DDR2

SDRAM are mixed in the same system but the DDR3 SDRAM controller is not compatible with DDR/DDR2 SDRAM)

■ The controllers must have their ref_clk input connected to the same signal

SOPC Builder Flow

The SOPC Builder in version 8.1 and onwards of the Quartus II software allows you to add multiple controllers directly to a new or existing SOPC Builder system. 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 DDR3/DDR2/DDR SDRAM

High Performance Controller, as shown in

Figure 5 . This option must be turned on for

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 16 Creating PHY and Controller in a Quartus II Project

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 6

. The Force Merging of PLL Clock Fanouts assignment will automatically be assigned in the Quartus II software.

Figure 5. Enabling Multiple Controllers Sharing Clock for Slave Controllers

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project

Figure 6. Connection Between Master and Slave Controller

Page 17

After the system generation, you must add the SDC file and run the pin assignment

TCL scripts as usual.

When an SOPC Builder multiple controllers system does not share the sys_clk, the

SOPC Builder inadvertently insert clock-crossing adaptors between the controller and the NIOS II processor. In this situation, the system cannot achieve the maximum performance for both controllers.

The SOPC Builder checks all the conditions listed in the regulation section and prevents you from generating the system when they are not met.

f

For more information on how to use controllers with SOPC Builder, refer to

AN 517:

Using High-Performance DDR, DDR2, and DDR3 SDRAM With SOPC Builder

.

f

For more information on DDR, DDR2, and DDR3 SDRAM High Performance

Controllers, refer to

DDR and DDR2 SDRAM high-Performance Controller User Guide

and the

DDR3 SDRAM High-Performance Controller User Guide

.

f

For more information on simulating SOPC Builder systems, refer to

AN 351:

Simulating Nios II Systems

.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 18 Creating PHY and Controller in a Quartus II Project

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 plan to modify the RTL generated by the MegaWizard Plug-In Manager (as required for resource sharing in some cases), you must generate each variation of the memory controller individually.

The high-performance memory controller is generated with a top-level design,

<

variation_name>_example_top.v/.vhd, in which variation_name is the name of the memory controller that you entered in the first page of the MegaWizard Plug-In

Manager. This top-level design example instantiates the memory controller

(<variation_name>.v/.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.

1

For more information on how to use the ALTMEMPHY megafunction, refer to the

ALTMEMPHY Megafunction User Guide

and the

DDR and DDR2 SDRAM

High-Performance Controller User Guide .

Sharing DLLs

If the controllers are sharing a DLL, ensure that the Instantiate DLL externally option is turned on in the PHY Settings page of the DDR3/DDR2/DDR SDRAM

High-Performance Controller or the ALTMEMPHY MegaWizard Plug-In Manager, as

shown in Figure 4

. This option must be checked for every interface that is sharing a

DLL.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project Page 19

Figure 7

shows you how to allow the DLL to be instantiated externally for controllers sharing DLLS.

Figure 7. Allowing the DLL to be Instantiated Externally for Controllers Sharing DLLs

1

For more information on instantiating the controllers, refer to the

DDR and DDR2

SDRAM High-Performance Controller User Guide .

When the Instantiate DLL externally option is checked, the MegaWizard Plug-In

Manager generates a file called

<

variation_name>_phy_alt_mem_phy_dll_<device_family>.v/.vhd, in which the device family is:

sii

when targeting Arria GX, HardCopy II, Stratix II, or Stratix II GX devices

siii

when targeting HardCopy III, HardCopy IV, Stratix III, or Stratix IV devices

aii

when targeting Arria II GX devices

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 20 Creating PHY and Controller in a Quartus II Project

The example top design then instantiates the DLL in addition to instantiating the memory controller and the example driver. You can then instantiate the other memory controllers for the design and either modify the example driver to create the test pattern for all controllers or create another design example for each controller that is instantiated.

1

If you do not need to share any other clock networks or PLLs, you can continue to

“Adding Constraints to the Design” on page 24

.

Sharing PLL Clock Outputs or Clock Networks

You can share the static clock networks in multiple memory controllers using

ALTMEMPHY megafunction. Although a PLL instance is used for each

ALTMEMPHY instance, the static clocks are shared, which uses fewer clocking resources. This is an easy-to-implement option that reduces the required number of

clocks. Figure 8

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

Figure 8. Two Controllers Static Clocks with Separate Resynchronization Clocks from Different PLLs

ALTMEMPHY

PLL

Memory

Memory

6

DLL resynch_clk_2x measure_clk_2x phy_clk_1x mem_clk_2x write_clk_2x mem_clk_ext_2x

PLL resynch_clk_2x measure_clk_2x

Master Controller

FPGA

Slave Controller

The maximum number of interfaces that are shared in this scheme is limited by the number of PLLs and the number of pins available in the device. You must ensure that the memory devices that are accessed by the different controllers are laid out on the board with the same trace lengths.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project Page 21

You can share the static clock networks in multiple memory controllers by setting the

Force Merging of PLL Clock Fanouts

assignment to On. You need to manually add the two PLL merging assignments using the Assignment Editor or directly update the

.qsf

file.

Table 6

shows a list of PLL merging assignments.

Table 6. PLL Merging Assignments

(Note 1)

(Part 1 of 3)

Device

(2)

Arria II GX

Rate

Half

Assigments

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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]

Full set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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] set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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_pl l:*:altpll_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]

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 22 Creating PHY and Controller in a Quartus II Project

Table 6. PLL Merging Assignments

(Note 1)

(Part 2 of 3)

Device

(2)

Cyclone III

Rate

Half

Assigments

set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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]

Stratix II

Full

Half

Full set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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] set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_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_pl l:*:altpll_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] set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_component|*clk0 -to

*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_ pll:*:altpll_component|*clk0 set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_component|*clk2 -to

*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_ pll:*:altpll_component|*clk2 set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_component|*clk1 -to

*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_ pll:*:altpll_component|*clk1 set_instance_assignment -name FORCE_MERGE_PLL_FANOUTS ON -from

*|<SLAVE>_phy_alt_mem_phy_clk_reset:clk|<SLAVE>_phy_alt_mem_phy_pl l:*:altpll_component|*clk2 -to

*|<MASTER>_phy_alt_mem_phy_clk_reset:clk|<MASTER>_phy_alt_mem_phy_ pll:*:altpll_component|*clk2

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project Page 23

Table 6. PLL Merging Assignments

(Note 1)

(Part 3 of 3)

Device

(2)

Rate Assigments

Stratix III Half 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

Notes to Table 6 :

(1) 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.

(2) Stratix II includes Arria GX, HardCopy II, Stratix II, or Stratix II GX devices; Stratix III includes HardCopy III, HardCopy IV, Stratix III, or Stratix IV devices.

To check if the Quartus II software has applied the assignments, you need to read the

Compilation Report - PLL Usage window (available only if the Fitter step is successful), which shows the two merged clocks.

Figure 9

shows PLL usage in the compilation report which shows the two clocks have been merged (clk0 and clk2)

Figure 9. Compilation Report PLL Usage

1

If the report does not show the clocks merged as expected you must 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.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 24 Creating PHY and Controller in a Quartus II Project

1

QDRII ALTMEMPHY does not have dynamic clocks, thus you can share the static clocks among the QDRII ALTMEMPHYs. Use regional clock networks for high-speed interfaces. For lower-speed interfaces, use global clock network if the FPGA output clock meets the QDRII SRAM input jitter specification.

1

You cannot merge dynamic clocks of the ALTMEMPHY megafunction or

High-Performance Controller. The Quartus II software may not give a warning, but this will not work in the hardware.

Adding Constraints to the Design

The MegaWizard Plug-In Manager generates an .sdc file for timing constraints and

.tcl

scripts for I/O standard and DQS/DQ grouping constraints of each controller. The

TimeQuest timing analyzer is the default timing analyzer for the Arria GX,

Arria II GX, Cyclone III, Stratix III, and Stratix IV device families. To manually optimize timing with the Quartus II compiler and to use the timing report script created by the MegaWizard Plug-In Manager, you must enable the TimeQuest timing analyzer. To enable the TimeQuest timing analyzer manually for Stratix II and Stratix

II GX designs, you must perform the following steps:

1. On the Assignments menu, click Settings. The Settings dialog box appears.

2. In the Category list, select Timing Analysis Settings. The Timing Analysis

Settings

page appears.

3. Under Timing analysis processing, select Use TimeQuest Timing Analyzer during compilation (

Figure 10 shows how the Settings dialog box).

4. Click OK.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project

Figure 10. Enabling TimeQuest Timing Analyzer

Page 25

© April 2009 Altera Corporation

You must then add the .sdc file for each controller. If you are using two or more different memory controller variations, you must add the .sdc files generated for each variation. However, if your design consists of multiple instantiations of the same controller, you only need to add the .sdc file once without modification. The

Quartus II software is able to apply the .sdc file for all the interfaces using the same variation.

The High-Performance Memory Controller MegaWizard Plug-In Manager also generates two .tcl scripts per variation to set the I/O standard, output enable grouping, termination, and current strength for the memory interface pins. 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 performing the following 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

as shown in

Figure 11

.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 26 Creating PHY and Controller in a Quartus II Project

Figure 11. Create/Import Megafunction Option in the Pin Planner

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 as shown in

Figure 12

.

Figure 12. Adding Prefix to the Memory Interface Pin Names

You may also want to set the default I/O standard for your design in the Voltage section of the Device and Pin Options, by navigating to Assignment and clicking

Setting

as shown in

Figure 13

.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Creating PHY and Controller in a Quartus II Project

Figure 13. Setting a Default Voltage for Your Design

Page 27

1

Take note of the number of available pins per I/O bank to ensure that the Quartus II software can successfully compile the design.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 28 Compiling the Design to Generate a Timing Report

Compiling the Design to Generate a Timing Report

After compiling the design, open the Tools menu and select TimeQuest Timing

Analyzer

. Double click on Report DDR (refer to Figure 14 ) to get the timing report for

all ALTMEMPHY-based memory controllers in the design.

Figure 14. Report DDR in TimeQuest Timing Analyzer for ALTMEMPHY-Based Controller

1

For more information on analyzing memory interface timing in the Cyclone III and

Stratix III devices, refer to

AN 438: Constraining and Analyzing Timing for External

Memory Interfaces in Stratix III and Cyclone III Devices

.

Some of the timing failures that you may encounter are as follow:

■ If read capture setup time is negative, you must decrease the delay chain used in the DQ pins by setting the Input Delay from Pin to Input Register to 0 or a lower number than the current setting in the Assignment Editor. However, if hold time is negative, you must do the opposite; increment the Input Delay from Pin to

Input Register

setting to a higher number than the current setting in the

Assignment Editor

.

■ If you are experiencing any write and address/command timing failures, you can resolve them by setting:

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Stratix II Design Example Page 29

set_instance_assignment -name CLOCK_TO_OUTPUT_DELAY 0 -to

<address/command/CK/CK# pin>

■ If the resynchronization path does not meet the timing, you must move the resynchronization registers closer to the IOE. Report DDR shows information messages with the names of the source and destination registers of the worst case setup path. You must copy the name of the destination register from the message and move it as close as possible to the source register using the Assignment

Editor

. Similarly, if the postamble path is not meeting recovery timing, move the postamble registers closer to the IOE.

■ Setup failures for transfers from the measure clock (clk5) to the PHY clock (clk0 for half-rate interfaces or clk1 for full-rate interfaces) must be ignored. Due to the dynamic nature of the measure clock, these must be treated as asynchronous transfers.

f

For more information on other issues that may cause timing failures in your design, refer to the latest version of the

Quartus II Release Notes

. f

For an example of step-by-step flow for closing timing with ALTMEMPHY-based controllers, refer to

AN 328: Interfacing DDR2 SDRAM with Stratix II, Stratix II GX, and

Arria GX Devices

.

Once your design meets timing requirements, you can continue your design flow by either performing a gate-level simulation or determining the board design constraints.

Stratix II Design Example

To illustrate the flow described above, you must consider a Stratix II EP2S90F1508C3 device with the following memory requirements:

■ One controller interfacing with a ×72 DDR2 SDRAM DIMM device running at

267 MHz

Two controllers interfacing with ×8 DDR2 SDRAM devices running at 267 MHz

All three controllers use the Altera DDR2 SDRAM High-Performance Controllers in half-rate mode.

1

Half-rate mode means that the clock frequency of the memory controller is half the frequency of the actual memory device’s clock rate. In half-rate mode, ALTMEMPHY multiplexes and demultiplexes data between the memory controller and the memory devices to transfer data between the two frequencies.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 30 Stratix II Design Example

Comparing I/O Pin Number Requirements

Table 1

indicates that a DDR2 SDRAM DIMM interface requires about 124 pins, while a ×8 DDR2 SDRAM interface requires around 38 pins. As noted in the

Stratix II Device

Handbook

, Stratix II has a maximum of 9 groups of ×8 DQS/DQ groups, such that the

DIMM interface needs to take one side of the FPGA. Furthermore, the Quartus II Pin

Planner indicates that there are 94 pins in I/O bank 3, and 102 pins in I/O bank 4, so the whole DIMM interface can fit in the top bank.

I/O banks 7 and 8 have 100 and 95 user I/O pins, respectively, so the two ×8 DDR2

SDRAM interfaces can share one I/O bank. However, for this exercise, the ×8 DDR2

SDRAM interfaces are placed in two different I/O banks so that the separation between the two interfaces are clearer.

To summarize, the DIMM interface is going to be located on the top of the device (I/O banks 3 and 4), while one ×8 DDR2 SDRAM controller is located on I/O bank 7, and the other on I/O bank 8.

Deciding DLL Requirements

Because there are two interfaces on the bottom side of the design, these interfaces must share a single DLL.

This example uses two DLLs.

Creating PHY and Controller for the Design Example

You must create the DIMM interface as a single interface without any special handling

(called top.v in the design example) because it is not sharing any resources.

The two memory interfaces at the bottom of the device are exactly the same. They both receive their static clocks from the top.v module. In this design example, because they are identical, you can create one variation and instantiate the same variation twice in the top-level file.

f

For more information on instantiating the controllers, refer to the

DDR and DDR2

SDRAM High-Performance Controller User Guide .

1

For easy organization of the files, Altera recommends that you create each controller as subfolders of the top project.

Sharing the DLLs Between the Two Bottom Controllers

The DLL is shared between the two bottom controllers and the steps for sharing are in the

“Sharing DLLs” section.

Sharing the PLL Clock Outputs

The design in this example is in half-rate mode. Refer to the “Sharing PLL Clock

Outputs or Clock Networks” section for the Force Merge PLL assignments.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Stratix II Design Example Page 31

Figure 15 shows the snapshot of the assignment for Force Merge PLLs in .qsf file.

Figure 15. Assignments for Force Merge PLLs

Adding Constraints to the Design Example

To add constraints to the design example, you must enable TimeQuest timing analyzer and add all the .sdc files for the three controllers. Next, perform the following steps:

1. In the Quartus II software, open the Pin Planner.

2. Right-click Create/Import Megafunction and follow the instructions described on

“Adding Constraints to the Design” on page 24

to add prefixes to match your actual top-level pin names for each controller (use prefixes top, bot1, and bot2 for the design example).

1

Each controller comes with its own <variation_name>_pin_assignments.tcl file. The pin assignments contained in this script use default pin names that must be changed so that they are unique for each controller instance.

You can also use the Pin Planner to assign actual locations to the pins. You may also want to set the default I/O standard for your design in the Voltage section of the

Device and Pin

Options by navigating to the Assignment menu and click Setting.

Compiling the Design Example

Add the two .sdc files from the two controller variations to the design. You must also add another .sdc file to the list of TimeQuest timing analyzer .sdc files to describe the frequency of the input PLL reference clock pins of all the controllers in the design. The design example uses a file called top.sdc which has the following lines: create_clock -period 10 top_pll_ref_clk create_clock -period 10 bot1_pll_ref_clk create_clock -period 10 bot2_pll_ref_clk

1

If you place the controllers in a different folder than the top-level project, you must add the directories of your controllers to the project library.

Compiling the Design Example to Verify Timing

You must compile the design and select the TimeQuest Timing Analyzer from the

Tools menu. Double-click on the Report DDR macro to check if the design meets all timing requirements. If not, you must fix the timing by either adding or removing delay chains, or by moving the registers closer using placement constraints.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 32 Stratix II Design Example

1

To ensure faster timing closure, you can close timing on each controller and place the controller logic in a LogicLock

TM

block before creating the multiple interface top level design.

Figure 16 shows the initial timing analysis results for the three controllers in the

design.

Figure 16. Initial Timing Analysis Result for the Design Example

If you look into the failing path, you can see that the failing path is on the mimic register. You must move this path closer to the IOE that is feeding the register in Chip

Planner

and recompile the design.

Figure 17 shows the final timing analysis result for the design.

Figure 17. Final Timing Analysis Result for the Design Example

Once your design meets timing, you can continue your design flow by either performing a gate-level simulation or determining the board design constraints.

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Conclusion Page 33

Conclusion

The ALTMEMPHY megafunction allows Altera FPGAs to interface with high-performance external memory interfaces. The architecture of the device further allows the FPGAs to interface with multiple memory interfaces.

As shown in this application note, there are several ways to create multiple-controller design using the ALTMEMPHY megafunction data path. Pick one that is optimal for your system as both the ALTMEMPHY megafunction data path and the high-performance controller are modified to meet your needs.

Knowing the requirements and limitations for the multiple memory interface in the initial design allows you to architect your system better.

© April 2009 Altera Corporation

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction

Page 34 Document Revision History

Document Revision History

Table 7

shows the revision history for this application note.

Table 7. Document Revision History (Part 1 of 2)

Date and Document

Version

April 2009 v1.3

May 2008 v1.2

Changes Made

Updated the

“Introduction” section.

Updated the

Figure 1

, Figure 2 ,

Figure 3 ,

Figure 4

, Figure 5 ,

Figure 7

,

Figure 8

, Figure 15 ,

Figure 16 , and Figure 17

.

Updated the

Table 1 ,

Table 2 ,

Table 3 , Table 4 , and

Table 5 .

Updated the

“Before Creating a Design in the Quartus II Software”

section.

Updated the

“Getting to Know Your Altera Device” section.

Updated the

“HardCopy III, HardCopy IV, Stratix III, and Stratix IV

Devices” section.

Updated the

“Arria II GX Devices” section.

Updated the

“Arria GX, HardCopy II, Stratix II, and Stratix II GX

Devices” section.

Updated the “PLLs and Clock Network Resources” section.

Added the

“Resources Planning for DLL and PLL Static Clocks”

section.

Updated the

“Creating PHY and Controller in a Quartus II Project”

section.

Added the

“SOPC Builder Flow”

section.

Updated the

“MegaWizard Plug-in Manager Flow” section.

Updated the

“Sharing DLLs”

section.

Updated the

“Sharing PLL Clock Outputs or Clock Networks” section.

Updated the

“Adding Constraints to the Design”

section.

Updated the

“Compiling the Design to Generate a Timing Report”

section.

Updated the

“Deciding DLL Requirements”

section.

Updated the

“Creating PHY and Controller for the Design Example”

section.

Updated the

“Sharing the DLLs Between the Two Bottom Controllers”

section.

Updated the “Sharing the PLL Clock Outputs” section.

Updated the

“Adding Constraints to the Design”

section.

Updated the “Compiling the Design Example to Verify Timing” section.

Removed “Appendix A: Stratix III RTL Modification for DLL Sharing”.

Updated the “Stratix III PLL Static Clock Sharing” section.

Updated the “Sharing PLL Clock Outputs or Clock Networks” section.

Removed original Figure 5.

Completed minor text edits.

Summary of Changes

AN 462: Implementing Multiple Memory Interfaces Using the ALTMEMPHY Megafunction © April 2009 Altera Corporation

Document Revision History

Table 7. Document Revision History (Part 2 of 2)

Date and Document

Version

October 2007 v1.1

June 2007 v1.0

Changes Made Summary of Changes

Updated the sections “Introduction”, “Before Creating a Design in the

Quartus II Software”, “PLLs and Clock Network Resources”, “Creating

PHY and Controller in a Quartus II Project”, “Sharing DLLs”, “Sharing

PLL Clock Outputs or Clock Networks”, “Adding Constraints to the

Design”, “Compiling the Design to Generate a Timing Report”,

“Creating PHY and Controller for the Example Design”, and “Sharing the PLL Clock Outputs”

Added the section “Stratix II, Stratix II GX, Arria GX, HardCopy II, and

Cyclone III PLL Static Clock Sharing”, “Stratix II Design Example”

(removed section Verifying Timing for the Design), “Appendix A:

Stratix III RTL Modification for DLL Sharing”, and “Referenced

Documents”.

Updated Figure 1, Figure 5, Figure 14, Figure 15, Figure 16, and

Figure 17.

Added Figure 7, Figure 12.

Removed original Figure 4 and Figure 8.

Updated Table 2.

Initial Release.

Added text, removed text, included new sections, section titles, updates to figures and tables, and added new figures.

101 Innovation Drive

San Jose, CA 95134 www.altera.com

Technical Support www.altera.com/support

Copyright © 2009 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized

Altera logo, specific device designations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera 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 Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services

.

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement