两种io约束方式对于后端的影响

众所周知，block的port接口部分的约束，我们是通过set_input_delay set_output_delay来实现的。在约束的时候，我们通常会遇到两种方式，一种是通过创建virtual clock，另外一种是通过真实的clock来进行约束。

用virtual clock的最大优势，就是简单。你可以通过设置一个virtual clock，就可以对与port相关的block内部的多个clock的路径进行约束。如果用真实的clock，你必须确保，这些clock已经设置齐全。因为使用真实的clock会有这样的风险，如果你用clockA来进行的约束，而clockB和clockA之间是异步关系，那么，port到clockB domain的约束就会没有设上。

但是为什么还是有很多公司，在设置的时候采用更加麻烦的真实的clock呢？

我们从后端实现的角度来分析一下。

我们在cts之后，计算timing的时候会从原来的ideal clock转为propagated clock。这里会有一个问题，综合以及place阶段，io的约束是不考虑clock的，也就是ideal clock条件下的约束。当cts做完后，core clock会有latency。而port上用来约束的clock仍然是ideal的（因为本来就没有长tree）。其结果就是，这对于input来说，setup放松了，output的约束变严格了。这就会和我们本来的意图不符合。

在早期，我们是通过脚本，来更新这部分约束，从而避免cts前后的这个gap。而现在，EDA工具，都已经有了相关的命令来解决这个问题。

以innovus为例，这个命令叫update_io_latency，也可以通过ccopt自动来打开。set_ccopt_property upate_io_latency true。

如果我们是采用一个virtual clock来对应多个core clock，那么io约束的调整是以多个clock的总平均latency来计算的。这个就会和我们的预期不一致。core clock可能千差万别。小tree可能很短，而大tree又很长，采用平均的latency显然并不理想。

如果我们才用的是真实的clock，工具就会针对每一种clock单独进行io约束的udpdate，这是我们需要的。

因此，如果有时间的话，尽量还是把约束写好，这样对于时序的收敛是有好处的。