К вопросу об оптимизации энергопотребления

К вопросу об оптимизации энергопотребления

Выпуск 4(6728) от 25 февраля 2021 г.
РУБРИКА: МИКРОЭЛЕКТРОНИКА

По мере масштабирования ИС и усложнения конструкций SoC обостряется вопрос оптимизации потребляемой мощности. Особенно это важно для конечных систем с батарейным питанием. Отраслевые специалисты считают, что при анализе потребляемой мощности и разработке методов ее оптимизации необходимо применять комплексный подход, охватывающий как можно больший круг возможных решений.

По мере того как разработчики полупроводниковых приборов активно изучают новые способы повысить их производительность без ущерба для срока службы батарей или увеличения затрат на электроэнергию, задача оптимизации энергопотребления начинает смещаться на более ранние этапы жизненного цикла продукции. В отличие от потребляемой мощности, которую квалифицированные проектировщики могут снизить на 1–5%, повышение эффективности использования электроэнергии может позволить сократить фактическую потребляемую мощность вдвое. Но чтобы этого достичь, требуется существенно переосмыслить всю архитектуру системы, включая то, как и где происходит обработка данных, какие функции приоритетны, как долго они должны выполняться и как все это контролируется и оптимизируется внутри системы. Данный момент очень важен для разработчиков, занятых проектированием сложнофункциональных блоков. Но еще большее значение он имеет для вертикально-интегрированных фирм, специалисты которых осуществляют весь комплекс работ – ​от микропрограммного обеспечения (прошивки), которое будет использоваться в приборах, до того, каким в конце концов станет прибор. В последнем случае можно добиться большего, так как оптимизируется вся система. Чем шире пространство решений разработчика, тем больше набор переменных, которыми он оперирует, и, как следствие, влияние, которое он может оказать на конечный результат. Обычно процесс укладывается в эволюционную повестку, но в некоторых случаях удается добиваться трансформационных достижений.

Вышесказанное особенно важно для приборов с батарейным питанием – ​тем более в свете увеличения объемов данных, которые обрабатываются этими приборами. Все, что ранее расценивалось как полезный, но необязательный фактор, теперь становится конкурентным преимуществом. Это верно и для электромобилей, где конкурентная борьба ведется за максимальную дальность проезда на одной зарядке, и для компьютеров и смартфонов, где срок службы аккумуляторных батарей между зарядками становится характеристикой, повышающей привлекательность товара для потребителей.

Потребности в энергии -какого-либо изделия, будь то сервер или мобильный телефон, в течение всего его жизненного цикла должны быть по возможности минимальными. Разработчики, как правило, сосредотачиваются на потребляемой мощности на уровне СФ-блоков и стремятся снизить и оптимизировать ее. Допустим, удалось снизить динамическую (потребляемую) мощность на 20%. Что это дает с точки зрения повышения энергоэффективности на системном уровне? Не слишком многое – ​иногда общий прирост энергоэффективности составляет менее 1%.

Чтобы справиться с подобными ситуациями, лучше перейти на системный уровень. Действительно, на уровне «систем-на-кристалле» (SoC) некоторые блоки демонстрируют малую активность переключений, при этом оставаясь в рабочем состоянии в течение довольно долгого времени. Другие блоки отличаются всплесками поступающей информации – ​тогда их активность переключения очень высока, а потом они снова уходят в режим ожидания. Если сопоставить оба типа этих блоков, может получиться, что на длительном временном отрезке первые в конечном итоге потребляют больше энергии. Такой расклад – ​хорошая отправная точка для начала процесса оптимизации.

Подобные компромиссы встречаются все чаще по мере распространения проектов разработки ИС и SoC. И если снизить потребляемую мощность относительно просто, то повышение энергоэффективности – ​задача более сложная. Обычно разработчики сосредотачиваются на снижении потребляемой мощности и при совмещении этой задачи с повышением энергоэффективности следят за наиболее эффективным потреблением мощности – ​пытаются сделать задание меньше и выключить процессор по его завершении. Однако это не всегда приемлемо. С точки зрения архитектуры, когда требуется выполнить некую задачу, сделать это можно либо быстро закончив задание и перейдя в период ожидания, либо, если выполнение задачи допустимо в течение определенного периода времени, снизив скорость его выполнения. Иначе говоря, если на выполнение задачи отводится 50 циклов тактовой частоты, можно сэкономить время, завершив ее за пять циклов, и оставшееся время оставаться в ожидании, а можно снизить частоту, увеличив время реализации задачи. Вопрос в том, что первоочередно в конкретном случае (рис. 1).



Источник: Synopsys

Рисунок 1. Проектирование ИС с целью повышения эффективности


Анализ энергоэффективности, поиск компромиссов

Одной из ключевых задач при проектировании ИС и SoC в будущем станет определение приоритетов на архитектурном уровне. То есть для достижения оптимальной энергоэффективности архитектурный анализ должен проводиться в самом начале процесса проектирования.

При осуществлении архитектурного анализа проекта с несколькими ядрами (например, SoC мобильного телефона) могут рассматриваться пяти- или шестиядерные процессоры. Можно запускать все ядра на частоте 1 ГГц, а можно активировать процессор только в случае необходимости, когда одно ядро будет работать на высокой частоте, а остальные – ​на низкой.

Частью процесса принятия решений является планирование ПО. При этом следует преду-смотреть как нагрузки с пиковой мощностью, так и со средней потребляемой мощностью в течение определенного периода времени. Система должна быть спроектирована таким образом, чтобы удовлетворять условиям пиковых нагрузок. Даже если -какую-либо задачу можно реализовать не за 80 тактов, а за пять (в сценарии с 80 тактами), в оставшееся время все равно могут быть резкие всплески потребляемой мощности – ​из-за обращений к процессору для решения еще -какой-нибудь задачи. Соответственно, требуется довольно большой объем планирования.

В прошлом большинство задач реализовывалось последовательно, сейчас же их все чаще необходимо выполнять параллельно. Возникла и развивается тенденция совместной разработки аппаратного и программного обеспечения на более ранних этапах жизненного цикла продукции. Одновременно реализуется и другая тенденция – ​перехода на более высокие уровни при оптимизации потребляемой мощности, энергии, тепловыделения. Сегодня достаточно распространен подход, предполагающий взаимосвязь данных по моделированию и эмуляции с анализом потребляемой мощности, основанным на фактических технологических характеристиках, – ​динамический анализ мощности. В эпоху процессоров с расширенными возможностями и высокоуровневого синтеза он смещается на более высокие уровни. В качестве входных данных процесса анализа и оптимизации мощности пользователи могут брать высокоуровневое описание и сгенерированные RTL-вариации. Такой подход позволяет оценить на еще более ранних уровнях влияние на потребляемую мощность, энергетические и тепловые аспекты различных разбиений аппаратного и программного обеспечения, а также вариаций процессоров. Это особенно важно, потому что большая часть управления режимом энергопотребления контролируется программным обеспечением. Еще более важна проверка функциональности микропрограммного обеспечения мощности перед внедрением вновь созданных компонентов, использующих новые конфигурации чиплетов. Для таких моделей использования спрос на виртуальное прототипирование и многокристальную эмуляцию будет, по всей видимости, увеличиваться.

Еще один аспект принятия решений при выборе архитектуры на основе нескольких процессоров или вычислительных блоков заключается в необходимости определить доминирующую потребляемую мощность – ​динамическую или статическую. В случае доминирования статической мощности оптимальным решением будет запуск меньшего числа узлов на более высоких частотах. При доминировании динамической мощности предпочтительнее использовать большее число узлов на более низких частотах. Вопрос о том, какой вариант и при каких обстоятельствах использовать, является предметом планирования. Для этого используются такие методы, как динамическое масштабирование напряжения и частоты (DVFS), динамическое масштабирование напряжения (DVS) или адаптивное масштабирование напряжения (AVS) (рис. 2). Чем выше частота – ​тем выше энергия. Использование DVFS связано с программным планировщиком задач, определяющим необходимость включения большего числа узлов. Если в динамическом режиме возникает необходимость использовать большее число узлов, то задействуется блок управления режимом электропитания, определяющий частоту процессоров. Например, если при доминировании динамической мощности запускаются три процессора (ядра), то частота снижается с 1 ГГц (условно) до 500 МГц, а если доминирует статическая мощность, то запускается один процессор (ядро), но с тактовой частотой 3 ГГц.



Источник: Synopsys

Рисунок 2. Разные технологии – разные результаты


Простое изменение частоты не имеет смысла. Одновременно должно изменяться и напряжение, так как чем выше напряжение, тем выше частота, и наоборот.


Варианты оптимизации энергопотребления

Для оптимизации энергопотребления необходимо задействовать различные архитектурные решения как на уровне ИС, так и на системном уровне. Обычно происходящее на уровне ИС может описываться несколькими типами сценариев, основанными на средней вычислительной мощности, мощности холостого режима, пиковой мощности. В их рамках в холостом режиме определяется мощность утечки, фактическое выполнение работы (выполняется или нет).

Пиковая мощность, также называемая максимальной средней мощностью, относится к моментам времени, когда происходит бóльшая часть работы и потребляется много энергии. Между этими периодами существуют и другие режимы нормального функционирования, которые также требуют энергии. При этом неверно будет исходить из того, что между объемами выполняемых работ и потребляемой мощностью существует линейная зависимость – ​возможны варианты большего потребления энергии при исполнении относительно небольшого объема работ. В частности, это может быть обусловлено тем, что конструкция прибора предполагает наличие напрасных переключений. Для устранения подобных недостатков существует множество стратегий оптимизации потребляемой мощности регистров и памяти. Так, в случае если имеются определенные типы данных, которые часто записываются в память и являются частью конфигурации, их можно записать на триггер и запускать в работу лишь тогда, когда это необходимо (например, при больших объемах входящих данных). Также можно осуществить тонкую подстройку тактового пропускания или внести некоторые архитектурные изменения с целью уменьшения числа переключений для снижения потребляемой мощности. Однако подобная оптимизация не всегда приводит к экономии энергии на системном уровне.

Блоки, над которыми проектировщики работают на системном уровне, могут иметь разные сценарии использования. Например, одни блоки активны лишь короткое время, а другие – ​бóльшую часть времени. Оптимизация рабочей нагрузки и максимизация энергоэффективности с точки зрения потребляемой мощности осуществляются с учетом таких сценариев. Чтобы реализовать это на системном уровне, для аппаратного обеспечения существуют стандартные методы, включая выделение частей системы («островков напряжения») таким образом, чтобы некоторые блоки, не ориентированные на обеспечение высокой производительности, фактически работали при более низком напряжении. Это экономит довольно много энергии. Кроме того, SoC можно разделить на несколько областей мощности. Некоторые блоки при этом будут использоваться для пропускания мощности с целью снижения мощности утечки. Объединенные межсоединениями блоки памяти могут быть переведены в режим ожидания. Иными словами, есть много способов справиться с поставленной задачей на аппаратном уровне.

Кроме того, при работе над управлением режимом энергопотребления проектировщикам легче определить, какая функциональность относится к ПО, а какая – ​к аппаратному обеспечению.

Один из вариантов, возникающих на программном уровне, – ​полное или частичное (в зависимости от обстоятельств) использование ресурсов. Могут появиться блоки, которые ПО использует не оптимально. Для лучшего управления энергией можно добавить уровень ОС, отвечающий за выборочное отключение компонентов, используемых частично или не используемых. Потерю ресурсов также можно устранить, разработав методы управления ими на уровне ОС, которые будут оптимизировать использование доступных аппаратных ресурсов. Наконец, уже существуют программы управления режимами энергопотребления, встроенные в серверы. Они способны оптимизировать рабочие нагрузки с целью изменения объемов требуемых работ – ​например, в зависимости от того, какую точность клиенты желают получить от своего приложения.


Изменение напряжения, частоты

Непростая задача внесения изменений в архитектуру для оптимизации энергопотреб-ления еще усложняется по мере усложнения систем. Просто уменьшить частоту проектировщик не может. С функциональной точки зрения переход в режим уменьшения частоты обеспечивает ПО. Но с точки зрения реализации есть некоторая задержка: сначала уменьшается напряжение, а потом – ​частота. Когда они синхронизируются, ПО сообщит о достижении заданного уровня. Проблема в том, что, если этот процесс займет слишком много времени, смысла в нем не будет.

Ключевыми частями уравнения являются момент активации и планируемое время. Вопрос в том, сколько времени требуется для того, чтобы перейти от определенного напряжения к определенной частоте и вернуться к нормальной работе. Это должно быть задано заранее – ​при анализе архитектурного уровня, на котором строится весь опытный образец SoC с использованием моделей SystemC, при этом конкретизируется (на уровне операций) время синхронизации, время перехода между уровнями, наличие смысла в переходе с одного напряжения на другое и т. п.

Основные производители мобильных телефонов в настоящее время используют от 10 до 12 режимов ожидания, начиная от крат-косрочных отключений питания до полной гибернации (режим пониженного энергопотребления). Выбор одного из этих состояний и времени его применения зависит от сценариев использования.

Разработчиков, берущих в качестве основного показателя энергию, обычно интересуют, например, способы достичь (если можно) 10%-ного улучшения энергоэффективности SoC. Какие меры нужно принять со стороны ПО, а какие – ​со стороны аппаратного обеспечения. При этом необходимо рассмотреть все виды рабочих нагрузок, в условиях которых будет работать ИС или SoC. Чем подробнее будет такое рассмотрение, тем понятнее станет, какие именно блоки аппаратного обеспечения лучше всего подходят для оптимизации, на чем надо сосредоточиться и насколько можно и нужно сократить потребляемую мощность.

Проблемы могут возникнуть в случае рассмотрения единичного решения. Дело в том, что изучение вопросов энергоэффективности имеет смысл лишь тогда, когда они рассматриваются на уровне SoC или когда рабочих нагрузок слишком много. Важно оценить полный диапазон поведения SoC, возможно, даже на уровне СФ-блоков. Выявить изменение потребляемой мощности при использовании различных микроархитектурных решений и алгоритмов. Другая трудность состоит в том, что современные инструментальные средства ориентированы прежде всего на оценку производительности (независимо от того, что осуществляется – ​синтез или размещение и трассировка). Иначе говоря, ощущается недостаток инструментальных средств, предназначенных для анализа и оценки энергоэффективности. Таким образом, любая оптимизация, любые нисходящие методики выбора, например, ячейки должны оцениваться с точки зрения не только производительности, но и энергоэффективности.


Mutschler Ann Steffora. Designing Low Energy Chips and Systems. Semiconductor Engineering, February 1, 2021: https://semiengineering.com/designing-for-low-energy/


ЧИТАЙТЕ ТАКЖЕ

Выпуск 24/25 (6748/6749) от 23 декабря 2021 г. г.
Выпуск 24/25 (6748/6749) от 23 декабря 2021 г. г.