Menu
Get structured porting guidance when moving a kernel between architectures. Launches sages for source and target, reads test harness.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Create, extend, debug, and validate Quasar LLK performance tests and their PerfRunType kernel paths. Use when adding perf_[op]_quasar.py, wiring PerfConfig, implementing UNPACK_ISOLATE / MATH_ISOLATE / PACK_ISOLATE / L1_CONGESTION, or investigating implausible Quasar perf metrics and dvalid handshakes.
Create, extend, debug, and validate Quasar LLK performance tests and their PerfRunType kernel paths. Use when adding perf_[op]_quasar.py, wiring PerfConfig, implementing UNPACK_ISOLATE / MATH_ISOLATE / PACK_ISOLATE / L1_CONGESTION, or investigating implausible Quasar perf metrics and dvalid handshakes.
Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.
Convert LLK lib/API tile-size args to ckernel::TensorShape and maintain TRISC TensorShape coverage. Use when adding TensorShape parameters, replacing face_r_dim/num_faces, editing LLK_VALIDATE_TENSOR_SHAPE_*, regenerating tensor_shape_coverage_*.h, or reviewing TensorShape PRs.
Audit LLK code for races on the backend CONFIG register file where differently-named fields share the SAME 32-bit config word — both cross-thread (unpack/math/pack write the same word) and intra-thread (a full-word write clobbers a sibling field the same thread set elsewhere). Use after adding/changing any ALU_FORMAT_SPEC / ALU_ACC_CTRL / ALU_ROUNDING_MODE / STACC_RELU / THCON_SEC* write, any WRCFG_32b/cfg[]= full-word write to a multi-field word, or any cfg_reg_rmw_tensix on a word another thread also touches.
Audit hand-written Tensix/SFPU instruction sequences for missing pipeline-latency padding — where a dependent instruction consumes a multi-cycle-latency result before it is ready and a NOP (or independent-instruction spacing) is required. Use after touching any raw TTI_SFP*/TTI_* sequence, ckernel_sfpu_* kernels, or hand-assembled instruction streams. NOT a cross-thread race — an intra-thread micro-architectural hazard.
| name | port-kernel |
| description | Get structured porting guidance when moving a kernel between architectures. Launches sages for source and target, reads test harness. |
| user_invocable | true |
/port-kernel reduce --from wormhole --to quasar
/port-kernel pack_untilize --from blackhole --to quasar
/port-kernel eltwise_binary --from wormhole --to blackhole
kernel_type (sfpu/math/unpack/pack) by checking which subdirectory or header prefix the kernel lives under in the source architecture.Task A — Source sage: Launch the sage for the source architecture
Agent tool:
subagent_type: "sage-{source_arch}"
description: "Source analysis: {kernel}"
prompt: |
Find the implementation of {kernel} on {source_arch}.
Report: algorithm, function signatures, template parameters,
key constructs (MOP, replay buffer, address modifiers),
data format handling, dependencies.
Task B — Target sage: Launch the sage for the target architecture
Agent tool:
subagent_type: "sage-{target_arch}"
description: "Target conventions: {kernel}"
prompt: |
Find the conventions for {kernel_type} kernels on {target_arch}.
Search for: closest existing kernel of the same type,
file naming pattern, instruction conventions, MOP patterns,
config write patterns, any existing partial implementation of {kernel}.
While sages run, read the test harness for the target architecture:
tests/sources/ for matching test files#ifdef ARCH_{TARGET} sections for expected function signatures when presentARCH_{TARGET} sections exist, fall back to unguarded/common signatures in the matching test filestests/helpers/include/* for target-specific declarations/helpers (especially for Quasar), and if needed inspect target arch headers directlyAggregate into structured porting guidance:
## Porting: {kernel} ({source} → {target})
### Algorithm Summary
[From source sage — what the kernel does]
### Source Implementation
[Key functions, patterns, data format handling]
### Target Conventions
[From target sage — how similar kernels are structured on target]
### API Contract (from test harness)
[Expected function signatures, template params from test files]
### Key Differences
[What changes between source and target — naming, instructions, patterns]
### Recommended Template
[Which existing target kernel to use as a starting point]
### Porting Checklist
- [ ] Function signatures match test harness expectations
- [ ] Uses target arch instruction conventions
- [ ] Init/uninit symmetry maintained
- [ ] All data format paths handled
.claude/references/porting-guide.md for detailed methodology