【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)是默认执行的。对于实现后的而设计，最大和最小延时分析(setup/hold, recover/removal)是默认执行的。若要只运行最小延时分析(hold and removal)，选择延时类型min。 等效Tcl选项：-delay_type。

• Report unconstrained paths 产生没有时序要求的路径的信息，IDE默认勾选，但是等效的Tcl命令（report_timing_summary）默认是不选的。 等效Tcl选项：-report_unconstrained。

• Report datasheet 生成报告数据表中定义的设计数据表。 等效Tcl选项：-datasheet

Path limits:

• Maximum number of paths per clock or path group: 控制每个时钟对或路径组报告的最大路径数。默认是10 等效Tcl选项：-max_paths
• Maximum number of worst paths per endpoint: 控制每个路径端点可能报告的最大路径数。此限制以每个时钟对或路径组的最大路径数为限。因此，报告的路径总数仍然受到-max_paths数量的限制。 等效Tcl选项：-nworst

Path Display:

• Display paths with slack less than: 根据松弛值过滤所报告的路径。此选项不影响汇总表的内容。 等效Tcl选项：-slack_lesser_than

• Significant digits: 控制报表中显示数字的准确性。 等效Tcl选项：-significant_digits

Command: 显示Tcl命令行，相当于在上面的对话框中指定的各种选项。 Open in a New Tab:: 在新选项卡中打开结果，或者替换由results窗口打开的最后一个选项卡。 Open in Timing Analysis Layout: 将当前视图布局重置为定时分析视图布局。

page2:

Report:

• Report from cell: 允许限制设计中特定单元格的时间报告。只有开始、结束或完全包含在单元格中的路径才会被报告。 等效Tcl选项：-cell

• Show input pins in path: 显示用于路径的单元格输入管脚。保留此选项以提供路径中使用的所有引脚的更多信息 等效Tcl选项：-input_pins

• Report unique Pins: 为每种特殊的引脚只显示一个时间路径。 等效Tcl选项：-unique_pins

File Output:

• Write results to file: 将结果写入指定的文件名。默认情况下，报告被写入Vivado IDE中的Timing窗口 等效Tcl选项：-file

• Overwrite/Append: 当报告被写入文件时，确定(1)指定的文件是否被覆盖，或(2)新的信息被附加到现有的报告中。 等效Tcl选项：-append

Miscellaneous:

• Ignore command errors: 忽略任何命令行错误并且不返回任何消息。该命令还返回TCL_OK，不管在执行期间遇到任何错误。 等效Tcl选项：-quiet

• Suspend message limits during command execution: 临时覆盖任何消息限制并返回所有消息。 等效Tcl选项：-verbose

page3：

Interconnect: 控制网络延时是根据leaf cell pins之间估计的布线距离计算的，还是由实际布线网络计算的，或者从时序分析中排除net延时。对于综合后的设计，该选项自动设置为“ Estimated”，对于实现后的设计，该选项自动设置为“Actual”。

• Estimated:对于未放置的单元，根据驱动器和负载以及扇出的性质，净延时值对应于可能的最佳放置的延时。在时序路径报告中，未放置的leaf cell pins之间的网被标记为unplaced。对于已放置的cell，净延时取决于驱动器和负载以及扇出之间的距离。这个网在时间路径报告中被标记为estimated。
• Actual: 对于已布线网络，net延时对应于路由互连的实际硬件延时。此net在定时路径报告中被标记为routed。
• None: 在时序报告中不考虑互连延时，净延时被强制为零。 等效Tcl命令： set_delay_model

Speed Grade Setting: 设置器件速度等级。默认情况下，此选项是根据创建项目或打开设计检查点时选择的器件类型来设置的。您可以更改此选项，以根据另一个速度级别报告同一设计数据库的时序情况，而无需重新运行完整的实现流程。 等效Tcl命令： set_speed_grade

Multi-Corner Configuration Setting: 指定要分析的指定 timing corner 的路径延时类型。有效值为none、max、min和min_max。选择none将禁用对指定corner的计时分析。推荐设置建立(max)和保持(min)分析选择的两个区域。 等效Tcl命令： config_timing_corners

Disable Flight Delays: 不要在I/O延时计算中添加包延时。 等效Tcl命令： config_timing_analysis

2.1.2 时序总结报告的详情

时序总结报告包含一下部分，Report Timing Summary不光包括其他报告的内容(Report Clock Interaction, Report Pulse Width, Report Timing, Check Timing) ，也包含一些特有的内容，如Unconstrained Paths。

节说明General Information Section提供设计名称，器件等信息Timer Settings Section包含有关Vivado用于在报告中生成时序信息的时序分析引擎设置的详细信息。Design Timing Summary Section时汇总报告的设计时序汇总部分提供了设计时序的汇总，并将所有其他部分的结果合并到一个视图中。Clock Summary Section包含类似于report_clocks生成的信息:设计中所有的时钟；每个时钟的属性。缩进反应了时钟的关系Check Timing Section包含关于缺少时序约束或需要检查的带有时序问题的路径的信息。对于完整的时序signoff，必须约束所有路径端点。Intra-Clock Paths Section汇总了同一源和目的时钟的最严重松弛和总违例情况。Inter-Clock Paths Section与Intra-Clock Paths部分类似，总结了不同源和目标时钟之间的时间路径的最严重松弛和总违例情况。Path Groups显示默认路径组和自定义路径组。User-Ignored Paths Section显示了由于set_clock_groups和set_false_path约束而在定时分析中被忽略的路径。报告的松弛是无限的。Unconstrained Paths Section显示由于缺少计时约束而没有时序的逻辑路径。这些路径按源时钟对和目标时钟对分组。当没有时钟可以与路径起点或端点相关联时，时钟名称信息显示为empty(或NONE)

Design Timing Summary Section

Setup Area (Max Delay Analysis)：

• Worst Negative Slack (WNS): 这个值对应于最大延时分析中所有时序路径的最坏松弛。可正可负。
• Total Negative Slack (TNS): 仅考虑每个计时路径端点的最坏违例时，所有WNS违例的总和。当满足最大延时分析的所有时序限制时为0ns，当有违例行为时，是负的。
• Number of Failing Endpoints: 时序违例（WNS < 0ns）的点总数。
• Total Number of Endpoints: 被分析的端点总数。

Hold Area (Min Delay Analysis)：

• Worst Hold Slack (WHS): 对应于所有时序路径的最坏松弛，用于最小延时分析。可正可负。
• Total Hold Slack (THS): 当只考虑每个计时路径端点最严重的违例时，所有WHS违例的总和。
• Number of Failing Endpoints: 时序违例（WHS < 0ns）的点总数。
• Total Number of Endpoints: 被分析的端点总数。

Pulse Width Area (Pin Switching Limits)：

• Worst Pulse Width Slack (WPWS): 当同时使用最小和最大延时时，对应于上面列出的所有时序检查的最坏松弛。
• Total Pulse Width Slack (TPWS): 当只考虑设计中每个引脚最严重的违例时，所有WPWS违例的总和。
• Number of Failing Endpoints: 时序违例（WPWS < 0ns）的点总数。
• Total Number of Endpoints: 被分析的端点总数。

Check Timing Section 可以通过Reports -> Timing -> Check Timing 或者 Tcl命令check_timing单独产生。

这个报告包含的时序检查：

时序检查说明pulse_width_clock报告只有与该时钟引脚相关联的脉冲宽度检查，以及没有setup或hold检查，没有recovery、 removal或clk > Q检查。no_input_delay没有任何输入延时限制的非时钟输入端口的数量。no_clock定义的时钟与时钟引脚数不匹配。电平恒定的时钟引脚也会报告constant_clock检查接到一个恒定信号（gnd/vss/data）的时钟信号unconstrained_internal_endpoints没有时序要求的路径端点数(不包括输出端口)。数量与缺少时钟定义直接相关，这也是由no_clock检查报告的no_output_delay一个输入延时约束都没有的non-clock端口数multiple_clock一个时钟引脚有多个时钟，如果在一个时钟树中有一个时钟多路复用器，就会发生这种情况。默认情况下，共享同一时钟树的时钟是一起计时的，这并不代表现实的时序情况。在任何给定的时间里，时钟树上只能有一个时钟。如果没有MUX，需要检查为什么多个时钟在同一时间到达generated_clocks不属于同一时钟树的主时钟源所生成的时钟的数量。当主时钟和生成的时钟源点之间的逻辑路径上的时序弧被禁用时，就会发生这种情况。当使用-edges选项指定时，此检查也适用于生成时钟的单个边缘:逻辑路径 unateness(反相/非反相)必须匹配主时钟和生成时钟之间的边缘关联。loops在设计中发现的组合逻辑loops的数目。循环被Vivado IDE时序引擎自动打破以报告时序partial_input_delay只有最小或最大输入延时限制的非时钟输入端口数。这些端口在setup和hold分析中都没有报告。partial_output_delay只有最小或最大输入延时限制的非时钟输出端口数。这些端口在setup和hold分析中都没有报告。latch_loops检查和警告设计中通过锁存器实现的loops。这些loops不会被报告为组合loops的一部分，并且会影响相同路径上的锁存时间计算。 2.1.3 报告Clock Networks

Tcl命令： report_clock_networks -name {network_1}

2.8 报告跨时钟域（Clock Domain Crossings）

报告CDC(Clock Domain Crossings)会进行分析的结构：

• 在异步时钟之间的所有路径上。
• 仅在有下列时序异常的同步时钟之间的路径上:
  • Clock groups
  • False Path
  • Max Delay Datapath Only

2.8.3 跨时钟域报告规则

CDC拓扑的原理图表示

1. 单bit同步器

ASYNC_REG属性必须在同步链的至少前两个触发器上设置。同步器深度由链式触发器的数量定义。

2. 多bit同步器

基于寄存器的总线同步器在跨时钟域处理中是不安全的，所以CDC-6规则会报一个警告供用户判断。 如果总线是格雷编码，那么这种方法就是安全的，只要总线上已经设置了足够的时间限制，以确保接收域一次只能捕获到一个数据。 如果总线不是格雷编码，应该用其他的同步器拓扑结构，比如CE控制的CDC或MUX控制的CDC。

3. 异步复位同步器 基于CLEAR进行同步：

*FDCE: D Flip-Flop with Clock Enable and Asynchronous Clear

基于PRESET进行同步：

*FDPE: D Flip-Flop with Clock Enable and Asynchronous Preset

触发器1分别连接同步clear或preset信号，它们对clk_a是安全的。 一般的建议是避免在目标时钟域内多次同步复位信号这意味着从源时钟域到目标时钟域的复位不应该有任何扇出。此建议防止目标时钟域在不同的时间释放复位，这会将设计置于未知状态。未能遵循这一建议将导致从 launch flop到目标时钟的关键CDC-11扇出违例。 然而，在FIFO Generator IP的场景种，有多次同步的复位信号在目的时钟域也是安全的。FIFO Generator异步进入复位状态然后同步释放，虽然FIFO接收到异步复位，但它将真正的同步复位应用于BRAM。只要设计使用其wr_rst_busy信号来保持数据流，就不会出现逻辑部分未复位而部分仍处于复位状态的情况。 AXI接口使用5个FIFO生成器IP来同步每个目标时钟域中的重置，并且是通过构造安全的重置电路的另一个示例。在安全的情况下，可以多次同步重置信号，可以忽略CDC-11违例。

在同一目标时钟域中涉及两个FIFO生成器的安全复位同步示例：

4. 组合逻辑 在clk_a到clk_b种的组合逻辑LUT3，实现clk_a到clk_b同步。

   这种结构传统上不推荐，因为组合逻辑的输出可能会出现小故障，它会被同步器捕获并向下传播到设计的其余部分。

5. 扇出 在下图所示的简化的Fanout示例中，源触发器驱动一个网络，该网络在以红色突出显示的clk_b域中同步了三次。不建议使用这种结构，因为它会导致目标时钟域的数据一致性问题，因为通过同步器的延时是有边界的，但不是周期精确的。

N到N个不同时钟域的扇出不是CDC问题，也不会触发CDC-11违例。

5. 多时钟扇入 clk_a和clk_x两个时钟传送数据通过组合逻辑（LUT2）给clk_b时钟域的同步器：

建议首先分别同步来自clk_a和clk_x的源数据，然后再通过一些逻辑将它们组合起来。这改善了CDC整体结构的MTBF特性，并防止小故障传播到目标时钟域。

6. Non-FD Primitive

FDRE与RAMB之间发生了CDC，而RAMB原语内部不存在同步逻辑。即使插入连接到clk_b的单级触发器到RAMB前,由于FDRE和RAMB单元之间的路由距离，它仍然被认为是一个不充分的同步器。

7. CE-controlled CDC 时钟使能（clock enable）信号在【用于控制寄存器FF3前】在时钟域clk_b同步。

CDC引擎仅检查连接到FF3/CE的信号是否也由clk_b驱动。时钟使能信号的同步方式没有限制，只要它作为安全CDC路径单独报告即可。此外，您还负责约束从clk_a域到FF3的延时，这通常是通过set_max_delay -datapath_only约束完成的。

8. Mux-Controlled CDC

   数据选择器输出的信号同步至clk_b 。

对于如何同步选择信号没有限制，只要它被单独报告为安全。用户负责约束在FF2_c上的传递延时。

9. Mux Data Hold CDC 数据选择信号同步到clk_b，data_out反馈到数据选择器。