电子说
STA是由SDC驱动的,所以SDC的完整性、正确性和一致性直接决定着综合、布局布线以及STA的有效性。
特别是对于接口时序约束,牵涉到标准协议和异步关系等,后仿真如果PASS可以让SDC作者睡得更香甜些。
后仿真一般是验证团队的职能领域,需要后端提供网表和SDF,不过后仿真需要后端所提供数据的时序是有要求的,其中hold timing必须干净,setup timing最好能干净,实在不行可以通过降频让setup满足。由此可见,后仿真往往是在项目后期才能够被执行。那我们在项目前期怎么去验收SDC呢?有了标准就不至于整天提心吊胆。下面以PT为例来进行讲解,其它工具会有些许区别。
check_timing
check_timing这个命令是在对时序约束做一个深度的体检,能检查时序约束相关的各种问题,其默认检查项是有下面的这个变量控制的:
pt_shell > printvar timing_check_defaults
这个变量的工具默认值:
generated_clocks
检查generated_clocks的定义是否合理,有没有源时钟,是否存在相互循环定义的情况。
generic
检查是否存在unmapped的cells,这类generic cell一般是零延时,影响时序检查准确性。
latch_fanout
检查电平触发latch的扇出是不是自身,有没有latch级联的情况
loops
检查组合逻辑有没有反馈回路,STA对这种反馈回路是不会分析的,需要通过set_disable_timing来打断这种反馈回路
no_clock
检查是否有时序单元的clock pin不在任何时钟网络上,特别留意中途是不是通过“set_sense -stop_propagation”之类的命令强制切断了时钟的传播。
no_input_delay
检查Input Port是否有关联的时钟,否则相关IN2REG路径是unconstrained的。
partial_input_delay
检查在set_input_delay时,是否存在只指定-min或者-max其中之一的情况
unconstrained_endpoints
检查时序单元数据Pins或者Output Ports是否没有max delay约束
unexpandable_clocks
检查相关的clocks之间是否可扩展,在跨两个不同频率的时钟路径上计算时序时,往往需要扩展时钟以计算相应的setup timing
no_driving_cell
检查Input Port是否定义了驱动单元,工具只会在相连的net有寄生参数存在时才会产生Warning信息
pulse_clock_non_pulse_clock_merge
检查pulse clock和normal clock是否共用相同时钟网络
pll_configuration
检查PLL的配置是否存在问题。
对于check_timing报告中的Warning和Error,要仔细地检查,最好是一个Warning/Error都没有,下面的结果也挺令人赏心悦目的(仅有2个Warning需要排查):
需要注意的是,在综合阶段需要先check_design保证设计本身没有问题的情况下,再通过check_timing进行时序约束的检查。
report_analysis_coverage
report_analysis_coverage命令可以统计出有design中需要STA进行的检查有多少项,其中有多少满足(Met),有多少违反(Violated),有多少缺失检查(Untested),如下图所示:
需要特别注意的是Untested一栏,造成的原因可以有以下几类:
false_paths
set_false_path 或者asynchronous/exclusive clock groups
user_disabled
timing check被用户禁用了,例如set_disable_timing
constant_disabled
set_case_analysis或者实际Signal已经接电源或地(Tie High/Low)
no_paths
路径不存在或被切断,造成原因也可能是set_disable_timing
mode_disabled
特定mode相关时序约束,在其他mode下不会检查
no_endpoint_clock
endpoint没有时钟
no_startpoint_clock
startpoint没有时钟
no_constrained_clock
针对skew和clock separation检查,没有约束时钟
no_ref_clok
针对skew和clock separation检查,没有参考时钟
no_clock
针对min_pulse_width和min_period检查,没有时钟定义
unknown
其它未知原因
具体可以通过以下命令来debug:
pt_shell > report_analysis_coverage -status_detail untested -check setup
需要特别强调 :对于异步路径,比如false_path,case_analysis,set_disable_timing等等,每一条SDC语句都需要designer仔细review确认,签字画押。
一致性和CDC检查
对于Top,往往还需要检查Top和Block的约束的一致性,以及跨时钟域检查。这里常用两个工具:一个是PT的GCA,适合门级网表的分析。另一个是SpyGlass,常用在RTL级别。
下图是GCA一般流程:
如果要进行Top和Block约束的一致性检查,可以参考以下命令:
ptc_shell > read_verilog ./top.v
ptc_shell > link_design top
ptc_shell > source top_constraints.tcl
ptc_shell > link_design -add block1
ptc_shell > source block1_constraints.tcl
ptc_shell > set out_dir /user/abc/compare_top
ptc_shell > compare_block_to_top -block_design block1
GCA中也可以打印出跨时钟域信息,通过以下命令:
ptc_shell > report_clock_crossing
需要强调 ,在RTL交付前,跨时钟域的检查是非常关键的,利用SpyGlass等工具检查其是否存在时钟同步单元(synchronizer),并在需要时添加必要的约束控制跨时钟路径,避免功能错误。另外,SpyGlass也能够进行约束一致性检查,有兴趣的可以查看其用户手册。
全部0条评论
快来发表一下你的评论吧 !