程序进入死循环，从看门狗退出，怎么寻找代码问题

1. task ReceiverBase::get_payload();
   
2. if (TRACE_ON) $display("[TRACE]%t %s:%m", $realtime, this.name);
   
3. this.pkt2cmp_payload.delete();
   
4. fork
   
5. begin: wd_timer_fork
   
6. fork: frameo_wd_timer
   
7. @(negedge this.rtr_io.cb.frameo_n[da]);
   
8. begin
   
9. repeat(1000) @(rtr_io.cb);
   
10. $display("\n%m\n[ERROR]%t Frame signal timed out！\n", $realtime);
    
11. $finish;
    
12. end
    
13. join_any: frameo_wd_timer
    
14. disable fork;
    
15. end: wd_timer_fork
    
16. join
    
17. forever begin
    
18. ...
    
19. ...
    
20. ...
    
21. ...

复制代码

根据仿真结果显示，找到了提示的router_test_top.t.\ReceiverBase::get_load .wd_timer_fork.frameo_wd_timer
正是代码中看门狗的那里 ，
说明程序进入了死循环，退出了，那下一步怎么去寻找代码问题那?（DUT没有问题！）

为什么就贴出这点代码?是觉得问题出在这点代码里么?现在TB报了error，那是满足了哪个条件才会报这个error?这个条件表达式里有哪些信号?这些信号又是由谁驱动的?一点点trace呗

理解你说的找代码问题的思想了。我贴出这段代码是因为，仿真报告中显示从这里退出仿真的。这里是一个看门狗程序，为了防止死循环，这种情况应该怎么找代码问题阿?

你怎么确定问题是”死循环", 不是例如数据丢失等其他问题的? 你真理解前面说的debug思路，就把那些问题的答案给出来呗，不然大家怎么往下trace

最近也在做这个LAB，碰到过同样的问题，将我的Debug过程简单说下，仅供参考：1.TRACE_ON=1,dump 波形，re_run
2.分析log，WDT触发条件为1000 cycle frameo_n无触发。查看波形，发现16个输出口中确实有reset后1000cycle都没用到的。分析输入波形，发现输入16个端口只用到了一个端口，再看log，发现，16个gen模块只调用其中一个。最后找到原因，16个gen模块共用一个mail_box,该mail_box例化是，忘记设置深度，无限容量，所以，当第一个gen产生Packets，由于无阻塞效果，直接在第一个gen模块，就产生了2000个Packet。修改，将mail_box深度设为1，re_run,simulation pass。
3.复盘：lab设置此WDT目的，是演示如何在checker中，加人预防超时机制。这个机制本身有其意义，其中引导的对mail_box深度的认识也是值得深究的。但严格来说，DUT本身，进行这个check，是要商榷的。输入输出端口的遍历，应该由function coverage进行check，超时机制的检查，应该引入输入的目标地址，该输出端口期望有输出时，才应该进行超时检查的，而整体无输出的检查，应该用线与逻辑，而非现在的遍历逻辑。而实际上，修改方式并没有消灭这种某个端口一直没输出的极端情况的，只是修改后，16个gen同时进行random，极大的降低了1000个cycle内，某个端口一直不触发的情况而已。
如上是当时的debug过程，希望能提供帮助。下面就是两个吐槽了：
1.提供尽可能多的信息，是求助，也是真正日常工作中的基本要求，神人，也无法由你提供的那一段代码加那几句log，得到root cause，事实上，虽然我上面写了那么多，我还是不能确认，你的bug就是这个的。
2.IC民工，不管设计还是验证，请勿使用“RTL没问题“，“DUT没问题”这类嘲讽描述，打脸很痛的。尚在ENV调试阶段，未经充分验证，你怎么确认的DUT没问题，就因为是S公司提供的LAB吗?
闲的无聊，第一个实质性回复，姑妄言之，姑妄听之。