Floorplan：
要做好floorplan需要掌握哪些知识跟技能？
通常，遇到floorplan问题，大致的debug步骤跟方法有哪些？
如何衡量floorplan的QA?
Floorplan是后端实现的根本，对后续流程的影响最大，因此必须综合考量。SoC顶层的Floorplan涉及面广而杂，以此做说明较有通用性。至于模块级或IP级，可以在SoC级的基础上删减一些。
以下罗列各方面的因素：
-
芯片的形状和尺寸。评价芯片三大指标PPA里的A（Area）最终体现在了这里。在工艺参数一定的条件下，A越小成本越低越有竞争力。对于TSMC来说（有的Foundry对曝光利用率并不强制要求），光有A还不够，具体的长和宽的大小也会影响成本——即所谓的MFU。过低的MFU会被额外收费，很高的MFU会有额外奖励；
-
芯片在板级的互联情况。配套的显示屏、存储、电源管理、晶体等位于哪个方向，决定了与之相关的IO的摆放，进而影响Floorplan；
-
芯片一共有多少路电源输入，其各自是否需要单独关断。归属同一电源的模块应尽量集中到一起方便封装走线以及电源网络设计；
-
封装的具体要求。封装对于PAD开口大小通常有明确的要求，其基板过孔的大小也会导致要求预留一定的位置不能开PAD口。类似存储接口这类IO较密集的位置，需要仔细考量如何同时满足信号质量以及供电等方面的要求，并且方便封装走线；
-
进入先进的深亚微米工艺之后（40nm及以下），工艺上对于很多指标有了非常细的要求，比如Poly direction等。这些需求，会导致IP出现了方向性的概念：买的IP是NS的？还是EW的？亦或是摆放在角落里？这会涉及到项目规划和IP采购，比如NS类型的IP就只能摆放在上、下两条边，无法旋转后放在左、右两边；
-
IO的选型也是Floorplan的一部分，in-line / stagger模式要根据芯片的实际情况确定，是否支持CUP要看工艺和IO库。选定IO库后，还会涉及到驱动能力的问题，一般讲对外输出的管脚对此敏感，需要用SSO的指标去评价是否带得动外部电路，具体对某一组功能IO添加多少PG IO需要经过计算和评估，另外还会涉及到ESD等，也要在Floorplan阶段规划好；
-
在Floorplan阶段还要结合工艺提供的可用金属层以及IR signoff标准，规划具体的PG网络设计。通常高层金属厚度大电阻小会被用于主干网，低层金属的PG会影响signal routing，要仔细计算评估strap width / spacing等，横竖strap之间的过孔会造成潜在的routing congestion，也要仔细评估如何添加。其他还包括是否要求有back-bias？SRAM或IP是否有额外的供电网络要求等；
-
模块的partition以及模块间的channel设计，也是Floorplan时需要关注的问题。规划时要充分考虑各模块的特性，是否timing难收敛？是否routing难度大？不同模块规划成不同的形状可能有利于利用顶层空间进而节省面积。Channel中要避免出现复杂逻辑以防止出现routing congestion。
-
细节还有很多，特定IP对周边环境的要求（比如PLL要放在尽量远离干扰的边角附近），几组IO是做成Ring？还是构成一个个孤岛？SRAM朝哪个方向摆？MTCMOS摆成什么pattern，用何种方式连接？如何利用placement / routing blockage引导工具做出自己想要的结果？
-
要多次迭代检查后续流程中是否有任何问题与Floorplan相关并及时调整；
-
Floorplan作为一个基础，直接决定了后续实现工作能够达到的高度。好的Floorplan对外符合系统的要求，不会给系统设计造成额外的麻烦，对内不会造成意外的timing问题和routing问题。坏的Floorplan对内对外都会浪费更多的资源，例如走线层数、run time、功耗等。
评价机制上，首先要满足外部系统要求和内部各类IP、库的具体使用要求，例如方位、PAD分布、间距、Pattern等。在此基础上，可以对比不同版本的Floorplan在timing result、power、total net length等方面的差异。符合数据流向的好的Floorplan会带来好的timing / routability / power结果。
Placement:
要做好placement需要掌握哪些知识跟技能？
通常，遇到placement问题，大致的debug步骤跟方法有哪些？
如何衡量placement的QA?
除了Floorplan阶段和物理检查阶段外，PPA这三个目标都会定量的出现在各个阶段中，成为每一阶段的目标。
Placement要完成的任务是把逻辑合理的摆放到Floorplan阶段预留的空间中，尽可能少的增加面积和功耗，同时满足时序要求。一方面，工程师应该了解工具的行为和方法，另一方面，工程师应该了解待处理的对象和可用的材料。
工具的行为方法可以从运行log中看出一部分，也可以请教EDA AE。现在深亚微米的工艺越来越复杂，EDA对应的也提供了很多开关选项供工程师选择，不同的开关会导致完全不同的结果。
待处理的对象是设计本身，是timing critial（例如高性能CPU）还是routing critical（例如CEVA DSP core）？也包括所使用的library，不同的library cell在时序、可绕线方面的表现完全不同，这需要花一定的时间研究，以便在不同的场景下指导工具选择不同的单元。
例如，让工具尽可能均匀地把逻辑摊开，还是尽可能把相关的逻辑集成到一起，对timing / routability的结果会完全不同。这对于CPU实现和DSP实现来说，就要求不同的开关组合。不同单元的pin density相差很大，因此dont use cell list等也需要斟酌。
Placement的问题通常表现在timing差，或者出现差的congestion map。debug时要具体问题具体分析，比如观察timing path、各hier module的分布情况，看是否有Floorplan不合理或是工具设置不合理导致。
评价Placement时通常看几点：
-
可以考虑逻辑门数的增量，由于完成了一些HFN的fixing以及一些逻辑优化，面积会有小幅的增加，具体合理的增幅与综合时是否考虑了Floorplan也有关系；
-
看timing result，各timing group的setup time不应该有过大的violation；
-
检查congestion map，确认placement legalization之后，没有出现high congestion的点等。
CTS:
要做好CTS需要掌握哪些知识跟技能？
通常，遇到CTS问题，大致的debug步骤跟方法有哪些？
如何衡量CTS的QA?
还是先看目标，对于传统的CTS来说，工程师需要尽可能的把时钟源头产生的时钟，在同一时刻传递给全部的FF（useful skew点除外）。在实际上当然无法做到同时到达全部FF，因此有了最基本的latency / skew的概念。首先CTS的目标就是追求尽可能小的skew，过大的skew会导致后续的setup/hold难以收敛；其次是追求尽可能小的latency，这将会通过OCV影响timing结果，也会影响功耗。另外还有一些额外的指标需要考虑，例如上升沿和下降沿的均衡问题，通常工程师要挑选一些特定的门电路用于CTS，再比如时钟脉宽在CPU设计中有较严格的要求，这对于CTS策略也有影响，另外考虑到SI的问题，用什么样的spacing，要不要加额外的shield routing也需要考虑。
同样的，凡是用到工具的地方，都需要理解工具的行为，从log里可以看到，工具是“如何”长成clock tree的，是从根节点向leaf节点看，还是从leaf节点向根倒推？哪些指标可以显式的影响到工具的运行结果？也要了解设计，通常SRAM、hard macro等有可能导致tree意外变长，可以重点关注。
CTS的结果如果不够好，需要分析具体是哪个时钟出了问题（通常设计中会有很多个时钟，特别是考虑到功能模式和测试模式后）。分步长CTS是一个可以考虑的方法，以便对比前后不同阶段时不同tree的性能。有时也需要与Designer讨论时钟的定义是否仍有优化的空间。
评价CTS的结果，除了latency / skew外，功耗也是一个重要因素，通常clock network会占到全芯片功耗的很大一部分。另外，如果common path过短，可能会造成后续的timing fix难度较大，因此需要检查不同分支的clock是否尽可能多的使用了common path。面积增量也是一个检查的方向，过大的面积增加可能意味着比较差的CTS结果。
Route:
要做好Route需要掌握哪些知识跟技能？
通常，遇到Route问题，大致的debug步骤跟方法有哪些？
如何衡量Route的QA?
仍然是要了解工具，了解工艺。不同金属层的厚度、电阻率都不同，在不同的PVT corner下会对timing带来完全不同的影响。
Route阶段工具可以优化的幅度已经不太大了，很多结果已经被前期Floorplan / Placement / CTS所决定，因此顺序上越靠前的步骤越应该多优化。
Double pattern的出现导致routing engine需要有一个升级，并且需要引导工具合理的使用double pattern CAD layer。除了基础的完成全部的连线外，从DFM的角度考虑，过孔的可靠性需要额外的进行优化，因此有了double via ratio的概念。实际routing完成后，工具可以看到真实的SI效应，因此timing结果需要根据实际情况进一步进行优化。
Route阶段不应该出现大的congestion意外，如果发现要仔细分析与Floorplan / Placement等阶段到底有何不同。理论上congestion map在各步骤之间应该是连续可控的。如果发现Route有问题，包括DRC / short / open等，需要检查是否有充足的资源用于route，是否出现局部routing过于拥塞，是否与PG或Clock net相关等，以便进行局部微调，或者调整Floorplan等。
Route之后不应该出现大的timing violation和DRC violation。面积增量应该是受控的，否则需要检查约束是否合理（尤其是hold time）。
DRC:
要做好DRC需要掌握哪些知识跟技能？
通常，遇到DRC问题，大致的debug步骤跟方法有哪些？
如何衡量DRC的QA?
DRC通常被分类为前段和后段，即通常讲的base layer / metal layer。前段DRC要在较早的时间点上确认干净，因其往往与Floorplan相关，如果后期改动时间来不及。
DRC与工艺直接相关，每一代先进工艺都会引进大量的DRC rule，因此需要提前学习设计规则文件，了解Foundry有哪些要求，以便在Floorplan时即有考虑。
先进工艺下的DRC检查，除了基础的宽度、间距这些几何检查外，还混合了ESD、latch-up等连接性和电路检查。这就要求工程师熟悉设计规则的同时，清楚DRC rule file里每个开关选项的具体含义和用法。正确的使用开关组合以及开启相应的完备的检查是DRC signoff正确的前提。
基础的DRC做debug在GUI上显示分析即可很容易，ESD等跟电路结构有关，如果自己不具备分析能力，需要请layout engineer帮忙分析。另外有很多新的DRC rule与电压等信息相关，因此输入信息的准确性也需要反复检查。
评价芯片的DRC结果，首先要划分类型：必须消灭的和可以waive的：
除了一些特定原因引起的DRC可以waive（比如电感或敏感电路周边的density issue，或者designer确认电路本身没问题只是工具的理解有问题）外（也要跟Foundry确认），其他的DRC都要修干净。
再说几句题外话，伟哥的师傅Kimi哥说过，后端实现是“良心活儿”。这实在是一句真理。理论上说，通过了形式验证的后端数据，功能正确性就有了保证；通过了物理验证的后端数据，可生产性就有了保证；再通过timing、IR、SI等方面的signoff check，后端数据的使用正确性也有了保证。然而，作为后端工程师这时候就可以交差了么？显然不是。PPA三项指标，还能不能再做优化一些？能不能少用一层金属一层孔？能不能少用一种Vt的device？电源网络设计还能不能再robust一些？DFM recommendation rule是否能多满足一些？ESD放电路径是否能再增加一些冗余度......
如果有无限多的时间和无限多的资源，理论上可以逼近最完美的那个解。可是在实际项目里，不管是时间还是其他资源，trade-off无处不在，因此，虽然后端实现无法从无到有的增加功能，但好的后端实现能够最大程度上保障芯片的可用性和可靠性。后端实现的“灵魂”，在于在于不断地寻找更优的可能，发自内心的想把芯片做得更强壮更好用，在于今天要比昨天做得更好。
