设计收敛报告
Report QoR Assessment
report_qor_assessment
命令会生成报告以提供下列信息
:
• 评估得分
,
用于指示设计满足性能目标的概率
• 有关建议的后续步骤的流程指南
• 使用率和性能指标汇总信息
• 对于
QoR
至关重要的方法论检查汇总信息
(
仅限在文本版本中提供
)
• 有关
ML
策略可用性的信息
总体评估汇总
此汇总包含
QoR
评估得分和流程指南信息。
评估得分可以预测设计在实现流程中给定时间点达成时序目标的可能性。在流程中越早运行该命令
,
可节省的编译时间更多,
因此收益就越大。虽然准确性略有牺牲
,
得分比最终布线后得分高
,
但差值应不超过
1
。此得分是通过分析一组复杂的设计指标来生成的,
这些指标包括
UltraFast
方法论、器件使用率、控制集、时钟设置、建立裕量和保持裕量等。此外,
其中还考量了器件特有的特性和设计阶段。例如
,
执行
synth_design
后
,
将对时钟设置网表结构进行仔细检查;
在
place_design
时钟偏差随着准确性增加而具有更大的权重之后以及在
route_design
之后
,
将考虑其他新因素,
例如设计能否完全布线。评分范围为从
1
至
5
。如果得分低于
5
,
请使用
report_qor_suggestions
来改善得分。
流程指南属于总体评估汇总的一部分。它会根据设计的当前状态进行动态更新。它可提供以下相关信息
:
• 您是否需要解决方法论问题
• 使用
QoR
建议是否改善设计
• 使用
ML
策略还是增量编译
QoR Assessment Details
“
QoR Assessment Details
”
(
QoR
评估详情
)
表如下图所示
,
其中提供了便利的设计概览
,
着重显示奠定
RQA
评分基础的以下领域的问题。
•
Utilization
(
使用率
)
•
Netlist
(
网表
)
•
Clocking
(
时钟设置
)
•
Congestion
(
拥塞
)
•
Timing
(
时序
)
该表显示了分为
5
个类别的设计特性。每个类别中如无任何子项标记为
REVIEW
,
则该类别标记为
OK
。如有子项标记为 REVIEW
,
则会显示时序失败的项及其阈值和当前值。阈值并非硬性限制
,
可超出阈值限制
,
但可能导致难以达成时序收敛。如果阈值超出过多或者有众多类别均超出其阈值,
则需特别留意。标有
*
的项并不直接参与评分
,
但对于设计是否将满足时序,
这些项可能至关重要
,
故而因加以复查。 使用率检查是在 SLR
级别和
Pblock
级别对整个器件执行的检查。运行
report_qor_suggestions
有助于降低使用率。 网表检查是针对网表结构和非时序约束执行的检查。这些检查将识别具有 DONT_TOUCH
属性的项、驱动程序剖析信息欠佳的高扇出信号线以及可能给实现工具增加困难的其他设计功能特性。时钟设置可显示建立时间路径或保持时间路径上时钟偏差是否过高。失败的时钟偏差路径会被自动添加到 Vivado IDE 中。在文本模式下,
添加 ‑
csv_output_dir <directory>
即可生成
CSV
格式的时序路径。运行 report_qor_suggestions 可以给众多时钟偏差问题提供自动修复。 拥塞会查看网表中的剖析信息,
寻找可能造成布线拥塞的问题。拥塞区域信息在布局前不可用
,
但有部分网表项可用。 您可先运行布局布线来评估拥塞,
而后再修复这些项。运行
report_qor_suggestions
可生成相关建议
,
以拥塞区 域内的单元为目标来减少拥塞。 时序会查看每个时钟组中 100
条最差的路径。它将分析
:
•
WNS
、
TNS
、
WHS
和
THS
,
判定设计是否有可能达成时序收敛。
• 信号线预算检查的是可布线的信号线
,
其中将添加保守的信号线延迟
,
而不是添加估算的延迟。
•
LUT
预算检查的是
LUT
,
将延迟替换为保守的
LUT
延迟
,
而不是使用估算的延迟。
LUT
和信号线预算检查都允许使用低于理想值的估算值。通过解决超出裕量的路径中的问题
,
以减少设计流程中后续出现的问题数量。请参阅 Vivado IDE
中的“
Challenging Timing Paths
”
(
时序收敛困难的路径
)
部分
,
或者生成
CSV文件以查看有关这些文件的更多信息。
在已布线的设计上
,
通过检查其他功能特性即可使用“
last mile
”
(
最后一步
)
指令查看设计是否收敛
,
该指令是在“Intelligent Design Runs
”
(
智能设计运行
)
功能特性内部使用的指令。它将基于最差情况时序路径内涉及的
WNS
、WHS、路径前后裕量和原语
,
检查时序路径是否能满足时序。
方法论检查
使用
report_methodology
运行有限数量的方法论检查以奠定坚实的基础
,
确保
QoR
建议有效。如果已生成方法论检查,
那么除非设计中存在变更
,
否则就会复用缓存的结果。如需运行方法论检查
,
则会导致运行时间增加。方法论检查可使用 -exclude_methodology_checks
开关来禁用。
ML Strategy Availability
如果参考运行中尚未运行所需的实现运行
,
那么
report_qor_suggestions
不会生成
ML
策略。“
ML Strategy Availability”
(
ML
策略可用性
)
表
(
如下图所示
)
会核对每一个必需的实现步骤。
流程要求如下
:
•
opt_design
命令必须搭配
Explore
或
Default
指令一起运行。
• 剩余实现指令必须全部设为
Default
或全部设为
Explore
。不允许混用搭配这些实现步骤。
• 必须启用
phys_opt_design
命令
• 设计必须完成布线。