控制器的时序优化

cugjack

  最近有个国外的客户，需求是使用GF22的工艺设计完成支持4266Mbps的LPDDR4颗粒的控制器和PHY。对于控制器这边来说，需要在这个工艺下按照1066MHz的速率进行收敛，还是有不小的挑战的。目前还有好多路径的时序没有收敛，这里开贴记录一下整个优化的过程，希望可以最终收敛。

1 首先在客户给定的范围内加上速度最快的库以帮助优化critical path.
2 有一条critical path上使用了冗余的逻辑，导致路径非常长。冗余逻辑产生的原因是本来控制信号已经有现成的，又通过一个选择网络重新生成了一遍。这个值得反思。在coding过程中过于追求形式的统一，使用选择网络对所有的需要用到的信号进行生成，没有注意到实际上有相关逻辑已经生成了的。
3 有些critical path的路径的确是比较长比较复杂，在设计过程中其实应该就要注意到这些逻辑路径的分布和负载。
4 有些critical path的路径需要进行逻辑的拆分，将其分散在cpature D触发器的前后。
5 虽然不是专业的后端工程师，也需要自己写脚本将综合的时序拿出来进行分析，同时还要尽可能的多生成timing reports，有的时候生成的太少会报出来不完全，出现优化完一一些路径后综合有报出新的violation。

继续后续的更新：
目前经过几轮的优化，已经可以满足时序要求顺利流片了。一些新的经验如下：
1 要先清理干净critical path所属时钟域其它比较容易处理的timing violation，比如控制器和phy之间的接口所导致的违例，否则它会影响你care的critical path的分析。
   有一个还算简单的模块是设计的critical path，经过分析总觉得它不应该有这么大的vialation,因为工具没有选择预期中的cell进行优化。采用把这个模块单独拿出来进行时序分析，果然时序还好。最后跟后端工程师讨论，他建议我先把接口时序处理干净，后来就解决了。
2 对组合逻辑进行差分，并行完成以后再通过mux进行选择，这是一个比较常见的优化方法，效果还是非常不错的。

y23angchen

感觉和S的umctl2有点像，TE TS里面各级选择蛮复杂的，22nm 跑 1066 实在有点难