第二十三课：Data setup_dc中hfn(1)

最新推荐文章于 2024-08-30 22:38:41 发布

2401_83817418

最新推荐文章于 2024-08-30 22:38:41 发布

阅读量699

点赞数 21

分类专栏：程序员文章标签： java 网络 linux

本文链接：https://blog.csdn.net/2401_83817418/article/details/138932203

版权

程序员专栏收录该内容

379 篇文章 1 订阅

订阅专栏

在此，我们的Target lib一般指的就是Standard cell lib，在DC中目标库也是指的工艺库，此处其实就是叫法不同；此处设置目标库的目的是为了opt优化过程，在PR中会有多步优化，当某步优化出问题时，就会返回上一步，这时候就需要目标库来告诉工具哪个cell是什么功能和含义；

Link Lib包含了所有要用到的库文件，工具有需要会自己去里面找；

Physical Lib

物理库中主要就是物理信息，包括芯片的概要图，最小单元site的定义等；

site：芯片中的最小单元，因此，所有的标准cell的大小都是site的整数倍，芯片的面积也是site面积的整数倍；

Height of placement rows: site的高度，可以看出，不同cell由不同个数的site组成，但大家的高度都是相同的；

Minium width resolution: site的宽度；

Preferred routing direction：参考金属走线方向；现在的芯片上面都有多层金属层，一般我们以M1金属走线方向作为参考方向，如果M1是横向horizatal，那么该方向就是Preferred routing direction；那么，M2就是纵向vertical，叫做Non-Preferred这样纵横交织堆叠；

Pitch of routing tracks：布线通道，不同层金属在走线时，不是乱走的，有一个走线通道；

Milkyway structure of 物理库

物理库的结构信息，主要了解两个views: FRAM view & CEL view，二者都是描述的SC(standard cell)中最基本的布局布线信息，FRAM是一个概括的视图，CEL view存储的信息更全面，最后在到导出GDSII文件时，用的就是CEL view；

Data Setup Flow细分

逻辑库的设置

关于逻辑库的设置，我们可以和DC一样，在隐藏的de.setup文件中设置，当然也可以自己写成一个setup脚本，到时候加载进去即可；

PR中库文件设置时，需要考虑max库(setup)和min(hold)都要设置；

简单解释一下为什么setup / hold=max / min:

Tsetup在计算时，slack=Require - arrived，其中arrived是我们真实的延时，当slack>0收敛时，我们考虑最worse的情况，那么就需要arrived最大；

Thold在计算时，slack=arrived - require，arrived是我们真实的延时，当slack>0收敛时，我们考虑最worse的情况，那么就需要arrived最小；

.synopsys_dc.setup

.synopsys_dc.setup文件在上述三个地方都会存在，优先级最高的是3级，当同时存在时，优先级高的会覆盖低的；

物理库的设置

创建Design lib in Milkyway

通过create_mw_lib命令创建一个design_lib，并指定了工艺文件和ref lib，类似于创建了一个新的项目，不过此时一些相关的文件还没有读进来；

创建好design lib后，整体的结构如上图所示；

将netlist读进design_lib

当我们把综合后得到的netlist读进design_lib后，工具就会自动生成初始的design cell；读取netlist的命令和综合中一样，然后需要指定顶层，在进行唯一化指定；

uniquify设定

何为unquify设定？举个例子，我们的设计中使用了某个成熟模块的设计，该模块的相关内容放在了ref lib中，在我们的设计中多处调用了该模块，如上图，在没有进行uniquify前，每处调用的该模块名称都是一样的，而进行unquify后，工具会帮我们对多处调用进行命名区分；

save_mw_cel

当我们save_mw_cel后，我们前面生成的design_cell就保存下来了，并在design_lib下面得到CEL view；

等价操作，更加简洁；

Technology File

Technology File(TF file)的内容说明，主要就是命名，Design rule，电气特性等；

简单说明一下TF文件中的一些名词：

Precision：精度，1000就表示小数点后三位；

pitch：前面我们说过，tracks是布线时的走线通道，那么对于同一层金属来说，两条tracks中心之间的距离，就叫pitch；

TLU+ file

TLU+文件的设置用”set_tlu_plus_files”命令来设置，同样包含了max和min两部分，mapping file后面讲；

mapping file

mapping file的目的就是为了将.tf文件中的名称与.rtf文件中的相对应，为了在进行RC模型建模时抽取.tf对应的StarRC.itf文件中的寄生参数；(简单理解就是，.tf文件中的metal寄生参数存储在另一个.itf文件中，但这两个文件中对同一matal的命名是不一样的，所以需要一个中间的mapping映射文件来告诉工具哪个对哪个)

ICC在计算延时(这里所说的延时，主要是针对组合电路的延时计算，包括cell & wire delay)时，主要基于cell delay和Net delay，其中net delay主要就是一些RC寄生参数相关；

TLU+ Models–UDSM

ICC在计算RC参数时，是根据net geometry和TLU+查找表来计算的；使用的TLU+模型为UDSM模型；一些供应商会提供.itf文件给用户，用户需要通过mapping file自行抽取RC参数；

Check Libraries

物理库check

Check lib主要就是让工具帮我们检查一些文件是否有缺失及失配，首先我们用”set_check_library_options -all”命令告诉工具检查所有要check的项目；其中，主要有两大类：

check_library: 检查逻辑库和物理库之间是否有missing /mismatched cell；这里要提一点，一般来说，在物理库中会包含一些纯物理的填充filler cell，这部分cell完全没有逻辑作用(在逻辑库中是不存在的)，是纯填充作用，因此肯定会报missing cell；因为我们在layout中，肯定有些部分是空白的，但在制造过程中这些空白区域是不被允许的，所以就产生了filler cell，一般就是一些cap cell，来填充这些空白位置；

同时，也会检查物理库中的CEL & FRAM view是都有missing, 是否存在多次引用模块导致的重名(unquify设置)；

check_tlu_plus_files: 用来检查TLU+相关文件和设置的完整性；

逻辑库check

物理库check命名用”list_libs”，其实主要就是检查link_lib中的库文件是否齐全，工具会列出来所有link_lib中的库文件，我们自己进行检查；

Define Logical P/G connections

定义Power & Ground pin/net的名称及建立逻辑上的连接；如果仔细看过综合后的netlist我们就会发现，其中cell都是只有input/output的，并没有显示出PWR & GND，这是因为每个cell都需要连接pwr和gnd，所以工具省略了，但我们在做布线时就必须加上去，因此我们先用”derive_pg_connection”定义了Power & Ground pin/net的名称，然后再告诉工具建立逻辑上的P/G连接，如上图所示：

①将所有cell的PWR逻辑上连到一起，将所有的GND逻辑上连到一起；

②建立一些tie连接，tie连接就是有些cell的一些pin，是固定接高/低的，因为在数字电路中，input是绝不能floating的，因此对于一些固定接高/低的pin, 此时也需要建立逻辑上的P/G连接；

Check Timing constraints

导入时序文件并进行检查，主要就是检查clock & input delay & output delay & translation & capaticity这五项；

几个点需要注意一下：

①我们需要告诉ICC工具我们的时序要求是什么，所以需要导入时序约束文件；

②如果我们用的是综合后的ddc文件，那么就不需要再次导入约束文件了，ddc文件里面都包含了；

③如果用的不是ddc文件，那么就要导入.sdc文件，注意，这里的sdc文件必须和综合中用的保持一致；

Proper Model of CTS

时钟树主要和uncert/transition/latency相关，也就是FF1–FF2之间的三种延时；

Timing and Optimization controls

上述举得这三个例子前面18/19/17课时都讲过：允许互斥时钟/直连引起assign语句，需要工具插入buffer解决/group path；这些设置一般都是通用的，因为相关的命令很多，我们可以用GUI界面来设置，然后把相关的command保存为一个脚本文件，每次使用时进行调用；

GUI界面举例；

Timing Sanity check时序完整性检查

时序完整性检查主要做两件事：

①在进行placement之前确保时序没有over-constrained，因为一但过约束了，那付出的代价可能就是面积增大，因此约束一定要和设计标准相匹配，比如我们的频率是1G，那就不要用1.1G来设置约束；

②进行”ZIC–zero interconnect check”检查，就是不考虑net-delay来检查设计的时序违规，如果没有加上net delay就已经存在严重的时序违规的话，那大概率是后端无法收敛的，直接打回上一层让设计修改代码/约束；具体的command如上，就是先打开ZIC模式，然后报告所有的时序违规，在关闭ZIC模式；

Remove unwanted HFN:High-Fanout-Net

在DC中，我们是有理想设计的：对于clock和HFN(高扇出线)是不考虑net delay的，但是在ICC中，HFN我们是需要考虑net delay的；而HFN的地方一般就是select reset处，因此需要"remove_ideal_network [get_ports “Enable Select Reset”]"；

Save and loading the Design

当我们设置好了上述1-12所有的Data setup步骤后，一定记住要进行存档，以便后面有更改时可以找回来；

当我们要对design lib中的文件进行操作时，记住不要用linux的一些命令，而是要用ICC的一些命令！！

当我们重新启动ICC后，想再次打开我们的设计，分为三步：

①先打开design_lib;

②再打开保存的data_setup文件；

③每次重新打开设计时，都需要重新导入时序约束及优化相关设置文件；

Data Setup Flow总结

至此，data setup就设置完成了，我们需要掌握的是：上图这六大部分，每个部分的信息是什么，ICC怎么读进来的，是否check，重点关注时序完整性检查和derive_PG_connection两部分；

①Logic/timing lib file：包含了所有的逻辑库文件，通过隐藏的.dc_setup中的target & link lib读进来，读进来后需要和物理库文件一起进行check；

②.sdc file: 时序约束文件，通过read_sdc读进来，需要进行check_timing；

③门级网表：read_verilog；

④物理库文件：工艺制造相关的信息，在创建design lib in milkyway时就直接指定了；

⑤TF文件：design rule相关工艺信息，同④一起导入；

⑥RC model file：工艺对应的RC延时信息，通过set_tlu_plus_files命令导入，需要进行check；

部分命令总结

ICC Flow简介

Design Planning

前面提过，Design planning又叫Floorplan,，即布图规划；在这一步中，可以分为两部分：Chip-level 和Block-level，对于ICC而言，一般简单的芯片可以chip-level直接做，但是当芯片比较复杂，cell过多时，直接做runtime太久了，因此通过hierarchy层次化设计，将芯片分成多个block分开来进行ICC，最后再拼接起来；

在Floorplan阶段，ICC主要做的事情有两件：

①IO/Pad place并规划芯片的大小及形状，上图中，对于芯片四个角位置的空白区域，无法放置正常的pad，因此引入了corner pad的概念，属于纯物理pad，没有任何逻辑功能；

②IP place & PNS–Power Network-Sythesis，将IP和电源网络放置好；