老驴发现『问题』地出现是有聚集效应的——某段时间突然间许多人都在关心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
驴说IC
