Help us improve
Share bugs, ideas, or general feedback.
From rtl-agent-team
Measures RTL throughput, latency, and stall cycles against BFM-predicted baselines, flagging deviations over 10% and generating a PASS/FAIL performance report.
npx claudepluginhub babyworm/rtl-agent-team --plugin rtl-agent-teamHow this skill is triggered — by the user, by Claude, or both
Slash command
/rtl-agent-team:rtl-p5s-perf-verify [module-name][module-name]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<Purpose>
Defines RTL performance verification policy: monitor naming conventions, BFM comparison thresholds (10% deviation), escalation rules, and stress vector patterns for cycle-accurate measurement.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
<Use_When>
bfm/perf_baseline.json.<Do_Not_Use_When>
bfm-develop first.rtl-p5s-func-verify first.rtl-synth-check instead.
</Do_Not_Use_When><Why_This_Exists> RTL 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. </Why_This_Exists>
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.
<Responsibility_Boundary>
{module}_perf.json schema and report structure documented in references/perf-verify-conventions.md.
</Responsibility_Boundary>Apply steps 1-5 to every requested module — do not stop after the first.
<Tool_Usage> Performance orchestration:
Task(subagent_type="rtl-agent-team:p5s-perf-orchestrator",
prompt="Execute performance verification. User input: $ARGUMENTS")
Do not perform simulation work directly — the orchestrator manages performance simulation, BFM baseline comparison, throughput/latency/stall measurement, and deviation flagging. </Tool_Usage>
Video encoder module after a pipeline rebalancing change; throughput must match BFM baseline within 10%. skills/rtl-p5s-perf-verify/examples/ 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`. RTL change introduced a pipeline bubble; stall cycles exceed baseline by 15%. skills/rtl-p5s-perf-verify/examples/ 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`. `bfm/perf_baseline.json` is absent before BFM development is complete. skills/rtl-p5s-perf-verify/examples/ WARNING emitted: `bfm/perf_baseline.json` not found — recommend running `/rtl-agent-team:bfm-develop` first. Skill does not proceed to simulation.<Escalation_And_Stop_Conditions>
bfm/perf_baseline.json absent → emit WARNING; do not fabricate baseline values; stop.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.<Final_Checklist>
bfm/perf_baseline.json read as baseline source — no fabricated values.sim/{module}/{module}_perf.json written with all three metric categories.reviews/phase-5-verify/{module}-performance-report.md written with deviation analysis.