Comments 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?
0
Несколько рекомендаций:
— Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
— Комментировать большой кусок кода удобно конструкцией if 0 {… }
— Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
— Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
— Комментировать большой кусок кода удобно конструкцией if 0 {… }
— Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
+1
Спасибо!
Задам несколько вопросов, если не против.
— Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
— Этим активно пользуюсь, не только в TCL :)
— С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?
Задам несколько вопросов, если не против.
— Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
— Этим активно пользуюсь, не только в TCL :)
— С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?
0
> — Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
set my-variable 42
puts ${my-variable}
Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
set my-variable 42
puts ${my-variable}
Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
0
Собственно, под дефайнами я и имел ввиду задание констант для проекта -переменных, хешей и т.д.
Удобна конвейерная работа, когда используется единый скрипт с 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.
0
Понял, спасибо!
Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)
По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.
С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)
Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)
По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.
С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)
0
Лучше работать со списками файлов-исходников, и списком дефайнов. Почему? Потому что и исходники, и дефайны могут быть разные — набор для поведенческого временного моделирования, набор для имплементации ПЛИС, и несколько наборов для ASIC. Автоматизация поиска и составления списков в данном случае — враг, поскольку увеличивает вероятность сделать ошибку там, где ее можно исключить вовсе.
Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
0
Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
Пардон, а можно ссылочку, где такое предлагается?
По работе довольно много на Tcl пишу, и никогда фигурных скобочек у имен переменых не требовалось, только значок доллара.
0
https://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm 7й пункт Variable substitution
Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
0
Спасибо за статью! Есть пара вопросов по изе.
Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?
Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.
Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?
Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.
+1
Добрый день!
С лицензиями все по-старому. 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, то ответа не знаю, не пробовал.
+1
OMFG, понятно… Я просто надеялся на то, что есть хоть какой-то прогресс. А у других производителей ситуация отличается? Говорят, Quartus и вообще софт от Altera поживее.
Да, FPGA Editor, конечно же. Название забыл.
Да, FPGA Editor, конечно же. Название забыл.
0
Я сейчас редко пользуюсь Quartus, но в нем вообще никогда не имел проблем, все очень интуитивно. Может быть из-за того, что он мне сейчас для работы нужен раз-два в месяц. Но в нем даже прошивку зашить проще, если в JTAG-цепочке стоит две разные ПЛИС: Altera и Xilinx.
0
UFO just landed and posted this here
Говорят, Quartus и вообще софт от Altera поживее.
Верно говорят. Причём, «поживее» — не то слово. Quartus по сравнению с Xilinx ISE — сверхстабильная и сверхудобная среда разработки. В нём просто работаешь, занимаешся делом, а не воюешь с глюками среды разработки, лезущими как тараканы из каждой щели.
0
А как там с поддержкой железа? Есть ли аналог FPGA Editor-а? Насколько удобно делать Place & Route?
Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?
Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?
0
Несколько не понял вопрос насчёт поддержки железа… Про какое «железо» речь? Если про чипы, то естественно, 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-эдишена для этого более чем достаточно.
+1
Спасибо, я думаю вы ответили на мои вопросы.
0
UFO just landed and posted this here
Place & Route — это размещение блоков на кристалле. Очень полезная вещь, если нужно, чтобы сигналы успевали дойти до следующего блока в одно и то же время. На работе в Xilinxe ISE такое использовал, когда боролся с проблемами сигналов на высоких частотах.Разрешите поинтересоваться — о каких частотах речь?
0
UFO just landed and posted this here
Да, серьёзные частоты. На таких частотах вполне может понадобиться ручная доводка. Нам пока что выше 200 не приходилось делать.
0
Вы говорите о полностью ручной расстановке и трассировке логических вентилей в ПЛИС через FPGA Editor, или вы делали расстановку путём добавления pblock-s на floorplanning? Если первое, то это действительно круто. А второй способ — вроде как типичное средство достижения требуемых тактовых частот. Нам в проектах с рабочей частотой 350МГц хватало расстановки pblocks нужным образом, иначе от разводки к разводке частоты получались всегда разные. Плюс, еще есть такая штука как Promote partitions, когда закрепленные блоки удачно разведены на требуемую частоту, и в дальнейшем эта разводка и размещение используются для уменьшения времени сборки прошивки (при условии, что внутри этих блоков логика не менялась).
+1
UFO just landed and posted this here
Понял! Собственно, мы стараемся делать аналогично, если частоты обработки переваливают за 300 МГц. Как правило, основные проблемы таймингов связаны с длинными путями распространения сигналов. Часто спасает добавление триггеров в цепочку, но есть места, где этого сделать невозможно (узлы с обратными связями, например). Кстати, в этом плане у Vivado есть несомненный плюс — она без всех этих размещений для относительно простых проектов старается сделать максимально «хорошо», и ручное размещение практически не требуется.
Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
0
del
0
Sign up to leave a comment.
Использование TCL в разработке на FPGA