后端关于CTS后的uncertainty
第一，后端为什么只在timing report中报出crosstalk的影响?还有其他的SI问题不关心吗?为什么都没听过要分析SI什么的在flow中。
第一，在CTS后，有人说要执行：remove_clock_uncertainty [all_clocks],执行完这个条命令不是吧design中的setup和hold的uncertainty都去掉了?怎么可以这样?
谔谔，你确定是remove_clock_uncertainty，而不是remove clock latency
要报一下Glitch，还要报一下时钟双沿
很开心收到您的回复，可是通过什么命令来报呢?要报一下Glitch，还要报一下时钟双沿?我就知道一个-delta。
还有对您说的双沿不是特别懂，input tran和output tran?
哈哈，这都被你看出来了哦，我写错了，我其实就是不知道在CTS后，我应该怎样相应的改一下SDC约束，需要改set_input_delay?假如长完tree，我的inset delay是1，应该怎么考虑改SDC的约束?还需要改别的吗?
set_input_delay是前端预估信号到chip port的一个delay值，这个值ARP是不能去改变的。它将伴随APR的一生，一直到timing signoff
cts结束之后，clock上有了真实的delay，这个时候就需要把networklatency ideal clock什么的都去掉了，然后让工具计算clock 上的delay了。
cts之后可以使用cmd:
reset_propagated_clock [all_clocks]
update_io_latency
set_propagated_clock [all_clocks]
自己man，看一下。
encounter tool cmd，icc的不太会。
我懂了，看到资料做完CTS，应该更新IO latency，其实就是更新从clock port到reg的clock delay吧?update_clock_latency命令是会自己做的?
另外我在CTS时遇到了一些问题：就是有5个clock是同步的，但是设计中还有generate clock，我应该怎么设置balance group?您在CTS前一般是怎么分析tree结构的?感觉自己不会分析tree的结构哦，不知道怎么入手
tool generate spec file->generate trace file->cts之后看clock report，分析latency & skew。DRV什么的。
我们都是remove_clock_uncertainty [all_clocks] postcts 之后
怎么 可能，你CTS后，就一点uncertainty也不留了?！不给route留一些margin了 ?
嗯 就是这样
glitch:report_noise_common_format -type height
double switch: report_si_double_switching_common_format