Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Думаю, то, что САПР порой не совсем корректно синтезирует описание на собственном опыте убедился любой серьёзный разработчик)
Это знаете, когда переходили с совсем низкоуровнего описания схем на HDL возникали резонные вопросы типа «САПР там насинтезирует непойми чего — как это потом работать будет»? Но прошло лет 20 и Verilog/VHDL заняли место прошлого низкоуровневневого собирания схем и теперь те же вопросы возникают относительно той же Vivado HLS, где код пишется на Си, а САПР уже сам выполняет трансляцию в HDL описание. Там порой такие чудеса синтезятся ;) Но, например, низкоскоростные фильтры делать всяко проще, чем Verilog/VHDL разрабатывать, а потом отлаживать.
Это, конечно, правильно. Но одно дело, анализировать предупреждения САПР на модуль из 18 строк и совсем другое — когда у тебя только один топ уровень «разлёгся» строк этак тысячи на две, а если посчитать ещё код вложенных модулей, то совсем цифра немалая получится. В таких проектах предупреждений может быть легко до тысячи и не факт, что стоит тратить время на их подробный анализ. Хотя сам по себе список просматривать безусловно стоит и что-то подмечать.
Я предпочитаю VHDL как более жёсткий и не позволящий выстрелить себе в ногу. Например, в VHDL Check syntax никогда не пропустит присвоение сигналов разной разрядности или несоответствие типов. Ну и в VHDL есть такая штука как типы данных, используя которые можно гибко оперировать матрицами.
Это знаете, когда переходили с совсем низкоуровнего описания схем на HDL возникали резонные вопросы типа «САПР там насинтезирует непойми чего — как это потом работать будет»? Но прошло лет 20 и Verilog/VHDL заняли место прошлого низкоуровневневого собирания схем и теперь те же вопросы возникают относительно той же Vivado HLS, где код пишется на Си, а САПР уже сам выполняет трансляцию в HDL описание. Там порой такие чудеса синтезятся ;) Но, например, низкоскоростные фильтры делать всяко проще, чем Verilog/VHDL разрабатывать, а потом отлаживать.
а также анализировать списки предупреждений и ошибок, возникающих на каждом этапе построения проекта
Это, конечно, правильно. Но одно дело, анализировать предупреждения САПР на модуль из 18 строк и совсем другое — когда у тебя только один топ уровень «разлёгся» строк этак тысячи на две, а если посчитать ещё код вложенных модулей, то совсем цифра немалая получится. В таких проектах предупреждений может быть легко до тысячи и не факт, что стоит тратить время на их подробный анализ. Хотя сам по себе список просматривать безусловно стоит и что-то подмечать.
Я предпочитаю VHDL как более жёсткий и не позволящий выстрелить себе в ногу. Например, в VHDL Check syntax никогда не пропустит присвоение сигналов разной разрядности или несоответствие типов. Ну и в VHDL есть такая штука как типы данных, используя которые можно гибко оперировать матрицами.
С VHDL к сожалению знаком слабо, только по одному курсу лабораторных работ, однако за то короткое время понял, что он является более строгим языком описания аппаратуры. Этой статьёй хотел обратить внимание новичков, которые только вступают на путь разработки на ПЛИС, на то, что необходимо анализировать ошибки и предупреждения возникающие при разработке. Это также связано с тем, что проведя курс лабораторных работ по описанию аппаратуры на языке Verilog понял, что не все студенты обращают внимание на ошибки и предупреждения, хотя в них обычно и написано, что конкретно не так в дизайне. И конечно согласен, что нет смысла анализировать все предупреждения досконально, но заострять внимание на определённых всё же стоит)
для правильного описания аппаратуры необходимо знать синтаксис языка ...
Неужели? :)
для правильного описания аппаратуры необходимо знать синтаксис языка ...
А ещё нужно знать стандарты конкретно для Verilog стандарт по синтезу есть: Std 1364.1-2002.
К сожалению вот по SystemVerilog подобного нет, что приводит к некоторым косякам.
Можно предположить, что синтез модуля test2 не должен отличаться от синтеза модуля test1, так как логики описания обоих модулей не противоречат друг другу.
Вы правда думаете, что проверка и низкого и высокого уровня сигнала arst по negedge-фронту этого сигнала — это одно и то же?
ограничениями которого являются возможности самих сред разработки
Ограничением является форма глобуса, на который вы пытаетесь натягивать сову. А форма эта не от среды разработки зависит, а от возможностей примитивов конкретного FPGA.
P.S. Не используйте асинхронный сброс в FPGA, если не знаете точно, как его готовить. Сколько новичков набили себе шишки на этом — и не передать.
Я бы сказал даже не так: не используйте асинхронные схемы в FPGA, если в этом нет острой необходимости. Порой деваться просто некуда и такие штуки приходится применять, тогда надо понимать времянку работы своей схемы и в случае какой-то критичности всегда лучше «повесить» на «асинхронные сигналы» временные ограничения, чтобы потом долго и упорно днями напролёт не выяснять почему эта часть схемы начала глючить после переразводки проекта из-за изменений совсем в другой его части ;)
Всё это, что вы (безусловно правильно) написали, как раз я и подразумевал в своём комментарии. Только мне было немного лень вдаваться в подробности. :)
На самом деле, удручает непонимание многими того факта, что HDL предоставляет существенно больше возможностей, чем FPGA. Особенно verilog, где столько замечательных способов незаметно выстрелить себе в ногу и понять это уже после того, как нога отвалилась из-за гангрены. А потом, когда нога отвалилась, появляются статьи про ограничения сред разработки и плохие синтезаторы.
Хотя то, что во Vivado не ругается на test3 — это таки косяк синтезатора, на мой взгляд.
На самом деле, удручает непонимание многими того факта, что HDL предоставляет существенно больше возможностей, чем FPGA. Особенно verilog, где столько замечательных способов незаметно выстрелить себе в ногу и понять это уже после того, как нога отвалилась из-за гангрены. А потом, когда нога отвалилась, появляются статьи про ограничения сред разработки и плохие синтезаторы.
Хотя то, что во Vivado не ругается на test3 — это таки косяк синтезатора, на мой взгляд.
Да мне кажется в некоторой степени даже бесполезно новичков предупреждать об опасностях асинхронной логики или, допустим, пробросе сигналов (особенно шины со стробом) между тактовыми доменами. Это надо самому налететь пару раз, на своей шкуре ощутить коварность этих ситуаций.
Я не так давно искал ошибку в проекте, который начал ни с того, ни с сего подглючивать на определённых режимах. ПЛИС уже забит под завязку и начала сказываться времянка, в одном месте был некорректный переход по тактам — вот вам и привет проблеме. Цифровой подмодуль без проблем работал лет этак с пять (!), считался надёжным и проверенным — ну кто мог на него подумать? Подобные проблемы обычно процентов на 75% обычно локализуются аналитически, если у тебя хорошее погружение в проект. В противном случае приходится долго и нудно пользоваться отладчиком — тогда может уйти и несколько дней и пара недель… всего лишь из-за того, что кто-то накосячил с тактовыми переходами ;)
Я не так давно искал ошибку в проекте, который начал ни с того, ни с сего подглючивать на определённых режимах. ПЛИС уже забит под завязку и начала сказываться времянка, в одном месте был некорректный переход по тактам — вот вам и привет проблеме. Цифровой подмодуль без проблем работал лет этак с пять (!), считался надёжным и проверенным — ну кто мог на него подумать? Подобные проблемы обычно процентов на 75% обычно локализуются аналитически, если у тебя хорошее погружение в проект. В противном случае приходится долго и нудно пользоваться отладчиком — тогда может уйти и несколько дней и пара недель… всего лишь из-за того, что кто-то накосячил с тактовыми переходами ;)
При разработке ASIC (нет, не про блокчейны), в которых асинхронный сброс/установка является как раз нормой, и прототипировании кода в FPGA переделывать весь код с асинхронного сброса на синхронный обычно не только сложно и бесполезно, но и невозможно ввиду логики работы схемы.
В статье поднят правильный вопрос про универсальность HDL, но, как мне кажется, подход к его раскрытию совсем неправильный. У вендоров есть специальная документация, по тому, как писать HDL код так, чтобы результат был предсказуемым, например:
- От Altera/Intel: Recommended HDL Coding Styles
- От Xilinx: Coding Style Guidelines.pdf (Section 5)
Конкретно эти ссылки только для примера. Но статья про то, какие есть в этих рекомендациях различия, почему они есть и самое главное — выводы о том, как писать HDL код так, чтобы он удовлетворял и тем и другим рекомендациям была бы намного более полезной, чем выводы:
для правильного описания аппаратуры необходимо знать синтаксис языка
Это мне напомнило код, который иногда мне попадает в руки из проектов коллег, которые писали его еще в 90х — начале 2000х. Там иногда волосы встают дыбом и думаешь как вообще компиляторы тех лет такое хавали и как это уже по 20 лет работает в аппаратуре. Там и тактовые сигналы из асинхронной логики и по 10 разных assign для одного и того же сигнала в модуле, или деленный тактовый сигнал который потом через and и or асинхронно формирует что-то там… Вывод — без знания стандартов и coding style нефига там делать.
Я бы рекомендовал автору
1) Учить verilog либо перейти на VHDL — там /немножко/ меньше шансов отстрелить себе ногу
2) Запустить моделирование и убедиться, что test1 и test2 как бы совсем разные устройства, что синтез и показал.
3) Посетить electronix.ru в качестве тематического форума
1) Учить verilog либо перейти на VHDL — там /немножко/ меньше шансов отстрелить себе ногу
2) Запустить моделирование и убедиться, что test1 и test2 как бы совсем разные устройства, что синтез и показал.
3) Посетить electronix.ru в качестве тематического форума
Моделирование как раз такие говорит, что это одно и то же устройство. С точки зрения стандарта языка Verilog там ошибок нет, а вот с точки зрения синтезируемого подмножества языка Verilog ошибка есть… Так что просто учить verilog тут не поможет…
Результаты моделирования до синтеза кому интересно:
Результаты моделирования до синтеза кому интересно:
Согласен. Не вчитался в код. Воспользуюсь своим же первым советом — пойду дальше учить верилог, чтобы эффективнее стрелять себе в ногу ;-)
На самом деле, как уже написали выше, в первую очередь следует понять одну простую истину: Verilog и VHDL создавались для моделирования аппаратуры, но не для её создания. Это потом умные люди придумали, что с помощью этих языков можно синтезировать схемы, изначально подобный функционал в них не закладывался, отсюда и некоторые косяки синтеза, особенно когда человек не понимает физики процесса.
Надо понять простую истину — есть стандарты.
И если их нарушать, то будут проблемы.
Автору выше уже советовали посмотреть в стандарт IEEE 1364.1-2002, который описывает синтезируемое подмножество языка Verilog.
Нужно посмотреть на раздел
5.2.2.1 Edge-sensitive storage device modeling with asynchronous set-reset (стр. 9)
И сравнитить то, что написано там, с модулем test2.
И если их нарушать, то будут проблемы.
Автору выше уже советовали посмотреть в стандарт IEEE 1364.1-2002, который описывает синтезируемое подмножество языка Verilog.
Нужно посмотреть на раздел
5.2.2.1 Edge-sensitive storage device modeling with asynchronous set-reset (стр. 9)
И сравнитить то, что написано там, с модулем test2.
Моделирование как раз такие говорит, что это одно и то же устройство.
А вы дёрнете сбросом по положительному фронту, а не по отрицательному…
Да, действительно, если написать код неправильно, то можно получить неожиданный результат. Это и называется Undefined behaviour ;)
В Verilog проблема с тем, что полностью корректно описать триггер с асинхронным сбросом невозможно, т.к. в таком элементе сброс работает по уровню, а не по фронту, а в always-блоке можно задавать только либо фронты, либо уровни. Впрочем, и в VHDL это не сильно лучше — список чувствительности в process при моделировании работает только по уровням (что очевидно), хотя в самом тексте и более явно указывается проверка по уровню или проверка по фронту (
clk'event and clk = '1'rising_edge(clk)В SystemVerilog, к слову, есть некоторые расширения (always_ff, always_comb, always_latch), позволяющие организовать дополнительный статический анализ кода и избежать множества ошибок, допустимых в чистом Verilog.
Добрый день
Радостно видеть на хабре статьи по ПЛИС тематике, хотелось бы чтобы побольше эту тему как говорится «раскрывали»
Теперь по теме: поправьте меня если я ошибаюсь но мне кажется что результаты Quartus и Libero это и правда результат synthesis. Что же до Vivado то там уже мы видим более продвинутый этап. На схеме видно компоненты BUFG (да и LUTы видно) а это уже реальные компоненты чипа. Получается что хотя бы частично произведен mapping. Так что все же результаты сравнивать (как мне кажется) не совсем корректно.
Немного на счёт выводов статьи.
1) язык Verilog является универсальным языком описания аппаратуры, ограничениями которого являются возможности самих сред разработки.
Мне кажется, что язык ограничен не столько средой разработки сколько строением чипа под который компилируется код. Среда разработки обычно поддерживает последнюю (или почти последнюю версию языка). Дело в том, что нужно очень хорошо понимать какую аппаратуру с помощью этого языка описывают. Ведь от того, что на Verilog описан неведомый компонент (о чём вым пытается намекнуть например Quartus) он не прибавится на реальном чипе.
2) для правильного описания аппаратуры необходимо знать синтаксис языка, а также анализировать списки предупреждений и ошибок, возникающих на каждом этапе построения проекта.
Мне кажется, что кроме знания синтаксиса очень важно знать и понимать, каков будет резальтат имплементации на чипе той или иной языковой конструкции. Более того, результат будет иногда разительно отличатся если взять один и тот же код и прогнать их на Quartus и Vivado, например. Да, и в том и в другом случае мы получим идентично работающие блоки. Но иногда один или другой компилятор «сожрет» по той или иной причине намного больше или что куда хуже – не те ресурсы.
Радостно видеть на хабре статьи по ПЛИС тематике, хотелось бы чтобы побольше эту тему как говорится «раскрывали»
Теперь по теме: поправьте меня если я ошибаюсь но мне кажется что результаты Quartus и Libero это и правда результат synthesis. Что же до Vivado то там уже мы видим более продвинутый этап. На схеме видно компоненты BUFG (да и LUTы видно) а это уже реальные компоненты чипа. Получается что хотя бы частично произведен mapping. Так что все же результаты сравнивать (как мне кажется) не совсем корректно.
Немного на счёт выводов статьи.
1) язык Verilog является универсальным языком описания аппаратуры, ограничениями которого являются возможности самих сред разработки.
Мне кажется, что язык ограничен не столько средой разработки сколько строением чипа под который компилируется код. Среда разработки обычно поддерживает последнюю (или почти последнюю версию языка). Дело в том, что нужно очень хорошо понимать какую аппаратуру с помощью этого языка описывают. Ведь от того, что на Verilog описан неведомый компонент (о чём вым пытается намекнуть например Quartus) он не прибавится на реальном чипе.
2) для правильного описания аппаратуры необходимо знать синтаксис языка, а также анализировать списки предупреждений и ошибок, возникающих на каждом этапе построения проекта.
Мне кажется, что кроме знания синтаксиса очень важно знать и понимать, каков будет резальтат имплементации на чипе той или иной языковой конструкции. Более того, результат будет иногда разительно отличатся если взять один и тот же код и прогнать их на Quartus и Vivado, например. Да, и в том и в другом случае мы получим идентично работающие блоки. Но иногда один или другой компилятор «сожрет» по той или иной причине намного больше или что куда хуже – не те ресурсы.
Добрый день.
По поводу:
Как в Quartus и Libero SoC так и в Vivado были взяты для рассмотрения одинаковые этапы синтеза, но видимо в Vivado изначально было принято так отображать синтезируемую схему (Если не так, то надеюсь меня поправят).
На счёт замечаний по поводу выводов статьи, они будут исправлены, возможно как и остальной текст. И да кроме знания синтаксиса языка также необходимо знать основы цифровой схемотехники, стандарт используемого языка, и много чего ещё. При переносе одного проекта от одной среды разработки к другой также может возникнуть ряд сложностей, например, среда Quartus не поддерживает тип real, хотя Libero SoC и Vivado, насколько я помню, правильно их интерпретируют. Помимо этого все среды разработки позволяют выбирать стандарты языка используемого для дизайна.
По поводу:
Теперь по теме: поправьте меня если я ошибаюсь но мне кажется что результаты Quartus и Libero это и правда результат synthesis. Что же до Vivado то там уже мы видим более продвинутый этап.
Как в Quartus и Libero SoC так и в Vivado были взяты для рассмотрения одинаковые этапы синтеза, но видимо в Vivado изначально было принято так отображать синтезируемую схему (Если не так, то надеюсь меня поправят).
На счёт замечаний по поводу выводов статьи, они будут исправлены, возможно как и остальной текст. И да кроме знания синтаксиса языка также необходимо знать основы цифровой схемотехники, стандарт используемого языка, и много чего ещё. При переносе одного проекта от одной среды разработки к другой также может возникнуть ряд сложностей, например, среда Quartus не поддерживает тип real, хотя Libero SoC и Vivado, насколько я помню, правильно их интерпретируют. Помимо этого все среды разработки позволяют выбирать стандарты языка используемого для дизайна.
Мне кажется, в примере test2 вы себе таки сами стреляете в ногу.
В Verilog не 2 возможных значения входа (0 и 1), а четыре: 0, 1, z, x.
Условие вида if(~arst) транслируется в if(arst==0), то есть, определённое состояние. А вот ветка else для if(arst) превращается в if(arst==0 || arst==z || arst==x), чего достаточно, чтобы сбить с толку большинство синтезаторов самим фактом, что можно что-то проверять по условию вида arst==x. В результате это условие просто выкидывается из проверки, но с предупреждением, что так нельзя, или же оно вообще может начать делать что-то запредельно неожиданное. Я бы такое не пропускал вообще, но нельзя от программы требовать того же, что от человека, по уровню интеллекта.
В программировании есть аналогичная ситуация с плавающими числами: if(a==b) нельзя превратить в if(!(a!=b)), потому что есть случай несравнимости чисел (хотя одно из них равно NaN), при котором a==b и a!=b оба ложны.
С test3 более очевидно, что проверять на 1 после отрицательного фронта нелогично.
В Verilog не 2 возможных значения входа (0 и 1), а четыре: 0, 1, z, x.
Условие вида if(~arst) транслируется в if(arst==0), то есть, определённое состояние. А вот ветка else для if(arst) превращается в if(arst==0 || arst==z || arst==x), чего достаточно, чтобы сбить с толку большинство синтезаторов самим фактом, что можно что-то проверять по условию вида arst==x. В результате это условие просто выкидывается из проверки, но с предупреждением, что так нельзя, или же оно вообще может начать делать что-то запредельно неожиданное. Я бы такое не пропускал вообще, но нельзя от программы требовать того же, что от человека, по уровню интеллекта.
В программировании есть аналогичная ситуация с плавающими числами: if(a==b) нельзя превратить в if(!(a!=b)), потому что есть случай несравнимости чисел (хотя одно из них равно NaN), при котором a==b и a!=b оба ложны.
С test3 более очевидно, что проверять на 1 после отрицательного фронта нелогично.
Добрый день, да я с вами полностью согласен, но дело в том, что эта статья писалась с целью того, как ненужно описывать аппаратуру и что необходимо следить за тем, что происходит в проекте (ошибки, предупреждения и много чего ещё). Кроме этого в статье не отражены результаты симуляции, которые стоит добавить впоследствии.
Изначально я описал аппаратуру согласно описанию test2, который успешно синтезировался и работал на SmartFusion2, однако при попытке перенести его на Cyclone IV возникли проблемы, которые я впоследствии понял. Модули test3 и test4 я проверил чисто из интереса, а именно как их вообще могут воспринять выбранные среды разработки.
И собственно этой статьей я хотел обратить внимание начинающих разработчиков FPGA на то, что необходимо придерживаться стандартов языков, а также понимать что такое FPGA и из чего она состоит. Через некоторое время я постараюсь переписать выводы статьи.
Изначально я описал аппаратуру согласно описанию test2, который успешно синтезировался и работал на SmartFusion2, однако при попытке перенести его на Cyclone IV возникли проблемы, которые я впоследствии понял. Модули test3 и test4 я проверил чисто из интереса, а именно как их вообще могут воспринять выбранные среды разработки.
И собственно этой статьей я хотел обратить внимание начинающих разработчиков FPGA на то, что необходимо придерживаться стандартов языков, а также понимать что такое FPGA и из чего она состоит. Через некоторое время я постараюсь переписать выводы статьи.
С verilog не знаком, больше по vhdl, ко второму пункту бы добавил, что для выбранной среды и выбранной технологии/семейства неплохо изучить набор template-ов и правил inferring-a (для Vivado и то и другое прописано). То, что вы отметили, на мой взгляд, не совсем касается универсальности синтеза или языка, а больше относится к возможностям распознавания аппаратных идиом (не знаю как точнее по-русски назвать «inferring»).
Здравствуйте. Действительно достаточно интересная статья с несколькими нюансами. Как указано пользователем Wilderwein очень важно понимать на каком чипе ведется разработка. По моей памяти, к примеру, Spartan 6 нивкакую не хотел адекватно реагировать на синхронный set, при том что aset и arst синтезировал отлично (там большой вопрос в строении LUT). И то же касается всех остальных чипов. Они только для студента и системного инженера «полностью программируемые». По факту же для разработки нужно понимать как разрабатывать на чипе и чем больше уровень понимания, тем выше профессионализм разработчика.
По указанным примерам. Я проектирую на VHDL, но попытка сбросить по положительному фронту
з.ы. На картинках Vivado указаны уже синтезированные конструкции от чего ненужные буферы и т.п. Для просмотра схематика достаточно вызвать Elaborated Design — и проще, и не требует пересинтезировать каждый раз.
По указанным примерам. Я проектирую на VHDL, но попытка сбросить по положительному фронту
if (arst) begin при списке чувствительности отрицательного фронте negedge arst вызывает конфуз даже у схемотехника. Что говорить об синтезаторе. Из чего следует, что как миним перед проектированием следует ознакомится с соответствующим кодстайлом и не использовать «придуманные» конструкции либо быть готовым к «абракрадабре» после синтеза.з.ы. На картинках Vivado указаны уже синтезированные конструкции от чего ненужные буферы и т.п. Для просмотра схематика достаточно вызвать Elaborated Design — и проще, и не требует пересинтезировать каждый раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Странности синтеза при работе с FPGA