cts后，latency差异导致output delay违背的问题

在icc中，function下有一条路径是这样约束的：set_output_delay -max 7 -clock ClkX [get_ports X_PAD]其中ClkX为在RTL中例化的一个buffer的输出，而在cts的约束中，ClkX定义为一个时种树的起点。
文字很难表达清楚，我下面画图在最下面。
现在问题是，做完cts后，有一条从ClkX的tree上寄存器到X_PAD的路径setup违背，我看了一下报告，
主要是因为工具计算这个寄存器的clk latency与约束中ClkX的latency不一致导致的，寄存器的clk latency
为实际的clk tree的latency（下图中B点），而ClkX的latency就按时种树起点位置计算的latency（下图中A点），
这样从latency上timing就差了2个ns。

|-------buffer
|----buffer----|-------buffer
||-------buffer
ClkX（A点）---|
|
|-------buffer
|----buffer----|-------buffer
|-------buffer（B点）
请教一下大家，在icc中这种情况怎么能让工具正确计算output delay约束中ClkX的latency呢?

对于这种output delay引起的违例，icc的计算方法本身是没问题的。
至于能不能接受这个违例，那得和做前端的商量了。比如他说板子上的clk端也有一个差不多大的delay，那就没问题。

约束中写的set_clock_latency没有什么作用,在生成clock tree的时候,工具会自己决定做多长,在sdc中我一般是把该约束删除掉,(source latency还是要保留的),另外你的时钟周期是多大,可以问问前端,看看是否可以更改这个output_delay?

update io latency

这个可以问下设计，X_PAD 是否需要那么大的output delya 可否改?

寄存器上的clock latency就应该从root 到clk之间的delay

当时这个约束是按时钟周期的30%来定的，从上面各位的回复来看，看来没有好的方法解决这个问题，只能修改约束，把output delay减小了