메뉴
Get structured porting guidance when moving a kernel between architectures. Launches sages for source and target, reads test harness.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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