关于 行波 时钟的经典分析 转载.docVIP

关于 行波 时钟的经典分析 转载 在补充完整了时序例外约束，排除了虚假时序违规报告之后，设计中的绝大部分时钟都得到了收敛。但是，仍然有部分关键时钟不能收敛，时序余量总的负值很大。二进制文件下载后，时序不收敛路径对应的功能不能在设计要求的频率下正常运行，选用较低的频率后运行正常。这表明时序分析报告反映出的问题与实测结果是一致的。启用高级编译选项后，不收敛的路径有局部变化，但是整体上的时序收敛问题依然存在，优化效果并不明显。 在以往的工作中，我遇到的时序收敛问题可以归纳为两类:一类是缺少引脚时序约束导致的编译不稳定问题;另一类是组合逻辑过于复杂导致的时序收敛困难问题。在这一设计中，通过添加引脚时序约束，第一类问题已经不存在了;这一设计存在第二类问题的可能性较大。通过对不收敛路径起止节点和所在时钟域的分析，可以看出，在这些路径上固然存在比较复杂的组合逻辑，但是还有一个共同点:这些路径的起点和终点的寄存器并不是由同一个时钟驱动的，这两个不同的时钟处在同一个时钟组内，相互之间存在确定的(或可推断的)时钟相位关系，属于同源时钟。(这里需要说明的是，在前面添加时序例外约束的工作中，我已经把不同时钟域之间可能存在的路径都设置为了false_path，在时序分析报告中不会存在虚假的跨时钟域路径报告。)通过进一步分析这些同源时钟，还可以发现另一个规律:出现时序违规的路径大都发生在生成时钟(GeneratedClock)之间，或者是基时钟(BaseClock)与生成时钟之间;这些生成时钟都是通过计数器分频或状态机输出得到的，通过PLL分频得到的生成时钟并不存在时序收敛问题。现在，我遇到了时序收敛的第三类问题:由于使用生成时钟造成的时序收敛困难。 至此，该设计在时序收敛上存在的问题变得清晰了--该设计的时序收敛问题，并不仅仅是由于缺少完整的时序约束导致的虚假报告或端口时序问题，也不单纯是组合逻辑过于复杂导致的，该设计在时钟方案(ClockScheme)上存在的问题是时序收敛困难的根本原因。在着手对该设计进行时序调整之初，我就对该设计中大量使用了生成时钟的做法提出过质疑，但是当时缺乏充分的证据来支持这一论断。只有完成了前面一系列的时序约束工作，除却浮云遮望眼，这一问题才能最终水落石出。 在我和我的同事们接触过的设计中，都不存在这么复杂的时钟生成关系。我们在设计中偶尔也会使用生成时钟来完成简单的时钟分频，由于芯片资源丰富或生成时钟作用范围小等原因，并没有遇到过什么严重的问题。我们对于生成时钟的普遍看法是，使用计数器分频产生生成时钟的做法不好，可能的话最好用PLL来实现;计数器分频产生的生成时钟属于同步设计(对于TimeQuest来说，基时钟与生成时钟之间的相位关系是可以确定的，并不是随机的，因此也是可以采用同步时序分析方法加以分析的)，不会引入跨时钟域问题;只要综合工具能够把生成时钟分配到全局时钟网络上，生成时钟的偏斜(skew)就会很小，也就不会引入时序收敛问题。上述看法的前两点都是对的，但是最后一点是经不住推敲的。对于最后这一点，可以参考AlteraForum上的一篇文章。我也会在后面的博客中给出详尽的实例分析。这里不做展开论述。 由计数器分频或状态机输出产生的时钟又叫行波时钟(rippleclock)。当前一级时序逻辑的数据输出被用作下一级时序逻辑的时钟输入时，这个时钟就是行波时钟，在TimeQuest里被归为生成时钟。在大学里最初接触计数器电路时，我们都学过行波计数器(ripplecounter)，其原理就是采用行波时钟来驱动下一级触发器。这是一类并不被推荐的计数器设计风格，被归为异步设计，但它们在数字电路的发展史上占有一席之地。由于我的名字中有一个波字，从那时起，出于对数字电路的兴趣，我把自己的网名起成了riple。没想到，近十年后的今天，riple在维护遗留代码的过程中与ripple相遇了。下面，我就讲讲我是如何把行波时钟转换为正常时钟的。 针对行波时钟方案向同步时钟方案转换的问题，所有的相关文献上都建议采用时钟使能来解决。通过修改行波时钟的生成逻辑，在行波时钟的上升沿(或下降沿)产生宽度为一个基时钟周期的正脉冲，把这个脉冲信号作为后级触发器的时钟使能信号，用基时钟代替行波时钟作为后级触发器的时钟输入信号，从而把原本由行波时钟驱动的后级逻辑转换为由基时钟驱动，并采用新生成的时钟使能信号来产生与行波时钟边沿对应的时序控制。这样一来，原本由两个时钟驱动的复杂同步电路(行波时钟方案并不能看作异步时钟方案)就转化为了由同一个基时钟驱动的简单同步电路。 简单同步电路带来的好处是，较小的时钟偏斜给PR工具调整源寄存器和目的寄存器的布局位置和其间的走线延时提供了便利。在TimeQuest对简单同步电路时序路径的分析中，我们可以看到源寄存器和目的寄存器的时