DC学习笔记

视频  数字逻辑综合工具实践 DC 01_哔哩哔哩_bilibili

一、DC工作模式（此小节为搬运内容）

原链接：Design_Compiler User Guide 随手笔记（9）Using Floorplan Information - 知乎

DC拥有四种工作模式：

工具模式：wire load mode和 topographical mode
非工具模式：Multimode和UPF模式（Unified Power Format）

非工具模式只能用在topographical mode下，wire load mode是默认模式，启动dc时必须选择工具模式的一种。Multimode允许在多个操作条件和多种模式下操作工具（比如：测试模式和备用模式）。UPF模式允许指定先进的低功耗方法。

Wire load mode下的编译命令为:compile和compile_ultra，这是最常用的模式。

Topographical mode：使用物理约束时必须在该模式下，此种模式对于前端设计来说使用较少。在综合时精确预测布线后的时序、面积、功耗，时序的估算无需基于线载模型。综合命令：compile_ultra和compile_ultra -spg

在topographical mode下，Design Compiler支持高水平的物理约束，例如：芯片面积、核心区域及形状、端口位置、单元格位置及方向、禁止布线区域边界、布局blockage、预布线、边界定义、过孔、导线层、电压区以及布线禁入区等。

通过在优化过程中考虑布局规划信息，在topo模式下使用布局物理约束可增强与PR工具（如IC Compiler）的时间相关性。

可以通过以下任一方法将布局物理约束提供给Design Compiler -topo模式：

• 从IC Compiler中以DEF文件或Tcl脚本的形式导出布局规划信息，并将其导入到Design Compiler中。

• 手动创建这些约束条件。

1.导入布局信息

有两种方式导入floorplan的信息，一个是用ICC写出DEF再被DC读入，另一种是直接使用write_floorplan这样的命令来让DC读入floorplan的tcl脚本。

从ICC里导出def的指令：

icc_shell> write_def  -version 5.7  -rows_tracks_gcells -macro -pins \
                      -blockages -specialnets -vias -regions_groups -verbose \
                      -output my_physical_data.def

在DC里读入DEF文件，需要使用以下命令：

dc_shell-topo> extract_physical_constraints {des_1.def des2.def … des_N.def}

默认情况下，当读入多个def文件时，只有一个值的物理约束，比如port的位置等会被最新的def文件所覆盖，keepouts和blockages这样的约束会累加起来，示例：

读入第一个def时候，core的位置是200x200的矩形，随之被第二个def的core叠加上，另外K1和K2都添加上。

DEF里的Die Area、Placement Area、Macro Location and Orientation、Placement Blockages、Wiring Keepouts、Placement Bounds、Port Location、Preroutes、Site Array Information、Vias、Routing Tracks、Keepout Margins这些信息都可以被读入，具体格式就不多介绍了。

从DEF里提取Physical -Only cells时候，需要在后缀上加上 -allow_physical_cells 的选项。

至于第二种即在DC里使用Tcl创建Floorplan，我没用过，如果有PR工具可以很方便地创建floorplan并通过def导出，为什么还要大费周章在DC里手动做呢？可能对于一些非常简单的调整可以使用，具体的还是翻看UG在需要的时候查询吧。

DC有三种交互模式：

1. gui  可以直接打开图形化界面

2. dc_shell  通过dc_shell逐步进行操作

3. batch mode 通过脚本文件一次运行多条dc命令。

二、DC综合流程

DC主要功能是将我们的RTL代码进行综合，综合的过程分为三步：转换、优化、映射。

1、转换

这一步在DC读入RTL文件后就完成了，读入RTL文件有两种方式，一种是使用read_file 指令，第二种是使用 analyze命令 和 elaborate命令配合使用达到read_file的效果。其中analyze命令可以按照vcs的方式进行读入设计文件(包括定义宏和使用file list)。DC读入RTL后，会将RTL转换为GTECH格式(gtech格式的与综合后的cell与pin有一定区别，例如某个寄存器的综合后的D端为 xxx_reg/D，但是gtech中pin的名字为xxx_reg/next_state)。

读入RTL文件后，还需要进行link，dc user guide的原话为：

For a design to be complete, it must connect to all the library components and designs it references. This process is called linking the design or resolving references.

例如如果RTL中使用了stand cell和designware时，需要使用link命令将这些模块与库文件连接起来。

2、优化和映射

优化和映射需要DC对转换后的RTL代码进行综合，综合需要依赖库文件(logical library）

指定库文件,包括搜索路径（search_path）、链接库（link library）、目标库（target library） 、符号库（symbol library）、综合库（synthetic library）。

search_path
  综合工具只会从该指定的路径去寻找各种库文件，指定search_path后可以不写出库文件的绝对路径。

target library：

工艺库是综合后电路网表要最终映射到的库，读入的HDL代码首先要由synopsys自带的GTECH转换成DC内部的交换格式，然后经过映射到工艺库和优化生成门级网表。工艺库又Foundary提供，一般是.db格式，我们可以查看的是.lib格式。

工艺库中包含了各个门级单元的行为、引脚、面积以及时序信息，DC在综合时就是根据单元电路中的延迟信息来计算路径的延时。

Link library ：

链接库设置模块或者单元电路的引用，对于所有DC可能用到的库，我们都需要在链接库中指定，其中包括要用到的IP。

在link_library的设置中必须包含 " * "（且要放在最左边，DC会按照从左到右的顺序进行查找），表示DC在引用实例化模块或者单元电路时首先搜索以及调进DC memory的模块和电源电路，如果在link_library中不包含 *，DC就不会使用DC memory中已有的模块。

Symbol library：
  Symbol library 提供 Design Vision GUI 中设计实现的图形符号，如果使用脚本模式而不使用 GUI,可不指定 Symbol library 。

Synthetic library
  虽然直译为综合库，但是常称为IP库，包括Designware library和使用的一些hard macro。特殊的IP库需要授权（例如多级流水线乘法器），标准IP库由DC软件商提供，无需指定。

三、DC中的object(此小节为搬运内容)

原文链接：https://www.cnblogs.com/xh13dream/p/8675072.html

1.什么是object？

(1) 分类

　　

　　包括六类：Design(顶层)，Clock，Port(顶层的pin)，Pin（cell里面的引脚），Cell（例化的模块），Net（模块与模块之间的互连线）

有一点需要注意，我们在写SDC的时候，要找到leaf cell上的pin,否则综合后可能找不到这个pin（没有子模块的cell 统称为leaf cell）。

(2)电路图看

　　

(3)design可以转换为cell

(4)objects名字相同时

　　

　　如果不指定object的类型，DC会按照默认的优先级进行选择，port比net的优先级更高。加在net上，5个单位的电容会覆盖原电容值；加在port上，5个单位电容与原电容值x并联，总电容值为（5+x）个单元。

　　改进：

　　set_load 5 [get_net sum]：加在net上

3. 相关命令

有关object的操作会返回一个collection，这个collection可能有多个object，也可能只有一个object。个人感觉一个object的类型就相当于一个类，这个类又在collection里被实例化，因此直接打印collection只会输出这个collection的句柄，而不会输出collection里object的名字。

(1）get_*

　　返回一个collection；使用echo返回collection的句柄

　　set_load 5 [get_ports addr_bus*]     *是模式匹配里多个的意思，以addr_bus开头的n个port

　　set_load 6 [get_ports "Y??M Z*"]     ？是模式匹配里匹配前面字符0个或者1个的意思

　　如果不存在，返回empty_collection

（2）all_*

　　all_inputs

　　all_outputs

　　all_clocks

　　all_registers

（3） remove_from_collectiion

　　从collection中去除某些object

　　remove_from_collection [all_inputs] [get_ports CLK]   #从所有inputs里去除CLK

　　add_to_collection $pci_ports [get_ports CTRL*]  #在pci_ports里添加CTRL*

（4）query_objects $pci_ports

　　query_objects $foo  #得到集合的具体objects名字

（5）sizeof_collection $pci_ports(大小)

（6）echo

　　set foo [get_ports p*]

　　echp $foo  #返回集合的句柄值

（7）过滤器

　　filter_collection [get_cells *] "ref_name = ~AN* "

　　get_cells *-filter "don't_touch == true"

（8）foreach

　　

。

（9） index_collection $pci_ports number

　　相当于求数组的某个number值

4. objects的属性

　

四、时序约束

可以通过check_timing命令检查约束是否完整，这个完整只是结构上的检查。对于功能上的，比如需要使用multicycle的地方，需要设置max delay的地方，需要设置false path的地方，工具是没办法帮你检查出来的。比较通用的就是对input ports设置input delay，对output ports设置output delay，对于non-unate的时钟传播需要设置generated clock。

上图是check_timing的检查点，可以看出会对未约束的endpoint进行检查，但除了input delay外，不会对未约束的start point进行检查，因为endpoint肯定是从startpoint来的，只需要对endpoint进行约束即可。但还是有一些地方需要注意，不然初学者在使用report_timing这条命令时，很有可能稀里糊涂。

我们首先要搞清楚什么是时序分析start point和end point，时序分析的start point包括寄存器的时钟和design的输入端口；时序分析的end point包括寄存器除时钟外的输入和design的输出端口。

当我们使用report_timing -from xxx -to xxx时，可能的情况会有三种，一种时会直接报告出时序信息，一种是报出path is unconstrained，最后一种是报出no path。我们着重分析第三种，哪些路径是不存在的。对于时序单元有下图的时序弧：

其中D和CDN都是endpoint，这个endpoint的startpoint是上一级寄存器的CK。上一级寄存器的CK到下一级的D端就是一条完整的路径，对于这条path中的任何子路径的startpoint和endpoint，都可以作为report_timing的startpoint和endpoint，我们可以单独去设完整路径或者子路径max delay和min delay，这也属于时序约束的一种。但是即使我们不去设max delay或者min delay，工具还需要会考虑setup和hold，只要是同步时钟，setup和hold就属于这条路径的约束，会报出时序信息。但需要注意setup和hold其实是这条完整path和CK间的相对关系，并不是起始点和终点的关系，因此如果使用report_timing是起始点是一个寄存器的D，终点是同一寄存器的CK；或者相反的起始点是一个寄存器的CK，终点是同一寄存器的D，工具会报出no path。对于CDN也是同理，异步复位的source到寄存器的CDN是一条完整的路径，这条路径的分析方法与上面说的CK到D的路径分析方法类似，但是需要考虑的是recoverry和remove，由于CDN是低电平复位有效，recoverry和remove只会考虑CDN上的rise(解复位时CDN的电平变化)，fall_to CDN或者fall_from CDN会报告path is unconstrained。

最后需要注意，report_timing 的-to 是可以是时钟，但这个时钟是object(即我们创建的时钟)，而不是寄存器的CK端，这两者有很大的区别，千万不要混淆。

5.环境约束

1.input driver和input transition time约束

一个cell的延迟与两个因素有关：input transition 以及 output capacitance。

输入port工具无法知道其input transition是多少，可以通过set_input_transition来设置：

set_input_transition 0.12  [get_ports A]; #port A的input transition time为0.12 ns

如果不知道准确的input transition，可以通过set_driving_cell让工具进行估计：

set_driving_cell -lib_cell -pin Qn [get_ports A]; #port A由DFF的Qn pin驱动，-pin是可选项，如果不指定 -pin, 工具会选择cell的第一个output pin。

如果无法准确估计输入端口上的电容，应该遵守下面的规则：

（1） 约束文件选择驱动能力较弱的cell来驱动输入端口；

（2）限制输入端口的最大负载电容。

如：set_max_capacitance 1 [get_ports A]; #input port A的最大负载为1pf

2. output  load约束

与输入端口类似，我们要告诉工具输入端口上的负载是多少

set_load 2 [get_ports A] ；  # port A上的输出负载时2pf

如果不知到准确的输出负载电容是多少，可以使用lib的cell进行估计

set_load [expr  {[load_of my_lib/inv1a0/A]*3 }]；#输出需要驱动3个反相器inv1a0的A pin

如果无法准确估计输出端口上的负载，约束文件因尽量假设输入端口驱动较多的单元。

3. 线负载模型约束

线延迟会通过线负载模型(WLM)来进行计算，WLM会根据连线扇出的不同等效成不同的RC单元，然后计算延迟，工具会自动选择WLM，用户也可以手动指定。

线负载模型存在三种互联树：

互联树模型可以通过set_operating_conditions指定：

4.特征化条件和工作条件约束

这个范围以“工艺角”（Process Corners）(特征化条件)的形式给出。其思想是：把NMOS和PMOS晶体管的速度波动范围限制在由四个角所确定的矩形内

此外同一工艺角下不同的PVT(工作条件)下cell的延迟也不同，foundry在提供库文件时，一般会按照下面三种方式来给：

（1）只提供一个typical(特征化条件)库文件，但这个库文件会包含多个pvt corner(工作条件)，且包含derating model，如果特征化条件和工作条件与实际不符，需要使用减免系数(k-factor,k系数)进行减免(derate)：

此时工艺角是tt，但一个库文件包含多个pvt corner，可以通过set_operating_conditions选择不同的pvt corner:

(2)多个库文件，为不同pvt corner指定不同的工艺角，不需要进行减免：

例如 xxx_wc_xxx.db（ff工艺角）, xxx_wc_xxx.db(ss工艺角)，, xxx_typical_xxx.db(ss工艺角)

(3)多个库文件，为同一工艺角下指定不同的pvt corner，包含derating model：

例如 xxx_ss_pvt01.db,   xxx_ss_pvt02.db ,   xxx_ff_pvt01.db , xxx_ff_pvt02.db ,  xxx_tt_pvt01.db , xxx_tt_pvt02.db。

此时可以选择一个库文件，然后通过set_operating_conditions指定工作条件：