dc约束中的multi scenarios（多场景）
我们在做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支持多场景。
好了，先介绍这么多，快去试试吧。
本文参与 腾讯云自媒体分享计划，分享自微信公众号。
原始发表：2022-05-14，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读