Vitex-6如何延迟dqs 3 ns

可能你可以试试tocascade IODELAYE1，但请注意，这不是一个增加I / O延迟量的推荐设置。
不推荐它的原因是IDELAY之间没有专用路径，因此这将在通用互连上路由，并且这将在PVT上变化，而IDEL不会对其进行补偿。
--Krishna



以下为原文

may be you can try to cascade IODELAYE1 but kindly note that this is not a recommended setup for increasing the amount of I/O delay. The reason that its not recommended is that there is not a dedicated path between the IDELAYs so this will be routed on general interconnect and also this will vary over PVT that will not be compensated by the IDELAY.
 
--Krishna

非常感谢你的回复。 
我试过这种方法。
但它没有用。
从第一个IODELAY1到第二个IODELAY1的数据路径的延迟时间超过3ns。
此外，它根本不稳定。 
现在，我发现DQX数据无法准确锁存的原因不是缺少延迟时间，而是DQS从IODELAYE1的输出到8个DQX端口的每个IDDR的不同数据路径延迟。
鉴于8个DQX端口被分配到各个时钟区域。（当我们设计PCB时，我们没有预料到这个问题。）我们不能使用BUFR，其时钟网只能到达现有区域和相邻区域，
平衡数据路径偏差。 
幸运的是，我们通过手动校准DQS和DQX的数据路径延迟的偏差来准确捕获DQX数据（我们可以改变DQS的抽头数和每个DQX以满足OFFSET IN时序约束）。
然而，它太复杂了，严重依赖于地方和结果的结果。
路由。 
我想知道，有没有更好的方法来平衡DQS从IODELAYE1到不同的DQX的dath路径延迟的偏差。
如果使用BUFG资源是不够的。 
你的答案非常感谢。



以下为原文

Many thanks for your reply. I have tried this method. But it didn't work.  The delay time of data path from the first IODELAY1 to the second exceeds 3ns. Furthermore, it is not stable at all.      Now, I find that the reason why the DQX data can not be latched accurately is not the lack of delay time, but the different data path delay of DQS  from the output of IODELAYE1 to each IDDR of the 8 DQX ports.  Given that the 8 DQX ports are distrubuted to various clock regions.(We had not anticipated this problem when we desined the PCB) .We can not use the BUFR,whose clock nets  can only reach to the existing region and the adjacent regions,  to balance the data path skews.     Luckily,  we have accurately  capture the DQX data by manully calibarating  the skews of  data paths delay of DQS and DQXs.( We can change the tap number of the DQS and each of DQX to meet the OFFSET IN timing contraints). However, it is too complicated, and badly dependent  on the result of  place & routing.      I was wondering, Is there a better way to balance the skew of dath path delays of DQS  from IODELAYE1 to the disparate DQXs. BUFG resource is not enough if used.      Your answers are really appreciated.

如果您发布了有关此闪存的更多信息，可能会有所帮助......（数据表和/或界面的时序图会有所帮助）。
DQS是否持续运行（与DDRx-SDRAM不同，它改变了读写之间的方向）。
如果是这样，那么一种选择是将DQS用作常规时钟并将其带到MMCM以根据需要对其进行相位偏移以对数据窗口进行采样。
另一件需要注意的事情是“芯片同步”接口的设置/保持窗口要求（使用BUFIO和IOB触发器/输入DDR触发器/ ISERDES）是不对称的;
窗户后期严重偏斜;
它实际上具有负设置时间要求和大的保持时间要求。
要查看值，请查看数据表（DS152）并查看Tpscs / Tphcs的值。
对于速度等级为-1的V6，这些是-0.28 / 1.33，这意味着“dqs”周围所需的窗口在DQS边缘后0.28ns开始，在DQS后结束1.33ns。
对于166Mb / s的边缘对齐源同步接口，“完美”窗口从0ns开始，以6.024ns结束。
根据DQS与闪存数据的偏差，您可能不需要将时钟向前移动以使这些窗口匹配。
哦等等......我刚看完你的最新回复......你的电路板就这样完成了（DQX在不同地区而不是DQS，没有备用的BUFG），你可能会干杯。
为了可靠地捕获数据，您必须使用专用时钟网络 - 即使在这些相对适中的速度下也是如此。
如果DQX和DQS不在同一个库（甚至是相邻的库）中，则不能使用BUFIO / BUFR。
如果你没有足够的BUFG，那么就不能使用BUFG。
这就是全部！
如果你不能使用这些资源，那么你就完成了。
尝试使用结构路由时钟（即不在时钟网络上的时钟）的任何解决方案都将失败。
同样，我们不了解您的系统。
我假设这些设备为每组DQX提供DQS以进行计时。
但是，DQX也与源时钟有关吗？
所有闪存芯片（或字节通道，或其他什么）都使用相同的源时钟进行计时？
这个源时钟是否可供FPGA使用？
源时钟和任何DQS引脚之间是否存在最大偏差（如果是这样，您可以在BUFG上使用一个DQS来捕获所有字节通道）。
在FPGA中找不到解决方案，因为您似乎已经从提供的所有FPGA机制中解脱出来以解决此问题。
该解决方案必须来自系统，如果没有关于闪存及其连接方式的更多信息，我们无法帮助您。
Avrum



以下为原文

It might help if you posted some more information about this flash... (A data sheet and/or timing diagram of the interface would help).
 
Is the DQS continuously running (unlike DDRx-SDRAM, where it changes directions between read and write). If so, then one option is to use the DQS as a regular clock and bring it to an MMCM to phase offset it as required to sample the data window.
 
Another thing to realize is that the setup/hold window requirement of a "chip sync" interface (using the BUFIO and IOB flip-flops/input DDR flops/ISERDES) is not symmetric; the window is significantly skewed late; it actually has a negative setup time requirement and a large hold time requirement. To see the values, look at the datasheet (DS152) and look at the values for Tpscs/Tphcs. For a V6 with a -1 speed grade, these are -0.28/1.33, which means the required window around your "dqs" starts 0.28ns after the edge of DQS and ends 1.33ns after your DQS. For an edge aligned source syncronous interface at  166Mb/s, the "perfect" window starts at 0ns and ends at 6.024ns. Depending on the skew from DQS to data of your flash, you may not need to shift your clock that far forward to make these windows match.
 
Oh wait... I just read your latest reply... With your board done this way (with the DQX in different regions than the DQS and no spare BUFGs), you may well be toast. To capture data reliably you have to use a dedicated clock network - even at these relatively moderate speeds. If the DQX and the DQS aren't in the same bank (or even adjacent banks) then you can't use the BUFIO/BUFR. If you don't have enough BUFGs, then you can't use BUFGs. That's all there is! If you can't use these resources, then you are done. Any solution that tries to use fabric routed clocks (i.e. clocks not on a clock network) will fail.
 
Again, we don't understand your system. I presume these devices provide a DQS with each bunch of DQX for timing. But, are the DQX also related to the source clock? Are all flash chips (or byte lanes, or whatever) clocked using the same source clock? Is this source clock available to the FPGA? Is there a maximum skew between the source clock and any of the DQS pins (if so, maybe you can use one DQS on a BUFG to capture all byte lanes).
 
The solution to this is not going to be found in the FPGA, since you seem to have cut yourself off from all the provided FPGA mechanisms for solving this problem. The solution will have to come from the system, and without lots more information about the flash and how its connected, we can't help you.
 
Avrum