如果数据端输入是异步的，这个端口还需要做set_input_delay吗？

你可以将这个input相关的clk create成一个virtual clk，然后set_input_delay的clk指定为这个virtual clk。个人建议在DC综合的时候不要加AC相关的约束，因为DC看不到真实的物理信息，在PR工具优化的时候加上。

原来的clk就不用create了? 这个“virtual clk”有什么作用?与原来有什么不同?对input delay有影响吗?
“在DC综合的时候不要加AC相关的约束”指的是哪些约束?比如说?
谢谢！

原来的clk当然也要create了，你不是说这是个异步的input吗，那就把drive这个input的clk create成virtual clk。AC相关就是指约束input->reg ,reg -> output这种path的constraint，有可能是set_max_delay也有可能是set_input_delay，他指的是你的这个design里用来约束这种path的命令。

谢谢！
对不起，我的说法有问题。我的意思是这个输入口是静态的，和时钟没有关系。就比如是设计中我能改变的一个输入常数，或是一个使能标志位。这种情况，input delay需要怎么设置?

“约束input->reg ,reg -> output这种path的constraint” 这中约束不就是input/output delay?DC应该加以约束吧?

我又遇到了两个问题：
1、create_generated_clock -name clk1 -master_clcok clk0；
set_clock_latency 1.0 clk0
那么，clk1理应也要继承一部分latency的，可report_timing中没有，相当于做了一个新的时钟一样。那么，也应该对生成的时钟加上clock_latency?
2、上面的设置依旧存在，那么clk1所对应的net的除了时钟，还可能在寄存器的数据端出现。当我report_timing这个数据端的timing时，data arrival time没有从前一个寄存器的D端算起，而是直接从定义时钟的q端，即clk1算起，这样timing路径就有问题了呀！

额。是不是有点多。谢谢解答！

这样的话我也不太清楚，可能要仿真吧。
其他两个问题：
1. 你执行这个命令之后再报一下：set_propagated_clock [all_clocks]
2. 你在FF Q端定义generate clk之后报timing是会这样的，但你设了propagated clock之后从CK到Q的delay会被考虑到master clk ->generate clk 这段latency里的，不用担心。

这样设置后，原来clock的ideal属性就被替换了，latency的属性的确继承了。不过，由于后续庞大时钟树中电容过大，导致source latency很大。
我现在是这样做的，后续生成的时钟也加上latency，和前面一致，消除latency对timing产生的影响。在ICC中，把两者的latency都去掉，让它自己建时钟树，满足timing要求。这样做合理吗?

谢谢您的回答！

可以，但你给generate clk设latency的时候加个option：-source
ps：如果你所有时钟都加了一样的latency，这和不加有什么区别。clk latency只有在有cross clk domain的talk的时候给某些clk 加上去模拟不同clk的skew这才有意义啊

-source是加了的。不加会有什么不良影响?
的确，这和不加没有什么区别。

那什么情况下才要去模拟clk skew呢?DC时，需要模拟模拟吗?

谢谢解答！

不加 -source的话是指到那个点的所有clk latency（source+net）,工具就不会再计算net latency了。加了-source之后就只是source latency, master clk到generate clk之间的net latency还是会被计算。
一般去模拟clk skew是你有意要把一个clk做的快，一个做的慢，或者是片外latency有长有短。在DC综合的时候前段应该告诉你需不需要latency，怎么设。sdc也应该是前段给的。

谢谢您的解答！我还得好好学习呀！