Научная электронная библиотека
Монографии, изданные в издательстве Российской Академии Естествознания
2. Разработка конфигураций ПЛИС без использования проектов САПР
Дальнейшее описание производится на примере САПР Vivado фирмы Xilinx, хотя похожие возможности есть и в других САПР.
Процесс разработки конфигураций ПЛИС без использования проектов САПР является простым и удобным решением для обозначенных проблем. В этом процессе вместо проектов САПР используются файлы описания аппаратуры (HDL), файлы ограничений и программы на скриптовом языке программирования Tcl, хранящиеся в репозитории системы управления версиями. Программы на скриптовом языке могут использовать файлы описания устройства [5], расположенные в любом месте репозитория, и могут давать инструкции для Vivado о создании временных файлов в специально созданных для этого директориях. Эти директории легко исключить из системы управления версиями, оставив в ней только файлы, созданные непосредственно разработчиком, поэтому только осмысленные изменения в файлах описания устройства будут видны в системе управления версиями. Кроме того, поскольку файлы описания аппаратуры и программы на Tcl – это всё, что необходимо для разработки конфигураций ПЛИС без использования проектов САПР, разработчик может быть уверен, что вся важная информация сохранена в системе управления версиями. Эта информация остается непротиворечивой при переключении версий и слиянии изменений сделанных в разных версиях, и другие разработчики могут произвести синтез схемы используя только те файлы, что содержится в системе управления версиями.
Поскольку каждая программа может использовать одни и те же файлы описания устройства, но при этом создавать отдельную директорию с файлами, необходимыми для её работы, различные программы не конфликтуют друг с другом при одновременной работе. Поэтому возможно запускать множество программ одновременно, даже если они используют одни и те же файлы описания устройства. Это позволяет одновременно запускать множество различных тестов для одного и того же устройства или множество различных процессов синтеза конфигурации ПЛИС. Возможна практика, при которой разработчик использует специальную программу на Tcl, которая запускает сразу все тесты в конце дня, а утром следующего дня разработчик использует другую программу, которая проверяет все отчеты о проведённых за ночь тестах на предмет наличия в них сообщений об ошибках. Данный подход позволяет значительно увеличить тестовое покрытие устройства за счёт того, что каждый раз тесты проводятся с новыми случайными воздействиями. Также, данный подход позволяет обнаруживать вновь внесённые ошибки вскоре после их внесения, что значительно облегчает их поиск и устранение.
Процесс разработки конфигураций ПЛИС без использования проектов САПР позволяет также одновременно запускать множество процессов синтеза конфигураций ПЛИС. Данная возможность позволяет одновременно попробовать разные настройки синтеза и разные оптимизационные стратегии. Также возможна одновременная сборка отдельных небольших частей устройства с целью быстрой проверки достижимости целевой частоты работы схемы для этих частей устройства. Для этого инженеру нужно создать простой модуль-обертку, который подключает все порты выбранного модуля к выводам микросхемы и создать программу для синтеза модуля-обёртки. Примером использования данной возможности является следующая ситуация. Например, разработчик может создать несколько программ для сборки отдельных модулей разрабатываемого устройства, чтобы убедиться в том, что данные модули используют приемлемое количество аппаратных ресурсов и могут работать на целевой частоте, после чего, через какое-то время, он может принять решение поменять какой-либо параметр в устройстве, который влияет на все эти модули. После изменения этого параметра разработчик может заново и одновременно запустить программы для сборки отдельных модулей устройства и убедится, что данные модули по прежнему имеют приемлемые характеристики.
Важно понимать, что использование процесса разработки конфигураций ПЛИС без использования проектов САПР не означает отказа от преимуществ графического интерфейса пользователя Vivado. Разработчик, использующий процесс разработки конфигураций ПЛИС без использования проектов САПР, может запускать графический интерфейс Vivado для изучения результатов работы программ на Tcl. Например, изучать критические пути цифровой схемы часто гораздо удобнее с помощью графического интерфейса, чем изучая текстовые отчеты. Также возможно добавить команду start_gui в любое место программы на Tcl, чтобы последующие команды выполнялись со включенным графическим интерфейсом. Возможно использование специальной константы для определения того, как должен выполняется тест – с включенным или выключенным графическим интерфейсом. Это позволяет не менять текст самой программы, а контролировать наличие графического интерфейса изменением одной константы.
Рассмотрим примеры программы Tcl для запуска теста модуля и программы для запуска синтеза конфигурации ПЛИС.
2.1. Программа на Tcl для запуска теста модуля устройства
В данном разделе мы рассмотрим простой пример программы для запуска теста, попутно разъясняя выполняемые действия.
В начале текста программы удобно определить все переменные, такие как имена файлов или имя рабочей директории. Такие переменные обычно меняются разработчиком наиболее часто и их удобно иметь в начале программы. Такой подход также улучшает читаемость программы.
Для начала определим имя рабочей директории. Имена рабочих директорий для тестов удобно начинать с sim_. Это позволяет легко отделять директории, созданные во время тестирования устройства, от директорий, содержащих исходные тексты описания устройства, и директорий, содержащих результаты синтеза схемы устройства. Имя директории для промежуточных файлов теста и отчётов о результатах тестирования должно быть уникальным для каждого теста, чтобы можно было запускать несколько тестов одновременно. Тем самым мы гарантируем, что разные тесты используют различные временные файлы, что позволяет избежать конфликтов между тестами.
Команда TCL
set simdir ./sim_OurTestbench
задаёт переменную simdir с именем директории для теста OurTestbench.
Затем, удобно задать переменную, которая определяет, как будет работать тест – в командной стоке или с графическим интерфейсом.
set visual 0
Это позволяет обычно запускать тест без графического интерфейса и переключаться на графический интерфейс только когда во время проведения теста была найдена ошибка, и разработчику требуется разобраться в её причинах, что проще сделать, используя графический интерфейс пользователя.
Мы также определяем имя модуля верхнего уровня иерархии модулей и список RTL файлов описания устройства.
Задаём имя теста в переменной tst
set tst OurTestbench
Данное имя должно совпадать с именем модуля (entity для VHDL), являющегося модулем, реализующим тест (testbench). Данное имя будет использовано в программе в дальнейшем, в том числе для запуска теста.
set slist [list \
./src/SourceFile1.vhd \
./src/OurTestbench.vhd \
]
В языках VHDL и Verilog существует такая конструкция как пакет (package). В пакетах можно определять константы, объявлять новые типы данных, функции и процедуры. Объекты, объявленные в пакете, можно использовать в файлах, описывающих модули устройства, а также в других пакетах. Применение пакетов позволяет избежать повторения описания одного и того же объекта в нескольких файлах.
Однако при использовании пакетов следует соблюдать некоторые правила касательно порядка загрузки файлов. Поскольку файлы из списка slist будут считываться и обрабатываться в том же
порядке, в котором они перечислены в списке, то следует убедиться, что файлы с пакетами (package) перечислены перед файлами, в которых эти пакеты используются, иначе Vivado сообщит об ошибке и о том, что подключаемый пакет ещё не был скомпилирован. То же замечание относится и к самим пакетам, если одни пакеты используют другие пакеты.
Если в устройстве используются IP-ядра, то в список slist следует добавить файлы <имя_ядра>_stub.vhdl (или .v) и <имя_ядра>_sim_netlist.vhdl (или .v). Эти два файла могут быть найдены в директории IP-ядра. Эти файлы автоматически создаются при создании IP-ядра во время шага Generate output products и позволяют симулятору симулировать поведение ядра.
После объявления наименования целевого устройства с помощью команды
set_part -quiet <device_p/n>
можно воспользоваться командой, которая разрешает Vivado работать в несколько потоков
set_param general.maxThreads 8
В этом примере команда позволяет использовать до 8 потоков. Данная команда повышает скорость работы программы, если она запущена на компьютере, имеющим больше одного процессорного ядра. Поскольку многоядерные процессоры широко распространены, то использование данной команды почти всегда полезно.
Создадим директорию для временных файлов и отчётов о симуляции и сделаем эту директорию текущей, чтобы все временные файлы и файлы отчёта создавались в ней.
file mkdir $simdir
cd $simdir
Поскольку пути к файлам описания устройства были заданы относительно директории, в которой расположена программа для запуска теста, а после выполнения предыдущей команды текущая директория оказалась одним уровнем «ниже», пути к файлам описания устройства следует использовать с префиксом $srcdir, где srcdir определена следующим образом.
set srcdir ./..
Таким образом переменная srcdir содержит путь к директории, в которой расположена текущая директория.
Загрузим все исходные файлы в память, перебрав все файлы из списка slist и считав их командой xvhdl. Для описаний на языке Verilog следует использовать команду xvlog взамен xvhdl.
foreach a $slist {exec cmd /c xvhdl $srcdir/$a}
Как уже было описано, использование рандомизированного тестирования со случайным вектором инициализации ГПСЧ увеличивает тестовое покрытие и повышает качество тестирования, что в свою очередь положительно сказывается на сроках разработки устройства, снижает затраты на его разработку и улучшает качество устройства. В нашем примере мы тоже будем использовать этот полезный прием, и продемонстрируем, насколько это несложно.
Существуют различные способы получения случайного вектора инициализации ГПСЧ, мы рассмотрим один из самых простых.
Для получения случайных значений в данном примере мы используем системную переменную окружения Windows %RANDOM %, которая принимает значения от 0 до 32767. Возможно также использовать и другие источники случайных чисел. Поскольку переменная %RANDOM % имеет небольшой диапазон значений, то для получения одного вектора инициализации можно использовать несколько значений полученных из системной переменной окружения, что позволяет получить большую область возможных значений вектора инициализации. В нашем примере предполагается, что в программу передаётся два случайных аргумента, значения которых мы присваиваем переменным seeda1 и seeda2. После этого, комбинируя эти две переменные мы создаём переменную seeda с расширенным диапазоном возможных значений.
set seeda1 [lindex $argv 0]
set seeda2 [lindex $argv 1]
set seeda [expr $seeda1 * 32768 + $seeda2 + 1]
Выражение для вычисления значения переменной seeda составлено таким образом, чтобы полученное значение всегда было положительным, поскольку такое значение проще использовать для генерации случайных чисел на VHDL с помощью функции uniform библиотеки ieee.math_real.
Удобно вывести на экран значения, используемые для получения вектора инициализации для того, чтобы можно было повторить тест с тем же значением вектора инициализации в случае, если во время теста будут обнаружены ошибки. Таким образом, когда инженер видит, что тест обнаружил ошибку в поведении модуля, то он читает отчёт, созданный тестом, и, помимо другой информации об ошибке, он узнаёт из этого отчёта значения, использованные для инициализации ГПСЧ. Запуск теста с этими же значениями гарантирует, что тест обнаружит ту же ошибку в тот же момент времени, что удобно для поиска причины ошибки.
puts seeda:$seeda
puts seeda1:$seeda1
puts seeda2:$seeda2
Вычисленное значение вектора инициализации ГПСЧ будет передано как параметр (generic) модуля тестирования во время выполнения процедуры elaborate.
Перед запуском теста его нужно сформировать (elaborate) c помощью команды xelab. Для примера предположим, что тест в описываемом примере имеет два параметра (generic в терминах VHDL): seed и Encoder, то есть модуль OurTestbench содержит два параметра (generic), которые влияют на его поведение. Первый параметр seed является вектором инициализации ГПСЧ, который влияет на формируемые для тестируемого модуля воздействия. Второй параметр может быть, например, параметром передаваемым тестируемому модулю и меняющим его поведение. Параметры generic передаются симулятору с помощью опции -generic_top команды xelab.
Полный список опций команд Vivado с их описанием можно получить с помощью вызова в командной оболочке vivado интересующей команды с опцией -help. Например xelab -help.
Запустим программу предварительной обработки описания устройства с вычисленным параметром [5] и параметром Encoder=1:
set seedf «seed=»
exec xelab -s ${tst}Enc --debug typical \
-generic_top $seedf$seeda \
-generic_top «Encoder=1» work.$tst
Следует отметить, что символ «\» используется для того, чтобы экранировать перенос строки при разбиении команды на несколько строк для повышения читаемости исходного текста программы и этот символ должен располагаться непосредственно перед символом переноса строки.
Затем запустим тест:
if [ expr $visual == 1] {
start_gui
xsim -log sim_${tst}Enc.log \
-view $srcdir/${tst}Enc.wcfg ${tst}Enc
} else {
exec cmd /c xsim -R -onerror quit \
-log report_${tst}Enc.log ${tst}Enc
}
Представленный набор команд демонстрирует сразу несколько полезных возможностей. Если объявление переменной visual было изменено разработчиком на «set visual 1» в первых строках программы, то во время выполнения команды start_gui будет запущен графический интерфейс пользователя и все дальнейшие команды будут выполняться в графическом режиме. Кроме того, при запуске симуляции командой xsim будет использована опция -view, которая позволяет указать симулятору файл настроек отображения состояний сигналов на экране. При первом запуске симуляции в графическом режиме этого файла существовать не будет, и симулятор выдаст ошибку, сообщающую, что файл не найден. Если после получения этой ошибки разработчик создаст (через меню File → New Waveform Configuration) файл конфигурации с соответствующим названием, то при последующих запусках данный файл конфигурации будет автоматически загружаться, что повышает удобство пользования симулятором в графическом режиме.
Продолжим исследование программы для запуска тестов.
Предположим, что после окончания теста мы хотим повторить тест с другим значением параметра Encoder. Следующий код повторяет сборку теста и его запуск, но уже с Encoder=0 и, как видно из значения опции -log команды xsim, отчёт о результатах тестирования с параметром Encoder=0 будет записан в файл с другим именем.
exec xelab -s ${tst}Dec --debug typical -generic_top $seedf$seeda \
-generic_top «Encoder=0» work.$tst
if [ expr $visual == 1] {
start_gui
xsim -log sim_${tst}Dec.log \
-view ../${tst}Dec.wcfg ${tst}Dec
} else {
exec cmd /c xsim -R -onerror quit \
-log report_${tst}Dec.log ${tst}Dec
}
Закроем Vivado когда тесты проводились без графического интерфейса и все тесты окончены.
if [ expr $visual == 0] {
exit
}
На этом программа для запуска тестов заканчивается.
Если переменная visual установлена в 0 результаты тестирования будут сохранены в файлы report_OurTestbenchEnc.log и report_OurTestbenchDec.log.
Описанная программа запускается с использованием пакетного файла sim_OurTestbench.bat со следующим содержимым:
TITLE %~n0
vivado -mode tcl -tempDir tmp -source sim_OurTestbench.tcl -log vivado_sim_OurTestbench.log -tclargs %RANDOM % %RANDOM %
Первая команда устанавливает имя окна совпадающим с именем пакетного файла, что облегчает навигацию между окнами, когда запущено несколько тестов. Например, если запуск одного из тестов был остановлен Vivado из-за синтаксической ошибки, то по имени окна с ошибкой значительно проще понять, какой из тестов был остановлен.
Вторая команда пакетного файла запускает Vivado и указывает САПР команды из какого файла следует выполнять, какую директорию следует использовать для хранения временных файлов и в какой файл следует записывать отчёты о работе. Случайные значения из системной переменной окружения Windows %RANDOM % передаются в программу sim_OurTestbench.tcl с помощью опции -tclargs.
Если тест обнаруживает ошибочное поведение тестируемого модуля, то для поиска причин ошибки удобно иметь возможность повторять запуск теста так, чтобы та же ошибка повторялась одинаковым образом при каждом запуске. Для этого данный тест нужно запускать с тем же вектором инициализации ГПСЧ. Разработчику для этого следует взять значения seeda1 и seeda2 из файла отчёта Vivado и вставить эти значения вместо двух аргументов %RANDOM % в пакетный файл, запускающий тест. Поскольку в программу для запуска теста теперь
будут постоянно передаваться одни и те же аргументы, то и поведение теста будет идентичным для всех запусков. После нахождения и исправления ошибки следует вернуть системные переменные окружения %RANDOM % в пакетный файл.
Для автоматизации запуска всех тестов одновременно достаточно, например, написать пакетный файл, одновременно вызывающий все пакетные файлы запуска отдельных тестов. Приведём пример содержимого такого файла:
TITLE %~n0
start cmd /c sim_OurTestbench.bat
start cmd /c sim_OtherTestbench.bat
Первая команда задаёт имя окна, вторая команда запускает пакетный файл sim_OurTestbench.bat, причём использование команды start cmd для запуска теста позволяет запускать второй тест не дожидаясь завершения первого теста.
Как было показано в этой главе, предложенный способ запуска тестов для модулей разрабатываемого устройства позволяет запускать множество различных тестов без каких-либо ручных манипуляций. Для этого достаточно запускать пакетные файлы, которые в свою очередь вызывают Vivado, передают ему необходимые параметры и указывают какую программу на TCL необходимо выполнять. Также очевидно, что данный запуск легко автоматизировать с помощью пакетного файла одновременно вызывающего все пакетные файлы запуска отдельных тестов. Например, при использовании операционной системы Windows можно воспользоваться командой start для запуска нескольких пакетных файлов одновременно. Возможность задавать для каждого теста свою рабочую директорию позволяет запускать все тесты одновременно, что ускоряет тестирование на компьютерах с многоядерными процессорами.
Мы также продемонстрировали возможность запуска тестов без использования графического интерфейса. Если разработчики запускают тесты в конце рабочего дня для того чтобы утром следующего дня проверить, что в устройство не внесено новых ошибок, то графический интерфейс пользователя не нужен для выполнения таких тестов. Такой интерфейс будет замедлять работу компьютера и не будет приносить никакой пользы. Поэтому разумнее запускать тесты без графического интерфейса. При этом у разработчика остаётся возможность включить графический интерфейс у любого теста изменением одного значения в программе на TCL.
Мы также продемонстрировали, что в предложенном способе запуска тестов легко достичь того, чтобы каждый раз тесты запускались с различным вектором инициализации ГПСЧ, что позволяет каждый раз тестировать модуль с помощью новой последовательности воздействий на него.
Помимо этого, продемонстрирована возможность запуска одного и того же модуля с различными значениями параметров параметризованных модулей. Возможен запуск тестирования модуля, при котором он последовательно тестируется со всеми возможными значениями параметров. Также возможно запускать тесты со случайными значениями параметров.
Очевидно, что проверку результатов тестирования, организованного таким образом легко автоматизировать. Для этого достаточно написать несложную программу, которая проверяет содержимое всех директорий, название которых начинается на «sim_» и проверить все файлы отчёта в них на наличие сообщений об ошибках. Запуская такую программу утром, после окончания ночных тестов, разработчик может сразу получить отчёт об отсутствии или наличии обнаруженных ошибок.
Также была продемонстрирована возможность запуска отдельных тестов, в которых обнаружены ошибки с настройками, позволяющими
в точности воспроизвести ситуацию, в которой обнаружена проблема – с теми же параметрами параметризированного модуля и с тем же вектором инициализации. Данный тест можно запустить с включенным графическим интерфейсом для облегчения поиска ошибки. При этом, если тест запущен с включенным графическим интерфейсом пользователя, то при запуске тестов с несколькими различными параметрами модуля, как в нашем примере, данные тесты с различными параметрами откроются в различных вкладках Vivado, что позволит тестировать модуль с интересующими настройками.
2.2. Программа для запуска синтеза файла конфигурации ПЛИС
Опишем программу на Tcl, которая генерирует файлы конфигурации ПЛИС – файл с расширением .bit, для непосредственной конфигурации микросхемы через интерфейс JTAG и файл с расширением .mcs для загрузки его в микросхему флеш-памяти.
Как и в программе для запуска тестов, в начале программы для синтеза конфигураций определим рабочую директорию, название модуля верхнего уровня иерархии, наименование целевой микросхемы, список файлов с описанием устройства.
set synthdir ./Synth_OurDesign
set topmodule TopVCU118Module
set part xcvu9p-flga2104-2L-e
set VHDL_sources [list \
./src/I2C/I2C.vhd \
./src/TopVCU118Module.vhd \
]
set ips [list \
./src/ip/ip1/ip1.xci \
./src/ip/ip2/ip2.xci \
./src/ip/clk_0/clk_0.xci \
]
set constraints [list \
./src/VCU118TopClocks.xdc \
./src/VCU118TopPins.xdc \
./src/VCU118Conf.xdc \
./src/I2C.xdc \
]
Как и в случае программы для запуска тестов, уникальность имени каждой программы для синтеза конфигурации ПЛИС гарантирует возможность одновременного запуска нескольких различных программ синтеза. Это могут быть несколько программ синтеза одной и той же конфигурации с различными настройками синтеза, несколько программ синтеза различных модулей одного устройства, либо несколько программ синтеза одной и той же конфигурации, но для различных типов микросхем. Во всех перечисленных случаях конфигурации создаются с использованием одних и тех же исходных файлов описания аппаратуры из репозитория системы управления версиями, либо с использованием практически одних и тех же файлов с небольшими различиями. Например, в случае синтеза конфигураций для различных типов микросхем, различные программы будут использовать различные файлы описания выводов микросхем вместо файла VCU118TopPins.xdc в списке constraints
Сделаем программу многопоточной, для ускорения процесса синтеза конфигурации.
set_param general.maxThreads 8
Создадим рабочую директорию и загрузим исходные файлы в память.
file mkdir $synthdir
cd $synthdir
set srcdir ./..
set outdir ./results
file mkdir $outdir
set_part -quiet $part
foreach a $VHDL_sources {
read_vhdl $srcdir/$a
}
foreach a $ips {
read_ip $srcdir/$a
}
foreach a $constraints {
read_xdc $srcdir/$a
}
Команда read_vhdl, вызываемая в цикле для всех файлов из списка VHDL_sources, считывает указанный VHDL файл в память компьютера и добавляет его содержимое в описание устройства, которое Vivado формирует в памяти компьютера. Важно следить за порядком
считывания файлов в память компьютера, поскольку если в файле используются какие-либо пакеты, то файлы, содержащие данные пакеты должны быть считаны в память перед файлами, их использующими.
Если в описании устройства есть модули, описанные на языках Verilog или SystemVerilog, то их следует считывать командой read_verilog.
Заранее сформированные IP-ядра из списка ips считываются командой read_ip. Работа с IP-ядрами в беспроектном режиме подробнее описана в следующей главе.
Команда read_xdc считывает файлы описания физических и временных ограничений. Такие файлы могут содержать описание выводов микросхемы, задавать соответствие портов модуля верхнего уровня описания устройства и выводов микросхемы, задавать соответствие выводов микросхемы и протоколов физического уровня (LVCMOS, LVDS и т. д.), которые должны использоваться для этих выводов. В таких файлах так же задают описание ограничений, накладываемых на тактовый сигнал, взаимозависимости между различными тактовыми сигналами, задержки распространения сигналов и ограничения, накладываемые на схемы пересечения сигналами границ тактовых доменов.
Имеется возможность установить параметры синтеза перед его началом [6].
set_param synth.elaboration.rodinMoreOptions «rt::set_parameter synRetiming true»
В данном случае мы устанавливаем опцию, которая включает механизм retiming. Данный механизм позволяет оптимизировать схему с целью повышения максимальной частоты её работы. Для этого Vivado ищет в сгенерированной схеме пути распространения сигнала, где за участком с большим числом элементов комбинаторной логики, соединённых последовательно, следует участок, на котором между триггерами содержится небольшое количество комбинаторных элементов, либо их нет совсем. Обнаружив такой участок, программа пытается перенести
один или несколько триггеров так, чтобы сбалансировать количество комбинаторных элементов. Такая оптимизация уменьшает максимальное количество комбинаторных элементов между двумя триггерами. Поскольку максимальная частота, на которой может работать синхронная схема определяется, в том числе, и максимальной задержкой распространения сигнала от одного синхронного элемента к другому, а такая задержка в ПЛИС зависит от количества комбинаторных элементов между триггерами, данная оптимизация позволяет увеличить максимально возможную частоту работы устройства, что в свою очередь, позволяет увеличить быстродействие этого устройства.
synth_design -top $topmodule -part $part
Команда synth_design запускает процесс синтеза цифровой схемы. Vivado формирует электрическую схему устройства на основе её описания на языке описания аппаратуры.
После синтеза схемы можно сохранить его результаты, создав точку восстановления.
write_checkpoint -force $outdir/post_synth
Точка восстановления может содержать синтезированную схему устройства, информацию о физических и временных ограничениях схемы, любую информацию о размещении элементов схемы на кристалле ПЛИС, а также любую информацию о том, как проложены электрические цепи между элементами схемы. Точку восстановления можно загрузить в память Vivado с диска компьютера с помощью команды read_checkpoint, если по какой-либо причине понадобиться перезапустить дальнейшие стадии синтеза конфигурации. Например, если после завершения выполнения всех шагов программы ограничения на время распространения сигналов не будут выполнены, то инженер может захотеть попробовать запустить процедуры расположения элементов
на ПЛИС и подключения их друг к другу с другими настройками оптимизации. Чтобы сэкономить время и не выполнять опять уже проведённый синтез схемы можно загрузить в память точку восстановления, созданную после завершения синтеза или оптимизации, запустить выбранные дополнительные оптимизации, после этого запустить процедуры расположения элементов на ПЛИС и подключения их друг к другу.
После окончания синтеза схемы также полезно сохранить некоторые отчёты САПР используя команды report_clocks, report_clock_interaction, report_timing_summary.
report_clocks -file $outdir/post_synth_clocks
report_clock_interaction -delay_type \
min_max -file $outdir/post_synth_clock_inter
report_timing_summary \
-file $outdir/post_synth_timing_summary_unc \ -report_unconstrained
Данные команды формируют отчёты, анализируя которые можно обнаружить некоторые типы ошибок, не дожидаясь полного окончания программы формирования конфигурации ПЛИС. Например, отчёт, созданный командой report_clock_interaction позволяет обнаружить неверно организованные переходы с одной тактовой частоты на другую тактовую частоту. Обнаружение такой ошибки на ранних этапах процесса формирования конфигурации ПЛИС позволяет прервать выполнение программы и приступить к исправлению ошибки раньше, чем если бы разработчик был вынужден ждать полного окончания программы для поиска ошибок. Таким образом, формирование и анализ таких промежуточных отчётов позволяет сократить время итераций разработки и повысить её скорость.
После формирования промежуточных отчётов запускается оптимизация синтезированной схемы.
opt_design
Данная команда выполняет оптимизацию схемы для выбранной микросхемы и имеет множество опций, описание которых можно найти запустив команду в командной строке Vivado с опцией -help. Запуск данной команды без опций запускает по умолчанию целый набор различных оптимизаций.
После оптимизации полученной цифровой схемы запускают процесс расположения элементов на ПЛИС.
place_design
Данная команда автоматически размещает на ПЛИС все порты схемы и её логические элементы. Элементы располагаются таким образом, чтобы, с одной стороны, уменьшить время прохождения сигнала между ними, с другой стороны, разместить эти элементы таким образом, чтобы облегчить процесс их соединения. При необходимости, инженер может также самостоятельно разместить элементы по своему усмотрению используя команду place_ports или установив свойство (property) LOC интересующих элементов в соответствующее значение с помощью команды set_property непосредственно в программе или в файле физических ограничений (xdc файле). В рассматриваемой программе всё размещение производится автоматически, за исключением ограничений на расположение портов схемы, описанном в файле VCU118TopPins.xdc, как уже было описано ранее.
После размещения можно произвести оптимизации полученной схемы и её расположения.
phys_opt_design -retime
Команда phys_opt_design производит оптимизации над теми путями распространения сигнала, для которых прогнозируется превышение времени распространения сигнала. Данная команда, запущенная без опций производит целый набор различных оптимизаций. Мы в данном случае запускаем только оптимизацию с помощью механизма retiming, который уже обсуждался в этой главе. Список возможных оптимизаций можно посмотреть в справке к этой команде с помощью запуска её с опцией -help.
Для оптимизации энергопотребления схемы, при необходимости, возможен запуск команды power_opt_design, которая автоматически применяет схемы отключения сигналов тактирования от триггеров, без изменения поведения схемы с функциональной точки зрения.
Создание точек восстановления после каждого шага не является обязательным, но может оказаться полезным.
write_checkpoint -force $outdir/post_place
route_design
Команда route_design соединяет логические элементы между собой в соответствии с разработанной цифровой схемой.
Следует отметить, что, при необходимости, запуск команды phys_opt_design возможен также и после процедуры соединения расположенных элементов.
write_checkpoint -force $outdir/post_route
Сформируем отчёты, которые следует изучить после завершения программы для поиска возможных ошибок в схеме.
report_timing_summary -file $outdir/post_route_timing_summary_unc \ -report_unconstrained
Команда report_timing_summary создаёт файл, в котором содержится информация, помогающая понять, удовлетворяет ли созданная конфигурация временным ограничениям. В частности, данный файл содержит информацию о возможных проблемах, связанных со временами распространения сигнала, данные о сигнале с наихудшими показателями распространения сигнала и суммарное время отставания всех сигналов от заданных величин, информацию о всех тактовых сигналах цифровой схемы, а также другую полезную для анализа результатов информацию.
report_drc -file $outdir/post_route_drc
Данная команда формирует отчёт о выполнении сформированной конфигурацией большого количества правил, заданных изготовителем.
Далее сформируем отчёт о количестве использованных аппаратных ресурсов ПЛИС с помощью команды report_drc. Данный отчёт позволяет оценить возможности по увеличению функциональных возможностей разрабатываемой схемы на следующих итерациях разработки, а также определить возможные альтернативные ПЛИС для реализации разработанного устройства.
report_utilization -file $outdir/utilization
Если в проектируемом устройстве установлен отладочный модуль ChipScope, то следующая команда может оказаться полезной.
write_debug_probes -force $outdir/probes.ltx
Она формирует файл, с использованием которого программа ChipScope сможет автоматически сгруппировать сигналы в шины и присвоить им корректные имена, соответствующие описанию устройства в исходных файлах.
Наконец, создаём файл конфигурации ПЛИС для загрузки непосредственно в ПЛИС и загрузочный образ .msc для записи в микросхему флэш-памяти.
write_bitstream -force $outdir/$topmodule.bit
file copy -force $outdir/$topmodule.bit ./
write_cfgmem -force -format MCS -size 128 -interface BPIx16 -loadbit «up 0x00000000 $topmodule.bit» $outdir/$topmodule.mcs
exit
Как было продемонстрировано в этой главе, предложенный способ генерации конфигураций ПЛИС обеспечивает возможность полноценного использования систем управления версиями с сохранением функциональных возможностей САПР. Для генерации конфигурации с использованием данного способа требуется несложная программа на языке TCL, которая управляет поведением САПР, файлы описания устройства на языке описания аппаратуры (например VHDL или Verilog), файлы описания физических и временных ограничений. Все указанные файлы добавляются в систему управления версиями. Изменения в само устройство вносятся с помощью изменения отслеживаемых системой управления версиями файлов описания аппаратуры и все изменения остаются задокументированными. Физические и временные ограничения, а также программа генерации конфигурации ПЛИС из имеющегося описания цифровой схемы также описываются файлами, управляемыми системой управления версиями. Данное обстоятельство позволяет иметь различные настройки генерации конфигураций в различных ветвях разработки. Таким образом, система управления версиями полностью покрывает всё описание устройства и переключение между различными версиями устройства происходит предсказуемо и без проблем. При этом файлы в системе управления версиями
являются человекочитаемыми, содержат только осмысленные изменения, внесённые разработчиком. Когда он сравнивает версии файлов, он видит те изменения, которые действительно заслуживают внимания, потому что это изменения, сделанные вручную, а значит у автора изменений была достаточно весомая причина, чтобы потратить на них свои усилия. Инженеру не приходится просматривать тысячи автоматически сделанных незначительных правок! Данное обстоятельство имеет ещё один положительный эффект – при слиянии изменений, сделанных различными разработчиками с помощью системы управления версиями, наличие в описании устройства только необходимого количества сделанных вручную правок обеспечивает либо полностью автоматическое слияние версий с объединением всех изменений, либо, при наличии конфликтов между версиями, их не очень много и они относительно легко разрешимы. Небольшое количество конфликтов обеспечивается небольшим количеством изменений, а их разрешимость тем, что все изменения сделаны разработчиками и поэтому разработчикам всегда известен смысл данных изменений, что обеспечивает возможность объединения конфликтующих строк описания.
Предлагаемый способ разработки также обладает высокой гибкостью, команды САПР совместно с языком программирования TCL позволяют разработчику задавать крайне сложное поведение САПР для генерации конфигурации ПЛИС и её анализа. Кроме того, возможен одновременный запуск множества процессов сборки конфигураций из одних и тех же исходных файлов.
2.3. Использование IP ядер
Использование IP ядер при создании конфигураций ПЛИС без использования проектов САПР, как было показано в предыдущей главе, не составляет большого труда, однако несколько отличается от использования IP ядер в проектах САПР. IP ядра сами по себе являются мини-проектами САПР, поэтому их использование вносит в работу инженера некоторые неудобства, присущие проектам. В этой главе мы рассмотрим несколько вариантов работы с IP ядрами в беспроектном режиме САПР и рассмотрим их достоинства и недостатки.
Для создания IP ядер потребуется создать проект Vivado в котором эти ядра будут настраиваться. В данном проекте создают IP ядра, конфигурируют их, устанавливая параметры ядер в требуемые для данной ситуации значения. Затем используют данное ядро для создания конфигурации ПЛИС.
Для создания IP ядер существует специальный тип проектов Vivado – Manage IP. При создании проекта следует учитывать, что IP ядра создаются для конкретных наименований микросхем ПЛИС, поэтому при создании проекта для конфигурации IP ядер следует выбрать правильную микросхему, иначе при генерации конфигурации ПЛИС САПР выдаст ошибку, сообщающую, что наименование микросхемы, выбранное во время конфигурации IP ядра, не соответствует наименованию микросхемы выбранной в качестве целевой для устройства. Также следует обратить внимание на выбор директории, в которой будет созданы файлы IP ядра. Данную директорию следует выбрать такой, чтобы было удобно добавить её в систему управления версиями и далее ссылаться на неё из других проектов, использующих это IP ядро.
Существует несколько вариантов управления IP ядрами в системе управления версиями. Один из таких вариантов – после конфигурации IP ядра, выбрать опцию синтеза Global synthesis и отказаться от генерации производных файлов (generate ip products). Опция global synthesis означает, что во время конфигурации создаётся только 3 файла – файлы с расширениями xci, xml, а так же vho или veo. В этом случае в систему управления версиями добавляют только два файла: IP configuration file (xci) и IP definition file(xml), а цифровая схема для данного IP ядра будет создана Vivado во время стадии синтеза. Данный подход к работе с ядрами позволяет хранить в системе управления версиями только два файла на каждое IP ядро, но при этом каждый раз при синтезе IP ядро синтезируется заново.
Другой подход к работе с IP ядрами удобен, когда IP ядра изменяются редко, либо совсем не изменяются в процессе разработки устройства. В этом случае возможно синтезировать ядро (out-of-context synthesis) сразу после его конфигурации, и добавить все файлы ядра в систему управления версиями. Данный способ повышает скорость синтеза конфигурации ПЛИС, что положительно сказывается на длительности каждой итерации разработки устройства, но при этом в системе управления версиями оказывается множество автоматически созданных файлов. В случае, если разработчику нужно изменить IP ядро, изменения затронут множество файлов, что вызовет неудобства, уже описанные ранее.