Если вам интересно как выглядит работа Vivado на одноядерном ARM процессоре с частотой 1.8 ГГц, и 2 Гб ОЗУ, то я вам это покажу, и расскажу, как я запустил и успешно прошил плату (ДА! Собрал проект и прошил).

Вводная

Даже не знаю с чего начать. Если вы решили читать эту статью, то вас зацепило одно из знакомых слов в заголовке, либо вы понимаете, что такое Vivado и что такое Orange Pi 3, и то, что никому даром не нужна эта связка. Но все-таки, я начну с системных требований Vivado и возможностей Orange Pi 3.

Vivado 2019.1 – системные требования:

Я не смог найти однозначных значений к требованиям. Но в целом минимальные требования Vivado 2019.1 от 8 ГБ ОЗУ, 20+ГБ места на диске, и, что не мало важно, архитектура процессора x86_64.

Разумеется, потребление ресурсов ПК зависит от того какой проект грузится в Vivado. Сам запуск Vivado (с проектом) съедает 2-3 ГБ. А вот уже синтез и имплементация могут потребовать гораздо больше памяти (16 ГБ ОЗУ спокойно улетают).

Ресурсы Orange Pi 3 LTS:

Плата имеет 4-ядерный 64-битный Allwinner H6 (Cortex-A53) с частотой до 1.8 ГГц, ОЗУ 2ГБ LPDDR3.

Операционная система Debian (bullseye_desktop_xfce_linux5.16.17) будет грузиться с SD карты.

Откуда растут ноги у идеи:

Есть у меня ПЛИС Zynq7000, у которой имеется целых два ядра ARM. И на ней можно запустить полноценную Ubuntu. Конечно, полноценным это трудно назвать, но, если там все запускается и показывает (хоть и крайне медленно), значит не все так плохо. В итоге, имеем тот же самый одноплатный ПК, а если это ПК… В общем, почему бы не запустить на Zynq Vivado, не собрать проект и не прошить эту же Zynq новой прошивкой? Так сказать, замкнуть цикл разработки прошивки для платы на самой себе.

Стал я на эту тему размышлять и выяснил, что главный камень преткновения — это архитектура процессора Zynq7000, она 32 битная, а Vivado хочет 64 бита. Конечно, есть какие-то версии Vivado которые умеют на 32 битах работать, но это моментально сужает свободу действий. Ближайшая ПЛИС с 64 битный процессором это Zynq UltraScale+ MPSoC XCZU2CG с AliExpress.

Разумеется стоимость тоже важна, нужна хоть какая-то условная доступность рядовому потребителю.

Эта ПЛИС уже имеет 64 битный ARM процессор Cortex-A53. А также имеет дополнительные интерфейсы (тот же PCI-e, USB), которые могут помочь в дальнейшем запуске Vivado.

Дальше размышления я строил следующим образом: нехватку ОЗУ для Vivado можно реализовать SWAP файлом на NVME-диске, саму Vivado установить туда же. Совместимость архитектур решить через эмулятор x86_64 процессор, в данном случае это QEMU. Не хватает только одного, наличия платы у меня в руках). А покупать ее за ~45к рублей ради этого эксперимента, который мог бы еще и не получиться, я не готов.

В итоге эта идея могла на этом кануть в Лету, если бы я не вспомнил, что у меня имеется Orange Pi 3. Стоит отметить, что у ПЛИС и у Orange Pi одинаковое ядро процессора: Cortex-A53. А это означает, что если я добьюсь успеха на одноплатном ПК, то и на Zynq можно будет добиться его (правда, какой ценой…).

В случае с Orange Pi, я пошел по тому же пути размышления: ОЗУ увеличить за счет SSD, а х86_64 эмулировать через QEMU. Есть у меня SSD ADATA SC610 на 500Гб, подключается он по USB 3.0(версия и поколения не так важны, главное, что не 2.0). На самом одноплатном ПК имеется один USB 3.0, вот через него и будет происходить вся магия расширения ОЗУ и объёма дискового пространства.

Ну, а раз теоретически все требования для Vivado получается выполнить, то приступим к практической части!

Оценка работы USB SSD.

Разумеется, значения скорости чтения и записи которые пишут на страничке товара мы видим, но надо самостоятельно проверить, что да как.

Сначала я запустил тест на Windows 10 в программе CrystalDiskMark. С файловой системой extFAT(или NTFS), это я не проверил и не помню. Результаты на скриншоте ниже.

Затем я подключил SSD к OrangePi, и стал гонять там тесты. Команда для запуска выглядела примерно так:

//тест записи
dd if=/dev/zero of="/media/orangepi/ADATA SC610/testfile" bs=1M count=500 conv=fdatasync
//тест чтения 
sudo dd if="/media/orangepi/ADATA SC610/testfile" of=/dev/null bs=1M

Краткое пояснение командам: параметр BS указывает на размер блока, в данном случае это 1 мегабайт; параметр «conv=fdatasync» заставляет утилиту дождаться РЕАЛЬНОГО копирования данных на SSD(иногда данные могут просто повиснуть в буфере, а тест записи завершится значительно раньше); параметр count=500 указывает количество итераций.

Для записи данных источником данных было некое устройство с нулями if=/dev/zero.

Для чтения, данные вычитывались в несуществующее устройство of=/dev/null.

Таким образом тестировалась непосредственно сама скорость чтения и записи, а не работа передачи данных в системе.

Первые тесты скорости я проверял на той файловой системе, что была по умолчанию на SSD. Я не помню какая была точно, но точно не EXT4, поэтому указываю так не однозначно: extFAT (или NTFS). При этой файловой системе скорость передачи данных оказалась подозрительно медленной. Сначала хотел списать на особенности OrangePi, но потом пришла идея отформатировать диск в EXT4. Это дало прирост в скорости, практически в 2 раза! Результаты тестов ниже:

Хочется отметить, что тесты скорости я проводил разные, не только для bs=1M, в тестах были значения до нескольких гигабайт.

Попытка 1. Запуск эмуляции QEMU и установка Vivado 2018.3

SSD есть, OrangePi есть, тесты скорости выше нуля – значит можно приступать к настройке окружения и установки всего необходимого ПО.

Скажу сразу, эта стадия оказалась даже хуже, чем «первый блин комом», все закончилось чисткой SD карты и заливкой нового образа на нее. Поэтому, никаких полезных команд на этой стадии не скажу, только расскажу на словах.

С официального сайта был скачан образ ОС Orangepi3-lts_2.2.2_ubuntu_focal_desktop_linux5.10.75, успешно загружен на SD карту и запущен на апельсинке.

Далее я подключил SSD, провел тесты скорости (которые были выше), а потом стал настраивать SWAP файл. Для автоматической настройки и его дальнейшего подключения, были прописаны необходимые команды в файл /etc/fstab.

Из соображений что более старая версия Vivado будет иметь меньше фишек и выкрутасов, решил качать Vivado 2018.3 Lab Edition (Xilinx_Vivado_Lab_Lin_2018_3), специально для линукс версии, без лишних файлов для Windows.

Разумеется, я не специалист в области Linux, поэтому в вопросе команд мне активно помогала нейронка. С ее подачи я стал разворачивать полноценное (оказывается есть еще не полноценное) виртуальное окружение x86_64 на OrangePi, В конечном счете оно прошло все тесты и запускало приложения предназначенные для x86_64 архитектуры, а это значит пора запускать установочник Vivado.

Установка вроде бы запускалась, но сыпалась на разных проблемах. Одна из частых ошибок была связана с Java. Ей постоянно что-то не хватало. То архитектура не та, то файлы не найдены, то версия компонентов не та.

Все закончилось тем, что после ввода очередной команды, система больше не запустилась. В отладочном UART логи сыпались, что идет какая-то загрузка, но до стадии авторизации не доходило и рабочий стол тоже не появлялся. ВСЕ!

Попытка 2, спустя несколько недель. Запуск эмуляции QEMU и установка Vivado 2019.1

После продолжительного времени я снова вернулся к этой идее. Наличие ошибок запуска не означает полную несовместимость, нужно лишь эти ошибки решить. Возможно, я что-то делал не так и надо начать с нуля.

Этап 1. Базовая настройка системы.

Поэтому, берем SD карту на 32 Гб, скачиваем образ Orangepi3-lts_3.0.8_debian_bullseye_desktop_xfce_linux5.16.17 с официального сайта, с помощью программы SD Card Formatter форматируем карту от старого запуска. И с помощью balenaEtcher заливаем образ на флешку.

Все это делается по инструкции с официального сайта.

Для более удобного использования OrangePi, лучше всего подключиться к нему через удаленный рабочий стол (RDP). И тут есть нюанс!

По умолчанию, когда система стартовала, у нее есть два пользователя root и OrangePi.

Root есть root, мы его не трогаем (хотя в первой попытке я все делал через него). А вот OrangePi это пользователь с рабочим столом. Когда система загружается, то именно этот пользователь будет отображен на мониторе подключенным через HDMI. И если попытаться подключиться к OrangePi либо root, система просто выкинет и не даст соединиться. В первом случае это вызвано тем, что рабочий стол уже занят пользователем, во втором случае система сама защищается и не пускает к рабочему столу под root. Отсюда есть два пути, либо править этих пользователей и выдавать себе разрешение на подключение, либо просто создать нового пользователя. Вот вторым путем и идем:

//создаем нового пользователя
sudo adduser имя_пользователя
//даем права супервользователя – администратора
sudo usermod -aG sudo имя_пользователя

В процессе выполнения команд, система попросит пароль и информацию для настройки пользователя. Затем открываем Пуск и вводим «Подключение к удаленному рабочему столу», обычно на первых словах система даст нужный ярлык.

Далее в открывшемся окне, сначала разворачиваем окно чтобы было видно все параметры (1), а затем вводим локальный адрес OrangePi, и имя пользователя (2). Внимание, на этой стадии важно проверить, что у вас включена английская раскладка клавиатуры. При первом запуске вы конечно же переключитесь на нее, но при повторных стоит проверять. IP адрес можно узнать либо в роутере, либо через команду ifconfig.

Конечно же, предварительную настройку OrangePi нужно делать либо с подключением клавиатуры, мышки и монитора к самому одноплатному ПК, либо через PuTTY, подключившись по UART; конечно, еще можно подключиться по SSH к пользователю OrangePi(пароль у него такой же, как и логин).

После подключения по RDP вас встретит вот такой интерфейс:

где можно повторно ввести логин и указать пароль. После перезагрузки ПК, рабочий стол будет долго запускаться, где-то секунд 10.

За счет подключения через RDP, есть возможность копировать информацию с вашего рабочего ПК, это удобно.

Теперь идем обновлять систему, подключать SSD и swap через FSTAB, и устанавливать QEMU.

//сначала стоит проверить репозитории. Те, что стоят по-умолчанию в наших реалиях не прокатывают
sudo nano /etc/apt/sources.list
//все закоментировать и прописать эти репозитории
deb http://deb.debian.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian-security bullseye-security main contrib non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free
//обновляем систему
sudo apt update
sudo apt upgrade -y
//проверяем установку некоторых компонентов, может пригодиться
sudo apt install -y wget curl nano git

Далее переходим к подключению SSD и файла swap.

//смотрим все накопители в системе
lsblk -f

Вывод будет выглядеть примерно так:

Любым методом вычисляем в какой строке находится ваш диск. В моем случае это sda2, его легко заметить по размеру, он такой один. Из этой информации запоминаем имя диска - sda2, и значение из поля UUID, они понадобятся для файла fstab.

Продолжаем работу с диском:

//если диск уже смонтирован (например, указано значение в MOUNTPOINT),
 то его нужно размонтировать
sudo umount /dev/sda2
//форматируем диск под нужный формат ext4. У меня уже это выполнено.
sudo mkfs.ext4 /dev/sda2

Далее необходимо смонтировать диск и создать на нем файл подкачки. Так же стоит изменить папку монтирования, чисто для удобства.

//Создаем папку монтирования
sudo mkdir -p /mnt/ssd
//Монтируем диск
sudo mount /dev/sda2 /mnt/ssd
//И можно проверить монтирование. 
df -h | grep /mnt/ssd
//Создаем swap файл
sudo fallocate -l 32G /mnt/ssd/swapfile
//Устанавливаем правильные права
sudo chmod 600 /mnt/ssd/swapfile
//Создаем swap область. По сути, говорим, что этот файл будет выполнять swap функции 
sudo mkswap /mnt/ssd/swapfile
//Активируем swap
sudo swapon /mnt/ssd/swapfile
//Проверяем
swapon --show
free -h

После проверки получим примерно такую информацию:

В первом случае вызываем информацию о swap состоянии, и видим там файл на 32ГБ, во втором случае в строке Swp видим наш объем в 32ГБ.

Далее нужно указать системе чтобы она автоматически подключала USB SSD и подцепляла swap файл. Это нужно сделать на ранних этапах загрузки, для этого используем файл /etc/fstab. Для этого:

//Открываем fstab
sudo nano /etc/fstab
//Добавляем строки. Первая монтирует диск, вторая подключает swap файл:
UUID=ваш-uuid-диска /mnt/ssd ext4 defaults,noatime,user,exec 0 2
/mnt/ssd/swapfile none swap sw 0 0
//Напоминаю: чтобы получить UUID диска можно ввести следующую команду:
sudo blkid /dev/sda2
//Проверьте конфигурацию. Все переподключаем
sudo mount -a

На этой стадии нужно сделать перерыв, налить себе чаю, и перезагрузить устройство (не выдернув кабель питания, а нажав кнопку перезагрузки). После загрузки системы, повторно проверяем, что swap файл подцепился командами: swapon –show  или free -h.

Этап 2. Установка QEMU и Java.

Установка выполняется банальной командой:

//устанавливается несколько компонентов
sudo apt install -y qemu-user-static binfmt-support

Затем необходимо проверить установку и регистрацию утилит в системе:

//Проверяем версию QEMU
qemu-x86_64-static --version
//Проверяем регистрацию binfmt
ls -l /proc/sys/fs/binfmt_misc/ | grep qemu

В результате должны увидеть что-то подобное, главное, что не пустой вывод:

Сама Vivado активно использует Java, поэтому ее тоже необходимо установить:

//Устанавливаем OpenJDK 8 для amd64 (эмуляция x86_64)
sudo apt install -y openjdk-8-jre-headless:amd64
//Устанавливаем дополнительные библиотеки для Vivado
sudo apt install -y libtinfo6:amd64 libncurses5:amd64 libncursesw5:amd64
//Создаем ссылку для libtinfo (если требуется, а как понять – не знаю, поэтому создаем) 
sudo ln -sf /usr/lib/x86_64-linux-gnu/libtinfo.so.6 /usr/lib/x86_64-linux-gnu/libtinfo.so.5
//Обновляем кэш библиотек
sudo ldconfig

Этап 3. Установка Vivado

По своей ошибке я стал устанавливать Vivado 2018.3, ту версию что пытался установить ранее. Но ошибка была не в том, что я повторил старые не верные действия, а в том, что я не проверил эту версию. И только после нескольких часов установки я осознал, что Vivado Lab Edition не умеет синтезировать, только прошивать ПЛИС. И когда я попробовал другую сборку Vivado 2018.3 WebPACK, она оказалось битой. Банально некий файл librdi_xdm.so оказался пустым и при запуске Vivado ругалась и закрывалась. Зато, благодаря легковесным версиям сборки, сам запуск установочника проходил за считаные минуты (минут 5 открывалось окно).

В общем, выбрал я версию Vivado 2019.1, проверил ее установку на нормальном ПК с Ubuntu, увидел, что она заработала корректно и пошел запускать установку на OrangePi.

Для этого я на вторую флешку распаковал в отдельную папку все то, что было в образе iso установочника Vivado, таким образом я решил убрать прослойку монтирования iso-образов в систему Linux (возможно это бессмысленно, но мне так проще).

И далее уже с OrangePi продолжаем работу (конечно же подключив флешку с Vivado).

Vivado устанавливается запуском скрипта xsetup, в котором она делает проверку на архитектуру системы, если эту проверку не убрать, то даже при существующей эмуляции x86_64 Vivado завершит выполнение скрипта с ошибкой, что система не та. Поэтому открываем файл xsetup любым подходящим редактором и комментируем некоторые строки:

Примерно с 15 строки начинается блок проверки архитектуры, его нужно закомментировать, прописав вначале строки знак решётки#. А после него добавить объявление переменной lnx32LibDir="${workingDir}/lib/lnx32.o", если этого не сделать, то Vivado тоже не запустится.

Теперь сохраняем файл xsetup, делаем его исполняемым и запускаем xsetup:

//Делаем файл исполняемым, если нужно.
chmod +x xsetup
//Добавляем необходимые переменные окружения. Ограничиваем работу Java, чтобы не запросила лишнего.
export JAVA_TOOL_OPTIONS="-Xint -Xms2g -Xmx4g -XX:+UseSerialGC -Djava.compiler=NONE"
export LIBGL_ALWAYS_SOFTWARE=1
//запускаем установку
./xsetup

На скриншоте видим терминал с запуском xsetup, а еще видим терминал с htop, в котором ярко видно загруженность одного ядра. К сожалению, на этом этапе загрузить больше ядер не получится. Поэтому просто ждем, когда скрипт соберет в себе всю информацию о том, что он готов установить и подготовит окно установочника. Это занимает порядка 2,5 часов)))

Чтобы оценить «пациента» что он жив, а не мертв, достаточно заметить, что в htop будет периодически меняться загруженное ядро.

Фото на память

И вот, спустя 2 часа и 45 минут на экране появляется окно установки Vivado. Разумеется, я выбрал версию WebPACK, и в настройках выбрал только ту ПЛИС которая у меня имеется.

Можно обратить внимание что swap почти не используется, из ОЗУ потребляется 1.55ГБ. Также показываю окно с той конфигурацией, которую я оставил себе (кстати у меня Artix-7 100t на плате Nexys-A7). Конечно, можно было отключить SDK и DocNav, но я решил оставить.

Сама установка в отличие от запуска проходит достаточно быстро, примерно 1 час 20 минут.

Этап 4. Запуск Vivado

Запуск самой Vivado делается аналогично, как и ее установка. Переходим в папку bin, прописываем параметры окружения и запускаем скрипт Vivado.

//переходим в папку с Vivado в папку bin, ваш путь может отличаться.
cd /mnt/ssd/Xilinx/Vivado/2019.1/bin 
//указываем значения для окружения
export JAVA_TOOL_OPTIONS="-Xint -Xms2g -Xmx4g -XX:+UseSerialGC -Djava.compiler=NONE"
export LIBGL_ALWAYS_SOFTWARE=1
//запускаем Vivado
./vivado

Запуск самой Vivado занимает минут 15. А вот уже работа в ней, становится достаточно долгой. Хочется еще отметить параметр -Xmx4g, он указывает максимальный объём ОЗУ доступный Java. На данный момент 4 Гб, но его можно увеличить увеличить не получится, запуск вылетает и ругается на сегментирование памяти.

Вот так выглядит запущенная Vivado на OrangePi, в терминале запуска есть ключевые записи, а в htop видно потребление ресурсов:

Демонстрация работы Vivado.

На видео ниже я запускаю Vivado, создаю проект и синтезирую на нем код для моргания светодиодом. Все это я буду делать исключительно в среде Vivado, и пытаться пользоваться ей как на обычном ПК.  

Получилось открыть синтез и имплемент

Вполне реально дождаться открытия синтеза и имплемента, и даже (если не торопиться) можно посмотреть, как это все дело собралось.

Прошивка BitStream на ПЛИС.

Прошить плату из Vivado не получится, так как программатор не виден средой. Один из вариантов — это запустить hw_server на другом ПК, и по сети достучаться до программатора.

Но как я сказал в начале статьи, плату я прошил с OrangePi.

И так, подключаем плату к одноплатному ПК, и вводим в терминал lsusb, эта команда выдаст информацию о подключенных устройствах по USB шине, получим примерно такое:

В списке видим два устройства, первое это A-DATA, это USB SSD который используется для swap файла и установки Vivado, а второе устройство FT2232C/D/H Dual UART/FIFO IC – это и есть наш программатор на плате. В режиме не полной эмуляции x86_64 нет эмуляции интерфейсов USB, и Vivado в упор не видит это устройство, поэтому загрузить прошивку из Vivado не получится. А получится это сделать другими программами OpenOCD + Telnet.

//устанавливаем openocd
sudo apt install -y openocd
//так же устанавливаем telnet, если его нет
sudo apt install -y telnet
//затем создаем файл с конфигурацией, сразу откроется файл для редактирования
sudo nano /etc/openocd/digilent_hs2.cfg
//содержимое файла
# Digilent JTAG-HS2/HS3 configuration (FT2232C)
interface ftdi
ftdi_device_desc "Digilent USB Device"
ftdi_vid_pid 0x0403 0x6010
ftdi_channel 0
ftdi_layout_init 0x0088 0x008b
reset_config none
adapter_khz 10000
# Xilinx Artix-7 (Series 7)
source [find cpld/xilinx-xc7.cfg]

Обратите внимание на ftdi_vid_pid, параметры в этой команде нужно указывать такие? какие получены при lsusb для устройства.

На данный момент у нас есть две утилиты и конфигурационный файл.

Первым этапом запускаем OpenOCD командой:

//указываем путь до файла с конфигурацией
sudo openocd -f /etc/openocd/digilent_hs2.cfg

Далее подключаемся к этому серверу через telnet (в другом окне терминала) и шьем прошивку в плату:

//подключение через telnet
telnet localhost 4444
//подключение к программатору и прошивка. Команды выполнять по очереди
 init
 xc7_program xc7.tap
 pld load 0 /mnt/ssd/vivado_prj/first_tst/first_tst.runs/impl_1/blink_led.bit
 exit

Результат процесса прошивки отображен ниже на скриншоте (а также есть в видео выше). В момент подключения по telnet в терминале с OpenOCD появляется новое сообщение. В команде pld указываем полный путь до *.bit файла, в качестве примера открыт проводник в нижнем левом углу.

Заключение

Статья получилась своеобразным туториалом, но я по новой не проверял весь этот путь, поэтому что-то мог упустить. В первую очередь статья несет экспериментальный характер.

Эта статья яркий пример того, как помогают нам нейронки. Благодаря ей, я смог успешно реализовать эту идею, она оказалась хорошим инструментом, чтобы разобраться по какому пути идти.