Vitis IDE 艰难切换--从传统 Vitis GUI 到 2024.1 统一软件界面

1. 简介

Vitis 2024.1 已经完全不支持传统界面了，新版软件提供一个更加统一和现代化的用户界面。

传统的 Vitis GUI 像是一位老朋友，我们熟悉它的每一个角落，每一个命令，就像回到自己温馨的家。新的统一软件界面却像是搬进了一个未知的新城市，尽管它充满了现代化的便利和先进的功能，但那份亲切感和熟悉度却需要时间来建立。

命令行选项的变更、菜单结构的重组、工具链的整合，每一个细节都需要重新学习。笔者不得不告别那些熟悉的命令行快捷方式，转而学习新的操作方法。

比如运行 vitis -w <workspace> 将直接进入新的界面，不在提供进入传统 SDK 的模式。

这个过程中，我们可能会感到迷茫，甚至有些挫败。

但正如所有的成长过程一样，适应是必经之路。随着时间的推移，我们将逐渐掌握新界面的奥秘，发现它带来的高效和便捷。新的统一软件界面不仅仅是一个工具的更新，它是我们作为开发者进步的象征，是我们与时俱进的证明。

据说从2023.2版本开始，Vitis统一IDE整合了多个工具，以便在Vitis、Vitis AIE编译器/仿真器和Vitis HLS中提供一致的图形用户界面。

本文将探索这种变换的一角，开启笔者适应新GUI的过程。

Vitis IDE的新特性简述如下：

• 用户界面友好：Flow Navigator助力工作流程管理，模板样本启迪新手，多任务并行执行提升效率。
• AI引擎优化：软件仿真在x86环境下加快迭代，AI引擎的流水线和微代码视图得到多核支持和筛选功能增强。
• 界面现代化：提供明亮和暗色两种主题，自定义快捷键简化操作，命令选用板更加人性化，C++语法高亮和智能提示功能。
• 灵活切换：GUI和CLI模式无缝转换，结合两者优势，配置文件实时展示，CLI构建项目，GUI用于调试和核心分析，操作记录可用于批处理。

2. 界面展示

2.1 启动

Vitis Unified 把 Vitis HLS 和 SDK 合并了。

启动 Vitis Unified IDE：

vitis -w <workspace>

workspace 是一个文件夹，用于保存设计的各种组件和项目。

2.2 Flow Navigator

传统 Vitis IDE 启动每个 Flow，都会弹出配置对话框。新 Vitis Unified IDE，全部都在 Vitis Component下的 Settings 下进行设置，启动每个 Flow 则会直接运行。

2.1.1 C Simulation Dialog

Vitis Unified IDE

csim.clean：启用清理构建。如果不选择此选项，csim_design将进行增量编译。

csim.code_analyzer：启用代码分析器。设计在执行过程中将被分析。

csim.sanitize_address：启用地址检查器

csim.sanitize_undefined：启用未定义行为检查器

csim.setup：当指定此选项时，C仿真二进制文件将被创建在当前解决方案的'csim'目录中，但不会执行仿真。

2.1.2 C Synthesis

Vitis IDE

Vitis Unified IDE

2.1.3 C/RTL Co-simulation

2.1.4 Implementation

2.1.5 Package

在 Vitis Unified IDE 中独有。

3. C Synthesis 详解

在 Vivado IP Flow Target 流程中。

3.1 Classic Configuration Settings

3.1.1 config_array_partition

• complete_threshold, defalt=4
• throughput_driven, default=auto, (auto/off)

3.1.2 config_compile

• enable_auto_rewind, default=true
• ignore_long_run_time, default=false
• name_max_length, default=80
• no_signed_zeros, default=false
• pipeline_loops, default=64
• pipeline_style, default=frp, (stp/flp/frp)
• pragma_strict_mode, default=false
• pre_tcl
• unsafe_math_optimizations, default=false

3.1.3 config_dataflow

• default_channel, default=pingpong, (fifo/pingpong)
• disable_fifo_sizing_opt, default=false
• fifo_depth, default=2
• override_user_fifo_depth, default=0
• scalar_fifo_depth, default=2
• start_fifo_depth, default=2
• strict_mode, default=warning, (off/warning/error)
• strict_stable_sync, default=false
• task_level_fifo_depth, default=2

3.1.4 config_debug

• directory, default=.debug
• enable, default=false

3.1.5 config_export

3.1.6 config_interface

3.1.7 config_op

3.1.8 config_rtl

3.1.9 config_schedule

• enable_dsp_full_reg, default=true

3.1.10 config_storage

• fifo impl, default=autosrl, (bram/lutram/ram/memory/srl)
• fifo auto_srl_max_bits, default=1024
• fifo auto_srl_max_depth, default=2

3.1.11 config_unroll

• tripcount_threshold, default=0

3.2 New Configuration Settings

3.2.1 Array Partition

• array_partition.complete_threshold: 设置完全分区数组的阈值。具有少于阈值元素的数组将被完全分区为单独的元素。
• array_partition.throughput_driven: 启用自动部分和/或完全数组分区。

3.2.2 Array Stencil

• array_stencil.throughput_driven: 启用自动数组模板

3.2.3 Compile

• compile.design_size_maximum_warning: 当总设计指令超过此值时显示警告
• compile.enable_auto_rewind: 当为真时，启用用于流水线循环的替代 HLS 实现，该实现使用自动循环回绕
• compile.ignore_long_run_time: 忽略长运行时间警告
• compile.name_max_length: name_max_length 选项将指定函数名称的最大长度。如果长度超过阈值，名称的最后部分将被截断。
• compile.no_signed_zeros: no_signed_zeros 选项将忽略浮点零的符号，以便编译器可以对浮点操作进行最大程度的优化。
• compile.pipeline_flush_in_task: 启用数据流程中的非回绕流水线默认刷新。
• compile.pipeline_loops: 循环的迭代次数大于此值将自动进行流水线处理。
• compile.pipeline_style: 设置默认流水线样式，这是一种偏好而不是硬性约束。
• compile.pragma_strict_mode: 启用错误而不是警告，用于旧的和不正确的编译指示语法检查。
• compile.unsafe_math_optimizations: unsafe_math_optimizations 选项将忽略浮点零的符号，并启用浮点操作的结合性，以便编译器可以对浮点操作进行激进的优化。

3.2.4 Dataflow

• dataflow.default_channel: 默认情况下，在使用数据流流水线时，将以ping-pong方式配置的RAM内存用于在函数或循环之间缓冲数据。当使用流式数据（其中数据总是按顺序读取和写入）时，FIFO内存将更有效，并可以选择为默认内存类型。请注意，必须使用 set_directive_array_stream 命令将数组设置为流式，以便执行FIFO访问。
• dataflow.disable_fifo_sizing_opt: 禁用增加资源使用量并可能提高性能并减少死锁的FIFO大小优化。
• dataflow.fifo_depth: 指定FIFO的默认深度的整数值。当使用ping-pong方式的存储器时，此选项不起作用。如果未指定，通道中使用的FIFO将设置为最大生产者或消费者的大小（以较大者为准）。在某些情况下，这可能过于保守，引入比实际所需更大的FIFO。当用户知道FIFO比所需更大时，可以使用此选项。在使用此选项时要小心，因为不正确的使用可能导致设计无法正确运行。
• dataflow.override_user_fifo_depth: 设置设计中所有FIFO的深度，除非深度已经大于覆盖值。
• dataflow.scalar_fifo_depth: 指定标量值传播FIFO的最小深度的整数值。如果未指定，最小值为 fifo_depth 选项的值（如果指定），否则为2。这些FIFO用于将数据流区域的标量参数值传播到区域内具有前驱的处理过程。它们不影响功能正确性，但自动计算的大小不足可能导致性能损失甚至死锁。粗略来说，最佳深度是发出标量的处理过程在最后读取它的处理过程实际启动前的平均次数。
• dataflow.start_fifo_depth: 指定启动传播FIFO的最小深度的整数值。如果未指定，最小值为 fifo_depth 选项的值（如果指定），否则为2。这些FIFO用于将 ap_start 握手信号转发到区域内具有前驱的处理过程。它们不影响功能正确性，但自动计算的大小不足可能导致性能损失。粗略来说，最佳深度是处理过程应该被允许提前启动的预期平均次数。
• dataflow.strict_mode: 设置数据流规范形式消息的严重程度。
• dataflow.strict_stable_sync: 稳定端口强制与 done 同步。
• dataflow.task_level_fifo_depth: 默认任务级FIFO深度（用于自动创建的用于在处理过程之间传输标量的FIFO）。

3.2.5 Debug

• debug.directory: 相对于 solution 方案目录的输出目录名称
• debug.enable: 启用调试文件生成
• debug.enable_verbose_report: 启用覆盖率报告

3.2.6 interface

3.2.7 RTL

3.2.8 Schedule

• schedule.enable_dsp_full_reg: 启用完整的 dsp48 寄存器利用率

3.2.9 Unroll

• unroll.tripcount_threshold: 自动展开循环，其迭代次数少于此阈值。

3.2.10 Op

• hls.syn.op: 配置不同运算符的默认实现样式和延迟。

3.2.11 Storage

• hls.syn.storage: 配置不同类型存储元素的默认实现样式和延迟。

4. 创建 HLS 工程

在 Vitis Unified IDE 中，PL 内核被创建为 HLS 组件，你可以在 C/C++ 源代码上运行 C 仿真，使用编译指示或指令优化设计，综合和分析结果，并将设计导出为 Vivado IP 与 Vivado Design Suite 一起使用，或作为 Vitis 内核 ( .xo ) 文件在更高级别的系统项目中使用。

4.1 选择 HLS 组件

4.2 名称和路径

4.3 创建配置文件

4.4 选择综合源文件和TestBench

这里我们先跳过，后续再添加。

编写良好的测试平台可以极大地提高工作效率，因为 C 函数的执行速度比 RTL 仿真快几个数量级。在综合之前使用 C 来开发和验证算法比开发和调试 RTL 代码要快得多。

4.5 选择硬件平台

4.6 配置Clock和Flow

当未指定时钟不确定度时，默认时钟不确定性为时钟周期的 27%。

4.7 查看摘要

4.8 新建组件完毕

5. 总结

在Vitis 2024.1版本中，传统的Vitis GUI已经被全新的统一软件界面所取代。这个变化虽然初看令人生疏，但它实际上为开发者们带来了更加高效和现代化的工作环境。新界面的Flow Navigator、多任务并行执行、AI引擎优化、以及界面的现代化设计，都极大地提升了工作流程的管理和执行效率。此外，新的统一软件界面还提供了GUI和CLI模式的无缝转换，使得项目构建和调试更加灵活。虽然适应新界面需要时间，但随着熟悉度的提升，开发者们将能够充分利用这些新特性，以更快的速度迭代和优化他们的工程。总的来说，Vitis的这次更新不仅仅是界面上的改变，更是开发者与时俱进、不断进步的体现。