老驴发现『问题』地出现是有聚集效应的——某段时间突然间许多人都在关心 Congestion 就像每个客户的每个 Design 都被 Congestion 阻挡住了前进步伐;而另一段时间大家又突然开始关心面积,面积是天面积是地面积是可以牺牲其他一切来换取的『核心价值』;而最近大家又一股脑的都关心起了功耗,几毫瓦几毫瓦地扣,乍看都笼罩了层匠人精神。

 

小时候下田锄地拔草,连续劳作超过三天,晚上睡着后就会梦到无边无边的野草把麦子豆子遮得严严实实的,最近晚上经常梦到功耗,leakage, internal, switch, glitch, toggle rate, condition, correlation —— 老驴也码过若干功耗优化功耗计算的文章,最近一篇是《低功耗 | 从综合到 PostRoute 功耗的 Gap 有多大》

 

今日再聊聊 Glitch Power 分析,功耗优化,功耗计算,看似十分简单,做得越细会发现越复杂,通常会笼统地认为如果同一个设计两种实现方式,只要面积接近线长接近线电容接近,功耗应该接近,然而现实是两者功耗在相同波形、相同电压、相同温度、相同 corner 等同等条件下功耗可能相差 2~3 倍或者更多,究其原因是 toggle rate 作祟。

 

目前常用做法是 RTL 波形 + name mapping file + netlist + spef 去估算 netlist 功耗,而 RTL 波形中只有 primary input, macro output, Sequential cell output 的 toggle rate, 其他部分的 toggle rate 都是工具自己计算所得,不同的功耗计算引擎,在计算 leakage, internal power, switch power 时公式不应该有差别,因为这些是有『公理』可循的,而 toggle rate 的计算就开始属灵了,局限于当前的算力,toggle rate 跟 STA 类似只能用各种抽象模型,不同工具之间的差别主要是 toggle rate 的计算模型不同,所以在 debug 不同工具间 power correlatiion 时,如果输入读取没有低级错误,更多的精力要放在 toggle rate 上。

 

拉回来说 Glitch Power, Joules 2019 年新加了 Glitch power 分析功能,Joules 的 Glitch Power 分析针对 netlist 需要有后仿波形。对于『逻辑无效翻转 Glitch 』可以分为:

 

Transport Glitch: cell 输出在到达稳定状态前的无效翻转,这类翻转消耗的功耗跟正常翻转一样,Joules 目前只分析这类 Glitch power—— Transport glitches are extra transitions at the output of the gate before the output signal reaches its steady state. A transport glitch consumes the same amount of power as the normal transition. The pulse width of the transport glitch is more than the gate delay and does not contribute to the functional behavior of the circuit. 

 

Inertial Glitch:  cell 输入翻转由于宽度小于 cell delay 未传到 cell 输出,这类翻转会对 cell 的 input pin 跟内部结点电容充放电,故消耗功耗,Joules 目前还不支持这类 Glitch power 的分析—— These are transitions which may occur at the input of the gate. However, they will not be propagated to the output, as the pulse width of the glitch is smaller than the gate delay. 

 

Joules 分析 Glitch Power 的过程为:

 Identifying a glitch: 如果一次 toggle 发生在一个时钟周期内,则该次 toggle 被认为是一个毛刺;如果一次 toggle 是跨时钟周期的,则该次 toggle 不被当做毛刺——Get the clocks reaching (both in and out clocks) the given combination and find out the fastest among them. Get the waveform of the clock; if the two toggles of data signal (going from 0 -> 1 -> 0, or vice versa) fall within a clock cycle, it is a glitch. If the two toggles are across the clock cycle, it is not a glitch. The clock cycle considered is --|__ for positive triggered and __|-- for negative triggered. If there is a pin that goes from PI to PO without any clock, the glitches are not identified for them. 

 

Criteria used for considering transitions as a glitch: 工具进一步依据预订规则筛选第一步识别出的 Glitch.

 

 

Glitch toggle count calculation: 计算 Glitch 的 toggle 次数,当一次 toggle 被识别成了 Glitch 则 Glitch toggle count 加 2,同时将 normal rise/fall 的 toggle count 减 1.  

 

分析、计算、报告 Glitch power: 流程非常简单,关键的一部是在 read_stimulus 的时候加 option -glitch. 

 

 

在 Joules 里可以用如下命令做进一步分析:

 


谈到 Glitch Power 通常一定会聊到的两个问题是:

Glitch Power 在设计中占多大比例:这是个无解的问题,这完全依赖于设计特性,通常 data path 越长 Glitch power 越大,但占多大比例取决于设计特征、工艺、工作场景等。

 

如何优化 Glitch Power, 在《Glitch, Glitch, Glitch》中罗列了一串论文跟若干种方式,其中看似最有效的是 logic balance —— 而 logic balance 要涉及到在哪个 corner, 在哪种应用场景去做 balance, 还要考虑在 logic balance 插入的 cell 所消耗的功耗是否小于所消除的 Glitch Power? 另一个问题是,logic balance 一定是需要仿真波形的,而在新工艺点,不论是 AOCV 还是 SOCV 都无法将 variation 部分精确地写到 SDF 中,那么后仿的精度偏差是无法避免的,那得出的波形是否可以真实的反应实际工作场景?等等这些因素,让 Glitch Power 的优化几乎成了玄学的一个分支,它属灵!也许最有效的手段还是要从架构算法设计入手,让懂电路的人写精致的代码!

 

C 记实现端的工具都有 report leaf cell 功耗计算的命令,该命令对于 debug power 有巨大帮助,工具会列出 leakage, internal power, switch power 每一项详细信息,包括 arc, condition, toggle rate, probability, cap, slew 等信息。

 

Genus, Voltus, command: report_instance -power -detail XX

Innovus, report_inst_power XXX

Joules, get_inst_power -show_details XX