求助，如何定义dc下分频时钟的问题（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分频。
求助，求助。
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吧。再适当加些裕量吧。
谢谢你的解答，但仍然有些疑惑
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似乎不够准确吧?
如下图的一个时序分析情况，在没有考虑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这个时间，是如何和真是情况一致的?
算时序是要算各个时钟的latency的，buf的延迟含在latency中。
你好的，你的意思是说，在pre分析的时候，要把div_clk定义一个latency，这个latency的值大小要和buf上的延时一致或者更大么?
然后在propagate的情况将latency都去掉?
分频时钟的latency不是会集成主时钟的latency属性么?可以给一个约束值定义分频的latency么?
对于上图的情况，如果在插了buf后，将div_clk定义在buf的输出端；而设计中有别的other_div_clk。
那么根据这样的情况，从div_clk到REG2的D端的时序就无法计算了吧?因为没有这样的路径了，
但是如果将div_clk定义在REG1的Q端，这条路径就存在了。
可以为分频时钟指定自己的latency
"
对于上图的情况，如果在插了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
我没太明白的你的意思，
1.other_div_clk的master是clk。div_clk的master也是clk
“如果，other_div_clk的master是clk，那么它也不应该接在reg1/Q”，关键是这句话没明白，“不应该接在reg1/q”?
对了，我想补充一个问题
FAQ中说：为了防止因为在REG/Q段定义generated clock，打断了dff的时序，所以建议在q的后面加上buf后，在buf的out端定义分频时钟的点。
问题：
2.为何在reg的Q端定义generated_clock会打断时序?能举个例子么?非常感谢。
我没太明白的你的意思，
1.other_div_clk的master是clk。div_clk的master也是clk
“如果，other_div_clk的master是clk，那么它也不应该接在reg1/Q”，关键是这句话没明白，“不应该接在reg1/q”?
对了，我想补充一个问题
FAQ中说：为了防止因为在REG/Q段定义generated clock，打断了dff的时序，所以建议在q的后面加上buf后，在buf的out端定义分频时钟的点。
问题：
2.为何在reg的Q端定义generated_clock会打断时序?能举个例子么?非常感谢。
---------------------------------
1. 打错了，如果other_div_clk的master是clk，那么就是说div_clk与other_div_clk没有master-slave的关系了。在你的“计算时钟latency”的大前提下，它们之间就没有latency的关系。
2.你定义一下reg/Q，然后如果有问题的话，PT会报出一个warning信息，man一下就有解释的。
1. 打错了，如果other_div_clk的master是clk，那么就是说div_clk与other_div_clk没有master-slave的关系了。在你的“计算时钟latency”的大前提下，它们之间就没有latency的关系。
问：
（1）“计算时钟latency”的大前提是什么意思?
（2）下图中红线部分是我单独给代码加上的buf，其余的部分是前端设计。加buf的目的是因为看了faq中的那句话，我才加的。加上buf之后，原本的generate_clock的定义点pin就从REG1/Q移到了buf/O。
我的问题的意思是，
下图红线部分的div_clk定义点是否合理?我感觉应该要将buf做成和“圆圈”之间串联关系，而不是现在的并联关系。
2.你定义一下reg/Q，然后如果有问题的话，PT会报出一个warning信息，man一下就有解释的。
问题：在上图中，如果将generate_clock定义在REG1/Q端，工具如果没有报告warning，是不是意味着就可以不用加个buf去定义div_clk了?考虑到如果要认为的插入一个latency去模拟buf导致的时钟插入延时，可能会有些预估值和实际值的偏差，对dc的时序分析似乎不利。
3.如果定义了buf之后再去定义generate clock，那么pr之后的generate_clock还应该定义在buf之后么?latency是否还需要保留才能做post route sta，还是去掉latency，添加propagate clock做post route sta?
小编你好，
我目前给一个设计定义的分频时钟点都是count_reg_0/Q和count_reg_4/Q；分别定义为2分频和32分频时钟。
dc的时候报告了warning：non-unate path in clock network for clock "div2_clk"("div32_clk")；
1.我确定在dc的网表中有xor门，那么这个警告可以不管么?或者应该如何处理?
2.我在论坛上看过这样的问题，有人提出可以不管这个警告，那么我应该如何处理呢?
If you do not want both the inverted and non-inverted clock waveforms to reach the clock pin of a sequential device, use the set_clock_sense command to explicitly specify the sense of the signal reaching the clock pin, either positive or negative unate, with respect to the clock source.
小编你好
1.请问，造成non-unate的原因是什么?是代码的原因还是其他的?可否举一个例子来说明?
我刚才查了些资料，明白xor gate如果两个输入都不固定的就会有non_unate的现象。问题：
1.对于我所遇到的这个警告，是否可以忽略?
2.通过什么约束可以消去这个warning，同时使得电路function正确?补充一点。设计的div2_clk和div32_clk都是连接positive edge的ff。电路中的所有reg都是工作在posidge clk下。
non-unate 的path会造成其fanout时钟波形被毁掉。
此问题应与前端设计讨论。
通过set_case_analysis可以解决。
前面那段英文解释中有另一解决方法，你也可以试试看