APR

APR （floorplan， place， CTS，route）

真正详细完整的介绍应该是Synopsys和Cadence的教程和userguide

就捡一些教程里面没有的东西吧

（1） 文件的准备和网表的检验

Q1.1 后端都需要什么样的库文件？

因为现在的APR工具尽量把所有的功能都整合进去，所以需要的库文件也是五花八门，杂乱繁复，

（Synopsys会把这些文件整合到一起，存在milkyway里面）

physical： LEF 和 GDS

timing： LIB, (分为NLDM, CCS 和 ECSM 三种，有一个基本上就可以了）

RC delay： capTable， QRC tech， QRC lib 或者 TLU+

route rule： tech lef 或者 tech file

xtalk： cdb 或者

power： VoltageStorm tech, VoltageStorm lib 或者

Q1.2 与设计有关的文件要哪些？

网表，时序约束，IO file， scan DEF

Q1.3 时序约束需要修改吗？

有时需要，

如果综合时使用了过小的clock period，要还原回来

可以去掉SDC里面的wire load， operation condition， ideal net， max area

有些为综合而设置的dont_touch， dont_use

有些为综合而设置的clock latency

Q1.4 APR之前要做什么样的检验？

检查所有库是否一致，版本是否一样，使用单位是否一样，是否有重名

用zero wire load model 来 report timing，结果应该和同样条件下DC/RC的结果非常一致

check timing 保证所有的单元都有约束

check design，不能看到任何input悬空，不能有3态门以外的ouput短路

（2） 一个好的floorplan

如果问我APR里面那步最重要的话，我会选floorplan。因为它的好坏，可以直接影响到timing，congestion，IR-drop，以及芯片的大小和价格。

Q2.1  什么是一个好的floorplan？

简单讲就是让上面几条都过得去的。

一个好的floorplan应该是macro摆放井然有序，走线密度刚好达到congestion可以承受的上限，标准单元的摆放不可过于松散，标准单元的区域最好是大片相连的，IO的排放按照功能分类，顺序与其他芯片的顺序一致，没有供电困难的死角。

Q2.2 做floorplan时要考虑哪些因素？

IO的排放顺序

power和IR-drop

模拟信号与数字信号的隔离

内部数据的流程

macro的面积和连接

critical timing模块的距离

congestion模块的走线资源

Q2.3 如何得到一个好的floorplan？

与系统工程师讨论IO的排放

和前端工程师商量内部数据的流向，critical timing模块

向mix signal工程师请教模拟模块的位置，间隔

然后让APR工具摆几个方案，以供参考

最后还是要自己手动调整。对绝大多数设计来讲，把macro放在四周，中间留给标准单元

大macro放外圈，小macro放内圈

大的macro之间一般要留一些空间给标准单元，因为clock buffer，signal repeater等跨过大macro的信号需要那些空间插入buffer

小的macro之间可以没有空间，几个小的可以挤在一堆，堆与堆之间留出一点空间就可以了

（3） 时序收敛

这是后端的核心任务之一，也是判断一个工具好坏的重要标准。各家EDA公司为之努力了几十年，至今也没有得到圆满的解决。初学者经常会问，如何让ICC时序收敛啊？为什么做了optDesign，encounter还有setup violation啊？建议以后就别这么问了，如果有一个好方法，可以从头跑到尾，自动把时序收敛了，那家公司就可以一统天下。到时，我们也就都可以下岗了！

每个EDA工具都有一定的局限性，我们要做的不是去挑战它的极限，而是为它准备一个好的条件，让它达到我们的要求。

这节不用问答的形式

3.1 了解每个工具的特性，预测最后的结果，在开始时预留一定的余量。

APR大致分为3步，place，CTS 和route，每步都有相应的时序优化，每一步，不同的工具会给出不同的的结果。以ICC为例，place （如果没有特别说明，以后所说每步均包含相应的优化）后，会比综合的时序差一点，CTS后会更差，route后会比CTS好一些，但是达不到place后的水平。encounter是一路向下。Azuro （现在已经被cadence购买）的CTS会把时序拉回来。所以ICC的place + Azuto CTS + ICC route可以得到比较好的结果。

知道了这个特点，在place时，如果有可能的话，多留些余量，也就是把时序设得更紧一些

3.2 MMMC

每个设计可能会有多个function mode，还有多个DFT mode，还有foundry建议的不同PVT，加不同RC的setup和hold的检查，这种组合出来的timing mode有几十上百种，要收敛这么多的时序，绝不是一件容易的事，所以出现了MMMC。EDA公司号称为我们迎接挑战，已经准备好了需要的工具，但是可信吗？我们搭得起这么多的运行时间吗？所以还是不要把这么多的mode全丢给工具，仔细的选几个最困难的setup和hold mode给工具，其他mode的时序基本上会被这几个选上的mode涵盖的。 有一个帖子讨论过选哪几个mode。

有一种比较高超的技巧，经过仔细分析各个mode下，时钟的关系，可以把其中几个合并成一个，比如function和mbist。但是这种方法并不是放之四海而皆准的，而且要求精通SDC命令的使用。

3.3 每步都干什么？

place之后，只优化setup。使用粗糙的RC抽取，global route

CTS之后，可以只优化setup，也可以优化setup和hold。使用粗糙的RC抽取，global route，如果clock net 已经route过了，clock就用detail route的结果。 时钟走线要double width和double space，高速（>500MHz）时钟要shielding

route之后，要优化setup和hold

可以试着多做几次优化，从中挑一个最好的结果，但是，一般情况下，不要重复（同样的命令和选项）超过3次。

3.4 出现congestion怎么办？

congestion说明走线太多，要把那一块的cell推开一些； 避免使用端口太多（>6个）太密的组合逻辑单元； 不要把单元放在M2的power mesh下； macro边上不要放单元； 使用congestion driven的place和opt； 遇到十分严重的congestion时，减小global route可以使用的资源，比如在encounter里面可以让trail route在若干条走线后，空出一根走线。

3.4 仔细分析timing violation，再找解决方法

出现timing violation后的第一步是分析那条path，找出违反的原因，然后才是解决办法。造成timing violation的原因很多，随便列几个常见的，

clock tree不平衡：CTS的定义有错误；不合理的FF位置，比如，放在了一个很细很长的通道中。利用useful skew消除setup违反

起始FF与终点FF的距离太长：用group把它们拉近

xtalk的干扰：加大线间距离，不要用infinit timing window算xtalk

detour走线造成的大的延迟：解决congestion问题

fanout太大：忘记set_max_fanout，或者设定不合理，或者对某些net set_dont_touch了

单元的驱动能力太小：去掉大驱动能力cell的dont_use属性，检查是否局部placement太密，没有空间sizeup了

hold timing violation与setup violation同时存在，工具无法做了。这种情况多半是SDC的问题，很少是真的，除非那是一个非常特殊的IO timing

（4） 低功耗

低功耗与高速度是相互矛盾的，要事先确定你更想要哪个，可以牺牲哪个.

后端对低功耗可以做的事情并不是很多，power island，multiple supply voltage，DVFS等都不是由后端决定的。

后端能主导的有，

Multi-Vth单元的替换：建议先不要用LVT单元

ICG单元在CTS里的位置：当然是在时序容许的条件下，越靠近clock root越好。

最后在时序收敛后，再做一次power优化

（5） ECO

ECO分为post mask ECO 和pre mask ECO，也就是只修改metal layer的ECO和任何layer都可以动到的ECO

post mask ECO是利用预先留好的备用单元，做的逻辑修改。现在的标准单元库中，有些FILL cell是带transister，只要用metal1/2把它们连起来，就可以搭成需要的逻辑单元。这种ECO受限与spare cell的位置，如果附近找不到的话，就比较麻烦了，所以它的修改规模十分有限。

pre mask ECO比post mask的要灵活得多。在tapeout之前，如果发现有修改的地方，就是用这种方法。它可以改几百个，甚至上千个单元。

ECO修改组合逻辑比较容易，如果动到FF的话，有格外小心，因为它有可能影响clock tree，进而造成大量的时序违反。

做ECO要前端后端联手完成，如何单反的一意孤行，不会得到正确的结果。前端找到要修改的逻辑单元 ==> 后端找到相应的物理位置，检查周围是否有足够的spare cell或者空间做ECO ==》 检查时序，预估ECO后的时序 ==》后端建议使用的ECO cell ==》 前端修改netlist ==》 后端做ECO place/route ==》 ... ...

原文链接：https://blog.csdn.net/u014703817/article/details/53705038