Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Казалось бы, чего ради внутри одного модуля переназначать клок с одного сигнала на другой? И задержка сброса решит далеко не все проблемы такого переназначения. А так да, это одна из дыр VHDL, создающая принципиальное расхождение между симуляцией и аппаратурой. Поэтому в ряде coding rules запрещают использовать переназначенный клок в том же модуле и смешивать сигналы от нового и старого.
>> after 1 ns – для облегчения моделирования
Весьма спорно, т.к. сразу попадаем в не синтезируемое подмножество.
>> Наличие такой записи позволяет быть уверенным что результаты моделирования и результаты работы в реальной аппаратуре будут одинаковыми.
А что мешает провести верификацию прогнав tb после P&R?
Весьма спорно, т.к. сразу попадаем в не синтезируемое подмножество.
>> Наличие такой записи позволяет быть уверенным что результаты моделирования и результаты работы в реальной аппаратуре будут одинаковыми.
А что мешает провести верификацию прогнав tb после P&R?
Использование after в синтезируемом коде — это плохо, потому что:
1. Вы смешиваете functional simulation и gate-level simulation (который после P&R). Задача первого — убедиться, что Ваш алгоритм правильный, второго — что суровая физическая реальность не разрушит Ваш правильный алгоритм. Если gate-level simulation выполняется слишком медленно, то стоит посмотреть в сторону timing analysis (у Altera это, если не ошибаюсь, TimeQuest): он укажет Вам, в каких именно местах могут быть проблемы с временными характеристиками (плюс компилятор может использовать эту информацию для оптимизации схемы).
2. Возможности повторного использования Вашего кода сильно ограниченны, поскольку он не инвариантен относительно частоты: при 10 МГц задержка 1 ns — это почти дельта-задержка (в том плане, что она мала по сравнению с периодом), на частоте 100 МГц — уже чувствительно, а на 1 ГГц — целый такт. В зависимости от заданной частоты работы схемы functional simulation будет давать очень разные результаты, и это явно не то, к чему Вы стремитесь. Ну и никакого физического обоснования для константы 1 ns нет, все будет зависеть от модели ПЛИС.
1. Вы смешиваете functional simulation и gate-level simulation (который после P&R). Задача первого — убедиться, что Ваш алгоритм правильный, второго — что суровая физическая реальность не разрушит Ваш правильный алгоритм. Если gate-level simulation выполняется слишком медленно, то стоит посмотреть в сторону timing analysis (у Altera это, если не ошибаюсь, TimeQuest): он укажет Вам, в каких именно местах могут быть проблемы с временными характеристиками (плюс компилятор может использовать эту информацию для оптимизации схемы).
2. Возможности повторного использования Вашего кода сильно ограниченны, поскольку он не инвариантен относительно частоты: при 10 МГц задержка 1 ns — это почти дельта-задержка (в том плане, что она мала по сравнению с периодом), на частоте 100 МГц — уже чувствительно, а на 1 ГГц — целый такт. В зависимости от заданной частоты работы схемы functional simulation будет давать очень разные результаты, и это явно не то, к чему Вы стремитесь. Ну и никакого физического обоснования для константы 1 ns нет, все будет зависеть от модели ПЛИС.
На современных проектах слишком медленно выполняется даже functional simulation. Например мне приходится при помощи параметров удалять целые блоки из проекта ПЛИС. Это касается например блоков PCE Express и контроллеров DDR. Timig Analysis конечно используется.
По поводу повторного использования — этот код у нас постоянно повторно используется. До 300 МГц after 1 ns прекрасно выглядит, а выше уже можно писать after 0.1 ns.
Ещё раз, задача after 1 ns — показать что есть задержка. Она должна быть меньше периода. С этой точки зрения неважно сколько получиться в реальной аппаратуре: 0.1 или 2.2 ns. Если получиться меньше периода — результаты моделирования и реальной работы совпадут. Остальное неважно.
По поводу повторного использования — этот код у нас постоянно повторно используется. До 300 МГц after 1 ns прекрасно выглядит, а выше уже можно писать after 0.1 ns.
Ещё раз, задача after 1 ns — показать что есть задержка. Она должна быть меньше периода. С этой точки зрения неважно сколько получиться в реальной аппаратуре: 0.1 или 2.2 ns. Если получиться меньше периода — результаты моделирования и реальной работы совпадут. Остальное неважно.
а можно попросить хоть один пример необходимости такого переназначения «clk2 <= clk1»?
Это связано с повторным использованием кода. Если есть какой-то кусок кода, который перенесён из другого проекта, то там может использоваться другое название сигнала тактовой частоты. И напрашивается сделать присваивание вместо переименования, особенно если надо провести несколько экспериментов с разными тактовыми частотами.
а компилятор дает ли гарантию прямого объединения цепей, есть ли уверенность, что он не засадит их через буфер, скромно сообщив об этом в одном из варнингов?
Если делать микросхему (ASIC), то так и произойдет — бэк-енд тул вставляет буферы во все assign в схеме. Учитывая, что это клоковская цепь, а не сигнальная, могут быть и другие последствия — к примеру, криво построенное клоковое дерево, поскольку для разрыва assign используются одни буфера, а для клокового дерева — другие. В общем, на ПЛИС это может и прокатывает, но вот для ASIC я бы не советовал использовать подобные конструкции без лишней надобности — лишний риск словить ошибку на ровном месте.
Я не суперспец в ПЛИС, но с каких пор копипаста называется повторным использованием кода? Разве не следует вынести общую функциональность в отдельный именованный модуль?
Это проверено, получается один и тот же сигнал тактовой частоты
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация конечного автомата на языке VHDL