标签：收集 route ase 关注 需要 实现 red 条件 delay
Floorplan：
要做好floorplan需要掌握哪些知识跟技能？
通常，遇到floorplan问题，大致的debug步骤跟方法有哪些？
如何衡量floorplan的QA?
Floorplan是后端实现的起始步骤，是P&R的先决条件，通常Trial Run的目的也是为了把FP固定。因此，在做FP的时需要从以下几个方面准备，第一方面收集Physical“规则”，这其中包括Design Rule，Package Rule，IP Guide，IO Guides等等，只有优先知道了限制条件，在限制条件内做FP才是有意义的。第二个方面是关于Design的需求，Data Flow决定module的位置，低功耗设计要求决定FP时要考虑的Power Domain以及相应的低功耗设计的诉求。
如何衡量FP的QA，通常我们会把P&R的结果作为相应的标准，其中Feasibility是很重要的一项，另外就是PPA的体现。另外，FP是后端流程中，特别体现个人风格的点，因此需要具有“美感”，具有让人一眼下去所能看到的“用心”程度，这个可能也是FP QA的一方面。
FP的Debug方向，倒是通常由于后续问题来修改FP。
Placement:
要做好placement需要掌握哪些知识跟技能？
通常，遇到placement问题，大致的debug步骤跟方法有哪些？
如何衡量placement的QA?
在数字后端实现中，有个原则，问题越早解决越好。FP是起点，Placement是接下来的重要一步。知识跟技能，所有的Tool的user guide上面都有大致介绍，概括来讲，需要综合考虑timing和physical两个方面。因此，Placement Guide，Placement的策略选择（Two pass flow，In-design OPT，甚至和前端综合工具的Physical Aware的配合等），是否需要带入CTS之后的一些问题的解决方案（比如clock gating timing部分，比如考虑CTS的routing资源的预估）等等决定Placement的结果。
通常做完Placement，单纯从这一步需要关注的是congestion map，timing QoR等。再详细的便是Module的位置，是否有被拉开的模块，为什么被拉开。是否有Tool无法修复的Timing, DRC，是否和FP相关，等等。现在深微纳米的工艺，单纯的从一步的结果已经很难综合评定此步的QoR，所以还是建议整个flow run完后再作相应的调整。当然如果CongestionMap或者timing QoR 在PL Stage已经暴差了，需要停下来分析。
Place的问题分为几类：
Congestion问题，这个问题要分析是否是FP造成的，还是因为Placement的Guide， Region之类的问题造成的。一些Channel的位置可能会有congestion的问题，需要Check是否正确使用了相应的Blockage。
Timing问题。主要看看Block的分布位置是否合理。Timing Path的走向是否合理等。
Check Area Increasement，看看新增的面积是否合理。是否由于过约等引入不必要的问题。
Check关键Module的位置和分布比如Clock Gen的cell等。
另外Placement阶段要为CTS做一定的准备，需要提前考虑Clock Gating不够balance可能引入的timing问题
CTS:
要做好CTS需要掌握哪些知识跟技能？
通常，遇到CTS问题，大致的debug步骤跟方法有哪些？
如何衡量CTS的QA?
CTS是PR flow中涉及design知识最多的步骤。做好的CTS是为了更好地收敛Timing，减低功耗等等，其前期准备，需要了解clock structure，需要了解DFT的 clock structure，需要知道Design CTS的Spec需求（比如使用什么CTS cell，CTS的timing DRC constraints如何设置，NDR如何设定，是否需要Shielding，Block/IP内部的tree的处理方式，等等）。当然，也需要对工具feature有相应的理解，才能在知道你要长成什么样的tree的前提下，去用Tool完成相应的工作。
CTS的QA，涉及两个方面，一是单纯的Tree，一个是基于这个Tree 的timing和Physical。单纯从Tree的角度，需要考虑Clock的latency，skew，甚至power等等。从统筹的后端实现来看时，需要考量Tree对Design的影响，是否有比较大的hold，是否有useful skew可以借来解决Setup，是否因为CTS的问题引入Physical的risk，比如为了balance tree而引入的局部集中的delay cell所带来的congestion问题。再比如跨corner间的balance情况。
Route:
要做好Route需要掌握哪些知识跟技能？
通常，遇到Route问题，大致的debug步骤跟方法有哪些？
如何衡量Route的QA?
Routing的Flow相对比较独立固定，基本原则是先绕什么，后绕什么，如何设置CrossTalk option等，另外还有些DFM的VIA处理，Cross Talk Reduction等。
通常的Routing问题，第一可能是大量的DRC出现，这个或许和FP，以及Placement, CTS相关，分析原因之后，可能要回溯到前面的步骤来完成。
另外可能的是SI的问题，引入SI可能有很多种情况，局部的SI以及通篇的SI，data path的SI或者clockPath的SI，这些都要分开来看。同样可能需要回到FP和PL及CTS来解这些问题。
Route的QA，就看Timing和Physical的结果吧。
DRC:
要做好Route需要掌握哪些知识跟技能？
通常，遇到Route问题，大致的debug步骤跟方法有哪些？
至于知识技能，我能说会看lef doc就可以了么，不要懒有啥问题就问。另外，在route时候工具的每一步行为都要清楚。
Debug drc就一点，分得清是谁的问题，是工具问题还是DB或者flow的问题，还是signoff工具的问题； 工具问题的话是place的问题，还是route的问题，然后看有没有work around；如果是其它问题需要找designer或者foundry确认。
标签：收集 route ase 关注 需要 实现 red 条件 delay
原文地址：https://www.cnblogs.com/lelin/p/11405441.html
