时序问题~~求帮助~求分析~~

yujiexie

①第一张图中，data path delay大于requirement的时间，但是slack为正值，这会出现什么问题么？
②第二张图这条关键路径的主要路径；
③第三张图是PAR出来的最大时钟频率154.083MHZ，我的系统跑在153.6MHZ，这样的话时钟会不会很吃紧呢？会不会出现意外的问题呢？

yujiexie

第一张图~~
回复 1# yujiexie

eaglelsb

时序不成问题，
生成时序报告时是以+85度，-0.95V的core电压这个最坏条件分析的，事实上你的板子运行条件要比这个要好得多。
上板经验 2ns的timing slack都能比较正常地工作，

yujiexie

回复 3# eaglelsb

谢谢回复~~
几条关键路径，我的slack time才是0.00几ns这个级别的，有点担心。
还有PAR出来的最大时钟频率，记得有人说过一般要有20%的余量才是最好，才不会出错，我实际要工作在153.6M，即PAR出来的要大于192M才是最好，但是我时序分析出来的才是155M，这会出现什么问题么？

绿茶盖儿

关注此贴， 学习了

eaglelsb

回复 4# yujiexie

不用，规则是死的，要看具体场景灵活使用。比如你的产品是商用，并且要求很苛刻，那需要20%的降额之类的是有必要的，要是普通环境使用，就大可不必这么严格，工具本身已经考虑了较差情况。过设计同样不太合适。


当然你还有其它手段去提高时序，比如注意代码风格，对关键路径优先编码，XILINX推荐使用同步高复位，使用synplify premier带physics synthesis综合，使用多周期约束、加false path等一堆手段。
上板的时候，适当提高输入电压有利于提高板上稳定性（比如5.3V输入的你用5.4V输入，其实这个效果不大，如果板上接的是开关电源或LDO，下一级输出基本是保持稳定输出的，不受输入电压影响，只要欠压不严重），另外做好散热，加个散热片、风扇之类的，

iidestiny

1. 仅仅只有data path dealy 和 requirement 不能决定slack 的，具体到你这里positive clock skew 改善了setup time 的状况。

3. 约束正确的情况下，只要时钟质量、电源质量过硬的话没问题的。约束我们一般是10%的余量。

yujiexie

回复 7# eaglelsb
谢谢那么耐心的回复~长知识了

yujiexie

回复 8# iidestiny

谢谢回复~我现在正在优化一下代码，争取把时钟余量再提高一点   

tianguau

1.slack是正的因为后面的公式。
2.比较边缘，最好优化。
3.slack负的比较少，可能不出问题，可能出问题，出了问题就很难搞定。