Cadence Innovus中createInstGroup命令详解与应用实战

1. 项目概述：为什么我们需要createInstGroup

在数字后端设计的物理实现流程里，尤其是使用Cadence Innovus这类工具时，我们面对的是一个由数百万甚至上千万个标准单元（Standard Cell）构成的复杂网络。这些单元散落在芯片的版图上，就像一座巨大城市里的建筑。如果我们想对某一类“建筑”进行统一的管理、约束或操作，比如给所有位于特定区域的“学校”（比如时钟缓冲器）设定统一的供电标准，或者把所有“医院”（比如关键路径上的单元）临时集中起来进行加固处理，一个最朴素的想法就是：给它们贴上一个共同的“标签”或“分组”。

createInstGroup命令，就是Innovus中用来创建这个“分组标签”的核心工具。它的名字直白地揭示了其功能：创建实例组。这里的“实例”（Instance），指的就是布局布线后，那些具有具体物理位置和连接关系的标准单元、宏模块（Macro）、IO单元等对象。而“组”（Group），则是一个逻辑上的容器，用于将多个具有某些共同特征的实例聚合在一起，以便进行批量操作。

这个命令看似简单，但其背后的应用场景和设计哲学却非常深刻。它不仅仅是“选中一些东西然后起个名字”，而是后端工程师实现精细化、自动化物理约束管理的关键桥梁。无论是为了优化时钟树综合（CTS）的局部拥塞，还是为了对特定模块进行功耗分析，亦或是为了实现复杂的布局约束（如模块化布局、电压域划分），createInstGroup都是不可或缺的第一步。

2. 命令核心语法与参数深度解析

createInstGroup的命令基础语法结构清晰，但每个参数都蕴含着特定的设计意图。一个完整的命令调用通常如下所示：

createInstGroup <group_name> \ -region {<llx> <lly> <urx> <ury>} \ -inst <instance_list> \ -pattern <pattern_string> \ -hinst <hierarchical_instance> \ -physical \ -timing \ -exclude

让我们逐一拆解这些参数，理解其背后的“为什么”：

2.1 核心参数：定义组的成员

组的成员可以通过多种方式指定，这体现了工具设计的灵活性，以适应不同场景下的筛选需求。

-region：基于物理区域的“圈地”分组这是最直观的一种分组方式。通过指定一个矩形的左下角（llx, lly）和右上角（urx, ury）坐标，所有完全或部分位于该区域内的实例都会被加入组中。

• 为什么需要它？在布局规划（Floorplan）阶段，我们经常需要根据模块的物理位置来施加约束。例如，创建一个名为CPU_CORE_REGION的组，包含核心CPU区域内的所有逻辑单元和存储器，以便统一设置该区域的高密度布局规则或电源网络参数。坐标通常以微米（um）或数据库单位（DBU）给出，需要与当前设计的布局坐标系一致。
• 实操注意：使用-region时，要清楚工具对边界实例的处理规则。通常，只要实例的边界框（BBox）与指定区域有交集，就会被包含。如果只想包含完全在区域内的实例，可能需要结合后续的筛选命令或使用更精确的坐标计算。

-inst：基于明确实例列表的“点名”分组直接提供一个Tcl列表，列出需要加入组的所有实例名称。

• 为什么需要它？当我们需要分组的实例列表已经通过其他命令（如get_cells,filter等）精确获取时，这是最直接、最没有歧义的方式。例如，在脚本中先通过时序分析找到一批关键路径上的驱动单元，然后将这些单元放入一个名为CRITICAL_DRIVERS的组中，以便后续进行尺寸优化或布局加固。
• 实操心得：当实例数量巨大时，直接构造列表可能导致命令过长。更优雅的做法是先将列表存入一个Tcl变量，然后在命令中通过变量替换引用。例如：

  set high_fanout_cells [get_cells -hier -filter “pin_count > 50”] if {[llength $high_fanout_cells] > 0} { createInstGroup HIGH_FANOUT_CELLS -inst $high_fanout_cells }

-pattern：基于名称模式的“模糊”分组使用通配符（*匹配任意字符，?匹配单个字符）来匹配实例名称。

• 为什么需要它？在层次化设计中，实例名称往往带有规律性的前缀或后缀。例如，所有属于某个子模块U_MMU的实例可能都以U_MMU/开头。使用-pattern “U_MMU/*”可以快速地将该子模块的所有叶子单元（不包括其本身）加入一个组。这对于模块级的约束管理非常高效。
• 避坑指南：通配符匹配需要谨慎。*非常贪婪，可能匹配到超出预期的实例。建议先在get_cells命令中使用相同模式进行测试，确认返回的列表符合预期后，再用于createInstGroup。例如，get_cells -hier -pattern “U_MMU/*”先查看结果。

-hinst：基于层次实例的“子网”分组指定一个层次化实例（如一个子模块的顶层实例），该实例下的所有叶子单元（不包括其内部的子层次实例）会被加入组。

• 为什么需要它？这是处理层次化设计最自然的方式之一。它直接对应了设计的逻辑层次。当你需要对一个完整的IP核或功能模块施加物理约束（如区域约束、密度约束）时，使用-hinst比用-pattern更精确，也比用-region更贴合逻辑结构。
• 与-pattern的区别：-hinst U_MMU会将U_MMU这个实例内部的所有最底层单元加入组，但不会包含名为U_MMU的实例本身（它是一个层次块）。而-pattern “U_MMU/*”的匹配范围取决于命名规则，可能有所不同。

2.2 修饰参数：定义组的属性与行为

创建组之后，我们还可以通过一些修饰参数来定义这个组的附加属性，这些属性会影响后续哪些命令可以作用于该组。

-physical：声明为物理组这是最常用、最重要的修饰符。它声明这个组主要用于物理实现相关的操作，如布局、布线、电源规划、物理优化等。

• 为什么需要它？Innovus 中的“组”概念是分域的。一个被标记为-physical的组，可以被place_opt、ccopt（时钟树综合）、addStripe（添加电源条带）等物理实现命令识别和引用。例如，你可以创建一个物理组HIGH_DENSITY_AREA，然后在运行place_opt时，通过-incremental和-inst_group参数，只优化这个组内的单元，而不影响其他区域。
• 默认行为：如果不指定任何修饰符（-physical或-timing），创建的组通常是一个“通用组”，但某些命令可能只识别特定类型的组。为清晰和避免意外，建议总是根据用途明确指定-physical或-timing。

-timing：声明为时序组声明这个组主要用于时序分析相关的操作。

• 为什么需要它？当时序组被创建后，可以在设置时序约束（如set_max_delay、set_min_delay）、进行时序报告（report_timing）时，通过-group选项来指定范围。这对于分析特定模块或路径组的时序性能非常方便。例如，将某个时钟域的所有寄存器创建一个时序组CLK_A_REG，然后单独报告该组的建立时间（setup）和保持时间（hold）违规。

-exclude：创建“排除组”这是一个非常实用的功能。它创建的不是一个包含成员的组，而是一个“黑名单”。后续在对其他组或区域进行操作时，可以引用这个排除组，将其成员排除在外。

• 为什么需要它？在复杂设计中，经常有需要“保护”起来的单元，比如已经手工精心布局的模拟模块接口单元、特殊的填充单元（decap）等。我们不希望自动布局布线工具去移动或优化它们。这时，可以先用createInstGroup -exclude FIXED_CELLS -inst [list ...]创建一个排除组。之后，当你在某个区域运行优化命令时，可以添加-ignore FIXED_CELLS参数，确保这些被“冻结”的单元不受影响。
• 应用场景：假设你有一批用于电源完整性的去耦电容（DCAP）被手工放置在坐标X=100um的位置，并且不希望它们被工具移动。你可以先找到它们：get_cells -filter “ref_name == DCAP2 && location_x == 100”，然后将其加入排除组FIXED_DCAP。这样，在后续的全局布局或优化中，这些DCAP就会保持原位。

3. 实战应用：从场景到脚本

理解了命令的“筋骨”（语法），我们再来看看它的“血肉”（实战）。下面通过几个典型的场景，展示如何将createInstGroup融入实际的后端设计流程。

3.1 场景一：模块化布局与区域约束

在超大规模设计中，模块化（Block-Level）设计流程非常普遍。每个子模块（Block）先独立进行综合和布局，形成物理抽象（如LEF），再在顶层进行集成。createInstGroup在这里扮演了定义模块边界的角色。

操作流程：

1. 导入子模块的物理信息：在顶层设计中，除了子模块的抽象（LEF），通常还会导入其布局后的DEF或OA数据，这样子模块内部的实例网表也会被加载进来，但可能处于“不可动”的状态。
2. 为子模块创建物理组：使用-hinst参数为每个子模块的顶层实例创建物理组。这相当于告诉顶层工具：“这些单元属于一个逻辑整体”。

   # 假设顶层有三个子模块实例 U_CPU, U_GPU, U_NPU createInstGroup -physical GROUP_CPU -hinst U_CPU createInstGroup -physical GROUP_GPU -hinst U_GPU createInstGroup -physical GROUP_NPU -hinst U_NPU

3. 应用区域约束：你可以为这些组创建对应的布局区域（Placement Region），或者直接将它们与已有的布局区域关联起来。这样，在顶层布局时，工具会尽量将这些组的成员约束在指定的区域内，保持子模块内部的相对布局，同时允许在顶层进行微调以适应全局连接和时序。
4. 精细化控制：你还可以基于组的属性，设置不同的布局密度（Placement Density）、布线层限制（Route Layer）等。例如，对高功耗的GPU模块区域，设置更宽松的密度以避免热点。

注意事项：

• 确保子模块实例（U_CPU等）在设计中确实存在且是层次化实例（get_cells U_CPU可以查到）。
• 在创建组之后，使用reportInstGroup命令检查组成员是否正确。
• 模块化布局中，子模块的电源网络（Power Mesh）可能需要特殊处理。创建组有助于在顶层规划时识别这些区域，并施加不同的电源条带规则。

3.2 场景二：时钟树综合（CTS）的局部优化

时钟树综合是后端流程中的关键一步，其质量直接影响时序和功耗。我们经常需要对时钟网络的不同部分进行差异化处理。

操作流程：

1. 识别关键时钟路径：通过时序分析或结构分析，识别出时钟网络中负载重、路径长的部分，或者位于高拥塞区域的时钟缓冲器（CLKBUF）。
2. 创建时钟单元组：将这些需要特别关注的时钟单元加入一个物理组。

   # 找到所有驱动超过50个sink点的时钟缓冲器 set heavy_clk_bufs [get_cells -hier -filter “ref_name =~ CLKBUF* && fanout_load > 50”] if {[llength $heavy_clk_bufs] > 0} { createInstGroup -physical HEAVY_CLK_DRIVERS -inst $heavy_clk_bufs }

3. 在CTS命令中引用组：运行ccopt命令时，可以使用-inst_group参数对其施加特殊的优化策略。例如，可以对这个组内的缓冲器设置更大的尺寸范围（-size_only列表），或者允许工具对其进行更激进的缓冲器插入和尺寸调整，以确保该部分时钟网络的延迟和偏斜（Skew）得到严格控制。

   # 在ccopt设计文件（.ctstch）或脚本中指定 set_ccopt_property -inst_group HEAVY_CLK_DRIVERS -max_capacitance 0.5 set_ccopt_property -inst_group HEAVY_CLK_DRIVERS -cell_list {CLKBUFXL CLKBUFX2 CLKBUFX4}

4. 后期修复：CTS后，如果发现某个局部区域时钟偏差仍然很大，可以手动将该区域的时钟单元（包括缓冲器和门控时钟单元）创建一个组，然后使用clock_opt的增量模式，仅对该组进行优化，避免扰动其他已经稳定的时钟网络。

避坑技巧：

• 在CTS前创建组是有效的。如果在CTS运行中途动态创建组，可能需要重启CTS阶段或使用增量命令才能生效。
• 对时钟单元分组进行过度约束（如过紧的电容限制）可能导致CTS无法收敛，或插入过多缓冲器增加面积和功耗。需要根据实际时序报告和拥塞情况反复调整。

3.3 场景三：功耗分析与优化

对于低功耗设计，需要对不同电压域（Voltage Domain）或电源门控（Power Gating）区域的单元进行分别管理。

操作流程：

1. 依据电压域创建组：设计中的标准单元通常属于不同的电源域（如VDD_CORE, VDD_MEM）。可以通过单元的特性或布局区域来筛选。

   # 方法1：如果单元有相关的属性（需要UPF/CPF支持） # set vddl_cells [get_cells -hier -filter “voltage_area == VDDL”] # 方法2：如果不同电压域的单元布局在不同区域（更常见） # 假设VDD_MEM区域在坐标 (100,100) 到 (200,200) 之间 createInstGroup -physical DOMAIN_MEM -region {100 100 200 200}

2. 进行域特定的分析：在运行功耗分析工具（如Cadence Voltus）时，可以针对不同的组报告其静态功耗（Leakage）、动态功耗（Switching）和内部功耗（Internal）。这有助于精准定位功耗热点。
3. 应用功耗优化：在物理优化阶段，可以对高功耗区域的组施加特殊的优化策略。例如，对DOMAIN_MEM组中的单元，在满足时序的前提下，优先选用低泄漏（Low-Vt）但高阈值的库单元，或者更积极地插入电源门控单元。
4. 处理电平转换器（Level Shifter）和隔离单元（Isolation Cell）：这些用于电压域接口的特殊单元，更应该被明确分组和管理，以确保它们被正确放置在其所属的电压域边界附近。

经验分享：

• 功耗组的创建强烈依赖于设计的前期规划（Floorplan）和电源网络架构（Power Intent）。清晰的区域划分是有效分组的基础。
• 除了createInstGroup，Innovus 中更专业的功耗管理是通过UPF（Unified Power Format）或CPF（Common Power Format）文件来实现的，它们定义了电压域、电源开关等对象。createInstGroup可以作为UPF/CPF流程的补充，用于一些工具内部、更灵活的临时分组需求。

4. 高级技巧与问题排查

掌握了基础应用后，一些高级技巧和常见问题的解决能让你更游刃有余。

4.1 组的嵌套、合并与查询

• 嵌套（间接实现）：Innovus的组本身不支持直接的层次嵌套（即一个组包含另一个组）。但可以通过脚本逻辑实现类似效果：先查询父组的成员，再基于这些成员创建或添加到一个新的“子组”中。这通常用于对一个大组进行更精细的划分。
• 合并：没有直接合并组的命令。标准做法是：分别获取两个组的成员列表，合并列表，然后创建一个新组，或者将合并后的列表添加到一个已存在的组中（使用addInstToInstGroup命令）。
• 查询与管理：
  • reportInstGroup [<group_name>]：报告一个或所有组的信息，包括名称、类型（物理/时序）、成员数量等。使用-full选项可以列出所有成员名称。
  • getInstGroup：获取符合模式的组对象，常用于脚本中。
  • addInstToInstGroup/removeInstFromInstGroup：动态地向已有组中添加或移除实例。这在迭代优化流程中非常有用。
  • deleteInstGroup：删除不再需要的组，释放内存。

4.2 性能考量：处理超大设计

当设计规模达到千万级单元时，不加选择地创建包含海量实例的组，或者频繁地对大组进行操作，可能会对工具的内存和性能产生影响。

• 按需创建，及时清理：只在必要的步骤前创建组，并在该步骤完成后，如果组不再需要，就将其删除。避免在脚本中保留大量“僵尸组”。
• 使用更精确的筛选条件：尽量结合-region、-pattern、-filter等多种条件，创建目标明确的、成员数量可控的组，而不是先创建一个巨大的组再从中筛选。
• 利用Tcl脚本的效率：在循环中操作组时，注意Tcl脚本的效率。例如，避免在循环内多次调用createInstGroup，而是先在循环外构建好实例列表，最后一次性创建组。

4.3 常见问题与解决方案速查表

问题现象	可能原因	排查步骤与解决方案
创建组成功，但后续命令（如place_opt -inst_group）提示组不存在或为空。	1. 组类型不匹配。 2. 组成员在命令执行时已被移动或删除。 3. 坐标单位或筛选条件有误，导致组实际为空。	1.检查组类型：用reportInstGroup -full确认组是PHYSICAL类型。时序命令需要用-timing创建的组。 2.检查设计状态：确认在创建组和执行命令之间，没有进行过导致实例改变的操作（如删除、反标等）。 3.验证组成员：创建组后立即用reportInstGroup <group_name> -full查看前几个成员，确认非空且符合预期。检查-region坐标是否在当前设计的布局范围内。
使用-pattern创建的组，成员数量远多于或少于预期。	通配符匹配范围过宽或过窄。层次化设计中路径分隔符（/）的影响。	1.先用get_cells测试：在创建组前，执行get_cells -hier -pattern “你的模式”，查看返回的列表是否正确。 2.理解层次：-pattern “U_A/*”匹配U_A下的所有叶子单元。-pattern “U_A*”会匹配所有以U_A开头的实例，可能包括U_A,U_AB,U_A/sub等，范围更广。
对组进行操作后，设计出现非预期的单元移动或时序恶化。	组的约束过于严格或与其他全局约束冲突。	1.检查约束优先级：物理组的约束可能与布局区域（Placement Blockage）、密度屏（Density Screen）等约束叠加，导致过度约束。尝试放宽组的约束条件。 2.增量优化：对于关键组，使用place_opt -incremental -inst_group进行局部优化，而不是在全局优化中施加过强约束。 3.分析时序报告：比较优化前后的时序报告，看是否是组内单元的优化导致了组外路径的恶化。可能需要平衡组内外的约束。
脚本中创建的组，在重新打开设计后消失。	组信息默认保存在内存中，未保存到设计数据库（如.enc文件）中。	在创建重要、需要持久化的组之后，使用saveDesign命令保存设计。saveDesign会保存当前的组信息。下次用restoreDesign加载设计时，组会一同被加载。

4.4 一个综合案例：解决特定坐标的DCAP2单元问题

结合网络热词中的一个具体问题：“innovus里如何用命令实现把所有x坐标为100 cell 类型为dcap2的instance 的place”。这里的“place”可能指“放置”或“处理”。假设我们的需求是：将所有X坐标在100um附近、且引用名为DCAP2的实例固定住，防止被布局工具移动。

解决方案步骤：

1. 精确筛选目标实例：使用get_cells命令配合-filter选项。坐标判断需要考虑数据库单位（DBU）和浮点精度，通常使用范围判断更可靠。

   # 假设设计单位是微米(um)，我们允许一个很小的误差范围，比如 +/- 0.001 um set target_x 100.0 set tolerance 0.001 set lower_x [expr $target_x - $tolerance] set upper_x [expr $target_x + $tolerance] set fixed_dcap_cells [get_cells -hier -filter \ “ref_name == DCAP2 && location_x >= $lower_x && location_x <= $upper_x”]

   • 为什么用范围判断？在数据库中，坐标可能是浮点数，直接判断相等（==）可能因精度问题失败。
   • ref_namevs.base_cell：ref_name通常指实例化时引用的库单元名称（如DCAP2），而base_cell可能指向更基础的库单元。这里用ref_name更直接。

2. 创建排除组：将筛选出的实例加入一个排除组（-exclude）。

   if {[llength $fixed_dcap_cells] > 0} { createInstGroup -exclude FIXED_DCAP_AT_X100 -inst $fixed_dcap_cells puts “INFO: Created exclude group ‘FIXED_DCAP_AT_X100’ with [llength $fixed_dcap_cells] cells.” } else { puts “WARNING: No DCAP2 cells found near X=$target_x.” }

3. 在布局优化中应用排除：在后续运行place_opt或任何可能移动单元的优化命令时，使用-ignore参数引用这个排除组。

   place_opt -incremental -ignore FIXED_DCAP_AT_X100

   这样，工具在进行布局优化时，就会跳过这个组内的所有DCAP2单元，保持它们的位置不变。

4. 验证：优化后，可以再次检查这些单元的位置是否真的没有变化。

   foreach cell $fixed_dcap_cells { set loc [dbGet [dbGet -p top.insts.name $cell].location] puts “Cell $cell remains at $loc” }

这个案例展示了如何将createInstGroup与精确的实例查询、以及后续的物理实现命令参数结合，解决一个非常具体的工程问题。它体现了后端工程师通过脚本将设计意图准确传达给工具的典型工作流。