Комментарии 27
Может не в тему, но… Раньше у Xilinx, в предыдущих версиях (6 и ниже), использовались ISE, PlanAhead, FPGA Editor и т.д. В FPGA Editor была очень удобная фича — автоматическое добавление пробников в готовый дизайн. Если ножка ПЛИС не использовалась в дизайне, то можно было вывести любой сигнал на эту ногу, при этом «имплементейшн» не затрагивался. Для поздней отладки это иногда здорово сокращало время на поиск ошибки.
Теперь, с 7 версии кристаллов и выше, Xilinx использует Vivado. Так вот пробников там нет, и у народа на форумах бомбит. При этом сотрудники Xilinx обещают уже который год добавить эту фичу, но ее все нет. Вместо этого они добавили tcl скрипт add_probe. Но для меня это костыль, очень неудобно, может кто-нибудь пользовался и/или как добиться удобства FPGA Editor?
Теперь, с 7 версии кристаллов и выше, Xilinx использует Vivado. Так вот пробников там нет, и у народа на форумах бомбит. При этом сотрудники Xilinx обещают уже который год добавить эту фичу, но ее все нет. Вместо этого они добавили tcl скрипт add_probe. Но для меня это костыль, очень неудобно, может кто-нибудь пользовался и/или как добиться удобства FPGA Editor?
Несколько рекомендаций:
— Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
— Комментировать большой кусок кода удобно конструкцией if 0 {… }
— Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
— Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
— Комментировать большой кусок кода удобно конструкцией if 0 {… }
— Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
Спасибо!
Задам несколько вопросов, если не против.
— Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
— Этим активно пользуюсь, не только в TCL :)
— С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?
Задам несколько вопросов, если не против.
— Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
— Этим активно пользуюсь, не только в TCL :)
— С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?
> — Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
set my-variable 42
puts ${my-variable}
Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
set my-variable 42
puts ${my-variable}
Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
Собственно, под дефайнами я и имел ввиду задание констант для проекта -переменных, хешей и т.д.
Удобна конвейерная работа, когда используется единый скрипт с flow, в котором лишь в начале подсовываются файл с дефайнами-переменными, списком RTL-исходников и файл с констрейнтами — применительно к конкретному проекту. По сути, ведь проекты отличаются только RTL, названием топ-модуля и констрентами. А flow один раз отладили, и можно использовать постоянно.
К тому же, работа в консоли позволяет проводить распределенные вычисления, если у вас имеется большой кластер из серверов (для очень тяжелых проектов)
По поводу переменных, предыдущий автор все верно написал. К примеру, вы хотите получить переменную
set new-variable ${old-variable}311
Если убрать скобки, транслятор ругнется, что нет такой переменной old-variable311. А префиксы и постфиксы на практике используются очень часто. Поэтому, проще сразу привыкнуть ставить скобки, и забыть о проблеме вообще.
В дополнение к tcl очень полезно изучить еще какой нибудь make, perl и т.д. -они полезны для составления batch файлов для потокового запуска нескольких программ, чистке логов, архивации результа и т.д.
К примеру, батч файл может содержать: очистку лога, запуск квартуса (исполняемый tcl скрипт), архивация результатов, затем запуск симулятора, а потом парсер ошибок по всем логам для выжимки сухого остатка. Запустили на ночь, и пошли спать.
На самом деле, все описанное умещается в одно емкое словосочетание Design automation.
Удобна конвейерная работа, когда используется единый скрипт с flow, в котором лишь в начале подсовываются файл с дефайнами-переменными, списком RTL-исходников и файл с констрейнтами — применительно к конкретному проекту. По сути, ведь проекты отличаются только RTL, названием топ-модуля и констрентами. А flow один раз отладили, и можно использовать постоянно.
К тому же, работа в консоли позволяет проводить распределенные вычисления, если у вас имеется большой кластер из серверов (для очень тяжелых проектов)
По поводу переменных, предыдущий автор все верно написал. К примеру, вы хотите получить переменную
set new-variable ${old-variable}311
Если убрать скобки, транслятор ругнется, что нет такой переменной old-variable311. А префиксы и постфиксы на практике используются очень часто. Поэтому, проще сразу привыкнуть ставить скобки, и забыть о проблеме вообще.
В дополнение к tcl очень полезно изучить еще какой нибудь make, perl и т.д. -они полезны для составления batch файлов для потокового запуска нескольких программ, чистке логов, архивации результа и т.д.
К примеру, батч файл может содержать: очистку лога, запуск квартуса (исполняемый tcl скрипт), архивация результатов, затем запуск симулятора, а потом парсер ошибок по всем логам для выжимки сухого остатка. Запустили на ночь, и пошли спать.
На самом деле, все описанное умещается в одно емкое словосочетание Design automation.
Понял, спасибо!
Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)
По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.
С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)
Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)
По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.
С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)
Лучше работать со списками файлов-исходников, и списком дефайнов. Почему? Потому что и исходники, и дефайны могут быть разные — набор для поведенческого временного моделирования, набор для имплементации ПЛИС, и несколько наборов для ASIC. Автоматизация поиска и составления списков в данном случае — враг, поскольку увеличивает вероятность сделать ошибку там, где ее можно исключить вовсе.
Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
Пардон, а можно ссылочку, где такое предлагается?
По работе довольно много на Tcl пишу, и никогда фигурных скобочек у имен переменых не требовалось, только значок доллара.
https://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm 7й пункт Variable substitution
Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
Спасибо за статью! Есть пара вопросов по изе.
Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?
Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.
Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?
Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.
Добрый день!
С лицензиями все по-старому. ISE вообще имеет свойство от версии к версии становиться только хуже. Благо, разработка закончилась на версии 14.7. К счастью, со всеми косяками можно совладать и привыкнуть к этим «особенностям» среды. Да, она все ещё глючная, но Vivado не менее глючная, чем ISE.
Кроме того, на Windows 10 вообще отказываются работать 64-битные приложения от Xilinx. Программирование через Impact вообще не работает. Приходится сидеть в 32-битных ISE, PlanAhead etc. а программировать через 32-bit ChipScope Analyzer. Создать из bit файла mcs можно только через командную строку или TCL скрипт. Загрузить mcs во флешку — средствами ISE вообще не получилось. Моделирование в ISim частенько отваливается и вылетает. Такие вот пироги.
Если вы про FPGA Editor под Linux, то ответа не знаю, не пробовал.
С лицензиями все по-старому. ISE вообще имеет свойство от версии к версии становиться только хуже. Благо, разработка закончилась на версии 14.7. К счастью, со всеми косяками можно совладать и привыкнуть к этим «особенностям» среды. Да, она все ещё глючная, но Vivado не менее глючная, чем ISE.
Кроме того, на Windows 10 вообще отказываются работать 64-битные приложения от Xilinx. Программирование через Impact вообще не работает. Приходится сидеть в 32-битных ISE, PlanAhead etc. а программировать через 32-bit ChipScope Analyzer. Создать из bit файла mcs можно только через командную строку или TCL скрипт. Загрузить mcs во флешку — средствами ISE вообще не получилось. Моделирование в ISim частенько отваливается и вылетает. Такие вот пироги.
Если вы про FPGA Editor под Linux, то ответа не знаю, не пробовал.
OMFG, понятно… Я просто надеялся на то, что есть хоть какой-то прогресс. А у других производителей ситуация отличается? Говорят, Quartus и вообще софт от Altera поживее.
Да, FPGA Editor, конечно же. Название забыл.
Да, FPGA Editor, конечно же. Название забыл.
Я сейчас редко пользуюсь Quartus, но в нем вообще никогда не имел проблем, все очень интуитивно. Может быть из-за того, что он мне сейчас для работы нужен раз-два в месяц. Но в нем даже прошивку зашить проще, если в JTAG-цепочке стоит две разные ПЛИС: Altera и Xilinx.
НЛО прилетело и опубликовало эту надпись здесь
Говорят, Quartus и вообще софт от Altera поживее.
Верно говорят. Причём, «поживее» — не то слово. Quartus по сравнению с Xilinx ISE — сверхстабильная и сверхудобная среда разработки. В нём просто работаешь, занимаешся делом, а не воюешь с глюками среды разработки, лезущими как тараканы из каждой щели.
А как там с поддержкой железа? Есть ли аналог FPGA Editor-а? Насколько удобно делать Place & Route?
Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?
Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?
Несколько не понял вопрос насчёт поддержки железа… Про какое «железо» речь? Если про чипы, то естественно, Quartus заточен под альтеровские матрицы.
По поводу аналога FPGA Editor-а ничего сказать не могу — мы не используем подобные инструменты в разработке.
Насчёт удобства Place & Route — опять-же не понял… FPGA это же не печатная плата — чтобы разводить её вручную. Фиттер Квартуса прекрасно справляется с поставленной задачей сам. Конечно, может появиться необходимость в «тонкой настройке» фиттера — в Квартусе для этого есть всё необходимое. Но в моей практике ни разу не возникло необходимости этим заниматься.
Ну а насчёт поиграться с демобордой — с этим проблем вообще нет никаких. Скачиваете Quartus II Web Edition (современное название — Quartus Prime Lite Edition), создаёте в нём проект под Вашу демоборду или нет, ещё проще, открываете какую-нибудь демку, идущую в комплекте с демобордой и вперёд и с песней — играйтесь наздоровье. Возможностей WEB-эдишена для этого более чем достаточно.
По поводу аналога FPGA Editor-а ничего сказать не могу — мы не используем подобные инструменты в разработке.
Насчёт удобства Place & Route — опять-же не понял… FPGA это же не печатная плата — чтобы разводить её вручную. Фиттер Квартуса прекрасно справляется с поставленной задачей сам. Конечно, может появиться необходимость в «тонкой настройке» фиттера — в Квартусе для этого есть всё необходимое. Но в моей практике ни разу не возникло необходимости этим заниматься.
Ну а насчёт поиграться с демобордой — с этим проблем вообще нет никаких. Скачиваете Quartus II Web Edition (современное название — Quartus Prime Lite Edition), создаёте в нём проект под Вашу демоборду или нет, ещё проще, открываете какую-нибудь демку, идущую в комплекте с демобордой и вперёд и с песней — играйтесь наздоровье. Возможностей WEB-эдишена для этого более чем достаточно.
Спасибо, я думаю вы ответили на мои вопросы.
НЛО прилетело и опубликовало эту надпись здесь
Place & Route — это размещение блоков на кристалле. Очень полезная вещь, если нужно, чтобы сигналы успевали дойти до следующего блока в одно и то же время. На работе в Xilinxe ISE такое использовал, когда боролся с проблемами сигналов на высоких частотах.Разрешите поинтересоваться — о каких частотах речь?
НЛО прилетело и опубликовало эту надпись здесь
Да, серьёзные частоты. На таких частотах вполне может понадобиться ручная доводка. Нам пока что выше 200 не приходилось делать.
Вы говорите о полностью ручной расстановке и трассировке логических вентилей в ПЛИС через FPGA Editor, или вы делали расстановку путём добавления pblock-s на floorplanning? Если первое, то это действительно круто. А второй способ — вроде как типичное средство достижения требуемых тактовых частот. Нам в проектах с рабочей частотой 350МГц хватало расстановки pblocks нужным образом, иначе от разводки к разводке частоты получались всегда разные. Плюс, еще есть такая штука как Promote partitions, когда закрепленные блоки удачно разведены на требуемую частоту, и в дальнейшем эта разводка и размещение используются для уменьшения времени сборки прошивки (при условии, что внутри этих блоков логика не менялась).
НЛО прилетело и опубликовало эту надпись здесь
Понял! Собственно, мы стараемся делать аналогично, если частоты обработки переваливают за 300 МГц. Как правило, основные проблемы таймингов связаны с длинными путями распространения сигналов. Часто спасает добавление триггеров в цепочку, но есть места, где этого сделать невозможно (узлы с обратными связями, например). Кстати, в этом плане у Vivado есть несомненный плюс — она без всех этих размещений для относительно простых проектов старается сделать максимально «хорошо», и ручное размещение практически не требуется.
Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
del
Зачастую TCL применяется в связке с графической оболочкой Tk (Tool Kit), но в рамках этой статьи этот аспект рассматриваться не будет.
Про TK можно посмотреть здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование TCL в разработке на FPGA