如何在shell单元建立washer_STA | 8. SDC是如何炼成的？验收篇如履薄冰

最新推荐文章于 2023-10-18 11:36:51 发布

weixin_40002224

最新推荐文章于 2023-10-18 11:36:51 发布

阅读量256

点赞数

文章标签：如何在shell单元建立washer

本文链接：https://blog.csdn.net/weixin_40002224/article/details/112066820

版权

本文介绍了如何在项目早期验收和检查时序设计约束（SDC），通过PT工具的check_timing命令深度检查SDC的完整性，以及使用report_analysis_coverage命令统计未满足的约束。此外，还强调了异步路径检查和跨时钟域一致性的重要性，并提供了相关工具和命令的使用方法。

摘要由CSDN通过智能技术生成

你好，我是老本(Benjamin)。转发需注明作者和原文链接！

STA是由SDC驱动的，所以SDC的完整性、正确性和一致性直接决定着综合、布局布线以及STA的有效性。

在STA系列开篇文章《STA | 0. 静态时序分析概述》就提到了其局限性，通过后仿真不但可以弥补STA方法的缺漏，而且可以很大程度上佐证SDC的正确性。特别是对于接口时序约束，牵涉到标准协议和异步关系等，后仿真如果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.vptc_shell> link_design topptc_shell> source top_constraints.tclptc_shell> link_design -add block1ptc_shell> source block1_constraints.tclptc_shell> set out_dir /user/abc/compare_topptc_shell> compare_block_to_top -block_design block1

GCA中也可以打印出跨时钟域信息，通过以下命令：