DC约束时钟约束问题2

qtomx30

在目前这种设计下面，不对CLKB,CLKC gen clock是可以的。为什么呢？
首先我们问为什么需要gen clock？是因为时钟路径被打断了，也就是说，如果CLKB CLKC后面有驱动独立于CLKA时钟域以外的寄存器的话，那么就会出现没有被约束的R2R路径。这是很危险的。
但是，在楼主的设计当中，CLKA CLKB CLKC本质上驱动的寄存器是一样的。不存在上面所提到的独立于某个时钟域之外的寄存器，所以不会出去没有约束的R2R路径。

第二个原因是，CLKB CLKC是CLKA的分频。所以频率不可能比CLKA高。STA的角度来看，setup最紧的肯定是CLKA。

第三个原因是，CLKA, CLKB 和CLKC在后端PR做时钟树的时候肯定是做一个时钟树（要知道时钟树是有开销的，可以复用的时候后端都会复用，对工具和设计都友好）。这个时钟树的root会在MUX的输出端。因此实际的skew会是一样的。因此hold分析无论对A B 还是C来说都是一样的。

所以，不gen CLKB CLKC不会有影响。

关于你说的第二个问题。
前端人员应该给你设计的时钟复位结构。这个文件应该详细描述他所设计的时钟和复位网络的拓扑结构。是否有手动加入的clock gating，是否有mux等等都应该被详细标明。让后端人员可以直接找到对应的器件，方便写约束。

当然，大家都不爱文档，只能戳戳戳：D

sdlyyuxi

回复 11# qtomx30

关于对hold的影响，mux之后会share tree这个也许没问题；不过mux之前，很难保证place的时候，分频reg 离分叉点很近吧？如果这里也长了tree 但又没有 gen clk constrain; 很难说SI会不会对hold有影响，特别是那种类似移位寄存器的R2Rpath，对skew很敏感吧；定义上gen clk不是坏事。

qtomx30

回复 12# sdlyyuxi
分频REG和分叉点的远近并不影响mux之后时钟树的skew大小。只是会影响整个时钟树的root-sink延迟而已。因为逻辑上，某个时刻只可能有一个时钟从mux的输出端通过，因此不需要管mux输入端3个脚之间的延迟差异。

sdlyyuxi

回复 13# qtomx30


    嗯，应该你说的是对的；skew 不会受common path影响；而且确实每次应该只会有一路时钟；
    不过，我想了想，如果不把B和C 都约束上，clock transition 工具还会去care吗？