综合优化策略
compile_ultra
designware library
数据路径优化
CPR可通过compile命令使用，但必须通过-map_effort high选项显式调用
组合逻辑复制始终启用，并根据需要进行以改进时序。没有控制来关闭它，寄存器复制也可用。
库分析基于库中可用单元的简单布尔函数计算更复杂布尔函数的大小和延迟独立实现：
构建最多4个输入的所有函数
构建常用函数>4个输入
每个函数大约生成15个实现
alib_analyze_libs命令可用于显式生成ALIB。否则，如果它不存在。它是在第一次compile_ultra时自动创建.
alib_library_analysis_path变量可用于指定创建ALIB的UNIX目录
如果分析的technology library 中的cell应用或删除了“don’t_use”属性，则不会重新创建ALIB缓存.
1.答案为b
a:使用compile时需要添加库名字，使用compile_ultra 不需要 c:这些IP需要例化进去。
2.答案为c: a: 无cproption b: 使整个datapath更小，更快d:不能减小面积，增加了面积
The following optimization techniques can be controlled to influence timing , area and / or run time results . Thesetechniques can be controlled with special commands applied prior to invoking , or with options when invokingcompile ultra
auto_ungrouping
如果sub-design的所有数据输入未直接连接到寄存器端口，或者如果其所有数据输出未寄存（换句话说），则子设计被视为较差的模块划分。
a well partitioned sub-design does not have hierarchy boundaries that " slice " through non-clock combinational logic or register inputs.
set uu ungroup false可用于禁用对指定cell或reference的autoungroiping。
划分良好的子设计没有层次结构边界，通过非时钟组合逻辑或寄存器输入“切片”Set uuGroup false可用于禁用指定单元格或引用上的自动解组。默认情况下，任何模块划分不好且输入或输出路径违反时序的子设计都可以自动解组，包括顶层块。例如，如果要避免顶层的粘合逻辑，可以禁用所有顶层cells的auto -ungrouping。您还可以使用此属性维护特定设计的层次结构以进行验证，或使用“pipeline”子设计来进行register-retiming。
boundary optimization
-no-autoungroup 选项防止SUB2、SUB3和SUB4的hierarchies自动ungroup，
保留层次，但同时会进行优化，在关掉autogroup的情况下，不能进行跨越边界的优化.
在边界优化中，Design Compiler会对propagates constants，unconnected pins和complement information进行优化，也就是说boundary optimization会对边界引脚一些固定的电平，固定的逻辑进行优化。但是在formility（形式验证），需要告诉formility电路结构发生了改变。这个改变存放在DC的生成文件里。
Since boundary optimization may eliminate output ports and invert input port signals , this can have an impact on verification : For example ,如果为RTL 创建了验证testbench，该testbench会探测和驱动稍后会被反转或者移除的blockport，现存的 test-bench 将不能工作.如果事先知道哪些模块出于验证目的需要被保留，可以使用Set_boundary_optimization仅在选择的模块上进行边界优化。
在编译过程中会自动创建一个名为default.svf的文件，该文件记录了boudary optimization , register repositioning and ungrouping对设计所做的“更改”。此文件可通过synopsys 的形式验证或等效性检查工具读取。svf信息有助于formality验证等效性。可通过set_svf <My_name.svf>重命名该文件。需要在读取RTL文件之前调用此命令。
任何被例化多次的sub-design在compile过程中都会自动“uniquified”：sub-design会被赋予新的唯一referencename（默认情况下，ref_name_0 , ref_name_1等）。在上面的例子中，如果SUB2例化了两次，其中实例I1_SUB2的输入In2和In3如上图所示被连到高/低电平，但实例I2_SUB2的输入In2和In3连接到了drivers，因为这两个实例首先是uniquified的，所以boundaryoptimization将能够执行constant propagation.
Complemented pins被自动重命名为_BAR,这可以通过set_app_varport_complement_naming_style进行修改
如果cells/designs上的set_boundary_optimization设置为true，
则compile_ultra-no_bounday_optimization将对这些cells/designs应用boundary optimization
模块划分
扫描链寄存器
在scan chain stitching，DFT Compiler自动选择更好的（less loaded , less timing-critical) Q or Q-BAR pin用于scan-out of each register
获取更为准确的timing和area信息
adaptive retiming
adaptive retiming is able to reduce the WNS from-0.12ns to-0.04ns . It introduces a new , butsmall violation of-0.01ns to accomplish this.
WNS = Worst negative slack
会导致寄存器数量的增加或者减少
Adaptive retiming可智能选择是否可以repositioned给定register以减少path的WNS。寄存器总数可能因“拆分”而增加，也可能因“合并”而减少，但CombinationLogic保持不变
3.答案：bcd
a：会修改sub_design 的pinname
e:修改过程会记录在svf文件中
4.答案为e
a:默认打开，所以不需要加-auto_ungroup
b: 可以选择性关闭某些模块，不做auto_ungrouping
c:designware默认会做ungroup
d:不是poorly partitioned，而是poorly partitioned且io ports有violation的做
5.答案为a b:做扫描链寄存器插入，只会修改扫描链寄存器为带mux的寄存器，而不做scanchainstitching(扫描链连起来)
c；test_in和test_en 综合阶段，接零，不会影响时序
6：答案为d
high effort timing optimization
只对topo模式下有影响
clock_network DRC fix
设置setuptiming优先于DRC：默认情况下，在优化过程中，max transition、max fanout和maxcapacity 等design rule constraints（DRC）的优先级高于时序，如果优化只能选择修复一个DRC违例或一个时序违例，但不能同时修复，那么将以时序为代价，而修复DRC。
对于综合来说，将修复时序优先于DRC违例可能更为重要，因为DRC是我们人为估计的，不准确，DC更重要的是修复时序违例，设置建立时间的优先级超过DRC：set cost priority - delay
DRC修复仍然执行，但不会影响setuptiming
在许多technology libraries中，在不影响延迟的情况下，唯一无法修复的重大DRC violations是over-constrained nets，例如：input ports with large external loads，或标记为dont touch的逻辑周围。将max_delay优先级放在DRC之前，允许以不损害延迟的方式修复这些DRCviolation。例如，DC NXT可能会调整另一个模块中的驱动的大小。当 synthesizinga small block of logic,，如extracted critical region of a larger design，在block boundaries处的over-constraints的可能性很高。在这种情况下，最好推迟DRC fixing，直到小数据块被regroup成较大的设计。
对于那些直接与寄存器的时钟引脚相连的时钟网络来说DRC修复默认是关闭的;为理想网络，不会加buffer，时钟网络从被逻辑分离出来的没有直接与寄存器的时钟引脚相连的时钟网络不是DRC无效的,可能会添加buffer 使其满足DRC;综合阶段需要使时钟网络为理想的，不插buffer。
上面的命令使得所有的时钟网络都不差插buffer，关闭DRC_fix，但clock作为data的path同样会进行DRC fixing，是推荐的首选方法。
下面也有几种方法可以在clocknetwork中禁用DRCbuffer。
set_auto_disable_drc_nets-on_clock_network true
在整个时钟网络上禁用DRC rule，这会阻止buffer à the desired effect
不影响用作数据的clock nets,这些net会进行buffer来满足 DRC andtiming。这是需要的，因为时钟树综合不会buffer这些作为data net的clock
set_dont_touch _ network [ get ports ”clka… clkE”]
1.将“don touch”属性应用于entire transitive fanout from the clock ports on , up to but not including the registers。这可以防止逻辑的任何添加、移除或大小调整，从而防止在entire clock network插buffer，---------desiredresult。
2.不禁用DRC规则，这意味着可能会在时钟网络上报告DRC违例-----------notdesired
应用于用clock nets that are used as data，防止这些网络由于DRC以及时序的修复来插buffer-----not a desired effect
set_ideal_network [ get portsCLKA]
在从clock ports on , upbut not including the registers的entire transitive fanout 上应用" ideal " and "dont _touch "属性，但不包括寄存器（有一些限制），同时禁用DRC规则，此防止在整个时钟网络上插buffer-----------the desired effect
Applies to clock nets that are used as data，防止这些网络由于DRC以及时序的修复来插buffer----------not a desired effect
无法使用set_auto_disable_drc_nets命令覆盖set_ideal_network命令指定的设置
set_dont_touch_network：时钟不插buffer，但会进行DRC检查，
set_ideal_network：时钟既不插buffer，也不会进行DRC 检查， clock作为data的path同样也不会进行DRC fixing
path grouping
默认情况下，路径组的名称与其相关的（end_point）时钟对象名称相同。
以路径end_point的时钟作为分组的依据
report_path_group
创建用户定义的路径组还可以促进divide-and-conquer的时序分析策略，因为report_timing分别报告每个路径组的时序。这可以帮助您隔离或分析设计中特定区域中的问题
可以指示工具自动创建路径组。您可以控制工具是在优化之前创建路径组，还是仅为优化之后时序失败的块创建路径组。执行以下操作可以在优化之前创建路径组：
create_auto_path_groups -mode rtl
compile_ultra
remove_auto_path_groups
这将在设计中为每个层次创建一个路径组。如果存在多个层次结构，则工具将在初始编译期间进行优化。但是，设计中的分层级别数量可能很大，导致大量路径组并导致运行时间过长。要在设计初始compile完成后创建路径组，可以使用：
compile_ultra
create_auto_path_groups-mode Mapped
compile_ultra-incremental
remove_auto_path_groups
report_gor
仅用于设计中不符合时序要求的分层块，该工具将为每个层次创建路径组。如果层次结构的多个级别不符合计时要求，该工具将为每个级别创建路径组。在初始或增量编译后，使用remove_auto_path_groups命令可获得仅包含用户创建的路径组的QOR报告，或在初始编译后使用create_auto_path_groups -mode mapped命令删除使用create_auto_path_groups -mode rtl命令创建的路径组。
设定路径组时，from的优先级高于to，
默认情况下，所有路径的critical range是0，修复与critical path共享逻辑的sub-critical paths可能有助于critical path。critical range与critical path delay有关，如果critical path delay有所改善，则critical range band将随着improved critical path而降低。
一旦正在优化的sub-critical paths低于critical range，它将不再优化。如果这些改善使critical range变得更糟，critical range优化不会改善sub-critical path，。对于非0critical range，DC NXT将在设计中减少TNS（Total Negative Slack），即使它不能减少WNS（Worst Negative Slack）。建议criticalrange不超过有效时钟周期的10%，只是为了控制运行时间，如果超过，运行时间将非常长。
为什么不建议使用比5大得多的权重，比如说100（最大允许数）？
回答：理论上，这将允许优化减少reg-to-reg的违例从-0.1ns减少到-0.09 ns（提高10 PS），同时将输入路径违例从-0.4ns增加到-1.4ns（比1000 ps 更差）！这可能不是很好的折中。根据经验，非默认权重数5和2通常是合理的。当然，也可能有一个非常特殊的情况，想要超出“正常”推荐设置，但需要知道潜在的后果（如大幅增加设计的WNS）。
建议通过使用“-weight”选项，将weight分配给不同的路径组。这是为了控制relative priority of violations。具有最高“cost”=Negativeslack * Weight的的路径被赋予最高优先级。例如：一个critical violation为-2ns且权重为5的路径组的cost为10，因此其优先级高于另一个critical violation为-3ns但默认权重仅为1，cost为3的路径组。如果这两条路径相互关联，使得改进一条路径会损害另一条路径，则DC NXT将有利于改进权重较高的路径，即使其slack小于权重较低的路径。group_path命令还具有-priority选项，可用于超越命令默认优先级：指定的priority level为命令分配优先级，以解决不同路径组命令之间的conflicting path选择。
默认情况下，不同的组路径命令遵循普通的优先级规则来解决conflicting path选择。例如，使用-from and -to选择路径的命令优先于使用through选择路径的命令。
目标生将降低代价函数
max_capatiance 设置在inputport；
如果，IO 约束很精确，不能认为IO 约束没有寄存器到寄存器的约束的时序重要。report_path_group
在上述示例中，CLK1和CLK2组被认为是最关键的组，因此给出了5的权重。CLK3组仍然是关键的，但低于CLK和CLK2，因此被赋予了2的权重。每一个时钟组被分配了一个不同的关键范围，代表其各自时钟周期的10%（分别为0.3、0.1和0.2）. The INPUTS , OUTPUTS and COMBO groups不被认为是关键的，因为输入和输出延迟约束的估计比较保守。如果I/O路径是关键的，您可以应用适当的权重和关键范围值。上述解决方案是一个非常CPU和内存密集型的选项，但值得考虑。
因为默认情况下，DC NXT只在每个路径组中最关键的路径上工作，所以如果它卡住了，它不会走得很远，因为它无法满足时间要求。通过打开“WINDOW”以允许优化更多路径，DCNXT在设计的其余部分有了更好的工作，即使是以一条路径为代价。您可以通过将其临界范围设置为zero,来限制优化非关键路径的数量，从而保持运行时的合理性
如果I/O端口约束是准确的（不是悲观的），则I/O路径违例不能被认为没有regtoreg冲突重要。因此，对reg-to-reg路径应用更高的权重是不适用的。现在，您可能仍然希望对所有路径应用criticalrange，以便优化次关键路径。由于I/OPath与regtoreg路径具有相同的criticalrange（和权重），因此无需创建单独的I/Opath group。
您将应用以下命令:
group_path -name CLKl -critical 0.3
group_path -name CLK2 -critical 0.1
group_path - name CLK3 -critical 0.2
约束的路径不是时钟、用户定义、**async**或**clock_gating**路径组,
例如st_max/min_delay路径，进入**default**路径组
incrcompile focus 在TNS上
在增量编译（compile ultra-incremental）时序驱动的placement过程中，默认情况下优化设计中的TNS，而不是WNS。要在增量编译期间优化WNS，
在运行compile ultra-incremental命令之前，需要设置：
placer_tns_driven_in_incremental_compile false
register retiming
调用compile_ultra时，首先使用ultra中的全套DataPath优化技术对datapath logic进行优化。起初是谨慎的算术逻辑即对应的组合逻辑。现在开始registerretiming，它首先平衡寄存器级之间的slacks（min-period retiming），然后利用任何positive slack来减少每个阶段的寄存器数量（minarea retiming）。现在形成了一组新的组合逻辑，进行了更多的逻辑优化。这可能会引入一些timing violations -例如，通过修复high-fanout DRC violations.然后调用adaptive retiming以进一步减少或消除timing violations。
使用set_svf<my_name.svf>以记录寄存器位置更改。这有助于确保Synopys的formality工具成功地进行fomalverification,在读取RTL之前调用此命令.
由于“-retime”选项而产生的adaptive retiming对将set_optimize_registers 设置为true的设计没有影响
但是，register retiming 包含adaptive retiming " post-processing " step ,寄存器重定时包括自适应重定时“后处理”步骤，如果需要，该步骤将自动应用于pipeline registers。它不受“-retime”选项的控制，无论是否使用该选项
对于应用了set_optimize_registers true的任何设计，编译期间的auto_ungrouping将自动禁用，因此用户无需显式应用set_ungroup false,以防止在应用register retiming优化流水线设计之前auto-ungrouping并删除hierarchy。
在上面的示例中，名为PIPELINE的设计包含三个独立pipeline，标记为pipelined_1到pipelined_3，在整个PIPELINE块上使能registerretiming：
set_optimize_registers true –design PIPELINE
如果同一pipeline内的不同路径具有广泛变化的总组合逻辑延迟回路”，则“延迟回路”由最长路径确定，这也可以限制pipeline内sub-critical paths的retiming。在这种情况下，唯一的解决方案是使能threshold optimization（因为将pipeline的每条路径放在其自己的层次结构中并不实际）
多核优化
如果出现randomcrash或者error可以尝试减小core运行尝试
选B，
registerretiming不会改变 pipelinestages的个数，但会改变寄存器的个数，
8：captureclock
9：F:没有nearcriticalpath
10:criticalrange可以修复 near_criticalpath ,near_criticalpath 和 critical path之间有关系，会改善critical path，同时减少TNS数量
11.A b: path group而不是create_clock,C:critical range
12.T,可能会导致某个路径组的时序变差，但总的TNS 是降低的
13.F速度的增加不是线性的
1.设置多核2.up_timing， parallel_execute
可使用parallel_execute_list_all列出由parallel_execute执行的受支持的命令
增量编译，进一步优化
检查约束是否有问题和修改约束，修改RTL。
- compile_ultra 2.compile_ultra -incremental （通常会进行多次compile）最后的optimize_netlist 不会伤害timing和power
- You can ignore the weights set on path groups during area optimization by
- 设置set_optimize_area _ignore_path_group_weights true 可以在面积优化时忽略路径组上设置的权重. 该变量的默认值为false。启用变量时，当执行optimize_netlist_area命令进行面积优化时，所有路径组的权重都设置为I。在面积优化之后，每个路径组上的权重将恢复为用户指定的原始值。
