跳转到主要内容

Vivado 2018.2.x 及更早版本的设计咨询——生成的、引用错误主时钟的时钟会导致不正确的时钟偏移

judy 提交于

<strong>描述</strong>
本设计咨询主要介绍一个错误的时钟偏移计算导致错误时序收敛的问题。

出现问题的情况:

这可能会影响使用生成时钟的设计,其具有以下特征:
<li>使用 Vivado 2018.2.x 及更早版本。</li>
<li>用户生成的时钟没有使用‘-master_clock’定义</li>
<li>在同一时钟网络的并行分支上的层级引脚上创建的主时钟或生成的时钟连接至上述用户生成的时钟源引脚</li>

在上述情况下,时序引擎可能会为生成的时钟选择错误的主时钟,这可能会导致在路径上报告的不正确时钟偏移。

在 Vivado 2018.3 中,定时器使用正确的主时钟,这会导致相同路径上不同的时钟偏移和不同的签收时序。

注:如果用户生成的时钟用‘-master_clock’创建并指向正确的主时钟,该问题就不会出现。

该问题的示例:

在本示例中,datapath 通过 LUT 循环回到相同的寄存器。寄存器和 LUT 都放在同一个 SLICE 中。

示例时钟拓扑:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_1shi_zhong_tuo_bu_.jp…; alt="" width="670"></center>

示例 Datapath 拓扑:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_2_datapath_tuo_bu_.jp…; alt="" width="670"></center>

使用 Vivado 2018.2.x 及更早版本,在‘route_design’后使用正裕量报告上述路径:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_3_3.jpg&quot; alt="" width="670"></center>

请注意,由于缺少源时钟路径,2.560nS 的路径偏移过大。

由于选择了错误的主时钟进行时序分析,因此在工具选择的主时钟和用户生成的时钟之间没有路径,从而导致较大的时钟偏移。

这将迫使路由器在路径上通过一个较长的路由绕道来修复保持违规。

该路径通过在 Vivado 2018.3 中重新加载路由后检查点来显示违规:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_4_3.jpg&quot; alt="" width="670"></center>

在 Vivado 2018.3 中,由于可以计算源时钟延迟,因此路径偏移要小得多。

时钟偏移会导致设置违规,这是由于在该路径上为了修复 Vivado 2018.2.x 及更早版本中出现的保持违规而绕道了很长的路由路径。

可能会出现问题的典型情况:

在本实例中,在层级引脚上创建的主时钟不正确。
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_5_4.jpg&quot; alt="" width="670"></center>

有问题的时钟约束来自输入时钟源选项被设置为“单端时钟支持引脚(默认)”或“差分时钟支持引脚”而 IP 时钟输入没有连接至顶层输入端口的时钟向导。

####################################################################################

# Constraints from file : 'pfm_top_clkwiz_kernel_0.xdc'

####################################################################################

current_instance -quiet

current_instance pfm_top_i/static_region/slr1/base_clocking/clkwiz_kernel/inst

create_clock -period 10.000 [get_ports -scoped_to_current_instance clk_in1]

set_input_jitter [get_clocks -of_objects [get_ports -scoped_to_current_instance clk_in1]] 0.100

在时钟向导输入时钟源设置为“全缓冲”或“无缓冲”时,层级引脚上没有创建主时钟。

确认:

上述问题由‘report_methodology’检测报告。

建议始终运行“report_methodology”并处理报告的违规:
TIMING-6#1 Warning

No common primary clock between related clocks

The clocks pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q and microblaze_0_Clk are related (timed together) but they have no common primary clock. The design could fail in hardware. To find a timing path between these clocks, run the following command: report_timing -from [get_clocks pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q] -to [get_clocks microblaze_0_Clk]

Related violations: <none>

TIMING-30#1 Warning

Sub-optimal master source pin selection for generated clock

The generated clock pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q has a sub-optimal master source pin selection, timing can be pessimistic

Related violations: <none>

TIMING-36#1 Warning

Invalid Generated Clock due to missing edge propagation

There is no rising/falling edge propagation between master clock pfm_top_i/static_region/slr1/base_clocking/clkwiz_pcie/inst/clk_in1 to generated clock pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q

Related violations: <none>

Vivado 2018.2.x 和 2018.3 中也会报告 TIMING-27 违规。

TIMING-27 检查指向层级引脚上不正确的主时钟定义,这可能会导致不安全的时序。
TIMING-27#1 Warning

Invalid primary clock on hierarchical pin

A primary clock pfm_top_i/static_region/slr1/base_clocking/clkwiz_kernel/inst/clk_in1 is created on an inappropriate internal pin pfm_top_i/static_region/slr1/base_clocking/clkwiz_kernel/inst/clk_in1. It is not recommended to create a primary clock on a hierarchical pin when its driver pin has a fanout connected to multiple clock pins

Related violations: <none>

此外,在 Vivado 2018.2 中,‘report_clock_interaction’也会显示不安全的时钟对,但在 2018.3 版中不会:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_6_3.jpg&quot; alt="" width="670"></center>

‘check_timing’报告了一个在 2018.2.x 中生成的时钟的问题:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_7_2.jpg&quot; alt="" width="670"></center>

‘report_clock’报告 Vivado 为用户生成的时钟使用的实际主时钟。

虽然时钟 microblaze_0_Clk 传播至所生成时钟的源引脚,但‘report_clocks’会按照主时钟报告 pfm_top_i/static_region/slr1/base_clocking/clkwiz_pcie/inst/clk_in1:
<center><img src="http://xilinx.eetrend.com/files-eetrend-xilinx/tu_8_0.jpg&quot; alt="" width="670"></center>

Vivado 2018.2.x:
report_clocks pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q

Generated Clock : pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q

Master Source : pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/C

Master Clock : pfm_top_i/static_region/slr1/base_clocking/clkwiz_pcie/inst/clk_in1

Divide By : 8

Generated Sources : {pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q}

Vivado 2018.3:
report_clocks pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q

Generated Clock : pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q

Master Source : pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/C

Master Clock : microblaze_0_Clk

Divide By : 8

Generated Sources : {pfm_top_i/static_region/slr1/mgmt_debug_bridge/inst/axi_jtag/inst/u_jtag_proc/tck_i_reg/Q}

<strong>解决方案</strong>
该问题将在 Vivado 2018.3 中修复。

出现该问题时,通常的解决方法是在创建用户生成的时钟时指定主时钟名:
create_generated_clock -source [get_pins -filter REF_PIN_NAME=~C -of_objects [get_cells -hierarchical -filter {NAME =~ "*/u_jtag_proc/tck_i_reg*"}]] -divide_by 8 [get_pins -filter REF_PIN_NAME=~Q -of_objects [get_cells -hierarchical -filter {NAME =~ "*/u_jtag_proc/tck_i_reg*"}]] -master_clock microblaze_0_Clk

但在本示例设计中,最初的问题是没有正确配置时钟向导。

对于该设计,需要重新运行时钟向导并纠正配置。

常见问题解答:

1) 该问题会影响 Vivado 的哪些版本?

该问题会影响 Vivado 2018.2 及更早版本。

2) 如果一个设计使用 2018.2 及更早 Vivado 版本符合时序要求,那用户对时序覆盖范围应该有多大的信心?(如果他们不想升级至最新 Vivado 版本,即 2018.3)

该漏洞主要针对错误的/部分时钟定义。因此,如果设计有适当的约束,并且符合时序要求,那就不应该有问题。

要进行完整性检查,您可以运行以下命令并查找与时序相关的警告/重要警告。
<li>运行‘report_clock’命令并验证 所有主时钟(‘create_clock’约束)是否都在 I/O 端口上。</li>
<li>运行‘report_method’命令并验证在设计中是不是没有 Timing-6、Timing-27、Timing-30 和 Timing-36 警告。</li>
<li>建议使用‘master_clock’选项编辑‘generated_clock’约束。</li>

注:请参阅 (UG903) 和 (UG835),了解更多详情。

3) 在 Vivado 2018.3 中,用户是需要为生成的时钟约束使用‘master_clock’选项,还是这只是在早期 Vivado 版本中避免该问题的解决方法?

该问题已在 Vivado 2018.3 中修复。

根据 Xilinx 方法指南,始终建议为‘generated_clock’约束使用‘master_clock’选项。这个建议不仅仅只针对早期的 Vivado 版本。

4) 将设计从 Vivado 2018.2 及更早版本升级至 Vivado 2018.3 版有多安全?

该问题已在 Vivado 2018.3 中修复。

将设计从旧 Vivado 版本升级至最新的 Vivado 版本(即 2018.3)没有风险。

5) 在我的设计中有一个上述警告,但是电路板上一切正常,时序得分为 0,忽略该警告安全吗?

Xilinx 建议搞清楚警告的根本原因并正确修复。

重要通知:

Timing-6:如果该警告发生在介绍部分列出的条件下,就需要应用上述解决方法来解决该问题。