JESD204 v5.2约束使用生成的dcp构建逻辑计时失败

嗨，
JESD IP的时钟约束在_ooc.xdc中定义。
此XDC文件将仅在脱离上下文流程中读取。
以下是此文件中的相同行。
＃此约束文件包含在上下文流程中使用的默认时钟频率，例如＃OOC Synthesis和Hierarchical Designs。
为获得最佳效果，应修改频率＃以匹配目标频率。
＃此约束文件未在正常的自上而下合成中使用（Vivado的默认流程）
因此，此约束文件不会用于顶级综合或实现。
这些约束仅用于指导OOC运行。
在您的情况下，我看到您在顶级模块的综合属性中设置了-mode out_of_context。
这实际上是在脱离上下文模式下运行顶级综合。
在此流程中，该工具也在顶级综合中读取IP的_ooc.xdc。
当我在顶级综合设置中删除-mode out_of_context并且在顶级XDCjesd204_8tx_4rx_support_tim.xdc文件中只有以下约束时，我发现内核中的同步元素也受限于此顶级XDC中提到的值。
create_clock -period 4.0 -name gbtclk [get_ports refclk_p]
＃将Tx和Rx设备时钟设置为250MHzcreate_clock -period 4.0 -name txclk [get_ports txclk_p] create_clock -period 4.0 -name rxclk [get_ports rxclk_p]
如果要在OOC模式下运行顶级综合，则可以禁用IP XDC文件_ooc.xdc并在顶层定义这些时钟。
谢谢，
迪皮卡。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）
在原帖中查看解决方案



以下为原文

Hi,
 
The clock constraint of JESD IP are defined in _ooc.xdc. This XDC file will be read in out of context flow alone. Below are the lines from this file which say the same.
 
# This constraints file contains default clock frequencies to be used during out-of-context flows such as # OOC Synthesis and Hierarchical Designs. For best results the frequencies should be modified # to match the target frequencies. # This constraints file is not used in normal top-down synthesis (the default flow of Vivado)
 
So this constraint file will not be used in top level synthesis or implementation. These constraints are only used to direct OOC run.
 
In your case I see that you had set -mode out_of_context in synthesis properties for top level module. This actually runs top level synthesis in out of context mode. During this flow the tool is reading the _ooc.xdc of IP in the top level synthesis too.
 
When I removed -mode out_of_context in top level synthesis settings and had only the below constraints in top XDC jesd204_8tx_4rx_support_tim.xdc file, I see that the sync elements inside the cores are also constrained to the values mentioned in this top XDC.
 
create_clock -period 4.0 -name gbtclk [get_ports refclk_p]
# Set Tx and Rx Device Clocks to 250MHz
create_clock -period 4.0 -name txclk [get_ports txclk_p]
create_clock -period 4.0 -name rxclk [get_ports rxclk_p]
 
If you want to run top level synthesis in OOC mode then you can disable the IP XDC file _ooc.xdc and define these clocks at top level.
 
Thanks,
Deepika.
 
 
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)View solution in original post

嗨Shant，
您可以更改XDC文件的处理顺序，以使顶级约束覆盖IP约束。
查看这篇文章http://www.xilinx.com/support/answers/52947.html
检查这是否有帮助。
谢谢，
迪皮卡。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）



以下为原文

Hi Shant,
 
 
You can change the processing order of XDC files to make top level constraint overwrite IP constraints. Check this article http://www.xilinx.com/support/answers/52947.html
 
Check if this helps.
 
Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

嗨Deepika，
感谢您的快速回复。
我添加了一个带有时序覆盖约束的xdc（create_clock -period 4 [get_pins inst_jesd204_8l_tx / tx_core_clk]），将其PROCESSING_ORDER设置为LATE，然后重建dcp.dcp内置约束覆盖工作并且如时钟网络报告中所报告的那样tx_core_clk
在inst_jesd204_8l_tx内核实例中设置为250MHz而不是默认的156.25MHz。
问题是更新的时序约束仅适用于inst_jesd204_8l_tx级别的逻辑（即约束仅向下传播）。
在顶层逻辑级别，在“support”模块中，tx_core_clk也用于为i_gtwizard_top模块提供时钟。
由时钟计时的路径在时钟网络报告中显示为不受约束。 
约束顶级时钟（create_clock -period 4 -name tx_core_clk_bufg [get_pins i_shared_clocks / inst_bufg_txclk / O]），然后重建dcp并检查时钟报告，使该工具认为有两个不同的时钟，tx_core_clk和inst_jesd204_8l_tx / tx_core_clk。
这两个域之间的路径交叉失败。
任何建议如何进行？
提前致谢，
Shant



以下为原文

Hi Deepika,
 
Thanks for the prompt reply. I added an xdc with the timing override constraints (create_clock -period 4 [get_pins inst_jesd204_8l_tx/tx_core_clk]), set its PROCESSING_ORDER to LATE, then rebuilt the dcp. The dcp built-in constraints overriding worked and as reported in the clock network report the tx_core_clk within the inst_jesd204_8l_tx core instance was set to 250MHz as opposed to the default 156.25MHz.
 
The problem is the updated timing constraint applies only to logic at the inst_jesd204_8l_tx level (i.e the constraints propagate downwards only). At the top logic level, in the "support" module, the tx_core_clk is also used to clock the i_gtwizard_top module. Paths clocked by this clock showed up as unconstrained in the clock network report.
 
Constraining the top level clock (create_clock -period 4 -name tx_core_clk_bufg [get_pins i_shared_clocks/inst_bufg_txclk/O]) and then rebuilding the dcp and checking the clock report, makes the tool think there are two different clocks, tx_core_clk and inst_jesd204_8l_tx/tx_core_clk. Paths crossing between these two domains fail timing. Any recommendation how to proceed?
 
Thanks in advance,
Shant

嗨Shant，您可以尝试在主端口（顶级端口）上进行时钟处理吗？
不要在bufg输出或jesd核心输入上定义时钟。检查工具是否能够传播这个顶级时钟。同样当你从引脚指定时钟约束时，在你的情况下说bufg输出，工具将不会考虑bufg之前的路径延迟
计算，因此建议在主端口上定义时钟。如果要重命名或覆盖工具，请在mmcm输出上自动生成约束，使用create_generated_clock约束。谢谢，Deepika。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）



以下为原文

Hi Shant,

Can you try deifing the clock on the primary port(top level port)? Donot define the clock on bufg output or jesd core input.

Check if the tool is able to propagate this top level clock.

Also when you specify clock constraint from pins say bufg output in your case the tool will not consider the path before bufg in delay calculation, hence it is recommended to define the clocks on primary ports.

In case if you want to rename or override the tool auto generated constraints on mmcm outputs use create_generated_clock constraint.

Thanks,
Deepika.Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)