С. С. Андреев, С. А. Дбар, А. О. Лацис, Е. А. Плоткина
Схемотехнический стенд mvse.kiam.ru
Руководство пользователя.
Введение.
Схемотехнический стенд mvse.kiam.ru — это вычислительный кластер под управлением СУППЗ, некоторые узлы которого оснащены реконфигурируемыми вычислительными модулями на базе ПЛИС. Определения основных понятий прикладного программирования таких вычислительных установок даны в документе "Гибридный реконфигурируемый вычислитель. Основные понятия", и предполагаются известными читателю настоящего документа. Также известными читателю предполагаются основные понятия использования кластеров под управлением СУППЗ.
Запуск гибридно-параллельных приложений возможен только на тех вычислительных узлах, которые оснащены модулями на базе ПЛИС. Чтобы запущенное при помощи команды mpirun приложение попало именно на такие вычислительные узлы, используются специальные ключи (опции) этой команды. Прожиг ПЛИС заранее подготовленной схемой в машинном формате перед запуском приложения происходит в этом случае автоматически.
Чтобы запустить гибридно-параллельное приложение, схему для загрузки в реконфигурируемый вычислительный модуль необходимо сначала синтезировать, то есть оттранслировать с того или иного языка описания схем в машинный формат, пригодный для прожига ПЛИС. В отличие от компиляции программы, синтез схемы, даже совсем простой, это довольно длительный процесс, требующий значительного процессорного времени и больших объемов памяти. Поэтому синтез схем, в отличие от компиляции программ при работе на обычном кластере, выполняется не на управляющей машине кластера, а на его вычислительных узлах. Для этого процесс синтеза запускается командой mpirun с числом требуемых процессоров, равным единице. При такой дисциплине работы каждый синтез выполняется на отдельном вычислительном узле, не мешая другим синтезам, возможно, запущенным одновременно. Синтез схемы возможен на любом узле кластера. Некоторые фазы синтеза, не требующие больших вычислительных ресурсов, могут выполняться на управляющей машине и, соответственно, запускаться не командой mpirun, а напрямую. Компиляция программной части гибридно-параллельного приложения заметных машинных ресурсов не требует, и выполняется на управляющей машине, как и при работе на обычном кластере.
1. Настройка инструментальной среды.
Конфигурационные файлы .bash_profile и .bashrc следует взять из одной из поддиректорий директории /common/profile.versions. Для начала работы рекомендуется использовать вариант из поддиректории vivado-k7-v14. Для выбора другого конкретного варианта и, возможно, для выполнения некоторых дополнительных настроек, следует посоветоваться с администратором установки.
2. Компиляция программной части приложения.
Для компиляции программной части гибридно-параллельного приложения следует использовать команду fpga_compile_{32|64|128}, где число в конце команды означает платформенную разрядность внешнего интерфейса схемы, например:
fpga_compile_64 -o myexe mysrc.c
Аргументы у этих команд те же, что и у команды mpicc. Компилируемая таким образом программа может как использовать, так и не использовать MPI.
3. Запуск гибридно-параллельного приложения.
Для запуска гибридно-параллельных приложений в настоящее время доступен только один вычислительный узел, оснащенный восемью процессорными ядрами, и восемью ПЛИС xc7k410t фирмы Xilinx. Описание схемы в машинном формате (битовая последовательность) должно находиться в файле download.bit в текущей директории. Этой схемой автоматически прожигаются все восемь ПЛИС. Протокол прожига можно посмотреть в файле manager.log (находится в директории задачи, там же, где output и errors) или командой mout.
Сообщение об успешном прожиге завершается фразой
All doneоб ошибочном - фразой
FOUND ERRORS
При успешном прожиге, каждая ПЛИС вычислительного узла становится той схемой, битовая последовательность которой была использована для прожига, и остается ей вплоть до выключения питания или нового прожига.
При разработке схемы на языках VHDL, Verilog или Автокод, пользователь иногда сам контролирует в схеме логику начального сброса. Напомним еще раз, что начальный сброс происходит ТОЛЬКО в завершающий момент прожига, и никогда больше. Никакими действиями программной части приложения повторить начальный сброс нельзя. Проектировщик схемы, в которой начальный сброс контролируется вручную, должен сам позаботиться о том, чтобы схема приходила в начальное, готовое к работе, состояние после каждого цикла срабатывания под управлением управляющей программы.
Для попадания приложения на вычислительный узел, оснащенный модулями на ПЛИС, в команде mpirun обязательно следует указать ключ "-resource fpga=k7 ", например:
mpirun -np 1 -resource fpga=k7 myexe
При отсутствии ключа "-resource" в команде mpirun, СУППЗ выделяет "ресурсный узел" под задачу в самую последнюю очередь, минимизируя занятость такого узла задачами, которым именно этот узел не нужен.
Прохождение и окончание задачи можно отследить при помощи команды mout.
Если программа не использует MPI, или формально использует его, но запускается всегда на единственном процессоре, программа может, обращаясь к функциям init_coprocessor() и set_coprocessor() (см. Руководство программиста), переключаться между всеми восемью ПЛИС. Например:
init_coprocessor(0,7); // Инициализировать доступ ко всем ПЛИС ...... set_coprocessor(0); // Сейчас будем работать с нулевой ПЛИС ...... set_coprocessor(5); // А сейчас - с пятой ......
Если же программа использует MPI, она может быть запущена на числе процессоров от 1 до 8, с обязательным указанием ключа "- ppn 8", и тогда каждому MPI-процессу имеет смысл выделить свою ПЛИС. Например:
mpirun -np 8 -ppn 8 -resource fpga=k7 myexe
MPI_Comm_rank(MPI_COMM_WORLD, &myrank);
init_coprocessor(myrank%8, myrank%8); // Инициализировать доступ к своей ПЛИС
set_coprocessor(myrank%8); // Сейчас и впредь будем работать со своей ПЛИС
.......
Взятие остатка от деления на 8 нужно для того, чтобы в будущем не менять текст программы, если вычислительных узлов, каждый из которых оснащен восемью модулями на ПЛИС, в кластере станет больше одного.
Возможны промежуточные варианты (например, четыре MPI- процесса, каждый из которых переключается между двумя ПЛИС).
Настоятельно рекомендуется указывать ключ "-ppn 8" всегда, поскольку по умолчанию предполагается "-ppn 7".
4. Синтез схем.
Как уже говорилось выше, синтез даже не очень сложной схемы требует заметного времени и больших машинных ресурсов. Поскольку управляющая машина в кластере всего одна, запуск непосредственно на ней тех фаз синтеза, которые в этом разделе указаны как предназначенные для выполнения на вычислительных узлах, категорически запрещен. Помимо того, что такой запуск является антиобщественным, он еще и не имеет особого смысла, поскольку на вычислительном узле гораздо больше как памяти, так и процессорных ядер, чем на управляющей машине. Даже если Вы абсолютно уверены, что находитесь на стенде в одиночестве, синтез, запущенный на управляющей машине, будет в лучшем случае продолжаться гораздо дольше, чем на вычислительном узле, а в худшем случае - закончится аварийно из-за нехватки памяти в самый неподходящий момент.
Конкретный вид команды запуска синтеза зависит от того, на каком языке описания схем написан исходный текст схемы. Возможны 3 варианта:
- текст написан на аннотированном С++, для трансляции схемы на VHDL используется компилятор Vivado HLS фирмы Xilinx;
- текст написан на Автокоде, для трансляции схемы на VHDL используется компилятор Автокода;
- текст написан непосредственно на VHDL, Verilog или на смеси этих языков.
В любом случае, завершающая фаза синтеза - это синтез схемы на VHDL (и/или Verilog) с последующей трассировкой и генерацией битовой последовательности. Именно эта, завершающая, фаза синтеза требует заметных машинных ресурсов, и должна выполняться исключительно на вычислительном модуле, а не на управляющей машине. На управляющей машине допускается выполнять трансляцию с С++ на VHDL при помощи Vivado HLS, а также отладочную трансляцию с Автокода на VHDL без последующего синтеза полученных текстов на VHDL.
4.1. Синтез схем, написанных на языке C/C++.
Если Ваша схема написана на языке C, то ее синтез потребует последовательного выполнения трех действий:
- трансляция содержательной части схемы из C в VHDL;
- изготовление, по исходным текстам содержательной части схемы на C и VHDL, текста интерфейсной части схемы на VHDL;
- окончательный синтез всей схемы, включая как содержательную, так и интерфейсную ее части, в битовую последовательность при помощи схемотехнической САПР.
Для лучшего понимания всего сказанного ниже в настоящем подразделе, очень желательно предварительное знакомство с Разделом 7 документа «Инженерная методика адаптации приложения к гибридному кластеру с ускорителями на ПЛИС».
4.1.1. Трансляция содержательной части схемы из C в VHDL.
Трансляция содержательной части схемы из C в VHDL выполняется так:
<команда> <имя головной функции> <имена файлов с исходным текстом>
Здесь <команда> - это одна из трех команд: hls, hls_ise или hls_vivado. Выбор конкретной команды, как будет рассказано ниже, зависит от того, какую схемотехническую САПР предполагается использовать для окончательного синтеза всей схемы. Фирма Xilinx предоставляет две таких САПР: ISE и Vivado. Vivado гораздо лучше во многих отношениях, но поддерживает только современные типы ПЛИС Xilinx (начиная с 7-й серии). САПР ISE следует использовать только в случаях, когда необходимо изготовить битовую последовательность для более старых серий ПЛИС. В настоящем документе мы будем предполагать, что используемая для окончательного синтеза схемотехническая САПР - это Vivado.
<имя головной функции> - это имя той функции, которая будет реализована аппаратно в качестве сопроцессора, и выполнение которой управляющая программа сможет запустить при помощи logic_init().
Если файлов с исходным текстом несколько, их следует указать через пробел, например:
file1.c file2.c file4.c.
Файлы с исходным текстом должны иметь расширение .c (С) или .cpp (С++). Типы файлов, транслируемых одной командой, должны быть одинаковыми.
Для работы указанных команд в текущей директории должен находиться командный файл run_hls.tcl, вызываемый изнутри указанных команд. Его образец можно скопировать из /usr/local/bin. Файл пригоден для восприятия человеком, его можно редактировать. В частности, в этом файле задается конкретная ПЛИС, для которой производится трансляция, и требуемая рабочая частота. Можно указывать и другие опции из Xilinx UG902 (официальное описание системы трансляции из C в VHDL от Xilinx).
Для доступа к встроенным математическим функциям, вроде логарифма и экспоненты, тип файлов с исходным текстом должен быть .cpp. Данные функции реализованы при помощи возможностей именно C++ (не Си), требуют включения в программу заголовочного файла hls_math.h. Этот заголовочный файл содержит специфические конструкции C++, и может включаться только в исходные файлы с типом .cpp.
Как команда hls, так и команда hls_vivado порождает протокол трансляции в файле vivado_hls.log. В этом протоколе подробно рассказано о том, какие оптимизации (развертывание циклов, конвейеризация, расслоение памяти массивов и т. п.) применил транслятор при построении схемы. При отладке исходного текста иногда требуется быстро получить именно протокол трансляции, чтобы оценить влияние внесенных в текст изменений на поведение транслятора. В этом, и только в этом, случае следует использовать команду hls. Если требуется не только протокол, но и результат трансляции, то следует использовать команду hls_vivado.
4.1.2. Изготовление текста интерфейсной части схемы на VHDL.
Помимо полученных на предыдущем этапе текстов содержательной части схемы, для подключения создаваемой схемы к стандартной интерфейсной логике необходима ее (схемы) интерфейсная часть. Ее строение зависит от того, какие параметры и как именно необходимо передавать между управляющей программой и схемой. Параметры могут быть входными скалярными, а также массивами слов платформенной ширины: входными, входными/выходными, или выходными.
В тексте схемы на C, перед объявлением заголовка головной функции, следует разместить псевдокомментарий, в котором содержится дополнительная информация о передаваемых между программой и схемой параметрах. Пример написания такого псевдокомментария приводится в Разделе 7 документа "Инженерная методика адаптации приложения к гибридному кластеру с ускорителями на ПЛИС". Команда генерации интерфейсной части схемы имеет вид:
make_vector_proc <имя головной функции> <имя файла с текстом головной функции>
Команда порождает файл vector_proc_<X>.vhd, где <X> - 32, 64 или 128, в зависимости от выбранной платформенной разрядности интерфейсной части схемы. Для успешного срабатывания команды необходимо наличие в текущей директории не только файла с исходным текстом головной функции, но и результата его трансляции на VHDL командой
hls_{ise|vivado}
4.1.3. Окончательный синтез всей схемы.
Порядок дальнейшего синтеза схемы описан ниже, в п.4.4.
4.2. Синтез схем, написанных на языке Автокод HDL/Stream.
Если Ваша схема написана на языке Автокод, то ее синтез потребует выполнения следующей команды:
avts [-vivado] <имя файла с текстом схемы> [дополнительные файлы]
При отсутствии ключа трансляция завершится созданием файла типа .vhd, синтез схемы запущен не будет. Данный вариант необходим для трансляции схемы, не содержащей головного сомпонента (см. Руководство программиста). В этом случае результат трансляции – файл имя_файла.vhd. Также данный вариант используется для начальной отладки схемы с головным компонентом (в этом случае образуется файл vector_proc_<X>.vhd).
Параметр <имя файла с текстом схемы> – имя файла с основной схемой, написанного на Автокоде (имеющего расширение .avt).
Если в основной схеме используются схемы компонентов, оформленные в виде отдельных файлов, то эти файлы указываются после исходного файла через пробел (это не относится к файлам библиотечных компонентов, см. Библиотечные компоненты). Тексты дополнительных файлов могут быть написаны на Автокоде (расширение .avt) или VHDL (расширение .vhd или .vhdl).
Все перечисленные в команде файлы должны лежать в текущей директории, а для каждого из дополнительных файлов в директории USERCOMPONENTS текущей директории должен находиться его заголовочный файл - имя_файла.h, написанный на VHDL (см. Руководство программиста).
На первом этапе команда avts транслирует файлы с раширением .avt с Автокода на VHDL, а потом полученные и, если есть, дополнительные файлы с расширением .vhd собирает в файл с основной схемой. Если схема – головной компонент, то файлу дается имя vector_proc_<X>.vhd и, при указании ключа в команде, вызывается САПР для окончательного синтеза схемы.
ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ.
Указанную команду можно запускать непосредственно (то есть на управляющей машине кластера) только при отсутствии ключа, то есть в случае, когда не запускается окончательный синтез схемы. В противном случае команду следует запускать на вычислительном узле. Делается это так:
mpirun -np 1 -maxtime 45 `which avts` -vivado <имя файла с текстом схемы> [дополнительные файлы]
Обратите внимание, что кавычки, обрамляющие `which avts`, не простые одинарные, а обратные (левый верхний угол клавиатуры, на той же клавише, что и тильда).
4.3. Синтез схем, написанных непосредственно на VHDL, Verilog или на смеси этих языков.
Синтез схем, написанных непосредственно на VHDL, Verilog или на смеси этих языков, фактически сводится к окончательному синтезу схемы при помощи схемотехнической САПР (см. ниже, п.4.4). Для правильного задания внешнего интерфейса головного компонента можно использовать в качестве примера результат трансляции с Автокода HDL на VHDL любого из примеров схем на Автокоде HDL, приведенных в «Руководстве программиста».
4.4. Окончательный синтез схемы при помощи схемотехнической САПР.
Окончательный синтез схемы предполагает, что в текущей директории находятся все входящие в состав данной схемы .vhd, .ngc, .edf, .edn - файлы, а .vhd - файл с головным компонентом схемы называется vector_proc_32.vhd, vector_proc_64.vhd, или vector_proc_128.vhd, в зависимости от используемой платформенной разрядности интерфейсной части схемы. Если эти условия соблюдены, то окончательный синтез схемы с помощью схемотехнической САПР запускается командой:
mpirun -np 1 -maxtime 45 `which build` -vivado {32|64|128}
где 32, 64 или 128 — платформенная разрядность интерфейсной части схемы.
Результатом успешного синтеза схемы будет файл download.bit в текущей директории. Именно его содержимым автоматически прожигаются все ПЛИС ускорительных модулей при запуске приложения командой mpirun с ключом -resource fpga=k7.
- Замечание.
- Пусть Вы отлаживали трансляцию текста на Автокоде на VHDL (см. выше, в разделе "Синтез схем, написанных на языке Автокод"), используя команду avts без ключа, и отладка, наконец, увенчалась успехом. Поскольку все необходимые файлы на VHDL уже получены, у Вас может возникнуть желание завершить синтез при помощи команды build, как указано выше в данном разделе. Так делать не следует. Вместо этого следует повторить команду avts, но теперь уже - с ключом.
- Конец замечания.
Синтез - длительный процесс, может занимать от 10-15 минут для простых схем до нескольких часов для сложных. Схемотехническая САПР очень многословна, и выдает по ходу синтеза, как на консоль, так и в многочисленные log-файлы, массу информации, обычно совсем не интересной конкретному пользователю. Тем не менее, из этой информации необходимо уметь извлечь главное, а именно - удался ли, в конечном итоге, синтез схемы. Как это сделать?
Главный файл с диагностикой, практически, дублирующий вывод на консоль, называется vivado.log. Его полезно проверить на предмет наличия в нем слова "Error", например, командой:
grep Error vivado.log
В полученных при этом строках диагностики будет присутствовать также информация о "Warnings", причем в огромных (сотни, возможно - тысячи) количествах. Это нормально. Внимания заслуживают Errors и Critical Warnings. Например, типичное сообщение об успешном завершении первой фазы синтеза выглядит так:
Synthesis finished with 0 errors, 0 critical warnings and 1300 warnings.
Кроме того, при синтезе схемы формируются три "тематических" log-файла, а именно:
Кроме того, при синтезе схемы формируются три "тематических" log-файла, а именно:
|
|
|
|
|
|
Файл route_timing.rpt полезно проверить на предмет сообщений о временных ошибках при прокладке цепей схемы командой:
grep Violation route_timing.rpt
В графе "Total Violation" выдаваемых при этом строк трассировочных таблиц, в конце строки, должно быть указано "0" или "N/A".
Полезно также выполнить команду:
grep constraints route_timing.rptЕсли трассировка схемы прошла успешно, среди выданных строк будет такая:
All user specified timing constraints are met.
Наконец, в файле utilization.rpt подробно рассказывается об использовании аппаратных ресурсов ПЛИС. Ресурсы, расход которых зависит от строения пользовательской схемы, можно грубо поделить на три части: универсальная логика, память и блоки DSP.
Расход универсальной логики представлен в таблице Slice Logic Distribution. Значение в правом верхнем углу таблицы (строка "Slice", столбец "Util%") - это процент использования имеющегося в составе ПЛИС ресурса универсальной логики.
Расход памяти представлен в таблице Memory, также в столбце Util% первой строки таблицы.
Расход блоков DSP представлен в таблице DSP.
Несколько слов о том, какие ресурсы на что используются. Применение ресурса универсальной логики ясно из его названия. Ресурс памяти расходуется на реализацию в схеме массивов описывающей ее программы. Если массив очень маленький, транслятор может сделать его из универсальной логики. Граница, меньше которой массив считается "очень маленьким", задается опциями компилятора при трансляции содержательной части схемы из C в VHDL.
Арифметические устройства в составе схемы можно делать как исключительно из универсальной логики, так и с использованием блоков DSP (задается опциями компилятора при трансляции содержательной части схемы из C в VHDL). Использование блоков DSP экономит ресурс универсальной логики, но может усложнить трассировку.
5. Примеры использования.
В директории /common/fpgaexamples, находятся примеры исходных текстов модельного гибридно - параллельного приложения, разработка которого подробно разбирается в документе «Инженерная методика адаптации приложения к гибридному кластеру с ускорителями на ПЛИС».
В поддиректории C/program находятся поддиректории с текстами модельного приложения и скриптами их сборки, соответствующие одноименным разделам Инженерной методики. Например, в поддиректории Part_5 расположены исходные тексты модельного приложения в том виде, как они описаны в Разделе 5, «Реализация итерационного шага вычислений с использованием буферных массивов», Инженерной методики. Комплекты исходных текстов, соответствующие нескольким первым разделам, пропущены, поскольку слишком просты, и потому не интересны.
В поддиректории C/scheme находятся исходные тексты схемы (идентичные исходным текстам из последнего по счету варианта в C/program), и скрипт синтеза схемы.