本文主要是介绍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,而不是简单的一路回车,可能会去的意想不到的收获
参考资料
Cadence Innovus User Guide
这篇关于INVS 对时钟二分频器(reg-clkgen)的理解和处理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!