Так и не нашел для себя ответ на вопрос:
Вы описываете как аналогичные конструкции SV выглядят на SystemC, но при этом этом для синтеза все равно используется HLS-синтезатор.
Это выглядит как прослойка в виде SystemC, чтобы иметь возможность написать SV код в C++ для синтеза.
Почему от этого не отказываются в пользу чистого HLS-синтеза с директивами (или OpenCL), но без специальных классов SystemC, которые опускают программистов на низкий уровень абстракции SV?
От задержек (времени прихода фронтов сигналов) может зависеть длительность глитча, но два его фронта (передний и задний) остаются
Я предполагал решение, в котором если сигналы будут выравнены по времени прихода, то явного глитча не должно быть. В зависимости от рассинхронизации глитч сможет появится только частично, а соответствено дополнительное потребление на глитч будет не на полные переключения уровней в две стороны.
Но согласен, что сложно точно выровнять сигналы задержкой трассировки даже в одном тактовом домене. Но в теории — это бы избавило от гличта при любом сочетании значений сигналов.
Если логические части в пути разбиты тригерами, то, кажется, что задержав на одном участке «быстрые» сигналы это не приведет к «переливанию из пустого в порожнее».
Я и не рассчитывал на комментарии автора по моему вопросу.
Просто после упомянутого рисунка автора задумался насколько такие глитчи (честные 2 переключения при подсчете) сказываются на потреблении.
Я сранвивал оценки потребления для одинаковой схемы и тестбенча, которые получаются при wireload-модели и в topographical-режиме. Но задумался после рисунка автора, что без полной разводки с точным вычислением задержки распространения сигналов не учесть дополнительное потребление связанное с глитчами. Ведь только тестбенч с честным «sdf» позволит посчитать в потреблении эти глитчи на сигналах.
После синтеза, но до честной топологии не известны фактические задержки распространения сигналов. У автора это приведено на Рис. 4. Схема с лишним переключением.
Не всегда можно избежать неэффективных переключений особыми приемами синтеза.
В данном примере на Рис.4 я вижу для синхронной схемы возможность задержать сигнал B на разводке, чтобы для него задержка распространения стала совпадать с сигналом А. Тогда переключение сигналов А и В на входе будет практически в один момент, что позволит уже на выходе Z не иметь лишнего переключения.
После разводки цифровой схемы уже есть вся информация для учета дополнительного потребления, связанного с несинхронностью прихода сигналов (лишние переключения). Соответственно можно посчитать эту добавку или ее минимизировать вставив (если возможно) задержки для «быстрых сигналов».
Может кто-то прокомментирует:
Для современных техпроцессов (65-130нм) эта добавка присутствует и ощутимая или успешно минимизируется правильной разводкой?
Какое у вас получается покрытие по команде 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 не рассчитал активность.
У всех описанных методов есть свои недостатки и цена. В своем комментарии постарался описать на что идет размен.
Косвенно упомянутый метод создания отдельного 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)
— Сделали реализацию интреполятора в базисе радиус-фаза для квадратурного сигнала. (Также ценой некоторых цифровых потерь обработки)
Вот не могу понять, что в этом плохого и «резкого».
Использование вертикального выравнивания улучшает читаемость кода, тк повышает структурность описания.
Считаю, что использования логических и/или (&& / ||) может скрыть опечатку/ошибку, которая никак себя не проявит при компиляции, но может сказаться на результат выражения в условном операторе и на работу схемы.
А вот при использовании побитовых и/или на этапе компиляции появится ошибка и привлечет внимание.
Простой пример: изначально в if использовался и/или с однобитным типом reg/wire/logic/bit, а потом его изменили на вектор, чтобы было удобней использовать в другом месте.
Тут как раз и получается весело и двойственно.
Для сотрудника ДПС ВУ, как и написали для составления протокола, удостоверяет.
Но он может стать обычным сотрудником Полиции (например на него напал водитель) и должен подчиняться инструкциям полицейского. А для полицейского ВУ не удостоверяет личность.
Юридическая казуистика формулировок.
Считаю, что вы некорректно ссылаетесь на решение Верховного суда ГКПИ06-1016.
В нем между делом упомянуто «СОДЕРЖИТ все необходимые реквизиты, позволяющие удостоверить личность гражданина».
Это как раз означает может использоваться, если это будет утверждено. Но у условия «есть необходимые реквизиты» нет юридической силы приравнять его к удостоверению личности (нет такого закона).
Напоминает анекдот, что «все мужчины насильники, тк прибор то имеется».
Сотрудник ДПС, также является сотрудником полиции. (Я не знаю как разрешается это двойственность юридически)
Думаю, вы согласны, что сотрудник полиции может потребовать паспорт и для него права не являются документом удостоверяющим личность. Те получается он может человека без паспорта задержать и отвезти для установления личности.
Юридическая казуистика из-за наших законов.
По закону как раз могут, тк они также являются сотрудниками МВД, поэтому как и обычные полицейские могут проверить удостоверение личности как у пешехода рядом с машиной.
Как-то странно написано. «Окно» всегда есть, но есть шаги/решения, которые гарантировано позволяют избежать этих проблем. Соответственно при правильной реализации в принципе не может быть «такая комбинация сигналов на входе которая может нарушить внутреннее состояние схемы».
Не следил за текущей ситуацией.
Но поползновения отказаться от асинхронных сбросов начались еще у Altera лет 5 назад. Хотели так сделать, но не знаю сделали по факту в каком-то семействе.
Как раз рассматривали такой вариант по совокупности причин, что в FPGA все заточено на синхронный дизайн + отдельные линии/площадь нужны для асинхронные цепей + флип-флоп занимает больше места, но тогда ресет включался бы в расчет пути данных и требовал бы еще задержку+площадь на один гейт перед входом флип-флопа.
Вы описываете как аналогичные конструкции SV выглядят на SystemC, но при этом этом для синтеза все равно используется HLS-синтезатор.
Это выглядит как прослойка в виде SystemC, чтобы иметь возможность написать SV код в C++ для синтеза.
Почему от этого не отказываются в пользу чистого HLS-синтеза с директивами (или OpenCL), но без специальных классов SystemC, которые опускают программистов на низкий уровень абстракции SV?
Я предполагал решение, в котором если сигналы будут выравнены по времени прихода, то явного глитча не должно быть. В зависимости от рассинхронизации глитч сможет появится только частично, а соответствено дополнительное потребление на глитч будет не на полные переключения уровней в две стороны.
Но согласен, что сложно точно выровнять сигналы задержкой трассировки даже в одном тактовом домене. Но в теории — это бы избавило от гличта при любом сочетании значений сигналов.
Я и не рассчитывал на комментарии автора по моему вопросу.
Просто после упомянутого рисунка автора задумался насколько такие глитчи (честные 2 переключения при подсчете) сказываются на потреблении.
Я сранвивал оценки потребления для одинаковой схемы и тестбенча, которые получаются при wireload-модели и в topographical-режиме. Но задумался после рисунка автора, что без полной разводки с точным вычислением задержки распространения сигналов не учесть дополнительное потребление связанное с глитчами. Ведь только тестбенч с честным «sdf» позволит посчитать в потреблении эти глитчи на сигналах.
Не всегда можно избежать неэффективных переключений особыми приемами синтеза.
В данном примере на Рис.4 я вижу для синхронной схемы возможность задержать сигнал B на разводке, чтобы для него задержка распространения стала совпадать с сигналом А. Тогда переключение сигналов А и В на входе будет практически в один момент, что позволит уже на выходе Z не иметь лишнего переключения.
Может кто-то прокомментирует:
Для современных техпроцессов (65-130нм) эта добавка присутствует и ощутимая или успешно минимизируется правильной разводкой?
*написал вам в личку ранее*
Только для 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 не рассчитал активность.
Косвенно упомянутый метод создания отдельного power domain (области со своим питание) за собой тянет слишком много издержек. И обычно требует расчета своей целесообразности. А вот изменение тактовой частоты уже и правда перешло из разряда sleep режима в штатный метод в современных чипах/процессорах.
2. Использовать более прогрессивную технологию производства (90нм-->65нм-->55нм-->45нм) или оптимизированную библиотеку по потреблению в рамках выбранной (при этом пострадает максимальная частота работы). Обычно такой вариант сильно затратный по финансам (шаг в уменьшении технологии может увеличить стоимость на порядок).
3. Переделать реализацию IP-блока, используя алгоритмы цифровой обработки, которые лучше подходят для аппаратной реализации. Самый эффективный способ. В примере приведена структура подблоков, которая получилась для реализации нашей задачи DDC. Я как раз в статье написал, что мы сравнивали несколько реализаций. Могу привести на базе моего примера — то что было выбрано как оптимальная реализация с точки зрения потребления:
— модифицировали алгоритм, так чтобы можно было максимально использовать подблок ddc_qsr0.v (ЧЧП- четверть-частотное преобразование) — вместо обычного цифрового смесителя сигнала
— Объединили для вещественного сигнала выход ЧЧП и вход FIR фильтра (ddc_qsr_lpf1.v). Сэкономил в реализации фильтра.
— Ценой увеличения цифрового шума — уменьшили количество stage/коэффициентов в FIR фильтре (ddc_lpf0.v)
— Сделали реализацию интреполятора в базисе радиус-фаза для квадратурного сигнала. (Также ценой некоторых цифровых потерь обработки)
Использование вертикального выравнивания улучшает читаемость кода, тк повышает структурность описания.
А вот при использовании побитовых и/или на этапе компиляции появится ошибка и привлечет внимание.
Простой пример: изначально в if использовался и/или с однобитным типом reg/wire/logic/bit, а потом его изменили на вектор, чтобы было удобней использовать в другом месте.
Для сотрудника ДПС ВУ, как и написали для составления протокола, удостоверяет.
Но он может стать обычным сотрудником Полиции (например на него напал водитель) и должен подчиняться инструкциям полицейского. А для полицейского ВУ не удостоверяет личность.
Юридическая казуистика формулировок.
В нем между делом упомянуто «СОДЕРЖИТ все необходимые реквизиты, позволяющие удостоверить личность гражданина».
Это как раз означает может использоваться, если это будет утверждено. Но у условия «есть необходимые реквизиты» нет юридической силы приравнять его к удостоверению личности (нет такого закона).
Напоминает анекдот, что «все мужчины насильники, тк прибор то имеется».
Думаю, вы согласны, что сотрудник полиции может потребовать паспорт и для него права не являются документом удостоверяющим личность. Те получается он может человека без паспорта задержать и отвезти для установления личности.
Юридическая казуистика из-за наших законов.
Но поползновения отказаться от асинхронных сбросов начались еще у Altera лет 5 назад. Хотели так сделать, но не знаю сделали по факту в каком-то семействе.
Как раз рассматривали такой вариант по совокупности причин, что в FPGA все заточено на синхронный дизайн + отдельные линии/площадь нужны для асинхронные цепей + флип-флоп занимает больше места, но тогда ресет включался бы в расчет пути данных и требовал бы еще задержку+площадь на один гейт перед входом флип-флопа.