数字PR, tempus 报 data to data check violation

haier822

大家好，
跑tempus 分析后报出这样 关于 data to data check的violation, 不明白为啥这里的phase shift：-49.98（周期）， 要对参考数据沿提前一个周期。这样slack time 出现很大的违例-33.7767。有知道的朋友们吗，请指教，谢谢！
PS: RN的数据来源于 clock leading edge， SN的数据来源于clock trailing edge

                               
登录/注册后可看大图

jake

Data-to-data check 属于 zero-cycle check。
这里的 phase shift 是由于时钟沿不同造成的，leading edge, trailing edge，画个图会清楚一些。
加个multicycle path可以避免phase shift。
set_multicycle_path -setup -to AutoBalance_flag_neg_sync1_reg/SN 1

本质上还是由于AutoBalance_flag_neg_sync1_reg同时带有SN, RN造成的。这两个pin之间在.lib里有non-seq check。
如果SN, RN的变化在时间上有一定的差别，理论上OK，实际使用还是会有麻烦，除非设计上就保证只有SN会变，或只有RN会变。

貌似有个更大的问题，报告中的时钟为scan_clock，scan mode下flop的RN, SN应该来自ATE可控的pin。目前这个样子像是没有插入DFT mux，要么DFT DRC不过，要么覆盖率大打折扣。

haier822

jake 发表于 2023-12-30 12:48
Data-to-data check 属于 zero-cycle check。
这里的 phase shift 是由于时钟沿不同造成的，leading edge,  ...

非常感谢Jake您的回复！如下我回复了些信息，方便看到不对的地方还请多指正，多谢！！！

Data-to-data check 属于 zero-cycle check。 这里的 phase shift 是由于时钟沿不同造成的，leading edge, trailing edge，画个图会清楚一些。 加个multicycle path可以避免phase shift。 set_multicycle_path -setup -to AutoBalance_flag_neg_sync1_reg/SN 1 Haier>>学习了。后面试下。对于hold是不是也要写下：set_multicycle_path -hold-to AutoBalance_flag_neg_sync1_reg/SN 1 本质上还是由于AutoBalance_flag_neg_sync1_reg同时带有SN, RN造成的。这两个pin之间在.lib里有non-seq check。 如果SN, RN的变化在时间上有一定的差别，理论上OK，实际使用还是会有麻烦，除非设计上就保证只有SN会变，或只有RN会变。 Haier>>是的，确实是.lib有 timing_type : non_seq_setup_rising;  /timing_type : non_seq_hold_rising;   貌似有个更大的问题，报告中的时钟为scan_clock，scan mode下flop的RN, SN应该来自ATE可控的pin。目前这个样子像是没有插入DFT mux，要么DFT DRC不过，要么覆盖率大打折扣。 Haier>>谢谢您注意到这个，发完贴后来我们也发现这个问题，在scan mode下，这RN, SN设计中缺少了DFT mux，设计中需要去加的。后面要在rtl中分别对复位端逻辑（netlist中对应RN）和置位端逻辑(netlist中对应SN)分别加入DFT MUX，在后期测试的时候一次测试只测试一端比如RN, 另一端SN保持无效状态High。下一次pattern来测试SN端， 另一端RN保持无效状态High。确保一个时间只有SN会变或者RN会变，这样在scan mode测试中避开了RN, SN之间的non seq check timing 问题。 另外在function mode下， 复位端逻辑和置位端逻辑属于异步逻辑，复位信号来自于模拟，置位信号来自数字内部，在功能角度已经可以保证同一时间只会变化一端。

jake

haier822 发表于 2023-12-30 10:33
非常感谢Jake您的回复！如下我回复了些信息，方便看到不对的地方还请多指正，多谢！！！

我把自己的分析写了下来，也许有参考价值。

STA: non-seq check, data-to-data check - jake的日志 - EETOP 创芯网论坛 (原名：电子顶级开发网) -

haier822

jake 发表于 2023-12-31 09:00
我把自己的分析写了下来，也许有参考价值。

STA: non-seq check, data-to-data check - jake的日志 - EE ...

Hi  Jake,  非常感谢您的帮忙解惑，同时还写了一份分析总结，挺全面的，受益匪浅！加深了对toool在分析data to data类型的timing所执行的zero cycle原则的理解，以常规data to CK分析setup 时序时的phase shift情况作参考，想到这四种情况：
case 1: launch clock是正沿，capture clock是正沿的情况下，phase shift 加上1T (next clock cycle);
case 2: launch clock是正沿，capture clock是负沿的情况下，phase shift 为0T，不加delay;
case 3: launch clock是负沿，capture clock是正沿的情况下，phase shift 加上1T (next clock cycle);
case 4: launch clock是负沿，capture clock是负沿的情况下，phase shift 加上1T (next clock cycle);


当进行data to data 时序分析时，所用的zero cycle原则就要对related pin在原来分析data to clock的phase shift基础上统一减去1T, 就是说对related pin类似上面data to clock的case 1/3/4, 那么就要对phase shift在原来的加上1T的情况下减去1T，最终得到phase shift: 0T.  如果related pin类似上面data to clock的case 2，那么就要对phase shift在原来的0T的情况下减去1T, 最终得到phase shift: -1T。目前终于理解了data to data 报告中的phase shift这一项是如何得出的，尤其那个 -1T的phase shift.



确实是要尽量避免使用复位端和置位端的FF，以避免涉及置位端和复位端两者之间的non seq timing check。我的理解如果一旦涉及这两者之间的non seq timing check，由于non seq timing check 是检查两者之间的时序，而两者信号必然有先后，比如SDN 到来时刻在CDN 到来之前，这就会可能出现CDN的setup timing 是过的，那就以为意味着反过来相对另外一个比如SDN的setup timing 一定是有违例的（因为CDN到来在SDN到来之后）。所以假若必须要用到这种带有复位端和置位端的FF，一定要从设计层面确保复位和置位信号时间上是分开的。



另外次要地，我们发现tempus 默认分析这种data-to-data non seq check, 好奇innovus为什么没有做这种分析。后来发现是innovus 默认不分析这种。setOptMode 中的enableDataToDataChecks 默认是false的。如果你也想在innovus中报下data-to-data check，需要把它设为true，innovus才会做这种分析。具体在前面postroute中 fix hold时序之后再加入下面命令（根据具体innovus help解释，如果设了enableDataToDataChecks true， tool只会分析这种data to data 而不会分析其他种类timing，所以要在前面已经fix hold timing动作之后再来做这个data to data check），主要是setOptMode  -enableDataToDataChecks  true（由默认的false改为true），其他的默认已经是false的了，这里是显性的重复设置下。

相关的命令有：
##enable data2data check
set_global timing_disable_library_data_to_data_checks false
set_global timing_disable_user_data_to_data_checks false
set_global timing_disable_backward_compatible_comb_path_delay_path_group_mode true
setOptMode  -enableDataToDataChecks  true

在此命令之后在report_timing -check_type data_setup ...， 就可以报出来和tempus基本一致的data-to-data non seq timing violation了。

jake

haier822 发表于 2024-1-1 09:55
Hi  Jake,  非常感谢您的帮忙解惑，同时还写了一份分析总结，挺全面的，受益匪浅！加深了对toool在分析dat ...

感谢！

我在日志后面加了到这里的链接，希望不介意！
新年快乐！

haier822

jake 发表于 2024-1-2 00:45
感谢！

我在日志后面加了到这里的链接，希望不介意！

谢谢，挺好的，您客气了，完全支持，这样能更完整，更能让其他朋友受益。


新年快乐！

susu

学习了谢谢

枫夜

学习了，谢谢