DC NXT TOPO flow （1）SPG flow 基础

什么是物理综合 physical synthesis

物理综合就是将RTL综合为coarse-placement的网表;这需要让DC工作在TOPO mode' 并使用compile_ultra 命令;

需要一个布局文件,一般是ICC生成的;(icc ii design planning);

DC NTX topological mode 是支持物理综合的

DC NTX in topological mode 使用virtual routing 去估计net的长度; virtual routing 使用 Manhattan distance估计两个pin之间的线网的长度;

RC参数的计算也是基于net的长度而不是fanout;

Day1: objectives

加载RTL设计和逻辑库
加载物理库和technology data 包括: physical 或 layout library (NDMdirectories) technology routing layer definition file (tf file) RC modeling files (TLUplus & map files)
加载布局的信息; TCL的物理约束或者来自ICCII的DEF文件

所以整个NTX topo mode flow的输入包括: RTL design .v文件,design constraints 设计约束文件,db库文件,物理库文件 ,floorplan的DEF文件

指定technology的逻辑库

DCNTX flow 需要指定technology的逻辑库,才能完成综合;

标准单元库
宏单元和IP库

每个逻辑库对应单一的PVT属性或者工作条件;

标准单元的功能和属性信息

通过.lib中对标准单元的表述我们可以获得以下信息:

cell的name ,面积,引脚信息,design rule constraints(每个引脚的 function max_capacitance mian_capacitance)

附加的需求: DC NTX generic logic library(DC的通用逻辑库)

这个generic logic library 是由DCNTX提供的,在仅进行功能的综合时,可以用他来描述RTL结构.

通用的逻辑库用来在读入RTL文件加载入DCNTXshell转换成未布局的gtech ddc 格式

target library:用来选择指定工艺的单元

用来生成,technology-specific的门级网表;

DC NTX 会选择指定工艺库中最小的满足DRC timing和逻辑功能的单元.

在综合之前,需要指定实际的由芯片的供应商或者库组提供的标准单元库文件

set_app_var target_library libs/20nm_wc.db

使用以下命令可以查看那些从默认设置中修改的所有application variable:

get_app_var -list -only_changed_vars *

link_library:用来解析实例化的reference

用来link设计,解析RTL设计中或者门级网表中实例化的参考;

在link设计之前指定标准单元和IP 逻辑库的名字

reference(参考),是那些门,逻辑块,子设计,在设计中的实例化

search path:用来指定搜索路径

search_path = “. <install_dir>/libraries/syn

<install_dir>/dw/sim_var

默认的search_path包括需要的通用库的路径;

增加search_path到默认路径,而不是over_write(覆盖)

set_app_var search_path "$search_path\

mapped

libs

cons"

application variables是全局的变量而非私有的

在相同的工具环境下会应用到所有的设计中;

设置也不会跟随设计而保存;当工具的会话结束时(tool session ends) 这些application variable会恢复到默认状态;

所以application variables需要在工具启动时重新设置;

处理analyze命令产生的中间文件(intermediate files)

会产生 .syn .pvl .mr文件

这些文件被保存在由 application variable"WORK”指定的路径中,默认是CWD,这会使CWD文件夹很杂乱,使用以下命令可以获得更整洁的CWD;

CWD : current design directory

define_design_lib WORK -path ./work

analyze -f verilog TOP.v

你可以指定独立的libraries name 在analyze的时候;

define_design_lib MID -path ./mid

define_design_lib BOT -path ./bot

analyze -f sverilog -library BOT bot.sv

analyze -f sverilog -library MID mid.sv

物理综合的需求

物理综合会将输入的RTL模型生成一个门级网表附带标准单元的粗布局

topo mode 会在综合时生成粗布局布线估计;但这需要物理单元库使用NDM(new data model)格式拥有technology data;并且需要布局的信息;

NDMcell library 或者叫做 CLIBs 包含frame和timing view frame view包含物理拓扑信息,timing view 包含所有的来自原始db库的信息,包含逻辑定义,时序,功耗和其他属性信息;

物理综合所需要的物理信息

来自ASIC代工厂或者library group的物理单元库,(NDM format),包括标准单元的frame view 和 IP核和宏单元的frame view;工艺信息(technology data)包括工艺文件(technology file) TLUPlus文件(RC寄生参数的信息) layer mapping files()

一个"design library”设计库用来存储工艺文件内容和指向物理单元库;

什么是物理单元库

一个标准单元是用指定工艺的基础逻辑门提前设计好版图的

每个标准单元通常都有相同标准的高度

一个物理单元库包含用frame view描述的标准单元的集合,并且在NDM格式下是可用的;

DC NTX和ICCII使用相同的NDMformat,但是ICC使用的物理单元库的格式叫milkways

technology file (.tf文件)

工艺文件,对于每一个technology来说是唯一的

定义了所有的工艺参数;这个文件主要定义的一些 layer的信息,金属,mos管的一些参数,DRCs等等;

布线的方向 routing direction

tech file 并不会定义金属层的优先布局方向；这需要全局的基于布线的拥塞分析;

指定routing direction

set_preferred_routing_direction -layers {M1 M3 M5 M7} -direction horizontal set_preferred_routing_direction -layers {M2 M4 M5 M8 MRDL} -direction vertical

必须在读入了RTL代码或者DDC网表之后才能设置 routing_direction 否则会报错;当前设计没有定义,无法找到object M1

TLUplus file

包含RC的查找表

layer mapping file

是匹配technology file和TLUPlus file的信息;

物理综合需要一个Design library;

更像一个容器,包含设计所需要的工艺文件信息,并指向物理单元库;

第一次综合,创建加载设计库 design library

//create the design library and set tluplus files set ndm_reference_library .../CLIB/saed32_lvt.ndm set ndm_design_library ./MY_design.dlib if{! [file isdirectory $ndm_design_library]} { create_lib -reference_library $ndm_reference_library \ -technology ./tech/saed32_1p9m.tf $ndm_design_library check_library //检查逻辑库和物理库的一致性 consistency }else{ open_lib $ndm_design_library } set_tlu_plus_files -max_tluplus ./tech/***.tluplus \ -tech2itf_map ./tech/ ***.map

关于综合后的网表和floorplan先有鸡还是先有蛋;

解决方法:

two-Phase SPG synthesis flow; 双向的SPG综合流程

pre_floorplan使用的是默认的布局约束

如果没有指定约束的话;

它会使用: 1. 方形的core的放置区域

核心的大小基于60%的利用率
将宏单元和标准单元一起摆放
顶层端口的位置是任意摆放的

那如何修改pre_floorplan的默认布局约束呢

默认的core size and shape

set_utilization 0.6 标准单元利用率 60%

set_aspect_ratio 1 正方形

定义精确的矩形/直线 core或die的面积

先将默认的utilization和aspect ratio改掉

标准单元和宏单元放在 core area

pads和 I/Opins 放在die area

默认 DCNTX 声明的core area和die diearea 是一样大的;

除非用 crate_site_row被用来定义 core area 的边界;

create_die_area -coordinate {{0 0}{600 400}}

用它来定义core area的面积边界

example : 物理约束文件

post_floorplan synthesis 布局后综合,加载floorplan

在经过ICCII的设计布局后,布局的信息通过 write_floorplan 输出为 DRF文件和floorplan的tcl文件

在DCNTX中加载ICCII的floorplan

create_net -power “VDD VDDL"

create_net -ground VSS

read_floorplan floorplan_dc/floorplan.tcly

读取tcl文件就会将DEF文件读入?

时序约束

输出capacitive laod的影响

输出端口的电容负载会影响transition time,因此会影响到cell输出到outputdriver的delay,

DCNXT默认outpu的capa load为0;所以给output capa load 一个估计(为capa load 建模)是十分必要的;

所以设置负载的方式有两个:

直接给输出端口赋 capa的值

set_load -max [expr {30.0/1000}] [get_ports B]

为输出端口指定具体的标准单元,利用laod_of 计算此标准单元的capa

set_load -max [load_of my_lib/AN2/A] [get_ports B]

set_laod -max [expr {[laod_of my_lib/AN@2/A] * 3}] [get_ports B]

输入Transiton time的影响

和输出的capa 为一对 ,同样会影响 cell delay of the input gate,同样DC在默认情况下, input的transitiontime 也为0;

同样有两种方式,like output_load :来指定input_transition:

set_input_transition -max 0.12 [get_ports A]
set_driver_cell -max -lib_cell OR3B[get_ports A] 对于这种一输出的门来说,不用指定pin
set_driver_cell -max -lib_cell FD1 -pin Qn [get_ports A]

如果在综合之前,你不知道input_driver 和output_load呢

这就需要 load budget;

load budget assumptions 负载预算假设;

应用一个弱驱动,在输入引脚(作为保护) :inv1a1

应用一个合理情况下最大的负载;

_(待补充)

负载预算脚本

reset_design

source timing_budget.tcl

set all_in_exp_clk ...

set_driver_cell -max -no_design_rule -lib_cell inv1a1 $all_in_exp_clk

set max_capacitance [expr {[load_of ssc_core_slow/and2a1/A]* 10 }] &all_in_exp_clk

set_load -max [expr {[load_of ssc_core_slow/and2a1/A] * 3 }] [all_outputs]

其中set_max_capacitance是设计规则的约束 DRC 限制一个端口扇出的capacitance,默认情况下,DRCs 比时序面积约束又会更高的优先级;所以不要过度约束用户定义的DRCs 是十分重要的;

DC NXT Ultral synthesis tech DC的极端综合科技

一个最优的综合结果需要:

高质量的RTL代码适合综合的
完整精确的约束
适用所有DC ultra的优化选项
利用DCNXT 物理指向的有点;

简化综合流程,对大的设计最好使用 top-down的综合

默认的优化选项of compile ultra

1, 三个层次上的优化

architecture

logic level

gate level

什么是DesignWare library 设计容器库

soft IP和datapath 元件的集合,这里的IP主要是算术运算符的小IP

当输入输出的宽度超过4bit的话,会封装成hierarchy

单算术运算的优化

DW库会使用数据路径生成器去建立不同算术运算符的运算结构

这些不同的结构使得compile_ultra可以选择执行最好的结构应用到设计中;

一旦选择了某一结构的运算符,便会针对目标工艺库进行优化;

数据路径的优化,CSA transformation

CSA: carry save adder,其实指的是carry save adder tree; 超前进位加法器;

超前进位加法器在大部分情况下,相较于传统的加法器,是小而快的;

关键路径的二次综合;re_synthesis

在compile_ultra下国建路径的二次综合会在需要的时候自动执行;

CPR (critical path re-synthesis)在compile指令下也可以执行,加option -map_effort high

当门级不符合时序,或存在违例的关键路径,会返回logic_level进行忧化;然后再次mapping 网表;这样循环往复;

负载划分和组合逻辑的复制

会减少critical_path的延迟,得到更快的电路,但是面积会更大;

这个选项是常开的,没有option可以将其关闭;

库的分析 library analysis (ALIB)

会利用库中的单元,创建一个缓存区,存储一些常用复杂布尔运算逻辑的实现

会得到的更好的面积优化的结果;

ALIB 对于每一个工艺库都会生成一次,可以在下次使用此库时继续使用,也可被别的用户使用;

当ALIB不存在时候,使用alib_analyze_libs命令,可以人为生成ALIB,一般在第一次执行compile_ultra命令时,会自动生成,使用alib_library_analysis_path选项,指定ALIB生成的文件路径;

子模块pins的保持

默认综合必须保持子模块在层次上pins的定义;

旨在优化逻辑上冗余,可以被合并或者剔除的逻辑门;

自动解除组合 auto_ungroup 是默认开启的;

它会自动将poorly partition(congestion 比较大)的层次解组,所谓的poorly partition:如果他的数据输入,并不是直接与寄存器输出相连,或者所有的输出是不被储存的;换句话说:一个好的分割(well partition),的子设计没有用没有时钟的组合逻辑或者寄存器输入作为层次便捷的划分;

可以在compile_ultra 后加option 解除自动的ungroup;

compile_ultra -no_autoungroup;

也可以指定不能被ungroup的design或者cell;

自动的ungroup允许组合和时序偶记电路的优化;,但是这会可能影响形式验证

在综合期间,工具会自动生成default.svf文件,这个文件记录了设计中的边界优化,寄存器复制和ungroup;可以被formality 做形式验证时读入;

set_svf <My_svf.svf> 命令可以自定义svf文件的名字,此命令要在读入RTL设计之前执行;

DW库hierarchy的自动ungroup;

auto_ungroup 也会自动解除DW库的hierarchy结构;可以单独控制不对DW库做ungroup;

set_app_var compile_ultra_ungroup_dw false

boundary optimization 边界优化默认开启

在未开启ungroup的时候,compile_ultra 还会利用boundary optimization在保持当前hierarchy结构的前提下,对sub_design的内部边界逻辑进行优化;

当然边界优化也是可控的,通过设置app_var 可以指定design不被边界优化,+option,关闭compile_ultra的自动boundary optimization;

DesignPartitioning 设计划分;

将涉及划分成子设计或者块(block) 对于大型的设计来说是十分必要的,driven by following:

划分单独的功能区
实现可行的规模和复杂性
在团队工作中管理项目
设计的复用;

设计的划分准则 for DCNXT

在可用的内存资源和可接受的运行时间的允许下尽可能大的划分block;

划分sub_design尽可能用寄存器作为输出;

考虑层次化布局的需要;

自动的 shift_register 识别

compile_ultra 在-scan的option下会自动将电路的移位寄存器进行识别,并直将第一个寄存器替换为扫描链用的寄存器;

默认是自动打开的,可以通过设置appvar将其关闭;

adaptive retiming(移动寄存器的位置)

通过移动寄存器,去减少关键路径的违例;(WNS) worst negative slack; 特别是对于pipeline结构的逻辑电路来说;

Adaptive retiming的基本原则

Adaptive retiming 通过移动,分割,合并寄存器来实现WNS的减少;

end_to_end的功能并不会改变;

如果综合后的网表文件中存在 R_##的寄存器就说明此设计被retiming了

可以指定特定的cell 和设计不被retiming:set_dont_retime <cell name or designs> true

时序优先的综合(High_Effort timing optimization)

默认情况下,max_transition max_fanout max_capacitance 这些DRCs拥有更高的优先级,相较于timing来说;如果智能优化解决DRC的违例和时序的违例其中的一个,那么DRC的违例会被解决;

但是有是有对于综合来说,fix setup timing要比DRC违例要更重要;

所以可以使用以下命令: set_cost_priority -delay

在许多工艺库中,那些不伤害delay的情况下没有办法被修复的重大的DRC的违例,像:输入端口存在大量的外部负载,或者在一端标记dont_touch的逻辑,将max_delay的优先级放在DRC之前,允许这些DRC的违例在不伤害delay的情况下去解决;

比如 DCNXT 可能会在另外一个模块里面重新设置驱动的大小;

当综合一个小的逻辑块的时候:比如从一个大设计中摘取出的一小部分电路区域;很有可能在这个块的边界其over_constraints 比较高,在他重组进大的设计之前,最好将DRC的fixing放在次要的位置;(postponed)

时钟网络,默认DRC -disabling;

默认情况下:DRC的fixing对于那些直接与寄存器的时钟引脚相连的时钟网络来说是关闭的;

时钟网络从clockpin 被逻辑分离出来的不是DRC无效的,可能会添加buffer 使其满足DRC;

当然有办法将所有的时钟网络都是DRC检查无效的;

set_auto_disable_drc_nets -on_clock_network true

这里有好几种方式可以将时钟网络的DRC检查关闭:

除了上面的哪种方法之外,做常用的还有:

set_dont_touch_network [get_ports clk]

set_ideal_network [get_ports clk]

默认的路径分组(path group)

在综合期间每一个时序路径,都会依照路径相关联的时钟放在一个路径组中;

DC NXT会依次优化每一个路径组;每一个路径组中的关键路径;

使用report_path_group 可以报告当前的设计中定义的路径分组;

Problem: 忽略sub-critical path

默认情况下,优化停止的条件是:

这个路径组中的所有的路径都满足时序要求
或者 critical_path没有办法进一步被优化,

在默认分组的情况下很容易产生的问题就是;

比critical_path稍微好一点,但也是违例的路径是不会被优化的;

however: 如果sub_critical_path和critical_path是互相缠绕的,也就是说他们有共享的逻辑电路:很有可能通过提升critical_pathd的timing,就可以解决sub_critical_path的timing问题;

Problem:忽略Reg-to-reg path

solution:用户定义的路径组

用户定义的路径组允许在优化时更多的控制;

每一个路径组都是独立优化的;

一组中最坏的违例不会阻止另一组的违例优化;

创建用户定义的path group

group_path -name INPUTS -from [all_inputs]

group_path -name OUTPUTS -to [all_outputs]

group_path -name COMBO -from [all_inputs] -to [all_outputs]

打开 Near-critical Path的优化

group_path -name clk -critical_rang 0.2

0.2 这个range 不能超过时钟周期的10%

path_group的优先级 -weight

report_path_group

TNS-Driven的placemnet

set_app_var palcer_tns_driven true

compile_ultra

reduce large datdapath delay

减少大型的数据路径的delay;

尝试将datapath中改为流水线结构; 用面积换delay;

一是在RTL代码中自己去插寄存器;

直接将比较长的公式,拆解成几步去完成;

此时时钟的频率被运行最慢的流水线级所限制;

二是工具帮你去插pipeline; register retiming

在综合之前设置application variable: set_optimize_register true -design Pipeline

在执行 compile_ultra

而adaptive retiming目标是减少非pipeline设计的WNS

所以两个优化是可以同时执行的,

所以可以将寄存器(几级流水线,就插几级寄存器)放在要优化的datapath的最前面或者最后见面,用register retiming自己去规划将流水线插在哪.

它会使每一级流水线的所用的时间都是差不多的;