ug1292深度解析

ug1292第一页的主题是初始设计检查。这一步是针对综合后或者opt_design阶段生成的dcp。尽管在Vivado下，从功能仿真到综合、布局布线、直至生成.bit文件是相对自动化的流程，但是解决时序违例仍然是一个复杂且耗时的过程。仅仅靠log信息或者布线后的时序报告往往很难定位，这是因为实现过程中的每一步（opt_design逻辑优化，place_design布局, phys_opt_design物理优化, route_design布线）都会做一些优化，这些优化可能会导致关键路径被掩盖，例如，有时发现设计中逻辑级数（Logic Level）较高的路径时序收敛了，反倒是逻辑级数较低甚至为0的路径出现时序违例。因此，采取按部就班的策略，检查每一步的结果，及时且尽早发现设计中的问题是很有必要的。

初始设计检查流程如下图所示。对象是综合后或opt_design阶段生成的dcp。会依次执行三个命令（图中红色标记），生成三个报告：FailFast报告、时序报告和UFDM（UltraFast Design Methodology）报告。

（图片来源ug1292, page 1）

report_failfast的一个便利之处是可以给出各类资源利用率的上限，如下图所示，这是Vivado自带例子工程cpu的FailFast报告。可以看到，对于LUT，利用率应控制在70%以内；触发器（FD）应控制在50%以内；BlockRAM和DSP48可以达到80%。在这个报告中尤其要关注Status为Review的条目，这是会给时序收敛带来负面影响的，需要优化的。对于设计中存在Pblock情形，report_failfast提供了-pblock选项，对于SSI器件，report_failfast提供了-slr和-by_slr（需要在place_design阶段生成的dcp下使用）选项。这样，可针对某个pblock或某个SLR进行分析。

report_timing_summary可以生成时序报告，除了查看时序违例路径之外，该报告还可显示时序约束是否存在潜在问题。如下图所示，Check Timing下包含12个条目，这个阶段需要格外关注是否有未约束的时序路径，是否有Timing loop，同时还要关注时钟约束是否合理。

report_methodology可以生成UFDM报告。该命令不仅可以检查RTL代码存在的问题，例如Block RAM没有使用内部Embedded Registers，DSP48用做乘法器时没有使能MREG等，还可以检查时序约束存在的问题。如图所示，要尤其关注其中的Bad Practice。

对于这三个报告中存在的问题，要尽可能地在综合阶段或者opt_design阶段加以解决，最终确保这三个报告足够“干净”，即所有隐患都被消除。

此外，对于大规模的设计，可针对设计中的关键模块使用上述三个命令，因为这些关键模块很有可能成为时序收敛的瓶颈。为了使用这三个命令，可以对关键模块采用OOC（Out-of-Context）的综合方式或单独创建Vivado工程以便生成相应的dcp。