Наш цикл про ПЛИС Lattice ECP5 растянулся уже на шесть статей. Мы уже научились не только создавать простые проекты для них, но набили руку в разработке сложных систем на базе кроссплатформенной открытой среды LiteX. В целом, я уже набрал материалов, чтобы выдать инструкцию, как подключится к шине Wishbone в роли активного устройства (Master), но перед публикацией хочется провести ряд проверок, чтобы не наболтать не того.
С другой стороны, ещё в первой статье цикла я обещал, как будет формализована методика сборки синтезатора Yosys и разводчика NextPNR под Windows, рассказать, как это сделать, так как на тот момент у меня процесс сборки прошёл в режиме «неделю промучился, как-то сделал, повторить не смогу». Мой коллега систематизировал все те наброски, и теперь я могу поделиться итогами с общественностью. Так что, кто дружит с Linux, сегодня вряд ли узнает что-то интересное, а вот любители Windows – получат сведения, как начать работать с ПЛИС Lattice в этой ОС. Приступаем.
Предыдущие статьи цикла.
1. Экспериментируем с ПЛИС семейства ECP5 фирмы Lattice
2. Синтезируем SystemVerilog код в OpenSource среде Yosys/NextPNR
3. Создаём простейший проект для ПЛИС Lattice в среде Litex
4. Первые эксперименты со смешанным Litex+Verilog проектом для ПЛИС
5. Наводим красоту в коде для ПЛИС Lattice, построенном на базе пакета LiteX
6. Подключаем Slave-устройства с шиной Wishbone к системе на базе LiteX
Собираем Yosys
Начнём с простого. Со сборки синтезатора Yosys. Его исходники можно взять тут: GitHub — YosysHQ/yosys: Yosys Open SYnthesis Suite
Итак, клонируем репозиторий к себе на диск (да хоть просто скачав архив). Чтобы собрать исходный код, нам понадобится скачать и установить среду Cygwin. Причём при установке можно выбирать компоненты вручную (чем больше, тем лучше, но и ставиться это будет дольше), а можно – воспользоваться подсказкой со страницы проекта. Там говорят, что минимально необходимый набор устанавливается следующей командой:
setup-x86_64.exe -q —packages=bison,flex,gcc-core,gcc-g++,git,libffi-devel,libreadline-devel,make,pkg-config,python3,tcl-devel,boost-build,zlib-devel
Итак, Cygwin мы установили, что дальше? А дальше начинается интересное. Если просто начать процесс сборки – полезет масса ошибок. Чтобы избежать этого, нам придётся немного поправить makefile проекта. Мы сейчас, ни много ни мало, поменяем тип компилятора!
Вот самое начало makefile:
Строчку clang надо закомментировать, а gcc – наоборот раскомментировать.
Теперь находим строку:
CXXSTD ?= c++11
И меняем её на:
CXXSTD ?= gnu++11
Всё. Теперь можно собирать! Открываем консоль Cygwin, идём в каталог проекта и даём три команды:
$make config-gcc
$make
$make installВ результате, у нас появятся вот такие файлы в каталоге C:\cygwin64\usr\local\bin:
Правда, работать это будет, только если система видит сам Cygwin (то есть его надо будет включить в Path), но это не так страшно. Мы это сделаем в практической части. А пока – обратим внимание, что кроме каталога с исполняемым файлами появится и библиотечный каталог C:\cygwin64\usr\local\share\yosys:
С синтезатором покончено. Мы размялись, мы поняли, что всё не так страшно, так что приступаем к сборке трассировщика NextPNR. Правда, там всё будет несколько веселей.
Собираем проект PrjTrellis
Если синтезатор – штука довольно универсальная, то трассировщик – более специфичен. Даже под разные Латтисы надо собирать всё несколько по-разному. Не будем пытаться объять необъятное, соберём только под ECP5. Я до конца не могу сформулировать в научных терминах, но если на пальцах, то проект, который стыкует NextPNR с ECP5 (описывающий блоки, характерные для этого чипа) называется Trellis. Почему так, что там в конкретике – да какая разница? Надо собрать Trellis! И это поможет только для ECP5! Это – точно. Приступаем!
Сам проект расположен тут: GitHub — YosysHQ/prjtrellis: Documenting the Lattice ECP5 bit-stream format.
Его придётся собирать при помощи Visual Studio. И перед тем, как мы этим займёмся, установим такую замечательную утилиту, как vcpkg.
Утилита vcpkg и что мы через неё делаем
Вообще, эта утилита заслуживает отдельной статьи… Но на самом деле, такие статьи уже давно написаны. В своё время я через Гугль их много находил. Поэтому сегодня мы будем просто ею пользоваться. Если коротко, то это менеджер библиотек. Раньше надо было мучиться, скачивать библиотеки, от которых зависит тот или иной проект… Потом – библиотеки, от которых зависят скачанные библиотеки… Потом… Ну, в общем, итераций могло быть много. Потом надо было в проекте прописать пути к ним… Сейчас же в Студии всё стало так же просто, как при работе в Линуксе. Мы просим у vcpkg библиотеку. Она сама находит все зависимости, сама всё скачивает, сама располагает так, что все новые проекты будут автоматически иметь к ним доступ. Мечта! И эта мечта сбылась.
Утилита живёт тут GitHub — microsoft/vcpkg: C++ Library Manager for Windows, Linux, and MacOS
Важно запомнить, что, когда мы скачиваем библиотеки просто по имени, нам будут тянуть 32-битные версии. Чтобы стянуть 64-битные, к имени обязательно надо добавлять суффикс «:x64-windows».
Итак, если Студия у нас уже стоит (а нет – сначала ставим её), качаем vcpkg, исполняем входящий в комплект файл bootstrap-vcpkg.bat. Потом для подключения к Visual Studio подаём команду
vcpkg integrate install
У кого не стоит Питон – установите и его. Но у меня он встал вместе с Visual Studio.
Теперь ставим пакеты. Вообще, перечень пакетов указан в описании к самому NextPNR, а не к Треллису. Но коллега, который делал формальное описание процесса, велит ставить их сразу. Вот так гласит инструкция из readme.md:
vcpkg install boost-filesystem:x64-windows boost-program-options:x64-windows boost-thread:x64-windows eigen3:x64-windows
Насколько я помню, перечень не полный (при вычитке статьи, я подтверждаю – не полный, мы ещё несколько раз вспомним об этом).
Создание и сборка проекта в Visual Studio
Вот мы установили эти пакеты, что дальше? Надо открыть каталог проекта в Visual Studio. Можно это сделать через саму среду разработки, но коллега подсказал убойный вариант. Идём в каталог с PrjTrellis средствами Windows и нажимает в нём правую кнопку. Не на каком-то конкретном файле, а просто в окне с папкой. После этого, надо выбрать пункт меню «Открыть в Visual Studio». Обратите внимание, что мы открываем не просто PrjTrellis, а вложенный в него libtrellis!!!
Студия открылась, проект создался…
Но собирать этот проект рано. Дело в том, что у нас имеется только одна конфигурация – Debug:
А я помню, как отладочная сборка одной моей программы с STL работала две минуты, а Release – несколько секунд. Поэтому нам и тут лучше добавить боевую сборку. Для этого идём в управление конфигурациями (пункт меню сразу под X64-Debug на предыдущем рисунке), нажимаем на плюсик
И в появившемся окне выбираем x64 Release (обратите внимание, скроллер сдвинут, исходно эту конфигурацию было не видно)
Устраняем пару ошибок
Сохраняем файлы, выбираем вновь появившуюся конфигурацию, собираем проект…Получаем ошибки… В частности:
D:\src\Database.cpp(8): fatal error C1083: Не удается открыть файл включение: boost/property_tree/ptree.hpp: No such file or directory,
D:\lattice\prjtrellis-master\libtrellis\include\DatabasePath.hpp(18): fatal error C1083: Не удается открыть файл включение: boost/dll/runtime_symbol_info.hpp: No such file or directory,
А я говорил, что не все библиотеки были установлены! Ну что ж, хороший повод показать, как это выявляется и устраняется. Для начала спросим у vcpkg, может ли он нам добыть библиотеки с таким именем.
vcpkg search property_tree
В ответ нам сообщают:
boost-property-tree 1.78.0 Boost property_tree module
Ну прекрасно! Говорим:
vcpkg install boost-property-tree:x64-windows
Первая недостача устранена. Теперь вторая. С нею было не так просто. Но через час пыток Гугля, я нашёл вот такое утверждение:
Очень часто фигурирует слово dll. И в имени модуля оно есть, и в названии пространства имён… А нет ли чего-то подобного среди библиотек? Сейчас спросим у vcpkg:
vcpkg search dll
Прекрасно! Что делать – мы уже знаем:
vcpkg install boost-dll:x64-windows
Прогоняем сборку…
Ура! Ошибок нет!
Предпоследний шаг
Кроме исполняемых файлов, нужны базы данных. Можно их сгенерить, но можно и просто скачать. Для наших целей хватит простого скачивания. В инструкции сказано, что это делается так:
git clone —recursive https://github.com/YosysHQ/prjtrellis
Последний штрих
После сборки надо сделать развёртывание проекта. В англоязычной Студии для этого есть пункт меню Build->Install. В русскоязычном варианте это Сборка->Установить. Только давайте чуть-чуть упростим себе жизнь. Укажем каталог установки попроще. Для этого откроем свойства конфигурации и промотаем чуть-чуть вниз, до списка параметров. А сам список – до этого параметра:
Я впишу путь покороче: D:/Lattice/Trellis
Всё. Можно выполнять установку:
Вот они, наши файлы:
Чем короче пути, тем меньше потом в path вписывать…
Собираем NextPNR
Уффф. Нам остался последний шаг. Но чем дальше мы идём, тем больше подготовительных действий нам надо совершить. Студия, vcpkg и все требуемые библиотеки у нас уже стоят. При сборке этого проекта нам дополнительно потребуется прописать одну строчку. Дело в том, что если всё собирать так, как есть – будет много ошибок. Для их устранения в опциях компилятора надо объявить два макроса NOMINMAX и BOOST_CORE_USE_GENERIC_CMATH. Вся проблема в том, что коллега, который во всём этом разбирался, не нашёл, как их добавить к переменной CMAKE_PREFIX_PATH. Только взять готовую и вписать её с дополнением. Это очень плохая идея. Да, он выяснил текущее значение, но завтра оно может измениться. Если кто знает решение лучше – буду рад разъяснениям в комментариях. А пока – давайте делать так, как не совсем хорошо, но точно работает.
Итак. Скачиваем проект отсюда GitHub — YosysHQ/nextpnr: nextpnr portable FPGA place and route tool , идём в его каталог, открываем его в Студии уже привычным движением, а именно – нажав правую кнопку и выбрав пункт меню «Открыть в Visual Studio».
При открытии будут ошибки. Их надо стойко проигнорировать. Теперь привычным движением руки, как это было на предыдущем шаге, добавляем конфигурацию x64-Release. Но если в прошлый раз мы её добавили и всё, то сейчас мы будем её настраивать. Вот так выглядит окно сразу после добавления:
А мы сейчас добавим строку «Аргументы команды CMake». Начало взято из инструкции в readme.md (туда надо в несколько мест вписать пути к разным участкам Trellis), а концовка – как раз добавляет опции для компилятора. Для моего каталога, куда я установил Trellis и компилятора Microsoft, эта строка будет выглядеть так:
cmake . -DARCH=ecp5 -DTRELLIS_LIBDIR=D:/lattice/Trellis/lib/trellis -DTRELLIS_INSTALL_PREFIX=D:/lattice/Trellis -DCMAKE_PREFIX_PATH=D:/lattice/Trellis -DCMAKE_CXX_FLAGS=»/DWIN32 /D_WINDOWS /W3 /GR /EHsc -DNOMINMAX -DBOOST_CORE_USE_GENERIC_CMATH»
Проверяем:
Кому больше нравится CLang, те могут использовать такой вариант строки (отличается, начиная с -DCMAKE_CXX_FLAGS):
cmake . -DARCH=ecp5 -DTRELLIS_LIBDIR=D:/lattice/Trellis/lib/trellis -DTRELLIS_INSTALL_PREFIX=D:/lattice/Trellis -DCMAKE_PREFIX_PATH=D:/lattice/Trellis -DCMAKE_CXX_FLAGS=»-m64 -fdiagnostics-absolute-paths /DWIN32 /D_WINDOWS /W3 /GR /EHsc -DNOMINMAX -DBOOST_CORE_USE_GENERIC_CMATH»
Теперь находим очень полезную ссылку (она чуть ниже на той странице в настройках конфигурации, надо будет проскроллировать) называется «Сохранить и создать кэш CMake для загрузки переменных». Щёлкаем по этой ссылке. Иначе переменные не обновятся.
Не забываем переключиться на конфигурацию X64-Release:
Ну, здрасьте, приехали:
Очередная библиотека, которую забыли внести в требования в readme.md на github. Ну, хорошо-хорошо…
vcpkg install boost-iostreams:x64-windows
Что теперь?
Ура!
Ура! Всё собралось! Как и в случае с Trellis, я прописываю путь установки покороче:
И выполняю Сборка->Установка
Как скучно! Всего один файл! Ну ладно…
Скрытый шаг
А, нет, не скучно. Этот файл – хороший, но его мало. Это я уже при испытаниях выяснил. Надо найти каталог, откуда он скопировался, и оттуда же скопировать все DLL-ки:
Немного перфекционизма
Чтобы не плодить каталоги, я слил каталоги Trellis и NextPNR вместе. И положил рядом с исполняемыми файлами все получившиеся DLL-ки от Boost из обоих проектов. Получилось так
Дальше – любой любитель Windows разберётся :).
Для Yosys, кроме каталога с EXE-шниками, нужен ещё каталог share.
Получившуюся пару каталогов (Yosys и, как у меня случайно получилось, Trellis) можно перекидывать между машинами. Правда, где запускаем Yosys, там должен жить Cygwin, а NextPNR очень хочет присутствия Питона именно той версии, под которой он был собран. Но это – не очень страшно, это можно обеспечить. А так – всё работает!
Испытания
Ну что. Давайте испытаем всё в бою. Качаем следующий проект:
GitHub — kholia/Colorlight-5A-75B: Notes for Colorlight-5A-75B.
Идём в каталог, где есть makefile:
Надо бы запустить make, но у нас не прописаны пути. Можно их все прописать в системе… И желающие пусть так и сделают… Но я профессиональный программист. У меня такой зоопарк из средств разработки на машине – мама не горюй! Если все они будут прописаны в Path, начнётся драка… Если точнее, то уже были прецеденты. Поэтому я сейчас создам пакетный файл, в первую строку которого помещу команду setlocal. Благодаря ей все изменения в системе, сделанные за время выполнения пакетного файла, будут забыты при окончании работы с ним. Вот так будет выглядеть мой файл build.bat:
setlocal
PATH=C:\cygwin64\bin;%PATH%
PATH=D:\LATICE\Yosys;%PATH%
PATH=D:\LATICE\Trellis\bin;%PATH%
PATH=<тут длинный путь к Питону Студии>;%PATH%
PATH=D:\LATICE\OpenOCD-20210729-0.11.0\bin;%PATH%
set PYTHONHOME=<тут длинный путь к Питону Студии>
make %1Я писал ещё в первой статье цикла, что в makefile у автора есть опечатка. На старом Yosys это не вызывало проблем, сейчас я попробовал – уже вызывает. Надо поправить одну строку. Было:
yosys -p «synth_ecp5 -json $@» $(OBJS)
Стало:
Прогоняем пакетный файл, получаем:
Всё! Задача сборки проекта под Windows решена.
Заключение
Мы получили синтезатор Yosys, а также трассировщик NextPNR, работающие с ПЛИС семейства ECP5 фирмы Lattice. Собранные инструменты предназначены для запуска в ОС Windows. А как залить готовый проект в ПЛИС, описано в самой первой статье цикла. Вообще, Остап Бендер знал 400 способов сравнительно честного отъёма денег у населения и полтораста рецептов самогона. Я уже знаю четыре способа залить проект в ПЛИС Lattice. И каждый из них имеет свои достоинства и недостатки. Но об этом, если надо, можно написать отдельную статью. А пока – пользуемся базовым методом, через FT232H и OpenOCD.
В целом, не зря я собрал новую версию инструментов. Одни и те же Верилоговские исходники, собранные сентябрьским комплектом среды разработки и свежим, дают разные значения Fmax. У прогнанных через свежий комплект, этот параметр лучше. На какую величину – вопрос сложный. Зависит от проекта. И всё равно сильно плавает от минимальных правок. Но, при одних и тех же условиях, новая версия компилятора всегда даёт этот параметр чуть выше. И это верно для всех имеющихся у меня проектов.
Ну вот, дух я перевёл, теперь можно вернуться к Lattice и подключить активное устройство к шине Wishbone.
