命令之：set_cell_mode)
情景再现1前阵子在检查 flatten sta timing 时发现 func 下存在 dft 的 timing path。主要是因为有一个 IP DB 的 scan clock 连接了 function 时钟该 IP 相应的 scan pin 也就有了 scan 相关的 timing path。该如何在 func mode 下正确的屏蔽 dft 相关 timing 呢1set_sense 停止 scan clock 向后传播上述情景中IP 的 scan clock pin 存在 func clock属实是不应该。但是项目上总有类似奇葩的例子无法避免该怎么办呢我们首先可以想到的是在 IP 的 scan clock pin 上施加命令在 func 模式下禁止任何时钟流经该 pin也就是set_sense -stop_propagation-clocks [all_clocks] ip_inst/scan_clk这种命令确实可以让我们在检查 func timing path 时滤掉 IP scan clock 相关的 timing path。但是这么做实在是有点说不通的因为 func 下这里的 scan clock pin 上确实存在时钟。只是我们通过掩耳盗铃的方式在 pt 里将其隐藏了从而工具无法在 IP DB 中分析到与该 scan pin 相关的所有 timing如果该 scan clock pin 尤其它的什么作用或者检查那么这里的做法就存在隐患这里是我纯臆想的项目经验不足看不到更深层次的东西以及存在的风险也许没问题先叠个甲。2set_case_analysis 常值化处理 dft 相关控制信号我们退一步想与 IP 无关在正常的 func 电路中加入了 dft 的 occ 模块我们往往是通过控制 dft 相关的 test_mode 信号来切换 dft clock 和 func clock 如下图所示。IP 内部其实也是类似的结构那么在 func clock 的 dft clock 都存在的情况下我们不应该是去 stop dft clock 的传播来屏蔽 dft 相关的 timing path而是要使用set_case_analysis命令对 test mode 或者其他 dft 相关的信号进行常值约束。这才是合乎情理的做法。在 func dft 电路的网表上这么做确实没问题实际情况我们对 IP 相关的所有 dft 控制信号都有 tie 0工具分析时也是如此仍然存在 dft 相关 timing path。也就是说这种方法不如上一个 set_sense -stop_propagation 的方式有效。3set_cell_mode 控制 IP mode第二种方式无效的情况下我们此刻要做的一件事情是在 IP lib 文件中确认 dft 相关 timing path 是与什么相关联pin或者 clock亦或者mode。下图展示了 IP lib 中同一个 pin 下的不同 timing 相关信息。能看到这个 pin 在一个 timing 下只与 clock pin 有关这也证明了为什么方法二的 set_case_analysis dft 相关信号没有效果。但是我们也可以注意到另一个信息pin 的 timing 还存在 mode 这个属性。vendor 提供给我们的是一份 func、scan、capture 三合一的 IP DB。也就是说我们在进行 func timing 分析时只需要 IP 的 func mode timing而不需要 scan 和 capture mode 的 timing。在 pt 环境中我们可以使用 report_cell_mode 来查看 cell mode 的开启情况如下图所示此时我们能看到 scan_capturescan_shiftfunc mode 均处于开启的状态report_cell_modeip_inst接下来我们就需要通过set_cell_mode 仅开启 func mode从而关闭 scan_capturescan_shift 这两个不需要的 mode。set_cell_modefuncip_inst后语在 pt 中存在 set_mode 和 set_cell_mode 这两个命令效果差不多具体为啥估计要问 AE 了大家可以学习后使用。本文主要是记录了一个时序分析的思维其实方法都是可取的主要是看哪种更有效果哪种更能让人信服。大家如果有什么疑问或者我讲述不正确的地方欢迎评论交流。我也想多学习学习各位大佬的经验。本文的分享就到这里感谢大家的关注。如果对使用方法有任何见解欢迎在评论区交流讨论。也期待各位前辈分享宝贵经验。
