Report QoR Suggestions助力解决Vivado设计问题

简介

许多 FPGA 设计都难以达成所期望的性能目标。原因不尽相同，以下列出的只是其中部分可能的原因：

未遵循 UltraFast 设计方法

时序约束不良

过高资源利用率

控制集过多

未采用最优化时钟设置

逻辑层次过多，难以达成目标性能

布局规划不良

布线拥塞

因约束导致工具优化受限

如何才能轻松发现并快速修复这些问题？

Report QoR Suggestions

Report QoR Suggestions （RQS） 可识别设计问题，并提供工具开关和可影响工具行为的设计单元属性的解决方案，即便在无法自动执行解决方案的情况下也可提供文本修改建议。

早在 Vivado 2019.1 中，RQS 就已经开始输出建议对象文件。这使我们可以对建议进行跟踪、自动完成其实现、改进每一项建议的验证工作并提供更复杂的建议。在此过程中新的命令和一些流程修改应运而生，如下所述：

1. “report_qor_suggestions”命令将生成新建议并提供现有建议的相关报告。如下图所示，此命令可在实现过程的任意阶段完成后运行。

2. 审核建议完成后，将使用“write_qor_suggestions”写出一个包含所选建议的 RQS 文件。期间，建议的状态将自动被设置为 ENABLED（大写表示它属于建议对象的属性。

3. 通常下一步就是将此 RQS 文件应用到“建议运行 （Suggestion Run）”流程中，可以在 synth_design 或 opt_design 之前读入。在此流程中，处于“自动 （AUTOMATIC）”状态的建议经 APPLICABLE_FOR 阶段后即可被应用。

要使 AUTOMATIC 建议状态变更为 APPLIED，应在“建议运行”中调用 APPLICABLE_FOR 阶段的同时将其设置为 ENABLED。下图显示了流经 APPLICABLE_FOR 阶段的建议的处理过程：

在“建议运行”流程中，用户可以再次调用“report_qor_suggestions”。这整个流程是可重复的，通过将来自前一轮运行的建议与当前轮次的建议累积起来即可组成单个文件并馈送到最新一轮的建议运行中。

如果有部分建议不符合您的期望，那么您可以使用以下命令来对写入文件的建议加以过滤：

write_qor_suggestions -of_objects ［get_qor_suggestions -filter {some_fillter}

如果在此流程中多次运行“report_qor_suggestions”，并在流程的不同阶段生成相同的建议，那么 RQS 将自动对重复的建议进行管理。

出现的建议可能会重复。例如，通过运行综合或“opt_design”建议可得到相同的结果。在此情况下，RQS 仅允许将其中一项建议设置为 APPLIED，并且倾向于采用综合建议。

此外，编写 checkpoint 时，建议的当前状态将存储在 checkpoint 中。因此，只要建议已被读取，即可写出 checkpoint，而重新打开 checkpoint 时，则无需重新读取建议。

案例分析示例

示例分析是了解建议效果的最佳途径。

以下是针对此具体设计示例执行“place_design”之后出现的建议列表。

建议名称

首先请注意名称。第一项建议的名称 （NAME） 为 RQS_XDC-1-1。NAME 用于指示建议的类别。这项建议来自于 XDC 类别。

总共有 6 个类别：

• 利用率 （Utilization）

• XDC

• 时钟设置 （Clocking）

• 拥塞 （Congestion）

• 时序 （Timing）

• 策略 （Strategy）

根据经验，影响利用率、XDC 和时钟设置的建议应在设计周期内尽早解决，如下图所示：

这些建议通常会对大量路径产生影响，并且还能降低设计收敛流程后期的拥塞和时序问题的严重程度。解决时序和拥塞问题的建议与解决时钟设置、利用率和 XDC 问题的建议总是一并应用，无法拆分，但前两类建议可能导致利用率增高，并且时钟设置修复后可能就不再需要。

有鉴于此，通常在根据赛灵思 UltraFast 方法建议调整时序和 XDC 之前，不建议尝试解决时序问题或拥塞问题。

时序和拥塞问题主要出现在特定模块或特定时序路径上。

拥塞仅出现在布局之后，并且在布线后准确性可有所提升。

通常仅在 RQS 发现时序路径违例的路径上才会报告时序建议。默认情况下，RQS 可在每个时钟组中发现 100 条时钟路径。如果有的路径有时序问题但未出现在这 100 条路径中，那么 RQS 将不会提供有关这些路径的建议。要增加路径数量，请运行以下命令：

report_qor_suggestions -max_paths 《大于 100 的值》

有关策略建议的相关话题将在后续博客中进行探讨。

自动建议

接下来请看表中的最后一条建议 RQS_CLOCK-1-1。在该表格中可以看到这是一项 AUTOMATIC 建议。此建议将对 BUFG 驱动的网络应用 CLOCK_DELAY_GROUP 属性。

倒数第二条建议 RQS_CLOCK-2-1 为手动 （AUTOMATIC = 0） 建议。它建议更改时钟设置拓扑结构，通过将 BUFGCE + MMCM 除法器更换为含内置除法器的 BUFGCE_DIV 来进一步优化此拓扑结构。Vivado 无法自动交换这些Buffer，因此需要用户手动执行 RTL 编辑。

顾名思义，AUTOMATIC 建议简单易用，而手动建议则更为复杂。以下显示了自动建议和手动建议所需的不同方法。

自动

• 将属性应用于对象

• 将开关应用于命令

• 对约束稍作修改

手动

• 需要执行 RTL 设计编辑

• 需要更新约束

• 需要更多用户分析

总之，接近 80% 的建议为自动建议。鉴于手动建议所需工作量更大，因此可以考虑先跳过部分手动时钟设置 （CLOCKING） 或利用率 （UTILIZATION） 建议，直接尝试自动 （AUTOMATIC） 拥塞建议。但要实现最佳 QoR，必须先解决这些问题。

QoR 增益

以下显示的是 30 个设计使用如下条件后所得结果：

• “place_design”Explore 指令

• 不含建议的“参考运行 （Reference Run）”与相同流程的“建议运行 （Suggestion Run）”对比结果

“place_design”生成的时钟设置建议

“route_design”生成的所有其他建议

仅对自动 （AUTOMATIC） 建议进行比较

QoR 增益通过两种方式来测量：

通过观察 WNS 的绝对提升量（易于理解的指标）。

观察建议运行相比参考运行中所有失败的时钟的几何平均增益（更可靠的 QoR 增益指标）。

以下示例来自于先前表格对应的设计：

蓝色高度表示“参考运行”，橙色高度表示“建议运行”的新 WNS。可以看到，RQS 对设计的 WNS 的提升效果显著。全部 30 项设计的平均 WNS 增益达 0.648 ns。

此图显示了一种更为完善的测量措施。它通过观察所有运行失败的时钟来计算几何平均数的提升百分比 （%）。此方法可以平滑掉单一时钟出现重大错误盖过其他多个时钟出现时序设置故障的数值。

这些设计中的几何平均值的平均增益为 12.1%。

当然其中有特别突出的增益。在排名前 4 的设计中，QoR 平均提升 34.7%。

通过对增益进行分析可以发现：

存在对少量路径产生重大影响的单一特定问题时，QoR 增益超过 20%。解决此类问题易如反掌。

解决时钟设置问题时，QoR 增益超过 10%

解决通常接近设计收敛周期末尾的个别时序路径中的问题所得到的增益较少。

简单问题全部解决后，再要继续提升增益就不那么容易了。这段解析展示了 RQS 在整个设计周期内产生的影响，应在完成设计中的重大修改后再运行。

除了此处展示的数字之外，并没有其他简单方法可用来测量手动建议所实现的增益，因此执行手动修改后，用户所能实现的 QoR 增益甚至可能超过此处所示的数字。