Implications of dynamic frequency scaling in an embedded system

Question

Dynamic frequency scaling is used to increase or decrease the speed of a processor to conserve power, heat, etc. I've seen my own processor fluctuate between 3GHz and 3.5GHz.

What are the implications of the clock frequency changing? There's a 500MHz difference going on in my example above. Are there any design considerations in an embedded device that must be observed when designing for a variable clock? Is there dangers in a device controlling its own clock rate?

Assume in the design scenario we have no power, heat, or any other physical limitations. The device's clock can be set to any frequency.

Answer 1

Yes, of course there are issues. If the new clock frequency is generated by a PLL then you must allow time for the PLL to settle and lock to the new frequency.

If you increase the clock frequency you may also need to increase the operating voltage of the core. On the other hand, if you lower the frequency you may want to decrease the core voltage to save power.

Many peripherals are unable to run at the same frequency as the system clock, so if you increase the system clock you may need to change the divider values used to create the peripheral clocks.

Some peripherals, such as UARTs, use clock dividers to generate specific frequencies. If you change the system clock these dividers may also need to be adjusted.

If you increase the system clock you may need to add "wait states" to accesses of slower memory devices, such as flash memory. Alternatively, you could copy the executable code to RAM and execute from there.

As an example of a microcontroller where these issues are relevant, see the MSP432.

Answer 2

For the vast majority of embedded systems, it doesn't make sense to change CPU clock dynamically. Simply because the PC computer heat problem doesn't exist in microcontrollers.

When you use PLL/FLL to set the system frequency, it is most often a one-time setup. Which is always a matter of execution speed versus current consumption. On most MCUs you have to configure flash "wait states" according to the clock speed. Very simplified: if the flash memory can't be read as fast as the CPU is running, the CPU has to wait between reads (in practice, it doesn't always do, since there's pipelining, branch prediction and cache).

But the only kind of dynamic clock changes you'll likely see, is when you have low current specifications, where the clock and execution will stop entirely, the core put "asleep" until woken again by an external interrupt. More advanced setups may exist, where you have a running mode and low power mode, with the CPU performing low priority calculations at slow speed instead of sleeping, but that's quite a special case.