Zynq: LPDDR2 worth it?

[tom66]

We are looking at respinning a design with a Zynq 7010 on it.

The design currently has some DDR3L on it, 1.35V, running at 533MHz,  x16 single chip configuration, 2Gbit/256MB.  Power consumption of the DRAM block under normal operation is around 100mW, and under significant memory operations is around 350mW.  That's quite significant for our power budget.

I have considered moving the design over to LPDDR2, as Zynq has support for some devices which are Long-Term Buy from Micron.  We would benefit from using a single chip to get a 32-bit interface, allowing the chip to be downclocked and still maintain our performance requirements, and possibly also benefit from overall lower power consumption of LPDDR2.  I know LPDDR2 isn't clock for clock as fast as DDR3, but we're not in need of the most performance except in very specific circumstances and can tune the device to work well there if needed.

What I cannot find is data on how substantial the saving is on Zynq or similar platforms.  Has anyone had any experience with this?  Was it worth doing in your design?  I am aware of memory power consumption calculators but it's not trivial to measure some of the parameters on our system.

Any input appreciated.

[asmi]

I haven't tried LPDDR2, but from what I know the biggest power savings of LP memory come from PASR (partial array self-refresh), which can refresh only part of entire memory array if not all memory is used by your application. In your case I would begin with downclocking the memory and CPU to see if power savings is worth the performance loss, as well as review your application code so it would spend more time in a WFI/WFE (or whatever it's called in ARM) as well as in low-power modes. Also audit PS peripherals configuration and ensure unused peripherals are powered down and clock-gated whenever possible.

Finally, if your memory interface has termination resistors for address/control lines, try getting rid of them to see if design would still work. Termination consumes power too, I remember reading somewhere the rule of thumb is approximately 1 mW per resistor for DDR3, it's likely slightly less for DDR3L due to lower voltage swing requirement, but since you have ~20 of them, that's a 20 mW down the drain, and it's a constant draw because DDR3 is terminated to Vdq/2, so the logic value only determines a direction of a current (source or sink), but the current magnitude (and therefore power loss) stays the same. If you combine downclocking of DDR controller with removal of termination resistors, you can still get it to work (DDR3 can be downclocked down to 300 MHz AFAIR).

I've attended Xilinx webinar about minimizing power consumption, and it basically revolved around power-gating (things like turning off Vccio supplies if IO of the bank are not used), clock-gating and dynamic down-clocking of certain parts of your design. I've attached a presentation from that webinar if you're curious.

[BrianHG]

Not just disabling the termination.  If you are running at <= 400mhz/800mtps, with a single DDR chip, you can also try lowering the IO drive current on the DDR3 and Zynq IOs to minimum.  This will lower power consumption during long sequential bursts.  However, this will not help as much with random tiny BL8 read and writes.

[tom66]

Thanks guys.

We already have termination removed. The board was designed with it because we didn't know if we could get away without it but experimentation revealed it was stable without it.  (We also had someone simulate the design to calculate under/overshoot and settling times and they said it was ok without termination.)  The 40R terminators at 0.675V  Vtt dissipate roughly 11mW each if the IO is driving a state and there's one for each address bit then RAS, CAS, CS, WE, CKE and maybe ODT.  I don't know if the address lines can tristate or not, but it's probably in the region of 100-200mW of power dissipation in that alone saved without termination.

I'll look into drive strength.  Is that a kernel option?  I didn't see any way to change it at the devicetree/Vivado level.

[asmi]

We already have termination removed. The board was designed with it because we didn't know if we could get away without it but experimentation revealed it was stable without it.  (We also had someone simulate the design to calculate under/overshoot and settling times and they said it was ok without termination.) 

I did quite a bit of simulations myself, and my conclusion was that if all your connections are point-to-point (meaning a single memory device), and your traces are short, then at least for 533 MHz and below you don't need termination.

The 40R terminators at 0.675V  Vtt dissipate roughly 11mW each if the IO is driving a state and there's one for each address bit then RAS, CAS, CS, WE, CKE and maybe ODT. 

A spec only demands a swing of 0.1 - 0.2 V from Vref for a logic level to register as a zero or one, so these lines never go all the way to 0 V or Vddq. Which I guess is where the rule of thumb I mentioned came from: 0.2 V / 40 Ohm = 5 mA, 5 mA * 0.2 V = 1 mW.

I don't know if the address lines can tristate or not, but it's probably in the region of 100-200mW of power dissipation in that alone saved without termination.

I don't think they can because DDR3 spec requires CK/CK# to be a free-running clock and so address/control must have a valid levels at all times the clock is running to prevent registering spurious commands.

I'll look into drive strength. 

According to Zynq TRM, there are some registers which control it, but they are not documented and you are not supposed to mess with them manually.

Is that a kernel option?  I didn't see any way to change it at the devicetree/Vivado level.

Oh, you're running Linux on that and expect a super high power efficiency? Get rid of Linux and go baremetal, this by itself will save you a ton of power.

[tom66]

The 40R terminators at 0.675V  Vtt dissipate roughly 11mW each if the IO is driving a state and there's one for each address bit then RAS, CAS, CS, WE, CKE and maybe ODT. 

A spec only demands a swing of 0.1 - 0.2 V from Vref for a logic level to register as a zero or one, so these lines never go all the way to 0 V or Vddq. Which I guess is where the rule of thumb I mentioned came from: 0.2 V / 40 Ohm = 5 mA, 5 mA * 0.2 V = 1 mW.

That surprises me, I have looked at RAS and CAS on the scope before and seen swings almost all the way to Vdd and Vss.  (Used the 2GHz Siglent scope we had with a soldered on test lead.)  Is this driver dependent?  It certainly seems like the Zynq uses most/all of the swing for address/ctrl.  Not sure about data lines as no easily accessible test pads on current board (an omission I will look to correct.)

Oh, you're running Linux on that and expect a super high power efficiency? Get rid of Linux and go baremetal, this by itself will save you a ton of power.

Can't, unfortunately, our stack is all dependent on things like Linux networking, file I/O, caching etc.  A huge amount to rewrite and not worth it for a tiny power saving.  Linux does have decent power management on Zynq, it can use cpuidle and suspend, but we can't do some of the more advanced stuff like switching DRAM to self refresh in idle state, without modifying the kernel.  Our application does require the CPU to be available most of the time, so I don't know that it makes that much difference.

[asmi]

That surprises me, I have looked at RAS and CAS on the scope before and seen swings almost all the way to Vdd and Vss.  (Used the 2GHz Siglent scope we had with a soldered on test lead.)  Is this driver dependent?  It certainly seems like the Zynq uses most/all of the swing for address/ctrl.  Not sure about data lines as no easily accessible test pads on current board (an omission I will look to correct.)

I don't have the equipment to check myself (I would love to, but it's too damn expensive!), so I'm going off of what specs and manufacturers' appnotes say on this. Unfortunately, I couldn't find the source of that 1mW number in my documents library, so take it as unconfirmed for now as I can't remember where exactly I got this number from. The driver side probably drives this all the way to 0 or Vddq, but termination is at the receiving end, and so the swing isn't going to be as dramatic due to transmission line losses, at least during operation, and DDR3L memory modules datasheet only requires 0.1-0.175 V offset from Vref to register a valid level, so one can use lower drive levels to still have interface working and yet reduce reflections. Zynq of course can only drive memory at 533 MHz max, which is a far cry from 933 MHz top JEDEC spec, so it's drivers are not super-high strength, which actually helps with termination-less connections.

Can't, unfortunately, our stack is all dependent on things like Linux networking, file I/O, caching etc.  A huge amount to rewrite and not worth it for a tiny power saving.  Linux does have decent power management on Zynq, it can use cpuidle and suspend, but we can't do some of the more advanced stuff like switching DRAM to self refresh in idle state, without modifying the kernel.  Our application does require the CPU to be available most of the time, so I don't know that it makes that much difference.

In this case I'd suggest to inspect your kernel/services config with a magnifying glass and disable everything that you don't need, there is a lot of stuff there than can potentially consume CPU resources. Also like I said above try downclocking everything and see if you get any benefit at all (evey SoC has a "sweet spot" mode in which it's the most efficient, but that is typically not the top clock frequency, but not the lowest one either).
On a hardware side, you might want to have a look at your PDS design and see if you can increase it's efficiency as well. Most DC-DC designs involve trades of solution size vs cost vs efficiency, so you can gain some efficiency by using lower ESR inductor (which are typically largers and/or more expensive), you can also use switchers which support margining and bring all rails closer to the lower end of the spec, or even lower if combined with downclocking.
I also looked at LPDDR2 datasheet, and it looks like the current consumption is about the same as the same capacity DDR3L module, so I don't think it's going to be worth it, but of course if you decide to prototype it anyway to confirm, please let us know as hard facts always trump any theories.

[glenenglish]

LPDDR2 at 200 MHz clock, no termination, single device  is OK with 7010. leads to a very relaxed layout (anything will work !) if you use a 400 MHz clock device at 200 MHz.

and from memory, you could use a 8 bit wide device (I think)  to really simplify things (and slow down the app of course) .

Alliance and IM will have LPDDR2 for a long time yet, dont restrict yourself to Micron...

[cedric!]

Finally, if your memory interface has termination resistors for address/control lines, try getting rid of them to see if design would still work. Termination consumes power too, I remember reading somewhere the rule of thumb is approximately 1 mW per resistor for DDR3, it's likely slightly less for DDR3L due to lower voltage swing requirement, but since you have ~20 of them, that's a 20 mW down the drain, and it's a constant draw because DDR3 is terminated to Vdq/2, so the logic value only determines a direction of a current (source or sink), but the current magnitude (and therefore power loss) stays the same.

Disclaimer: I have not yet routed a DDR3 pcb, and I also never measured one.
I assume the fet driving the DDR3 signal line has a very low resistance, and the pin at the receiving end has a very high resistance. This causes both sides of the transmission line to reflect the signal back, resulting in the signal bouncing back and forth for a relatively long time.

I would consider placing a resistor in series with the driving FET, so the total impedance of the FET and the resistor matches the characteristic impedance of the PCB trace / stripline. The signal will still reflect back from the receiving pin, but it will then be correctly terminated, so the signal doesn't bounce back from the driving FET after that. 

I think this solution improves the signal quality, without power loss.

Is this assumption correct?
Would series termination be better than no termination?

[glenenglish]

@tom66
half a year on,  what did you end up doing with your design ?

I'm buying some LPDDR2 right now for a new 7010 design.  1Gbx 16. ....x32 is more layers, although it is very forgiving. using 533M parts at 250M.