| name | verify |
| description | Verify functional correctness of the Ball named $ARGUMENTS. Use this skill when users ask to verify/test a Ball, check whether a Ball works correctly, or validate a newly created Ball. |
Important: build, simulation, and test operations must be invoked via MCP tools. Do not call bbdev CLI or nix develop directly.
Phase 1 - Completeness Check
Use /check logic to validate registration consistency, then ensure all required artifacts exist and fill missing pieces:
- Ball implementation:
arch/src/main/scala/framework/balldomain/prototype/<name>/
- Registration entry in
arch/src/main/scala/framework/balldomain/configs/default.json
- ISA macro file in
bb-tests/workloads/lib/bbhw/isa/
- CTest file in
bb-tests/workloads/src/CTest/toy/
Phase 2 - Build and Simulate
- Run MCP tool
bbdev_workload_build to build all CTests
- Run MCP tool
bbdev_verilator_run for this Ball's CTest
- binary naming format:
ctest_<name>_test_singlecore-baremetal
- set
batch=true
- If build/simulation fails, switch to
/debug flow
Phase 3 - PMC Performance Analysis
After simulation passes, analyze PMC traces from bdb.log:
- Locate log directory (
ls -t arch/log/ | head -5)
- Search
[PMCTRACE] BALL entries in bdb.log and extract elapsed cycles for the target Ball
- Summarize:
- average elapsed cycles per task
- max/min elapsed cycles
- total invocation count
Phase 4 - Waveform Analysis (when simulation fails)
If simulation fails, use waveform-mcp for precise timing analysis in addition to logs. See /waveform.
Key signal checklist:
cmdReq.valid && cmdReq.ready (command handshake)
- SRAM
req.valid/ready and resp.valid (read/write timing)
- FSM state register (state transitions)
cmdResp.valid && cmdResp.fire (completion handshake)
Failure Handling
If simulation result is FAILED, run /debug for systematic troubleshooting.