GitHub Actions、验证证据与项目复盘
返回 项目总览。
验证项目不仅要在本机跑通，还要让别人能用明确依赖和统一入口重复运行。本项目用 requirements、Makefile 和 GitHub Actions 串起这条路径。
自动回归链路
workflow 在 push 和 pull request 时运行：
- checkout 仓库；
- 在 Ubuntu runner 安装 Icarus Verilog；
- 配置 Python 3.11；
- 按
requirements.txt安装cocotb==1.9.2； - 进入
tests执行make。
Makefile 指定 Verilog 顶层、RTL 源文件、Python 测试模块和三个 FIFO 参数，再引入 Cocotb 提供的 simulator rules。
当前可以陈述的证据
| 项目 | 可确认内容 |
|---|---|
| 源码测试数 | 5 个 @cocotb.test() |
| 固定配置 | DATA_WIDTH 8、DEPTH 16、threshold 14 |
| 随机测试 | 单一 seed 20260527，循环 1000 周期后 drain |
| CI | 提交 388e6a7 对应 regression workflow 成功 |
| Simulator | CI 使用 Icarus Verilog |
证据边界
GitHub Actions 的成功状态说明该 workflow 当时以退出码 0 完成；历史详细日志已过保留期，不能据此补写精确运行时长或逐测试输出。项目也没有保存 coverage 报告，因此不能声称功能或代码覆盖率百分比。
CI 成功不等于验证完成
CI 解决的是可重复执行与变更保护。验证完成度仍取决于 test plan、checker 和 coverage：
- 测试是否覆盖所有需求与边界；
- scoreboard 是否独立且正确；
- 是否存在未观察的内部错误；
- 参数空间和随机空间是否充分；
- 检查器是否经过反例验证。
当前项目具备自检、随机化和自动回归的骨架，但没有 coverage-driven closure。
分层改进路线
第一阶段：增强可复现性
- 把 width/depth/threshold/seed 统一为 regression 参数。
- 保存 JUnit 测试结果和失败波形为 CI artifact。
- 运行多个固定 seed，并在日志中打印配置和 seed。
第二阶段：补验证计划
- 增加 occupancy 和 accepted-operation functional coverage。
- 增加运行中 reset、非 2 的幂深度、阈值极值。
- 加入 count 范围、empty/full 互斥和拒绝操作不改变状态的 assertions。
第三阶段：验证检查器
- 注入 overflow overwrite、underflow pointer move、同拍 count 错误。
- 确认每个 fault 被指定 scoreboard check 或 assertion 捕获。
- 对未覆盖点分类为刺激缺口、不可达场景或 coverage model 问题。
项目价值
这个项目展示了从 RTL 到自动化验证的完整最小闭环：
- 设计端有清楚的状态表示和边界处理；
- 验证端有 driver、monitor、独立 reference queue 和逐拍检查；
- test 层同时使用定向场景与随机序列；
- 工程端固定依赖并在远端 CI 自动执行。
它的价值不是“Python 比 SystemVerilog 更简单”，而是用更轻量的技术栈练习同样重要的验证原则：规格先行、观察独立、自动判分、随机可复现、结果可重复。
一分钟面试表达
我实现了一个参数化同步 FIFO，内部用 memory、循环读写指针和 occupancy counter，支持 empty、full、almost-full，以及 full 状态下无气泡的同拍读写。验证使用 Cocotb/Python：driver 驱动每拍请求，monitor 读取输出，deque 作为 golden model，逐拍检查读数据和 flags。五个测试覆盖复位、写满读空、溢出保护、阈值、并发读写和固定种子随机流，并通过 GitHub Actions 在 Icarus 上自动回归。当前缺口是尚无 coverage、SVA、多种子和参数矩阵。
自测
- workflow 成功能证明哪些事实，不能证明哪些事实？
- 为什么保存 seed 和失败波形比只显示 PASS/FAIL 更有价值？
- 下一步应先盲目增加随机周期，还是先建立 coverage model？
答案要点：证明流程成功完成但不证明覆盖充分；便于复现定位；先让 coverage 与验证计划对应，再用刺激关闭缺口。