物理综合就是将RTL综合为coarse-placement的网表;这需要让DC工作在TOPO mode' 并使用compile_ultra 命令;
需要一个布局文件,一般是ICC生成的;(icc ii design planning);
DC NTX in topological mode 使用virtual routing 去估计net的长度; virtual routing 使用 Manhattan distance估计两个pin之间的线网的长度;
RC参数的计算也是基于net的长度而不是fanout;
Day1: objectives
加载RTL设计和逻辑库
加载物理库和technology data 包括: physical 或 layout library (NDMdirectories) technology routing layer definition file (tf file) RC modeling files (TLUplus & map files)
加载布局的信息; TCL的物理约束或者来自ICCII的DEF文件
所以整个NTX topo mode flow的输入包括: RTL design .v文件,design constraints 设计约束文件,db库文件,物理库文件 ,floorplan的DEF文件
DCNTX flow 需要指定technology的逻辑库,才能完成综合;
标准单元库
宏单元和IP库
每个逻辑库对应单一的PVT属性或者工作条件;
通过.lib中对标准单元的表述我们可以获得以下信息:
cell的name ,面积,引脚信息,design rule constraints(每个引脚的 function max_capacitance mian_capacitance)
这个generic logic library 是由DCNTX提供的,在仅进行功能的综合时,可以用他来描述RTL结构.
通用的逻辑库用来在读入RTL文件加载入DCNTXshell转换成未布局的gtech ddc 格式
用来生成,technology-specific的门级网表;
DC NTX 会选择指定工艺库中最小的满足DRC timing和逻辑功能的单元.
在综合之前,需要指定实际的由芯片的供应商或者库组提供的标准单元库文件
set_app_var target_library libs/20nm_wc.db
使用以下命令可以查看那些从默认设置中修改的所有application variable:
get_app_var -list -only_changed_vars *
用来link设计,解析RTL设计中或者门级网表中实例化的参考;
在link设计之前指定标准单元和IP 逻辑库的名字
reference(参考),是那些门,逻辑块,子设计,在设计中的实例化
search_path = “. <install_dir>/libraries/syn
<install_dir>/dw/sim_var
"
默认的search_path包括需要的通用库的路径;
增加search_path到默认路径,而不是over_write(覆盖)
set_app_var search_path "$search_path\
mapped
libs
cons"
在相同的工具环境下会应用到所有的设计中;
设置也不会跟随设计而保存;当工具的会话结束时(tool session ends) 这些application variable会恢复到默认状态;
所以application variables需要在工具启动时重新设置;
会产生 .syn .pvl .mr文件
这些文件被保存在由 application variable"WORK”指定的路径中,默认是CWD,这会使CWD文件夹很杂乱,使用以下命令可以获得更整洁的CWD;
CWD : current design directory
define_design_lib WORK -path ./work
analyze -f verilog TOP.v
你可以指定独立的libraries name 在analyze的时候;
define_design_lib MID -path ./mid
define_design_lib BOT -path ./bot
analyze -f sverilog -library BOT bot.sv
analyze -f sverilog -library MID mid.sv
物理综合会将输入的RTL模型生成一个门级网表附带标准单元的粗布局
topo mode 会在综合时生成粗布局布线估计;但这需要物理单元库使用NDM(new data model)格式拥有technology data;并且需要布局的信息;
NDMcell library 或者叫做 CLIBs 包含frame和timing view frame view包含物理拓扑信息,timing view 包含所有的来自原始db库的信息,包含逻辑定义,时序,功耗和其他属性信息;
来自ASIC代工厂或者library group的 物理单元库,(NDM format),包括标准单元的frame view 和 IP核和宏单元的frame view;工艺信息(technology data)包括工艺文件(technology file) TLUPlus文件(RC寄生参数的信息) layer mapping files()
一个"design library”设计库用来存储工艺文件内容和指向物理单元库;
一个标准单元是用指定工艺的基础逻辑门提前设计好版图的
每个标准单元通常都有相同标准的高度
一个物理单元库包含用frame view描述的标准单元的集合,并且在NDM格式下是可用的;
DC NTX和ICCII使用相同的NDMformat,但是ICC使用的物理单元库的格式叫milkways
工艺文件,对于每一个technology来说是唯一的
定义了所有的工艺参数;这个文件主要定义的一些 layer的信息,金属,mos管的一些参数,DRCs等等;
tech file 并不会定义金属层的优先布局方向；这需要全局的基于布线的拥塞分析;
指定routing direction
set_preferred_routing_direction -layers {M1 M3 M5 M7} -direction horizontal set_preferred_routing_direction -layers {M2 M4 M5 M8 MRDL} -direction vertical
必须在读入了RTL代码或者DDC网表之后 才能设置 routing_direction 否则会报错;当前设计没有定义,无法找到object M1
包含RC的查找表
是匹配technology file和TLUPlus file的信息;
更像一个容器,包含设计所需要的工艺文件信息,并指向物理单元库;
//create the design library and set tluplus files set ndm_reference_library .../CLIB/saed32_lvt.ndm set ndm_design_library ./MY_design.dlib if{! [file isdirectory $ndm_design_library]} { create_lib -reference_library $ndm_reference_library \ -technology ./tech/saed32_1p9m.tf $ndm_design_library check_library //检查逻辑库和物理库的一致性 consistency }else{ open_lib $ndm_design_library } set_tlu_plus_files -max_tluplus ./tech/***.tluplus \ -tech2itf_map ./tech/ ***.map
解决方法:
two-Phase SPG synthesis flow; 双向的SPG综合流程
如果没有指定约束的话;
它会使用: 1. 方形的core的放置区域
核心的大小基于60%的利用率
将宏单元和标准单元一起摆放
顶层端口的位置是任意摆放的
set_utilization 0.6 标准单元利用率 60%
set_aspect_ratio 1 正方形
先将默认的utilization和aspect ratio改掉
标准单元和宏单元放在 core area
pads和 I/Opins 放在die area
默认 DCNTX 声明的core area和die diearea 是一样大的;
除非用 crate_site_row被用来定义 core area 的边界;
create_die_area -coordinate {{0 0}{600 400}}
用它来定义core area的面积边界
在经过ICCII的设计布局后,布局的信息通过 write_floorplan 输出为 DRF文件和floorplan的tcl文件
在DCNTX中加载ICCII的floorplan
create_net -power “VDD VDDL"
create_net -ground VSS
read_floorplan floorplan_dc/floorplan.tcly
读取tcl文件就会将DEF文件读入?
输出端口的电容负载会影响transition time,因此会影响到cell输出到outputdriver的delay,
DCNXT默认outpu的capa load为0;所以给output capa load 一个估计(为capa load 建模)是十分必要的;
所以设置负载的方式有两个:
直接给输出端口 赋 capa的值
set_load -max [expr {30.0/1000}] [get_ports B]
为输出端口指定具体的标准单元,利用laod_of 计算此标准单元的capa
set_load -max [load_of my_lib/AN2/A] [get_ports B]
set_laod -max [expr {[laod_of my_lib/AN@2/A] * 3}] [get_ports B]
和输出的capa 为一对 ,同样会影响 cell delay of the input gate,同样DC在默认情况下, input的transitiontime 也为0;
同样有两种方式,like output_load :来指定input_transition:
set_input_transition -max 0.12 [get_ports A]
set_driver_cell -max -lib_cell OR3B[get_ports A] 对于这种一输出的门来说,不用指定pin
set_driver_cell -max -lib_cell FD1 -pin Qn [get_ports A]
load budget assumptions 负载预算假设;
应用一个弱驱动,在输入引脚(作为保护) :inv1a1
应用一个合理情况下最大的负载;
_
_(待补充)
reset_design
source timing_budget.tcl
set all_in_exp_clk ...
set_driver_cell -max -no_design_rule -lib_cell inv1a1 $all_in_exp_clk
set max_capacitance [expr {[load_of ssc_core_slow/and2a1/A]* 10 }] &all_in_exp_clk
set_load -max [expr {[load_of ssc_core_slow/and2a1/A] * 3 }] [all_outputs]
其中set_max_capacitance是设计规则的约束 DRC 限制一个端口扇出的capacitance,默认情况下,DRCs 比时序面积约束又会更高的优先级;所以不要过度约束用户定义的DRCs 是十分重要的;
高质量的RTL代码 适合综合的
完整精确的约束
适用所有DC ultra的优化选项
利用DCNXT 物理指向的有点;
简化综合流程,对大的设计最好使用 top-down的综合
1, 三个层次上的优化
architecture
logic level
gate level
soft IP和datapath 元件的集合,这里的IP主要是算术运算符的小IP
当输入输出的宽度超过4bit的话,会封装成hierarchy
DW库会使用数据路径生成器去建立不同算术运算符的运算结构
这些不同的结构使得compile_ultra可以选择执行最好的结构应用到设计中;
一旦选择了某一结构的运算符,便会针对目标工艺库进行优化;
CSA: carry save adder,其实指的是carry save adder tree; 超前进位加法器;
超前进位加法器在大部分情况下,相较于传统的加法器,是小而快的;
在compile_ultra下国建路径的二次综合会在需要的时候自动执行;
CPR (critical path re-synthesis)在compile指令下也可以执行,加option -map_effort high
当门级不符合时序,或存在违例的关键路径,会返回logic_level进行忧化;然后再次mapping 网表;这样循环往复;
会减少critical_path的延迟,得到更快的电路,但是面积会更大;
这个选项是常开的,没有option可以将其关闭;
会利用库中的单元,创建一个缓存区,存储一些常用复杂布尔运算逻辑的实现
会得到的更好的面积优化的结果;
ALIB 对于每一个工艺库都会生成一次,可以在下次使用此库时继续使用,也可被别的用户使用;
当ALIB不存在时候,使用alib_analyze_libs命令,可以人为生成ALIB,一般在第一次执行compile_ultra命令时,会自动生成,使用alib_library_analysis_path选项,指定ALIB生成的文件路径;
默认综合必须保持子模块在层次上pins的定义;
旨在优化逻辑上冗余,可以被合并或者剔除的逻辑门;
它会自动将poorly partition(congestion 比较大)的层次解组,所谓的poorly partition:如果他的数据输入,并不是直接与寄存器输出相连,或者所有的输出是不被储存的;换句话说:一个好的分割(well partition),的子设计没有用 没有时钟的组合逻辑或者寄存器输入作为层次便捷的划分;
可以在compile_ultra 后加option 解除自动的ungroup;
compile_ultra -no_autoungroup;
也可以指定不能被ungroup的design或者cell;
自动的ungroup允许组合和时序偶记电路的优化;,但是这会可能影响形式验证
在综合期间,工具会自动生成default.svf文件,这个文件记录了设计中的边界优化,寄存器复制和ungroup;可以被formality 做形式验证时读入;
set_svf <My_svf.svf> 命令可以自定义svf文件的名字,此命令要在读入RTL设计之前执行;
auto_ungroup 也会自动解除DW库的hierarchy结构;可以单独控制不对DW库做ungroup;
set_app_var compile_ultra_ungroup_dw false
在未开启ungroup的时候,compile_ultra 还会利用boundary optimization在保持当前hierarchy结构的前提下,对sub_design的内部边界逻辑进行优化;
当然边界优化也是可控的,通过设置app_var 可以指定design不被边界优化,+option,关闭compile_ultra的自动boundary optimization;
将涉及划分成子设计或者块(block) 对于大型的设计来说是十分必要的,driven by following:
划分单独的功能区
实现可行的规模和复杂性
在团队工作中管理项目
设计的复用;
在可用的内存资源和可接受的运行时间的允许下尽可能大的划分block;
划分sub_design尽可能用寄存器作为输出;
考虑层次化布局的需要;
compile_ultra 在-scan的option下 会自动将电路的移位寄存器进行识别,并直将第一个寄存器替换为扫描链用的寄存器;
默认是自动打开的,可以通过设置appvar将其关闭;
通过移动寄存器,去减少关键路径的违例;(WNS) worst negative slack; 特别是对于pipeline结构的逻辑电路来说;
Adaptive retiming 通过移动,分割,合并寄存器来实现WNS的减少;
end_to_end的功能并不会改变;
如果综合后的网表文件中存在 R_##的寄存器 就说明此设计被retiming了
可以指定特定的cell 和设计不被retiming:set_dont_retime <cell name or designs> true
默认情况下,max_transition max_fanout max_capacitance 这些DRCs拥有更高的优先级,相较于timing来说;如果智能优化解决DRC的违例和时序的违例其中的一个,那么DRC的违例会被解决;
但是有是有对于综合来说,fix setup timing要比DRC违例要更重要;
所以可以使用以下命令: set_cost_priority -delay
在许多工艺库中,那些不伤害delay的情况下没有办法被修复的重大的DRC的违例,像:输入端口存在大量的外部负载,或者在一端标记dont_touch的逻辑,将max_delay的优先级放在DRC之前,允许这些DRC的违例在不伤害delay的情况下去解决;
比如 DCNXT 可能会在另外一个模块里面重新设置驱动的大小;
当综合一个小的逻辑块的时候:比如从一个大设计中摘取出的一小部分电路区域;很有可能在这个块的边界其over_constraints 比较高,在他重组进大的设计之前,最好将DRC的fixing放在次要的位置;(postponed)
默认情况下:DRC的fixing对于那些直接与寄存器的时钟引脚相连的时钟网络来说是关闭的;
时钟网络从clockpin 被逻辑分离出来的不是DRC无效的,可能会添加buffer 使其满足DRC;
当然有办法将所有的时钟网络都是DRC检查无效的;
set_auto_disable_drc_nets -on_clock_network true
这里有好几种方式可以将时钟网络的DRC检查关闭:
除了上面的哪种方法之外,做常用的还有:
set_dont_touch_network [get_ports clk]
set_ideal_network [get_ports clk]
在综合期间每一个时序路径,都会依照路径相关联的时钟放在一个路径组中;
DC NXT会依次优化每一个路径组;每一个路径组中的关键路径;
使用report_path_group 可以报告当前的设计中定义的路径分组;
默认情况下,优化停止的条件是:
这个路径组中的所有的路径都满足时序要求
或者 critical_path没有办法进一步被优化,
在默认分组的情况下很容易产生的问题就是;
比critical_path稍微好一点,但也是违例的路径是不会被优化的;
however: 如果sub_critical_path和critical_path是互相缠绕的,也就是说他们有共享的逻辑电路:很有可能通过提升critical_pathd的timing,就可以解决sub_critical_path的timing问题;
用户定义的路径组允许在优化时更多的控制;
每一个路径组都是独立优化的;
一组中最坏的违例不会阻止另一组的违例优化;
group_path -name INPUTS -from [all_inputs]
group_path -name OUTPUTS -to [all_outputs]
group_path -name COMBO -from [all_inputs] -to [all_outputs]
group_path -name clk -critical_rang 0.2
0.2 这个range 不能超过时钟周期的10%
report_path_group
set_app_var palcer_tns_driven true
compile_ultra
减少大型的数据路径的delay;
尝试将datapath中改为流水线结构; 用面积换delay;
直接将比较长的公式,拆解成几步去完成;
此时时钟的频率被运行最慢的流水线级所限制;
在综合之前设置application variable: set_optimize_register true -design Pipeline
在执行 compile_ultra
register retiming和adaptive retiming是不太相同的,但可以交替使用;
register retiming 的目的是提升纯流水线结构设计的时序和面积
而adaptive retiming目标是减少非pipeline设计的WNS
所以两个优化是可以同时执行的,
所以可以将寄存器(几级流水线,就插几级寄存器)放在要优化的datapath的最前面或者最后见面,用register retiming自己去规划将流水线插在哪.
它会使每一级流水线的所用的时间都是差不多的;
