DDR controller - best device to perform

A normal and 90 degrees phase shifted clock are all that is required to clock a DDR controller.

Not necessary for DDR (should be left disabled)

Yes, These are very necessary. Clock the signals as close to the IO pin as possible. The setup and hold times will vary more as the amount of logic increases which is something you don't want.

Useless. It will make the chip run very hot especially with many lines connected. Use series resistors on the board.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

It is a common misconception that DCI (on-chip termination) causes the chip to run hot. When used as serial (output) termination, the on-chip heat generated by DCI is insignificant. When used as parallel (input) Thevenin termination, the heat indeed is substantial. But an external series resistor is not the alternative to the parallel case... Peter Alfke

Also the best way is to use a SSTL2_II (without DCI) iostandard with output driver impedance 25Ohm and external parallel resistor?

PGW

I agree, but parallel termination is the only option for SSTL-II outputs. So if you want to connect a 32 bit wide DDR memory to a Spartan 3 device (like I did), DCI is not going to work.

The Spartan 3 ain't that fast. I know the I/O pins are specified to be able to run at 300MHz or so, but the internal logic won't allow that speed anyway in practical situations. I estimate the real life upper limit is about 150MHz.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Output pin in SSTL2_II IOSTANDARD has output driver impedance 25 Ohms is that not suffiecient? Additionally an external parallel 50 Ohms resistor connect to Vtt and output and input termination is done, I think.

--
PGW

For the perfect (or close to it) case. A practical DDR controller running at 200/400 or greater benefits greatly from having the ability to add/subtract a small delay around the 90 degrees. Whether the delay is useful depends on the application.

See above.

Agreed, but DDR should have a known impedance at the driver and receiver, which I believe the SSTL (II) IO standard provides.

>

It is not always necessary to parallel terminate data lines in DDR. If the system is point to point (only one bank physically) it's perfectly possible to series terminate the line with a little homework. Parallel termination is not an option for address and control, however.

Cheers

PeteS

I recently removed the series and parallel terminations from a Cyclone

3 dev board and ran the ddr interface at 133MHz. The interface worked overnight without a problem.

I think the trace length on the ddr signals is about 2-3 inches. They are point-to-point signals. The data bus is 16bits wide and is implemented using Altera's ALTMEMPHY megafunction. Further, I momentarily cooled down the memory and altera chips to -40degC and then heated them up to 125degC without any errors.

I see that without the series terminations there is a problem on the overshoot and undershoot. But it does not violate the specs of the fpga. On the memory side, the problem goes away when I use onchip series termination.

Almost all the address and control lines can be run at half the memory clock frequency so drive strength and termination can be relaxed.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

See this Samsung App Note:

Tim

The decision as to whether to parallel terminate is based on a number of things, as is the decision to simply series terminate. It depends on the application. Generally, if the data lines are point to point (2 connections only) you can get away with series termination (but it's not that simple - some thought needs to be given to the termination value) - if you have more than one endpoint, series termination is not possible for guaranteed operation, which is why series termination of address/control is generally not possible for guaranteed operation.

Cheers

PeteS

Hey

Thanks for your replies, all are very helpful. But I still don'y know which device to choose.

At the moment any information about Spartan3 component: IFDDRxxx, OFDDRxxx and CycloneII: altdq, altdqs will be appreciate.

Maybe someone have been using both and can compare them.

--
PGW

For Cyclone II devices you will find user guides on alt_dq and alt_dqs megafunctions on the Altera web site at

Note that on Cyclone III devices Altera has changed the design/ architecture of DDR/DDR2 interfaces to use a new megafunction called ALTMEMPHY. This new megafunction is included with all versions of the Quartus II software including the free Quartus II Web Edition. This function builds an autocalibrating DDR/DDR2 PHY interface (calibrates out PVT changes) with the goal of relieving designers from much of the timing analysis burden associated with static interfaces and reducing PLL resource needs for wider DDR interfaces. The calibration feature takes advantage of new dynamic phase adjustment circuitry included in the Cyclone III PLL. The PLL phase shift is adjusted at power up and automatically over time to place the read capture clock in the center of the data valid window for the memory data calibrating out changes over process, voltage, and temperature. Cyclone III devices also add 2 additional output registers in the I/O cell that improve write margin timing. The ALTMEMPHY user guide is available at

ALTMEMPHY users have the choice of using the Altera high performance (HP)controller, third party controller, or designing their own controller. The Altera HP controller is included with Altera software subscriptions. Performance specifications are available in the External Memory Interfaces chapter of the Cyclone III Handbook at

.

I hope you find this helpful.

For Cyclone II devices you will find user guides on alt_dq and alt_dqs megafunctions on the Altera web site at

Note that on Cyclone III devices Altera has changed the design/ architecture of DDR/DDR2 interfaces to use a new megafunction called ALTMEMPHY. This new megafunction is included with all versions of the Quartus II software including the free Quartus II Web Edition. This function builds an autocalibrating DDR/DDR2 PHY interface (calibrates out PVT changes) with the goal of relieving designers from much of the timing analysis burden associated with static interfaces and reducing PLL resource needs for wider DDR interfaces. The calibration feature takes advantage of new dynamic phase adjustment circuitry included in the Cyclone III PLL. The PLL phase shift is adjusted at power up and automatically over time to place the read capture clock in the center of the data valid window for the memory data calibrating out changes over process, voltage, and temperature. Cyclone III devices also add

2 additional output registers in the I/O cell that improve write margin timing. The ALTMEMPHY user guide is available at

ALTMEMPHY users have the choice of using the Altera high performance (HP) controller, third party controller, or designing their own controller. The Altera HP controller is included with Altera software subscriptions. Performance specifications are available in the External Memory Interfaces chapter of the Cyclone III Handbook at

.

I hope you find this helpful.

When trace lengths are below 1/100 of your clock's electrical wavelength, you can get away with lots of otherwise potentially nasty stuff. To reduce your overshoot, you could also experiment with programmable drive strengths from both FPGA and DRAM ends.

Thanks for your response. It's helpful.

--
PGW