请求握手
返回知识网络总入口 · 运行与激励
核心结论
start_item 等授权，finish_item 提交并等待 item 完成；driver 用 get_next_item/item_done 配对，响应返回是另一件事。
关键机制
- create → start_item → randomize → finish_item，授权后到提交间不要加入耗时等待。
- driver 可先进入 get_next_item 等请求，与授权/提交协同，不是等 finish_item 返回才取。
- driver 按约定处理后 item_done，使 finish_item 返回。
- get 是另一方式，在取出时完成 sequencer 握手，不能再配 item_done，此时引脚操作未必完成。
小例子或流程
// sequence body
req = packet::type_id::create("req");
start_item(req);
if (!req.randomize()) `uvm_fatal("RAND","randomization failed")
finish_item(req);
// driver运行task
seq_item_port.get_next_item(req);
drive_one(req);
seq_item_port.item_done();易错点
- finish_item 卡住查连接、driver、接口等待、漏 item_done。
- 提前完成后仍用 req，要额外管理所有权。
- item_done 不等于发起者取得 rsp。
关联知识
- transaction与字段操作：握手时机影响 item 安全复用与所有权。
- driver与virtual_interface：driver 的取请求/完成通知与发送端配对。
- report日志机制：节点日志帮助定位握手阻塞环节。
- sequence与sequencer：sequence 将场景细化为 item 发送。
- 仲裁与lock_grab：start_item 授权受仲裁和锁影响。
- sequence生命周期与宏：宏的 item 路径封装显式握手。
- response：item 完成和响应获取要分别追踪。