4.1 逻辑综合概述
4.1.1 逻辑综合的概念

综合(synthesis)：就是把思想转换为实现欲想功能的可制造的设计。综合是约束驱动 和基于路径的。
在这里，综合也就是把行为级或 RTL 级的 HDL 描述转换为门级电路的过程，用公式表示 就是：
综合等于  = 翻译  + 优化  + 映射
( Synthesis  = Transiation  + Optimization  + Mapping  ) 用图形表示就是：(见图 4.1)

图 4.1 综合的概念

4.1.2 逻辑综合的工具介绍

。工具操作界面

设计编译器(Design Compiler 简称 DC)是 Synopsys 综合工具的核心。综合一个设计 时，可以选用两种界面： A 。设计分析器(Design Analyzer 简称 DA)-图形窗口界面。 B 。 dc_shell—命令行界面。
DA 图形窗口界面的启动：%da
dc_shell 命令行界面的启动；%dc_shell
dc_shell 界面的提示符为:dc_shell  >
dc_shell 命令行界面支持两种脚本语言:dcsh 模式和 dctcl 模式。
dcsh 是使用源于 Synopsys 的语言。 dctcl 使用工具命令语言（ Tool Command Langugae ）。
dcsh 模式和 dctcl 模式比较
tcl 是一种开放型的工业标准语言。它比 dc_shell 更加强大。
启动 dcsh 模式用 dc_shell 命令,启动 dctcl 模式用 dc_shell  -t

如果你已经有了 dcsh 的 setup 文件或脚本文件(.scr),你想转换为 Tcl 的 setup 文件 和约束文件,则我们只需执行下面命令即可.
setup 文件的转换:
设 dcsh 的 setup 文件为.synopsys_dc.setup.old,要转换为 Tcl 的 setup 文
件.synopsys_dc.setup 则
% dc-transcript  .synopsys_dc.setup.old  .synopsys_dc.setup 脚本文件的转换:
设 dcsh 的约束文件为 old_scriptfile.scr,dctcl 的约束文件为 tcl_script.tcl ，则 % dc-transcript old_scriptfile.scr tcl_script.tcl
由于 dcsh 和 dctcl 是可以转换的，以下的介绍中，在支持 dcsh 的地方，将都用 dcsh 命令。
。Synopsys 格式
大多数 Synopsys 产品都支持和共享一个公用的中间结构--”db”格式。 db 文件是描述
文本数据的二进制已编译表格式。 DC 可以读和写以下的所有格式： Verilog ， VHDL ，
EDIF 。
逻辑综合的流程
流程图如图 4.2 ：

图 4.2 逻辑综合设计流程

4.2  setup 文件,库以及一些基本概念
4.2.1    setup 文件
把行为级描述转换为门级电路，在映射过程种，必须有技术库的支持，否则它将找不 参照的元器件。为此我们在综合前必须在 setup 文件中设置好综合所需的技术库。这里所 需的技术库的格式为.db 和.sdb 格式。技术库的描述略。
Synopsys 的设计编译器(Design Compiler,简称 DC)提供了三个同名的 setup 文
件.synopsys_dc.setup 。一个为安装目录下的 setup 文件，它提供系统管理员指定的系统 变量设置。一个为你根目录下的 setup 文件，它提供你的工作环境变量的设置：公司的名 字，你的名字，背景色。这是由用户指定的 DC 值。
一个为你工作目录下的 setup 文件，它规定了你设计所指定的 DC 值，如：
search path, target library, link library  , symbol library.
启动 DC 工具时，它依次读入这三个文件，且读的越后的文件优先级别更高，即相同的

变量，后面的设置值将覆盖前面的设置。
 根目录下的 setup 例子如下：
company  =  “ your_company”;
designer  =  “your_name”;
view_blackground  =  “black”;
工作目录下的 setup 文件例子如下：
dcsh 模式：
searsh_path  =  {}  + search_path
link_library  =  {MTC45000.db};
target_library  =  {MTC45000.db};
symbol_library  =  {MTC45000.sdb};
define_design_lib work  -path work  ;
Tcl 模式：
set search_path  [concat 

  $search_path]
set link_library  [list MTC45000.DB]
set target_library  [list MTC45000.db]
set symbol_library  [list MTC45000.sdb]
define_design_lib work  -path work
说明：
search_path:为 DC 提供未分析设计标准的搜寻路径，亦即你的技术库的搜寻路径。
 如果你的库不是放在 DC 的安装目录下的库的目录下，则你还需修改你的 search+path,
 指定库的目录。方法是:
dcsh 模式：
search_path  =  {directory}  + search_path dctcl 模式：
set search_path  [concat  [list directory]  $search_path] link_library:
指明了你的设计所参照的子设计的位置。 DC 根据 link_library 寻找它所参照的设 计。如果参考设计的完整名字在 link_library 里没有定义，则需在 search_path 中包括这 参考设计的路径。 link_library 定义了被单独使用的元器件的库的名字。即，
link_library 里的元器件是不被 DC 所 inferred 的。




4.2.2 库




target_library:
指明了在你优化设计时用到的元器件的库。
symbol library:指明了含技术库元件的图形描述的库。





4.2.3 对象
在进行综合时，我们经常会遇到一些对象的概念。搞清楚这些概念具体是指代什幺是 很有必要的。
Design: 对应于执行一定逻辑功能的电路描述。 design 可以是独立的一个，也可以含 有其他的子设计。子设计虽然可以是设计的一部分，但是 Synopsys 也把它看成是一个设计。
 Cell: 是 design 中的子设计的一个 instance 。在 Synopsys 的术语中， cell 和
instance 被认为是一样的。
Reference: cell 或 instance 参考的源设计的定义。
Port: 指主要 inputs,outputs 或 design 的 IO 管脚。
Pin: 对应于设计中的 cell 的 input,output,或 IO 管脚。
Net: 这是信号的名字,即通过连接 ports 与 pins 或 pins 与 pins 而把一个设计连在一 起的的金属线的名字。
Clock: 作为时钟源的 port 或 pin..
library: 对应于设计的综合目标或参考连接的工艺指定单元的集合。 具体示例如图 4.3 ：










图 4.3  对象




 




4.3 设计分块




分块(partitioning)：把复杂的设计分成各个小部分的过程。
Partitioning  = Divide  +Conquer
概念如图 4.4




 
图 4.4 分块的概念





 




分块是成功的进行综合和布局布线的关键。传统上的分块是根据逻辑功能,而不考虑综 合的。固定的边界降低了综合结果的质量,使优化难以进行。正确的给设计分块能大大的增 强设计结果，而且降低编译的时间和简化脚本的管理。
以下是分块的几条建议：
1.   把相关的组合逻辑保留在同一模块中；
2.   考虑设计的重用；
3.   根据它们的功能划分模块；
4.   把结构逻辑和随机逻辑分开；
5.   合理的块大小(每个块最大大约为 10K 个门)；
6.   把顶层分块出来(独立 I/OPads,边界扫描 Boundary Scan  ，核心逻辑,Clocks)；
7.   顶层避免存在 glue-logic;
8.   把状态机和其他逻辑独立开来；
9.   避免在一个块中存在多时钟；
10.  把用来同步多个时钟的块独立出来；
11.  分块时考虑你的版图设计。
块的产生： entity 和 module 语句定义了层次的块。 entity 或 module 的示例也产生 了一个新层。算术电路(  +,-  ,*,。。)的 inference 也能产生新层。 process 和 always 语句不会产生层次。
逻辑优化并不能穿过块的界线。最好的分块是把相关的组合逻辑和它的目的寄存器聚 集在同一个块中。这样组合优化技术能被完全的利用，时序优化也可以吸收一些组合逻辑 到复杂的触发器中(JK,T,Clock-enabled)。好的分块如图 4.5 所示：




 




 




图 4.5 最佳的分块




什幺是 glue-logic :就是用一个组合逻辑把几个块结合起来，这个组合逻辑就是 glue logic.由于这 glue logic 不能被吸收，优化是被限制的，要删除这 glue logic,我们把这 NAND 放进后面的逻辑电路中。这样 glue logic 就可以和其他逻辑一起优化了。顶层设计只 能是一个结构的网表，不需要被编译。换句话说，就是顶层不能含 glue logic ，当然其他 层最好也是不要存在 glue logic 。
分块时各个块的大小最好不要相差太大，因为，太小多余的边界将限制优化，太大编 译的时间又太长。尽量减少不必要的层。编写 HDL 源代码时每一个块的输出最好都是通过 寄存器实现，这样可以可以简化约束的说明和方便优化。 input delay 和 output delay 可 以不用设置。块的名字必须和文件名相同，否则在分析是将会出错。
初始的分块由 HDL 定义。不满意的话， DC 可以进行调整。 DC 分块的命令是 group 与 ungroup.
例如我们把两个块 U1,U2 合并为一个块 U23,则转到当前层后 group  {U1,U2}  -cell_name U23
ungroup  {U23}
命令的具体应用请查看在线帮助。





4.4 读进设计




DC 的输入格式可以是 Verilog HDL,VHDL 等硬件描述语言，可编程逻辑阵列(PLA)， EDIF2000 ，格式。
对于 HDL 格式， DC 要求用 analyze 和 elaborate 读进设计。
analyze ：读进 VHDL,或 Verilog 文件，检查语法和可综合逻辑，并把设计已中间格式 存在设计工作库(WORK)中。 analyze 后，在 DA(Design Analyzer)中并看不到有什幺东西出 现。 analyze 命令可以同时对若干个文件执行操作。
elaborate ：从工作库中把 analyze 后的中间文件转换为一个设计。 elaborate 命令 用综合的操作符代替 HDL 的操作符，且决定正确的总线大小。 elaborate 命令后，在 DA 中 你可以看到出来了一个一个的模块。一个文件一个，即一个 entity 或 module 一个。
elaborate 一次只能对一个文件进行操作。这点需要注意。
在这里我们需要提醒一下的是， entity 或 module 的名字，即设计的名字必须和文件





名相同。因为 analyze 后它存在 WORK 里的名字是设计的名字(entity or module)而不是你 源程序的文件名，所以如果你 elaborate 的是文件名，那幺如果设计和文件名不同， DC 将 找不到你的设计，出现 error 。当然如果你不厌其烦的特别让 elaborate 他的设计名，这 问题就不存在了。
对于其他非 HDL 文件， DC 用 read 命令读进设计。
read 命令并不产生中间文件，而是之间把他转换为了 DC 里的符号。
理论上， read 可以读进所以的设计，不管是不是 HDL 文件，但是建议对 HDL 文件用 analyze 和 elaborate 读。
对于 VHDL 的 package 文件，我们应该用 read 命令读，且必须在读进 VHDL 源程序前读。





4.5 设计约束
为了从 DC 中能得到合适的结果，设计者必须通过描述其的设计环境，目标任务和设计规则来系统的 约束其设计。约束包含时序和面积信息。它们通常是从规格说明中提取出来的。 DC 用这些约束去综合和 优化设计以符合其目标任务。本文只讲些最常用的约束命令，且不会讲的很详细。约束命令的具体用法请 参照在线帮助。





4.5.1 设计环境
几个环境变量含义如图 4.6 所示：




 





图 4.6 环境变量





 





图 4.7 时序图




set_operating_conditions ：描述了设计的工艺，电压和温度等条件。通常以
WORST,TYPICAL,BEST 的情况进行描述。技术库通常具有正常情况的的特性。为了查找芯片




商提供的运行环境，我们可以用 report_lib libname 命令。
set_operating_conditions  <name of operating conditions> 例子：
dc_shell> current_design  =  “addtwo”
dc_shell> set_operating_conditions  -max  “typ_124_4.50” 最坏(即最慢)的运行条件是最低的电压和最高的温度。
最好(即最快)的运行条件是最高的电压和最低的温度。
对于设置 the best case 的运行条件是：
set_operating_conditions  -max WORSTC_OPCONDS  -min BESTC_OPCONDS
如果你想检查你的设置，你可以用 report_port  -verbose,write_script 和 report_design 命令。
set_load: 定义了输出单元总的驱动能力。
set_load  <value>  <object list>
例子：
直接指定一个值： dc_shell> set_load  4 find  (port OUT1)
利用 load_of(lib/cell/pin)命令把技术库的门作为负载数的衡量： dc_shell> set_load load_of(CBA/AN2/A) find  (port OUT1)
load_of(lib/cell/pin)可以乘以系数：
dc_shell> set_load load_of(CBA/IVA/A)  *  3 find  (port OUT1)
set_driving_cell: 模拟了驱动输入管脚的的驱动单元的驱动电阻。定义了信号到达 输入管脚的传输时间，可以直接指明驱动输入管脚的外部实际单元。
 set_driving_cell  -cell  <cell name>  -pin  <pin name>  <object list>




例子：
dc_shell> set_driving_cell  -cell BUFF1  -pin Z all_inputs()
set_drive: 指明了输入管脚的驱动强度。模拟了输入管脚的外部驱动电阻。它一般只 用在 clock 管脚上。
set_drive  <value>  <object list>
例子：
dc_shell> set_drive  0  {CLK RST}
set_wire_load: 用来提供估计的统计线载(wire load)信息，反过来也用线载信息模
拟 net 延时。线载模型是基于 net 扇出的 net 参数估计。
 set_wire_load <wire-load model> -mode <top | enclosed | segmented >
例子:
set_wire_load MEDIUM  -mode top
wire load 模型是芯片制造商产生的,但是也可以你自己产生。自己产生的方法举例如
下:
设库名为 Extra.lib:
Library  (“ extraa ”)  {
operating_conditions  (“ SLOW ”)  {
process  :  1.75;
temperature  :  100;
voltage  :4.66;
tree_type  :  “ worst_case_tree ”;}
}
再执行以下命令：
dc_shelll> read_lib extra.lib
dc_shelll> write_lib extra  -output extra.lib
dc_shell> link_library  =  {“ *”,tech_library extra.lib}
dc_sehll> set_operating_conditions “ SLOW ”  -library  “ extra ”





 




这样就完成了运行条件的产生。





4.5.2 设计规则
set_max_fanout, set_nax_transition, set_max_fanout 设计规则在技术库中设置， 为工艺参数所决定。
set_max_transition  <value>  <object list>
set_max_capacitance  <value>  <object list>
set_max_fanout  <value>  <object list>
例子：
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-Specify
3.   设置 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 ，时 序满足要求，则综合工作就完成了。否则，你需修改约束条件或尝试其他方法重新 进行综合。