By: --- (---.delete@this.redheron.com), September 13, 2021 1:06 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on September 13, 2021 11:57 am wrote:
> --- (---.delete@this.redheron.com) on September 13, 2021 11:19 am wrote:
> > - one thing Apple do (I don't know about other designs)
> > is slide voltage up and down while keeping frequency
> > unchanged. Obviously changing frequency is somewhat disruptive in a way that changing voltage is not.
> > Apple have some flexibility to do this given the digital
> > power estimators, a knowledge of the capacitance in
> > the system, and an ability to prevent catastrophe if the
> > system is oversubscribed by having instruction issue
> > paused by the DPE for a cycle or two. Maybe also the fact
> > that every SRAM is decoupled from logic with a voltage
> > shifter between the two, so you have flexibility to down-voltage logic while not losing SRAM retention.
> > (At least they have a long sequence of patents about this, so you'd hope it's implemented!)
>
>
> I'm a little confused on this point. Why would you want to alter voltage while keeping frequency
> constant? Shouldn't you always want to run at the lowest voltage capable of handling a given frequency
> to minimize power? In what circumstance would you for example want to increase voltage while keeping
> frequency constant? That makes no sense to me, but maybe I'm missing something.
>
I'm no expert at this low-level, but I think the primary issue is voltage droop.
Obviously an ideal power source would maintain the exact (varying) current you need at the exact (unvarying) voltage you request, but the reality is that as load changes, voltage will droop.
You can either deal with this by constantly operating at a higher voltage than absolutely necessary, or you can slide voltage up-and-down reactively, as I suggested -- but the closer you operate to the edge, the faster you need to be able to cope with an unexpected additional load.
Here's an example of what I'm talking about
https://patents.google.com/patent/US20150033045A1
Here's a more explicit version
https://patents.google.com/patent/US20150253836A1
with an update a few years later here
https://patents.google.com/patent/US10401938B1
(Note as you read these the reference to, for example, micro-architectural features of the core, like a particular pipeline, being powered down, which knowledge can be used to reduce voltage margin.)
Here's a really low level version (hardly relevant to the discussion except that it's in the same philosophical vein) tracking changes, by analog means, of the retention voltages required for individual SRAM sub-arrays; and switching the feed into those arrays by having each sub-array connected to a set of slightly different diodes, the optimal one of which at any give time feeds in power.
https://patents.google.com/patent/US9792979B1
Here's an example from the other side (rather than trying to operate at minimum voltage, ensure that maximum performance is achieved, but issue throttling will kick in if too many IP blocks all simultaneously go into high power)
https://patents.google.com/patent/US20140380071A1
There are multiple of these sorts of patents, covering different cases (for example the required/desired voltage can slide up and down as system temperature changes, as the system ages, etc). Some monitoring is done by the DPE's, some by various analog circuits.
Obviously at least some of this is being done by other companies (eg Intel are monitoring which of N cores on a die have the best efficiency so that those can be goosed an extra 100MHz when no other cores are active, whatever Turboboost version that one is called).
I make no claim for the uniqueness of what Apple is doing, simply that they track the whole set of possibilities
- very slow changes (aging)
- slow (by computer standards) changes like temperature
- fast change (IP blocks powering up and powering off)
- cycle to cycle changes (DPE, and preventing issue to limit exceeding spec)
and they provide enough separate voltage planes and islands to manage this on a very fine-grained scale.
> --- (---.delete@this.redheron.com) on September 13, 2021 11:19 am wrote:
> > - one thing Apple do (I don't know about other designs)
> > is slide voltage up and down while keeping frequency
> > unchanged. Obviously changing frequency is somewhat disruptive in a way that changing voltage is not.
> > Apple have some flexibility to do this given the digital
> > power estimators, a knowledge of the capacitance in
> > the system, and an ability to prevent catastrophe if the
> > system is oversubscribed by having instruction issue
> > paused by the DPE for a cycle or two. Maybe also the fact
> > that every SRAM is decoupled from logic with a voltage
> > shifter between the two, so you have flexibility to down-voltage logic while not losing SRAM retention.
> > (At least they have a long sequence of patents about this, so you'd hope it's implemented!)
>
>
> I'm a little confused on this point. Why would you want to alter voltage while keeping frequency
> constant? Shouldn't you always want to run at the lowest voltage capable of handling a given frequency
> to minimize power? In what circumstance would you for example want to increase voltage while keeping
> frequency constant? That makes no sense to me, but maybe I'm missing something.
>
I'm no expert at this low-level, but I think the primary issue is voltage droop.
Obviously an ideal power source would maintain the exact (varying) current you need at the exact (unvarying) voltage you request, but the reality is that as load changes, voltage will droop.
You can either deal with this by constantly operating at a higher voltage than absolutely necessary, or you can slide voltage up-and-down reactively, as I suggested -- but the closer you operate to the edge, the faster you need to be able to cope with an unexpected additional load.
Here's an example of what I'm talking about
https://patents.google.com/patent/US20150033045A1
Here's a more explicit version
https://patents.google.com/patent/US20150253836A1
with an update a few years later here
https://patents.google.com/patent/US10401938B1
(Note as you read these the reference to, for example, micro-architectural features of the core, like a particular pipeline, being powered down, which knowledge can be used to reduce voltage margin.)
Here's a really low level version (hardly relevant to the discussion except that it's in the same philosophical vein) tracking changes, by analog means, of the retention voltages required for individual SRAM sub-arrays; and switching the feed into those arrays by having each sub-array connected to a set of slightly different diodes, the optimal one of which at any give time feeds in power.
https://patents.google.com/patent/US9792979B1
Here's an example from the other side (rather than trying to operate at minimum voltage, ensure that maximum performance is achieved, but issue throttling will kick in if too many IP blocks all simultaneously go into high power)
https://patents.google.com/patent/US20140380071A1
There are multiple of these sorts of patents, covering different cases (for example the required/desired voltage can slide up and down as system temperature changes, as the system ages, etc). Some monitoring is done by the DPE's, some by various analog circuits.
Obviously at least some of this is being done by other companies (eg Intel are monitoring which of N cores on a die have the best efficiency so that those can be goosed an extra 100MHz when no other cores are active, whatever Turboboost version that one is called).
I make no claim for the uniqueness of what Apple is doing, simply that they track the whole set of possibilities
- very slow changes (aging)
- slow (by computer standards) changes like temperature
- fast change (IP blocks powering up and powering off)
- cycle to cycle changes (DPE, and preventing issue to limit exceeding spec)
and they provide enough separate voltage planes and islands to manage this on a very fine-grained scale.
Topic | Posted By | Date |
---|---|---|
alder lake. | inteluser | 2021/09/10 01:52 AM |
alder lake. | Andrei F | 2021/09/10 09:31 AM |
alder lake. | Andrey | 2021/09/10 09:38 AM |
alder lake. | rwessel | 2021/09/10 11:18 AM |
alder lake. | Andrei F | 2021/09/10 12:49 PM |
alder lake. | Andrey | 2021/09/10 04:12 PM |
alder lake. | David Hess | 2021/09/10 07:39 PM |
alder lake. | Andrey | 2021/09/11 12:28 AM |
alder lake. | --- | 2021/09/10 05:24 PM |
alder lake. | Andrei F | 2021/09/12 01:09 AM |
DVFS | David Kanter | 2021/09/12 09:58 PM |
DVFS | Andrei F | 2021/09/13 01:02 AM |
DVFS | Anon | 2021/09/13 03:28 AM |
DVFS | Jukka Larja | 2021/09/13 05:35 AM |
DVFS | Andrei F | 2021/09/14 12:07 AM |
DVFS | Jukka Larja | 2021/09/14 04:11 AM |
DVFS | Andrei F | 2021/09/14 07:55 AM |
DVFS | Jukka Larja | 2021/09/14 10:23 AM |
DVFS | --- | 2021/09/13 10:19 AM |
DVFS | Doug S | 2021/09/13 10:57 AM |
DVFS | David Hess | 2021/09/13 11:32 AM |
DVFS | --- | 2021/09/13 01:06 PM |
DVFS | David Hess | 2021/09/13 02:21 PM |
DVFS | David Kanter | 2021/09/15 03:05 PM |
DVFS | David Hess | 2021/09/13 11:46 AM |
DVFS | Jukka Larja | 2021/09/14 04:35 AM |
Quick shutdown? | David Kanter | 2021/09/15 10:46 AM |
Quick shutdown? | Andrei F | 2021/09/16 07:12 AM |
Quick shutdown? | David Kanter | 2021/09/16 11:04 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:35 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:38 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 04:20 AM |
and weren't 'they' right? | Andrei F | 2021/09/13 04:51 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 06:29 AM |
and weren't 'they' right? | anon | 2021/09/13 05:07 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/13 05:26 AM |
and weren't 'they' right? | anon | 2021/09/13 11:37 PM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 06:33 AM |
Alder Lake has no little cores | Michael S | 2021/09/13 07:33 AM |
Alder Lake has no little cores | me | 2021/09/13 10:45 AM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 01:49 PM |
Alder Lake has no little cores | anon | 2021/09/13 11:42 PM |
why stop at two core sizes? | hobold | 2021/09/14 05:47 AM |
Memory caches did this, right? | Mark Roulo | 2021/09/14 02:51 PM |
Memory caches did this, right? | Brett | 2021/09/14 07:17 PM |
Memory caches did this, right? | Kevin G | 2021/09/16 03:10 PM |
Large reorder buffers (L1+L2) | ⚛ | 2021/09/15 11:24 AM |
Large reorder buffers (L1+L2) | hobold | 2021/09/15 12:06 PM |
Alder Lake has no little cores | Adrian | 2021/09/14 08:33 AM |
and weren't 'they' right? | David Hess | 2021/09/13 12:00 PM |
Battery vs Performance | Mark Roulo | 2021/09/13 12:18 PM |
Battery vs Performance | Doug S | 2021/09/13 02:05 PM |
Battery vs Performance | David Hess | 2021/09/13 02:28 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | Doug S | 2021/09/13 08:53 PM |
Battery vs Performance | Anon | 2021/09/14 06:42 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 12:57 PM |
and weren't 'they' right? | David Hess | 2021/09/13 02:11 PM |
and weren't 'they' right? | --- | 2021/09/13 02:38 PM |
and weren't 'they' right? | --- | 2021/09/13 02:32 PM |
and weren't 'they' right? | Brendan | 2021/09/14 03:30 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/14 04:31 AM |
and weren't 'they' right? | Etienne Lorrain | 2021/09/14 12:29 AM |