ISE14.4时序分析器获取时钟相位延迟该怎么办？

只是为了确认Timing Analyzer是错误的，它还报告了2 nSec的建立时间要求，其中正确的数字是4 nSec。



以下为原文

Just to confirm that the Timing Analyser is in error it is also reporting a setup time requirement of 2 nSec where the correct figure is 4 nSec.

你说时钟是差分的，但你谈论它们的方式听起来就像是你把每个信号用作单端。
通常情况下，我希望每个时钟对进入IBUFGDS并将其输出到BUFG。
那么你只有两个全局时钟，你可以在BUFG后根据需要使用任一边。
或者，您可以将每个时钟对驱动到IBUFGDS_DIFFOUT，但此时我认为只有IBUFGDS_DIFFOUT缓冲区的正端具有到BUFG的快速路由资源。
您是否查看过路由问题的报告？
-  Gabor



以下为原文

You say the clocks are differential, but the way you talk about them it sounds like you are using each signal as single-ended.  Normally I would expect each clock pair to go into an IBUFGDS and the output of that to a BUFG.  Then you would only have two global clocks and you could use either edge as required after the BUFG.  Alternately you can drive each clock pair into an IBUFGDS_DIFFOUT, but at that point I think only the positive side of the IBUFGDS_DIFFOUT buffer has a fast routing resource to a BUFG.  Have you looked at the reports for routing issues?
-- Gabor

嗨Gabor，
我想，我已经对你的帖子做了回复，但是在检查时它似乎没有进入系统，所以这里是它的要点
1）重新报告
a）在地图或P＆amp; R报告中看不到任何与此处涉及的四个时钟网络有任何问题的报告。
b）时钟报告显示通过BUFGMUX连接的所有四个时钟，据我所知，这意味着它们必须使用全局时钟网络。
时钟报告还显示这些网络的最大延迟从1.733 nS到1.753nS不等，但我对Spartan 6部分的经验不足以了解这些是否是全球时钟网的合理数据？
2）输入逻辑是通过使用Coregen生成一个块来接收来自外部ADC的250 MHz差分时钟和7个DDR输入的输入而创建的。
这些ADC中有两个在具有共源的时钟上运行，但它们之间的相移为半个周期。
这种相移的重要意义在于，它意味着在FPGA引脚处，一个ADC的差分输入的“P”侧应该与另一个ADC的“N”侧具有几乎相同的时间。在时钟中存在时序约束。
.ucf文件来匹配这个。这个块有两个实例，每个ADC一个，
3）这两个输入模块中的时钟路径由IBUFGDS_DIFF_OUT whosediff输出馈送两个IODELAY2设置为固定延迟0.（数据输入也将IODELAY2设置为固定0延迟）。
IODELAY2的两个输出馈送两个BUFG，它们的输出驱动一系列IDDR2的时钟输入，对7个数据输入进行反序列化，提供14个并行数据输出。
ADC＃2上的IDDR2已设置为其输出被注册到其“N”时钟的上升沿。
4）为准备在Block RAM中存储，ADC＃2的14个并行数据输出必须在ADC＃1'P'时钟的上升沿重新计时。
由于这应该与ADC＃2的'N'时钟同相（+/-一些小偏斜），我认为对此的设置时间要求应该是4 nS，但这是Timing Analyser报告设置出错的地方
定时异常，因为它认为所需的建立时间仅为2 nS。
5）时序分析器还报告了大约7 nS的两个时钟的延迟，与时钟报告相比，这似乎过高。
#Robert



以下为原文

Hi Gabor,
 
I had, I thought, entered a reply to your posting, but on checking it doesn't seem to have got onto the system so here is the gist of it again
 
1) Re Reports
a) Can't see anything in map or P&R reports to suggest any issues with the four clock nets involved here.
b) The clock report shows all four clocks connecting via BUFGMUXs which, I understand, means that they have to use the global clock networks. The clock report also shows max delays on these nets varying from 1.733 nS to 1.753nS but I don't have enough experience with Spartan 6 parts yet to know if these are reasonable figures for global clock nets?
 
2) The input logic was created by using Coregen to generate a block to accept inputs of a 250 MHz differential clock and seven DDR inputs from an external ADC. There are two of these ADCs running on clocks with a common source but with a phase-shift between them of one half cycle. The significant implication of this phase-shift is that it means that at the FPGA pins the 'P' side of the diff input of one ADC should have virtually identical times to the 'N' side of the other. There are timing constraints in the .ucf file to match this.There are two instances of this block, one for each ADC,
 
3) The clock paths in these two input blocks consists of a IBUFGDS_DIFF_OUT whose diff outputs feed two IODELAY2 set to a fixed delay of 0. (the data inputs also have IODELAY2s set to fixed 0 delay). The two outputs of the IODELAY2s feed two BUFGs and their outputs drive the clock inputs of a series of IDDR2 which deserialise the seven data inputs giving 14 parallel data outputs. The IDDR2 on ADC#2 is set up so that its outputs are registered to rising edges of its 'N' clock.
 
4) In preparation for storage in block RAM, the 14 parallel data outputs of ADC#2 must be re-clocked with the rising edge of ADC#1 'P' clock. Since this should be in phase with the 'N' clock of ADC#2 (+/- some small skew), I think that the setup time requirement for this should be 4 nS but this is where things go wrong with Timing Analyser reporting a setup timing exception because it thinks that the required setup time is only 2 nS.
 
5) The Timing Analyser is also reporting delays on both clocks of around 7 nS which seems excessively high when compared to the Clock report.
 
# Robert
 
 

一些想法：
1）为什么你通过IDELAY2以固定延迟0运行一切？
您是否打算根据需要最终修剪这些？
或者他们只是在那里因为IO向导将它们放在那里？
我认为在这个频率上实际上可能会使IDELAY2元素更糟糕，因为它们的“零”延迟仍然很大并且可能增加了输入时序的不确定性。
2）似乎使用IBUFGDS_DIFF_OUT并制作两个时钟可能只是一个资源浪费，除非你的意图是最终独立地修正正边和负边​​。
如果ADC时钟输出被很好地调节，我认为你最好只使用IBUFGDS来制作一个时钟并使用它的两个边缘用于IDDR2。
3）你说两个时钟实际上排在P到N之间，但是我会对这两个时钟域之间的保持时间问题保持警惕，特别是考虑到时钟网络增加的不确定性。
从理论上讲，工具应检查这一点，但它们只能与您提供的信息一样好。
即，如果一个时钟的P边缘相对于另一个时钟的N边缘有一些抖动或不确定性，则需要将这些信息提供给工具以便进行适当的检查。
否则，您最好将时钟视为同步（频率但不锁相），并使用浅FIFO等跨越时钟域的方式。
至于为什么工具使用2 ns而不是4 ns用于交叉，如果你发布时序报告（.twx文件），我可能会有更多的见解，但是有人认为IDDR2实际上没有将其输出对齐到
你认为它是时钟。
您可以在行为模拟中轻松检查这一点。
您可能还想首先仔细检查这些IDDR2上的DDR_ALIGNMENT属性，根据哪个时钟输入连接到N侧时钟，应将其设置为“C0”或“C1”。
默认的alignmnet是“NONE”，在这种情况下，一半信号将正确排列，另一半信号将关闭2 ns。
在任何情况下，假设你修复了这个，所以工具看到正确的4 ns路径而不是2ns，我的猜测是你将开始看到保持时间问题而不是设置时间。
-  Gabor



以下为原文

Some thoughts:
 
1) Why are you running everything through IDELAY2 with fixed delay of 0?  Is it your intention to eventually trim these as required?  Or are they just in there because the IO wizard placed them there?  I would think that at this frequency it may actually make things worse to add the IDELAY2 elements because their "zero" delay is still significant and probably adds to uncertainty in input timing.
 
2) It seems that using IBUFGDS_DIFF_OUT and making two clocks is probably just a wast of resources unless your intent was to eventually trim positive and negative edges independently.  If the ADC clock output is well regulated, I would think you would be better off just using an IBUFGDS to make a single clock and use both edges of that for the IDDR2s.
 
3) You say the two clocks are virtually lined up P to N, however I would be a bit wary of hold time issues crossing between these two clock domains , especially given the uncertainty added by the clocking networks.  Theoretically the tools should check for this, but they are only as good as the information you give them.  i.e. if the P edge of one clock has some jitter or uncertainty with respect to the N edge of the other clock, you need to supply that information to the tools in order to get proper checking.  Otherwise you would be better off treating the clocks as mesochronous (frequency but not phase locked) and use something like a shallow FIFO to cross the clock domains.
 
As to why the tools are using 2 ns instead of 4 ns for the crossing, I would probably have more insight if you post the timing report (.twx file), however one thought is that the IDDR2 is not actually aligning its outputs to the clock you think it is.  You could easily check this in a behavioral simulation.  You might also want to start by double checking the DDR_ALIGNMENT attribute on these IDDR2s, which should be set to either "C0" or "C1" depending on which clock input connects to your N side clock.  The default alignmnet is "NONE" in which case half of the signals would line up correctly and the other half would be 2 ns off.
 
In any case, assuming you fix this so the tools see the correct 4 ns path instead of 2ns, my guess is that you will start to see hold time issues instead of setup time.
-- Gabor

嗨Gabor，
1）是的，最终我希望至少需要调整时钟延迟，以避免强化ADC芯片。
2）重新使用IBUFGDS_DIFF_OUT等我到目前为止认为，如果Coregen采用这种方法，那么它有很好的架构原因。
如果要将其更改为使用一个时钟的两个边沿，那么由于IDDR2仅在上升沿上工作，因此需要生成具有平衡，低延迟的时钟的真正反转版本。
我想DCM会是一个很好的方法。
3）附加twx文件。
如果有更多的东西会有所帮助，例如源代码等，那么我很乐意提供，只是不想把它全部丢弃给你。
4）我已多次检查IDDR2设置，但会再次检查。
模拟是一个很好的建议;
到目前为止，我一直认为这可能是一个简单的错误，它可以更容易/更快地找到解决方案。
5）FIFO  - 我会看看这个。
5）你知道1.7SS是否合理，因为Spartan 6中全球时钟网的最大延迟 - 对我来说似乎相当大？
数据表DS162仅讨论了大约0.25 nS的“全局时钟树偏斜”，但没有定义“偏斜”的含义。
由于某种原因，该网站阻止我直接加载twx文件，所以我通过添加“.txt”重命名它。
#Robert
PM30_v4_FPGA_top.twx.txt 780 KB



以下为原文

Hi Gabor,
 
1) Yes, eventually I expect to need to adjust at least the clock delays to allow for timings of the ADC chips.
 
2) Re Use of IBUFGDS_DIFF_OUT etc. I've assumed up to now that if Coregen took this approach there were good architectural reasons for it. If it was to be changed to use both edges of one clock, then since the IDDR2s operate on rising edges only,it would be necessary to produce a true and inverted version of the clock with balanced, low delays. I guess a DCM would be a good way to do this.
 
3) The twx files is attached. If anything more would help, eg source code etc then I'm happy to provide, just didn't want to dump it all on you.
 
4) I have checked the IDDR2 settings several times, but will check again. Simulation is a good suggestion; I have been putting it off up to now on the assumption that it was probably down to a simple mistake which would have an easier/quicker route to a solution.
 
5) FIFOs - I'll have a look at this.
 
5) Do you know if 1.7nS is reasonable as a max delay on a global clock net in Spartan 6 - seems quite large to me? Data sheet DS162 only talks about something called "Global Clock Tree Skew" of around 0.25 nS but doesn't define what is meant by "skew".
 
For some reason the website is preventing me loading the twx file directly so I've renamed it by adding ".txt".
 
# Robert
            PM30_v4_FPGA_top.twx.txt ‏780 KB

HiGabor，
我说你还在看这个，应该说我似乎已经幸运地进行了各种修复;
通过重新设置我所做的时序约束，时间分析器给出正确的4 nSec所需的设置时间。
但是，我仍然认为时序分析器工作方式有问题，因为如果我将DDR从“C0”更改为“C1”，它将/应该将其注册输出移动2 nSec，那么它仍然会提供所需的设置时间
在4 nSec。
两者当然都不对。
无论如何，在此基础上我认为我们可以关闭这个话题。
谢谢你的帮助。
#Robert



以下为原文

HiGabor,
I case you're still looking at this, should say that I seem to have lucked into a fix of sorts; by re-jigging the timing constraints I've made Timing Analyser give correct required setup time of 4 nSec. However,I still think there is something wrong with the way that Timing Analyser is working because if I change the DDR from "C0" to "C1" which  will/should shift its registered outputs by 2 nSec then it still gives the required setup time at 4 nSec. Both can't be right of course.
 
Anyway on that basis I think we can close this topic. Thanks for your help.
 
#Robert