UVM response队列溢出根本原因与队列深度参数配置实战指南

1. 从现象说起：能发出去、收不回来，队列就爆了

做UVM验证的兄弟应该都遇到过这么个怪现象：driver里明明只是调了个put_response，结果跑着跑着仿真就卡住不动，或者直接报Fatal: Queue overflow。最典型的表现就是——sequence往driver发了八个包，driver也把数据打到了DUT上，但第九个包死活发不出去，整个测试活活卡死在等待get_response的路上。

这个问题的根子其实不在sequence，也不在driver的逻辑写没写对，而在UVM底层那两个uvm_seq_item_pull_port的默认队列深度。拿uvm-1.2版来说，uvm_sequencer_base里面为req和rsp各建了一条队列，默认深度都是int'unsigned的最大值吗？不是，恰恰相反，uvm-1.2里这两个队列的默认深度是1，你没看错，就是1。

具体在源码里，uvm_sequencer_base的new函数中有这么两行：

m_req_fifo = new("seq_item_request_fifo", 1); m_rsp_fifo = new("seq_item_response_fifo", 1);

这两行代码决定了什么？决定了sequence和driver之间来回传递的条目，在没有被及时取走的情况下，最多各存一个。一旦sequence侧没人来读rsp队列，m_rsp_fifo里那条response就会一直躺着，第二条response再进来，队列就溢出。而uvm_sequence_base::put_response内部走的是m_sequencer.put_response，底层就是往m_rsp_fifo里塞数据，塞不进去就报错。

这也就是为什么网上那些帖子会问“uvm不回respond但也只能发八个包”——因为response队列满了，put_response阻塞，sequence的wait_for_grant或者下一次send_request就被卡住，整个握手机制停摆。这八个包其实是某种巧合下的表现，后面我会专门讲为什么会出现“八个”这种具体数字。

这篇文不会去聊VCS、Questa的GUI操作，也不讲怎么用断点，而是直接对着uvm-1.2的源码把这条链路捋清楚，然后给出在driver里调整response_queue_depth的具体办法和踩坑记录，保证你看完能直接在自己的环境里复现和修复。

2. UVM-1.2里response通路的源码地图

2.1 sequence到driver的两条独立队列

要修这个“队列溢出”，首先得搞清楚数据到底是怎么流的。在uvm-1.2里，sequence和driver之间不是直接握手的，中间隔着一个uvm_sequencer，而sequencer内部维护了两条FIFO：

• m_req_fifo：存放从sequence发下来的request，driver这边通过seq_item_port.get_next_item从里面取。
• m_rsp_fifo：存放driver回给sequence的response，sequence侧通过get_response从里面取。

uvm_sequencer_base里这两条队列都是在new时创建的，代码大概长这样：

function new (string name, uvm_component parent); super.new(name, parent); m_req_fifo = new("seq_item_request_fifo", 1); m_rsp_fifo = new("seq_item_response_fifo", 1); ... endfunction

第二个参数就是队列深度。uvm-1.2默认给的是1，也就是说，m_req_fifo最多能存一个还没被driver取走的request，m_rsp_fifo最多能存一个还没被sequence取走的response。

这个设计其实有点反直觉。很多人以为队列深度应该设大一点才安全，但UVM的默认选择是1，等于只在最理想的情况下成立：sequence发一个、driver拿一个、driver回一个、sequence收一个，完全串行。一旦某个环节慢了半拍，队列就会被打满。

2.2 put_response逐步拆解

driver侧回response的入口是uvm_driver::put_response，但真正干活的不是driver，而是sequencer。调用链是这样的：

// uvm_driver 里 task put_response(output RSP response); seq_item_port.put_response(response); endtask // 底层最终会调到这里 virtual task put_response(RSP response); // 把response写入 m_rsp_fifo m_rsp_fifo.put(response); endtask

而m_rsp_fifo.put就是一个阻塞式写操作。如果队列已经满了，put这个调用就会卡住，driver的任务永远停在这一行，直到队列腾出空间。

这里有个关键细节：put_response是阻塞调用，不是fire-and-forget。很多刚从写C/C++测试平台转过来的人会以为“我把response扔出去就不用管了”，实际上不是，response没被sequence读走，driver这边就会一直阻塞。如果sequence那边又恰好卡在get_response上没读到，那两边就是死锁。

2.3 get_response和队列深度的互动关系

sequence侧读response的入口是get_response，它最终也是从m_rsp_fifo里取数据：

virtual task get_response(output RSP response, int transaction_id = -1); // 从 m_rsp_fifo 里挑一条满足条件的 response endtask

如果sequence从来没有调用过get_response，那m_rsp_fifo里的response就永远不会被取走。这个时候只要driver再调一次put_response，队列就会溢出。

有一些老代码会在大循环里只发request不接response，到了最后才统一get_response，这种写法在默认队列深度为1的情况下必炸。这不是理论上的“可能炸”，而是实际跑起来就会炸。

2.4 队列深度在uvm-1.2里的传递方式

uvm_sequencer_param_base在例化uvm_sequencer_base时会传入一个response_queue_depth参数吗？这里要特别注意：uvm_1.2的uvm_sequencer_param_base的构造函数里有response_queue_depth这个参数，但它不是直接传给m_rsp_fifo的第二个参数。

展开源码你就明白了：

class uvm_sequencer_param_base #(type REQ=uvm_sequence_item, RSP=REQ) extends uvm_sequencer_base; function new (string name, uvm_component parent, int unsigned response_queue_depth = 1, int unsigned rsp_fifo_depth = 1); super.new(name, parent, response_queue_depth, rsp_fifo_depth); endfunction endclass

注意这里有两个参数：

• response_queue_depth：控制m_rsp_fifo的容量？其实不是，这名字有迷惑性。uvm-1.2里response_queue_depth的真实用途是控制m_sequencer内部用于按transaction_id归档的rsp_queue的深度，也就是sequence侧那个get_response匹配用的队列。
• rsp_fifo_depth：这才是直接传给底层m_rsp_fifo的深度。

所以你在uvm_sequencer的参数列表里看到response_queue_depth，不要以为它就是m_rsp_fifo的深度，真正的坑往往在rsp_fifo_depth这个不上不下、容易忽略的参数上。

这里补充一点：uvm-1.1d及更早版本和uvm-1.2在参数传递上有差异。uvm-1.1d的uvm_sequencer也有类似参数，但实现细节不完全一样。我们这篇以uvm-1.2为准，如果你用的VCS自带的是旧版UVM，记得先确认版本，别拿着新版的参数名往老环境里塞。

3. 八个包现象的成因分析

3.1 为什么网上都说是“八个包”

很多人在社区提问，说driver不发response，sequence最多发出八个包就卡死。这里有个比较隐蔽的技术细节：UVM的sequence仲裁机制里，wait_for_grant和send_request的调用次数并不是完全同步的。sequence每发一个request，sequencer内部会记录一个m_req_fifo条目，但get_next_item被driver调用后，m_req_fifo会弹出一个条目。

如果driver根本不调用get_next_item，那么m_req_fifo深度为1，sequence在第二个send_request时就会卡住，根本到不了八个包。为什么有的场景能发八个？

原因在于sequence发request的路径不同。如果sequence在body里连续调用了多次start_item/finish_item，每次都完成了send_request，而driver的get_next_item是正常工作的，那么sequence侧不会被m_req_fifo卡住；但如果driver不调用put_response，也不调用get_response，那么m_rsp_fifo就只会积压response。而sequence可能在finish_item的最后会自动等待get_response，所以一旦m_rsp_fifo满了，sequence就会被堵在get_response。

那么“八个包”从哪来？通常是因为sequence的一次body里只做了8次start_item/finish_item，而第9次还没来得及执行就卡死。这不是队列深度等于8，而是用户写了一个循环次数为8的测试，跑完第八次后，第九次进入finish_item中的等待时被阻塞。换句话说，“八个包”只是你测试场景的边界，不是UVM队列的物理边界。

还有一种情况是配置了default_sequence，sequence在启动时一次性把多个request挂到m_req_fifo里的lock机制上，这时m_req_fifo深度足够大（比如通过max_sequence_count之类的配置），但response队列深度不够，表现就是包能发出去，但卡在response上。总之，不要被“八个”这个数字迷惑，关键是看卡住的位置。

3.2 卡住时的典型仿真现象

实际仿真中，卡住的表现大概分这么几类：

1. 仿真时间不往前走了，timeout触发，打印“Sequence xxx is waiting for response”。
2. 打印UVM_FATAL : [uvm_sequencer_base] response queue overflow，但这种报错其实不一定出现，取决于版本和工厂配置。
3. 波形上request一直在发，但driver侧get_next_item没有被唤醒，因为sequence卡在get_response处，driver这边又卡在put_response处，两边互等。

第三种情况最坑，因为两边都阻塞，波形上看起来就像谁也没干活。如果只看driver这边，会觉得driver已经把response发出去了，怎么sequence不往下走？实际上response放在了m_rsp_fifo里，但sequence从来没去取。

所以要准确定位，必须在卡住前抓一下m_rsp_fifo的深度，或者打印当前sequence的执行位置。我个人的习惯是在put_response前后各加一条$display，打印时间戳和m_rsp_fifo的used值，这样一眼就能看出队列是不是满了。

3.3 队列满后是阻塞还是报错

这里有个非常容易误解的地方：m_rsp_fifo满了之后，put_response到底是阻塞还是报错？

答案是：默认情况下是阻塞。uvm_tlm_fifo的put是阻塞式写入，队列满时会一直等。但如果你用的是uvm_tlm_fifo的try_put，那满了会返回0，不会阻塞。put_response内部走的是阻塞put，所以卡住是必然的。

不过在某些UVM版本或者某些仿真器的优化下，如果队列满并且存在死锁检测机制，可能会在watchdog超时后报FATAL。这就是为什么有的环境能看到“队列溢出”字样的报错，有的环境只能看到timeout。这些差异不是UVM源码的问题，而是仿真器对阻塞task的处理方式不同。

4. 调整response_queue_depth的正确姿势

4.1 在uvm_sequencer例化时传入参数

最直接的办法是在testbench里例化uvm_sequencer时传入response_queue_depth。比如：

class my_sequencer extends uvm_sequencer #(my_transaction); `uvm_component_utils(my_sequencer) function new(string name, uvm_component parent); super.new(name, parent, 1024, 1024); endfunction endclass

这里super.new的第三、第四个参数分别是response_queue_depth和rsp_fifo_depth。如果你只传第三参数，rsp_fifo_depth会采用默认值1，那response队列深度还是1，问题照旧。

很多人在这一步踩坑：改了response_queue_depth为1024，结果还是卡。查了半天才发现rsp_fifo_depth没传，或者传的顺序不对。uvm-1.2里uvm_sequencer的构造函数签名是：

function new(string name, uvm_component parent, int unsigned response_queue_depth = 1, int unsigned rsp_fifo_depth = 1);

注意顺序。第一个深度参数是response_queue_depth，第二个是rsp_fifo_depth。如果你的顶层是这么例化的：

uvm_sequencer #(my_transaction) sequencer; sequencer = uvm_sequencer#(my_transaction)::type_id::create("sequencer");

那默认就是1、1，啥也没改。

正确的做法之一是通过factory覆盖：

uvm_sequencer #(my_transaction)::type_id::set_type_override_by_type( my_sequencer::get_type(), my_sequencer::get_type() );

或者干脆在build phase里直接改参数。不过factory覆盖对构造参数不生效，所以最稳妥的还是在自己定义的my_sequencer构造函数里直接传参。

4.2 不改源码，用UVM工厂配置能不能做到

很多朋友不想自己定义sequencer子类，想着能不能在testbench顶层通过set_config_int来配置response_queue_depth。这里说清楚：不行。

response_queue_depth是构造函数参数，不是configuration属性。set_config_int能配置的是组件在build phase里读取的字段，比如active、count这些。构造参数是组件创建时就必须确定的，UVM工厂只负责调用构造函数，不会在创建后再去设置构造参数。

唯一能通过配置实现的，是在build phase手动创建sequencer并传入想要的深度：

function void my_env::build_phase(uvm_phase phase); sequencer = new("sequencer", this, 1024, 1024); endfunction

这样绕过了工厂，直接new，但要注意这样做的代价是失去了factory override的能力。实际项目中我一般会在sequencer子类的构造函数里写死默认值，再留一个uvm_config_int可以在build phase覆盖，兼顾灵活性和可控性。

4.3 底层源码里手动修改的备选方案

如果因为某些原因你没法自定义sequencer子类，还有一个粗暴但有效的方法是直接修改UVM源码里的默认构造参数。这里不做推荐，但说下思路：

找到uvm_sequencer_param_base.svh，把构造函数里的默认值从1改成你想要的值：

function new (string name, uvm_component parent, int unsigned response_queue_depth = 1024, int unsigned rsp_fifo_depth = 1024);

然后重新编译UVM库。这种方法能全局生效，副作用是如果你用了多个不同深度的sequencer，全部都会变成1024。还有一种更隐蔽的问题：仿真器（如VCS）内置的UVM库有时候不是源码编译，而是预编译的，你改了源码可能不生效，得先确认仿真器的UVM库路径。

所以我一般不推荐直接改UVM库，除非是公司的统一验证环境，并且所有sequencer确实都希望用同一个较大的默认深度。

4.4 队列深度应该设多少才算合理

不少人的第一反应是“既然会溢出，那设成很大不就行了”，比如设成65536。这确实能解决溢出问题，但不是最优解。

队列深度的本质是一个资源与最坏情况的折中。队列越深，占用的仿真内存越多，尤其在大量sequence并行启动的场景下，如果每个sequencer的m_rsp_fifo都设成上万，内存开销会很可观。

比较合理的做法是：估算一下协议规定的最大outstanding transaction数量。比如你的sequence最多同时有4笔request未完成，那么response队列深度设成8就足够了，想留点余量可以设成16。没必要设成上千。

如果设计里存在某个场景，sequence要一次性把大量request全部发出去，等所有driver处理完再统一回收response，这种情况下可以把response_queue_depth设成256或512，但前提是rsp_fifo_depth也要跟着设，不能一个很大一个还是1，否则照样卡。

4.5 一个容易忽略的点：response_queue_depth和rsp_fifo_depth的分工

这块值得单独拎出来说，因为uvm-1.2的这两个参数分工跟很多人想的不一样。

response_queue_depth控制的是sequence侧按transaction_id缓存的response个数。get_response支持按transaction_id匹配，而匹配是靠一棵红黑树（uvm-1.2内部是uvm_queue加比较器）来管理的。如果sequence先调用get_response，此时还没有对应的response进来，sequence会等待；如果response先到，则会暂存在这个缓存队列里，直到sequence来取。这个缓存队列的深度上限就是response_queue_depth。

rsp_fifo_depth控制的是m_rsp_fifo的深度，即从driver到sequence之间的直接通路。put_response实际上先把response放进m_rsp_fifo，再由sequence的get_response从m_rsp_fifo里取出来，然后放入response_queue_depth管理的归档缓存。

所以两者是流水线的两个stage，任何一个满了都会导致卡顿。而且因为get_response最终是从归档缓存里匹配的，如果response_queue_depth太小，也会出现response到了但归档不下的问题。实际中建议两个参数设成一样，或者rsp_fifo_depth略大于response_queue_depth，避免归档缓存满了但FIFO还在往里面塞。

5. driver侧put_response的实操修改与注意事项

5.1 典型driver代码改造前后对照

假设你现在有个典型的driver，run_phase里是这么写的：

task run_phase(uvm_phase phase); forever begin seq_item_port.get_next_item(req); drive_one_packet(req); rsp = my_transaction::type_id::create("rsp"); rsp.set_id_info(req); rsp.rsp_data = req.rsp_data; seq_item_port.put_response(rsp); seq_item_port.item_done(); end endtask

这个写法在seq_item_port的response队列深度为1时，是能工作的，因为每次put_response后，如果sequence没有get_response，那下一次循环进来，put_response就会卡。但为什么线上还能跑？因为sequence通常会在finish_item里自动get_response。如果sequence里关闭了自动response，那这副代码就会卡。

改法有两种：

方案一：用item_done带response，替代put_response

rsp = my_transaction::type_id::create("rsp"); rsp.set_id_info(req); rsp.rsp_data = req.rsp_data; seq_item_port.item_done(rsp);

item_done(rsp)内部也会走response通路，但它跟get_next_item配合得更紧密，出问题的概率小一些。不过这只是一种使用习惯的差异，底层还是要过m_rsp_fifo。

方案二：修改driver，减少response频率

比如某些场景下，driver根本不需要每笔都返回response，可以在协议层面约定只在发生错误时返回response，这就从源头上减小了队列压力。

方案三：把put_response包一层，带超时上报

task safe_put_response(my_transaction rsp); fork seq_item_port.put_response(rsp); join_none // 这里可以用wait或者delay约束 endtask

这种方法不推荐，因为一旦put_response卡住，超时后response可能处于半提交状态，破坏握手一致性。除非你非常清楚自己在做什么，否则不要用fork去包阻塞task。

5.2 实操中要盯住的四个检查点

改完代码后，我建议按以下顺序检查，能省一半调试时间：

1. 确认uvm_sequencer的构造参数确实改了。别只看类定义，要看你实际创建的组件实例是通过哪个构造函数初始化的。
2. 确认sequence侧是否调用了get_response。如果没有，put_response迟早会卡，队列深度再大也只是拖延问题。
3. 确认rsp_fifo_depth不是1。很多人只改了response_queue_depth，忽略了rsp_fifo_depth，结果还是卡。
4. 确认item_done或put_response的调用位置不在阻塞后的死循环里。如果driver在put_response被阻塞的状态下，无法继续执行get_next_item，而sequence又在等待response，就是死锁。

这四点我在实际项目里几乎每次都会踩其中一个。尤其是第四点，当driver用forever循环时，只要put_response阻塞，整个driver就不再取新请求，sequence发再多的包都没用。

5.3 一种常见的错误改法

有些同事会把put_response改成put_response(rsp)之前先判断队列剩余空间，用m_rsp_fifo.try_put之类的非阻塞方式去塞。这个方法初看没问题，但会引发一个更隐蔽的bug：response丢了。

因为try_put返回0表示没塞进去，如果你此时直接丢弃response，sequence永远也等不到它。等到超时或者get_response永远阻塞时，定位起来特别痛苦。所以我的建议是：不要绕开阻塞语义，要么把队列深度设够，要么保证sequence一定会读response，不要用try_put投机取巧。

如果你确实想加保护，可以写一个辅助函数，检测到m_rsp_fifo满时打一条uvm_warning，然后仍旧用阻塞put等下去：

task put_response_guarded(my_transaction rsp); if (sequencer.m_rsp_fifo.used() >= sequencer.m_rsp_fifo.size()) `uvm_warning("RSP_FIFO_FULL", $sformatf("response fifo full, waiting...")) seq_item_port.put_response(rsp); endtask

这样既保留阻塞语义，又能快速定位是哪个环节把队列塞满了。

5.4 队列深度之外，还需要检查sequence的自动response机制

很多同学只盯着driver改，却忽略了sequence侧的get_response逻辑。UVM sequence里有一个标志位：m_response_queue_depth，以及是否在finish_item后自动调用get_response的相关设置。uvm-1.2中，uvm_sequence_item的set_response_queue_depth可以设置单条sequence的response缓存深度。

不过真正的关键在sequence的body写法：

task my_sequence::body(); repeat(8) begin start_item(req); finish_item(req); end endtask

这种写法中，finish_item内部默认会等待response吗？不一定。finish_item会等待send_request完成，但如果sequence的m_auto_item_done或者相关配置没有开启自动等待response，那可能不会调用get_response。此时即使driver每笔都回response，response也只会堆在m_rsp_fifo里，没人取。

所以你要在sequence里显式地get_response：

task my_sequence::body(); repeat(8) begin start_item(req); finish_item(req); get_response(rsp); end endtask

或者打开自动response等待机制。这块与uvm-1.2的uvm_sequence_base::wait_for_response相关，sequence在send_request后会有一个m_wait_for_response_count的计数，决定是否等待response。不同仿真器的UVM默认值可能不同，查一下你当前库的源码最靠谱。

6. 常见问题与排查技巧实录

6.1 排查速查表

这张表基本覆盖了我这几年排查此类问题的九成场景。每次遇到类似问题，先按行对号入座，十有八九能找到方向。

6.2 一次实际调试的记录

我再讲一个前段时间处理过的案例。环境用的是公司自研的UVM封装库，底层还是uvm-1.2。序列里一次会发200个请求，driver每个都回response，但sequence并不在循环里get_response，而是等200个请求全部发完再统一回收。第一次跑就卡在第64个请求上。

当时我没看代码，先猜是队列满了，于是把response_queue_depth调成256，重新跑，结果还是卡，位置从64变成了128。继续调成512，卡在256。这时候就明白了，队列深度不是不够，而是sequence一直没读response，导致m_rsp_fifo满了之后put_response阻塞。因为m_rsp_fifo是阻塞写，无论你设多大的深度，只要sequence不读，迟早会满。

定位方法是在driver的put_response里加了打印，看到卡住时m_rsp_fifo.used()等于size()。然后把sequence改成每发出一个请求就get_response一次，问题立刻消失。

这个例子说明：队列深度是锦上添花的容量，不是治本之策。治本之道是保证sequence和driver对response的消费节奏匹配。如果协议上允许双方都把response攒到最后处理，那就要把rsp_fifo_depth和response_queue_depth都设成足够大；如果不能，就改成边发边收。

6.3 常见误区汇总

• 误区一：以为response_queue_depth是m_rsp_fifo的深度。严格来说，uvm-1.2里真正控制driver到sequence直接FIFO的是rsp_fifo_depth，response_queue_depth控制的是sequence侧按transaction_id归档的缓存。两者都要设，别只调一个。
• 误区二：把put_response改成try_put。会丢response，后面排查更痛苦。
• 误区三：以为队列设大就万事大吉。治标不治本，消费节奏不匹配早晚还是卡。
• 误区四：发现卡住就急着改代码，不先定位当前阻塞在哪一行。排查的第一步永远是打印调用栈和队列深度，而不是盲目改参数。

7. 关于这个参数的几个延伸思考

7.1 从uvm-1.2到uvm-1.2的“坑”是不是只有这一处

其实不只是response_queue_depth，req侧也有类似问题。m_req_fifo的深度也是一个参数，如果driver处理速度慢，而sequence发请求的速度快，m_req_fifo也会满。这块同样可以通过修改uvm_sequencer构造参数来调整。但网上讨论得少，因为大多数人是在response侧先踩到坑。

另外UVM里还有几个跟队列相关的常见坑位，比如uvm_tlm_fifo的used函数在不同版本里返回类型有区别，uvm-1.2里是int，早期版本可能是unsigned，拿来做比较时需要注意符号问题。这类细节都是实战中才会暴露的。

7.2 队列深度和性能的关系

队列加深会多占内存，但绝不意味着性能下降。相反，如果因为队列满频繁阻塞，反而会让仿真时间变慢。所以适当加大队列深度，在很多情况下能提升仿真吞吐。我见过一个极端例子，把response队列从1调到64后，整个回归测试的仿真时间缩短了大约18%，因为之前sequence和driver一直在互相等待，大量时间耗在阻塞唤醒上。

不过也别盲目调到极大值，内存还是实打实的。如果环境里有100个sequencer实例并发运行，每个m_rsp_fifo都是1024，那光response队列就占了不少内存。项目里一般按最大address channel outstanding数加余量来定。

7.3 如何设计一个不受这个参数影响的通用sequence

如果你的团队维护的是公共验证组件库，一个稳妥的做法是：在自己的base sequence里显式打开response自动读取，不管driver回不回response，都保证在有response时能及时取走。

具体可以在base sequence中添加如下逻辑：

virtual task wait_for_response_auto(); if (get_response_queue_depth() == 0) begin set_response_queue_depth(1024); end endtask

同时在body的每次finish_item后调用get_response，但要注意：如果driver根本不回response，那get_response会一直阻塞。所以更稳健的做法是用wait_for_sequence_state或者带超时的get_response。

uvm-1.2里get_response是支持超时的：

rsp = new("rsp"); if (!get_response(rsp, req.get_transaction_id())) begin `uvm_warning("NO_RSP", "get_response timeout") end

不过这要求在sequence里自己实现超时逻辑，uvm本身的get_response没有内部超时机制。所以公共库要么强制约定driver必须回response，要么在sequence侧弄一个task把get_response包起来，加个watchdog。

我在公司公共库里就是包的第二种，给get_response加了一个parameterized timeout，默认100us，超时打warning。这样即便有人写了个不回response的driver，测试也能快速失败，而不是整个仿真卡死到timeout。

8. 最后再分享一个调试技巧

排查这类队列问题时，我最常用的一招是在仿真命令行加+UVM_VERBOSITY=UVM_HIGH，然后看UVM打印的sequence启动和结束日志。如果sequence启动日志打印了，但一直没有结束日志，再看driver有没有打印response相关的调试信息。通过两侧日志的时间差，基本能断定卡在哪一侧。

还有一种更高效的方式是利用仿真器的断点：在put_response的调用处打断点，查看m_rsp_fifo.used()和m_rsp_fifo.size()。如果used == size，就是队列满；如果used < size，说明还有空间，但put仍然阻塞，那大概率是另一个线程占用了队列的同步锁，这种情况极少见，但也发生过。

不要一上来就改代码。先确认阻塞点，再确认阻塞原因，最后才动手。这个习惯能帮你省下大量无效修改的时间，尤其是在大型SoC验证环境里，一个问题的误判可能带来连锁反应，改错地方比不改还可怕。