罗风 · 2021年04月16日

若似月轮终皎洁 P&R问答第三篇

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。

WeChat Image_20210416100508.jpg

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问题。

WeChat Image_20210416100520.jpg

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情况。

WeChat Image_20210416100550.jpg

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的结果吧。

WeChat Image_20210416100603.jpg

DRC:

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

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

至于知识技能,我能说会看lef doc就可以了么,不要懒有啥问题就问。另外,在route时候工具的每一步行为都要清楚。

Debug drc就一点,分得清是谁的问题,是工具问题还是DB或者flow的问题,还是signoff工具的问题; 工具问题的话是place的问题,还是route的问题,然后看有没有work around;如果是其它问题需要找designer或者foundry确认。

作者:陌上风骑驴
来源:https://mp.weixin.qq.com/s/6zgl1HGDN3JmVRsmozBj\_A
作者微信公众号
捕获.PNG

相关文章推荐

更多IC设计技术干货请关注IC设计技术专栏。
推荐阅读
关注数
11182
内容数
1222
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息