北京移动端网站建设/seo关键词排名优

Floorplan：

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

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

如何衡量floorplan的QA?

Floorplan基本上是后端硅农最花时间的部分，一般是在解决三个问题：

IP、MEM、I/Opin、PAD/BUMP规划：琐碎重复且龟毛，可能就是在讲一个后端工程师在摆floorplan，经常的经历就是试过9527个FP后最后才发现第一个结果最佳。一般跟前端要一份data flow再去搞FP是明智选择，当然同时有前端详解各个不同模块的之间的联系和时序约束那是更棒。IP/IO的文档内一般会有一些place&route的建议，比如PLL周边的是否需要place halo/Litho，端口接线层次要求、方式(是否直连不可交叉)，不可与哪些device临近摆放。

各种physical cell的放置：WELLTAP、ENDCAP、DECAP、PowerSwitch这些玩意儿在前端的世界里不代表什么，而跑到后端的世界里属于稍有闪失便会DRCfail 甚至打回重来的窘迫境地。熟读FAB提供的DRC file必要至极，各种基于DRC、DFM、甚至是后期PV tool run time的考量都会收录其中。

Power plan：想要chip跑的快，供电不足怎么行，FP里占比重较大的一部分就是Power plan，怎么创建一个合理且强壮的power network，上能绕线欢畅不阻塞，下可静态动态不降压，一般成熟case会有一个沿用的Power plan结构，而新开case也不担心，可以拿DRC file里各互联层的max density为上限参考，多跑几版给Power analysis tool去确认。通常都会建议FP完成后去做一些P&R工具内部的verify，检查Physical cell之间有否place violation，检查power 有否缺via有否short，更稳妥的可以做个快速placement然后填满fill去跑 DRC&PA。DRC关注baselayer的问题，看有无Latch up问题或者边界cell冲突，PA可以大致看下power network有否特别薄弱的地方，看到一些犄角旮旯的遗漏问题。

就像clock skew和clock latency是检查cts QA的标准一样，floorplan QA的标准应该是placement结果，打开place data一看便知，关键路径所在模块是否被别的模块在place阶段冲的七零八落溃不成军？共享mbist的memory是否鹊桥相望天水一方？好好的两个REG有无翻越Macro去talking？

Placement:

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

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

如何衡量placement的QA?

Placement有三板斧，叫推开、聚拢、强锁死。

推开：常见做法是padding，可以是为了double height或者多pin的复杂组合逻辑甚至是整个routing congestion过多的module预先占routing resource，也可以是PA hot spot点大面积聚集时分散power mesh的压力。

聚拢：基本就是搞小团体，用instance group把希望在一起的inst, module, macro 撮合在一起。虽然P&R工具现在对path的分析优化能力越发强劲，但合理的group至少对runtime是福音。

强锁死：有时候有些inst在一万次place后发现无论怎样工具都没法给予非常合适的位置，就会需要用到一些强制锁定的小花招，比如pipeline打拍的DFF、DFT插入的某些mux、为了tree balance预先加入的anchor buffer都可以是强锁死的对象。

Placement遭遇的问题一般是timing导向或者congestion导向的，一个涉及timing可否meet，一个影响最后routing会不会有short或drc。一般都会根据timing report去调整inst group、region甚至重做整个FP或者调整sdc通过适度过约束来收敛timing；根据congestion map去预防之后可能存在的绕线问题，overflow是一个重要参考参数，而且现在的P&R工具基本都会引入合理的估算来模拟例如clock net因为应用了什么样的NDR而占据更多绕线资源的情况，使得place阶段的情况更接近最后的routing的情况。

CTS:

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

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

如何衡量CTS的QA?

CTS全称时钟树综合，是数字物理设计实现中最为关键的一步，一个好的时钟树可以有效保证绕线前后时序一致性。做好时钟树综合需要的知识技能没有特别的，STA是基础，然后同时对设计工艺有所熟悉，比如clock cell 类型，绕线层次等。

CTS的问题通常主要有skew不满足(平衡型时钟树设计)，树长过长等。以innovus为例，我们可以首先拿一个place db做一个快速的时钟树，set_ccopt_mode -cts_opt_type cluster ; ccopt_design-cts. 做完一个这样的时钟树，工具只修复了slew,并没有考虑时钟树平衡，这个阶段我们可以分析最长的时钟路径出现在哪，结合图形界面分析是否是placement不合理。同时我们也可以做一个快速的时钟树平衡，set_ccopt_mode -cts_opt_type trial; ccopt_design -cts.这是工具最理想状态做时钟树，通常这个阶段工具没法满足skew要求，到后期也不会满足，结合LOG信息我们可以快速定位是哪些sink不能做平。

通常评判时钟树质量主要是两方面，第一是反应时钟树功耗方面的，比如时钟树cell数量以及面积，时钟树线长。另外就是时序上的指标，比如时钟树insertiondelay, slew time, skew等。通常两个方面是互相关联的。

时钟树综合目前有两种设计理念，一是传统的平衡时钟树,另一种是cadence主打的时钟树并行时序优化。第一种旨在减小时钟树到不同sink点的差异，满足时序与否主要取决于数据路径。第二种建立在一个大致平衡的时钟树网络基础上，动态调整时钟树到不同sink的长短，结合数据路径的优化最大程度推高频率。通常，第二种设计方法用于高性能设计中比如CPU。

Route:

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

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

如何衡量Route的QA?

在先进工艺，绕线的工作越来越主要依赖于EDA工具的进步以及对先进工艺各种设计规则的支持。当然这并不代表PR工程师没有事情可以做了。绕线的好坏通常在flooplan阶段就决定了，我们要对设计的规格要非常熟悉比如金属层次，powermesh结构，macro 摆放等。

绕线问题最直观的体现就是DRC,我们可以结合Innovus route DB来分析。首先看DRC是零散分布还是集中出现在某些区域，通常这个和floorplan 有关，比如macro摆放，IO pin分布，细小沟道等。再结合金属层次具体分析，比如大量的DRC出现在出pin层M1,我们就要看看是否powermesh存在不合理，M1的spacing 和track 的offset选择是否合理考虑到了instance的pin access 。

首先是DRC clean,其次是是否有效合理利用金属层，在关键路径上是否出现大量的detour,是否合理规避SI的出现。

Innovus最大的优势是并行运算能够快速修DRC,而且能够保障可复现性。Innovus在先进工艺尤其16nm以下，对double pattern 的设计规则有更加成熟和有效的支持。

另外现在innovus基于时序的绕线也越来越强大，更加合理安排绕线资源，让时序收敛。

DRC:

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

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

对于数字P&R来说一般会遇到的DRC问题集中在两部分，一部分是在P&R工具内部的可检查出的DRC，或是因为某些std cell的本身因为cell layout的关系造成的某些cell内部的obs会跟特定方向走线有violation，或是特定某几个cell之间abut一起会有drc。另一部分是只能在PV工具出现在P&R工具内无法发现的问题，原因是各种各样，可能是PV工具的run set与PR工具的tech file并不一致，可能是GDS和LEF在互转中出现精度问题，甚至可能就是tool bug。前者现在某些FAB大厂常会提供一份针对cell的约束来防止以上问题，但也不排除遗漏需要自己去做一些补充约束。后者需要仔细定位问题发生的节点，是tech还是gds，然后及时跟FAB或EDA厂商沟通更新出问题的部分。初入行时听过一句话叫做没有修不掉的DRC，没有压不了的chip size，对于TO时间至上的后端来说，某些问题甚至要用一部分手动干预 (routing blockage )的方式解决，但因为工艺的变迁，10nm、7nm节点的DRC rule数量相较以前几乎是指数级别的增加，千万不要尝试用完全手动的方式去修正一个绕线密集区的space, enclosure, EOL问题，否则修一个DRC下一轮冒一百个的结果分分钟教你做人。