Interfacing to Altera external memory controller IP

[#1]

Interfacing to Altera external memory controller IP

Last Major Update

Page creation - November 16th 2010

Overview

Altera offers several external memory controller IPs that use the Avalon interface specification on the local side, this is the interface that is connected to the user's logic. This article will examine the basics of interfacing to an Avalon controller such as the High Performance Controller II (HPCII) and how to do simple read and write burst transfers. The diagram below shows the location of this interface in the IP example top project hierarchy, between the driver and the controller.

A Quartus project using HPCII and UniPHY with a modified driver is attached to show basic read and write transfers in simulation as a reference.

6/62/UniPHY_IP_Example_Top_Project_Structure.JPG ( UniPHY IP Example Top Project Structure.JPG - click here to view image )

 

Design Specifications

The table below lists the specifications for this design:  

Attribute	Specification
Quartus version	QuartusII v10.1b141a (customer beta)
FPGA	EP4SGX230KF40C2
Kit	Stratix IV GX FPGA Development kit (DK-DEV-4SGX230N/C2)
Memory device	DDR3 (Micron MT41J64M16LA-15E)
Memory speed	533MHz
Memory topology	single component, x16
IP used	UniPHY with HPCII and generated example top Quartus project and modified driver

Design files can be found here: Interfacing to Altera EMI IP example project files

Simulating with the attached design

1. Download and extract the project files in the zip file linked to above
2. Open Modelsim
3. From the File menu, Change Directory and browse to <>/UniPHY_HPCII_ddr3x16_top/simulation/modelsim, click OK
4. In the Transcript window run the following command: do ddr3_x16_example_top_run_msim_rtl_verilog.do
5. The simulation should take a few minutes and the results will be displayed in the Wave window 

 

Avalon Specification

The Avalon Interface is a data transfer standard created by Altera to allow easy connections between components particularly using the Avalon system interconnect fabric. It simplifies design by removing the requirement for a user to verify the actual transfer, just requiring them to ensure the interface conforms to the specification.

There are 6 types of Avalon interfaces:

• Memory Mapped (MM)
• Clock
• Conduit
• Interrupt
• MM Tristate
• Streaming

An Avalon component can use multiple types of these interfaces. The HPCII uses Memory Mapped for the primary part of its command transfer interface. Memory Mapped interfaces are read and write data transfer interfaces and can either be Masters (can initiate transfers) or Slaves (respond to transfers). HPCII is a Slave, in the above diagram the driver would be a Master.

For more information on Altera's Avalon specification refer to the link at the bottom of this page.

 

Basic Avalon writes

The following diagram shows the basic behavior for an Avalon write transfer.

7/72/Basic_avalon_write.jpg ( Basic avalon write.jpg - click here to view image )

Important things to note:

• The Avalon standard uses a signal called waitrequest", with the HPCII controller this signal is called local_ready and has inverse behavior to waitrequest, ie. you wait when local_ready is low.
• "beginbursttransfer" must go high for only one cycle when command is requested
• All other signals must remain constant once a transfer has been requested until waitrequest goes low
• Note that although bursting is requested, write data doesn’t have to be provided on consecutive clock cycles however all burst words must be provided before any further commands

 

Basic Avalon reads

The following diagram shows the basic behavior for an Avalon read transfer. 

7/7e/Basic_avalon_read.jpg  ( Basic avalon read.jpg - click here to view image )

Important things to note:

• Again, "beginbursttransfer" must go high for only one cycle when command is requested and other signals must remain constant until waitrequest goes low
• The above waveform shows two pipelined reads
• Read bursts always assumes the read is from consecutive address starting with the requested address
• "readdatavalid" indicates back to the master when to take the data
• Data for each burst request may not necessarily come back on consecutive clock cycles

 

Half rate accesses with HPCII and DDR3

Using DDR3 as an example, DDR3 specification requires accesses in bursts of 8 cycles (BL = 8). For a 64 bit DIMM this means 512 bits (64 x8) of data for each transfer (typically).

 4/4e/DDR3_x64_DDR_to_HR_bandwidth_calc.jpg ( DDR3 x64 DDR to HR bandwidth calc.jpg - click here to view image )

A half rate HPCII controller has a local data bus width of 256bits and thus with typical operation writes will have local_size = 2, ie. two beats to provide 512 bits of data for a full burst.

 

Example transfers

Click on any waveform for a higher resolution image. 

Typical half rate write - local_size = 2

d/d6/HPCII_half_rate_write_with_local_size%3D2.jpg

 ( HPCII half rate write with local size=2.jpg - click here to view image )

Half rate write - local _size = 1 with burst merging

Note: it take as few transfers requests in the HPCII's command FIFO before it starts making use of the burst merging feature

6/63/HPCII_half_rate_write_with_local_size%3D1_and_burst_merging.jpg

( HPCII half rate write with local size=1 and burst merging.jpg - click here to view image )

Typical half rate read - local_size = 2

e/ee/HPCII_half_rate_read_with_local_size%3D2.jpg

 ( HPCII half rate read with local size=2.jpg - click here to view image )

Half rate read - local size = 1

5/5c/HPCII_single_half_rate_read_with_local_size%3D1.jpg

(HPCII single half rate read with local size=1.jpg - click here to view image )

Half rate read - local_size = 1 with burst merging

Note: it take as few transfers requests in the HPCII's command FIFO before it starts making use of the burst merging feature

b/bf/HPCII_half_rate_read_with_local_size%3D1_and_burst_merging.jpg

( HPCII half rate read with local size=1 and burst merging.jpg - click here to view image )

 

HPCII addressing

 The local_address signal does not translate 1:1 to external memory address. On the local side there is a new address location for each beat as shown in the following table for the DDR3 half rate case:

c/c1/HPCII_addressing_example.jpg ( HPCII addressing example.jpg - click here to view image )

Also, external memory interface address my have special address bits for controller certain features. In the above waveforms for DDR3 we can observe auto precharge (A10) and burst chop (A12) being used. 

As as example above in the typical half rate write with local_size = 2

local side address 10d translated to external memory address mem_a = 1428h

10d x 4 = 40d = 28h 

and with precharge high and burst chop off = 1428h

See your external memory vendor's datasheet for more details.

 

Other HPCII local side signals

See the Altera EMI handbook for description (link below):

• local_refresh_req
• local_refresh_ack
• local_refresh_chip
• local_self_rfsh_req
• local_self_rfsh_ack
• local_multicast
• local_init_done
• local_read_data_error
• local_power_down_ack
• local_ecc_interrupt
• global_reset_n
• soft_reset_n
• pll_ref_clk
• phy_clk
• reset_phy_clk_n
• aux_full_rate_clk
• aux_half_rate_clk
• dll_reference_clk

 

Notes/Comments

• Modelsim Altera Starter Edition 6.5b was used for this investigation

 

Update History

1. Page creation - November 16th 2010

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
3. Altera's Avalon Interface Specification

Key Words

HPCII, External Memory Controller, High Performance Controller, Interface, Avalon, local side, burst transfers

© 2010 Altera Corporation. The material in this wiki page or document is provided AS-IS and is not

supported by Altera Corporation. Use the material in this document at your own risk; it might be, for example, objectionable,

misleading or inaccurate.Retrieved from http://www.alterawiki.com/wiki/Altera_Wiki