论文题目

 SoC Firmware Debugging Tracer in Emulation Platform

研究目的

 在SoC设计中，尤其是多处理器的设计中，firmware debug是最大挑战之一。既有的SoC firmware debug方式存在诸多缺点：几大厂家技工的工具要么不兼容、难用、费用高，片上debug工具占用的gate count又太多、太占面积；亦或受限于电路仿真/软件调试器的断点功能，所需的系统设计调试无法使用，也无法捕捉确切的系统动态，从而导致无法复现bug，更别提修复bug了。

 这篇文章就是要解决这些痛点。

新方法

 本文提出了一种 在硬件仿真平台调试SoC固件的方法 ，该方法简便易实现、成本低、占用gate count少、能够精确监测firrmware运行动态。

 本文实现了一种firmware tracer（图1），能够报出当前在运行的function name，能够根据PUSH/POP操作预测出PC下一步的值。firmware tracer包括硬件部分和软件部分，通过PXP仿真平台的标准仿真模型接口（SCEMI）来实现软硬件之间的通信。

图1 Fireware Tracer architecture in PXP emulation

 Firmware Tracer的实现也不算难，流程如下：

   用Perl脚本从firmware数据中提取function name和function address，生成name到address的映射表，放在本地备用。

   硬件端，Core中把PC值和函数表的地址通过接口拉出来

   软件端，在sv中根据PC值及本地生成的function name/address映射表，判断firmware当前运行到哪个function了。

   只有在dump波形的时候才开启这个tracer，否则不开启，以此来降低tracer的开销。

讨论

 本文实现的firmware tracer挺不错，适用于在zebu、palladium等硬件仿真平台debug firmware。有一点没搞明白，软件解析出来function name后，又反馈给了硬件模块，不知道是要做什么。难道是要通过force来debug吗？

 之前有在软件平台debug CPU的经历，debug的时候就是打开verdi，把PC指针拖出来看PC跑哪儿了，对照工具生成的反汇编文件一个个查firemware到底怎么跑的、是不是跟预期的不一样。firmware比较短还好，对于firmware比较大的case，找bug真的如大海捞针一般。

 苦于难以debug，当时我们想到的办法是在直接在firmware里添加打印信息，把一段字符串塞到DCache，同时把字符串首地址及一些标志位写到sram固定位置，sv / uvm去实时后门监测这段sram这段地址，有啥新动态及时去DCache指定位置后门搬字符串，并通过sv / uvm打印到log里。采用这种方法，还能够根据标志位打印uvm_info、uvm_warning或uvm_fatal等。采用这种方法不需要修改RTL、没有添加任何gate count，对仿真时间影响微乎其微，也算是比较便捷了。

完