[问答]

如何正确配置抽头延迟

问答对人有帮助，内容完整，我也想知道答案 0 我阅读了UG381第71页，DS162第47页以及该主板上的各种主题，以帮助我了解如何正确配置抽头延迟。我使用Spartan 6 IODELAY2块来恒定数据总线的ODELAY，以满足下游CPU的保持时间要求; PCB是制造的，下游不能延迟信号。我现在应该提一下，我使用了一个硬宏将TFF和OFF置于IOB中，因为我使用BUFIO2为它们计时，请参阅此主题。现在我收到了这个警告：警告：PhysDesignRules：1414 - 块::上的引脚连接和/或配置问题。当DELAY_SRC不是IO编程时，不使用T输入引脚，将被忽略。因此，由于某种原因，此消息告诉我TOUT不会像DOUT一样延迟，因为TOUT延迟仅在DELAY_src = IO时可用？但是，我在这个帖子中发现了相反的信息。如果有人能为我澄清这一点，我会很感激。现在问题的核心：TRACE值已经过时了。现在我正在测试不同的ODELAY_VALUES以确定TRACE报告的实际延迟。例如，我想要1.5 ns的延迟，所以我转到DS162，查找T_TAP8 = 424 ps。很自然地，我去了： #taps =整数（1.5 ns / T_TAP8）* 8 + n（其中n =最接近1.5 ns％T_TAP8匹配的T_TAPn）我最终得到#taps = ODELAY_VALUE = 29。然而，TRACE报告了tioddo_ODATAIN = ~2.7 ns的慢角路径延迟（最大延迟）！为了得到这个，我用ODELAY_VALUE = 1测试了设计，结果是Tioddo_ODATAIN = 1.356 ns。所以（假设T_TAP1 = 16 ps）当IODELAY2被实例化时，总是添加一些1.34 ns的最小max_delay并且实际的公式将是 #taps = 1.2 ns +整数（ODELAY_VALUE / 8）* T_TAP8 + T_TAPn（n = ODELAY_VALUE rem 8）？现在我看到Tioddo_ODATAIN为0.658 ns，> 1.356 ns的30％，但在我的最终设计中保持时间计算仍然存在很大的不确定性。我想了解这些值的来源，以便优化保持时间并仍然满足设置时间和一些松弛。我知道这个问题之前出现过这个问题，然而，解决方案是报告的min_delay大约是报告的max_delay的30％，所以一切都很好。然而，没有解决这个极其庞大的max_delay。模拟产生大致ODELAY_VALUE * SIM_TAPDELAY_VALUE，因此根本没有帮助。有没有办法通过IODELAY2更准确地确定最大延迟，因为DS162中的计算似乎已经过时了？并且当DELUT_src = ODATAIN时，DOUT在延迟ODATAIN的意义上是否真的是延迟的T？提前致谢，罗伯特以上来自于谷歌翻译以下为原文 I read UG381 pp. 71, DS162 pp. 47 and various topics on this board to help me understand how to properly configure the tap delay. I resorted to using the Spartan 6 IODELAY2 blocks for constant ODELAY of a data bus to meet hold time requirements of a downstream CPU; PCB is fabbed, downstream cannot delay signals. I should mention now that I used a hard macro to place the TFF and OFF inside the IOB because I clock them using a BUFIO2, see this thread. Now I got this warning: WARNING:PhysDesignRules:1414 - Issue with pin connections and/or configuration on block:<$COMP_2.IODELAY2>:. When DELAY_SRC is not IO programming the T input pin is not used and will be ignored. So for some reason, this message tells me that TOUT won't be delayed the same as DOUT because TOUT delay is only available when DELAY_src=IO? However, I found information to the contrary in this thread. I'd appreciate it if somebody could clarify this point for me. Now to the core of the problem: The TRACE values are way off. Right now I'm testing different ODELAY_VALUES to determine the actual delay as reported by TRACE. For instance, I wanted 1.5 ns delay, so I go to DS162, look up T_TAP8 = 424 ps. So naturally, I went: #taps = integer (1.5 ns / T_TAP8) * 8 + n (where n = T_TAPn of closest 1.5 ns % T_TAP8 match) I ended up with #taps = ODELAY_VALUE = 29. However, TRACE reported then a slow corner path delay (max delay) of Tioddo_ODATAIN = ~2.7 ns! To get to the bottom of this, I tested the design with ODELAY_VALUE = 1, which results in Tioddo_ODATAIN = 1.356 ns. So (assuming T_TAP1 = 16 ps) there is some 1.34 ns minimum max_delay that is always added when IODELAY2 is instantiated and the actual formula would be #taps = 1.2 ns + integer(ODELAY_VALUE/8) * T_TAP8 + T_TAPn (n = ODELAY_VALUE rem 8)? Now I see a Tioddo_ODATAIN of 0.658 ns, which is > 30% of 1.356 ns, but still a huge uncertainty for hold time calculation in my final design. I'd like to understand where these values come from in order to optimize the hold time and still meet setup time with some slack. I understand that this issue has come up before in this thread, however, the resolution there was that the reported min_delay is roughly 30% of reported max_delay, so all is well. However, the outrageously huge max_delay was not addressed. Simulation yields roughly ODELAY_VALUE * SIM_TAPDELAY_VALUE, so that's no help at all. Is there a way to more accurately determine max delay through IODELAY2 as the calculation in DS162 seems way off? And is TOUT really the delayed T in the sense that DOUT is delayed ODATAIN when DELAY_src=ODATAIN? Thanks in advance, Robert 0
2019-7-17 08:47:54　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × asd008 该类别下有 32 个回答。邀请回答 aaaa321 该类别下有 27 个回答。邀请回答 doublelove 该类别下有 26 个回答。邀请回答 vynywrwr 该类别下有 21 个回答。邀请回答 hgjhgd 该类别下有 19 个回答。邀请回答 bwerwer 该类别下有 18 个回答。邀请回答 hanyan533 该类别下有 18 个回答。邀请回答 Jaionm 该类别下有 18 个回答。邀请回答 wang2222222 该类别下有 17 个回答。邀请回答 handsomelchcpp 该类别下有 17 个回答。邀请回答 binro 该类别下有 16 个回答。邀请回答 ningee 该类别下有 16 个回答。邀请回答 wznnzw 该类别下有 15 个回答。邀请回答 myf888 该类别下有 15 个回答。邀请回答 zcy615 该类别下有 14 个回答。邀请回答 wanglinhua2627 该类别下有 14 个回答。邀请回答 guotong1984 该类别下有 14 个回答。邀请回答 yhxc 该类别下有 14 个回答。邀请回答 armortech 该类别下有 14 个回答。邀请回答 60user25 该类别下有 14 个回答。邀请回答举报李进锋相关推荐 • CNTVALUEIN为15，DATAOUT延迟为1.3 ns是正确的吗？ 1423 • 请问步进电机抽头怎么接 2661 • 请问电感怎么抽头呢？ 2874 • 可以在REGRST发布之前断言LD吗？ 697 • 特别想知道高频变压器有的会有两个中间抽头，这两个抽头来自哪里 3241 • 如何计算以及配置正确的死区时间呢 6479 • 初级带中心抽头变压器的电压相位问题？ 6114 • 关于AD9910的数据延迟问题以及匹配延迟的使用 2454 • 在使用Vivado 2015.2.1中， FIR编译器V7.2的异常问题 1927 • Spartan IODELAY2计算的最大延迟如何预测 4909 1个回答

答案对人有帮助，有参考价值 0 -----有没有办法通过IODELAY2更准确地确定最大延迟？请参阅以下AR - 有关上述查询的一些有用信息 http://www.xilinx.com/support/answers/35783.html - > Spartan-6 - 如何计算IODELAY2分接头延迟？ http://www.xilinx.com/support/answers/37293.html - > Spartan-6，IODELAY2 - 是否需要不断校准所有接口？如果是这样，多久一次？ http://www.xilinx.com/support/answers/38408.htmlàIODELAY2; 延迟和早期边沿延迟和单数据位损坏（针对不同的掩模版本SP-6器件） _______________________________________________如果有助于解决您的查询，请将此帖子标记为“接受为解决方案”。因此，它将有助于其他论坛用户直接参考答案。如果您认为该信息有用且面向答复，请给予此帖子称赞。以上来自于谷歌翻译以下为原文 -----Is there a way to more accurately determine max delay through IODELAY2? Refer the below AR’s-- some useful information with respect to the above query http://www.xilinx.com/support/answers/35783.html --> Spartan-6 - How are the IODELAY2 tap delays calculated? http://www.xilinx.com/support/answers/37293.html --> Spartan-6, IODELAY2 - Do all interfaces need to be constantly calibrated? If so, how often? http://www.xilinx.com/support/answers/38408.html à IODELAY2; Late and Early Edge Delays and Single Data Bit Corruption (With respect to different Mask Revision SP-6 Devices) ________________________________________________ Please mark this post as an "Accept as solution" in case if it helped to resolve your query. So that it will help to other forum users to directly refer to the answer. Give kudos to this post in case if you think the information is useful and reply oriented.

2019-7-17 09:07:24 评论举报张颖