TIG导致设置时间错误地被忽略

嗨，
假设正确定义了TIMESPEC，则TIG将仅位于设计的路径3中
仅限数据路径关键字仅分析建立/保持检查，并且不会考虑时钟偏差或相位。
--Hem
--------------------------------------------------
--------------------------------------------请注意 - 请注明
如果提供的信息有用，请回答“接受为解决方案”。给予您认为有用并回复导向的帖子。感谢K--
--------------------------------------------------
---------------------



以下为原文

Hi,
 
Assuming that the TIMESPEC's are properly defined, the TIG will only be in the path 3 of the design
 
Datapath only keyword will only analyze the setup/hold check and it will not take clock skew or phase into consideration.
 
--Hem
----------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------

一些额外的评论：
1）如果你的两个时钟不相关，即只要工具知道没有相位关系，那么你就不需要TIG，因为无论如何都不会分析路径3。
如果两个时钟可以追溯到FPGA的相同输入引脚，则工具只知道相位关系。
2）DATAPATHONLY意味着时钟路径被忽略，因此实际上“setup”或“hold”没有实际意义。
然而，将检查路径3的数据支持延迟，包括驱动触发器的Q时钟和接收触发器的输入设置时间。
在这种情况下使用FROM：TO约束可能很有用，例如，如果您有多个这样的数据路径并且想要约束它们，那么数据路径的延迟差异不能大于某个固定数量的时钟周期（通常是一个）。
再次没有分析延迟差异，但是它显然不能大于最大允许延迟，因为绝对路径延迟（不相对于时钟）不能小于零。
3）即使您有TIG约束，某些版本的工具仍会检查保持时间。
同样，这只适用于相关时钟。
如果您认为这些时钟是异步的，那么您最好使用FROM：TO ... DATAPATHONLY约束样式，因为它会阻止保持时间分析。
如果您真的不在乎数据路径中有多少延迟，您可以将延迟设置为大的延迟以防止设计过度约束。
-  Gabor



以下为原文

Some additional comments:
 
1) If your two clocks are not related, i.e. as far as the tools know there is no phase relationship, then you don't need the TIG because path 3 won't be analyzed anyway.  The tools only know about the phase relationship if the two clocks can be traced back to the same input pin of the FPGA.
 
2) DATAPATHONLY means that the clock paths are ignored, so in effect there is no real meaning for "setup" or "hold."  However the path 3 will be checked for data prop delay including the clock to Q of the driving flip-flop and the input setup time of the receiving flip-flop.  Using a FROM : TO constraint in this instance may be useful if for example you have multiple such data paths and want to constrain them so that the data paths cannot have delay differences greater than some fixed number of clock cycles (usually one).  Again the delay difference is not analyzed, but it obviously cannot be greater than the maximum allowed delay because the absolute path delay (not relative to clocks) cannot be less than zero.
 
3) Some versions of the tools will still check for hold timing even if you have a TIG constraint.  Again this would only be for related clocks.  If you consider these clocks to be asynchronous, then you're better off with the FROM : TO ... DATAPATHONLY style of constraint, since it will prevent hold time analysis.  If you really don't care how much delay is in the data path you can set the delay to something large to prevent overconstraining the design.
-- Gabor

这两个时钟是异步的。
谢谢Hem清理哪条路径被忽略了。
的Gabor，
我没有抓住时间问题，但很多公共汽车正在越过边界，所以我喜欢事实，我可以限制它们之间的最大延迟。
你指出最大延迟应该是一个时钟周期，它是接收时钟周期还是发送器时钟周期？
我也不确定如何根据发送时钟和接收时钟的频率来计算最大延迟。
我问这个问题因为，我使用自定义构建的fifo在两个域之间传递数据，我看到我的一个数据没有出现在输出中。
在模拟过程中，我发现发生这种情况的唯一情况是输入数据是否违反了接收触发器的设置时间。
显然该工具并未表明存在任何设置时间问题。
阿米什



以下为原文

The two clocks are asynchronous.
 
Thanks Hem for clearing up which path is ignored.
 
Gabor,
I have not been having hold time issues but many buses are going across the boundary so I do like to fact that I can constraint the max delay between them.
 
 you indicated that the max delay should be one clock cycle, would it be the receiving clock cycle or sender clock cycle? I am nor sure how to compute the max delay based on the freq of sending clock and receiving clock.
 
 
I am asking this question because, I am using a custom built fifo to pass data between the two domain and I am seeing one of my data not appearing at the output. During simulation, I found that the only scenario for that to happen is if the incoming data violated setup time for the receiving flip flop. Obviously the tool does not indicate there is any setup time issues.
 
Amish

通常我会使用接收时钟作为计时指南。
我们的想法是，您不希望信号之间的偏差累加到多个接收时钟周期，或者您可能会遇到类似（接收）时钟上多个格雷码位发生变化的问题。
这可能会破坏FIFO中的标志逻辑。
在没有任何其他标准的情况下，我还想简单地选择尽可能短的数据延迟值，但仍然很容易满足。
如果这恰好比发送或接收时钟少，那就更好了。
直接约束信号偏斜会很好，但保持总延迟低是最小化偏斜的最佳方法，至少在ISE工具中是这样。
-  Gabor



以下为原文

Normally I'd use the receiving clock as the guide for timing.  The idea is that you don't want the skew between signals to add up to multiple receiving clock cycles or you could have issues like more than one Gray code bit changing on the same (receiving) clock.  That could mess up flag logic in a FIFO.  In the absence of any other criteria, I also like to simply choose a value for the data delay that is as short as possible, but still easy to meet.  If this happens to be less that either the transmitting or receiving clock, then so much the better.  It would be nice to directly constrain the signal skew, but keeping the total delay low is the best way to minimize skew, at least in the ISE tools.
-- Gabor