PRIME TIME官方教程笔记(静态时序分析)(二)

24 篇文章 97 订阅

step2a 读入parasitic寄生参数(SPEF文件和GPD文件)

其中GDP:galaxy parasitic datapath
SPEF: 标准寄生交换文件,standard parastic exchange format;

read_parasitics -format SPEF flat.spef
read_parasitics -format GPD DPD_Dir
#支持读入milkway库
#层次化的SPEF
read_prasitics -path I_BlkB I_BLkB.aprf.gz
read_prasitics -path {U1 U2 U3} BlkC.spef.gz
read_prasitics TOP.spe.gz

step2b 检查寄生参数注解annotation

report_annotated_parasitics
report_annotated_parasitics -list_no_annotated
read_parasitics的命令会自动执行 report_annotated_parasitics 展示报告;
任何没有注释的pin-to-pin的nets需要被审查investigated
没有驱动和负载的nets 一般都是一些没用的引脚产生的,比如触发器的qbar pin,这些没有被注释是正常的;

step 3 约束文件的检查与修正

read_sdc -echo $constraint_file
#一般是.sdc文件 是DC综合后根据约束脚本吐出来的;
source -echo $constraint_file
#一般是tcl文件 ,就是我们自己编译的约束脚本
check_timing -verbose
#检查constraints的完整性
report_clock -skew -attribute
report_port -verbose
#检查时钟和端口的约束

report_design
report_exceptions -ignored
report_case_analysis
#检查设计约束和例外

Step 4a Update timing 更新时序

update_timing [-full]

#检查更新后的时序结果,就是通过生成总结报告summary report
report_global_timing [-pba]
report_qor [-pba]
report_constraint -all_violators [-pba]
report_analysis_coverage
report_global_slack

#加pba option path based analysis 在保存会话之后,避免在恢复会话session时重新计算;
coverage的分析

total met violated untested

step 4b 生成更详细的报告


report_timing \
    -input_pins -nets -capacitance -transition \
    -delay main_max -group CLK -max_path 10 \
    -slack_less infinity <other_options>
    #generate timing report in PBA mode
report_timing -pba_mode path | exhaustive $recalculated_path

save session保存会话

save_session $session_directory

save_session $session_directory
save_session $session_directory -include_libraries

# 检查保存会话的完整性
#检查曾经保存的会话版本
more $session_diractory/Readme
#检查使用的库
more $session_diractory/lib_map
#检查师傅可以restore
restore_session $session_diractory

一个保存了的session包含以下信息:

  1. 已经link的设计和加载的库
  2. 时钟,时序例外和其他的一些约束
  3. operating condition 工作条件 PVT
  4. 后标的SDF延迟和寄生参数
  5. 变量的设置
  6. 网表的修改(insert_buffer size_cell,swap_cell)
  7. 分析的数据
  8. cross-coupled 交叉耦合 延时信息和噪声信息

step6 退出

redirect -tee $exit_file {
   print_message_info 
   quit
}

implicit;盲目的,含蓄的
explicit;名确的,详述的

primetime的setup file 设置文件

setup file 和DC的Setup 文件相似,为隐藏文件,且可存在三个不同优先级的 .Synopsys_pt.setup

pt的用户定义的setup的文件,一般只用来aliases,定义常用的命令的缩写;
aliases page_on {set_app_var sh_enable_page_mode true}

history keep 200

脚本的语法检查

使用ptprocheck my_script.tcl

pt_shell -f run.tcl | tee -i run'log

##或者在shell下
source run.tcl -echo -verbose
redirect run.log {source run.tcl -echo -verbose}
;#重定向命令只下过的结果:
redirect  -tee check_timing.rpt {check_timing report_analysis_coverage}

profile
validating

完整的STA的需求
  1. 完整的设计约束,完整并不意味着正确;
  2. 运行所有需要的时序检查;
    两条命令来检查STA的完整性:
check_timing ;#标记缺失的约束
report_analysis_coverage ;#标记没有被检查的时序

bold indcates default checks

约束警告: No input delay

这类警告是默认关闭的,你需要设置变量:
set_app_var timing_input_port_default_clock true
收到这种警告信息,你需要知道:

  1. 这个输入引脚和什么相连
  2. 哪条路径会受到这条警告的影响;或者此案例缺少输入端口的分析;
    我们需要检查是否有必要约束这个port;
    一些情况下,是不需要为input port添加约束的: such as:
    1.假设这个端口驱动一个固定的信号,使用set_case_analysis 比如:A端口驱动一个mux的选择信号,检查这条命令set_case_analysis是否被应用;
    2.假设以这个port为起点的路径在当前模式的分析中是不存在的;
约束警告: No output delay

收到这类警告,你需要去知道:

  1. 输出端口M连接的是什么,寄存器还是输入端口;
  2. 这条警告所影响的路径是哪一条,他是否是一个输出的时钟端口;

输出端口必须被output delay 所约束;
如果他是一个输出的时钟端口,那么就用指定output_delay,创建一个generate_clock 然后忽略这条警告;

warning: NO clock

there are 2 register clock pin without clock
收到这类警告,你需要去知道:
哪里需要创建一个时钟去驱动受影响的端口;
manually 人为的;

时序检查: 代工厂指定和用户指定

recovery&removal啥意思?
你的工作是决定这个时需检查是否有必要,还有检查神魔原因导致时需检查没有被执行;

没有检查的时序:False_paths

false_path ;一般是用户 使用set_false_paths指定,非同步或者专用的时钟组;
收到此类的警告,你需要去知道:
1.这条时序路径包含哪个时钟;
2.F1 port的上一级触发器是:
3.哪条false_path的命令或者clock_group的命令与此warning相关;
比如: set_false_path -from F2/CLK -to F1/D

untestd timing path: user_disable

用户使用 set_disable_timing
使用L;report_analysis_coverage -status_details untested
-check_setup

其中-status_detials 会指明untested的原因:
user_disable;
出现此类的warning,你需要去知道:这个时序检查只是对指定cell(F1)无效还是定义在cell库中,对所有instance都无效;
这两者在命令的书写上是不同的:
set_disable_timing -from CLK -to D F1
set_disable_timing -from CLK -to D {get_lib_cell core_slow.db/fdesf2a15}

untested timing path:constant_disable 常量

这种警告一般出现在:

  1. 用户指定 set_case_ananlysis
  2. 信号绑定为高电平或低电平;
    出现这种警告,你需要去知道:
    这个timing的disable是不是由于用户指定的case或者恒高或者恒低电平的信号导致的;
    用户哪条约束导致了 timing的disable;
    such as:
    set_case_analysis 0 scan_en
    其中scan_en是输入信号的名字

untested timing check: no_path

他给出untested的原因是no_path的话:
这个需要配合图示进行解答:如:
用户指定:
set_disable_timing -from A -to Z U1
就会导致此问题;disable的是此路径上的一个缓冲器,导致后端的寄存器没有arrive timing; 就没办法check_timing;
所以当遇到此警告时:你需要知道:
disabletiming是否是用户指定的case造成的;

9 commands tools

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xdwabFFn-1602574989013)(evernotecid://B45F1306-E510-4A24-B78B-A9E1CC2C1F3C/appyinxiangcom/12890172/ENResource/p174)]

all_fanin 是如何工作的

当check_timing 出现constraint warning: no clock;
此时的模块工作在functional mode;在I_PLL出现 missing generated clock的warning;

使用以下commands追踪warning的来源路径:

all_fanin -startpoints -flat -to F1/CLK

trace timing arc追踪时序弧,跨层次结构,在下面几种情况下停止:

  1. input port
  2. CLK flop pin 或者G & D latch pin;
  3. 时序弧消失或者不可用的cell的输出引脚;

在路径中找到disable的timing arcs

report_disable_timing [all_fanin only_cells -to F1/CLK -flat]
PT会标记disable_arcs的原因
dissmiss clock gating logic as valid clock startpoint
all_fanout -flat -endpoint -from L1/Q

all_fanout追踪timing arcs的,不考虑模块边界,在下面情况下停止:

  1. 输出port
  2. input flop and latch pins
  3. cell里那些缺失或者不使用 timing_arcs的输入端口

从时序报告中识别出约束

clock_constraints
interface_constraints

pre versus post CTS

pre CTS 也就是在时钟树综合之前,需要用户指定时钟的network delay;clocks are created as ideal clock;
set_clock_latency 1 [get_clocks CLK]
在CTS之后; 工具有了更详细的时钟路径的延迟信息;路径中的buffer也插入完毕,所以PT会自动计算clock network 的延迟;
使用命令:
set_propagated_clock [all_clocks]

指定时钟的jitter 抖动

什么是时钟的抖动 jitter
cycle to cycle jitter in phase
duty cycle jitter
jitter是可以在PT中创建,报告,移除的;

create_clock x -name mclk -period  10
set_clock_jitter -cycle 2 -duty_cycle 3 -clock mclk
#cycle to cycle 的jitter 应用于max(setup)的path;

clock uncertainty& skew

clock_uncertainty 一般包括 clock skew 和margin(裕量)
在post CTS中,clock_uncertainty 只包含时序的裕量margin;
在传统的约束设置中,会将jitter也加入到clock_uncertainty中

约束interface path(接口路径)的一个比较清晰的解决方案

  1. 将clock_latency包含到输入延迟之中(input_delay)
set_input_delay -network_latency_included \
-source_latency_included -max 2.6 -clock clk [get_ports A]
#-max 指的是 setup time 的需要
#-min 是hold time需要

set_output_delay -max 2.5 -clock CLk [all_outputs]
set_output_delay -min -0.2 -clock CLK [all_outputs]

represented

时序报告的分析

生成总结性的报告,并保存会话
重新加载PT的会话
生成详细的信息
timing arcs的延迟计算

#design quality of results
report_qor
report_global_timing
report_global_slcak
report_constraint -all
report_analysis_coverage
report_timing
report_delay_calculation
report_qor

report_qor -only_violated
为一个总结性的报告:报告的内容包括:
违例路径组的summary;包括每条违例路径的max\min delay
还有设计的细节,和DRC的违例;

report_global_timing

internal 违例发生在内部还是I/O
会将违例按路径分成四类:
reg-reg reg-out in-reg in-out

report_global_slack

slack的总结性的报告 报告设计的setup & hold slack的信息;
或者指定pin或ports的slack
max_rise max_fall min_rise min_fall?
待补充:
报告经过指定端口的所有路径的setup hold slack信息;

  • 表示,指定的pin/port没有slack信息
    为了节省运行时间,在生成报告之前,设置:
    set_app_vartiming_save_pin_arrival_and_slack true
report_constraint

报告的是所有的违例的endpoints sorted by slack

report_analysis_coverage

violater的占比,untested的占比
setup
hold
recovery
removal
min_period
min_pulse_width
out_setup
out_hold

边缘敏感sensitivity negativ_unate

cell delay 输出从1到0 和从0 到1 的延迟是不同的
R: 表示 transitions from0 to 1
F: 表示 transitions from1 to 0
所以遂昌的数据到达时间,最短的数据到达时间,和可由的数据到达时间都是不同的:
longest: R + R+ F 当然里面有反相器
shortest : F+F+R

边缘敏感 non unate

路径中如果有一个多输入与非门,非此路径输入无法确定,
所以此路径的到达时间的可能情况一共有4种;

报告 库中的arcs :反相器

report_lib -timing_arcs cb13fs120_tsmc_max inv0d1
### 类似的 filp_flot的arcs信息
report-lib -timing_arcs cb13fs120_tsmc_max sdcrql

report_timing

stages
report_timing 默认是不会报告hierarchy pin的,为了显示hierarchy pin 可以添加option -include_hierarchical_pins
默认report_timing 会生成一个报告,包含setup time最坏的slack的情况

通过增加选项,可以实现报告每一个path group 的最坏的setup slack;
report_timing -group [get_path_group *]

-max_path选项 每个endpoint只报告一条最坏的slack
-nworst选线,就是报告情况最坏的slack的情况;

report_timing -to FF4/D -max_path 3
#也只报告一条路径
report_timing -to FF4/D -nworst 3 
#会报告此endpoint的三条路径;
report_timing -cover_design
#报告设计中每个违例pin的最坏的路径
#当你需要 capture 时钟SDRAM下降沿的 hold timing的最坏的十条路径,以总结的形式报告出来
report_timing -delay min -fall_to [get_clocks  SDRAM_CLK] -max -path end
#报告前十条setup违例的endpoints
report_timing -path summary -group SYS_2x_CLk -max_path 10
#使用-start_end_type 选项指定path的种类;
report_timing -start_end_type reg_to_reg -path_type summary -nworst 5 -nosplit
#使用 slack amount筛选违例路径
report_timing -slack_lesser_than *
report_timing -slack_greater_than *
#还可以生成类似的总结报告:
report_timing -slack_greater_than -13 -slack_lesser_than -12 -max_path 10 -path_type summary

包含input_pin 在时序报告中

report_timing -input_pins
在时序报告中,会将cell_delay和net_delay分开

STA(Static Timing Analysis)静态时序分析是设计验证中非常重要的一部分,它能够保证设计的时序满足要求,并且对于设计中存在的时序问题进行诊断和修复。PT(PrimeTime)是业界较为常用的 STA 工具之一。下面是一个 PT 做 STA 静态时序分析教程。 1. 确定时序约束 时序约束文件是进行静态时序分析的基础,它描述了设计中的时序要求。时序约束应该包括时钟频率、时钟时序、输入输出延迟等信息。在 PT 中,时序约束文件格式为 SDC(Synopsys Design Constraints)。 2. 进行时钟分析 时钟分析是静态时序分析的第一步,它能够检查时钟网络中存在的时序问题。在 PT 中,我们可以使用 clock report 命令生成时钟分析报告。时钟分析报告能够帮助我们确定时钟路径、时钟树等信息。 3. 进行时序分析 在进行时序分析之前,我们需要将设计进行综合,并产生时序数据库(.db 文件)。时序分析主要包括前端分析和后端分析,前端分析主要是对时序路径进行分析,后端分析主要是对时序路径进行优化。 在 PT 中,我们可以使用 timing report 命令生成时序分析报告,报告中包括了时序路径、时序偏差等信息。我们可以根据报告中的信息进行时序优化,例如添加时钟缓冲、调整时钟路径等操作。 4. 进行时序约束修复 在进行时序分析时,PT 会给出一些违反时序约束的警告和错误信息。我们需要根据这些信息进行时序约束修复,以保证设计满足时序要求。在 PT 中,我们可以使用 constraint report 命令生成时序约束修复报告,报告中包括了需要修复的时序约束信息。 5. 进行时序分析验证 在进行时序分析之后,我们需要进行时序分析验证,以保证时序分析结果的准确性。在 PT 中,我们可以使用 report checks 命令生成时序分析验证报告,报告中包括了时序分析结果的正确性信息。 以上就是 PT 做 STA 静态时序分析教程,希望能够对你有所帮助。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

旺旺脆兵兵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值