如何设置从相同输入源时钟导出的不同时钟域之间的错误路径？

INST“clk_module_inst / serdes_dcm_inst / CLKDV_BUFG_INST”TNM_NET =“TCLK_GRP”; INST“clk_module_inst / sdr_dcm_inst / CLKFX_BUFG_INST”TNM_NET =“CORECLK_GRP”;
这看起来对我很怀疑。
我以为TNM_NET想申请网，而不是实例。
我通常用BUFG的输出网写这些，看起来像：
NET“ser_clk”TNM_NET =“TCLK_GRP”;
NET“core_clk”TNM_NET =“CORECLK_GRP”;
请注意，您可能需要弄清楚时钟的已翻译名称，尽管看起来这是时序报告中使用的名称，所以我猜它出现在层次结构的顶层。
TIMESPEC“TSfalse”=从“TCLK_GRP”到“CORECLK_GRP”TIG; TIMESPEC“TSfalse”=从“CORECLK_GRP”到“TCLK_GRP”TIG;
我认为时序约束需要有不同的名称，否则第二个约束可能会覆盖第一个约束。
尝试：
TIMESPEC“TSfalse_T2C”=从“TCLK_GRP”到“CORECLK_GRP”TIG; TIMESPEC“TSfalse_C2T”=从“CORECLK_GRP”到“TCLK_GRP”TIG;
-  Gabor
在原帖中查看解决方案



以下为原文

INST "clk_module_inst/serdes_dcm_inst/CLKDV_BUFG_INST" TNM_NET=  "TCLK_GRP";
INST "clk_module_inst/sdr_dcm_inst/CLKFX_BUFG_INST" TNM_NET=  "CORECLK_GRP";
 
This looks suspect to me.  I thought TNM_NET wants to apply to a net, not an instance.  I normally write these using the output net of the BUFG which might look like:
 
NET "ser_clk" TNM_NET=  "TCLK_GRP";
NET "core_clk" TNM_NET=  "CORECLK_GRP";
 
Note that you may need to figure out the translated name of the clock, although it looks like this is the name used in the timing report, so I'm guessing it appears at the top level of the hierarchy.
 
TIMESPEC "TSfalse" = FROM "TCLK_GRP" TO "CORECLK_GRP" TIG;
TIMESPEC "TSfalse" = FROM "CORECLK_GRP" TO "TCLK_GRP" TIG;
 
I think timing constraints need to have separate names, otherwise the second constraint probably overrides the first.  Try:
 
TIMESPEC "TSfalse_T2C" = FROM "TCLK_GRP" TO "CORECLK_GRP" TIG;
TIMESPEC "TSfalse_C2T" = FROM "CORECLK_GRP" TO "TCLK_GRP" TIG;
 
 
-- GaborView solution in original post

嗨，TIMESPEC“TSfalse”= FROM“TS_serclk”到“TS_coreclk”TIG;这个TS_serclk和TS_coreclk是如何定义的？约束失败是什么意思？
你是说还在分析cdc路径吗？
与其他约束相比，TIG约束具有更高的优先级。
因此，即使相同的路径受到周期约束和tig约束的约束，tig也会优先，并且不会分析路径。
确保TNM_ NET约束中给出的时钟输出网络名称是正确的（打开合成设计并检查时钟网络名称）。谢谢，Deepika。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）



以下为原文

Hi,

TIMESPEC "TSfalse" = FROM "TS_serclk" TO "TS_coreclk" TIG;

How is this TS_serclk and TS_coreclk defined?

What do you mean by constraints fail? Do you mean that the cdc paths are still getting analysed? The TIG constraint has higher priority when compared to other constraints. So, even if the same path is constrained by period constraint and tig constraint, tig will take priority and paths will not be analyzed. Ensure that the clock output net names given in the TNM_ NET constraints are correct( open synthesized design and check for the clock net names).

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)

如果你告诉我们你正在使用什么版本的工具会有所帮助。
我已经看到了FROM：TO约束中的TIG不会导致时序分析器忽略保持时间的问题。
然而，显然在地点和路线上并非如此。
因此，在最后的位置和路线完成得分为0，然后发布P＆amp; R静态时序分析显示跨时域路径上的大量保持错误。
我发现如果我将这些TIG约束更改为以纳秒为单位的最大时间，并添加DATAPATHONLY关键字，则会修复此行为。
就像是：
TIMESPEC“TSfalse”=从“TS_serclk”到“TS_coreclk”20 ns DATAPATHONLY;
顺便说一下，这是一种单向约束。
即，它不包括从TS_coreclk时间组开始并以TS_serclk时间组结束的路径。
对于那些您需要添加的路径：
TIMESPEC“TSfalse2”=从“TS_coreclk”到“TS_serclk”20 ns DATAPATHONLY;
在这些示例中，20 ns并不重要。
使用任何容易满足的数字。
-  Gabor



以下为原文

It would help if you tell us what version of tools you're using.  I've seen issues where a TIG in a FROM : TO constraint does not cause the timing analyzer to ignore hold times.  Apparently this is not the case during place&route, however.  So in the end place&route completes with a score of 0, and then post P&R static timing analysis shows lots of hold errors on cross-clock-domain paths.  I've found that if I change these TIG constraints to a maximum time in nanoseconds, and add the DATAPATHONLY keyword, it fixes this behavior.  Something like:
 
TIMESPEC "TSfalse" = FROM "TS_serclk" TO "TS_coreclk" 20 ns DATAPATHONLY;
 
By the way, this is a one-way constraint.  i.e. it does not cover paths starting in the TS_coreclk time group and ending in the TS_serclk time group.  For those paths you'd need to add:
 
TIMESPEC "TSfalse2" = FROM "TS_coreclk" TO "TS_serclk" 20 ns DATAPATHONLY;
 
In these examples, 20 ns is not important.  Use any number that's easy to meet.
-- Gabor

你好
我假设您正在使用DCM / MMCM来获取查看时序报告的时钟。
如果是，以排除这些派生时钟的跨时钟域路径，请参阅http://www.xilinx.com/support/answers/34348.htm
--HS
--------------------------------------------------
--------------------------------------------请注意 - 请注明
如果提供的信息有用，请回答“接受为解决方案”。给予您认为有用并回复导向的帖子。感谢K--
--------------------------------------------------
---------------------



以下为原文

Hi
 
I assume that you are using DCM/MMCM to derive the clocks looking at your timing report.
 
If yes to exclude cross-clock domain paths for these derived clocks refer to http://www.xilinx.com/support/answers/34348.htm
 
--HS
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

所以，有几件事......
您不应该将.twr文件中的“约束”复制到.ucf文件中 - 很多报告都使用过时的约束格式。
其次，您不需要约束clkB和clkC  - 这些约束是从clkA约束自动生成的。
你可以通过查看ngdbuild日志文件（.bld）来看看这是由ngdbuild完成的。
所以你不应该有“约束2”。
您显示的用于定义clkB_GRP和clkC_GRP的约束看起来是正确的（约束1），但是 
- 我会取出'FFS' - 这只是限制组只包含触发器而不是所有时钟元素 
- 不会包括像块RAM，DSP和分布式RAM这样的东西，但如果clkB和clkC真的是异步的，那么它们应该是约束的一部分 
- 我无法验证网名是否正确 
- 第一个看起来合理（看起来像DCM的CLKDV输出） 
- 第二个看起来不太合理，从下面不应该是clk_module_inst_sdr_dcm_inst_CLKFX180_BUF
接下来，为什么要声明这些域之间的路径是假的？
如果它们之间没有任何路径，那么您不需要约束。
如果它们之间有路径，那么您有两个选择 
a）让工具将它们视为同步路径。
两个时钟分别为75ns和18ns，移位为9ns。
我没有做过完整的分析，但认为这最终会在边缘之间产生3ns的分离 
- 如果这两个时钟通过相同的缓冲区，则应该可以在3ns内在两个域之间同步交叉 
- 在这种情况下，不需要例外 
b）将时钟视为异步，并在它们之间放置时钟交叉电路。 
- 根据时钟交叉电路的构建方式，TIG可能不是正确的例外 - 带有DATAPATH_ONLY的FROM TO可能更合适（正如其他人所建议的那样）。
最后，我不认为你可以在时间规格之间做一个FROM TO，其他一些人已经提出过。
他们需要在团体之间完成。
所以在clkB_GRP和clkC_GRP之间，而不是在TS_clkB和TS_clkC之间。
Avrum



以下为原文

So, a couple of things...
 
You shouldn't copy "constraints" from the .twr file into your .ucf file - a lot of the reports use archaic formats of constraints.
 
Second, you don't need to constrain clkB and clkC - these constraints are generated automatically from the constraint on clkA. You can see this being done by ngdbuild by looking at the ngdbuild log file (.bld). So you shouldn't have "constraint 2".
 
The constraints you show for definging clkB_GRP and clkC_GRP look correct (constraint 1), but
  - I would take out the 'FFS' - this just restricts the group to contain only flip-flops instead of all clocked elements
    - things like block RAMs, DSPs and distributed RAMs will not be included, but if clkB and clkC are really asynchronous, then they should be part of the constraints
  - I can't verify if the net names are correct
    - the first one looks reasonable (it looks like the CLKDV output of the DCM)
    - the second one doesn't really look reasonable, from below shouldn't it be  clk_module_inst_sdr_dcm_inst_CLKFX180_BUF
 
Next, why do you want to declare the paths between these domains false? If there aren't any paths between them, then you don't need a constraint. If there are paths between them, then you have two choices
  a) let the tools treat them as synchronous paths. The two clocks are 75ns and 18ns with a 9ns shift. I haven't done a complete analysis, but think this ends up with 3ns separations between the edges
    - if these two clocks go through the same buffers, it should be possible to cross synchronously between the two domains in 3ns
    - in this case, no exception is required
  b) treat the clocks as asynchronous, and put a clock crossing circuit between them.
    - depending on how the clock crossing circuit is built, a TIG may not be the right exception - the FROM TO with DATAPATH_ONLY might be a more appropriate one (as others have suggested).
 
Finally, I don't think you can do a FROM TO between timespecs, which some of the others have suggested. They need to be done between groups. So between clkB_GRPand clkC_GRP, not between TS_clkB and TS_clkC.
 
Avrum

感谢大家的帮助！
someclarification
我的设计工具：synthesis-> synplifypro 9.6.2;
ISE13.2
为了简化描述，我使用clkB，clkC而不是serdes ser_clk，它来自serdes_dcm_inst，大约13M。
来自sdr_dcm_instis core_clk的另一个派生时钟，大约是50M。
由于我的逻辑处理了这两个时钟域之间的逻辑，我只需要声明之间的路径为false路径。
否则会报告太多时钟错误。
我试过下面的约束，它可以运行没有语法错误，但时间错误仍然在两个域之间。
INST“clk_module_inst / serdes_dcm_inst / CLKDV_BUFG_INST”TNM_NET =“TCLK_GRP”; INST“clk_module_inst / sdr_dcm_inst / CLKFX_BUFG_INST”TNM_NET =“CORECLK_GRP”;
NET“clk_module_inst / sdr_dcm_inst / C0_IN”TNM_NET =“CORECLK_GRP”; TIMESPEC“TSfalse”=从“TCLK_GRP”到“CORECLK_GRP”TIG; TIMESPEC“TSfalse”=从“CORECLK_GRP”到“TCLK_GRP”TIG;
上面的约束不起作用，一些twr报告如下，
==================================================
==============================时间约束：TS_serclk = PERIOD TIMEGRP“serclk”TS_ifclk * 2.5 HIGH 50％;
分析了7387个路径，分析了1126个端点，214个故障端点214检测到定时错误。
（214个设置错误，0个保持错误，0个组件切换限制错误）最小周期为282.800ns .-----------------------------
--------------------------------------------------
-
终点路径serdes_tx_inst / tx_mux_inst / tx_state_ret（SLICE_X12Y11.F4），57路径---------------------------------
----------------------------------------------- Slack（设置
路径）： -  8.312ns（要求 - （数据路径 - 时钟路径偏差+不确定性））来源：reg_module_inst / inkjet_pktcode_ret_1（FF）目的地：serdes_tx_inst / tx_mux_inst / tx_state_ret（FF）要求：3.000ns数据路径延迟：6.599ns（级别）
of Logic = 4）（仅限组件延迟超出约束）时钟路径偏移：-4.713ns（-1.734  -  2.979）源时钟：core_clk在72.000ns上升目标时钟：ser_clk在75.000ns上升时钟不确定度：0.000ns
相关逻辑如下
BUFG CLKFX_BUFG_INST（.I（CLKFX_BUF）,. O（C0_IN））;
BUFG CLKDV_BUFG_INST（.I（CLKDV_BUF）,. O（CLKDV_OUT））;
我试过下面的约束，它报告“未找到NET”，
NET“clk_module_inst / serdes_dcm_inst / CLKDV_OUT”TNM_NET =“TCLK_GRP”; NET“clk_module_inst / sdr_dcm_inst / C0_IN”TNM_NET =“CORECLK_GRP”;
那么我应该如何描述约束呢？
谢谢，
加斯



以下为原文

Thank you all for your help!
 
some clarification
my design tools: synthesis->synplifypro 9.6.2 ; ISE13.2
to simplify description, I used clkB, clkC instead of the serdes ser_clk, which is derived from serdes_dcm_inst, about 13M.
another derived clock from sdr_dcm_inst is core_clk, which is about 50M.
 
as my logic has handled the logic between these two clock domain, I only need to declare the paths between as false path.
otherwise too many clock error would report.
 
I tried below constraint, it could run without syntax error, but the timing errors remains between the two domain.
 
INST "clk_module_inst/serdes_dcm_inst/CLKDV_BUFG_INST" TNM_NET=  "TCLK_GRP";
INST "clk_module_inst/sdr_dcm_inst/CLKFX_BUFG_INST" TNM_NET=  "CORECLK_GRP";
 
NET "clk_module_inst/sdr_dcm_inst/C0_IN" TNM_NET=  "CORECLK_GRP";
TIMESPEC "TSfalse" = FROM "TCLK_GRP" TO "CORECLK_GRP" TIG;
TIMESPEC "TSfalse" = FROM "CORECLK_GRP" TO "TCLK_GRP" TIG;
 
the constraint above doesn't work, some twr report as below,
================================================================================
Timing constraint: TS_serclk = PERIOD TIMEGRP "serclk" TS_ifclk * 2.5 HIGH 50%;
 7387 paths analyzed, 1126 endpoints analyzed, 214 failing endpoints
 214 timing errors detected. (214 setup errors, 0 hold errors, 0 component switching limit errors)
 Minimum period is 282.800ns.
--------------------------------------------------------------------------------
Paths for end point serdes_tx_inst/tx_mux_inst/tx_state_ret (SLICE_X12Y11.F4), 57 paths
--------------------------------------------------------------------------------
Slack (setup path):     -8.312ns (requirement - (data path - clock path skew + uncertainty))
  Source:               reg_module_inst/inkjet_pktcode_ret_1 (FF)
  Destination:          serdes_tx_inst/tx_mux_inst/tx_state_ret (FF)
  Requirement:          3.000ns
  Data Path Delay:      6.599ns (Levels of Logic = 4)(Component delays alone exceeds constraint)
  Clock Path Skew:      -4.713ns (-1.734 - 2.979)
  Source Clock:         core_clk rising at 72.000ns
  Destination Clock:    ser_clk rising at 75.000ns
  Clock Uncertainty:    0.000ns
 
the related logic as below
BUFG  CLKFX_BUFG_INST (.I(CLKFX_BUF),  .O(C0_IN));
BUFG  CLKDV_BUFG_INST (.I(CLKDV_BUF),  .O(CLKDV_OUT)); 
I've tried below constraint, it report "NET not found",
NET "clk_module_inst/serdes_dcm_inst/CLKDV_OUT" TNM_NET=  "TCLK_GRP";
NET "clk_module_inst/sdr_dcm_inst/C0_IN" TNM_NET=  "CORECLK_GRP";
 
then how should I describe the constraint?
 
Thanks,
Gauz

INST“clk_module_inst / serdes_dcm_inst / CLKDV_BUFG_INST”TNM_NET =“TCLK_GRP”; INST“clk_module_inst / sdr_dcm_inst / CLKFX_BUFG_INST”TNM_NET =“CORECLK_GRP”;
这看起来对我很怀疑。
我以为TNM_NET想申请网，而不是实例。
我通常用BUFG的输出网写这些，看起来像：
NET“ser_clk”TNM_NET =“TCLK_GRP”;
NET“core_clk”TNM_NET =“CORECLK_GRP”;
请注意，您可能需要弄清楚时钟的已翻译名称，尽管看起来这是时序报告中使用的名称，所以我猜它出现在层次结构的顶层。
TIMESPEC“TSfalse”=从“TCLK_GRP”到“CORECLK_GRP”TIG; TIMESPEC“TSfalse”=从“CORECLK_GRP”到“TCLK_GRP”TIG;
我认为时序约束需要有不同的名称，否则第二个约束可能会覆盖第一个约束。
尝试：
TIMESPEC“TSfalse_T2C”=从“TCLK_GRP”到“CORECLK_GRP”TIG; TIMESPEC“TSfalse_C2T”=从“CORECLK_GRP”到“TCLK_GRP”TIG;
-  Gabor



以下为原文

INST "clk_module_inst/serdes_dcm_inst/CLKDV_BUFG_INST" TNM_NET=  "TCLK_GRP";
INST "clk_module_inst/sdr_dcm_inst/CLKFX_BUFG_INST" TNM_NET=  "CORECLK_GRP";
 
This looks suspect to me.  I thought TNM_NET wants to apply to a net, not an instance.  I normally write these using the output net of the BUFG which might look like:
 
NET "ser_clk" TNM_NET=  "TCLK_GRP";
NET "core_clk" TNM_NET=  "CORECLK_GRP";
 
Note that you may need to figure out the translated name of the clock, although it looks like this is the name used in the timing report, so I'm guessing it appears at the top level of the hierarchy.
 
TIMESPEC "TSfalse" = FROM "TCLK_GRP" TO "CORECLK_GRP" TIG;
TIMESPEC "TSfalse" = FROM "CORECLK_GRP" TO "TCLK_GRP" TIG;
 
I think timing constraints need to have separate names, otherwise the second constraint probably overrides the first.  Try:
 
TIMESPEC "TSfalse_T2C" = FROM "TCLK_GRP" TO "CORECLK_GRP" TIG;
TIMESPEC "TSfalse_C2T" = FROM "CORECLK_GRP" TO "TCLK_GRP" TIG;
 
 
-- Gabor

完全同意Gabor。
检查.BLD（翻译报告），当您在TNM_NET约束中使用INST时，将显示如下所示的消息
ConstraintSystem：134  -  Constraint [test.ucf（6）]：在块“CLKDV_BUFG”（type = BUFG）下找不到TNM约束的适当实例。
您需要使用NET名称创建TNM_NET组。
您可以通过打开综合设计并选择显示网络名称的BUFG输出来找到这些网络名称。
附件是一个简单的测试用例，展示了如何应用TIG。
谢谢，
迪皮卡。
谢谢，迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题，请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子，考虑给它Kudos（左边的明星）
dcm_test1.zip 8293 KB



以下为原文

Completely agreed with Gabor. Check .BLD (translate report) which will have messages like below when you use INST in TNM_NET constraint
 
ConstraintSystem:134 - Constraint [test.ucf(6)]: No appropriate instances for the TNM constraint were found under block "CLKDV_BUFG" (type=BUFG).
 
You need to create TNM_NET groups using NET names. You can find these net names by opening synthesized design and selecting the output of BUFG which shows the net name. 
 
Attached is a simple test case which shows how to apply TIG.
 
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)            dcm_test1.zip ‏8293 KB

谢谢大家，没关系！
NET“ser_clk”TNM_NET =“TCLK_GRP”; NET“core_clk”TNM_NET =“CORECLK_GRP”;
工作，我想知道的是为什么下面的线不起作用，
NET“clk_module_inst / sdr_dcm_inst / C0_IN”TNM_NET =“CORECLK_GRP”;
synplify原理图信号是我列出的，如下所示
再次感谢您的帮助。
加斯



以下为原文

Thank you all, it's ok!
 
NET "ser_clk" TNM_NET=  "TCLK_GRP";
NET "core_clk" TNM_NET=  "CORECLK_GRP";
 
works, what I want to know is why below line doesn't work,
NET "clk_module_inst/sdr_dcm_inst/C0_IN" TNM_NET=  "CORECLK_GRP";
 
the synplify schematic signal is what I listed, shown below
 

 
 
Thanks again for all your helps.
Gauz

您可能想要检查TNM_NET上的传播规则。
TNM可能在这种情况下有效。
我知道TNM_NET不会通过输入或输出缓冲区传播，也许它也不会通过全局时钟缓冲区传播。
在TNM_NET约束中使用全局缓冲时钟而不是时钟缓冲器的输入是正常的。
[编辑]哎呀。
我只是注意到信号是在BUFG之后，但在缓冲之前，当然会被优化掉。
因此，将不会显示所示的网络，因为它将重新命名，因为它连接到层次结构顶层的模块端口。
请记住，翻译的网表对于任何给定的网络只有一个名称。
-  Gabor



以下为原文

You might want to check the propagation rules on TNM_NET.  It's possible that TNM might have worked in this case.  I know that TNM_NET does not propagate through input or output buffers, and perhaps it also does not propagate through global clock buffers.  It is normal to use the globally buffered clock in the TNM_NET constraint rather than the input to the clock buffer.
 
[Edit]  Oops.  I just noticed that the signal is after the BUFG, but before a buffer, which would of course be optimised away.  Thus there will be no net named as shown since it will be re-named as it connects to the module port on the top level of hierarchy.  Remember that the translated netlist will have only one name for any given net.
-- Gabor

嗨Gabor，这是我的错，我应该采用synplify技术视图而不是rtl视图。
是的，BUFG输出网络C0_IN已经重命名为core_clk.Sorry以便无忧无虑。
谢谢，加斯



以下为原文

Hi Gabor,

It's my fault, I should take synplify technology view rather than rtl view.
Yes, the BUFG output net C0_IN has been renamed to core_clk.

Sorry for the carenlessness.

Thanks,
Gauz