Palladium 事务级实战 · 06 故障定位与异步队列演进

按事务生命周期定位第一处异常

先回答请求是否接受，再回答 FIFO 是否完成写读，最后确认响应是否被消费。观察 req_valid/ready、id/len、state、pushed/popped/captured 和 rsp_valid/ready 能把故障限定到明确阶段。设备波形只需围绕首个失败编号采集；先用本地短序列复现，再扩大范围，避免一次记录整个长回归却没有可关联的事务信息。

先运行可重复的故障注入

测试脚本将故障宏导致的失败视为预期检出，但只接受指定诊断；普通编译失败不会冒充故障测试通过。COURSE_BUG 翻转读出位，BAD_TAG 修改返回编号，DROP_RESPONSE 隐藏响应，BAD_REQUEST 发送零长度。它们是构造的教学故障，不是来自客户设备的真实事故记录；修复后的测试仍要重新确认全部正向场景。

1. 先跑无故障完整测试

   预期与判定：正确输出和所有边界场景通过

2. 单独启用 COURSE_BUG

   预期与判定：出现 TBA_DATA，定位第一处字节差异

3. 分别启用 BAD_TAG / DROP_RESPONSE

   预期与判定：分别检出 TBA_TAG 与 status=3

4. 关闭故障并全量重跑

   预期与判定：13 项通过，结果文件与源码摘要一致

本地独立复现实验；在工程根目录执行。

mkdir -p /tmp/tba-debug-run
iverilog -g2012 -DCOURSE_BUG -s hw_top -s tb_host \
  -o /tmp/tba-debug-run/sim rtl/*.sv tb/tb_host.sv
(cd /tmp/tba-debug-run && vvp ./sim +N=64 +BATCH=16)
# 预期非零退出，并出现 TBA_DATA
# 完整测试使用 python3 test.py

SFIFO / GFIFO 不是给阻塞 task 换个名字

官方异步通路通过 SFIFO 从软件送往硬件，通过 GFIFO 返回软件；相关函数采用输入参数、void 返回等约束，不能把本例带 output 的 exchange 原样改名。异步提交后 host 可以继续工作，但必须单独接收完成消息，并通过编号关联结果。信用限制、队列容量、超时、复位 epoch 与取消语义都需要重新设计，本实验包尚未实现或验证这条异步路径。

异步演进的协议设计草图，不是可编译的 Cadence API 示例。

request  = {epoch, id, len, payload}
complete = {epoch, id, status, len, result}
submit only if credits > 0
on accepted submit: credits -= 1
on matched completion: retire id; credits += 1
on reset: stop submit; drain or abort; advance epoch

故障练习：复位后的旧响应误配

单在途阻塞工程通过只在空闲边界复位回避了旧响应重入问题。增加异步队列后，即使硬件状态已复位，链路中仍可能保留旧完成消息；若编号从零重新开始，软件可能错误地接受旧数据。因此异步版本需要 epoch、明确的停止提交和排空策略，并验证重置发生在请求接受、执行及返回各阶段时的行为。

完成检查

• 能从首个失败编号关联请求、执行和响应。
• 四种故障诊断均有可重复检出证据。
• 明确异步队列仅为演进设计，不属于本工程已验证能力。

延伸阅读与来源

本文为黄河电子原创教学说明。产品命令与支持范围请以实际安装版本的官方文档为准。

• Cadence Palladium 官方入口；WXE 24.05 TBA Tutorial

  TBA Tutorial 第 40–42 页；OfflineDebugging 与 Probing 的设备采集章节以安装版本为准。页码指用户提供的本地安装文档印刷页；公开链接为产品入口，并非受限手册下载。

继续阅读