求助，如何定义dc下分频时钟的问题（FAQ中的疑惑）

AveryYoung

在后端FAQ中提到：

定义时钟的技巧中提到的，将分频计数器的Q端后面加上一个buf，然后从buf的输出点定义generated_clock，我有些疑问。

1.用多大的buf比较好？
2.如果主时钟clk和分频时钟之间有时序交互，需要分析时序路径，那么-from clk -to div2_clk的路径已经变成了从clk到buf输出端的路径，而不是从clk到分频输出端Q的路径，这地时序是否有影响？
3.如果主时钟的uncertainty为0.5ns已知，那么其分频时钟的uncertainty应该取多少？比如2分频和32分频。

AveryYoung

求助，求助。

sjtusonic

1.用多大的buf比较好？
用个跟前面reg/Q端驱动能力匹配的就好，后面的CTS会管。

2.如果主时钟clk和分频时钟之间有时序交互，需要分析时序路径，那么-from clk -to div2_clk的路径已经变成了从clk到buf输出端的路径，而不是从clk到分频输出端Q的路径，这地时序是否有影响？
设置propagated之后就不会有影响了。

3.如果主时钟的uncertainty为0.5ns已知，那么其分频时钟的uncertainty应该取多少？比如2分频和32分频。
从电路行为上来估计，应该是2*0.5ns吧。再适当加些裕量吧。

AveryYoung

回复 3# sjtusonic


    谢谢你的解答，但仍然有些疑惑

1.真实的时钟是从count_reg的Q端输出的，但是如果加了buf后从buf的输出O作为定义的generate_clock。那么在没有propagate_clock属性时（也就是pre route的dc下timing分析），主时钟clk和分频clk_div之间的时序检查报告的检查结果时间时间应该是不一样的吧？

2.即使定义了propagate clock在post route的情况下做分析，定义的是分频是时钟仍然是是及格buf的O端，工具如何在检查从clk 到clk2的时序，data_arrival_time是从clk域下的情况来分析，data_require_time是中div_clk来分析，但是div_clk因为多加了一个buf的延时，分析出来的data_require_time似乎不够准确吧？

AveryYoung

回复 3# sjtusonic


    如下图的一个时序分析情况，在没有考虑propagate_clock时，也就是preroute时的dc下timing分析：

如果div_clk定义在一个buf之后，
    假设REG2的CK端收到div_clk的时间为T（也就是REG2下对setup的data_require_time检查），而如果将div_clk定义到buf_clk之前时这个data_require_time的时间就会变成T+Tbuf。显然两者的timing分析结果不一样。

如果定义了propagate_clock，也就是post route之后，工具会如何考虑到加上buf后的data_require_time我不太理解。
generate_clock的pin还是定义在buf之后，工具分析这个timing应该仍然是T这个时间，是如何和真是情况一致的？

sjtusonic

回复 4# AveryYoung


    算时序是要算各个时钟的latency的，buf的延迟含在latency中。

AveryYoung

回复 6# sjtusonic


    你好的，你的意思是说，在pre分析的时候，要把div_clk定义一个latency，这个latency的值大小要和buf上的延时一致或者更大么？
然后在propagate的情况将latency都去掉？

分频时钟的latency不是会集成主时钟的latency属性么？可以给一个约束值定义分频的latency么？

AveryYoung

回复 6# sjtusonic


   
对于上图的情况，如果在插了buf后，将div_clk定义在buf的输出端；而设计中有别的other_div_clk。
那么根据这样的情况，从div_clk到REG2的D端的时序就无法计算了吧？因为没有这样的路径了，
但是如果将div_clk定义在REG1的Q端，这条路径就存在了。

sjtusonic

回复 7# AveryYoung


    可以为分频时钟指定自己的latency

sjtusonic

回复 8# AveryYoung


"
    对于上图的情况，如果在插了buf后，将div_clk定义在buf的输出端；而设计中有别的other_div_clk。
那么根据这样的情况，从div_clk到REG2的D端的时序就无法计算了吧？因为没有这样的路径了，
但是如果将div_clk定义在REG1的Q端，这条路径就存在了。"

从你的图中来看，other_div_clk的master是div_clk，那么它应该接在buf的fanout后面。

如果，other_div_clk的master是clk，那么它也不应该接在reg1/Q