关于set_clock_latency的疑问
set_clock_latency7[get_pins {xxx/A/CK}]
set_clock_latency-1[get_pins {xxx/B/CK}]
两个CK pin均为launch path！
CTS时，tool自动产生的spec文件针对上述latency转变为了以下语句：
set_ccopt_property insertion_delay -pin xxx/A/CK-1
set_ccopt_property insertion_delay -pin xxx/B/CK1
（1）非常不理解tool为何会将7，变insertion_delay为-1，以及将-1，变为了1?
（2）在preCTS阶段为何将set_clock_latency 设为-1?设为-1意为placement阶段此CK pin latency比其他path latency少-1，这样设定对tool优化setup time是不利的啊，为何要这样设定?
求高人指点迷津，谢谢！
edi没用过，icc做cts默认是不honor sdc里的set_clock_latency的
其实看了你的问题我也有疑问，cts之前clock不应该都是ideal的吗，sdc的问题还是问前端designer确认下吧
你这个应该是应用了prects usefulskew，所以在place database会保存相应的latency信息。
set_clock_latency7[get_pins {xxx/A/CK}]是想向后面借7ns的slack
set_clock_latency-1[get_pins {xxx/B/CK}]是想向前面借1ns的slack
cts时，相应的latency会在ccopt spec中变为insertion delay，即macro model
而xxx/A/CK的insertion delay变为-1，应该是因为useful skew最大只能借1ns，不允许借7ns那么多。相应参数 setUsefulskewMode -maxAllowedDelay.
确实最大只能借1ns
默认是1ns，可以人为的修改到任意值
CTS之前是ideal的状态，designer这样设定是为了在preCTS阶段先去给定一个模拟的tree上latency去优化相应的data path。
spec中还有一句将insertion delay变为-3的，在帖子中我没有写，这个也是tool自动带出的。很不理解tool是怎么根据sdc中set_clock_latency的值，得到spec中insertion delay值的?
ccopt还有选项叫ccopt_auto_limit_insertion_delay和几个类似的选项，同时对做tree时insertion delay有限制，只是猜测可能会有影响。最好看看你们的flow 脚本，应该是哪个选项设置导致。还有prects useful skew应该就受到maxAllowedDelay的限制，你确定place阶段能够借7ns这么多，一条clock tree怎么会这么长?
谢谢您的回复，tree长，是因为这是whole chip的clock tree，clock从PLL出来分频之后要从chip的一端走到另一端，所以tree会很长。您说的setUsefulskewMode -maxAllowedDelay 我get了一下，tool的默认值是1，并没有进行过人为的修改，但tool还是会将想关的clock_latency 转变为-3 的insertion delay。UG上面也有相关的转变指令介绍，但只是局限于set_clock_latency转变为insertion delay这句简短的粗略介绍....很无奈，毕竟带出的spec也只是一个参考，再次感谢！