如何将PLL / BUFPLL保留在我的项目中

你好！
我有一个关于UG382.pdf中建议的方案功能的问题（例如图1-38）以及着名的XAP1064文档，其中PLL_ADV与BUFPLL一起用于为SERDES原语生成SERDESTROBE信号。
和
我在我的解串器项目中重复了这种方法。
一切都在行为模拟上运行良好，但后置放和路由模拟揭示了一个重大缺陷。
问题在于：1）PLL和BUFPLL的GCLK引脚之间的路由长度的差异，以及2）BUFPLL的PLL和PLLIN引脚。
在我的情况下，路由差异大约为1.57 ns，这使得BUFPLL生成SERDESSTROBE信号太晚，因此反序列化的数据在错误的时刻被选通（位滑动对此没有帮助）。
作为检查这个长度差异是否是问题的唯一原因的方法，我在PLL-> PLLIN引脚的路上插入了另一个BUFG缓冲区（以均衡这两个路径）。
是的，这有效！
但是，我不能在最终设计中使用这种方法，因为BUFG在最大值时运行。
375 MHz，而我希望内部使用更高的频率。
我有一个问题针对已经处理过用PLL和BUFPLL缓冲区反序列化数据的人（XAPP1064应用笔记的图4）：如何将PLL / BUFPLL保留在我的项目中（驱动Spartan的整个边缘 -
欢迎使用6），保持使用频率高于375 MHz的能力，但删除此路由问题。
对时序约束指南的检查表明，限制这两个内部信号（没有输入或输出引脚）通常不是常用的。
根据线程中的建议，我希望避免基于手动（或非常复杂）路由策略的解决方案。
同时我还没有看到如何使用时钟使能概念来避免我的项目中的2个时钟。
建议是最受欢迎的。
最好的祝福
帕维尔



以下为原文

Hello!

I have a question regarding the functioning of the scheme suggested both in UG382.pdf (e.g. on Fig. 1-38) and also in the famous XAP1064 document where PLL_ADV has been used together with BUFPLL to generate SERDESTROBE signal for the SERDES primitive.

  and

I repeated exactly this approach in my deserializer project. Everything works fine on the Behavioural simulation, but the Post Placement and Routing simulation revealed a major flaw. The problem lies in the differece in the length of the routes between: 1) the PLL and the GCLK pin of the BUFPLL, and 2) the PLL and the PLLIN pin of the BUFPLL.

In my case thi routing difference is around 1.57 ns, which makes the BUFPLL generate the SERDESSTROBE signal too late, and as a result the deserialized data are strobed at wrong moments (bit-slipping does not help this). As a way to check if this length difference is the only cause of the problem I inserted another  BUFG buffer on the way PLL->PLLIN pin (to equalize the two paths). Yes this worked! However, I cannot use this approach in the final design, as BUFG operates at max. 375 MHz, whereas I expect to be using higher frequencies internally.

I have a question aimed at people who have already dealt with deserializing data with the PLL and BUFPLL buffer (Fig. 4 of the XAPP1064 app note): how do I keep the PLL/BUFPLL in my project (driving the whole edge of Spartan-6 will be welcome), keep the ability to work with frequencies higher than 375 MHz, but remove this routing problem.

A check on the timing constraints guide suggest that constraining such two internal signals (none has input or output pins) is not something used typically. Following the advice in the thread <http://forums.xilinx.com/t5/Virtex-Family-FPGAs/the-phase-relationship-of-PLL-clock-outputs/td-p/125360> I would like avoid solutions based on manual (or very complex) routing strategies. On the same time I do not quite see how I can use the clock enable concept to avoid 2 clocks in my project.

Suggestions are most welcome.

Best regards

Pawel