Как установить vivado в linux

Обновлено: 02.07.2024

Разработка под ПЛИС и СНК отличается монструозностью IDE и проектов в них. Это касается как сложности и нестабильности самого процесса, так и иерархии файлов и их размера.

Например, проект Импалы, собираемый в IDE Xilinx ISE, на диске занимает около 5 Гб. При этом большая часть файлов обновляется при любой манипуляции в IDE, часть из файлов - бинарные. Одним словом - ад для систем контроля версий.

К счастью, в Vivado разработчики сделали работу над ошибками.

Иметь возможность откатиться к старой версии дизайна.
Разворачивать и собирать дизайн на любой машине на основе одного-двух репозиториев.
Делать частые коммиты без страха за разрастающийся размер репозитория, т.е. коммититься должны файлы малого размера, рукописные, а не сгенерированные программой.
Легко переключаться между ветками.

Особенности наших проектов:

Используется Zynq, т.е. помимо PL части нужна и PS.
В разных дизайнах используются одни и те же модули (оформленные в виде HDL, а не IP блоков).
Используются родные Xilinx'овские IP модули (сериалайзеры, буферы, шины, сбросы и т.п.).

О Project и NonProject workflow

Разработчики Vivado выделяют два подхода к ведению проекта: project и non-project.

В первом случае мы активно пользуемся GUI, имеем файл проекта .xpr. Во втором - делаем упор на сборку на основе tcl-скриптов, т.е. реализуем unix-way.

По причине ограниченности наших навыков работы с Vivado, я пока решил остановиться на первом варианте - project workflow, т.е. предполагающем тесное взаимодействие с GUI.

Какие файлы бывают в дизайне Vivado?

Типы файлов, которые Vivado относит к source'м:

HDL and netlist files: Verilog (.v), SystemVerilog (.sv), VHDL (.vhd), and EDIF (.edf)
C based source files (.c)
Tcl files, run scripts, and init.tcl (.tcl)
Logical and Physical Constraints (.xdc)
IP core files (.xci)
IP core container (.xcix)
IP integrator block design files (.bd)
Design Checkpoint files (.dcp)
System Generator subsystems (.sgp)
Side files for use by related tools (например, “do”-файлы для симулятора)
Block Memory Map files (.bmm, .mmi)
Executable and Linkable Format files (.elf)
Coefficient files (.coe)

Что хранить в Git'е?

Наша точка зрения

Что "рукописного" мы вносим в проект и хотели бы сохранять в репозитории?

Точка зрения Xilinx

Xilinx предлагает два варианта в зависимости от того, какой набор файлов будет храниться в системе контроля версий:

держать в репозитории рекомендуемый набор исходников,
держать в репозитории минимальный набор исходников.

Минимальный набор исходников позволяет гарантированно восстановить весь проект, если используется та же версия Vivado. Если версии Vivado отличаются, то гарантий нет.

Scripts
- Run scripts used to compile the design including any pre and post scripts used when launching runs
- Project recreation scripts created with the write_project_tcl command
- Project .xpr files can be used to recreate a design project
- All RTL based source files including .include files
- Simulation test benches and stimulus files
- All XDC constraint files and Tcl commands used as constraints
- The .xci files associated for each IP
- If using IP core containers, the IP core container .xcix file
- The BD recreation Tcl command created using the write_bd_tcl command
- The .bd file used for each BD
- The UI directory for graphics locations for blocks and comments
Рекомендуемый набор упрощает переход между разными версиями Vivado и, как утверждается, уменьшает время компиляции.
- Scripts
  - Run scripts used to compile the design including any pre and post scripts used when launching runs
  - If modifications were made to the Vivado init.tcl file, it must also be checked in
  - Project recreation scripts created with the write_project_tcl command
  - Project .xpr files can be used to recreate a design project
  - All RTL-based source files including .include files
  - Simulation test benches and stimulus files
  - All XDC constraint files and Tcl commands used as constraints
  - All IP directories and output product files with names intact
  - If using IP core containers, the IP .xcix file with all third-party simulation and synthesis files in the ip_user_files and ip_static_files subdirectories
  - Any .coe, .csv, .bmm, and .elf files that are used
  - The entire block design location with all of the IP subdirectories, files, and names intact
  - All C sources files
  - Packaged HLS IP for use in Vivado synthesis
  - Scripts
  - The entire System Generator created module directory with all of the subdirectories, files, and names intact
  - All .bit files needed to program the device
  - The .ltx file containing tool defaults and custom user settings
  - The Handoff Design File (.hdf extension) contains all the information required by Xilinx SDK to create the corresponding software project for your design. The HDF file is created when you export your design either through the write_hwdef or write_sysdef Tcl command or the File > Export > Export Hardware command.
  - Any design related docs, specs, reports, etc.
  Мы будем использовать промежуточный вариант.
  
  Разделение песочницы и исходных файлов
  
  Шаг 1 для желающих собрать bit-файл: получаем исходные файлы
  
  Настало время сделать первый практический шаг по сборке нового bit-ника - получить описанные выше исходники.
  
  Заводим каталог под всея проект:
  
  / $ mkdir Oryx
  korogodin @ Diod:
  
  Мы готовы клонировать git-репозиторий. Для этого потребуется аккаунт и права доступа к проекту src:
  
  Среди прочего, мы получили желанные исходные файлы прошивки PL-части нашего СНК. Они расположены в каталоге fpga:
  
  / $ cd src / fpga
  korogodin @ Diod:
  
  Но если присмотреться, то можно заметить, что каталоги подмодулей всё ещё пусты. Получаем их ревизии, соответствующие выбранной ветке в склонированном репозитории:
  
  / Oryx / src / fpga$ git submodule update --init
  korogodin @ Diod:
  
  Ура, у нас есть все нужные для сборки bit-ника исходные файлы!
  
  Скрипт восстановления песочницы
  
  Т.к. мы остановились на project workflow, то по исходникам из репозитория нужно восстановить всю песочницу проекта. Делает это специальный tcl-скрипт регенерации проекта, который для дизайна Oryx SomZ назван prj_somz.tcl:
  
  variable script_file
  set script_file "prj_$prj_name.tcl"
  
  puts "INFO: Project created:somz"
  
  puts "INFO: Create HW Platform and BSP"
  exec xsdk -batch - eval "sdk set_workspace [file normalize " $proj_dir / $prj_name .sdk "]; sdk create_hw_project -name $hw_platform_name -hwspec [file normalize " $proj_dir / $prj_name .sdk/ $topmodule_name .hdf "]; sdk create_bsp_project -name $facq_bsp_name -hwproject $hw_platform_name -proc $facq_proc_name -os standalone; exec xsdk -eclipseargs -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import [file normalize " $origin_dir /sub/acquisition/sdk/ $facq_prj_name / "] -data [file normalize " $proj_dir / $prj_name .sdk "] -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole; exit"
  
  puts "INFO: Project is regenerated"
  
  Что есть интересного в этом скрипте:
  - Название проекта и относительное расположение песочницы
  - Указание платформы
  - Указание топового модуля
  - Настройка симулятора
  - Подключение к проекту различных наборов файлов - Verilog-исходников, TB, IP, .xdc и т.д.
  - Настройки синтеза (с указанием кристалла!)
  - Настройки имплементации (с указанием кристалла!)
  Кроме того, в конец этого скрипта я внес перекомпиляцию Block Design при первом запуске, создание HW Platform, BSP для SDK и подключение проекта прошивки для Microblaze (используется блоком поиска).
  
  Новый скрипт восстановления из существующего проекта можно получить через GUI Vivado ( File->Write Project Tcl ) или через TCL-консоль командой write_project_tcl :
  
  Но следует понимать, что при этом Vivado перетрет все внесенные вручную изменения. Думаю, после настройки проекта автоматическое создание этого скрипта нам уже не потребуется.
  
  Шаг 2 для желающих собрать bit-файл: восстанавливаем песочницу
  
  Скрипт регенерации песочницы проще всего запустить непосредственно через Vivado. При этом скрипт (а так же block design, IP-ядра и т.д.) подходит только к определенной версии среды, поэтому первым делом следует узнать требуемую версию в заголовке файла:
  
  Как следует из заголовка, необходимо использовать версию 2015.3.
  
  Внимание. Скрипт необходимо запускать из директории, в которой расположен файл регенерации проекта prj_somz.tcl!
  
  Запуск скрипта через командную строку
  
  Через командую строку в Linux (обращаю внимание, что я нахожусь в каталоге
  
  /Oryx/src/fpga$ / opt / Xilinx / Vivado / 2015.3 / bin / vivado -source prj_somz.tcl
  
  Запустится Vivado, начнется выполнения скрипта.
  
  Запуск скрипта через Vivado
  
  Второй вариант (альтернативный) - запустить скрипт из Vivado. Для этого запускаем Vivado нужной версии. В Tcl Console переходим в каталог с prj_somz.tcl и запускаем его с помощью команды source:
  
  / Oryx / src / fpga
  source prj_somz.tcl
  
  Результат исполнения скрипта
  
  Скрипт создает песочницу и файл проекта. Добавляет к проекту внешние исходные файлы. Настраивает правила синтеза и имплементации. Подключается уже собранный Elf-файл для прошивки MicroBlaze (лежит в репозитории в acquisition/bin, скопированный туда руками ранее).
  
  После этого перекомпилируется Block Design. Для проекта прошивки MicroBlaze в песочнице создается somz.sdk, в него добавляется HW Platform и собирается BSP (microblaze_0, standalone). К проекту подключаются исходники прошивки MicroBlaze из сабмодуля acquisition.
  
  Шаг 3 для желающих собрать bit-файл: Generate bitstream со старым elf-файлом для Microblaze
  
  По завершению выполнения скрипта prj_somz.tcl мы имеем готовую к работе настроенную среду:
  
  Если не требуется вносить изменения в программу MicroBlaze'а, используемого в блоке поиска, то можно воспользоваться готовым elf-файлом из acquisition/bin. Настраиваем число каналов коррелятора, размер ядра блока поиска, тип корреляторов и т.п. в global_param.v и запускам Generate Bitstream слева снизу в Vivado. Процесс пошел!
  
  Если повезет, то через несколько минут/часов/дней мы получим bit-файл, готовый для прошивки в Oryx (impl_2 - набор правил имплементации, описан в prj_somz.tcl):
  
  Шаг 4 для желающих собрать bit-файл: Generate bitstream с новым elf-файлом для Microblaze
  
  Если всё-таки нужны правки в прошивке MicroBlaze'а, то придется открывать SDK. Для этого в Vivado следует нажать File->Launch SDK . Открывается XSDK.
  
  Проект прошивки (mcs_facq) изменяется и компилируется в XSDK. Результат лежит в каталоге Debug внутри сабмодуля:
  
  / Oryx / src / fpga / sub / acquisition / sdk / mcs_facq / Debug$ ls mcs_facq.elf
  mcs_facq.elf
  
  Если он нас удовлетворяет, то заменяем им файл в каталоге acquisition/bin и собираем bit-файл, как указано на Шаге 3.
  
  Bonus: Автоматическое подключение проекта прошивки MicroBlaze в SDK
  
  Проект прошивки, BSP, HW Platform подключается автоматически скриптом prj_somz.tcl при регенерации проекта. Для этого в нем используется следующий хак:
  exec xsdk -batch - eval "sdk set_workspace [file normalize " $proj_dir / $prj_name .sdk "]; sdk create_hw_project -name $hw_platform_name -hwspec [file normalize " $proj_dir / $prj_name .sdk/ $topmodule_name .hdf "]; sdk create_bsp_project -name $facq_bsp_name -hwproject $hw_platform_name -proc $facq_proc_name -os standalone; exec xsdk -eclipseargs -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import [file normalize " $origin_dir /sub/acquisition/sdk/ $facq_prj_name / "] -data [file normalize " $proj_dir / $prj_name .sdk "] -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole; exit"
  Bonus: Файл .gitignore
  
  /Oryx/src/fpga расположен свой файл .gitignore :
  
  Как видно из файла, каталог с песочницей (с проектом) обязательно должен начинаться с prj.
  
  В сабмодуле acquisition/sdk также используется свой файл .gitignore , скрывающий от git'а каталоги Debug и Release.
  
  Bonus: О изменениях в файлах проекта приложения в SDK
  
  Настройки проекта приложения для MicroBlaze находятся в файле acquisition/sdk/mcs_facq/.cproject . Чтобы проект приложения легко подключался непосредственно из сабмодуля в .cproject изменены относительные пути до bsp на
  
  Bonus: О хранении Block Design в системе контроля версий
  
  Информация к размышлению. В итоге выбран вариант первый - с хранением BD файла в репозитории.
  
  Вариант с хранением .BD файла в репозитории
  
  Документ XAPP1165 опускает тему сохранения Block Desing'ов в git'е. Vivado же предполагает активное использование IP-интегратора. Если в проекте присутствует block design, то в скрипт восстановления добавляются строки вида:
  
  Из этих строк можно сделать вывод, что для восстановления Block Diagram достаточно самого .bd файла. Файл .bd является текстовым XML документом, размер несколько Кб, т.е. для хранения в СКВ не является проблемой.
  
  Я попробовал вывести design_1.bd за пределы песочницы, в каталог ./bd/, соответствующим образом поправил скрипт восстановления проекта. Скрипт успешно восстановил после этого проект, но при синтезе и имплементации Vivado сгенерировала множество файлов в каталоге ./bd:
  
  Какой выход в этом случае? Видимо только блокировать эти файлы через .gitignore, что неприятно.
  
  Какое преимущество? Не нужны ручные правки скрипта восстановления проекта.
  
  UPDATE: Замечен ещё недостаток. Если в проекте лежит elf'ник для microblaz'а, то в BD файле путь к нему заменяется полным. В итоге BD файл будет постоянно обновляться при отсутствии реальных изменений.
  
  Вариант с хранением скрипта восстановления .BD файла в репозитории
  
  Xilinx предлагает хранить не bd файл, а tcl-скрипт, его регенерирующий. Создать скрипт можно через File->Export при открытом Block Design в IP Integrator'е. Минус этого метода - наличие ещё одного скрипта, который нужно поддерживать в актуальном состоянии вручную.
  
  Конструкция комплект Vivado представляет собой интегрированную среду проектирования FPGA выданной Vendi 2012.
  
  2. Введите интерфейс Accept лицензионные соглашения, все выберите, я согласен, нажмите Далее, чтобы ввести выберите Издание для установки интерфейса.
  
  3. Выберите второй Vivado Design Edition и нажмите кнопку Далее, чтобы войти в интерфейс Vivado Design Edition.
  
  4. Набор комплектов разработки программного обеспечения в инструментах проектирования, затем вводит интерфейс Directory Directory.
  
  5. Выберите каталог установки Vivado, здесь я выбираю D: каталог \ Xilinx \ Vivado, Next Введите Сводка установки интерфейса.
  
  6. Нажмите Установить, чтобы ввести интерфейс установки прогресса установки.
  
  7. Дождитесь завершения установки.
  
  8. Диалоговое окно Установка Xilinx программного обеспечения появится после того, как установка будет завершена, нажмите кнопку OK для завершения, и он войдет в интерфейс диспетчера лицензий Vivado.
  
  9. Выберите вариант лицензии нагрузки по лицензии ПОЛУЧИТЬ, нажмите на копию лицензии на право.
  
  10. Диалоговое окно «Выбор файла лицензии» появится и найдет файл лицензии.
  
  11. LiCense File Load завершена, программное обеспечение Vivado также установлено.
  
  В данной статье будет описано каким образом подготовить все необходимые файлы для запуска Linux с FPGA фирмы Xilinx, а именно отладочной платы Zybo. С последующей записью необходимых файлов на QSPI и запуском готовой системы.
  
  Разработка FPGA части будет производиться в Vivado 2019.1, компиляция необходимых файлов для Linux будет выполнена в виртуальной машине Oracle VM VirtualBox, на которой установлена Ubuntu.
  
  Компиляция будет происходить без использования PetaLinux, как утверждают Xilinx - это платформа, которая содержит всё необходимое для запуска Linux на FPGA и облегчает внесение изменений. В данном руководстве всё будет собираться ручным образом, для того чтобы ближе взглянуть на работу встроенных систем.
  
  Процесс загрузки системы описывается следующей схемой, взятой из UG1165 и UG873:
  
  Рис.1 структурная схема загрузки системы
  
  Boot ROM - выполнение инструкций содержащихся в специально отведённой памяти FPGA, они осуществляют изначальную инициализацию, выбирают носитель в котором будет произведён поиск FSBL и запускают его. Изменить этот код нельзя, остальные файлы необходимо подготовить.
  Первым шагом следует создать проект в Vivado. Для проверки работоспособности платы и корректных настроек можно использовать готовый проект от Xilinx расположенный на github, он реализован на версии 2017.4. Но в данном руководстве используется версия 2019.1 и проект создаётся с нуля. Тем не менее там можно посмотреть правильные настройки для DDR и QSPI.
  
  В отладочной плате Zybo используется XC7Z010CLG400С-1 его и следует выбрать при создании проекта. Xilinx рекомендует использовать готовые библиотеки для своих отладочных плат, при создании проекта, вместо конкретной микросхемы. Как они говорят это облегчает подключение различных интерфейсов, подробное описание здесь. Но для того чтобы не привязываться к конкретным библиотекам выберем отдельно необходимую микросхему.
  
  Рис.2 Выбор микросхемы
  
  Далее нужно создать Block Design. В левом меню, под "IP Integrator", нажимаем "Create Block Design", в создавшемся Block Design добавляем новое IP ядро "Zynq7 processing system", далее жмём в верхней части экрана "Run Block Automation" в появившемся окне нажимаем ok. После выполнения данных действий, процессор должен быть корректно подключен к своим основным выводам.
  После этого нужно соединить выводы FCLK_CLK0 и M_AXI_GP0_ACLK, таким образом подаётся частота на AXI интерфейс, он использоваться не будет, но без этого нельзя скомпилировать проект.
  
  Рис.3 IP ядро процессора
  
  В данном руководстве не будет использоваться FPGA часть устройства, необходимо подключить лишь основные компоненты, большая часть из которых соединились автоматически. Но следует корректно настроить параметры тактовой частоты системы, QSPI и RAM память. Для простоты и уменьшения возможности ошибок желательно использовать готовый проект от Xilinx расположенный на github, но тем не менее далее будут приведены изменения которые необходимо сделать вручную при создании нового проекта.
  
  Подключение и используемые компоненты можно посмотреть на схеме, которая находится в открытом доступе.
  
  Двойным щелчком можно открыть настройки IP ядра процессора, для начала в разделе "Clock configuration" выставим корректное значение тактовой частоты процессора. Тактовые сигналы подаются на вывод PS_CLK_500, его и к чему он подсоединяется можно найти на странице 9:
  
  Рис.4 Генератор тактовой частоты процессора
  
  Как видно на процессор подаются тактовые сигналы с частотой 50 МГц.
  Выставим это в Vivado:
  
  Рис.5 Настройка тактовой частоты процессора
  
  В качестве RAM используется 2 блока DDR3 памяти "MT41J128M16JT-125" (стр 12):
  
  Рис.6 RAM память
  
  В разделе "DDR Configuration" следует указать используемую память. Но её не окажется среди доступных, её там нет из-за того, что это устаревшая версия. Новая версия ничем не отличается от предыдущей, но в дополнение может работать при низком напряжении, её код "MT41K128M16JT-125", отличается лишь одной буквой. Её и следует выбрать.
  
  Рис.7 Настройка RAM
  
  Также желательно выставить задержку распространения сигнала, значения из тестового проекта представлены ниже, но начиная с Vivado 2018.1 при сохранении введённых настроек компилятор выдаст предупреждение об отрицательных значениях задержек, подробное описание проблемы находится здесь. Чтобы убрать ошибки нужно отрицательные значения изменить на 0.
  
  Рис.8 Настройка задержек на дорожках печатной платы
  
  Далее следует перейти в "MIO Configuration" изменить "Bank 1 I/O Voltage" на "LVCMOS 1.8V" и в том же окне под "Memory interfaces" поставить галочку напротив "Quad SPI Flash", галочку напротив "Feedback CLK", поменять скорость на fast для всех выводов и отключить "pullup":
  
  Рис.9 Настройка интерфейсов
  
  U-boot сперва настраивает периферию, по умолчанию он будет инициализировать Ethernet, SDIO, из-за этого их нужно подключить, иначе U-boot зависнет. Отключить их можно в исходниках U-boot /configs/zynq_zybo_defconfig. Для конфигурации в Vivado параметры следующие:
  
  Рис.10 Настройка интерфейсов (2)
  
  Рис.11 Настройка интерфейсов (3)
  
  Также для того чтобы общаться с Linux, следует подключить UART:
  
  Рис.12 Настройка интерфейсов (3)
  
  Далее нужно создать HDL wrapper - во вкладке Sources, правой кнопкой на "design_1" и нажать "Create HDL wrapper. " и оставить вариант по умолчанию с автоматическим созданием.
  
  После этого нужно скомпилировать проект. Затем экспортировать его в SDK, нажав File -> Export -> Hardware. В появившемся окне нужно поставить галочку рядом с "Include bitstream" и нажать ок.
  
  Последним шагом следует запустить SDK через File -> Launch SDK. В дальнейшем в Vivado вводить изменения больше не потребуется.
  
  Внутри SDK, нужно создать FSBL. Он установит правильные настройки частоты и DDR вместе с QSPI. Также загрузит все файлы в RAM. Дополнительная информация: Видео от Xilinx про FSBL. Xilinx wiki FSBL, документация TRM UG585, UG821. Для этого следует создать новый проект File -> New -> Application project.
  
  Рис.13 Создание нового проекта
  
  В появившемся окне ввести имя проекта, нажать Next и выбрать "Zynq FSBL".
  
  Рис.14 Выбор FSBL
  
  FSBL позволяет запустить либо baremetal аппликацию либо сторонний загрузчик который запустит полноценную ОС, в нашем случае используется U-Boot для запуска Linux.
  
  Далее большая часть работы будет происходить в Linux. Также нужно будет переносить файлы между двумя ОС, как это делать в Oracle VM описано здесь.
  
  Если ты хочешь превратить код в микросхему, используя FPGA, то эта статья поможет тебе освоиться со всеми инструментами. Мы создадим простейший бинарный счетчик, способный считать вниз и вверх. Исходный код на языке Verilog мы промоделируем и синтезируем в среде разработки Xilinx Vivado. Заодно познакомимся с процессом разработки прошивки, а результат можно будет проверить на отладочной плате.
  
  Для примера я возьму простую и доступную Zybo board, но все будет работать на любой современной плате Xilinx, которая поддерживает Vivado. Если понадобится поменять файл ограничений, напиши мне, я смогу помочь.
  
  Стоит сказать о требованиях к операционной системе. Я работаю в Ubuntu 16.04, но подойдут и Windows 7 или 10, CentOS 6 и 7 или SUSE последних версий.
  
  Устанавливаем Vivado
  
  Первым делом скачивай Vivado Design Suite — HLx Editions — 2018.2 Full Product Installation для своей ОС отсюда (на выбор варианты для Linux и для Windows).
  
  Перед установкой следует зарегистрироваться на сайте.
  
  Для ознакомительных целей я рекомендую установить бесплатную версию Vivado — WEB Pack, она по набору функций ничем не отличается от платной версии, но имеет ограничение на размер дизайна. Это значит, что счетчик в ней можно спроектировать, а что-то посложнее, что можно было бы продать, — вряд ли.
  
  Программа установки Vivado 2018.2
  
  В конце установки откроется Vivado License Manager, также его можно открыть и из Vivado — через вкладку Help в главном меню. Сюда нам нужно подсунуть файл лицензии. Давай создадим ее.
  
  Скрин Vivado License Manager на данном этапе
  
  Теперь Vivado установлена, и нам нужно убедиться, что она корректно запускается.
  
  Открываем терминал в Linux и пишем:
  
  где XILINX_INSTALL_PATH — место установки Vivado. Теперь для запуска достаточно написать vivado .
  
  Также надо установить драйверы кабеля USB для загрузки прошивки. В Windows для этого просто ставим галочку Install Cable Drivers во время установки. В Linux следует вернуться в терминал и набрать следующее:
  
  Теперь ставим драйверы для платы Zybo:
  
  Запускаем пример и моделируем схему
  
  Мы спроектируем четырехбитный бинарный счетчик с задаваемым направлением счета и выводом значения на светодиоды. Счетчик будет синхронным: работать он будет на одной тактовой частоте. При работе в железе счетчик станет изменять свое значение не каждый период тактовой частоты, а один раз в секунду, иначе мы не увидим моргание (при частоте 125 МГц оно для глаза сольется в ровный свет).
  
  После загрузки проекта в FPGA он будет работать так: каждую секунду четыре светодиода переключаются в соответствии с бинарным представлением значения счетчика. Помимо светодиодов, на плате есть еще кнопки и тумблеры. При нажатии на одну кнопку счетчик сбрасывается в ноль. Один из тумблеров разрешает счет, второй тумблер — задает направление счета.
  
  Чтобы получить исходный код и запустить проект в Linux, нам нужно ввести такие команды:
  
  В Windows в месте выполнения скрипта create_project.sh надо открыть специальное терминальное окно из меню «Пуск» и из папки, созданной во время установки Vivado, перейти в директорию rtl_examples/counter_sv/vivado , где выполнить команду из файла create_project.sh .
  
  В терминале открывается Vivado, создает проект, добавляет в него исходные файлы. Далее открывается Vivado TCL shell, здесь вводим команду start_gui , чтобы перейти в режим GUI. В окне Flow Navigator жмем Simulation → Run Simulation → Run Behavioral Simulation и видим окно вейвформ сигналов.
  
  Вейвформы сигналов при моделировании
  
  В этом окне отображаются зависимости от времени логических сигналов внутри нашей схемы счетчика. Мы видим тактовый сигнал clk , сигнал сброса reset , сигнал разрешения работы enable , сигнал выбора направления счета dir , сигнал cnt_en , который определяет частоту переключения битов счетчика, и, наконец, значение счетчика, выведенное на четыре светодиода.
  
  Самое время посмотреть на исходные файлы! Закрываем симуляцию и смотрим в окно Sources.
  
  Исходные файлы проекта
  
  В разделе Design Sources лежат исходные файлы RTL на языке System Verilog: counter.sv и counter_top.sv . В каждом определено по одноименному модулю, причем, как видно, модуль counter находится внутри модуля counter_top , что определяет иерархию модулей проекта.
  
  В разделе Constraints находятся файлы ограничений XDC (Xilinx Design Constraints). Как уже упоминалось, в них определяются ножки микросхемы, к которым должны подключаться порты ввода-вывода верхнего уровня RTL (top level) и период тактового сигнала.
  
  В разделе Simulation Sources, помимо наших файлов RTL, мы видим еще один уровень иерархии — самый верхний. Это так называемый test bench (tb) — виртуальный стенд, куда мы поместили модуль counter_top . Надо обратить внимание, что модуль counter_tb не имеет портов ввода-вывода: входные сигналы для нашей схемы назначаются непосредственно средствами языка System Verilog.
  
  Посмотрим на код counter.sv .
  
  Продолжение доступно только подписчикам
  
  Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.
  
  Подпишись на «Хакер» по выгодной цене!
  
  Читайте также: