FPGA 流式实战 · 04 吞吐测试与瓶颈解释

先统一测量分母和有效字节

吞吐统计只计算实际接受的拍，不能把 VALID 为一的等待周期也算作传输。有效载荷按 TKEEP 的有效位数累计，本工程每八拍共有三十字节，因此三十二位总线的原始位宽并不是实际有效字节率。稳态窗口固定为读域周期二百五十六到二千零四十八之前，共一千七百九十二个周期，便于他人逐项复核。

复现软件测量结果

benchmark 脚本运行同一套逐拍测试，提取原始窗口计数，再用读时钟周期计算吞吐。输出保存工具版本、源文件摘要和原始参数，避免把手工填写的性能表当成实测。下面结果来自当前 RTL 软件仿真，虽然和解析上限一致，也不代表硬件已经达到这些速率；物理时序、存储映射和实际采集仍需独立验证。

在解压后的 fpga-stream 目录执行；软件测试需要 Python 3、iverilog 和 vvp。

python3 benchmark.py --output runs/metrics.json
# 利用率 = accepted / window_cycles
# MB/s = valid_bytes * 1000 / (window_cycles * read_period_ns)
# 输出包含源文件 SHA-256、Icarus 版本与六组原始计数

区分长期瓶颈与启动排空开销

写时钟快于读时钟时，FIFO 填满后会限制写端，但只要读侧有数据就仍能每周期接受一拍；读时钟更快时，窗口利用率下降可能只是源速率不足。长暂停增加了端到端耗时，却不一定影响暂停结束后的稳态窗口。增加 FIFO 深度可以缓冲更多突发，不能改变接收端长期只能接受多少数据的事实。

1. 固定输入

   预期与判定：相同 4096 拍与 TKEEP/TLAST 模式。

2. 固定窗口

   预期与判定：保留 1792 周期分母，包含空闲和反压。

3. 改变单个条件

   预期与判定：比较时钟比或接收模式，不同时更换多个变量。

4. 解释差异

   预期与判定：同时保存稳态 MB/s 与端到端 elapsed_ns，说明统计范围。

在解压后的 fpga-stream 目录执行；软件测试需要 Python 3、iverilog 和 vvp。

# 100 MHz 写、50 MHz 读的解析对照：
# 原始位宽容量 = 50e6 * 4 = 200 MB/s
# 每拍平均有效字节 = 30 / 8 = 3.75
# 无反压载荷上限 = 50e6 * 3.75 = 187.5 MB/s
# 接收 5/8 周期 = 187.5 * 5/8 = 117.1875 MB/s
# 与 metrics.json 中对应软件窗口计数交叉核对

典型故障：只数活跃周期导致虚高

如果先删掉 READY 为零或 VALID 为零的样本，再用剩余周期计算带宽，就把真正的等待成本从分母里移除了。另一种误差是把每次传输都当作四个有效字节，忽略尾拍掩码。这两种统计错误可能让明显受限的设计看起来达到原始总线带宽，必须回到完整周期窗口与逐拍字节限定重新计算。

完成检查

• 性能记录包含原始计数和代码摘要。
• 按握手和 TKEEP 计算有效载荷。
• 稳态与端到端口径分开解释。

延伸阅读与来源

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

• Arm IHI0051A · AXI4-Stream Protocol

  握手、字节限定与包尾；本文工程与测试为原创实现。

• AMD UG903 · CDC Constraints

  跨域最大延时与总线偏斜约束。

• AMD UG474 · Distributed RAM Timing

  分布式 RAM 的写入与异步读取时序特性。

• AMD UG908 · Programming and Debugging

  ILA、探针文件与采集流程。

继续阅读