论文题目
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,对仿真时间影响微乎其微,也算是比较便捷了。
完