David Kanter (dkanter.delete@this.realworldtech.com) on September 12, 2021 10:58 pm wrote:
> > One of the biggest issues that the traditional companies is that they have not understood power efficient
> > DVFS. Years ago, Intel engineers lambasted schemes like big.LITTLE because it was "not hardware controlled"
> > - but you precisely do not want ultra-fine grained DVFS like that for several reasons.
>
> >In battery powered
> > devices the whole point of DVFS was to avoid the higher
> > performance states and voltages as much as possible,
> > and what matters here is the delivery of performance within a unit of user experience, essentially a 16ms
> > or 8ms frame, which is AGES.
>
> Isn't the point to deliver max perf with min energy?
>
> >The act of frequency and voltage change itself takes up quite a bit of energy
> > and you literally do not want to do it that fast because it actually would be more efficient to smooth out
> > performance over the duration of your frame at a lower state, or clock/power-gate at smaller idle periods
> > rather than to DVFS down.
>
> That depends on several things:
>
> 1. Latency of adjusting voltage
> 2. Latency of adjusting the clock
> 3. Penalties associated with changing V or F
>
> For a system with a 120MHz FIVR, you can adjust voltage pretty quickly compared to that 8ms period.
>
> It is quite possible to change clocks in a small number of cycles, depending on your clocking architecture.
>
> Again - if you look at an 8ms period, that's 24M clock cycles. I think burning around 1-2% of those on voltage
> and frequency transition shouldn't be an issue compared to possible gains, although this is a guess.
>
> One issue is that I suspect many designs impose long penalties for
> voltage/clock transitions. But that's a choice, not a limitation.
>
> David


> Isn't the point to deliver max perf with min energy?

The point is that your window of user experience is 16/8ms. If the workload completes interactively to fill that "QoS" at the current frequency without going over a utilisation threshold in that sliding window, you *do not want to go any higher*.

So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher voltages for no gain in user performance. Fmax should only every be reached and triggered after continuous load of 2-3x of user experience window - current mobile phones do that in around 40-50ms, anything faster than that is waste of energy and battery life. These are not HW limitations, but learning the hard way what the most efficient way to design battery powered DVFS logic.