Интересно? Поехали…
Что такое TCL?
TCL (Tool Command Language) — скриптовый язык высокого уровня для исполнения различных задач. Зачастую TCL применяется в связке с графической оболочкой Tk (Tool Kit), но в рамках этой статьи этот аспект рассматриваться не будет. Язык находит широкое применение в различных задачах автоматизации процессов:
- Тестирование комплексных модулей, узлов, частей кода;
- Скоростное прототипирование;
- Создание графических интерфейсов для консольных приложений;
- Внедрение в прикладные приложения и задачи.
Так или иначе, основной функцией языка TCL является автоматизация рутинных задач, и существенное уменьшение времени, затрачиваемого на разработку. Программы на TCL не требуют компоновки и компиляции, что делает задачу отладки скриптов простой и незамысловатой. Интерпретатор TCL распространяется под свободной лицензией и доступен практически для всех платформ (во многих дистрибутивах Linux он доступен по умолчанию). Это означает, что вы можете без каких-либо ограничений использовать его в разработке частных программ и проприетарных приложений. На момент написания статьи актуальная версия TCL – 8.6. Для работы с TCL скриптами, их отладки и визуализации доступно множество дистрибутивов – MyTcl, TclKit, ActiveTcl и т.д. Цена за 1 лицензию ActiveTcl около ~1500$, что неоправданно для разработки коммерческих приложений. Из личной практики, большая часть разработчиков пользуется привычной командной строкой.
Все программы на языке TCL состоят из команд, которые разделяются символом ";" или символом начала новой строки. Как и во многих других языках программирования, первое слово — команда, остальные слова — аргументы команд.
command arg1 argt2 … argN
Например:
set NewValue “Hello World!”
puts $NewValueПервая команда создает переменную NewValue, а вторая команда производит печать значения переменной в консоль. Для того, чтобы использовать переменные с пробелами используются кавычки. В остальных случаях они не требуются. Результат исполнения команд представлен на рисунке ниже:
На мой взгляд, главное удобство языка TCL заключается в том, что любой аргумент команды может быть заменен другой командой. Для этого его необходимо поместить в квадратные скобки. На примере ниже я покажу эту возможность. Помимо всего прочего, TCL способен управлять поведением программы на основе различных событий. Это означает, что обработчик команд может выполнять те или иные действия не только по условию, записанному в скрипте, но и по всевозможным внешним событиям (изменение значение переменной во внешнем файле, захват данных в канале, завершение исполнения приложения, достижение счетчика таймера определенного значения и т.д.). Язык TCL богат набором команд, содержит достаточно удобные средства работы с массивами данных и регулярными выражениями. На TCL реализована возможность написания функций и процедур, доступно описание циклов и выражений по условию, что существенно облегчает написание код.
Зачем вам TCL?
Практически все разработчики на FPGA/ASIC рано или поздно сталкиваются с языком TCL в своих проектах. В современной разработке на ПЛИС скрипты TCL активно применяются для задач автоматизации и интеграции процессов. TCL входит во все ведущие САПР ПЛИС – Quartus для Altera, ISE Design Suite и Vivado для Xilinx. Что позволяет сделать TCL?
- создание проекта (добавление исходных файлов, установка опций, иерархии дизайна, назначение файла верхнего уровня и т.д.),
- синтез и трассировка (вплоть до создания независимых стадий с разными настройками),
- тестирование законченных узлов, отдельных модулей и всего проекта целиком,
- автоматическая генерация файлов ограничений (UCF / XCI) на базе шаблонов,
- проверка временных ограничений для синтезированного и трассированного проекта.
- задание параметров цепей, компонентов и примитивов ПЛИС, установка опций для IP-ядер,
и т.д.
Все эти стадии, так или иначе, являются базовыми операциями в процессе разработки на ПЛИС: от создания моделей поведения узлов на языках VHDL/Verilog до отладки законченного проекта в САПР на этапе синтеза и трассировки. Как правило, сложные проекты содержат большое число модулей, написанных разными разработчиками, несколько IP-ядер, файлы ограничений, библиотеки и пакеты функций. В итоге, законченный проект имеет некую иерархичную структуру и набор правил для подключения тех или иных модулей к требуемым узлам проекта. Разработчику сложно держать в голове знания о том, где и как должны находиться отлаженные модули и какие функции они выполняют, если в его работе они используются, но знания об их работе не требуются на этапе разработки (так называемые “black-box” модули). На помощь приходит TCL скрипт, который управляет структурой проекта и связывает требуемые узлы по заранее подготовленным шаблонам. Это обеспечивает гибкость в разработке и даёт возможность повторяемости законченных узлов при миграции от одного проекта к другому.
Как правило, одновременно со стадией создания новых узлов для ПЛИС протекает стадия отладки этих узлов отдельно от проекта и в совокупности с законченной системой. Первичное моделирование проводится абстрагировано от ПЛИС на компьютере в специализированных САПР и средах моделирования: это Modelsim, ISim, Aldec Active-HDL и другие. Для реализации задачи отладки проектов на помощь также приходят TCL скрипты, позволяющие обрабатывать события, возникающие во время моделирования, и принимать решения по результатам работы модели. При отладке RTL-узла чисто на HDL языках может возникнуть сложность написания модели, поскольку любое изменение в поведении схемы приведет к необходимости изменения модели и наборов тестирования. Использование связки модели на HDL языке и TCL скриптах достаточно удобно и для многих решений позволяет ускорить процесс отладки, а также унифицировать сложные тесты.
За стадиями написания кода и его отладки следуют привычные шаги синтеза, размещения и трассировки проекта в кристалле ПЛИС. Пожалуй, это один из самых сложных шагов, который требует больших вычислительных ресурсов рабочей станции и длительного времени исполнения до полного завершения. Скрипты TCL позволяют управлять событиями выполнения на каждой стадии, анализировать результаты тех или иных вычислений для достижения наилучших характеристик по разводке и трассировке проекта (объем занимаемых ресурсов, максимальные тактовые частоты, допустимые значения задержек по таймингам и прочее). Кроме того, TCL дает возможность исключить рутинные действия по выбору и смене настроек, повторному запуску стадий проверок, перезапуску конкретного этапа при создании файла прошивки ПЛИС. Такая автоматизация проектирования практически полностью исключает постоянное присутствие человека на этих стадиях.
Надеюсь, что, дочитав до этих строк, вы уже убеждены в том, что TCL – удобная и мощная штука, которой крайне необходимо пользоваться в своих проектах. Ниже я разберу один из полезных скриптов, который используется нашей командой для создания проекта в среде Vivado, для добавления уже написанных файлов исходных текстов, всевозможных IP-ядер, файлов ограничений XCI и многое другое.
TCL your FPGA!
Рассмотрим один из самых простейших TCL скриптов для автоматического создания проекта на ПЛИС. Предварительные действия совсем минимальны: на локальной машине требуется наличие каталога с исходными текстами проекта, как показано на рисунке ниже.
Для удобства я использую независимые каталоги для проектов, созданных в среде Xilinx ISE Design Suite и в Vivado, если это позволяет семейство ПЛИС (7 серия: Artix, Kintex, Virtex). Исходные файлы лежат в каталоге /src, проект vivado в одноименном каталоге, а проект для среды ISE создается в каталоге /ise, но результаты синтеза и разводки сохраняются в директории /implement. Все это сделано для удобства управления проектом в целом и независимого управления в разных средах. Также это делает иерархию более наглядной и избавляет вас от кучи мусорных файлов в исходниках. Отдельно следует отметить каталог /top в директории исходных текстов, где лежит файл верхнего уровня и необходимые файлы ограничений (для ISE это *.ucf файл, для Vivado это *.xdc файл).
Проект содержит смешанные IP-ядра – старые, созданные в ISE и новые, созданные в Vivado. В каталоге core_k7 лежат все ядра, созданные в CoreGenerator для ISE. Они не регенерируются и не обновляются при использовании в проекте Vivado (причем файл *.vhd используется для моделирования, файл *.ngc – для синтеза, а файл *.xco в проект Vivado не добавляется). В каталоге /ipcores лежат новые ядра в формате *.xci, созданные непосредственно в среде Vivado. Следует отметить, что для каждого ядра требуется отдельная под-директория, иначе для IP-ядер в проекте устанавливается атрибут “LOCKED”, что не дает возможности обновлять ядра и регенерировать их для синтеза.
Перейдем к описанию TCL скрипта:
# Stage 1: Specify project settings
set TclPath [file dirname [file normalize [info script]]]
set NewLoc [string range $TclPath 0 [string last / $TclPath]-5]
set PartDev "xc7k325tffg900-2"
set PrjDir [string range $TclPath 0 [string last / $NewLoc]]
set TopName [string range $NewLoc [string last / $NewLoc]+1 end]Первая строка ищет расположение TCL скрипта на локальной машине (находится в каталоге src/tcl) и создает строковую переменную с полным путём до файла.
Во второй строке создается дополнительная переменная, из которой вырезается часть пути. Обе переменные нужны для того, чтобы в следующих переменных вручную не указывать путь до проекта и название файла верхнего уровня.
Переменная PartDev содержит название кристалла ПЛИС. И это единственная переменная, которая меняется в проекте! Все остальные строки скрипта остаются НЕИЗМЕННЫМИ в любом проекте.
# Stage 2: Auto-complete part for path
set PrjName $TopName.xpr
set SrcDir $PrjDir/$TopName/src
set VivNm "vivado"
set VivDir $PrjDir/$TopName/$VivNm
cd $PrjDir/$TopName
pwd
if {[file exists $VivNm] == 1} { file delete -force $VivNm }
file mkdir $VivNm
cd $VivDirНа следующей стадии создаются дополнительные переменные, которые определяют расположение исходных файлов, создают директорию vivado, если её нет и т.д. Хочу отметить, что я проверяю наличие директории vivado на локальной машине. Если директория существует – она удаляется и создается заново, чтобы не было никаких конфликтов в новом проекте.
Команда cd меняет рабочую директорию, а команда pwd показывает расположение рабочей директории.
# Stage 3: Find sources: *.vhd, *.ngc *.xci *.xco *.xdc etc.
# This stage used instead of: add_files -scan_for_includes $SrcDir
set SrcVHD [findFiles $SrcDir "*.vhd"]
set SrcVer [findFiles $SrcDir "*.v"]
set SrcNGC [findFiles $SrcDir "*.ngc"]
set SrcXCI [findFiles $SrcDir "*.xci"]
set SrcXDC [findFiles $SrcDir "*.xdc"]
set SrcPCI [findFiles $SrcDir "cl_pcie*"]
set NewLoc [string range $SrcPCI 0 [string last / $SrcPCI]-6]
Здесь все примитивно и понятно – создаются переменные, определяющие названия всех исходных файлов в каталоге /src. Для поиска файлов используется процедура findFiles, к которой мы ещё вернемся.
Отдельно производится поиск компонента узла PCI-E, который является базовой и неотъемлемой частью для всех наших проектов.
# Stage 4: Find all subdirs for IP cores (VHD, XCO, NGC, EDN)
set PrjAll {}
lappend PrjAll $DirIps $DirAdm $SrcDir/core_v2_ise $SrcDir/core_v4_ise $SrcDir/core_v5_ise $SrcDir/core_v6_ise $SrcDir/core_k7 $SrcDir/TestBench
set SrcSim {}
for {set i 0} {$i < [llength $PrjAll]} {incr i} {
set SrcXXX [findFiles [lindex $PrjAll $i] "*.vhd"]
put $SrcXXX
foreach SrcAdd $SrcXXX {
lappend SrcSim $SrcAdd
}
}На следующей стадии производится поиск всех IP-ядер в проекте. Причем в переменную SrcSim записываются названия файлов, которые используются для моделирования. Команда lappend в цикле добавляет к переменной другие значения, формируя массив, который на языке TCL называется листом. На этом подготовительная часть скрипта заканчивается и начинается создание проекта.
# Stage 5: Create project and add source files
create_project -force $TopName $VivDir -part $PartDev
set_property target_language VHDL [current_project]
add_files -norecurse $SrcNGC
add_files -norecurse $SrcXCI
export_ip_user_files -of_objects [get_files $SrcXCI] -force -quiet
add_files $SrcVHD
add_files -fileset constrs_1 -norecurse $SrcXDCСоздаем проект, определяем файл верхнего уровня, устанавливаем тип кристалла ПЛИС (в данном примере это Kintex-7 K325T), добавляем найденные исходные файлы.
# Stage 6: Set properties and update compile order
set_property top $TopName [current_fileset]
for {set i 0} {$i < [llength $SrcSim]} {incr i} {
set_property used_in_synthesis false [get_files [lindex $SrcSim $i]]
}
set NgcGlb [findFiles $DirIps "*.ngc"]
for {set i 0} {$i < [llength $NgcGlb]} {incr i} {
set_property IS_GLOBAL_INCLUDE 1 [get_files [lindex $NgcGlb $i]]
}
set_property IS_GLOBAL_INCLUDE 1 [get_files $SrcPCI]
Устанавливаем опции для файлов моделирования (исключаем из синтеза), задаем параметр GLOBAL_INCLUDE для ядер, используемых в узле PCI-E (это специфическая особенность, требуемая для наших проектов).
# Stage 7: Upgrade IP Cores (if needed)
report_ip_status -name ip_status
set IpCores [get_ips]
for {set i 0} {$i < [llength $IpCores]} {incr i} {
set IpSingle [lindex $IpCores $i]
set locked [get_property IS_LOCKED $IpSingle]
set upgrade [get_property UPGRADE_VERSIONS $IpSingle]
if {$upgrade != "" && $locked} {
upgrade_ip $IpSingle
}
}
report_ip_status -name ip_statusНа этой стадии производится поиск IP-ядер проекта в формате XCI, проверяется необходимость обновления версии ядра и параметр locked, на который влияет смена кристалла ПЛИС. После анализа ядер происходит обновление и выдается отчет об успешно завершенной операции.
# Stage 8: Set properties for Synthesis and Implementation (Custom field)
set_property strategy Flow_PerfOptimized_high [get_runs synth_1]
set_property strategy Performance_ExtraTimingOpt [get_runs impl_1]
launch_runs synth_1
wait_on_run synth_1
open_run synth_1 -name synth_1
launch_runs impl_1 -to_step write_bitstream
wait_on_run impl_1
Завершающая стадия, на которой происходит установка настроек синтеза и трассировки – выбирается стратегия из списка доступных. Затем поочередно запускается синтез, размещение и трассировка до полной разводки прошивки ПЛИС.
Как видно, использование скрипта позволяет избавить пользователя от рутинной работы по созданию проекта, добавлению новых файлов, обновлению IP-ядер и многих других однотипных вещей. Скрипт полностью автоматизирован и требует установки единственного аргумента – тип кристалла ПЛИС. Его можно задать как переменную в файле, либо как аргумент, который исполняется одновременно с запуском TCL-скрипта. На рисунке ниже приведен скриншот рабочей области проекта в среде Vivado, который был запущен с использованием скрипта:
Отдельно следует обратить внимание на процедуру findFiles, с помощью которой можно производить поиск всех файлов в директории. Аргументы функции: basedir – каталог поиска, pattern – маска поиска.
proc findFiles { basedir pattern } {
set basedir [string trimright [file join [file normalize $basedir] { }]]
set fileList {}
foreach fileName [glob -nocomplain -type {f r} -path $basedir $pattern] {
lappend fileList $fileName
}
foreach dirName [glob -nocomplain -type {d r} -path $basedir *] {
set subDirList [findFiles $dirName $pattern]
if { [llength $subDirList] > 0 } {
foreach subDirFile $subDirList {
lappend fileList $subDirFile
}
}
}
return $fileList
}Поиск выполняется в несколько шагов: определение рабочей директории как шаблона файла, создание списка по имени файла с указанием полного пути и формирование массива-списка типа list, если найденных файлов больше одного. Пример работы функции findFiles приведен на рисунке ниже. Для пояснения написан цикл, который выводит на экран все найденные файлы. Как видно, указывается полный путь до каждого файла.
Скрипт запускается из командной строки, либо с использованием GUI приложения Vivado. В первом случае необходимо запустить Vivado TCL Shell и написать незамысловатую команду
vivado –mode tcl –source %full_path/example.tclПримечание: из командной строки можно запустить и графическую среду, поменяв режим запуска mode на gui.
В среде Vivado скрипты запускаются незамысловато и просто: Menu -> Tools -> Run TCL Script…
На этом знакомство с языком TCL завершается. На этом возможности автоматизации проектов не заканчиваются. В этом простом примере я хотел показать, как с использованием TCL скриптов можно автоматизировать проектирование на ПЛИС. Язык TCL является очень удобным, простым для понимания и самое главное – открытым для использования. По личным оценкам, внедрение скриптов в жизнь разработчиков позволяет в несколько раз уменьшить время на полное создание проекта от начальной до завершающей стадии, и оставить больше времени на «чистую» разработку (написание кода). Ниже приведены полезные ссылки для знакомства с TCL-скриптами на FPGA.
Литература:
- Vivado Design Suite User Guide — Using Tcl Scripting
- Vivado Design Suite Tcl Command Reference Guide
- TCL Tutorial
- Использование TCL в проекте Марсоход
- Статический временной анализ FPGA
- Поднимаем SOC: ARM + FPGA
Спасибо за внимание!
Комментарии (26)
Khort
31.08.2016 21:32+1Несколько рекомендаций:
— Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
— Комментировать большой кусок кода удобно конструкцией if 0 {… }
— Тиклевский скрипт эстетичней бить на иерархию: отдельно дефайны с конфигурацией, отдельно процедуры, и т.д. Для вызова вложений используется команда source inc_file.tcl
capitanov
31.08.2016 22:25Спасибо!
Задам несколько вопросов, если не против.
— Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
— Этим активно пользуюсь, не только в TCL :)
— С процедурами — верно подмечено, я стараюсь так делать, если скрип разрастается до больших размеров. Вызов вложений тоже удобная штука (использую для стадий synthesis / implement). А вот дефайнами не пользовался. Можете пример привести?naryl
31.08.2016 23:02> — Это дело привычки или есть какая-то особенность брать в фигурные скобки переменные?
Во-первых, в строках если нужно уточнить где заканчивается имя переменной, и продолжается просто строка.
Во-вторых, в Tcl имена-с-чёрточками понимаются везде, кроме подстановки, т.е.
set my-variable 42
puts ${my-variable}
Если вы используете CamelCase, а не lisp-case, то причин брать всегда в скобки почти нет.
Khort
01.09.2016 08:19Собственно, под дефайнами я и имел ввиду задание констант для проекта -переменных, хешей и т.д.
Удобна конвейерная работа, когда используется единый скрипт с flow, в котором лишь в начале подсовываются файл с дефайнами-переменными, списком RTL-исходников и файл с констрейнтами — применительно к конкретному проекту. По сути, ведь проекты отличаются только RTL, названием топ-модуля и констрентами. А flow один раз отладили, и можно использовать постоянно.
К тому же, работа в консоли позволяет проводить распределенные вычисления, если у вас имеется большой кластер из серверов (для очень тяжелых проектов)
По поводу переменных, предыдущий автор все верно написал. К примеру, вы хотите получить переменную
set new-variable ${old-variable}311
Если убрать скобки, транслятор ругнется, что нет такой переменной old-variable311. А префиксы и постфиксы на практике используются очень часто. Поэтому, проще сразу привыкнуть ставить скобки, и забыть о проблеме вообще.
В дополнение к tcl очень полезно изучить еще какой нибудь make, perl и т.д. -они полезны для составления batch файлов для потокового запуска нескольких программ, чистке логов, архивации результа и т.д.
К примеру, батч файл может содержать: очистку лога, запуск квартуса (исполняемый tcl скрипт), архивация результатов, затем запуск симулятора, а потом парсер ошибок по всем логам для выжимки сухого остатка. Запустили на ночь, и пошли спать.
На самом деле, все описанное умещается в одно емкое словосочетание Design automation.capitanov
01.09.2016 11:03Понял, спасибо!
Приму на вооружение ваши советы по поводу скобок, действительно полезно и не даст запутаться. :)
По поводу скрипта для flow. Зачем подсовывать каждый раз новые исходники и явно это указывать? Я постарался отойти от этой стадии и автоматизировать процесс поиска исходных файлов, чтобы разработчикам по команде не нужно было думать о том, что и как поменять. В том скрипте, на котором построен мой пример, нужно задать в качестве аргумента только кристалл ПЛИС, а проект соберется сам: найдет исходники, добавит ядра, обновит их, если надо, запустит синтез и имплемент. Таким образом, разработчику вообще не надо думать, что там в этом скрипте написано и зачем. Если есть четкие правила по именованию файлов верхнего уровня и расположению исходников, ядер и файлов для моделирования, то сам скрипт получается ещё проще.
С batch-файлами действительно удобно. Мы как раз сейчас активно занимаемся автоматизацией проектирования (особенно для сложных проектов с объемом ресурсов ПЛИС >80%), чтобы не запускать ручками процессы, а прийти и увидеть картинку по лучшей разводке. :)Khort
01.09.2016 14:52Лучше работать со списками файлов-исходников, и списком дефайнов. Почему? Потому что и исходники, и дефайны могут быть разные — набор для поведенческого временного моделирования, набор для имплементации ПЛИС, и несколько наборов для ASIC. Автоматизация поиска и составления списков в данном случае — враг, поскольку увеличивает вероятность сделать ошибку там, где ее можно исключить вовсе.
Но я имел ввиду несколько другое — при миграции от одного проекта к другому у Вас остается тот же flow-скрипт, а меняются лишь подгружаемые tcl модули с дефайнами, списками и констрентами. Когда используете отлаженное flow, меньше делаете ошибок.
nikolay_karelin
01.09.2016 14:37Название переменных корректнее в фигурные скобки заключать. Пример: puts ${NewValue}
Пардон, а можно ссылочку, где такое предлагается?
По работе довольно много на Tcl пишу, и никогда фигурных скобочек у имен переменых не требовалось, только значок доллара.
Khort
01.09.2016 15:00https://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm 7й пункт Variable substitution
Я тремя постами выше обьяснял, почему желательно фигурные скобки ставить. Транслятор в качестве названия переменной берет из текста все символы за долларом до пробела, либо то, что заключено в фигурных скобках.
Halt
01.09.2016 08:37+1Спасибо за статью! Есть пара вопросов по изе.
Оно все такое же глючное и падучее, как и раньше? Поменялись ли лицензионные ограничения для Webpack версии в последнее время или все такие же суровые?
Сделали ли линуксовую версию утилиты FPGA View или ее так и забросили совсем на уровне Win32 приложения? Уж очень было прикольно смотреть на реальную топологию кристалла, а не на абстрактные квадратики со стрелочками в ISE.capitanov
01.09.2016 10:53+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, то ответа не знаю, не пробовал.Halt
01.09.2016 11:18OMFG, понятно… Я просто надеялся на то, что есть хоть какой-то прогресс. А у других производителей ситуация отличается? Говорят, Quartus и вообще софт от Altera поживее.
Да, FPGA Editor, конечно же. Название забыл.capitanov
01.09.2016 11:30Я сейчас редко пользуюсь Quartus, но в нем вообще никогда не имел проблем, все очень интуитивно. Может быть из-за того, что он мне сейчас для работы нужен раз-два в месяц. Но в нем даже прошивку зашить проще, если в JTAG-цепочке стоит две разные ПЛИС: Altera и Xilinx.
Aquarius-Michael
01.09.2016 12:26+2У Quartus ситуация хорошая. Работает и 32- и 64-разрядные приложения. И в Linux, и в Windows.В последних версиях, насколько я помню уже предлагают только 64-разрядные программы. Просто сам пока не работаю на новых версиях, только на старом из-за поддержки кристаллов ПЛИС.
jok40
01.09.2016 15:32Говорят, Quartus и вообще софт от Altera поживее.
Верно говорят. Причём, «поживее» — не то слово. Quartus по сравнению с Xilinx ISE — сверхстабильная и сверхудобная среда разработки. В нём просто работаешь, занимаешся делом, а не воюешь с глюками среды разработки, лезущими как тараканы из каждой щели.Halt
01.09.2016 15:46А как там с поддержкой железа? Есть ли аналог FPGA Editor-а? Насколько удобно делать Place & Route?
Наконец, какие возможности предоставляются людям, которые просто хотят поиграться с демобордой и покопаться в недрах камушков, но не хотят платить за лицензию?jok40
01.09.2016 18:28+1Несколько не понял вопрос насчёт поддержки железа… Про какое «железо» речь? Если про чипы, то естественно, Quartus заточен под альтеровские матрицы.
По поводу аналога FPGA Editor-а ничего сказать не могу — мы не используем подобные инструменты в разработке.
Насчёт удобства Place & Route — опять-же не понял… FPGA это же не печатная плата — чтобы разводить её вручную. Фиттер Квартуса прекрасно справляется с поставленной задачей сам. Конечно, может появиться необходимость в «тонкой настройке» фиттера — в Квартусе для этого есть всё необходимое. Но в моей практике ни разу не возникло необходимости этим заниматься.
Ну а насчёт поиграться с демобордой — с этим проблем вообще нет никаких. Скачиваете Quartus II Web Edition (современное название — Quartus Prime Lite Edition), создаёте в нём проект под Вашу демоборду или нет, ещё проще, открываете какую-нибудь демку, идущую в комплекте с демобордой и вперёд и с песней — играйтесь наздоровье. Возможностей WEB-эдишена для этого более чем достаточно.Aquarius-Michael
01.09.2016 23:42+1Place & Route — это размещение блоков на кристалле. Очень полезная вещь, если нужно, чтобы сигналы успевали дойти до следующего блока в одно и то же время. На работе в Xilinxe ISE такое использовал, когда боролся с проблемами сигналов на высоких частотах.
Отвечу на вопрос для Halt. Думаю, аналогом для FPGA Editor в Altera Quartus является Chip Planner. Просто я настолько широко Альтеровскими инструментами не пользовался. Только в Xilinx ISE использую различные инструменты из-за её специфики. В основном, в Altera использовал Qsys с IP-блоками. Остальное Altera отлично справлялась с поставленными задачами. Порой использую на работе на Altera отдельные блоки для проверки работоспособности. Просто заметил, что написанные и проверенные на Altera c ModelSim работают нормально и на Xilinx ISE.jok40
02.09.2016 07:19Place & Route — это размещение блоков на кристалле. Очень полезная вещь, если нужно, чтобы сигналы успевали дойти до следующего блока в одно и то же время. На работе в Xilinxe ISE такое использовал, когда боролся с проблемами сигналов на высоких частотах.
Разрешите поинтересоваться — о каких частотах речь?Aquarius-Michael
02.09.2016 09:16+2360 МГц. Это рабочая частота. Во время работы я заметил, что некоторые биты просто не успевали дойти до ячеек памяти, либо слишком спешили. Place & Route показал, что блок памяти расположен хаотично по всему кристаллу. Пришлось задать им нужные участки памяти.
jok40
02.09.2016 09:37Да, серьёзные частоты. На таких частотах вполне может понадобиться ручная доводка. Нам пока что выше 200 не приходилось делать.
capitanov
02.09.2016 10:01+1Вы говорите о полностью ручной расстановке и трассировке логических вентилей в ПЛИС через FPGA Editor, или вы делали расстановку путём добавления pblock-s на floorplanning? Если первое, то это действительно круто. А второй способ — вроде как типичное средство достижения требуемых тактовых частот. Нам в проектах с рабочей частотой 350МГц хватало расстановки pblocks нужным образом, иначе от разводки к разводке частоты получались всегда разные. Плюс, еще есть такая штука как Promote partitions, когда закрепленные блоки удачно разведены на требуемую частоту, и в дальнейшем эта разводка и размещение используются для уменьшения времени сборки прошивки (при условии, что внутри этих блоков логика не менялась).
Aquarius-Michael
02.09.2016 10:23+1В FPGA Editor исследовал расположение блоков, а затем вручную в ucf файле прописывал для каждого функционального блока, который напрямую связан с 360 МГц, привязку к физическим блокам на ПЛИСе. В основном, это на трассе между встроенными блоками приёмопередатчиками и блоком памяти. На этом участке плохая ситуация. Если сделать внутреннюю петлю на уровне регистров (блок памяти — регистр — блок памяти), то работает нормально. А вот с приёмопередатчиками (блок памяти — приёмопередатчики — блок памяти) плохо. Получается только, когда непрерывно передавать одно и тоже слово, которое является меткой начала данных. Если добавить какое-нибудь полезное слово данных, то начинает сбиваться. А на кристалле блоки памяти и блоки приёмопередатчиков неудачно расположены. Приходится как-то выкручиваться.
capitanov
02.09.2016 13:30Понял! Собственно, мы стараемся делать аналогично, если частоты обработки переваливают за 300 МГц. Как правило, основные проблемы таймингов связаны с длинными путями распространения сигналов. Часто спасает добавление триггеров в цепочку, но есть места, где этого сделать невозможно (узлы с обратными связями, например). Кстати, в этом плане у Vivado есть несомненный плюс — она без всех этих размещений для относительно простых проектов старается сделать максимально «хорошо», и ручное размещение практически не требуется.
Но! Живой пример (против Vivado): в проекте используется два контроллера PCI-e gen3 x8 и два контроллера памяти DDR3 для Virtex-7. ISE с минимальной расстановкой по кристаллу и ограничениями через pblocks разводит за час, а Vivado либо не разводит вообще, либо разводит в разы дольше, и по таймингам проект у неё свести не получается.
Fen1xL
Может не в тему, но… Раньше у Xilinx, в предыдущих версиях (6 и ниже), использовались ISE, PlanAhead, FPGA Editor и т.д. В FPGA Editor была очень удобная фича — автоматическое добавление пробников в готовый дизайн. Если ножка ПЛИС не использовалась в дизайне, то можно было вывести любой сигнал на эту ногу, при этом «имплементейшн» не затрагивался. Для поздней отладки это иногда здорово сокращало время на поиск ошибки.
Теперь, с 7 версии кристаллов и выше, Xilinx использует Vivado. Так вот пробников там нет, и у народа на форумах бомбит. При этом сотрудники Xilinx обещают уже который год добавить эту фичу, но ее все нет. Вместо этого они добавили tcl скрипт add_probe. Но для меня это костыль, очень неудобно, может кто-нибудь пользовался и/или как добиться удобства FPGA Editor?