[alchemist59 0]

hi

меня интересует практически любая информация (статьи, программные средства, разработки) связанная с оптимизацией и оценкой энергопотребления на высоком уровне описания алгоритмов, в частности, SystemC.

У меня задача стоит так, чтобы оптимизировать исходный текст (циклы, переходы...), где целевой функцией есть энергопотребление.

Особый интерес возникает об оценке энергопотребления (пусть приблизительная) без опускания на уровень крислалла.

[SM 0]

Особый интерес возникает об оценке энергопотребления (пусть приблизительная) без опускания на уровень крислалла.

Не реально. Но и опускаться на уровень кристалла (трассировки) не надо - нетлиста достаточно для оценки.

[Grigory 0]

Имхо, синхронный дизайн - главный враг экономичноси.

[BVU 0]

Злая задача, но актуальная. Мне приходилось с подобным сталкиваться.

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

В основном эта проблема решается на разных уровнях hard и soft, которая зависит от правильной постановки задачи проекта (необходимые и достаточные условия) и его реализация в процессе которой выявляются неисчерпанные ресурсы. Исходя из этого должно быть подобрано оптимальное 'равновесие' программно-аппаратных средств по решению задачи.

Во первых hard уже сам по себе должен быть экономичным (низкое токопотребление) и возможная функциональность, которая бы аналогово-цифровым способом облегчала программные вычисления (снижая этим временные характеристики вычислительной системы - требования к системному clock). Дальше идут механизмы soft, которыми Вы дополнительно должны снижать токопотребление системы. Это перевод контроллера в низкопотребляющие режимы тока если требуются такие временные события, как ожидание прерываний (в отсутствие фоновой задачи). Минимизация алгоритмов по скорости выполнения. Далее если есть возможность понижать системный clock фоновой задачи не требующей быстрого вычисления. Либо же выполнение суб-рутинных вычислений на повышенных скоростях и возврат в нормальный режим тактирования (PLL и прочее), тем самым уменьшая (усредняя) время на не минимизирующийся алгоритм. Может я что-то упустил, но перечисленного и так достаточно, чтобы снизить токопотребление хотя бы на 10%, а это уже не так мало!

[SM 0]

Имхо, синхронный дизайн - главный враг экономичноси.

Да нет, не он враг. Враг это собственно частота переключения и кол-во переключаемых гейтов. А на сколько там все синхронно, на жрачку не влияет.

[dxp 34]

Имхо, синхронный дизайн - главный враг экономичноси.

Да нет, не он враг. Враг это собственно частота переключения и кол-во переключаемых гейтов. А на сколько там все синхронно, на жрачку не влияет.

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

[BVU 0]

Имхо, синхронный дизайн - главный враг экономичноси.

Закон Кирхгоффа для тока еще никто не отменил... Суммарный усредненный ток будет одинаковым и в том и в другом случае (синхронный/aсинхронный)!

[SM 0]

Имхо, синхронный дизайн - главный враг экономичноси.

Да нет, не он враг. Враг это собственно частота переключения и кол-во переключаемых гейтов. А на сколько там все синхронно, на жрачку не влияет.

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

 

Во первых их обычно относительно немного. Само дерево клоков да инвертора на клок-входах, управляющие ключами триггеров. Во вторых - главжрач это сквозной ток при переходе 0->1 и 1->0, а не перезаряд емкостей. А таких переходов в среднем за какой-то период может быть одинаковое кол-во как и в синхронном, так и в асинхронном дизайне.