请问最坏的情况松弛和最佳案例可实现不匹配跟什么有关？

你能发布clk2的最坏情况路径吗？
首先要解释的是差异。
也许两个不​​同的数字属于内部时钟和时钟间时序。
检查时钟交互。
- 如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。



以下为原文

can you post the worst case path for clk2? First thing would be to explain the difference. Maybe the two different numbers belong to intra vs inter clock timings. Check for clock interaction.
- 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）clk2使用正边缘和负边缘，并且松弛处于从一个边缘到另一个边缘的路径上。
2）clk2驱动PLL，MMCM或DCM，然后产生其他频率。
松弛在下游时钟之一上，并且与导出的时序约束相反。
然后，导出约束的最佳频率乘以PLL，MMCM或DCM中的频率比。
-  Gabor



以下为原文

Some possibilities:
 
1) clk2 uses both positive and negative edges, and the slack is on a path going from one edge to another.
 
2) clk2 drives a PLL, MMCM or DCM that in turn generates other frequencies.  The slack is on one of the downstream clocks and is against a derived timing constraint.  Then the best frequency for the derived constraint gets multiplied up by the frequency ratio in the PLL, MMCM or DCM.
-- Gabor

嗨gabor，
是的......你对理由＃1是正确的。
clk2正在使用上升沿和下降沿（我只是看着代码并注意到了这一点）
我猜下一个问题是如何限制这样的路径？
在有关模块中发生的是 -
数据/控制信号输入@ 150MHz（6.66ns），即clk2。
它们在clk2的上升沿和下降沿被计时。
然后在clk2的上升边缘进一步发出。
对于这样一个模块/设计的限制是什么，因为我现在只是把时间段放在一边。
clk2上一条失败路径的示例时序报告 -
Slack（设置路径）：-1.983ns（要求 - （数据路径 - 时钟路径偏差+不确定性））来源：rgmii_2_gmii / gmii_rxd_d0_neg [7]（FF）目的地：NTN_FPGA_TOP / NTN_TOP / emac_wrp / ip_toplevel / rxd_d [3]（FF
）要求：3.330ns数据路径延迟：5.355ns（逻辑电平= 2）时钟路径偏移：0.077ns（1.965  -  1.888）源时钟：clk2_c下降至3.330ns目标时钟：clk2_c上升至6.660ns时钟不确定度：0.035ns



以下为原文

hi gabor,
 
yes ... you are correct about reason #1. clk2 is using both rising and falling edge (i was just looking at the code and noticed this)
 
i guess the next question is how to constraint such a path? 
 
whats happening in the module in question is that - 
data/control signals come in @ 150MHz (6.66ns),  which is clk2.
they are clocked at  the rising and falling edge of clk2.
And  then sent out further at just the rising edgeof clk2.
 
what would be the  constraint for such a module/design as i am just putting the period consrtaint for now.?
 
example timing report  for one failing path on clk2 -
Slack (setup path): -1.983ns (requirement - (data path - clock path skew + uncertainty))
Source: rgmii_2_gmii/gmii_rxd_d0_neg[7] (FF)
Destination: NTN_FPGA_TOP/NTN_TOP/emac_wrp/ip_toplevel/rxd_d[3] (FF)
Requirement: 3.330ns
Data Path Delay: 5.355ns (Levels of Logic = 2)
Clock Path Skew: 0.077ns (1.965 - 1.888)
Source Clock: clk2_c falling at 3.330ns
Destination Clock: clk2_c rising at 6.660ns
Clock Uncertainty: 0.035ns
 

时钟的周期是已知的，工具可以从时钟周期的上升沿到下降沿的时间是您的条件所需的全部（如果您有50％的占空比;如果没有，则需要定义下降沿的位置
）。
显然，只有上升沿到上升沿才能报告最佳时序，因此在这种情况下不适用。
- 如果提供的信息有用，请将答案标记为“接受为解决方案”。给予您认为有用且回复的帖子。



以下为原文

The period of the clock is known and the tool can time from rising edge to falling edge so the clock period is all you need for your condition (if you have a 50% duty cycle; if not, you need to define where the falling edge is). Apparently best possible timing is reported only for rising edge to rising edge so it's not applicable in this case. 
- 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.

喜
是的，我的期限约为50％。
那么我应该把它放进去并与失败的道路一起生活吗？
或者我可以添加任何其他约束吗？
是否有一些约束告诉工具对于特定模块，将时钟视为双边和约束或PAR是相应的？
ž。



以下为原文

hi,
 
yes, i have the period constrained as 50%.
 
so should i just leave that in and live with the failing paths? or is there any other constraint i can add?
is there some constraint that tells the tool that for a particular module, consider the clock as dual edged and constrain or PAR is accordingly?
 
z.

不可以。除非它们不是真正的单时钟路径或者可以异步处理，否则你不能“忍受失败的路径”。
您需要修复这些路径。
从您发布的路径中，您在从一个时钟边缘到另一个时钟边缘的路径中有2个逻辑级别。
如果这不是假路径，则应考虑将逻辑移动到一个时钟边沿域或另一个时钟边缘域，而不是跨时钟边沿路径。
-  Gabor



以下为原文

No.  You can't "live with the failing paths" unless they are not really single-clock paths or can be treated asynchronously.  You need to fix these paths.  From the path you posted, you have 2 levels of logic in a path going from one clock edge to another.  If this is not a false path, you should consider moving the logic to exist in one clock-edge domain or the other, rather than in the cross-clock-edge path.
-- Gabor

嗨gabor，谢谢。
所以我只是简单地说你所说的 - 我猜你的意思是逻辑应该只是上升沿时钟或下降沿为时钟路径故障被移除。
这将带来逻辑上的变化。
根据你所说的，我的理解是否正确？
如果是，那么我面临的问题是逻辑无法改变，因为这是芯片的RTL。
所以有了这个限制，我有哪些其他选择？
我已经在SmartXplorer中尝试了xilinx多个位置和路由，我发布的路径是16次运行时间改进策略的最佳结果。
那么可以应用任何其他约束吗？
还有其他的尝试吗？
ž。



以下为原文

hi gabor, thanks.
 
so i simplyfy what you said - i guess you mean the logic should be only rising edge clocked or falling edge clocked  for the path failure to be removed. and this would entail a logic change. is my understanding correct based on what you said?
 
if yes, then the constaint i am facing is that the logic cannot be changed because this is RTL for a chip.
 
so with that restriction, what are the other options I have?
 
I have already tried xilinx multiple place and route in SmartXplorer and the path i posted is the best result from 16 runs with timing improvement strategy.
 
so any other constraint that can be applied? any other things to try?
 
z.

而且 - 看着路径，我看到rgmii_rxd_d [0]是源，但目的地是rgmii_rxd_d [3]。
所以我在想为什么从位d [0]到位d [3]的路径失败？
这是一条失败之路的特征吗？
ž。



以下为原文

and also - looking at the path, i see that the rgmii_rxd_d[0] is the source but the destination is rgmii_rxd_d[3].
 
so im thinking why is the path from bit d[0] to bit d[3] failing? is this the characteristics of a failing path?
 
z.