Should I Use the Built-In PMU on the i.MX6SoloLite for Voltage Generation (I Want LOWEST Power in Idle Mode)?

cancel
Showing results for 
Search instead for 
Did you mean: 

Should I Use the Built-In PMU on the i.MX6SoloLite for Voltage Generation (I Want LOWEST Power in Idle Mode)?

Jump to solution
1,323 Views
nathanpalmer
Contributor IV

I am trying to decide between using the built in PMU or using an external PMIC to generate chip voltages for an i.MX6SL.

The Reference Manual for the i.MX6SL states that the internal PMU can be used to simplify the power distribution network for a design, but to get optimal power the PMU should not be used.  I would like to understand why this is.

I understand that if the PMU is to generate several different voltages then I will have to supply at least the MAX of those voltages to the PMU.  The PMU will then lose some energy in the switchers/LDOs and that could decrease power efficiency.  Is that what the Manual is warning about? because if so, wouldn't the same (or similar) energy be lost using an external (non-PMU) switcher/LDO?   Also, can I still use dynamic voltage scaling if the voltages are generated outside of the chip?

Any information on this would be appreciated, Thanks!

Labels (2)
0 Kudos
1 Solution
334 Views
AnsonHuang
NXP Employee
NXP Employee

HI, Nathan

       Yes, PF0100 is the preferred PMIC, it is verified on our reference design. We use it on our reference design with both internal PMU enabled and bypass mode. our recommendation is to use bypass mode if there is external programmable PMIC, as it can save power.

       Yes, using DVFS will need to scale PF0100's voltage via I2C/SPI interface, we use I2C on our boards. Internal DVFS, do you mean internal DVFS hardware module? Even use it, you still need to scale PF0100's voltage via I2C/SPI, but we do not recommend to use internal DVFS, we use software module called CPUFreq in Linux, it is better than hardware DVFS, it can improve peripheral devices' performance, as we can customize CPUFreq's governor using different policy, but hardware DVFS can NOT achieve it, like, we can adding interrupt number monitor into CPUFreq. Anyway, our BSP use CPUFreq which is better.

       BTW, please close this question if you did not have further question, if you have, do not hesitate to contact me.

View solution in original post

0 Kudos
11 Replies
334 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Nathan

You are right, if using internal PMU, then the input of the PMU much be higher than the output, actually it must at least 125mV higher in order to make sure the drive capability of PMU is enough. So, take the ARM CORE power rail running at 1G for example, if not using PMU, then the power tree can be external 4.2V to external PMIC input, then PMIC's DCDC converter output a 1.25V for ARM CORE. The PMIC's DCDC effiency is very high, normally > 85%. But if using internal PMU, you will also need a 4.2V to external PMIC, then PMIC output a 1.375V to PMU, PMU use LDO to make a 1.25V for ARM CORE. The LDO's effiency is lower than DCDC, so there will be a second level power waste. We have done some power number comparison between using and not using PMU, it can be ~10% power saved if not using internal PMU.

So, our suggestion is that if there is a programmable external PMIC on your design, you can ignore the PMU, if there is only some fix voltage input source which voltage can not be changed on your design, you have to use PMU to do voltage scale for DVFS.

0 Kudos
334 Views
sujithkv
Contributor I

Hello Yongcai,

We are facing an issue which we suspect related to PMU with our custom board, based on iMX6Q. Initially we had taken our reference from SABRE-lite (Hence SABRE-lite board file is used), and the Android Kernel we ported worked with the P version of i.MX6Q (the Prerelease version). We are relying on internal regulator and there is no external PMIC available in the custom board.

But with the latest version of i.MX6Q, the Android Kernel crashes randomly with SMP enabled. But if we disable SMP and activate only one core, the crash is not observed. We also changed the output voltage of the external regulator from 1.2v to 1.375v, but still crash is observed with SMP.

Can we go ahead tweaking the PMU registers relying on internal voltage regulator for i.MX6Q to run in SMP mode ? If yes, any example configuration is there ?

Is there any reason that Freescale used external PMIC and didnt rely on internal regulator for SABRE-SD boards ? 

Thanks in advance for the help.

Cheers,

Sujith.

0 Kudos
334 Views
AnsonHuang
NXP Employee
NXP Employee

HI, Sujith

         I think it is not related to SMP, when you mean latest I.MX6Q, is it TO1.2? There is LDO patch available in our website, but first you need to identify when it is the same issue, can you build out CPUFreq or just use performance governor? This is to disable DVFS, if it works on SMP, then I think it is the LDO ramp up issue, patch is ready.

         Just build out the CPUFreq via menu config and try it first.

          There is no issue with our internal LDO, we use bypass mode is just toDave power, actually we also support LDO enable mode, just pass ldo_active=on to kernel command line will make internal LDO enabled. There should be no direct relationship between SMP and LDO, the only reason may be SMP's loading is more heavy, but even using one core, the issue should be still there once the whole system loading is heavy.

0 Kudos
334 Views
sujithkv
Contributor I

Hi Yongcai,

Thanks for the quick reply. The SOC version printed on the chip is imx6q5eym12ac.

We checked by removing CONFIG_CPU_FREQ_IMX  option in the defconfig and it works with SMP. Then we checked the LDO patch you mentioned and found that its already included in the kernel version we are using.

For testing purpose we added debug prints (mx6_set_cpu_freq() in "arch/arm/plat-mxc/dvfs_core.c") in the DVFS enabled code and we found that the crashing happens after it switches to 396Mhz.

As a next step, in DVFS enabled code, we changed static struct cpu_op mx6q_cpu_op_1G[] .cpu_voltage = 950000 to .cpu_voltage = 1250000 and found that it doesnt crash. But when the SOC is going to suspend, it never wakes up.

What could be going wrong here ?  What else we can verify ?

Thanks for your help.

Cheers,

Sujith.

0 Kudos
334 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Sujith

     We didn't use arch/arm/plat-mxc/dvfs_core.c anymore, we use linux common CPUFreq framework, and platform specific code is in arch/arm/plat-mxc/cpufreq.c, the dvfs_core.c is disable by default, do you enable it manually? We do NOT recommend to use this module anymore.

     So, please use default CPUFreq driver to have a try, if it still fail, please figure out the fail point, from which setpoint to which setpoint, for example, please figure out whether everytime it fail at from 1G to 396MHz cpu freq change, it yes, then increase 396MHz's voltage by 25mV and redo the test, I suspect it is the board ripple issue, it would be better if you can measure the board ripple as well on VDDARM_CAP.

0 Kudos
334 Views
sujithkv
Contributor I

Hi Yongcai,

I Have checked in the code and found that we are using CPU frequency driver only and dvfs is already in disabled state.

We also tried to increase the VDD ARM IN from external power supply to SoC from 1.2V to 1.4V, then crash is happening at 996 MHz setpoint, crash is there even after increasing voltage by 25mV for this perticular freq. set point. We have not found any ripples on VDDARM_CAP.

1) What should be the actual VDDARM_IN voltage? as per specification it should be around 1.375 V, however it is not poperly working on our custom desing board.

2) What could be another reason for this?

3) Any suggestion about how to verify our VDD ARM IN power rail design?  FYI we have not used any external PMIC.

0 Kudos
334 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Sujith

1) What should be the actual VDDARM_IN voltage? as per specification it should be around 1.375 V, however it is not poperly working on our custom desing board.

[Anson] The VDDARM_IN should be at least 125mV higher than VDDARM_CAP, so 1.375V is enough for 1GHz, as VDDARM_CAP's voltage @1GHz is 1.225V on spec.

2) What could be another reason for this?

[Anson] So far, I only know board level ripple could impact it, but you said there is no ripple on your board. So next step, you can try below:

1. remove some setpoint and redo the test to see whether it is caused by some dedicated setpoint;

2. use 1GHz's setpoint's voltage for all setpoint to do test, this is to see whether it is caused by voltage issue.

3. the suspend/resume should not be related to suspend/resume.

3) Any suggestion about how to verify our VDD ARM IN power rail design?  FYI we have not used any external PMIC.

[Anson] the rule is VDDARM_IN should be at least 125mV higher than VDDARM_CAP.

0 Kudos
334 Views
nathanpalmer
Contributor IV

Thanks for the response, that makes sense.

I think I would generate the rails externally to save as much power as possible.  Is the PF0100 still the preferred PMIC for the MX6SL, even if bypassing the PMU and generating the rails externally? 

I would like to use DVFS so I assume I would have to do the voltage scaling through the SPI interface to the PF0100?  I was hoping to use the internal DVFS because it seems so convenient.

0 Kudos
335 Views
AnsonHuang
NXP Employee
NXP Employee

HI, Nathan

       Yes, PF0100 is the preferred PMIC, it is verified on our reference design. We use it on our reference design with both internal PMU enabled and bypass mode. our recommendation is to use bypass mode if there is external programmable PMIC, as it can save power.

       Yes, using DVFS will need to scale PF0100's voltage via I2C/SPI interface, we use I2C on our boards. Internal DVFS, do you mean internal DVFS hardware module? Even use it, you still need to scale PF0100's voltage via I2C/SPI, but we do not recommend to use internal DVFS, we use software module called CPUFreq in Linux, it is better than hardware DVFS, it can improve peripheral devices' performance, as we can customize CPUFreq's governor using different policy, but hardware DVFS can NOT achieve it, like, we can adding interrupt number monitor into CPUFreq. Anyway, our BSP use CPUFreq which is better.

       BTW, please close this question if you did not have further question, if you have, do not hesitate to contact me.

View solution in original post

0 Kudos
334 Views
nathanpalmer
Contributor IV

Yongcai,  Sorry to reopen this issue, but upon further digging into the RM I read that (on imx6sl RM page:379):

"The power management system is built under assumption that in typical applications the single (and simple) shared power supply will be used for ARM core domain and SoC domain. The combined load gains some efficiency, especially in low power modes and saves BoM significantly."  and it made me think there may be some advantage to the internal PMU LDOs in low power modes.

I just wanted to note that our design will:

- Likely use the PF0100 PMIC (although I cannot find the F3 version available for sale which could be a problem)

- be operating low power modes most of the time, and will likely not ever even run at the full 1GHz speed

- will not be running Linux, so CPUFreq is not an option


Is there still an advantage to (1) using the external (i2c) DVFS mode? and (2) bypassing the internal PMU when operating in low power modes?

0 Kudos
334 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Nathan

     So you want to use PF0100, and there will be no CPUFreq on your SW system? Which means you will make SOC run at fix freq?

     From what I know, bypassing the internal PMU would always have advantage towards enabling internal PMUs... But if you do NOT care about the power but focus on the cost, then internal PMU can be enabled and not need an external PF0100.

0 Kudos