Как стать автором
Обновить

Комментарии 9

Спасибо, интересно!
А вот если нас после симуляции не устроил полученный результат по энергопотреблению, какие меры можно предпринять для снижения этого параметра?
Делать другую схему, использовать другую библиотеку, снижать напряжение питания, снижать тактовую частоту и т.д. и т.п.
Обычно стараются как-то адаптивно управлять питанием и частотой в зависимости от текущей загруженности блока.
У всех описанных методов есть свои недостатки и цена. В своем комментарии постарался описать на что идет размен.
Косвенно упомянутый метод создания отдельного power domain (области со своим питание) за собой тянет слишком много издержек. И обычно требует расчета своей целесообразности. А вот изменение тактовой частоты уже и правда перешло из разряда sleep режима в штатный метод в современных чипах/процессорах.
А какие большие издержки у создания доменов питания? Площади встроенные регуляторы жрут не очень много, логика управления ими не слишком сложная. Расчет целесообразности, разумеется, нужен, но, как мне видится, скорее с точки зрения соотношения потенциального выигрыша и затрат на разработку подсистемы управления питанием, а не с того, будет ли оно эффективно.
С другой стороны, если у вас блок постоянно гоняет одну и ту же программу, это не то же самое, что динамически изменяющийся рабочий режим.
1. Как написано в статье есть один автоматизированный метод снижения потребления в пределах 5-15% от общего — это clock gating. Он требует определенного описания регистров в исходном коде (использования enable). Можно проверить в отчете по clock gating, что для существенной части регистров он был применен или добавить/изменить код для регистров для его использования.
2. Использовать более прогрессивную технологию производства (90нм-->65нм-->55нм-->45нм) или оптимизированную библиотеку по потреблению в рамках выбранной (при этом пострадает максимальная частота работы). Обычно такой вариант сильно затратный по финансам (шаг в уменьшении технологии может увеличить стоимость на порядок).
3. Переделать реализацию IP-блока, используя алгоритмы цифровой обработки, которые лучше подходят для аппаратной реализации. Самый эффективный способ. В примере приведена структура подблоков, которая получилась для реализации нашей задачи DDC. Я как раз в статье написал, что мы сравнивали несколько реализаций. Могу привести на базе моего примера — то что было выбрано как оптимальная реализация с точки зрения потребления:
— модифицировали алгоритм, так чтобы можно было максимально использовать подблок ddc_qsr0.v (ЧЧП- четверть-частотное преобразование) — вместо обычного цифрового смесителя сигнала
— Объединили для вещественного сигнала выход ЧЧП и вход FIR фильтра (ddc_qsr_lpf1.v). Сэкономил в реализации фильтра.
— Ценой увеличения цифрового шума — уменьшили количество stage/коэффициентов в FIR фильтре (ddc_lpf0.v)
— Сделали реализацию интреполятора в базисе радиус-фаза для квадратурного сигнала. (Также ценой некоторых цифровых потерь обработки)
Есть какая-нибудь причина для использования gate-level симуляции для записи SAIF? Мы записываем SAIF в процессе RTL-симуляции (только активность на выходах регистров), а потом этот файл аннотируем на нетлист, при этом DC автоматически вычисляет активность на входах и выходах комбинационных логических элементов между регистрами (т.к. знает активность на регистрах). Если нужно симулировать хоть сколько-нибудь большой проект, то так гораздо быстрее, а точность почти такая же. К тому же один и тот же SAIF можно использовать с разными нетлистами (например, синтезированными под разную частоту, с разным процентным соотношением LVT/SVT/HVT-элементов, и т.д.)
Какое у вас получается покрытие по команде report_saif для RTL-симуляции?
Только для gate-level симуляции я получил полное покрытие Nets/ports/Pins — User Annotated в 100%.
Для RTL-симуляции у меня получалось не более 50-70% сопоставления с названиями в saif (power report -all -bsaif saif.saif). Для не найденных использовался расчет на основании статистики переключений, что существенно сказывалось на результат оценки. (сравнил два подхода).

>DC автоматически вычисляет активность на входах и выходах комбинационных логических элементов между регистрами
Изначально на это рассчитывал, хотя может это и проблема генерации saif в Modelsim, но в отчете не сопоставленных элементов было 30-40% внутренних не найденных Ports/Nets при RTL-симуляции. И сложно было понять почему DC для порта qn внутреннего синтезированного модуля xxx_gen_syn_0 не рассчитал активность.
покрытие около 99%. Но мы используем VCS.

Кстати, а вы namemap файл использовали?
namemap файл не использовал, тк эта же информация содержится в файле .ddc.

*написал вам в личку ранее*
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории