如何debug dft 的timing violation

在实际项目中，项目后期大部分的时间都在用来fix timing violation，那么，基于确定需要fix的timing 存在violation的情况下，我们如何去找到产生问题的原因呢，下面介绍一种实际项目中和后端同事fix timing时，我们dft owner需要注意和使用的一个小技巧。

在timing signoff 阶段，我们会经常收到后端同事发给我们和dft相关的timing report，我们出了需要去确认report里面的真假path，还需要去看timing rpt，查看violation的大小以及确认这条path是否有优化过或是否还能进行优化。除此之外，我们还得从后端的角度去看待问题，那就是，需要去确认后这些violation 造成的原因，影响最大的因素是什么，是否和cell 摆放的位置不合理相关，比较工具无法做到完全的最优，可能存在一些cell摆放不合理导致data path 过长的问题。

拿innovus举例，一般情况下，后端没做一次迭代，都会有一个db文件夹，我们需要和后端起一个相同版本的innovus工具，将design load 进去

/cadence/*/tools/bin/innovus
set restore_db_file_check 0
restoreDesign */dbs/*.dat

然后在pt session 里面报出你存在violation的path，在innovus里面将path的cell 的位置显示出来，这样你就能知道你这条path的实际走线是怎么样的，就可以去判断是否和cell的摆放位置有关系。

select_obj <cell_path>
win

通过pt和版图去验证和解释timing violation的不合理性，这样就可以更加准确的找到问题的实际原因。