我们在做MCU芯片的时候，经常遇到PAD复用。有一种情况比较特殊：一个PAD在一个场景下用作时钟输入，另一个场景下用作数据的输入。

这样的话，我们需要为这个PAD创建两组约束：

＃ as clock

create＿clock －name ＂clk＂ －period 10 ［get＿ports IN1］

set＿clock＿latency －source 1．5 ［get＿ports IN1］

＃ as data input

set＿input＿delay 6 －clock another＿clock ［get＿ports IN1］

设计中，我们还经常遇到时钟MUX，一个模式下是时钟1，另一个模式下是时钟2。大部分情况下，这两个模式是通过PAD或者寄存器来选择，不会同时出现，如下图。这样模块3就要求两种不同的时钟下都能工作。

是否要按频率高的来约束呢？我们看下图，Logic3在CLK1和CLK2下时序要求不一样，与Logic1和Logic2的大小有关。如果只看频率高的，很可能就过度约束了。所以，我们做综合时，不能图简单，应该以实际情况设置合理的约束。

DC中的多场景（multi scenarios）就是用来解决这个问题的。把复杂的约束分成多个场景（也可以叫工作模式，如正常模式1、正常模式2、测试模式1、测试模式2等），每个场景下只管自己的约束。由综合工具来自动优化电路，同时满足多个场景。

我们来写个脚本的示例：

＃ scenario 1

create＿scenario s1

set＿operating＿conditions －analysis＿type bc＿wc －max WORST －min BEST

set＿tlu＿plus＿files －max＿tluplus ＄tluplus＿max＿file －min＿tluplus ＄tluplus＿min＿file －tech2itf＿map ＄map＿file

set＿case＿analysis 0 ［get＿port MODE］source sdc＿s1．tcl

＃ scenario 2

create＿scenario s2

set＿operating＿conditions －analysis＿type bc＿wc －max WORST －min BEST

set＿tlu＿plus＿files －max＿tluplus ＄tluplus＿max＿file －min＿tluplus ＄tluplus＿min＿file －tech2itf＿map ＄map＿file

set＿case＿analysis 1 ［get＿port MODE］

source sdc＿s2．tcl

＃ active all scenarios

set＿active＿scenarios －all

这个脚本非常简洁，与上面的文字描述一致，就不解释了。需要注意两点：

多场景下，不支持wire model，要用tluplus（更准确的连线电容电阻信息库）。

要用compile＿ultra，只有compile＿ultra支持多场景。

好了，先介绍这么多，快去试试吧。