胖友们大家好，太久不见，大家都还好吗？发量减少了多少？脂肪堆积了多少？核酸码绿着吗？股票红着吗？大部分驴友都深陷在口罩围起的囹圄之中，辗转徘徊无可奈何却又不得不逆来顺受，接受这时代落下的粒粒灰尘，背负着转圈或是前行。遥想三年之前，我们踏海攀山远渡重洋去欣赏历史遗留的美好跟自然赠予的壮阔，跟陌生人聚在一起喝酒聊天畅想无尽的未来。如今，核酸码禁锢了一切，“病毒”扰乱了一切的秩序，每个人都成了“饿汉”只能顾着眼前，似乎今天的码还绿着就已是最大的幸运跟恩赐，连回家探亲这么理所应当的事都成了大逆不道贪得无厌，得谢深刻严肃真诚的谢！
闲篇儿扯完，回到今天的主体，给大家推荐一个Joules 里十分好用的小功能—— Xreplay. Joules 诞生于2015 年诞生之初是奔着RTL 功耗去的，而驱动RTL 功耗分析变得重要的原因是AI / GPGPU / 5G 这类运算量巨大的设计的兴起。也是因为这类设计，使得动态功耗优化成了继timing, leakage, Congestion 之后需要从综合开始考虑并优化的另一个对象，而实现工具优化动态功耗需要有精确且场景典型的波形文件予以驱动，如何得到典型场景的波形需要架构师跟设计师根据设计真实应用场景确定，如何得到精确的波形则需要借助于EDA 工具。
设计团队会提供给实现团队RTL 跟RTL 对应的仿真波形，而RTL 仿真波形中只有 “state points” 的信息<所谓state point 包括时序逻辑输出、primary input, primary output>，从综合到PR 的每一步，设计的逻辑都会发生变化，包括时序逻辑跟组合逻辑，如果每优化一步就拿去做后仿得到一个精确的波形再接着优化显然不现实，所以这部分工作必须由工具自己去完成。在最早期，实现工具会用自己的算法去推导每一个逻辑节点的toggle 信息，而为了runtime 实现工具内部toggle rate 的推导算法都相对简单，精度也差强人意，不精确的toggle 信息一定会误导工具的优化方向。因此Joules 的Xreplay 功能应求而生。
Xreplay 的思路非常简单，Joules 从RTL 波形里得到state points 的toggle 信息，有了state points 的信息，Joules 调用仿真器Xcelium 对剩余没有标上的逻辑做仿真，因为state points 将整个设计切分成了一个个的逻辑锥，使得仿真“区域” 变得很小，所以使得Xreplay 的仿真比对整个网标做门级仿真的时间短得多，更关键的是Xreplay 是直接集成在Genus 跟Innovus 中的，只需要在Genus 跟Innovus 中配置参数就可以，数据的交互工具会独立完成，这样就避免了flow 的中断。
Xreplay 使用也非常简单，需要的输入文件有：
library 仿真模型：所有用到的std cell 的仿真模型，如果是pg netlist 用带pg 的仿真模型，否则用不带pg 的仿真模型。不需要memory 跟hard macro 的仿真模型，因为Xreplay 不需要跨memory 跟hard macro 仿真。
netlist：被仿真的netlist, Joules 支持对GTECH netlist 跟mapped Gate netlist.
RTL 仿真波形：Joules 需要从RTL 波形中抓取state point 的波形信息，对于没有反标上的primary input joules 会根据default toggle 或user 指定的toggle 去仿真，对于没标上的寄存器工具会根据寄存器的输入去仿其输出的toggle.
mapping file: RTL2gate 的mapping file, 如果是对综合的netlist 做Xreplay 直接用Genus 写出的mapping file 就可以，如果是对PR 之后的netlist 做Xreplay 则需要将综合跟PR 的mapping file 做个合并，在Joules 21.15 之后的版本直接用merge_mapping_file 这个命令去merge 就可以。Joules 可以自动做stim mapping 但因为stim_auto_mapping 无法得知phase inversion 的信息，所以仍需要mapping file。
SDC：Joules 需要从SDC 中得到clock 的信息。
SDF / SPEF：Xreplay 支持Zero-delay 跟delay 的仿真，如果要做delay 模式的仿真需要读入SDF 或SPEF。
Xreplay 输出的波形是VCD, 从Joules 21.16 开始也可以直接输出FSDB 波形。VCD 波形跟FSDB 波形会有一点区别，VCD 波形里会save zero delay glitch toggle 而FSDB 波形里不会save 这部分信息。读回VCD 计算功耗时可以加option: -filter_zero_delay 将Zero delay glitch toggle 过滤掉。
What is zero delay glitch ? What is purpose to have this glitch in this waveform?
LV >> Signal having two values at same time stamp. This is from race condition.
Did this glitch is added by Joules when doing replay? How can Joules do it? it do not have delay information and we did the zero_delay simulation when replay, why this zero delay will be invoked?LV>> No this is not added by Joules, Joules run simulation based on input stim and netlist, Joules follows the input waveform unless directed to do otherwise.
And these zero_delay information can only be recognized by Cadence tool, Synopsys tool will auto filter these glitch.
LV>> This is waveform and not tool specific. There are no zero-delay glitches in FSDB.
Why joules include this zero_delay glitch by default? which is difficult for customer to debug the difference between different power calculation tool?
LV>> Default is changed from 22.x. By default Joules will filter zero-delay glitches.
Xreplay 的流程非常简单，包括两部分，第一部分配置Xcelium 相关参数，第二部分执行Xreplay。
说一千道一万，工程上的事还是得用数据说话，Xreplay 的精度如何呢？这里有一组Xreplay 后的波形跟后仿真波形读到Joules 或第三方工具中功耗计算的数据对比。
| Xreplay | gate level stim | Power correlation | |
| case1 | 379.7mW | 379.4mW | -0.08% |
| case2 | 42.98mW | 42.8mW | -0.42% |
| case3 | 159.06mW | 159.35mW | 0.18% |
| case4 | 212.8mW | 214.04mW | 0.58% |
| case5 | 147.4mW | 149.9mW | 1.6% |
Joules Xrelay 做的事情其实很简单就是根据已有的RTL 波形通过仿真的手段得到Gate level 波形， 而有了Gate level 波形就可以去做：
更精确的功耗优化
在设计早期去分析Glitch power
在设计早期做PI 分析
老话：百看不如一试，强烈推荐有需要捣鼓功耗的胖友们一试，诸位如果在使用过程中遇到任何问题可以通过官方渠道去寻求AE 的帮忙。
