完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
嗨，
我们有一个非常紧凑的Virtex7，看到相当多的时钟偏差。 在几个方面，我读过PLL可以用来弥补时钟偏差，但没有找到如何做到这一点的策略或实例。 任何人都可以提供可能的策略指针吗？ 谢谢， /麦克风 
0
|
|
相关推荐
24个回答
|
|
|
pll消除了由输入时钟相对于整个时钟树延迟引入的偏斜（偏斜校正）（或者更好地表示时钟树的特定点）。
当它们“到达”连续的元素时，它不能去除时钟树的各个时钟端点。 换句话说，PLL不能通过行进到芯片上的不同点来消除由时钟树引入的偏斜，例如， 在远处附近。 因此，或许可以对您的设计进行布局规划，使关键组件更紧密地放在一起 |
|
|
|
|
|
将PLL的功能描述为能够消除时钟插入延迟可能更有用。
虽然该过程通常被称为时钟偏移，但它仅修复时钟的相位，使得端点处的时钟相位与时钟输入引脚处的时钟相位相似。 时钟偏移与时钟插入延迟不同 - PLL无法做任何事情来影响时钟偏移。 这样想吧...... 时钟到达一个引脚。 从那里它需要散播到数十万个人字拖鞋。 为此，需要包含缓冲区，活动互连和大量路由的庞大网络。 Xilinx预先设计了这个时钟网络（全球时钟网络），以便时钟在“接近同一时间”达到数十万个端点。 但是，有些端点会很快到达，其他端点则会更快到达。 通常，所有端点的时间可以定义为（insertion_delay +/- clock_skew / 2）。 PLL可以补偿插入延迟（通过添加（CLK_PERIOD - insertion_delay）的有效延迟，但它无法对偏斜做任何事情 - 范围仍将具有spanof（clock_skew）。 Avrum |
|
|
|
|
|
嗨，我同意Ralfk。但我想你是在问如何使用PLL实现偏移。只需提供PLL输入并根据需要配置PLL。
默认情况下，deskew将被照顾。 不需要任何特殊设置来实现偏移机制。谢谢，Yash |
|
|
|
|
|
谢谢你的承诺和全面的答案！
我理解这一切，这就是我提出这个问题的原因。许多文档都可以避免因为插入延迟而导致混淆，而不是像他们那样倾斜。 所以，我回到正方形，并且现在探索一些非正统的想法。 我可能会想到这里的火焰，但试试这个尺寸; 1）使用PLL和移位阶段稍微负一点以平衡设置违规（这是我现在得到的）和保持时间违规。 2）从clocktree下方的点获取反馈给PLL做同样的事情。 我只是试过2），它似乎工作。第十/地方/路线干净，所有的中提琴都在那个区域消失。我没有_not_use专用.CLKFBOUT（从我收集的，.CLKFBOUT只是另一个端口了 来自PLL），而是实际的时钟信号，在BUFG放置在该区域的门附近之后。 问题是，谁是谁在愚弄谁。 我是在愚弄Xilinx时序分析，还是我在欺骗逻辑来进行看不见的事情？ /麦克风 |
|
|
|
|
|
你想解决什么问题？
如果您遇到从内部触发器到内部触发器的偏斜问题，那么PLL无法帮助您（至少是合理的）。 PLL可以向前或向后移动其输出时钟，但这将使所有触发器的到达时间完全相同，因此不会影响FF到FF路径上的任何设置或保持分析。 如果您在输入或输出接口上遇到问题（即在FPGA的输入引脚捕获数据），那么是 - 调整PLL或MMCM的相位以将时钟置于数据眼中间是正常的 在输入接口上。 至于CLKFBIN端口，必须将其连接到CLKFBOUT端口。 有两种法律配置 - 直接（它们之间没有缓冲区） - 如果您不关心时钟的插入延迟，请执行此操作 - 即仅当没有与此时钟关联的输入接口或系统同步输出接口时 - 它们之间有一个时钟缓冲区。 当您在它们之间使用时钟缓冲区时，您有两种输入/输出接口选择 - 使用CLKFBOUT端口上的时钟缓冲器输出接口接口（向导不执行此操作，但这是合法的） - 在CLKOUT0（或MMCM / PLL的其他CLKOUT端口）上使用相同的缓冲器并使用它来为接口提供时钟 - 如果您不使用相同的缓冲区，您的时钟插入将被不正确地取消，并且您的接口会出现时序问题 Avrum |
|
|
|
|
|
实际上，迈克有一点意见。
CLKFBOUT端口/计数器基本上与任何其他时钟输出一样。 因此，您可以使用另一个CLKOUT输出进行反馈。 有一些“问题”：反馈频率必须与PFD的CLKIN频率匹配。 反馈时钟的任何正相移将负向移相所有其他输出时钟。 话虽如此，在反馈路径中简单地使用BUFG来驱动逻辑可能更容易。 这假设你有一个ZHOLD配置（不是外部或内部或bufin），因此BUFG（或某些情况下BUFH或BUFR）在反馈路径中。 我没有得到你想要说的“从时钟树中获取反馈路径”。 除非您设法通过互连将本地路由作为反馈，否则反馈路径将从时钟区域的远端进行硬编码（简化说明）。 正如Avrum所说，如果你只是在数据在芯片上时处理偏斜，那么相移时钟对你没有任何好处。 |
|
|
|
|
|
感谢所有的反馈，非常感谢！
@avrumw，我们试图解决的问题是由于宽和深数据路径与相当拥挤的FPGA相结合而造成的时钟偏差。 我们正在使用SerDes和时钟路径相当长，所以hece myidea调整时钟相位稍微负一点以增加松弛。 我们没有看到任何保留时间违规，所以我认为有空间做到这一点。 增加问题的是与BRAM一起使用的宽路径，它在芯片的大面积上扩展了时钟路径。 我打算将时钟相位_relatve_调整为来自SerDes的数据，以允许更多的松弛（用于时序收敛）。 在实际驱动所有FF的BUFG之后路由反馈的想法是基于这样的假设：高扇出BUFG将使信号延迟超过光负载（如Xilinx文档中所建议的），即由于更高的容量负载导致的上升时间 会影响时间。 如果我在这个假设中错了，请纠正我。 @ralfk，谢谢，我意识到输入/输出频率必须相同。 我所做的（并且认为实际上工作）是将BUFG置于使用时钟的逻辑附近，然后在接近所述逻辑的BUFG之后驱动PLL反馈。 它看起来像这样（我希望我的糟糕解释是有道理的）： SerDes / CLKRX - > PLL / CLKOUT0 - > [wireto anothter时钟区域] - > BUFG - >（此路径上的许多FF） - > [回送到SerDes / PLLclock区域] - > PLL / CLKFBIN。 我不太明白你的配置是什么意思，你能开导我吗？ /麦克风 |
|
|
|
|
|
迈克，我认为通过重新阅读Avrum的帖子，你将获得最佳服务。
您不能使用PLL来调整FPGA不同区域之间的偏移。 另请注意，BUFG都位于FPGA的中心或附近，因此您无法将BUFG放置在某些逻辑附近，最多可以在找到所有BUFG的中心位置附近移动一些逻辑。 ZHOLD是补偿模式之一。 有关完整说明，请参阅UG472。 这是一个快速的： ZHOLD：表示MMCM配置为在I / O寄存器中提供负数时间。 EXTERNAL：表示正在补偿FPGA的networkexternal。 INTERNAL：表示MMCMis使用自己的内部反馈路径，因此不会补偿延迟。 BUF_IN：表示配置与其他补偿模式不匹配，不会补偿延迟。 如果时钟输入由BUFG / BUFH / BUFR或GTX / GTH / GTP驱动，则属于这种情况。 在SerDes之后无需延迟时钟：如果满足SerDes的设置和保持，则从SerDes输出的并行位与SerDes的输出时钟同步，就像翻转的Q输出一样。 触发器与驱动触发器的时钟同步。 如果SerDes并行数据锁定周期很短 - 比如说小于3 ns - 并且SerDes正在驱动一些接近的逻辑和一些远离FPGA的逻辑，那么就会延迟时钟以修复逻辑的设置问题 很远的地方只会对接近的逻辑产生保持问题。在这种情况下，最好分割数据流，这样就不需要在FPGA上长距离传输数据而不需要通过中间寄存器进行重新计时。 如果您要发布特定的时间违规，我们可以进一步发表评论。 丹尼尔 |
|
|
|
|
|
我同意丹尼尔的意见！
我们无法准确了解您的问题所在。 如果您遇到特定的时序违规（例如高速收发器的输出数据中的设置失败），那么让我们谈谈这个问题以及修复它的传统方法。 搞砸时钟通常不是解决时间错误的方法。 一些具体的事情...... FPGA时钟不是ASIC时钟。 它们不像ASIC那样“依赖于负载”; FPGA中的全局时钟网络已预先路由，可以跨越整个FPGA，并在一大堆连接点上进行主动缓冲。 因此，时钟树上的延迟不会随着端点数量的增加而变大; 由于负载与负载之间存在一些差异，因此偏差可能会增加（因此，如果您碰巧使用连接到BUFG的最短路径和BUFG的最快路线的FF，那么您将获得最大的偏斜报告），但是 整体延迟不会有太大变化。 所以你不能通过改变BUFG的负载来延迟时钟。 此外，您无法更改PLL连接到全局网络的方式。 正如我所说，全球网络已经预先路由。 这包括从全局域到PLL / MMCM的CLKFBIN的预接线连接（根据您的设计，可能使用也可能不使用）。 但是，对于给定的时钟网络，只有一个这样的连接 - 你无法控制它。 如果你确实需要调整时钟的相位（并且看起来这不是一个应该考虑它的应用程序），那么你可以使用MMCM（而不是PLL）的相移功能。 与PLL一样，您可以调整相位，增量为VCO周期的1/8。 如果您使用MMCM，您可以使用精细移相器，并降至VCO周期的1/56增量。 接下来，GTF / GTH数据由您的BUFG计时。 使用GTX / GTH时，为GTX / GTH提供一个RXUSRCLK，它应该是一个缓冲时钟（通过BUFH或BUFG），为GTX / GTH的接收（并行）数据以及用户提供时钟 捕获此数据的逻辑。 改变BUFG / BUFH的输出时钟的时序将没有任何区别，除非你给它们不同的时钟（你真的不应该这样做）。 Avrum |
|
|
|
|
|
Daniel，Avrum＆amp; co，
非常感谢所有澄清，我从中学到了很多东西。我们现在回到楼层规划=） 如果你有兴趣，我只是偶然发现了这个与这个帖子有关的内容。 /麦克风 |
|
|
|
|
|
谢谢你的论文，迈克。
作者使用Virtex-5编写并测试了这一点并考虑了Altera FPGA，但我不确定他们是否了解Virtex-5当时被称为“区域，I / O和本地时钟以及全球时钟”（ DS100）因为它们只描述了全球时钟分配网络。 为了公平起见，Xilinx没有开始强调BUFH和BUFR，直到Virtex-6和BUFMR出现在Virtex-7中。 作者可以通过BUFG为每个水平区域提供BUFH来改善他们计算的偏差。 但是使用单个BUFG的时钟偏差量并不是大多数人在会议中遇到的问题。 问题是信号拥塞导致长信号路由。 考虑在我正在进行的设计中未能满足时序的两条路径之一。 要求是3.103 ns; 实现错过了0.025 ns; 逻辑延迟为0.520 ns，路径延迟为2.293 ns，时钟偏差加上时钟和系统抖动的时钟不确定性为0.315 ns。 我的系统抖动设置为0.250 ns。 所以为了解决我的问题，我应该做些什么？ 时钟偏差位于可能有用的事物列表的最底部。 更不用说在两个时钟域之间穿越时可能会产生新问题的所有地方，特别是如果您需要从滞后域交叉回原始域。 丹尼尔 |
|
|
|
|
|
丹尼尔，
感谢单挑。 有趣的是要了解更多关于这一点。我很困惑BUFG如何从BUFG中获取的速度比单独使用BUFG更快。 你愿意苟延残喘吗？ 再次，非常感谢您花时间回答这个问题。 /麦克风 |
|
|
|
|
|
好问题。
有两种效果。 而且它并不会更快：它会增加更多的延迟，但变化会更少。 让我们比较这两条路径，使用数据表中的道具延迟并猜测我们没有数字的位置。 只有BUFG，让我们说网络支撑延迟从时钟驱动器旁边的2 ps到远离全局时钟驱动器的150 ps。 如果你在BUFG之后添加一个BUFH，那么你添加一个110 ps的BUFH道具延迟，比如说BUFG 30 ps到BUFH净支撑延迟，并且由于BUFH具有较少的areato驱动，可能是该水平区域中的净支撑延迟 是1 ps到75 ps。 加上道具延迟，从输入到BUFG，包括BUFG增加100 ps的道具延迟。 在仅BUFG电路中，延迟为102 ps（100 + 2）至250 ps（100 + 150），偏差为148 ps。 在BUFG加BUFH电路中，延迟为241 ps（100 + 110 + 30 + 1）至325 ps（100 + 110 + 30 + 75），偏移为84 ps。 所以总延迟更多，但偏差更小。 区别在于BUFH的驱动面积小于BUFG，因此BUFH的偏差应该更小，但延迟会更多。 那有意义吗？ 现在我错了，因为Xilinx没有告诉我们各种时钟电路的最大偏差是什么，但是作为一个区域问题，如果我已经合理估计了它们的时钟树可能是什么样的，那就是它的方式 可能有用。 丹尼尔 |
|
|
|
|
|
不可以.BUFG不能直接进入时钟区域。
总是有一个BUFH驱动进入时钟区域。 换句话说，BUFG之后总是添加BUFH，无论你是否将它放入你的设计中。 在您的设计中明确添加BUFH的两个优点是：a）您可以控制逻辑的位置，这些逻辑位于您通过LOCing与BUFG串联添加到BUFG的那些明确添加的BUF中b）您可以单独控制BUFH上的CE 由设计中的BUFG驱动。 另一方面，如果直接从有效时钟源驱动BUFH，则不会插入BUFG。 因此，如果你能做到这一点，你基本上消除了垂直偏斜分量，只处理从BUFH源到BUFH树终点的水平偏斜。 如果你在水平方向上左右相邻的BUFH组合，那么潜在的偏斜当然比直接使用单个BUFH更大。 |
|
|
|
|
|
谢谢，拉尔夫克。
你的回复中有很多好的信息。 什么时候BUFG转换成BUFG和BUFH？ 我刚刚打开了一个设计实现，并绘制了驱动一个寄存器的时钟原理图。 它似乎是由BUFG直接驱动的。 但也许Bitstream Generation中的某些东西会取代它？ 谢谢， 丹尼尔 |
|
|
|
|
|
|
|
|
|
|
|
我现在正在使用VIvado和Virtex-7部件。对于Vivado，似乎从RTL分析中提取的原理图正是原始表示。
来自Synthesized Design的那些将显示在综合期间所做的更改并且打开已实现的设计显示在实现期间所做的更改。是否有可能“BUFG不直接进入时钟区域而是通过BUFH”对于早期的FPGA是否正确？ 谢谢，丹尼尔 |
|
|
|
|
|
|
|
|
|
|
|
我做了，它显示了同样的事情：BUFG直接进入时钟区域。
你可以在lastimage中看到八个BUFH。 他们是我在别处分配的，都有我给他们的名字。 我唯一可以猜到的是你描述的BUFH是BUFG时钟树的一部分，用户无法访问 - 除了作为BUFG - 因此工具不会显示它们。 再次感谢您的信息。 丹尼尔 |
|
|
|
|
只有小组成员才能发言，加入小组>>
2370 浏览 7 评论
2786 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办？
2255 浏览 9 评论
3330 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区？
2420 浏览 15 评论
有输入，但是LVDS_25的FPGA内部接收不到数据，为什么？
743浏览 1评论
请问vc707的电源线是如何连接的，我这边可能出现了缺失元件的情况导致无法供电
531浏览 1评论
求一块XILINX开发板KC705，VC707，KC105和KCU1500
345浏览 1评论
748浏览 0评论
1949浏览 0评论
/7 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
3618
评论
淘帖
282
