数字IC 设计实现hierarchical flow系列（二）

数字IC 设计实现hierarchical flow系列（二）

文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。

上周吾爱 IC 社区小编分享了数字 IC 设计实现 Hierarchical flow 中关于逻辑综合，布局布线阶段的相关内容。今天我们继续分享下半部分内容----- 寄生参数提取（RC Extraction），静态时序分析（Static Timing Analysis）。限于篇幅，物理验证部分内容放在下期。

2019 年数字 IC 后端校招笔试题目（附数字后端培训视频教程）

Dummy 添加

在芯片 chip finish 阶段需要插 dummy，而插 dummy 后 timing 会有所变化，因此在最后阶段的 RC 抽取时必须事先把 design 的 dummy 插好。

一般 foundary 都会提供插 dummy 的 utility，我们可以利用它在 calibre 中自动完成 dummy insertion，从而满足 foundary 要求的 poly，metal density 等要求。如果某些个别地方仍然有 min 或者 max density 的 violation，需要找 foundary 进行确认，是否可以 waived。

寄生参数提取

业内比较公认的寄生参数提取工具是 Synopsys 家的 Star-RC。如果你们公司不是特别牛逼，没有一套自己的 signoff 标准或者经验体系，请严格按照业界的标准来做。所以不要问能不能用 calibre 来提取 RC，能不能在 ICC 中抽 RC 看 timing 等类似问题，甚至面试的时候跟面试官说你是在 ICC 中抽 RC 看 timing 的。因为这些问题都暴露了一个问题----- 你做的数字后端很不专业。

STAR-RC 作为一个业界公认的 RC 抽取工具，必然要考虑到几大主流工具数据转换问题。因此 RC 抽取主要有两种常用方式，一种是Milkyway Flow，另外一种是LEF/DEF Flow。

• Milkyway flow

RC 抽取的 Milkyway flow 如下图所示。这种主要针对数字 IC 后端实现用的工具是 ICC 或者 ICC2，RC 抽取时只需告诉工具 design 的 milkyway database 即可，无需进行任何的转换。

对于 hierarchical 方式实现的 design，还需要提供子模块的 Fram View 和 CELL View。对于层层嵌套的设计，特别需要注意 Fram view 和 cell view 的一致性问题，否则 RC 抽取可能不准确。在抽取 RC 时需要将子模块的模块名称填入 skip cell 中。

Milkyway 方式 RC 抽取的官方参考脚本如下：

MILKYWAY_DATABASE: /project/local/angela/design.mw

BLOCK:design

SKIP_CELLS: *

NETS:*

NETLIST_FILE:

MAPPING_FILE: nxtgrd/layer.map

OPERATING_TEMPERATURE:125

TCAD_GRD_FILE: cln28hpm_1p08m+ut-alrdl_5x2z_cbest.nxtgrd

MAGNIFY_DEVICE_PARAMS:NO

MILKYWAY_ADDITIONAL_VIEWS: FILL （带 dummy）

BUS_BIT: []

HIERARCHICAL_SEPARATOR: /

MILKYWAY_EXPAND_HIERARCHICAL_CELLS: NO

EXTRACTION: RC

COUPLE_TO_GROUND: NO

COUPLING_MULTIPLIER: 1

REDUCTION: LAYER

METAL_FILL_POLYGON_HANDLING:FLOATING

NETLIST_FORMAT:SPEF

EXTRACT_VIA_CAPS:YES

DENSITY_BASED_THICKNESS:YES

NETLIST_COMPRESS_COMMAND:gzip -q -f

NUM_CORES: 8

• LEF/DEF flow

LEF/DEF 流程如下图所示。这种方式比较适用于 PR 是在 cadence 家工具 innovus 中做的，当然 ICC/ICC2 也可以写出 def，走 lef 和 def flow。

LEF/DEF flow 的参考脚本与 milkyway flow 大同小异，限于篇幅，参考脚本请移步小编知识星球查看下载。

同样对于 hierarchical 实现的设计，RC 抽取时也需要提供子模块的 lef 和 def 文件，并在 skip cell 中填入对应需要 flatten 的各个子模块的 module 名字。

RC 抽取的数据准备

从前面介绍的 RC 抽取流程和参考 flow 中，可以知道整个 RC 抽取需要以下数据信息：

• Milkyway Database/LEF DEF

• Nxtgrd

• Layer map

• Skip cell

• Temperature

有了以上所讲述的 Flow 后，就可以轻松对 deisgn 进行 RC Extraction 了。但是我们应该如何确保工具抽的 RC 文件 SPEF 是否正确呢？很多新手都是为了抽 RC 而去抽 RC，抽完也完全不知道准确与否。如果你抽完 RC 并不能保证抽取结果是否正确，那 prime time 中的 timing 还准确吗？因此小编总结下 RC 抽取应该要 review 的 checklist，有了它从此不用担心 RC 抽取出现问题。

RC 抽取的 checklist

• nxtgrd 和温度检查

• Dummy

• 是否存在short 和 open

关于 short 和 open，这里简单提一下，因为实在是太重要了。如果你的 design 中存在 short 或者 open，STAR-RC 一定会报出来，一旦报出来基本上都是真的 short 或者 open，所以请认真对待。

如果你确定你的 database 中并没有 short 和 open，而工具仍然报出来，那么问题可能会变得很严重。因为大概率是 database 和 milkyway 不一致导致的。在出现问题，排除问题时，请首先相信工具，排查自身问题，往往大部分问题都是人为粗心导致的。

限于篇幅，关于 checklist 的细节可以前往知识星球上提问交流。

静态时序分析 STA

在当今的工艺制程下，设计的规模都非常大，使用传统 flatten 方式来进行 timing signof 的方法已经慢慢不被大家所接受。一方面是整个 timing signoff 周期更长，另外一方面是对 server 提出了更高的挑战。

• prime time input&outputs

• 静态时序分析 Prime Time 参考 flow

对采用 hierarchical 方式的设计来说，其 timing signoff 主要要用到子模块的 ETM，ITM 和 netlist。

• ETM（Extracted Timing Model）

ETMs use abstraction to minimize the amount of data while attempting to preserve accuracy.

ETMs replace respective blocks in hierarchical timing analysis, which significantly speed-up analysis and reduce the memory footprint for the full-chip analysis.

• ILM(Interface Logic Model)

The components within an ILM include a netlist, parasitic loading, constraints, and aggressor information pertinent to the preserved logic inside the ILM. ILMs are highly accurate and can also speed up analysis considerably, while reducing the memory footprint.

从 ETM 和 ILM 的定义和模型上看，ILM 比 ETM 更为准确，但是由于其大小较大，因此在 hierarchical 设计实现时更偏向于使用 ETM 模型。

• SPEF

通常情况，我们为了更准确地看接口处的时序，我们还需要各个子模块提供各自的寄生参数文件 SPEF。这种方式其实你们也可以理解成 flatten 方式来进行 timing signoff。由于这种方式还是各个子模块分别进行 RC 抽取，各自的工作仍然是并行的，我们仍然将这种 timing signoff 称之为 hierarchical timing signoff。

STA 的 checklist

• Library 是否已经 update 到新版本

这里所说的 library 是指标准单元，memory，IP 等 library 的 db 文件。在 timing signoff 时，请务必检查所有用到的 db 是 foundary 或者 vendor release 的最新版本。

• Timing Constraint 是否完备

因为工具的分析结果是基于特定的 constraint 文件，所以如果你提供的 timing constraint 不正确或者不完备，那么结果可能就不准确甚至是错误的。

• SI 等参数变量是否正确设置

CRPR 能补偿 crosstalk 吗？

• RC 参数反标是否正确

PT 跑完后，要养成查看 RC 反标情况的习惯。我们可以通过 report_annotated_parasitics 来查看，结果如下图所示。请问下图的 report 中是否所有 net 都反标上了？

• Timing Signoff 标准是否符合要求

对于 hierarchical 方式实现的设计，对于接口处的时序约束是否正确。比如我们抽子模块 ETM 时，已经含有 ocv 所带进的 derate 值，如果在顶层分析时序时又对接口处再额外加 derate 值，则会出现过度悲观的情况。

对于 hierarchical 方式实现的设计，可能各个子模块实现所用的 library 不一样，比如 B 模块是用 12Track 做的，而 top 是用 9Track 来做实现的，那么接口处的 derate 值应该如何设置呢？design 的 clock uncertainty 应该如何设置呢？

以上为今天分享的内容，关于数字 IC hierarchical 设计实现 Flow 中物理验证（DRC 和 LVS 的详细内容）过程的内容分享，敬请关注下期内容。

小编知识星球简介（如果你渴望进步，期望高薪，喜欢交流，欢迎加入 ****）：

在这里，目前已经规划并正着手做的事情：

• ICC/ICC2 lab 的编写

• 基于 ARM CPU 的后端实现流程

• 利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现

• 基于 ARM 四核 CPU 数字后端 Hierarchical Flow 实现教程

• 时钟树结构分析

• 低功耗设计实现

• 定期将项目中碰到的问题以案例的形式做技术分享

吾爱 IC 社区知识星球星主为公众号” 吾爱 IC 社区” 号主，从事数字 ic 后端设计实现工作近八年，拥有 55nm,40nm,28nm,22nm,14nm 等先进工艺节点成功流片经验，成功 tapeout 过三十多颗芯片。

这里是一个数字 IC 设计实现高度垂直细分领域的知识社群，聚集了无数数字 ic 前端设计，后端实现，模拟 layout 工程师们。

在这里大家可以多建立连接，多交流，多拓展人脉圈，甚至可以组织线下活动。 在这里你可以就数字 ic 后端设计实现领域的相关问题进行提问，也可以就职业发展规划问题进行咨询，也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答，如遇到不懂的，也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题，提问，从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。

最重要的是在这里，能够借助这个知识社群，短期内实现年薪百万的梦想！不管你信不信，反正已经进来的朋友肯定是相信的！相遇是一种缘分，相识更是一种难能可贵的情分！如若有缘你我一定会相遇相识！知识星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有220 位星球成员，感谢这220 位童鞋的支持！欢迎各位渴望进步，期望高薪的铁杆粉丝加入！终极目标是打造实现本知识星球全员年薪百万的宏伟目标。

https://mp.weixin.qq.com/s/dvP7RsGjvqjdwxGdsw9oWg