视频 数字逻辑综合工具实践 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约束不就相当于startpoint被约束了吗？但还是有一些地方需要注意，不然初学者在使用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端，这两者有很大的区别，千万不要混淆。
