HIgh power consumption in LPDDR3 EMIF interface Arria 10

We now think that calibration never finishes, neither success nor failure. Is this possible? What might cause it?

Clearer statement of problem:

Device: 10AX022C3U19I2LG

Attached memory: MT52L256M32D1PF

Uses Bank 2J for mem_dq and mem_dqs/mem_dqs_n according to LPDDR3 scheme 1. Quartus validates.

Uses Bank 2K for control, address and reference clock (CLK_2K_1p/n), again using LPDDR3 scheme 1. Quartus validates.

Device operates under control of external ARM, and that interface works.

When the board starts, an unreasonable amount of power is consumed in the FPGA and it gets too hot to touch.

LPDDR3 calibration results both inactive.

When the EMIF section is held in reset by an ARM-controlled signal, the excess power stops.

We do not think this is a short as there is no damage to the board. Is there something we should check?

Hi KCMurphy,

Is the power supply has been delivered with a correct value?

Do you see a similar issue with other board if possible?

Thanks.

I asked these questions, too. I have been assured that it is. An LTC2937 is used to sequence power. Power stability is critical to the application (communications DSP) and great care was taken to follow the power-up rules for the Arria and other devices.

At this time there is only the one board. The Arria's other logic behaves correctly; it is only when the LPDDR3 EMIF interface is released from reset (.global_reset_n) that the huge power draw occurs.

Following the release of reset, no activity is observed on the differential clock (or any other line) going to the Micron LPDDR3 ram. The testing engineer reports that the CKp line out to the RAM (B13 on the Arria U19) is pulled up to 1.2V before Arria configuration. Afterwards it floats with little or no drive current.

A Questa simulation of the full calibration process, using a Micron model for the RAM, succeeds in "calibration" in roughly 3.5mS sim time. Yet we see nothing of the sort in the real world.

We find all of this very surprising as our group has been using Altera (now Intel) parts since the last century and have never run across a difficulty of this sort. They usually just work. This is, of course, a critical problem for our project.

Hello,

I'm glad that your problem has been solved.

May I know which document that you're referred to?

Regards,

Adzim

Reference document: https://www.intel.com/content/www/us/en/docs/programmable/683814/current/transceiver-pins.html

https://www.intel.com/content/www/us/en/docs/programmable/683814/current.html

Table 11

But neither of these are likely to be found by folks not using transceivers. When only using PLLs, such as for an EMIF, there is really no good path to this information.

See also here: https://community.intel.com/t5/Programmable-Devices/Arria-10-IOPLL-not-locking/m-p/1301857#M80855