建立时间： Data Arrival Time = Launch Edge + Clock Network Delay + Input Maximum Delay of Pin + Pin-to-Register Delay = 0+3.681ns+17.765ns+ Pin-to-Register Delay = 21.446ns + Pin-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register - utSU = 20ns + 3.681ns – 0.333ns = 22.348ns
Clock Setup Slack = Time Data Required - Time Data Arrival Time = 22.348ns– (21.446ns + Pin-to-Register Delay) = 0.902ns - Pin-to-Register Delay
若满足时序要求，则：0.902ns - Pin-to-Register Delay > 0 即Pin-to-Register Delay < 0.902ns
保持时间：
Data Arrival Time = Launch Edge + Clock Network Delay +Input Minimum Delay of Pin Pin-to-Register Delay = 0+3.681ns+13.731ns+ Pin-to-Register Delay = 17.412ns+ Pin-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register + utH = 0+3.681ns+0.221ns = 3.901ns
Clock Hold Slack = Time Data Arrival - Time Data Required Time = 17.412ns+ Pin-to-Register Delay – 3.901ns = 13.511ns + Pin-to-Register Delay
若满足时序要求，则：13.511ns + Pin-to-Register Delay > 0
Pin-to-Register Delay 时间从时序报告里得出在4.711ns—6.105ns范围内。那么建立时间余量显然不满足，建立时间时序违规。而保持时间则不会违规。
虽然这个工程如此这般分析下来，似乎在这个工程条件下用50MHz的速率来读存取时间为8ns的SRAM是不可行的。但是在我初步调试这个工程的时候，没有进行时序约束和时序分析的情况下就进行了板级调试，而且调试的最终结果是正确的，读写SRAM的操作好像没有出现预想之外的问题。这让我很是纳闷，为什么理论上进行静态时序分析不可行的时序最后却通过了板级调试了呢？思考了很久，归纳了以下几种可能性：
1，首先不排除上文里时序分析的方法有误，很期待各位高手指点；
2，时序分析的有些太苛刻了，可能有些地方都是想到了最坏的情况（当然这是必要的，有些时序违规不是一天两天能出现的，甚至听说过恩年出现一次的问题，这是最让人郁闷的事，记得我们部门里的机器在实验过程中出现了一点问题立刻大群人马围坐分析，毕竟我们搞的都是～～不是一般的马虎不得的东西呵呵）；
3，有些违规最严重的路径可能是地址的高位，因为我们操作的时候都是递增地址读数据的，高位地址变化周期长，它的时序违规表现的不是那么明显；
4，还真有那么一次，发现一个从SRAM读出的很小块的显示图片区错误了，不排除是读时序问题造成的；
5，SRAM标称的8ns是最大的等待时间，或许和开篇提到的一样，SRAM实际上数据有效等待时间不需要那么长，也就是上面分析中外部器件的Tco减小了。
这是我能想到的可能的情况，也许还有别的问题，也期待各位提出自己的一些看法。 |
