timing setup
object
执行MCMM 的设置,根据分析和优化的需要定义Corner modes scenarios 加载 MCMM的约束;
应用 时序以及优化 的控制.
zero-interconnect timing sanity check (0互连的时序稳定性检查)
MCMM (multiple modes multiple corners)
今天的芯片必须适应多种工作模式
standby mode(待机模式)\test mode(测试模式)\low power mode(低功耗模式) \high performance 高性能模式 \normal functional mode (普通的工作模式)
能够在多种 PVT 环境下工作
Hi-T slow \Low-T fast \low-T slow \Hi-T fast \ max leackage;
concurrent （并发的）MCMM 优化
ICC允许 在多Corner 多mode组合下的 concurrent optimization(并行优化); multi-corner multi-mode 的组合称作 scenarios
例如: 定义FUNC_SLOW scenario = FUNC mode + slow Corner
并发的MCMM的优化体现在,优化是不在另外的scenario产生新的的violation的情况下,去改善一个scenario中的违例;
创建 modes corners and scenarios
在定义 scenario之前 要先定义mode 和Corners 然后对mode 和 corner 进行合适的组合;
question: 怎么算合适呢?
create_mode func
create_mode text
create_scenario -mode func -Corner ss125c
create_scenario -mode test -Corner ss125c
### 创建后的名字 就是 mode::Corner 也就是 func::ss125c
current_mode
test
# 默认当前的scenario 是你最后创建的 scenario;
# 默认的mode 和 Corner 也是 你最后创建的那一个;
current corner + current mode = current scenario;
改变当前的 Corner 或者 mode 就会改变 当前的scenario;
反之,改变当前的 scenario 就会将当前的 mode 和 Corner 一同改掉;
分类的约束
timing constraint 被分为4大类:
- mode specific 包含clock league cell (using list没听清)的定义, 会改变 timing graphy; 此类型的约束有可能改变网表的实际连接关系
- Corner specific 是包含PVT参数的constraints
- scenario specific 具体的delay 和 driving load 的信息
- global 就是全局的一些
分类后的约束指令如下 ：
scenario的约束
primetime DC 和ICC 仅使用 scenarios；
PT DC ICC中没有有 mode 和 Corner 的概念;
约束 要么是 指定scenario的 要么是 global的;
这些 scenario的约束 一般都放到同一个文件中 包含 scenario model Corner 的时序约束 例如 scenario: func_ss_125c 对于这一场景的约束 全都存放在 : func_ss125c.sdc 中;
而在ICC II 中有了 mode 和Corner 的概念 他和 scenarios 是共享的;
所以在ICC 中建议 将sdc 的约束 分成 mode Corner scenario-specific 的独立文件;
这样可以提高约束加载的效率, 但并不是必须的;
ICC II 提供了一些简单的命令 去separate(分离) scenario\mode\Corner 的文件
加载约束
为了最高效的 进行scenario的设置, 最好是将约束分成几个独立的文件;
这些约束金辉加载一次,即使他被多个scenario 共享;
能够得到更快的加载时间和更少的内存使用;
在mode Corner scenario 定义之后 将他们约束化;
确保没有缺失约束;
current_scenario M1_C1
read_sdc C1_corner.sdc
read_sdc M1_mode.sdc
read_sdc M1_C1_scenario.sdc
## 由于在M1_C1 中读取了 C1 Corner 的约束文件;
##所以在之后的 scenario 设置中 就不用 再次读入 C1 Corner;
current_scenario M2_C1
read_sdc M2_mode.sdc
read_sdc M2_C1_scenario.sdc
使用 write_script 去分离不同种类的约束
如果你继承了混合mode Corner scenario 的约束文件 可以使用 write_script 去将他们分离开来;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-phiv8IKq-1607224845638)(evernotecid://B45F1306-E510-4A24-B78B-A9E1CC2C1F3C/appyinxiangcom/12890172/ENResource/p223)]
如果你不知道正确的Corner 和 mode (意思就是 你不知道这个scenario 对应的是哪个mode 和 Corner)
可以为每一个 scenario 都创建独立的mode 和 Corner;
执行 remove_duplicate_timing_contexts 去掉相同的,重复定义的mode 和 Corner;
最后在实行write_script 获得 独立的mode Corner scenario 的约束文件;
检查时序约束;timing constraints
check_timing #检查 clock crossing 还有缺失的input/output delay;
report_exceptions #识别 sign_cycle timing exceptions: 包括 false_path (伪路径) multi-cycle path(多周期路径) asynchronous min- \ max-delay path (异步电路)
report_case_analysis # 确认正确的mode的设置;
report_disable_timing # 识别路径中不可用的timing arc (有一些不需要被优化的);
大多数的report 命令 都是对于当前scenario 做报告;
有一些指令 会有 -scenario -mode -Corner 的选项 去配置所报告的场景;
控制 MCMM的时序报告
report_timing
#报告单个最坏的 setup timing path
report_timing -Corner "C1 C4"
report_timing -mode FUNC*
report_timing -scenario "S1 S2 S5 S6"
#报告 所列有效的指定Corner mode scenario的单个最坏的setup timing path(C1 C4中只报告一个最坏的)
report_timing -report_by Corner|mode|scenario|group
#报告每一个 Corner mode scenario 以及 group的最坏的单个 setup timing path
report_timing -report_by Corner -corners "C1 C4"
## 和第二种对比 C1 C4 每组都会报告一个最坏的path
控制场景分析和优化(scenario analysis & optimization)
create_scenario 指令 会创建一个scenario 将它设置为有效 并且打开一下分析的选项:
setup & hold timing的分析
leakage and dynamic power 的分析;
max transition max& min capacitance的分析;
placement CTS routing 的优化是同时在所有scenario中发生的,是对多有可用分析的优化;
使用set_scenario_status 去限制分析的种类或者 在综合之前inactive 部分scenario;
报告 scenario status的设置:
report_scenrios
## 查看哪些 scenario 设置被setup timing的优化
get_scenarios -filter active&&setup
#hold timing 也是类似的
get_scenarios -filter active&&hold
根据操作环境 定义Corner PVT
ICC II 允许 通过 set_operating_conditions 去为每个Corner定义 PVT value;
set_operating_conditions Worst -library ss0p95v125c.db
这是一个间接的方法,依赖于 operating condition的 model 名 和名 去确定 PVT 的numbers,这种方法是不太推荐的;
下面是推荐的设置方法: 直接设置 process number voltage 以及 temperature;
current_corner ss125c
set_process_number 0.99
set_voltage 0.75
set_voltage 0.95 -object_list VDDH
set_temperature 125
工具会自动抓取 需要的lib
report library details (报告库的细节) report_lib
VT matching
如果PVT 三个元素并不是全都match的, VT resolution function 会在指定的 可用的 library pane之中找到 最接近的 VT 的匹配 ;
如果对于一个cell instance 来说 ,只有一个 可用的timing model, 那么无论 指定的PVT是啥 , 单元实例都会以这一个model 做timing;
在tapout 之前 ,必须match 到一模一样的PVT 库;
使用 process lable 去帮助 matching;
slow(ss) 和fast(ff) Corner 有着相同 的P value
那么这种 closest-match (最近匹配)并不会 pick 你想要的那个pane
process lable 的指定
在liberty .lib 中 在oprating_conditions 的第一种 使用process_lable;
在 library compiler 中 使用 set_process_lable 指令;
在使用 library configuration 的时候,使用 lib.configuration.process_lable_mapping application option;
process lable 指定为设计Corner 约束的一部分.
create_corner c_slow
set_process_number -Corner c_slow 1.0
set_process_lable -Corner c_slow slow
当指定了process lable 之后 会代替 process number 限制 VTmatching ,仅会匹配指定label的 panes;
举个例子
此时match 的pane 是 pane0; 因为 pane1 的lable 是fast;
报告所有的 没有PVT matching 的 Corner;
report_pvt
selective(挑选的) library loading
那些拥有很多pane 的library ，即使是不使用的，也会占用大量的内存 导致运行速度的下降。
你可以通过只加载需要的 panes 来优化内存的使用和运行时间；
这就需要你使用 支持multiple projects 的one-size-fits-all 的单元库 而不是 project-specific的库；
当然这需要 ICC library manager 的版本在2017.09 之后；
使用 selective library loading (单独加载选中的库)
使用 set_pvt_configuration 指定你定义的Corner 所使用的的PVTs ;
对于给定的库来说,工具只会加载 匹配的panes;没有被使用的panes 仍然在 disk中;
如果是的库有132个panes 而你配置只匹配了8个panes 那么你的 in-memory 库 就只有这8个panes;
#需要在你打开 或者创建你的设计库之前 配置PVT
set_pvt_configuration -voltage {0.75 0.95} -temperatures {-40 125} \
-process_numbers 1.0 -process_lables {slow fast}
create_lib -ref_libbs {all_panes.ndm ...}
read_verilog ...
指定TLUplus RC寄生参数模型 (parasitic RC Model);
为每一个 Corner指定 合适的TLUplus 的RC模型;
TLUplus 模型必须事先加载到 tech-only library 或者 design library 中;
#如果 TLUplus 模型并没有被加载到一个technology library中;
#他们能够被加载到design library中;
read_parasitic_tech -tlup $TLUPLUS_MAX_FILE -name Maxtlu
read_parasitic_tech -tlup $TLUPLUS_MIN_FILE -name Mintlu
#为每个Corner指定 tluplus model;
#如果已经加载到 tech lib 中 使用-library 选项
set_parasitic_parameters -Corner c_slow \
-library ${techlib} -early_spec maxtlu -late_spec maxtlu
set_parasitic_parameters -Corner c_fast \
-library ${techlib} -early_spec maxtlu -late_spec maxtlu
OCV 对时序的影响;
PVT 会在整个 die 的范围内发生变化, 或者叫做 on-chip-variation (片上变化),造成了 时序的variation;
如果在分析和优化的时候 不开率OCV 会导致 真实情况中的时序违例被忽略掉.
而且 真实情况中 process的变化是随机的,canvary from transistor to transistor;
而 voltage 和 temperature 的变化是有规律的, 一般是与相关单元的距离有关;
为OCV 建模的传统 timing derate 方法 ;
每个SLOW or FAST Corner 一般只有一个library是可用的;
应用估计的derating为PVT 的变化对组合逻辑的影响建模；
LATE derate ： slow down launch path for setup and capture path for hold;
set_timing_derate -early 0.92 # 其中的0.92是百分比；
EARLY derate : speed up capture path for setup and launch path for hold ;
set_timing_derate -late 1.04
还记得啥是 capture path 啥是launch path吗?
时序报告中， 上部分data path是 launch path 下半部分 是时钟的path 是 capture path；
时序报告中的 derate 的元素
report_timing -path full_clock_expanded -derate
#在报告中 会多一列 显示 derate的信息;
在 launch path 中的derate 是小于1 的;
而在 capture path 中的derate 是大于1 的;
使用 OCV 分析更加悲观的时序:
基于depth&distance 的 AOCV derating 计算;
AOCV advance On-chip variation
AOCV 通过 将路径的深度和距离纳入计算中能够提供更接近真实情况的 derating;
随机的P的变化模型 基于path的深度
系统的 V/T 的变化迷行 基于最大的相关timing path和nets物理距离
打开 ACOV的变化模型;
前提是你有ACOVM的table;
set_app_options -name time.acovm_enable_analysis -value true
set_app_options -name time_ocvm_enable_distance_analysis -value true
read_ocvm -Corner SLOW SLOW_derate_table
read_ocvm -Corner FAST FAST_derate_table
# derate 的table是 库的提供者提供的;
report_ocvm -type aocvm
POCV
两种POCV 的形式 GBA -PBA - 能够在同一时间被应用;
使用 Min/Max 库 为OCV 建模;
如果 min max library 是可用来 为 每个Corner 的on-chip 的变化建模； 他们除了应用 set_timing_derate 之外 还可以用以下方式指定：
current_Corner SLOW
set_voltage 0.95 -object_list VDD
set_voltage 0.98 -object_list VDD-min
set_temperature 125
set_temperature 117 -min
set_process_number -late 1.10
set_process_number -early 1.08
set_process_lable -late SLOW_MAX
set_process_lable -early SLOW_MIN
随机变化的OCV 模型参数;
POCV 并不依赖于路径深度 去建模随机变量,取而代之的是 高斯分布(正态分布)模型 for individual cell delays(单个单元的延迟)
每一个单元 都有一个 nominal (名义上的 有名无实的) 或者 平均的 delay 和一个 标准的 偏离delay 值;
路径上累计的的延迟 是由 统计学上的 每个阶段增减的delay distribution 决定的;
忽略(eliminates) GBA -based pessimism;
POCV 的输入参数 sigma () 两种形式
- POCV 系数 (coefficient)
它是以 每个库单元替丁的 input transition 和 output load 所决定的; - LVF cell delay的变化 被建模为一个公式 依据每个timing arc 的input transition 和 output load
POCV path 计算例子
timing analysis默认使用 3 sigmas
report_timing -variation
report_timing -variation -to I_ALU/Zro_Flag_reg -significant_digits 5
POCV setup
两种POCV 参数设置能形式 可以同时被应用;
LVF library (.db 或者.NDM) on some cell
POCV side file on others
set_app_options -name time.pocvm_enable_analysis -value true
set_app_options -name time.ocvm_enable_distance_ananlysis -value true
read_ocvm -corner SLOW SLOW_Pocv_coefficient_file
read_ocvm -corner SLOW SLOW_pocv_distance_table
report_ocvm -type pocvm
report_timing -variation
POCV的附加设置
如果 LVF 包含setup/hold 约束变化信息 使用:
time.enable_constraint_variation
#如果 LVF 包换 output slew variation 使用
time.enable_slew_variation
#如果如要的话 修改 the number of sigma
set_pocv_corner_signa -Corner {ff_corner} 4.0
report_ocvm -type pocvm -Corner_sigma -Corner ff_corner
## 默认 在timinganalysis 时 使用的 number of sigma 是 3;
执行 “Timing Sanity check” (时序的稳定性检查)
在布局之前 确保设计是没有被过度约束的 是十分必要的;
约束需要和设计的specification(特殊情况)是相匹配的;
在布局之前 报告 “ZIC” setup timing;
检查 不切实际 不正确的约束;
调查 在zero-interconnect (零互连)情况下 大的时序违例;
set_app_options -list {
time.delay_calculation_style zero_interconnect
time.high_fanout_net_pin_capacitance 0pF
time.high_fanout_net_threshold 32
}
update_timing -full
report_constraints -all_violators -max_delay
report_qor -summary -include setup
report_timing -slack_lesser_than 0
时序约束的可行性
需要在placement之前 识别 解决 不可行的时序约束;
实际可行的IO约束
所有必要的timing exception是 都被应用了;
如果 时序约束是不可行的 不切实际的 会浪费很多优化周期；
infeasible path example 不可行的路径实例
下面的例子 识别出了在当前场景下 的infeasible path 输出 set_path_margin 的exception 到 out.tcl文件
comput_infeasible_path_overrides -verbose -output out.tcl
## out的输出的内容;
set_apth_margin -10000.00 -setup -comment SYNOPSYS_INFEASIBLE_PATH_OVERRIDE \
-scenarios func.ss_125c -from IN1 -to instance/ff7_reg/D
infeasible path command 的细节
comput_infeasible_path_overrides
#默认是应用于 当前的scenario 的
#根据需要使用 -Corners / -modes / -scenarios
set_path_margin
#生成的这个指令:
#会应用一个timing_exception 能够被report_exception所报告;
# 经常默认会松弛时序要求10000个单位;
识别 最坏的 10000 paths 每个pathgroup
使用 -max_paths / -nworst 去修改的这个 path num
默认 不要应用 path margin;
建议生成输出文件 检查然后更正 最后 source;
可替代的使用 -apply_override_constraints 在命令执行期间应用;
附加的时序设置
使用set_app_options 寻找附加的时序application options
使用 man pages 获取更多信息;
report_app_options time*
# 会报告所有 time开头的app_options
2538
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
