FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6485 Discussions

HIgh power consumption in LPDDR3 EMIF interface Arria 10

KCMurphy
New Contributor II
996 Views

We have a custom-built board using an Arria 10 as a DSP engine.  Part of the design has the Arria 10's hard EMIF controller configured to control a 32-bit wide LPDDR3 memory IC.

 

The pinout for this section is below.  It conforms to the pin placement restrictions inherent in the Quartus Pro software.  The reference clock to the memory is 209MHz and the memory operates at half-rate or 418MHz.

 

The problem is that, the moment the EMIF controller is released from reset and the reference clock is applied, the part draws several watts more power than otherwise and things get quite warm.   It is noted that many of the lines to the external memory are floating at this time, including the clocks.  We don't think this is a board short as there is no smoke or fire.

 

When the part is initialized and only the EMIF controller is held in reset, the high current drain does not occur.

 

Is there some configuration issue that could cause this?

Device:  10AX022C3U19I2LG

Attached memory: MT52L256M32D1PF

0 Kudos
1 Solution
KCMurphy
New Contributor II
905 Views

Solved:  The gift that keeps on giving.

 

RREF_BL and RREF_TL, 2K resistor to ground.

 

Probably want to revise the docs to make this clearer to people who are not using the transceivers.

View solution in original post

0 Kudos
8 Replies
KCMurphy
New Contributor II
970 Views

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

0 Kudos
KCMurphy
New Contributor II
958 Views

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?

 

0 Kudos
AdzimZM_Intel
Employee
927 Views

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.


0 Kudos
KCMurphy
New Contributor II
919 Views

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.

0 Kudos
KCMurphy
New Contributor II
906 Views

Solved:  The gift that keeps on giving.

 

RREF_BL and RREF_TL, 2K resistor to ground.

 

Probably want to revise the docs to make this clearer to people who are not using the transceivers.

0 Kudos
AdzimZM_Intel
Employee
891 Views

Hello,


I'm glad that your problem has been solved.


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


Regards,

Adzim


0 Kudos
KCMurphy
New Contributor II
883 Views

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

0 Kudos
Reply