本文持续更新中...
另外因为最近在做的项目有对 Zynq 的应用需求,再加上我对这个结合了 多核 Arm+FPGA 的 Soc 有着浓厚的兴趣,因此准备开启一个专题,为自己记录备忘的同时为其他同学提供参考,欢迎关注。
本文主要从实际工程开发入手,从多个细节角度记录 Xilinx 在淘汰基于 Eclipse/Java 的 Vitis Classic 后推出的基于 Eclipse Theia 的全新 IDE 的开发流程。
基本概念
Vitis 有几个关键地概念需要了解,以便于对整个开发流程有一个深入的认识。

- Platform(平台)
- 目标平台(或称平台)是由硬件组件(XSA)和软件组件(域/BSP、FSBL 之类的启动组件等)组合而成。存储库内的平台不可编辑。工作空间内的平台可编辑,称为平台组件。
- System Project(系统工程)
- 同时运行的一个或多个 Application。若只有一个 Application 时,系统工程不是必须的。
- Domain(域)
- 域即板级支持包(BSP)或操作系统(OS),其中包含软件驱动程序集合,可在其中构建自己的应用。
- Application(应用程序)
- 即在 PS 端处理器上运行的软件,最终编译和生成二进制输出文件(ELF)。
Platform 和 Application;Vitis 将硬件平台与应用程序工程分隔开,可方便地将不同的硬件平台与应用程序工程组合而无需对各组合创建各自独立的工程,以尽可能地减少冗杂的开发流程。
从 Vivado 导出硬件并创建 Vitis 软件项目
导出硬件并创建 Platform
Extensible Vitis Platform -> File/Export Platform
不使用该选项,否则会在 Vitis/Flow 中找不到 Run/Debug 的功能。
(因为 Extensible Vitis Platform 不会自动创建包含 Run/Debug 命令的 launch.json 配置文件)
Extensible Vitis Platform (Deselected) -> File/Export Hardware
导出硬件描述文件 xsa,用于在 Vitis 中创建 Platform 时定义硬件细节使用

创建 Platform 时步骤包含 Domain 的自动创建,根据需要选择 standalone/freertos/linux 以及绑定的内核。
创建 Application
一般使用 Template 来扩展,方便项目框架的快速搭建。
注意:部分 Template 需要特殊的 3rd-party 库(例如 lwip),需要在 Domain 下的 Board Support Package 中找到并启用对应库、根据 Template 的需要配置后,Regenerate BSP 并在 Flow 中 Build Platform 后再从 Template 页面中创建 Application:

更新与切换 Platform
若在 Vivado 端对 PL 的硬件部分做过修改,需重新综合实现生成 bitstream 并导出硬件至 xsa 文件后,重新加载 xsa 文件到 Platform:

另外,Vitis 支持方便地对 Platform 进行切换。
例如你想在多个支持同一套固件地不同 Platform 间进行测试,可在 Application Component Settings 下进行 Platform 地切换。

注意:
- 给 Application 切换 Platform 时,由于没有经过从 Template 创建 Application 的流程,因此不会进行 BSP 依赖的检查,所以需要手动保证 Template 的依赖库以及配置的正确性。
- 若切换 Platform 后没有生效,可以尝试 重启 Vitis 大法(
编译
默认情况下,在 Flow 下点击 Build 进行编译时会弹出对话框确认是否在编译 Application 前自动编译 Platform BSP。建议选择手动分别编译(因为 Platform BSP 没有更改时也会 Clean build dir 然后重新进行编译,着实浪费时间)。
如果想在之后更改这项配置,可通过 ctrl+, 快捷键打开设置,找到 Vitis/Application - Platform Build Dependency:

P.S. 项目的路径名称不能过长,否则编译时 obj 文件不能正确地生成;下面是一个实际的例子:
CMake Warning in libsrc/freertos10_xilinx/src/CMakeLists.txt:
The object file directory
C:/Users/usrlibzy/Documents/Xilinx/ModSpotFlow/ModSpotFlow.vitis_test/TestHardware/ps7_cortexa9_0/freertos_ps7_cortexa9_0/bsp/libsrc/build_configs/gen_bsp/libsrc/freertos10_xilinx/src/CMakeFiles/freertos.dir/./
has 210 characters. The maximum full path to an object file is 250
characters (see CMAKE_OBJECT_PATH_MAX). Object file
Source/portable/GCC/ARM_CA9/portASM.S.obj
cannot be safely placed under this directory. The build may not work
correctly.
由于上述 obj 文件没有正确生成,在构建 BSP 时便会失败:
[ERROR] C:/Users/usrlibzy/Documents/Xilinx/ModSpotFlow/ModSpotFlow.vitis_test/TestHardware/ps7_cortexa9_0/freertos_ps7_cortexa9_0/bsp/libsrc/freertos10_xilinx/src/Source/portable/GCC/ARM_CA9/port_asm_vectors.S:144: fatal error: opening dependency file libsrc\freertos10_xilinx\src\CMakeFiles\freertos.dir\Source\portable\GCC\ARM_CA9\port_asm_vectors.S.obj.d: No such file or directory
Warning 中也给了提示,给环境变量 CMAKE_OBJECT_PATH_MAX 赋个更高的值。或者参考 这个回答 将 Windows API 的 MAX-PATH 限制设置更大一些。
不用浪费时间咯,实际测试检验上述方法根本没用(至少对 CMake.exe 是无效的)。
最终我使用系统自带的 虚拟驱动器映射 功能(subst 命令)来规避这个问题。
例如,使用下面这个命令将整个 Xilinx 工程映射至一个虚拟驱动器上:
subst W: C:\Users\usrlibzy\Documents\Xilinx\VirtualSource\

然后重新使用 Vitis 打开其中的 Workspace C:\Users\usrlibzy\Documents\Xilinx\VirtualSource\VirtualSource.vitis,现在映射到虚拟驱动器路径则是 W:\VirtualSource.vitis。
注意不要直接映射 Vitis 项目所在的文件夹,Vitis Unfied IDE 不能直接打开根目录作为 Workspace。
后续如果需要移除这个虚拟驱动器,可以使用 subst /d W: 命令实现。
程序下载与PS/PL联合调试
默认情况下,Application 配置的 launch.json 只是配置了 PS 端程序(.elf)的下载以及处理器的复位。若需要进行 PS 与 PL 的联调,可编辑该配置文件,手动添加最新硬件的 bitstream 文件,然后勾选 Program Device 即可:

配置界面的最下方贴心地提示了这个 launch 配置的运行流程。大致概括如下:
- 复位整个系统,清除 PL 端逻辑
- 使用配置的 bitstream 文件来编程 PL 端逻辑
- 加载并运行 ps7_init tcl 脚本来复位 PS 处理器
- 加载配置的 elf 文件到 PS 处理器并运行
注意检查用于初始化 ps 的 tcl 脚本应为 ps7_init.tcl;当工程中存在 IP 核时,Vitis 会选错为 IP 核中的脚本。
如果在 PL 端添加了 ILA 来观察波形,可运行上述的 launch 流程配置好 PS/PL 后,再回到 Vivado 打开 Hardware Manager/Logic Analyzer 来访问 ILA。
参考
- Xilinx 官方文档 UG1400
- How can I use ILA if I program my board with Vitis?