请问DC带PAD综合时出现了很大的violation应该怎么解决？

mguo

在chip的顶层加入了PAD，其中包含时钟PAD，综合的时候sdc已经写了dont touch这些PAD，但是综合出来的PAD输出点有很大的负载电容，导致上升时间很长。
猜测原因是create clock点在PAD上，IO INST的输出端就没有作为ideal clock来处理，因此1000多个负载都被考虑进去了，但是即使加上了 dont touch net也没有解决这个问题，请问这样的问题该怎么解决

mguo

刚刚试了试set ideal net，成功消掉了PAD的这个时序，不知道这样做对不对？是不是时钟路径的话在综合过程中做IDEAL处理没有影响？

jake

set_input_delay, set_output_delay是否以这个时钟为参照？
create_clock建立一个参照。参照本身变了，以这个参照为基准的其他约束也要变

mguo

jake 发表于 2021-9-17 22:53
set_input_delay, set_output_delay是否以这个时钟为参照？
create_clock建立一个参照。参照本身变了，以 ...

是的，设计里面有两个时钟，相关的端口都是以这个时钟为参照，意思是set ideal之后这些路径也会有影响吗？

mguo

mguo 发表于 2021-9-18 09:50
是的，设计里面有两个时钟，相关的端口都是以这个时钟为参照，意思是set ideal之后这些路径也会有影响吗 ...

但是ideal路径不是不传递的吗？到达寄存器的时钟端口是ideal的，输入端口和输出端口应该不会受到影响吧？

jake

mguo 发表于 2021-9-17 19:53
但是ideal路径不是不传递的吗？到达寄存器的时钟端口是ideal的，输入端口和输出端口应该不会受到影响吧？ ...

set_ideal_network后，clock path经过pad的delay变成0。对于锁存输入的寄存器，等于capture提前了。沿用以前的set_input_delay会出现过度约束。 对于锁存输出的寄存器，等于launch提前了。沿用以前的set_output_delay会出现约束过松。

mguo

jake 发表于 2021-9-18 11:21
set_ideal_network后，clock path经过pad的delay变成0。对于锁存输入的寄存器，等于capture提前了。沿用 ...

确实，这样综合之后ICC结果出了很多Violation，主要是时钟路径上的，还有PAD的transition，求教这样怎么解决比较好

jake

mguo 发表于 2021-9-18 03:11
确实，这样综合之后ICC结果出了很多Violation，主要是时钟路径上的，还有PAD的transition，求教这样怎么 ...

回到原来的现象一步步分析。

--------
但是综合出来的PAD输出点有很大的负载电容，导致上升时间很长。猜测原因是create clock点在PAD上，IO INST的输出端就没有作为ideal clock来处理，因此1000多个负载都被考虑进去了
--------
从这个描述，clock PAD的输出直接到了1000多个FF。 这是因为综合工具不做CTS，对clock network不做处理，不会在clock network上插入buffer tree。
综合时读入PAD的.lib，所以clock PAD的timing model是有的。而这个clock PAD timing model看到了1000多个负载，自然会给出很长的transition time，clock PAD的delay也就慢得一塌糊涂了。
实际上PR工具会做CTS，clock PAD的timing不会这么糟糕，但是综合工具并不知道。

再想象一下RTL。一般设计中有DFT。Clock PAD的输出首先到达的是一个scan clock mux。而且这个scan clock mux在综合里是dont_touch (Genus里推荐preserve)。这样clock PAD timing model看到的只有一个负载。后面1000多个FF都是挂在scan clock mux的输出上的，而且这个clock network是ideal network。这样就不会出现前面那种不合理的clock PAD transition time, excessive delay。
不妨问一下，这个设计是否真的不考虑DFT。是设计太小，不值得加DFT? 还是写RTL的不知道DFT留了个坑？

如果真的不需要DFT，可以在RTL里例化一个clock buffer，选稍大一点的clock buffer，X8, X10。这个clock buffer的输出驱动1000多个FF。
综合脚本里给这个clock buffer加dont_touch。这样clock PAD timing model看到的只有一个负载。
PR里把这个clock buffer的dont_touch去掉，给PR工具充分自由。

mguo

jake 发表于 2021-9-19 00:42
回到原来的现象一步步分析。

--------

因为设计很小所以没有加DFT，加上了buffer之后果然没有那么长的delay了，非常感谢！

jake

mguo 发表于 2021-9-21 21:32
因为设计很小所以没有加DFT，加上了buffer之后果然没有那么长的delay了，非常感谢！
...

好，谢谢回复确认！