P & R 9

Floorplan：

要做好floorplan需要掌握哪些知识跟技能？

明确Floorplan 处理的对象：对于数字设计的 Floorplan 来说，它是一个很依赖前后步骤的一个过程，这个可以看作是后端Layout 的开始，Floorplan 处理的对象我喜欢叫做Special Instance and Region，工具的进步已经可以从 RTL 级别，以及Synthesis 阶段去尝试做 Floorplan，而 Advanced Node，Physical Aware Synthesis 越来越成为必须。

如果把 Std Cell 做为一般的 Normal Cell，那么 Hard Macro，Pad 很明显是特殊的 Cell，还有 Low Power 相关的 Cell 也可以看作是特殊的 Instance，ESD，TCD，FinGrid 等等，剩下的就是一些功能上，性能上特殊的 Instance，举例来说有Clock Gen，IO Buffer，DDR related 等等。

而 Special Regin 包括你Power Domain，Blockage Area，Route Guide，Placement Guide 等都需要在 Floorplan 的时候做为一种物理约束告诉工具。

除此之外，Hierarchy Flow 还需要有 Top-Down 的能力。

总结来说，对这些基本的对象的各种属性、作用、常见问题、在工具中的 behaviour 等要了如指掌。

熟悉设计： Floorplan 的人不需要去做设计，但是做Floorplan 之前，需要仔细阅读设计的结构文档，特别是功能模块结构、Memory 使用文档、时钟文档、电源分布、Package 文档等等。最好结合网表查看工具来查看整个Design 的结构，而 Place Route 工具里可以让工具做Trial，做为你的初始版本，也作为你了解 Design 的一个途径。

通常，遇到floorplan问题，大致的debug步骤跟方法有哪些？

Floorplan 遇到问题？怎么会知道Floorplan 有问题呢？那就是放到placement去验证一下，关注的问题是就是我们的目标：PPA，当然还有Congestion。各项指标都要在一个经验可接受范围内，如果是新的尝试，第一版最好余量留大一点。

我个人的方法是半手工，在一定程度熟悉设计的基础上，写一些方便 Manual Work 的 Utility，提高 debug 的效率，这样你的操作看上去对当前设计很熟练。对出现问题的地方，比如placement blockage 加得不好，Power mesh 中缺少via，某些 timing 因为 instance 没有 fixed 等等，需要逐项排查。BTW，此时机器不能闲着，继续做 Route，看 Global Congestion Map 和 Real Route 有没有区别。

如何衡量floorplan的QA?

QA 很多，可以列十几二十个甚至更多，我就说说如何积累吧，多思考，多反馈（后续步骤对前续步骤的反馈），然后有些可以自动化的就直接用脚本去Check，在做 Manual Work 的时候，多利用工具和脚本，做得整齐犯错少。往下做到Placement，检查 DRC，检查 Power 是很有必要的，然后对 Floorplan 做反馈。

要做好placement需要掌握哪些知识跟技能？

Placement 相对来说不是一个那么需要交互的过程，就是你给什么样的初始输入，工具就按着当前设置进行 Placement，Placement 的对象是标准单元。

从我对 Placement 的粗浅认识，我觉得Placement 的关注点也就确定了，就是 Placement 的设置，这个步骤和Floorplan不同，Floorplan 目前来看更多的还是人的作用，而Placement更多的是如何和工具打交道，知识技能主要集中在熟悉工具方面，可以配合工具去了解 Placement 中有哪些 Physical Constraint。既然是算法驱动的，工具所需要的输入是有限的，不考虑AI的因素，你是可以穷尽影响工具 Placement 的所有条件的。

时序是贯穿整个IC 设计的技能，就不单独说了。

还是以总结结尾，需要掌握工具的Placement 过程和相关命令以及物理约束。

通常，遇到placement问题，大致的debug步骤跟方法有哪些？

Debug 总是从问题入手，再结合Placement 对每个问题的影响，比如 PPA 中的Performance，即 Timing 和Placement 结合就是物理信息对时序的影响。比如 Timing 有问题，transition很大，从版图上可以去看 cell 的相对位置，fanout，前一级的transition等一一排除找到原因。

最后还是要回到Placement 的设置上，通过具体的设置来引导工具进行问题的修复，比如Placement blockage 的放置，guide cell 的放置，全局max_transition的设置等。

还有就是要大胆假设，并去尝试自己的想法，很多时候Placement 和Floorplan 分不开，Placement 很多时候就是一个命令Run 了就出结果了，而很多设置要返回到Floorplan，当然也有些flow 将它们分得很清楚的。

如何衡量placement的QA?

Floorplan 本身会有自己的一些经验标准，而Placement 就完全是看最后的结果，通过工具提供的报告，去分析，也有很多Checklist，这个就需要慢慢积累，可以始终抓住两个原则PPA 和前后步骤的反馈。反馈最典型的就是Congestion，基本上 Route 的问题，需要从Floorplan开始后的每一个步骤都关注，还有一个比较典型的反馈是 DRC，Placement后做一版 Routing，来检查 PG，Detail Route 的 DRC 是很有必要的。

CTS:

要做好CTS需要掌握哪些知识跟技能？

Clock Tree Synthesis，这个话题很大。

Clock Modeling

首先你需要了解 Clock 这个大的话题，随便列几个概念，可以通过sdc 相关的内容取了解，sdc 对 Clock 做了很详细的约束，就是你需要了解的 Clock 的大部分内容。

• cycle

• skew

• pulse

• glitch

• virtual clock

• …

Clock Learning

需要能够快速获取 Clock Structure 的能力，如果你不是design的设计者，如何快速获得Clock 结构，有人开一次会就全懂了，有人到做完CTS 最后一天还是迷迷糊糊。

Clock Building

第二个是方法和技术，基本的就是buffering，怎么 buffering从cts 诞生到今天一直在不断被讨论。从最开始的 H Tree理论，到现在的 Concurrent Clock Data，需要去熟知。

还有很多细节问题可以去关注，有备无患你总有一天会遇到的,平时可以多看文章，做实验：

• clock gating

• ccd (usefule skew)

• low power

• …

通常，遇到CTS问题，大致的debug步骤跟方法有哪些？

如果 Clock 很多，那么首先的问题是如何定位是哪一支出问题了，这个可以使用二分法，或者灵感法。

对于具体出问题的 Clock，主要工作都是工具在做，我们所要做的就是确定我们加的时钟约束正确，工具理解的Clock 和我们想表达的是一致的，除此之外就是一些比较 tricky 的方法，可以去guide 工具。

但是 CCD 增加了 debug clock tree 的难度，也更多的关注于 Clock 对Performance 的贡献。

如何衡量CTS的QA?

传统的 CTS 的 Check 有不少，方法是一样的，首先关注 PPA，然后关注前后联系，能自动化的就不要手动去做，填Checklist 是一件很反人类的事情。

Route:

要做好Route需要掌握哪些知识跟技能？

Route 是Physical Design 比较靠尾的步骤，意味着胜利的已经在前方。在这个最后的阶段，需要掌握的内容也许就是问一个问题：你前面的准备都做好了吗？所以说Route 的技能是从全局来考虑的，当你做Floorplan 的时候要考虑你的Macro Placement 是不是会 block 很多Routing 资源，做 Power Plan 的时候需要考虑Power 和 Detail Routing 的 Tradeoff。如果单从知识来看，需要了解和 Metal Stack 相关的内容，比如Metal 的 Pitch，Thickness 怎么回事，via 如何定义，常见 DRC rule 有哪些，manhattan distance 是什么，如果你要做Flipchip Routing 相关的，需要了解更多的方法，这个我也不是很了解。

通常，遇到Route问题，大致的debug步骤跟方法有哪些？

Routing 最常遇到的问题是Congestion 问题和 DRC 问题，Congestion问题先从 Routing 资源分析开始，以及分析Congestion 相关资源涉及到的 net，解决办法就是从Net 和 Cell 入手，还可以从 PG 下手。

对于数字 PR 工程师，是使用工具让 DRC 最少，和 PV 的操作不同，所以，PR 工程师解决DRC 的方法也是从辅助手段开始，而不是直接对 DRC 本身去思考。我们使用Routing Guide，Move Cell 等手段来间接解决DRC 问题。

如何衡量Route的QA?

Routing Clean

DRC:

要做好DRC需要掌握哪些知识跟技能？

我只能从PR 工程师的角度来说，和 Routing 中讲的很像，了解一个工艺点的 DRC 规则，会使用工具去 Check 和反标回 PR tool 中查看。PR 工程师的技能还是集中在Floorplan 到 Routing 中，DRC 做为一种 Check 的手段。

通常，遇到DRC问题，大致的debug步骤跟方法有哪些？

和 Routing 中一样，对于数字工程师，基本方法不是直接去解决DRC 本身，而是用间接手段来防止 DRC 产生，让工具去修复DRC。

如何衡量DRC的QA?

看到 DRC check 笑脸。