如何解决ILogic Clock Net上的偏差过大问题？

请为时钟偏差过大的路径发布详细的时序报告。
如果时钟真的在BUFG上（并且所有负载都由BUFG驱动），则应该不可能在接近该高点时出现偏斜。
Avrum



以下为原文

Please post a detailed timing report for a path that has excessive clock skew.
 
If the clock is really on a BUFG (and all loads are driven by the BUFG), then it should be impossible to get skews anywhere near that high.
 
Avrum

嗨Avrum，
不想用文件轰炸你，但附加的是最近版本的twx文件加上两个vhdl文件，其中包含创建相关时钟网的相关代码。
重新检查twx文件，如果查看TS_ADC1_Clk_N的时序数据，尤其是保持时间，您将看到在计算时钟路径偏差时使用的最多8.nSec的延迟。
因此，您可以检查是否需要，我还附加了两个vhdl文件，其中包含用于生成相关时钟的所有代码（物理引脚除外）。
关于设计的一些说法可能有所帮助：它旨在接受来自在公共时钟上运行的两个14位250 MSPS ADC的数据，并将其保存在Block RAM中。
用于承载所有这些的FPGA时钟取自两个ADC之一，在本设计中，由三个BUFG缓冲在模块Dual_Fast_ADCs.vhd中，一个用于此模块中的代码，一个用于两个实例
ADC代码。
这个带有三个时钟网络的版本是为了查看时钟延迟是否是时钟负载过多的结果而生成的，有一个更简单的版本只有一个公共时钟和一个BUFG，其中时钟延迟实际上略低，
范围2到5 nSec但仍然比我预期的要大得多。
感谢帮助
问候
罗伯特
Dual_Fast_ADCs.vhd 31 KB
Fast_ADC_Single_Ch_Interface.vhd 21 KB
PM30_v4_FPGA_top.twx 795 KB



以下为原文

Hi Avrum,
 
Don't want to bombard you with files, but attached are the twx file for a recent version plus two vhdl files containing the relevant code that creates the clock net in question.
 
Re the twx file, if you look at the timing data for TS_ADC1_Clk_N, especially for Hold times, you will see delays of up to 8.nSec used in the calculation of clock path skew.
 
So you can check if you want, I've also attached the two two vhdl files which contain all the code (other than the physical pins) for generating the clocks in question. A few words about the design may help : it is intended to accept data from two 14 bits 250 MSPS ADCs running on a common clock and save it in block RAM. The FPGA clock used to carry all this out is taken from one of the two ADCs and in this design, is buffered in the module Dual_Fast_ADCs.vhd by three BUFGs, one for the code in this module, one each for the two instances of the ADC code.
 
This version with three clock nets was generated in an attempt to see if the clock delays were the result of excessive clock loads, there is an earlier version which just has a single common clock with one BUFG in which the clock delays are actually slightly lower, in the range 2 to 5 nSec but still much larger than I would expect.
 
Thanks for help
 
Regards
 
Robert
 
 
 
            Dual_Fast_ADCs.vhd ‏31 KB                Fast_ADC_Single_Ch_Interface.vhd ‏21 KB                PM30_v4_FPGA_top.twx ‏795 KB

在坚果壳中，你的计时结构似乎没有任何意义。
您正尝试使用BUFIO2驱动IDDR，但之后尝试使用通过BUFG的时钟捕获结果数据。
这两个时钟不同步 - 它们之间存在巨大的偏差，并且传输不起作用。
对于IDDR，IDDR的时钟和接收IDDR输出的触发器的时钟必须在同一时钟网络上 - 并且必须是BUFG。
我不确定你为什么认为你需要使用BUFIO2，或BUFIO2给你带来什么好处，但你不能这样使用它...
Avrum



以下为原文

In a nut shell, your clocking structure doesn't seem to make any sense.
 
You are trying to drive the IDDR using a BUFIO2, but are then trying to capture the resulting data using a clock that goes through a BUFG. These two clocks are not in phase - there is huge skew between them, and that transfer won't work.
 
For an IDDR, the clock of the IDDR and the clock of the flip-flops that are receiving the output of the IDDR must be on the same clock network - and that has to be the BUFG. I am not sure why you think that you need to use the BUFIO2, or what advantage the BUFIO2 gives you, but you cannot use it this way...
 
Avrum

嗨Avrum，
关于时钟的公平评论，但我的借口是设计的数据，时钟输入和DDR部分是由Coregen创建的，它选择使用BUFIO2s;
我认为这个选择有很好的理由，所以不管它。
我被骗以为这不是主要问题，因为BUFG时钟报告的延迟在目的地之间差异很大。
无论如何，我把它改成了一个共同的BUFG来驱动一个时钟网;
该设计实现了时序收敛，现在网络上的时钟延迟大大减少，最大约为0.5nSec，所以感谢您的意见和帮助。
罗伯特



以下为原文

Hi Avrum,
 
Fair comment about the clocking,  but my excuse is that the data, clock input and DDR part of the design was created by Coregen which chose to use BUFIO2s; I assumed that it had good reasons for this choice so left it alone. I was fooled into thinking this was not the main issue because the delays reported on the BUFG clock varied substantially between destinations.
 
Anyway, I've changed it all to a single common BUFG driving a single clock net; the design achieves timing closure and the clock delays on this net are now greatly reduced, to a max of about 0.5nSec so thank you for your comments and help.
 
Robert