例子: dc_shell> set_max_transition 0.3 current_design dc_shell> set_max_capacitance 1.5 find(port,”out1”)
dc_shell> set_max_fanout 3.0 all_outputs()
4.5.3 时序和面积约束: 各种变量的含义如图 4.8 所示:
图 4.8 时序和面积约束
create_clock: 定义时钟周期. 例子: dc_shell> create_clock -period 10 find(port,Clk)
set_output _delay on outputs set_dont_touch_network :告诉 DC 不要缓冲 clock net,即使它驱动了很多的触发器。
一般此命令用于 clock 网络和 reset 。 例子: dc_shell> create_clock -period 20 find(port,Clk)
dc_shell> set_dont_touch_network find(clock ,Clk)
set_input_delay: 限制输入路径的延时。 input delay = Tclk-q + Tm set_input_delay delay_value [-clock clock_name]
[-clock_fall] [level_sensitive] [-rise] [-fall] [-max]
[-min] [-add_delay] port_pin_list 例子: set_input_delay -max 4 -clock Clk find(port,“ A
”) set_input_delay 命令的参数是前面电路的 delay 数。如: clock 的周期为 10 。我们
限制输入 ports 的延时是时钟周期的 80%则参数应为 10 - 8 = 2.不想包括的管脚可用-除 掉,注意前后都有空格, 如: set_input_delay 2.0 -max -clock Clk
all_inputs() - Clk set_output_delay :约束输出路径的延时。用法和 set_input_delay 相似。 output
delay = Tt + Tsetup set_output_delay delay_value [-clock clock_name]
[-clock_fall] [- level_sensitive] [-rise] [-fall] [-min]
[-max] [-add_delay] [ -group_path group_name]
port_pin_list 例子: set_output_delay -max 5.0 -clock Clk
find(port,”s”) 与 set_input_delay 同样 set_outputdelay 的延时数是后一个电路的建立时间。也应该 时钟周期减去
outputs 的延时数。 你想看你的约束设置,你可以用 report_clock, report_port -verbose, write_script,
report_design 命令。 如果你的约束设置错了,你想修改,你可以用 reset_design, remove_design 命令删 除你的约束或设计重新来过。
4.5.4 时钟 DC 并不综合时钟树,时钟树的综合基于物理布局,由芯片制造商完成。为了模拟 (model)clock 分支的不确定性,我们使用 set_clock_uncertainty 命令。 对于同步的多时钟设计,我们采用虚拟时钟的方法。即在你的设计中选择所有时钟的
最小公倍数作为你的虚拟时钟的频率,然后把它分频为你设计中的多时钟服务。产生虚拟 时钟的方法如下: create_clock -name vTEMP_CLK -period 20 注意:必须是-name ,而且没有源的 pin 或 port 。 对于异步多时钟设计,凡是经过异步边界的路径,我们都应该不进行基于时序的综合。 为此,我们使用 set_false_path 命令。 例子: set_false_path -from find(clock CLKA) -to find(clock
CLKB) 检查你所加的时序约束,用 check_timing 命令。
4.5.5 时序分析
DC 有一个内嵌的静态时序分析器叫设计时间(DesignTime)。用这个 DesignTime ,你
可以对设计进行时序分析。你也可以用 Synosys 的辅助工具 PrimeTime 进行静态时序分析。 这里我们就以 DC
内嵌的静态时序分析器为例。命令为 report_timing 。输出的时序报告文
件按一条一条信号路径显示。每一个时序路径都计算两次,一次为上升沿输入,一次为下 降沿输入。时序报告文件具体如何看,请参考有关资料。 DesignTime 把设计分成一个个信号路径。每个路径的起点(startpoints)可以是 input
ports,也可以是触发器的的 clock pin 。终点(endpoints)可以是 output ports,也可以是
时序器件的数据输入脚。路径的划分由 clock 决定。
4.6 设计综合和优化
当设置好所有的约束条件后,就可以开始进行设计综合和优化了。综合优化的命令为 compiler 。在优化的过程中,时序和面积是两个矛盾的约束。我们把时序约束放宽了,则 能得到比较小的面积。时序约束要求越高则芯片的面积要求将越大。在以前的版本中, DC 总是优先考虑面积,总是为得到最小面积的最快逻辑( design space exploration )来分 析设计。现在由于时序方便的问题更重要,已经把时序约束放在了比面积更重要的地位。 为了能够得到比较好的综合结果,最好的是在你写源程序时就考虑了综合。 优化分为三个阶段:结构优化阶段,逻辑优化阶段,门级优化阶段。 结构优化:结构的高级综合指:设计构件( DesignWare )的更佳选择, 共享子表达式,资源共享,操作符的重新排列。 高级综合是约束驱动的,即基于约束和编码系统。通过高级综合, DC 产生了符合时序
要求的高效面积结果。需要注意的是,高级综合只能在优化未映射设计时发生。
逻辑优化:在高级优化以后,电路功能在 GTECH ( general technology )部分已经出
现。在逻辑优化期间两个优化处理可以选择: structuring , flattening 。 structuring :产生中间结构来改善设计,是基于约束的,可以同时改善设计的面积 和速度。选择 structuring 综合: set_structure true flattening: 删除中间结构,以减少积和电路设计。独立于约束,在速度的优化上很有 效,但是需要较大的面积。
Flattening 由于库的限制并不能保证实际映射一定为两级的积 和电路。选择 flattening 综合: set_flatten
true 门级优化: 主要任务是映射。映射包括组合电路的映射,时序电路的映射。
4.6.1 约束和时序检查: 最常用的约束和时序检查命令: report_constraint -all_violators :报告设计约束的所有违约(violators)。 report_timing -delay_max :报告每一个路径组建立时间( setup time )约束的最差
时序路径。 report_timing -delay_min :报告每一个路径组保持时间( hold time )约束的最差
时序路径。
4.6.2 违约的解决 如果你的是约束没有满足,则需要重新综合。执行连续的编译是没用的,你需要改变 一些东西,如调整你的约束,改变 set_structure
或 set_flatten 选项,或改变编译的映 射尝试( map effort )。可同时 enable the Design
Ware Foundation library components, in order to enable faster
adders: synthetic_library = {dw_foundation.sldb} link_library = link_library + dw_foundation.sldb /*这里的 dw.fondation.sldb 是否用{}括起来没关系 Compile -map_effort (low | medium |
high) 缺省选择为 medium.重新编译时一般选择 high. 使用 compile -incremental_mapping 重新编译设计 。使用此命令时只有门
级优化是进行的,在运行速度上比常规的编译要快。 当你有设计规则的违约时,用 compile -only_design_rule 命令. 由于综合时总是偏于最小面积和最快速度,所以 setup 时序一般不会有问题, 有问题的话也只能去该你的设计了。但是由于数据到来的太快, hold 时序往往会出现 违约( violator )。为了确定保持时间的违约,需要设置为最好情况下的约束: set_clock_uncertainty -hold set_input_delay -min set_output_delay -min set_operating_conditions -min 在缺省情况下, DC 并不确定保持时间的违约,我们使用 set_fix_hold 和 compile
-only_design_rule 让 DC 去确定保持时间的违约。 使用 characterize characterize计算周围环境强加在设计上面的属性和约束,然后放这些约束在设计上, write_script
输出当前设计的所有约束到一个脚本文件上。 characterize 的使用方法实例: current_design TOP characterize -constraints find(cell, ”U1”)
current_design A write_script > A_w.scr characterize 工作在 cell ,而不是 design,而 write_script 则显示 current_design
的所有 constraints,故要 write_script 是需先执行 current-design 命令,使它转换到泥 需的
design 上, write 后再转回去。 限制: characterize 只能在所有的块都已映射为了门级电路的设计上使用,不能用来作为第
一次编译的设计预算(budgets).characterize 一次只能对一个块进行处理。
假设关键路径的大多数组合电路在 ALU 设计中。则你可以: 对于小违约现象(10-30%): current_design ALU compile -map_effort high -incremental current_design = RISC_CORE /*current_design 后面有无=一样*/ report_constraint all_violators 对于大违约现象 (>40%): remove_design ALU read unmapped/ALU.db current_design ALU include scripts/ALU_w.scr synthetic_library = {dw_foundation.sldb} link_library = link_library +
{dw_foundation.sldb} compile -map_effort high current_design RISC_CORE report_constraint -all_violators /*可检查有无 violators*/ 如果你尝试了以上的方法后还不行,对不起,请回去修改你自己的源代码。
4.6.3 大型设计和层次设计主要综合方法学 对于层次设计, DC compile 的时候先不考虑约束把每一个 block 映射成门级电路,然
后再优化逻辑以符合时序面积的约束,并通过周围的块确定违约。 当你的设计中存在多 instance 问题(一个实例在不同的地方被多次使用)时,你可以用 check_design 命令检查,同时这命令还可以帮你检查是不是有管脚没连好。对于存在多实 例的设计,我们可以用 3 种方法解决:
uniquify, compile + dont_touch , ungroup 。 uniquif :为每一个多次引用的 instance 做备份,一个 instance 一个备份,这样每 一个 instance 都得到了一个单独的设计名。 DC 可以为每一个 instance 根据它的指定环境 进行映射。使用方法为:先
uniquify,在 compile. compile + dont_touch : set_dont_touch 设置 dont touch 属性给设计对象,它阻止
了这个设计对象在编译时的调整。(注意:如果这个设计对象是未映射的,那幺它还将是未
映射的)使用方法:我们先约束和编译这个设计对象,然后设置 dont_touch 属性在这个设 计上,最后再编译整个大的设计。 ungroup :删除所有的层,为当前设计的所有 cells 和 references 产生单一的名字。 例子:设 A_des
是一个多实例对象。 D_design 是顶层设计。 read -f db unmapped/A_des.db current_design = Ades link include Aconstraints.scr compile read -f db unmapped/D_design.db current_design = D_design set_dont_touch find(design Ades) include Dconstraints.scr compile 如果你不考虑编译运行时间,内存的限制,以及一次性就要放好这个块,你可以选择 uniquify. 注意:对于多 instance 设计,如果你不进行以上几个操作中的一项, DC 将出现 ERROR ,提示你解决多 instance
问题。 综合一个设计。我们可以采用 bottom-up ,也可以采用 top-down 。 top-down 综合方法: 1. 读进所有的设计, 2. 解决多实例问题 3. 应用顶层约束 4. 编译 5. 查看结果 6. 保存设计 top-down 综合方法的优点是模块之间的依赖关系被自动维护。人花在工具运行的时间 比较少。 bottom-up 综合方法: 1. 单独约束和编译每一个子模块, 2. 确定所有的子模块都符合了它们的初始约束, 3. 读进完整的设计,并应用顶层约束, 4. 检查约束报告,如果都通过了,那你就完成了。 bottom-up 综合方法的优点是大型的设计通过”divide and conquer”方法编译了,不受
有效内存的限制。缺点是需要人们反复的干预直到块与块之间的接口稳定下来。需要仔细 的修改控制。
4.7 设计输出 设计综合好,且所有的约束(可以除了 hold time)都满足以后,我们就可以输出综合 后的文件了。 DC 可以输出.db, VHDL, Verilog, EDIF, PLA, State Table, LSI, XNF 等格式。 为了以后重新读此设计的方便,我们一般要把设计存为.db 格式放在 mapped/目录下。 为了在 VSS
中进行版图后的门级仿真,我们要把设计存为 VHDL 格式。为了在 SE(Silicon
Ensemble)中进行自动布局布线,我们又要求把设计存为 Verilog 格式。 在综合后仿真中我们必须前注释延时的时序信息(SDF 文件)到 VSS 工具中,这时序信 息由 DC 得到。得延时时序信息的命令为: write_sdf design_name.sdf 进行自动布局布线,要求我们前注释约束信息到版图工具中去。这约束信息也叫 SDF 文件,注意与前面的 SDF
文件的区别。产生此约束信息的 SDF 文件的命令如: write_constraints -format sdf-v2.1
-max_nets 0.05 -net_priorities - max_path_timing -max_paths 1 -hierarchy
-output design_name.sdf
4.8 脚本的编写与执行
约束脚本的编写(constraints.scr) (这里假设所有的输出都已锁存,故不需要设置 input delay 和
output delay): 1. Reset the design 2. Create a clock object 3. Set input delays on all input ports except the clock port
(若无 Assume 则+ set output delays on all output ports) 4. Set the operating condition 5. Set the wire load model 6. Define the cell driving all input ports except the clock
port 7. Define the maximum capacitance allowed on the input ports 8. Define the pin capacitive load on all output ports 总的综合脚本的编写(runit.scr) (假设设计明和文件名相同): 1. Read a list of designs into dc_shell 2. For each design, set the current_design variable 3. For each design, link 4. For each design, apply the constraints.scr script file 5. For each design, compile 6. For each design, generate and save the results from a constraint
report to the reports directory, using a meaningful name 7. For each design, save the mapped design under the mapped
directory under a meaningful name
8. Quit dc_shell context_check 必需在完整的 script 文件上才使用,所以对约束文件 constraints.scr 不能用
context_check 产生和检查约束文件 constraints.scr : dc_shell -f scripts/constraints.scr -syntax_check
产生和检查总的脚本文件 runit.scr : dc_shell -f scripts/runit.scr -syntax_check dc_shell -f scripts/runit.scr -context_check |
tee context.log 运行脚本综合你的设计: dc_shell -f scripts/runit.scr | tee runit.log
constraints.scr 和 runit.scr 的样本见附录 一些注意点及常用命令的用法: 执行 group, ungroup 命令需在 Schematic View 执行 constraint, compile 命令需在 Symbol View ,也可在 Schematic View
其实指定单元即可寻找 critical path 需在 Schematic View command.log 文件可以当作 script 文件,特别是在你忘记 save your work 时, 你可把他当作
script 文件重新执行.切记要从命名 command.log 文件,否则重其 dc 是 会被覆盖掉. compare_design A B 命令需在 analyze 和 elaborate 之后 grep library
command.log 查找指定格式的文件library 这个参数是指你要查的信息,如要查 error,则改为 error
list -libraries remove_all : Edit>Reset 不想包括的管脚可用-除掉,注意前后都有空格, 如: set_input_delay 2.0 -max -clock Clk
all_inputs() - Clk
path type 为 max 暗示 setup time,min i 暗示 hold time 应该用 best case 的 operating conditions 来进行 hold-time checking
一个无效的路径是指没有时序约束的路径。
find 命令: dc_shell>find port 或 find (port,”*”) /*find 与(
之间的空格可有可无。( ) 里的逗号可用空格代替*/ dc_shelll>find (cell,”*DW*”) /*list all the cells
that contain letters “DW”*/ dc_shell>find (pin,cba_core/and2a0/*) /*list all the pins
of the AN2 gate in the cba_core library*/ dc_shell>set_load 5 find (net,”CLK”) /*place a 5 pF load on
the net CLK, 这里“””可不要*/ dc_shell>find (pin /Q) /*list all of the
“ Q” pins in the desig*/
4.9 Prime Time Prime Time(简称 PT)时 Synopsys 公司的一个 sign-off 静态时序分析工具。它只支持 TCL 脚本语言。 PT 的调用: 命令行界面:%pt_shell GUI 界面: primetime PT 的 setup 文件.synopsy_pt.setup: set search_path [list ~jzhu/csmchdlib/lib]
set link_path [list {*} csmc06core,csmc06pad] 在这里 set search-path 等价于 DC 的 setup 文件中的 search_path , set link_path
等价 于 link_path 。 PT 的使用命令与 DC 区别不大,由于篇幅的限制,这里不再详细讲解 PT 命令的使用,只以 实例说明。 版图前 setup-time 分析脚本: #*** ** * #Define top-level design name set active_design tap_controller #Design entry in db format,netlist only-no constraints read_db -netlist_only $active_design.db current_design $active_design #Design environment set_wire_load large set_wire_load_mode top set_operating_conditions WORST set_load 50.0 [all_outputs] set_driving_cell -cell BUFF1X -pin Z [all_inputs]
#Clock specification and design constraints create_clock -period 33 -waveform
[0 16.5] tck set_clock_latency 2.0 [get_clocks tck] set_clock_transition 0.2 [get_clocks tck] set_clock_uncertainty 3.0 -setup
[get_clocks tck] set_input_delay 20.0 -clock tck
[all_inputs] set_output_delay 10.0 -clock tck
[all_outputs] #Timing analysis commands report_constraint -all_violators report_timing -to [all_registers -data_pins]
report_timing -to [all_outputs]
4.10 设计实例 我们继续以 DDFS 设计为例。4.10.1 Design Analyzer 操作步骤: 设置路径及环境变量: 在自己的工作路径下创建.synopsys_dc.setup 文件,并在里面设置自己的 环境变量。 .synopsys_dc.setup 文件: ** search_path = {~jzhu/csmchdlib/lib} + search_path
link_library = {csmc06core.db csmcs06pad.db} target_library = {csmc06core.db} symbol_library = {csmc06core.sdb csmc06pad.sdb} synthetic_library = {standard.sldb dw_foundation.sldb}
link_library = link_library +synthetic_library define_design_lib work -path work; /*为输出的 VHDL 网表写上使用的 packages*/ vhdlout_use_packages ={
\ “IEEE.std_logic_1164”, \ “csmc06core.VCOMPONENTS” \ } /*.synopsys-dc.setup1*/ ** 在根目录下执行环境设置文件: su7>source .cshrc_syn 转到自己的工作路径下启动 synopsys 工具。 su7>da读进 design 1. Read in 各层的 design 用 Read 读进 PLA 等各种非 HDL 文件;即: File- Read 对 HDL 文件,先用 Analyze 读进,转化为中间格式的文件,再用 Elaborate 把 中间格转化为 synopsys
工具所用的操作符。具体操作为: File-Analyze 打开 Analyze File 窗口,在存放设计源文件的目录 vhdl/下用鼠标中键选择所 有的设计, 在 Library 栏中选择 WORK 库,然后 OK 。 File-Elaborate 在 WORK 库中逐个 elaborate 已分析的设计。注意: analyze 后 DA 窗口中并不 显示任何东西。设计在
elaborate 后才在窗口中显示出来。 此时 Designs View 为:
其中顶层的 Symbol View 为:
Schematic View 为:
可见此时电路不是门级的。
设置 Attributes 与 Constraints
设置属性 attributes: 在 Attribute-Operating Environment -…下设置各种属性。如: Attribute-Operating Environment-Drive Strength 设置 input strength Attribute-Operating Environment-Load 设置输出驱动能力 Attribute-Operating Environment-Wire Load 设置 wire load 。 Attribute-Operating Environment-Operating
Conditions 设 置 operating conditions 。
设置约束 constraints:1. 设置 Area Constraint 2. 设置 CLK Constrains 即:选中 CLK , Attribute-Clocks-Specify3. 设置 delay constraints 即:选中 output ports 设置 Attribute-Operating Environment-Output Delay 选中 input ports 设置 Attribute-Operating
Environment-Input Delay
DDFS 设计的输入输出我们都是通过寄存器的,这样 input delay ,output delay 就不需设置了。 对于这个 DDFS 设计我们只指定 CLOCK 周期: 在设计的 Synbol View 中选中 clk 管脚,然后 Attribute-Clocks-Specify 打开 Specify
Clock 窗口。在窗口中的 period 一栏中写上指定的周期 50 ,这说明你所 加的 clock 周期为 20M 。选中
Dont Touch Network,然后 apply,并关掉此 Specfy Clock 窗口。
我们可以看到这时 clk 管脚上出现了一个波形图标。
对于 multiple design instances 我们有三种解决方法: uniquify set_dont_touch ungroup 这些命令在工具栏中没有,我 们需用 命令窗口 Command Window 执 行。 例如在执行完 uniquify 命令 后,我们可能发 现 Design View 窗口中多了几 个新的图标。 我 们 在 命 令 窗 口 打 入
uniquify 。
查错 选中顶层设计,执行 Analyzing-Check Design , 检查和纠正各种问题。 在这里我们选中 Check Timing 以检查时序属性有无问题。
Compile Design 选中 DDFS , Tools-Design Optimization ,检查和设置 options ,然后执行
ok,即执行 compile 。 compile 后 the Schematic View of design 就转换成了门级电路。
此时的 Designs View 如下图所示: 从 中 我 们 可 以 看 到 模 块 的 标 志 已 经 用 门 级 表 示 , 而 且 多 了 一 个 模 块
ddfs_DW01_add_32_0 。
此时 ddfs 的 Schematic View 为: 我们可以看到 ddfs 的 Schematic View 已经转换为了门级电路。
产生 Report ,分析设计结果。
1. 产生各种 Attribute Report 2. 产生各种 Analyzing Report 其中 Timing Report 可检查 critical path Report-Timing ,然后在 Analysis Reports 中选中 constraints , timing,再 在
set options 中选中 All Violations 。 选择输出到文件中,在 File 一栏中打 入你的文件名,然后
Apply 。 产生报告文件后,检查是否有 violations 存在。如果没有存在,且时序都满足 要求,则综合优化完成。输出网表文件和 SDF 文件 完成综合优化后,我们选中顶层设计 ddfs ,然后把设计保存为 db 格式放在 mapped/中,切忌别忘了选中 Save All Designs in Hierarchy 。 为了在 VSS 中进行综合后仿真,我们需把设计存为 VHDL 格式(不要忘了选中 Save All Designs in Hierarchy),同时输出时序延时信息的 SDF 文件。输出此 SDF 文 件: File-Save Info-Design Timing ,打开 Save Timing Information 窗口后, 选中 SDF V2.1 格式,并在 Output File Name 里打入你的文件名,然后 ok 即可。 为了在版图工具 SE 中进行自动布局布线,我们要把设计存为 Verilog 格式 的网表(同样要选中 Save All Designs in Hierarchy)。同时我们还需输出约束文 件 .sdf 文件 。此 SDF 文件与前者不同 。它的保存方法为 :
File-Save Info- Constraints 打开 Save Constraint Information 窗口后,选中 SDF V2.1 格式。并 选中 Max Path Timing Constraints, Net Constraints, Design
Hierarchy 。然 后 ok 即可。
4.10.2 dc_shell 命令行批处理 执行批处理前我们需准备好脚本文件:约束文件 constraint.scr,执行文件 runit1.scr
。具体文件内容见附录。 检查约束文件 constraint.scr : dc_shell -f scripts/constraint.scr -syntax_check 检查执行文件 runit.scr : dc_shell -f scripts/runit1.scr -syntax_check dc_shell -f scripts/runit1.scr -context_check |
tee context.log 运行脚本综合你的设计: dc_shell -f scripts/runit1.scr | tee runit.log 执行完批处理文件以后,检查报告文件。如果报告文件中没有 violations ,时
序满足要求,则综合工作就完成了。否则,你需修改约束条件或尝试其他方法重新 进行综合。