【数字IC】hierarchical flow

Flatten Or Hierarchy

随着芯片规模越来越大，传统的flatten flow来design已经无法满足要求。针对规模比较庞大的设计，我们需要将这样的design A进行切分，划分成不同大小或功能的模块的design。然后采用Hierarchy方式对design进行N次逻辑综合，布局布线，寄生参数提取，静态时序分析，物理验证等工作。

Hierarchy的优势

• 设计规模

上面讲述过了，如果设计规模太大，如果用flatten方式来做设计实现，基本上是跑不出来的。

• Timing Signoff

进行flatten timing signoff时，Prime time本身的runtime会非常慢，而且极度消耗内存，特别是当芯片时钟结构比较复杂，对时序要求比较高的时候，经常会出现Prime Time跑不出结果的情况。

如果采用hierarchy方式，各个阶段的工作都是并行做的，一方面大大节省了run time，加速timing signoff进程。另外一方面各个子模块可以单独timing signoff，特别是当某个模块对时序要求比较高，但是模块大小又不大时，此时该模块一天可能可以进行两三轮hold fixing，而别的模块可能一天只能做一轮hold fixing。这样切分出来后可以有更多的时间对模块timing进行细调优化。

• 应用需求

在某个时刻，设计可能需要对芯片中的某部分逻辑进行power down操作，如果此时采用flatten方式进行设计实现，势必需要额外编写upf，需要对powerplan进行重新规划，powerplan需要对整芯片划分为两个区域。这样就给数字IC后端工程师添加额外的工作量。

此时如果对设计进行切分，将需要power domain的逻辑单独切出来，做成一个power domain。那么整个数字IC设计实现flow就非常流畅，省心省事。

如果在数字IC后端实现阶段发现某个模块，含有特别多的高pin density cell，导致绕线非常困难。此时也可以同前端工程师进行沟通协商，是否可以将该模块单独切出。但是切分时需要考虑接口处的timing。

Hierarchy方式实现IC Flow

数字IC Hierarchical方式设计实现流程大致如下图所示，整个过程涉及前端设计集成，逻辑综合，布局布线，寄生参数提取，静态时序分析，物理验证等环节。限于篇幅今天先分享一部分内容。

• 逻辑综合

逻辑综合阶段的流程如下图所示，其中上半部分为flatten综合方式，下半部分为hierarchical综合方式（DC综合）。如果是采用DCT综合，则还需要提供模块B和模块C的ETM model，Fram View以及工艺的tluplus文件。

• P&R布局布线

布局布线的hierarchy实现流程如下图所示。需要分别对子模块B和C进行布局布线，然后生成对应的post layout的etm，最后load进B和C的ETM和FRAM，进行顶层TOP的布局布线。其中使用ICC2 flow需要用到NDM(New Data Model)。产生NDM时需要用到DB和LEF文件。关于LEF写出方法，NDM制作方法和脚本，之前已经在知识星球分享过，需要的朋友可以前往下载查看。

需要特别注意的是，在这种hierarchy实现方式中制作Fram View时，千万别漏提取database中的antenna和绕线信息，否则ICC或者ICC2在route阶段可能无法看到内部绕线情况，从而容易出现接口处的天线效应（antenna effect）。

Hierarchical design flow的优点

• 数字后端P&R（Place&Route）实现时能够有效控制好每个子模块的实现过程，因为run time可以大量减少，而且不同子模块可以并行实现
• 将设计中新添加的模块单独切出来，预防因为新设计模块存在bug而导致大规模block重做，大大降低项目风险
• 解决绕线问题（为什么？大家好好思考，涉及logical hierarchical和physical hierarchical的概念）
• 寄生参数抽取（RC Extraction）时间大量减少 加速Timing Signoff进程

Hierarchical design flow的缺点

• Interface timing buget

P&R实现时，需要考虑IO接口的timing（预留timing buget），防止因接口相关的逻辑没有进行充分的优化而导致的timing violations。至于预留多少timing margin，留给大家思考。这个技能是数字后端工程师最基本的技能之一。各大公司的面试经常也会问到这个问题。

• RC准确性

第一，dummy的插法往往是flatten 抽取出来的。如果是hierarchical 的rc extraction，模块接口处的RC 是否可信 。
第二，相邻子模块边界处的RC是否准确。

-Timing的准确性
比如一个chip中，有的模块频率要求比较低，我们想用7Track的libray来实现。而对频率要求比较高的模块，我们则可以用9Track甚至12Track来实现。

那么问题来了，如果有一条path，startpoint是7Track中的，而endpoint是9Track中的。你们觉得应该如何处理呢？

如果top level的clock tree上存在crosstalk（等效于之前介绍过的common clock tree上存在crosstalk，分析对setup，hold的影响），子模块timing的准确性是否可信？