大家说说是如何约束port timing的，如何约束能得到最准确的port timing？
1set_input_delay,set_output_delay,然后在postCTS阶段对port设置virtual clock，对不同的port设置不同的virtual clock，并设置不同的clock latency，clock latency值根据与port相关的reg的clock latency确定
2set_max_delayfrom port --> reg/D或者from reg/Q --> port此delay值根据以前SI阶段的port-->reg或者reg-->port的delay获得。这种方法同样需要设置virtual clock，设置方法和1中的相同。
总而言之，如果对每个port都设置virtual clock的话，会很麻烦，首先要给每一个port create_clock，其次要对每个virtual clock 设置clock latency。当然也可以对所有的port设置一个相同的virtual clock和virtual latency，但是这样必然造成port timing计算不够准确。
之前我以为 ，如果用第二种方式set_max_delay来约束port timing的话，工具计算slack的时候就只会判断port-->reg或reg-->port的delay是否满足我给定的设定值，并不考虑和port相连的reg的clock latency。如果是这样的话，那么我就不需要设置virtual clock，从而得到很准确的port timing。
但是实现发现，在postCTS阶段，工具在计算port slack时，依然会把clock latency计算上，由于没有设置virtual clock，导致port timing没法看。
大家说说你们的port都是怎么约束的?是用哪种方式/
有没有高明的方法，可以不用设置virtual clock，也可以得到准确的port timing
一般对block level的约束才使用virtual clock，对chip level就不需要了
对于block，考虑到top level留有富余量，可以用同一个virtual clock，不必算得如此精确
谢谢小编的解答
我现在做的是block级的。问题是我的设计中打开了usefulskew。和port有关联的register的latency都不一样，从700ps到1000ps不等，设置同一个virtual clock太不准确了。我想针对每个port都设置相对应的virtual clock和virtual latency，这样是最准确的。
如果能只检查port的path delay是否满足，不考虑port处的clock latency的话，就会方便很多 。可惜目前没这样的方法
用real clock也行，就是CTS后把cts latency 反映到io port上就行了
这个叫virtual clock latency adjustment
还有一个方法是先算出与port关联的FF的clock insertion delay，然后从对应的output delay上减去，或者加到input delay上去，不需要任何virtual clock
谢谢两位小编高见，受益匪浅！
请问小编你所指的“导致port timing没法看” 不会是说slack很差吧? 我觉得如果clock latency会被考虑， 那么data required time ＝ clock_period + clock_latency - output_delay， 应该比不考虑clock latency要好很多吧。
我的帖子也是问个类似的问题， 我不理解为何PT仍然将CTS后的clock latency按照ideal， LZ要是有空请关注以下
http://bbs.eetop.cn/thread-318871-1-1.html
请问如何打开useful skew 啊?请教下
在encounter中是这样设置的：setOptMode -usefulskew true，别的工具没用过，就不清楚了。
你还可以在setUsefulskewMode里面设置很多选项，控制usefulskew借用的大小，端口是否借用等等。
你好，我说的“没法看”指的是in2reg会正很多，而reg2out会负很多。虽然一个负很多，一个正很多，但都不能反映真实的port timing。
你列出来的情况是reg2out的，在postCTS阶段timing设置virtual clock肯定是比不设置virtual clock要好的。
关键看你设置的virtual clock和reg的real clock的skew大不大，
如果不大，那么结果是比较合理的；
如果很大，那么结果是不合理的。
嗯， 赞同。
这种情况下， 如果懒一些， 是不是仅关注reg2out的datapath delay是否满足就行了， slack就不看了，反正也不精确，是这个意思吧?
上次给你回答的问题有些错误，我已经重新编辑了。你可以再看看。
--------------------------
你说的是对的，如果偷懒的话，只看port--reg之间的data path delay是否满足就行了。
但是port timing不精确的话，工具优化的依据就不对，可能不会对port timing起到很好的优化。
所以，最好还是设置一些约束，使得port timing比较合理，这样就能得到合理的优化。
嗯，已经看过了， 和我的理解完全吻合， 而且我的帖子其实已经证明这个问题了。
其实， 根本原因在于in2reg和reg2out都不是完整的path，要么缺少launch， 要么缺少capture， 依赖外部的FF组成完整F2F path。
我觉得陈版的一个方法可以考虑： 当block-level port timing不要求精确的话， 可以考虑output_delay约束适当减小, input_delay约束适当增加。
请问：如何算出与port关联的FF的clock insertion delay?应该在post cts之后才能算出这个latency值得吧?
谢谢！