INVS 对时钟二分频器（reg-clkgen）的理解和处理

在时钟树的设计中，有很多方式处理分频时钟，常见的无外乎两种模式：

• 时钟二分频器（reg-clkgen）
• 门控时钟

二者在功能上略有不同，比较的大差异是前者可以简单的实现50%占空比，后者却对功耗友好同时降低了实现难度。这里结合INVS在CTS的手法，一起了解一下INVS对二者的处理差异。闲言少叙，ICer GO!就后端工具而言，CTS是其三大引擎之一，在当下设计的高工艺、高性能的背景下，CTS的重要性越来越凸显，之前项目一键通的CTS方式，已经越来越不能满足日益提升的QoR诉求了。

INVS ccopt 系统简介

INVS在useful skew显然具备强大的优势，其中的ccopt flow，拥有灵活，高效和用户友好等多种特性，其独特的思维方式，给用户在CTS阶段提供了更多的选择和漂亮的QoR数据。从SDC到ccopt系统转化，让INVS采用一种类似数字孪生（digital twins）的方式，将SDC里边的相关命令，一一映射到ccopt系统中，主要来自于下列三个主命令：

• create_ccopt_clock_tree <=> create_clock
• create_ccopt_generated_clock_tree <=> create_gernerated_clock
• set_ccopt_property <==> other CTS setup

通过这种转义/隔离，巧妙的将ccopt构建成一个CTS warpper，将CTS的实现和SDC进行隔断。这样做的好处有以下几点：

• SDC里边的配置和设定，可以在ccopt系统里边进行修正和调整，而无需读入CTS专用的SDC
• CTS的配置通过导出可读文件进行抽取，继承和维护：create_ccopt_clock_tree_spec
• 在ccopt_design开始之前，可以灵活使用set_ccopt_property 命令干预ccopt的实现方式，而不用担心对原生的SDC产生影响。

用户可以在CTS阶段，放心大胆的使用ccopt系统。鉴于INVS是全局useful skew策略，即使在CTS之后，用户任然可以使用ccopt命令对CTS结构进行微调（modify），这样在后续的useful skew流程中，INVS仍然会使用ccopt引擎对相关的数据进行调整。

时钟传播的单调性

CTS的实现中，无论是ICC/ICC2还是INVS，都会强调；unate（单调性）

• unaet：单调传播：譬如：正向单调性的buffer，反向单调性的inveter
• none-unate：非单调传播：XOR，MUX，FF

具体解释详见博主老文；门控时钟检查（clock gating check）的理解和设计应用（上）由于每一个sink（sequential leaf）的时钟都是单沿触发（正沿或负沿），CTS阶段的重要目标就是计算每一个sink的latency，从而对用户的max_skew进行收敛，所以这个传播的单调性（unate）对CTS的影响就很明显：可以看到，在FF1的传播路径上，CLK时钟是正单调性，这样计算CLK-> FF1’CK的路径的时候CTS工具会只会看正沿。但是到了CLK->FF2’CK的路径上，由于XOR的none-unate特性，CTS工具计算latency的时候需要同时关注正相关和负相关的两种情况，在late和early的两种corner的影响下，这个计算量会成倍的增加，同时也会对实际的clock tree做了悲观化。因为实际情况下：XOR的enable大概率是一个半静态信号，这个会间接提高CTS的难度。由于设计的不明确性，可以用过约束来归类这种问题。

时钟二分频器（reg-clkgen）和CG

从上述时钟CTS实现的角度来看，基于寄存器的时钟二分频器（reg-clkgen）是典型的none-unate器件，而通常的CG则是一个典型的unate器件。所以，从时钟树构建的上看，CG是一个被推荐的时钟网络结构，但时钟二分频器（reg-clkgen）不是的。由于CG的结构类似下列：通常CG的尾部是一个or或者一个and，在std-lib中，这两类门很常见，通常会有很多种驱动类型，这种正是CTS需要的风格：功能单一，驱动多样，这个对于构建CTS会非常友好。反观寄存器，相较or/and，不会有这么多的选择类型，加之延迟较大，这个也会间接影响clock latency的质量

时钟二分频器的CTS实现

对于传统的组合逻辑，CTS实现无非面临两种选择：

• 单调性传播：AND，OR，CG， BUF， INV
• 非单调性传播：MUX、 XOR 。、

这样的传播的简单之处在于：由于是组合逻辑，时钟可以一路传播，不会被阻挡。但是对于采用寄存器实现的时钟二分频器（reg-clkgen），由于FF在CTS的传统理解下是属于一个sink器件，时钟的传播会自动在sink器件截止，所以任何穿越FF的时钟都需要用户单独定义。

# root clock create_clock -name CLK [get_port CLK] -period 1 -waveform {0 0.5} # generated clock create_generated_clock -name gen_clk1 -source [get_port CLK] -divided_by 2 -master_clock [get_clock CLK] [get_pin FF1/Q] 

对于上述拓扑结构，CTS的难点不在于divided信号，而在于gen_clk1_enable。众所周知，从CLK向下看，FF1/FF_A/FF_B同属于CLK domain，但是由于FF1的特殊性，会导致FF1‘D上的时序会成为一个gen_clk1时钟路径上的检查点，这个有点像clock gating检查，但又不全是。对于传统的CG检查，INVS有自己独到大处理方式。对于这类检查，INVS提供了一个有趣的配置选项：这个extract_clock_generator_skew_groups的选项是说：如果配置为true（default value），那么ccopt在创建clock_tree_spec的时候，除过正常的基于clock的-auto_sink模式进行skew_group创建，还会基于ff_clkgen结构的分频时钟（时钟二分频器）再独立创建一个使用 _clock_gen打头的新的skew_group，这个SG会包括这个ff_clkgen的所有fanin以及它自己，和原始的SG相比，这个SG拥有更高的优先级。

create_ccopt_skew_group -name CLK_SG -source clk -auto_sinks create_ccopt_skew_group -name _clock_gen_CLK_FF1_SG -source clk -sinks {FF_A FF_B FF1} -rank 1 

这种处理方式需要用户格外注意，如果用户拥有类似下列更为复杂的拓扑结果，INVS默认的处理方法可能并不适用于你的设计：由于这里会有下列的timing path

• FF_A/FF_B -> FF1
• FF_A/FF_B/FF1 -> FF3/FF4

从CTS角度而言，上述FF需要统一做平，如果使用了默认的INVS处理方式，可能会产生意想不到的结果。如果不想使用默认SG的处理方式，请将这个变量设定为false。个人理解**：从INVS而言，上述拓扑结构应该是不是一个典型的设计：既然已经是ff_genclk的enable信号了，那么就应该是一个类似半静态信号，这个不应该是一个关键路径，反言之，这个半静态信号，更应该专注于gen_clk1的生成，而非其他用途。同样FF1既然是一个gen_clk的定义点，那就不应该出现clk2data的情形。一个比较合理的设计应该类似下图：**但是，在当今百家争鸣的年代，已经很少看到有人可以静下心来仔仔细细的研究coding style了，这个时候还想TO，那么灵活运用后端工具进行补刀，可能是一种适应当下情景的变通方式吧。

【敲黑板划重点】

灵活使用ccopt，而不是简单的一路回车，可能会去的意想不到的收获