SDC是如何炼成的？IO约束篇

From 老本 Benjamin RTL2GDS

IO约束在顶层和模块级的主要命令都是以下几个，但是实际应用的复杂程度不可同日而语，本篇会先介绍模块级IO约束实战经验，然后讲解顶层IO约束复杂性，过程中会介绍DDR接口时序。

set_input_delay

set_output_delay

set_driveset_driving_cell

set_input_transition

set_load...

各个命令的具体用法可以在PT中通过man了解详情，这里就不费劲重复了：
pt_shell> man set_input_delay



模块级IO约束实战

 上图给出了一种IN2REG路径的示意图，DUA为当前模块，外部有一个假想的虚拟寄存器在驱动CIN端口，这种情况下我们可通过以下命令来约束：

set period 8
create_clock -name CLKP -period $period [get_ports CLKP]

#创建同频率的虚拟时钟
create_clock -name vCLKP -period $period

#参考值为0.6，根据实际情况调整
set_input_delay [expr 0.6 * $period] -clock vCLKP [get_ports CIN]

#假设端口buffer为BUFX4

set_driving_cell -lib_cell BUFX4 -pin Z [get_ports CIN]

虚拟时钟的作用

使用set_input_delay时，可以指定真实时钟CLKP，也可以指定虚拟时钟vCLKP，在CTS之前是没有区别的。然而，在CTS之后，如果指定的是真实时钟，那么虚拟寄存器的时钟延迟就被忽略了。如果指定的是虚拟时钟，工具往往可以根据内部真实时钟的平均延迟来估算外部虚拟寄存器的时钟延迟，更加合理。

一般地，为了让顶层的时序更容易满足，在模块级优化的时候，都会对自己内部的IN2REG和REG2OUT路径约束更加严格，可以设置外部的延迟为60%的时钟周期，给内部的数据路径留40%的空间。不过，具体问题需要具体分析了。

需要注意，set_input_delay 可以指定-max和-min选项，分别对应setup和hold时序检查，如果只是指定其中一个选项，或者都不指定，那么工具在检查setup和hold时，会使用相同的值。

端口Buffer和set_driving_cell配合使用

在实际项目中，为了避免模块之间，或者模块和顶层之间IO接口部分出现时序问题，一般会要求在靠近IO端口的地方添加具有一定驱动能力的端口Buffer。在这种情况下，可以通过set_driving_cell来模拟端口的真实外部环境。假如没有端口Buffer，也可以通过set_input_transition大致指定输入端口的驱动能力。

总体来说，set_driving_cell会考虑到OCV的影响，input transition是查表计算出来的，而set_input_transition比较简单粗暴，在IO端口时序不那么关键的时候，也可以使用。但在顶层，一般使用后者，因为IO单元的输入电容较大，芯片外部具备驱动能力较强的器件，标准单元库中没有buffer能够驱动。

顶层IO 约束实战

顶层IO约束在原理上与模块级没有本质区别，然而由于顶层需要与外部器件进行通讯，除了GPIO，还会接触到各种标准协议接口，例如UART，I2C，SPI，LVDS，DDR等等，在写SDC前需要读一读协议。更复杂的情况是，由于存在端口复用的情况，往往同一个端口具备多种时序要求，需要逐一定义。

上图是一个PinMux（也称为IOMux）的示意图，在SoC设计中非常常见，特别对于IO limited的芯片来说，PinMux是很有必要的。看似复杂，其实只要各个击破就能达到目标，SDC标准制定者已经为我们考虑到了这一点，通过set_input_delay的选项-add_delay，可以对同一个端口设置多重约束，例如：

set_input_delay [expr 0.6 * $periodA] -clock CLKA [get_ports CIN] -add_delay

set_input_delay [expr 0.3 * $periodB] -clock CLKB [get_ports CIN] -add_delay

 另外，针对顶层输出数字端口，需要根据芯片使用的实际情况set_load，一般的GPIO端口负载电容都在pF级别。