【vivado UG学习】UG906学习笔记：对综合或实现后的结果进行逻辑分析

1 用IDE进行逻辑分析

1.3 Netlist窗口的使用

网表窗口展示了经过Synthesis工具综合后的网表的层次结构。

根据综合设置
网表层次结构可能与原始RTL 100%匹配，也可能没有层次结构。
通常，Synthesis工具默认保留大部分用户层次结构，同时优化逻辑。这将产生一个更小、更快的网表。

使用合成工具的默认值，网表层次结构是可以识别的，但是层次结构的接口可能会被修改。可能缺少一些引脚和层次结构级别。层次结构的每一层都显示它的层次结构树。在每一层，工具显示：

• 一个nets文件夹。
• 一个leaf cells文件夹（如果有该级别的硬件原语实例）。
• 在该级别实例化的任何层次结构。

每个层级的属性窗口显示了资源使用统计包括：

• 整个分支树基本资源的使用情况。
• 分支树的net数量
• 层级的时钟使用。

1.4 Hierarchy窗口的使用

打开Hierarchy窗口： Tool-> Show Hierarchy 或者 在Netlist窗口按F6。
这个窗口是网表的层次结构图，层次结构的每一层的大小都是相对于该层的实例数量与设计中的实例总数的比值。

1.5 利用率报告的使用

打开窗口：Reports-> Report Utilization… 或者 Open Implementation Design -> Report Utilization

1.6 Schematic 窗口的使用

原理图是网表的图形化表示。原理图可以：

• 网表的图形表示。
• 检阅逻辑门，层次结构以及连接。
• 查找以及展开逻辑体。
• 分析设计。
• 更好的理解内部设计。

1.9 DRC报告的使用

设计规则检查（Design Rule Checks，DRCs）检查设计并报告常见的问题，2016.1版后，drc被分成两个不同的命令。方法学的drc已经移到report_methodology命令中，而所有其他的drc都在report_drc命令中。使用report_drc命令运行非方法学的drc。
在实现期间，这些工具也运行DRCS。在布局和路由方面，drc变得更加完整和全面。

在设计流的早期检查DRC消息、Critical Warnings和Warnings，以防止以后出现问题。

比如：在综合设计(synthetic Design)中，Report DRC步骤为不受约束的I/O报告一个【严重警告】。布线设计DRC报告也会报告【严重警告】。这个时候必须审查这份报告。不然在write_bitstream时，DRC会被提升为【Error】，无法生成比特流。所以需要尽早审查DRC报告，以确定需要修改的设计领域。

1.10 验证设计方法论DRC(Validating Design Methodology DRCs)

由于方法的重要性，Vivado工具提供了report_methodology命令，该命令专门检查方法是否符合drc。根据设计过程的不同阶段，有不同类型的drc。RTL lint风格的检查运行在详细的RTL设计上；综合设计中采用了基于网表的逻辑和约束检查；实现和时序检查在实现上运行。
要在Tcl提示符下运行这些检查，请打开要验证的设计并输入以下Tcl命令:
report_methodology

在Methodology窗口中列出了违例(如果有的话):

2 时序分析功能

报告时序总结（Timing Summary）： Implementation后，Reports -> Timing -> Report Timing Summary 或者打开implementation后打开。
Tcl命令： report_timing_summary

综合后的设计，Vivado 时序引擎基于连接和扇出估计net延时，对于用户已经放置的单元之间的网，延时的准确性更高。在一些预先放置单元(如I/O和GT)的路径上可能存在更大的时钟偏差。

实现后的而设计，Vivado基于实际的布线信息估计net延时，如果已经完成了布线则使用时序报告查看。

2.1 Report Timing Summary

2.1.1 Report Timing Summary对话框的设置

page1：

Report:

• Path delay type: 选择要运行的分析的类型。对于综合后的设计，只有最大延时分析(setup/recovery)是默认执行的。对于实现后的而设计，最大和最小延时分析