PLL vs FLL vs Power Consumption?

[dougpaulsen]

Is there any documentation regarding Coldfire power consumption when running PLL clock modes versus FLL clock modes versus neither?

I appreciate this is a complex subject and numerous variables are involved, but this particular ColdfireV1 project is found to draw 3-4 times the current it was expected to use.  A little burn 'n learn later, is was determined using PLL was the culprit.  In BPLPE mode, current consumption was as calculated.  Alas, the project code was premised on higher clock rates derived from using PLL.

If one googles around a bit, there are occasional comments that PLL modes are the most power hungry (and the most accurate clocks), FLL are less so in both categories, but that's essentially the level of detail that is presented.

Thanks for any clarification, although it looks in this case like compromises are in the future.

Doug

[TomE]

Which "ColdfireV1" are you using?

I've just looked through a few MCF51 Data Sheets. The lack of a section giving current consumption for when the PLL is enabled is rather glaring.

I'd say you're going to have to perform these measurements yourself. You should be able to set up tests with the PLL off and the PLL on but not driving the CPU (if that is possible) to get the consumption of the PLL block on its own. You can also do this at different PLL frequencies to see if it goes up much.

Then you can run the CPU at different PLL frequencies and measure the current. It should fall on a straight line.

It is also worth running the CPU from the PLL and seeing how much the CPU current drops in various STOP modes.

To a first approximation, modern CPUs should take a constant amount of ENERGY per instruction. So if you go from running at a low frequency with the CPU busy all the time to (say) running at four times the clock rate, but STOPped 3/4 of the time it should take the same average current (plus overhead for the clock distribution and peripherals getting the faster clock).

That also means that if power consumption is important, your code shouldn't run a "busy idle loop", but should STOP when there's nothing to do.

Tom

[dougpaulsen]

Tom:

I appreciate your comments, particularly your confirming that other power consumption numbers aren't hidden somewhere overlooked.  I feel by not identifying much higher current consumption under PLL and FLL modes (which is the default), Freescale imply the power needs are consistent regardless of the selected mode.  This might be a suspicious assumption to knowledgeable hardware types, but I'm not one those.  Now we have hardware in the pipeline which may be insufficient for our needs. 

I will admit being informed of a mysteriously high current early on in the prototypes, but it wasn't pursued until now so I am culpable for the situation.  It's now time for firmware to save the day, but I having real problems interfacing a much slower non-PLLed microprocessor with critical peripherals.

By the way, we're using the MCF51.

Thanks!

Doug

[TomE]

> By the way, we're using the MCF51.

Which MCF51? There's the AC, AG, CN, EM, JE, JF, JM, JU, MM, QE and QU.

> Now we have hardware in the pipeline which may be insufficient for our needs.

> but I having real problems interfacing a much slower non-PLLed microprocessor with critical peripherals.

What are your requirements? Is it battery powered? What is your allowable power budget? What's the I/O? Someone reading this might have done something like this already.

If you don't need the full 50 MIPs 100% of the time then it is possible that a mixture of clock and power saving modes running at a controlled duty-cycle might allow it to do what you you need it to do. There's always a way to optimise the code to make it more efficient and able to get the processing done for less instructions with a bit of work.

Tom

[dougpaulsen]

Tom:

We're using the MCF51AC256A.  And it's chugging along at a relatively modest 9.8304 MHz.

The situation is complicated in that this is an update of an old, proven design.  The Freescale's PWM outputs replace dedicated clock and baud rate generator circuitry to a Zilog SCC.  We have long experience with known inputs to this peripheral so a proven code base can be largely copied over, and with a very high confidence the results will be completely backwards compatible synchronous communications (very, very important). Without the expected use of PLL, the SCC PCLK will have to run at a quarter the old designs speed (if it will work at all: scoping the PWM outputs find they are distinctly loosing their square wave symmetry due to granularity)..

The design is not battery powered, but as part of a larger system, the power was strictly budgeted.  Any reshuffling at this point causes managers great angst, and that has a distinct and rapid trickle down effect.  And since this is all about communications, the Freescale/SCC combo has to run full bore all the time.

Looks like the classic rock-and-a-hard-place dilemma...

[TomE]

> dedicated clock and baud rate generator circuitry to a Zilog SCC

You can still buy them? I had a lot of fun getting Apple's LocalTalk running on those in the 1980's. The only thing worse than that was getting it working on the ISCC chips, which had more problems.

You do know about the horrible requirement to leave long gaps between SCC register accesses, don't you? There'll probably be NOPs or delays in the existing code that will have to be made longer with a faster CPU.

You should still follow the advice I gave in my first post and MEASURE the current taken under different conditions.

You should be able to get the current down by having the CPU running (say) 1/4 of the time on a 4-times PLL multipler as it running 100% of the time without the PLL. You HAVE to use the "STOP" instruction, but set up so it just stops the CPU without going into any of the more aggressive lower-power stop modes.

This should be quite easy to get working.

Tom