Prerequisites
rtl/**/*.sv files must exist.
bfm/perf_baseline.json must exist.
If prerequisites are missing: WARNING — recommend running /rtl-agent-team:rtl-p5s-func-verify and /rtl-agent-team:bfm-develop first. Orchestrator adapts scope with available artifacts.
Apply steps 1-5 to every requested module — do not stop after the first.
Do not perform simulation work directly — the orchestrator manages performance simulation, BFM baseline comparison, throughput/latency/stall measurement, and deviation flagging.
Output
sim/{module}/{module}_perf.json — raw measured vs expected metric values with per-metric PASS/FAIL.
reviews/phase-5-verify/{module}-performance-report.md — throughput and latency table vs BFM baseline, deviation analysis, PASS/FAIL verdict.
1---2name: rtl-p5s-perf-verify3description: P5 performance verification: RTL throughput/latency/stalls vs BFM baseline. Triggers 'measure throughput', 'performance regression', 'latency vs BFM'.4---56<Purpose>7Measure RTL performance (throughput, latency, stall cycles) against BFM-predicted baselines and flag deviations exceeding 10%. Outputs: `sim/{module}/{module}_perf.json` (raw measured vs expected metrics) and `reviews/phase-5-verify/{module}-performance-report.md` (PASS/FAIL verdict with deviation analysis).8</Purpose>910<Use_When>11- RTL passes functional verification and performance validation is the next step.12- A BFM performance baseline exists in `bfm/perf_baseline.json`.13- A performance regression needs quantification after an RTL change.14</Use_When>1516<Do_Not_Use_When>17- BFM does not exist yet — run `bfm-develop` first.18- Functional correctness is not yet established — run `rtl-p5s-func-verify` first.19- Synthesis timing analysis (setup/hold slack) is needed — use `rtl-synth-check` instead.20</Do_Not_Use_When>2122<Why_This_Exists>23RTL that is functionally correct may still fail performance targets due to unexpected stalls, backpressure, or pipeline bubbles invisible to functional tests. BFM provides the performance baseline; RTL must match it. Separating performance measurement from functional verification keeps each pass focused and regressions attributable.24</Why_This_Exists>2526## Prerequisites2728- `rtl/**/*.sv` files must exist.29- `bfm/perf_baseline.json` must exist.3031If prerequisites are missing: WARNING — recommend running `/rtl-agent-team:rtl-p5s-func-verify` and `/rtl-agent-team:bfm-develop` first. Orchestrator adapts scope with available artifacts.3233<Assets>34| Path | Role |35|------|------|36| `templates/perf-monitor-template.sv` | SV measurement harness scaffold: cycle counter, throughput/latency monitors wired to DUT ports. |37| `scripts/parse_perf_report.py` | Deterministic comparator: parses the perf-monitor summary block from the sim run log, compares against `bfm/perf_baseline.json`, writes `{module}_perf.json` with per-metric delta_pct/verdict (10% threshold; exit 1 on FAIL). |38| `references/perf-verify-conventions.md` | Metric naming, JSON schema, 10% deviation threshold, report structure, anti-patterns. |39| `examples/` | Worked example: sample run log + baseline + generated `cabac_encoder_perf.json` + README with the exact command and metric arithmetic. |40</Assets>4142<Responsibility_Boundary>43- **Scripts** handle deterministic measurement: cycle counters and throughput monitors in the SV harness produce raw numeric values written to the JSON output.44- **LLM** handles interpretive analysis: deviation root cause (which pipeline stage contributes stalls), recommendation text, and BFM vs RTL gap narrative.45- Contract surface: `{module}_perf.json` schema and report structure documented in `references/perf-verify-conventions.md`.46</Responsibility_Boundary>4748<Execution>491. Read `references/perf-verify-conventions.md` for the JSON schema, 10% deviation threshold, and report structure.502. Spawn `p5s-perf-orchestrator` (see Tool_Usage) to execute performance simulation using `templates/perf-monitor-template.sv` as the measurement harness scaffold.513. The orchestrator reads `bfm/perf_baseline.json`, runs the simulation, and writes `sim/{module}/{module}_perf.json` with measured vs expected values and per-metric PASS/FAIL verdicts. For deterministic comparison it can run `python3 {plugin_root}/skills/rtl-p5s-perf-verify/scripts/parse_perf_report.py --log sim/{module}/{module}_perf_run.log --baseline bfm/perf_baseline.json -o sim/{module}/{module}_perf.json` (`{plugin_root}` = plugin root resolved from `.rat/state/spawn-context.json`; see `examples/README.md` for flags).524. The orchestrator writes `reviews/phase-5-verify/{module}-performance-report.md` with the metrics table, deviation analysis for any failing metric, and a recommendation.535. Report the overall PASS/FAIL verdict and the report path to the user.5455Apply steps 1-5 to every requested module — do not stop after the first.56</Execution>5758<Tool_Usage>59Performance orchestration:60```61Task(subagent_type="rtl-agent-team:p5s-perf-orchestrator",62 prompt="Execute performance verification. User input: $ARGUMENTS")63```6465Do not perform simulation work directly — the orchestrator manages performance simulation, BFM baseline comparison, throughput/latency/stall measurement, and deviation flagging.66</Tool_Usage>6768<Examples>69<example index="1">70<scenario>Video encoder module after a pipeline rebalancing change; throughput must match BFM baseline within 10%.</scenario>71<reference>examples/</reference>72<expected_output>JSON reports throughput 480 Mbps measured vs 500 Mbps expected (4% delta → PASS); latency 12 cycles vs 12 expected (0% → PASS); overall PASS. Report recommends proceeding to `rtl-p6-design-review`.</expected_output>73</example>7475<example index="2">76<scenario>RTL change introduced a pipeline bubble; stall cycles exceed baseline by 15%.</scenario>77<reference>examples/</reference>78<expected_output>JSON reports stall_cycles_pct 23% measured vs 8% expected (188% delta → FAIL); overall FAIL. Report identifies the added pipeline register at the output FIFO as the contributor; recommends inspecting `rtl/encoder/output_buffer.sv`.</expected_output>79</example>8081<example index="3">82<scenario>`bfm/perf_baseline.json` is absent before BFM development is complete.</scenario>83<reference>examples/</reference>84<expected_output>WARNING emitted: `bfm/perf_baseline.json` not found — recommend running `/rtl-agent-team:bfm-develop` first. Skill does not proceed to simulation.</expected_output>85</example>86</Examples>8788<Escalation_And_Stop_Conditions>89- `bfm/perf_baseline.json` absent → emit WARNING; do not fabricate baseline values; stop.90- Simulation fails to compile or run → report the error; do not report performance metrics.91- Deviation exceeds 10% → report FAIL with deviation analysis; do not auto-accept.92- Performance bottleneck requires RTL-level investigation → flag the suspected module and signal path; do not modify RTL.93</Escalation_And_Stop_Conditions>9495## Output9697- `sim/{module}/{module}_perf.json` — raw measured vs expected metric values with per-metric PASS/FAIL.98- `reviews/phase-5-verify/{module}-performance-report.md` — throughput and latency table vs BFM baseline, deviation analysis, PASS/FAIL verdict.99100<Final_Checklist>101- [ ] `bfm/perf_baseline.json` read as baseline source — no fabricated values.102- [ ] `sim/{module}/{module}_perf.json` written with all three metric categories.103- [ ] Metrics exceeding 10% deviation flagged as FAIL.104- [ ] `reviews/phase-5-verify/{module}-performance-report.md` written with deviation analysis.105- [ ] RTL source not modified.106- [ ] Overall verdict and report path reported to the user.107</Final_Checklist>