如何对待时序问题

时序问题几乎贯穿整个ASIC实现流程的所有环节，也许大家从教材上或者网上了解了很多解决时序问题的方法。但我今天想从实际项目出发，以一个PD工程师的角度来说说时序问题。

首先，ASIC流程都是有不同部门协调来完成，主要包括设计，综合和PR等环节，他们也为同一个时序目标而努力，PR作为最后一个环节，也是时序能否收敛的最重要环节。

如果PR人员发现post-layout后时序不满足怎么办呢？是不是立马采用各种修复的方法，或者找前端反馈，找设计人员修改呢？别急，凡事都有个流程，特别是协调合作，最能体现个人的综合素质的。

当通过ICC或者PT的report_timing 报出有时序问题的路径时，可以按照以下思路来解决：

1

检查这条path是否合法，比如可能是条异步的path，或者半周期的path，这时可以找设计人员确认这是否是一条合法的path，或许是约束写错了，或者designer不小心写了一个负沿的寄存器。

2

如果合法，需要确认这条path本来逻辑就很长，还是因为PR的floorplan导致的。如果你发现时序路径上有一连串的buffer, 那很可能是floorplan导致这条path的cell之间距离很远，工具插入了很多buffer。

3

如果是floorplan导致，可以尝试在placement时把这条path group起来，加大权重使得工具优先对待这条path。

4

如果不是floorplan导致，那可以通过在pre-layout时报一下这条路径，以确认这条路径在综合时就已经有很大的时序违规了。

5

如果是逻辑问题，建议还是自己先研究一下原因，以便在找设计人员的“麻烦”的时能给出一些建议，比如是不是有些很大fanout的cell，或者一串复杂的逻辑门，或者是否有很深的逻辑深度。

6

设计人员可能告诉你这是一个多周期path，甚至是条不用check的path，这样就轻松了，直接加timing exception，甚至不用修就可以了。

7

如果设计人员告诉你这是条真实的单周期path，这时还是先建议设计人员修改代码，当然PR阶段还是有手段可以解决，但要给自己保留一点余地，同时修改代码是一劳永逸的问题。

8

如果设计人员说不能修改，或者项目已经过了RTL freeze这个节点，那只能依赖后端的手段来实现了。

9

到这个时候，才是你后端人员发挥的时候了，比如可以采用high effort的post-route时序优化命令，ECO修复方法，或者利用useful skew技术，通过调整时钟延时来修复，当然路径前后有得借才行。

10

如果还是不能解决，项目允许而且库也支持，可以采用低阈值电压的Cell（LVT）来替换一些cell，以修复setup。当然LVT的使用也会引起功耗的增加，这个需要从全局去考虑，比如项目只允许使用0.5%的LVT。

11

如果所有办法都不行，那没辙，只能采用终极手段了，那就是：“不好意思，臣妾做不到啊，降频吧”！！！

审核编辑 ：李倩