本文章记录工作中UVM环境挂死问题和一些自己的定位方法。前言UVM是当前主流的数字芯片验证方法学因其高度的封装性和可继承性广受青睐但其繁杂的运行机制也会导致实际使用时碰到形形色色对的问题本文章重点记录笔者在实际工作遇到的一些关于环境挂死的问题仅个人观点欢迎大家指正。1通过UVM_OBJECTION_TRACE来定位task_phase的挂死run_phase、main_phase等task_phase是相互独立的每个phase都有objection控制当前phase的开启和关闭若phase中的多个component提起raise了objection但未及时全部撤销drop则会导致phase挂死。此类问题可以通过在仿真阶段(simulation)添加指令UVM_OBJECTION_TRACE解决此处可参考白皮书部分内容Page372~373log中会显示树状结构的component中各自维护的objection个数(count)和当前phase所有存在的objection个数(total)只有当total0时代表当前phase中的所有objection均被撤销掉。因此可以通过查询log检查挂死点处有哪些task_phase的objection_total不为0再进一步定位是哪个component的objection尚未撤离及时drop即可解决挂死。2通过verdi的交互式界面来设置断点定位挂死verdi支持Interactive Debug Mode(交互式dbg模式)具体可以参考B站席老师的科普视频https://www.bilibili.com/video/BV16t421w7T8?spm_id_from333.788.videopod.sectionsvd_sourceabf22a82319ff1dc9c2d09b77221c889总结一下Step1需要在cmp_option中加入-debug_accessallreverseStep2使用verdi -ssf *.fsdb 打开verdiStep3Window-Interactive Debug Mode开启交互式debug模式Step4勾选Tools-Preferences-Interactive Debug-Reverse DebugStep5插入断点我设置过时间就是仿真挂死的时间点可以再往后设置一点观察到底是哪里挂死Step6运行即Debug界面中绿色右向箭头Step7观察Console窗口中最终代码停止位置分析挂死原因笔者当时是运行到断点之后发现是run_phase在运行进一步检查run_phase的objection定位到是driver的run_phase中的无限循环外包了一层objection导致挂死。当然他实际停止位置并不一定就是你出错的代码行只是告诉你当前代码在的phase挂死了要注意这一点