开发者分享 | 使用 Report QoR Assessment 命令

本文转载自:XILINX技术社区微信公众号

Report QoR Assessment (RQA) 用于详述您的设计 QoR 目标实现的可能性。如果此命令返回的结果与您的期望不符,那么本篇博文包含了有关您可采取的后续行动的附加信息。本篇博文不仅适合首次使用这些命令的新用户,对于有经验的用户应该同样很实用。

什么是 QoR 评估报告 ?

(Report QoR Assessment)

Report QoR Assessment (RQA) 详述了您为了实现自己的设计 QoR 目标而应采用的方法。它通过分析方法论和设计的特性,为您提供如下详细信息:

  • 按 1 到 5 评分,分值对应满足设计 QoR 目标的可能性
  • 您是否需要更正影响 QoR 的方法论问题
  • 您是否应使用 QoR 建议报告 (Report QoR Suggestions) 来增强设计
  • 流程指南,提供有关利用诸如 ML 策略或增量编译等工具功能的适当时机的建议
  • 它是一条基于文本的命令,可于综合后在 Tcl 控制台 (Tcl console) 中或脚本里,在实现流程的任意阶段运行。

    评估得分

    评估得分用于预测设计满足其 QoR 目标的可能性高低。它可在实现的任意阶段生成,但鉴于其前瞻性的本质,它适合在设计完全完成布线之前使用,并且在执行 opt_design 后生成的评分值最高。

    评估得分细分为 5 个等级:

    下表详列了 41 项设计的得分准确性:

    通过将 opt_design 得分与 route_design 得分进行比对,即可看到:

  • 59% 的设计预测准确
  • 98% 的设计预测偏差在 +/- 1 之间
  • 这样的准确率使我们得以指导用户在实现流程中是应继续运行后续步骤,还是使用 Report QoR Suggestions 等工具来改进设计并提升满足时序的可能性,亦或是执行其它操作。

    执行 place_design 后,评估得分准确率更高:

  • 76% 的设计预测准确
  • 98% 的设计预测偏差在 +/- 1 之间
  • 如您所见,如需进一步提升准确率,可运行额外的 place_design 步骤,但应注意的是,在此阶段运行该命令的作用有限。

    评估得分可用于判定您应致力于改进网表还是应运行实现工具。

    下表概括了常见后续操作:

    QoR 评估得分可使用 Report QoR Suggestions (RQS) 来加以改善,但这并不适用于所有设计。为了对得分 2(或低于 3)的设计进行改进,可能需要大量工作,例如,对 HLS 模块进行最优化、HDL 重新编码、变更 IP 配置等。

    如果我们仅关注实现工具流程,那么根据 RQA 得分应用自动 QoR 建议对于大部分设计都有效。运行 Report QoR Suggestions 后,对 RQA 得分的影响如下图所示。

    设计得分改善与否取决于建议的类型、建议的数量以及受影响的路径的数量。

    虽然并非所有设计的改善效果都足以使得分提升,但都能改善其设计性能特性(如,WNS 或拥塞),因此毋庸置疑,它朝着正确的方向迈出了一步。基于时钟和拥塞的建议所实现的改进效果最为明显。

    方法论报告

    改进设计时,如果 QoR 不升反降,那么您势必将面临如下选择。是继续修复?还是重新寻找新的解决方案?

    这里有一个好办法 - 解决方法论问题即可简化这一任务。

    如需了解这一观点的更多详情,请请进入赛灵思中文论坛(阅 解决方法论问题以简化时序收敛文。

    与 RQA 合并的方法论报告 (Report Methodology) 是一个精简版本。RQA 报告仅详列了影响 QoR 和工具变化的不合规的方法论检查。要获取完整报告,请运行 report_methodology 命令。

    将 QoR 评估报告与 QoR 建议搭配使用

    QoR 评估得分是通过观察多项底层级设计指标并形成总体设计得分的方法来生成的。即使使用自动建议,如需提升设计得分,最好还是查看设计中的问题详情,了解如何通过每次迭代来改进结果。

    详情 (Details) 表细分为多个类别,这些类别与 Report QoR Suggestions (RQS) 命令的类别相同。将设计问题综述集中于一处是非常有效的。此外,还有一个状态列用于显示需要复查的领域以及应满足的理想阈值。

    下图显示了 QoR 评估详情表示例:

    对于超出阈值的任何项,都会在其旁边添加 REVIEW 标记。阈值并非硬性限制,但可作为指导。这些阈值可帮助您洞悉设计中出现 QoR 下降的时机。如果只有某一个项略超阈值,那么您可以预判它对自己的设计影响有限。但如果有许多因子都略超阈值,或者如果某一个问题显著超出阈值,那么您几乎可以肯定设计中将出现问题。

    QoR 评估详情表还可提供实用概览,以便您在使用 QoR 建议改进设计之后检验资源变更情况。鉴于该表极为详尽,因此非常便于与先前版本进行并排对比。

    在 QoR 建议报告中,您将可以看到,各项建议根据对于所涉 RQA 得分的影响,按从高到低排列。通过将该表与建议进行比较,您即可看到各工具尝试从哪些方面来对设计进行改进。

    流程指南

    流程指南由 RQA 提供,其中详述了用户应采取的后续行动。它不仅十分便于新用户上手,对于经验丰富的 FPGA 设计师也十分实用。

    通常,它适合用于识别:

  • 尚未被解决的方法论违例
  • ML 策略或增量编译,因为用户不熟悉这些流程而可能将其忽略
  • 识别何时应使用 report_qor_suggestions (RQS)
  • 流程指南在“总体评估汇总 (Overall Assessment Summary)”表中提供。以下是报告示例:

    流程指南将判定设计是否需要进一步执行方法论修复、是否需要应用关键的实现建议,或者是否已经准备好执行 ML 策略或增量编译实现流程。设计的 QoR 指标中并没有任何一项属于硬性要求或属于被禁止项,但如果不符合标准,则很有可能无法满足期望目标。

    要使设计符合 ML 策略要求,必须满足以下条件:

  • 实现已完成且其运行经历了下列阶段:opt_design、place_design、phys_opt_design 和 route_design
  • 设计运行时所采用的所有Directive 均设置为“Default”或“Explore”。
  • 已完成关键设计修改。如果设计不符合 ML 策略要求并且上述条件已得到满足,那么您应该运行 RQS 来找出这些设计修改。
  • 受支持的系列为 UltraScale 和 UltraScale+
  • 要使设计符合增量编译要求,设计应满足下列条件:

  • 在时序收敛的合理范围内。WNS > -0.500 ns
  • RQA 得分为 4 或 5
  • 包含一些适合增量编译的 RQS 建议
  • 受支持的系列为 UltraScale 和UltraScale+

    注释:有部分关键路径无法通过增量流程来解决,例如,DSP/BRAM 中的固定级联路径。

    下一个建议的流程阶段会查看所有信息并判断最适合用户采取的行动方案。当设计符合增量和 ML 策略时,工具将为您提供最佳选择建议。

    总结

    在本篇博文中,我们向您展示了如何使用 Report QoR Assessment 来明确自己的设计满足时序的可能性以及哪些领域需要改进。

    我们演示了“详情 (Details)”表提供的详尽且实用的设计概述,最后还演示了如何使用“流程指南 (Flow Guidance)”功能来充分利用 Vivado 的工具流程。

    在下周博文中将为您展示将该工具用于真实设计的示例,敬请期待!

    最新文章

    最新文章