Использование TCL в разработке на FPGA31.08.2016 21:05

Всем привет!

Давно не писал статьи на любимую тематику и наконец-то созрел на что-то более-менее приличное и стоящее. В этой статье речь пойдет об очень интересной задаче, с которой инженер-разработчик сталкивается чуть ли не каждый день. Предлагаю вам посмотреть, каким образом можно использовать всю мощь и простоту TCL скриптов для проектирования на FPGA. В данной статье описание базируется на ПЛИС фирмы Xilinx, но это не отменяет возможностей TCL скриптов для кристаллов ПЛИС других производителей.

9a9d58766db04ddc993a2301d50f40c1.jpg
Интересно? Поехали…

Что такое 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, а вторая команда производит печать значения переменной в консоль. Для того, чтобы использовать переменные с пробелами используются кавычки. В остальных случаях они не требуются. Результат исполнения команд представлен на рисунке ниже:

5a089ee841134927bebf05f71a2ff9a7.png

На мой взгляд, главное удобство языка 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 скриптов для автоматического создания проекта на ПЛИС. Предварительные действия совсем минимальны: на локальной машине требуется наличие каталога с исходными текстами проекта, как показано на рисунке ниже.
66608e79abfd46b48aeb2b4fee53f67f.png

Для удобства я использую независимые каталоги для проектов, созданных в среде 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, который был запущен с использованием скрипта:

933cc6d4d9b24074a8157555f643ed40.png

Отдельно следует обратить внимание на процедуру 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 приведен на рисунке ниже. Для пояснения написан цикл, который выводит на экран все найденные файлы. Как видно, указывается полный путь до каждого файла.

0d89c74939254453a9bf0d3a16b6d738.png

Скрипт запускается из командной строки, либо с использованием GUI приложения Vivado. В первом случае необходимо запустить Vivado TCL Shell и написать незамысловатую команду

vivado –mode tcl –source %full_path/example.tcl

Примечание: из командной строки можно запустить и графическую среду, поменяв режим запуска mode на gui.
В среде Vivado скрипты запускаются незамысловато и просто: Menu → Tools → Run TCL Script…

ae0f8cd4284c40e3b3693c436467707e.png

На этом знакомство с языком 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

Спасибо за внимание!

Комментарии (1)

  • 31 августа 2016 в 20:46

    0

    ↑

    ↓

    Может не в тему, но… Раньше у Xilinx, в предыдущих версиях (6 и ниже), использовались ISE, PlanAhead, FPGA Editor и т.д. В FPGA Editor была очень удобная фича — автоматическое добавление пробников в готовый дизайн. Если ножка ПЛИС не использовалась в дизайне, то можно было вывести любой сигнал на эту ногу, при этом «имплементейшн» не затрагивался. Для поздней отладки это иногда здорово сокращало время на поиск ошибки.
    Теперь, с 7 версии кристаллов и выше, Xilinx использует Vivado. Так вот пробников там нет, и у народа на форумах бомбит. При этом сотрудники Xilinx обещают уже который год добавить эту фичу, но ее все нет. Вместо этого они добавили tcl скрипт add_probe. Но для меня это костыль, очень неудобно, может кто-нибудь пользовался и/или как добиться удобства FPGA Editor?

© Habrahabr.ru