ascendc-cross-gen-port

Ports AscendC operators from arch22 to arch35 NPU architectures via an orchestration engine.

Updated Sep 15, 2026
One-click install
npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-cross-gen-port-wangwindow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ascendc-cross-gen-port
Source: https://github.com/WangWindow/CANN-BatchMatMulMaxsum/tree/main/.agents/skills/ascendc-cross-gen-port
Command: npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-cross-gen-port-wangwindow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Migrating an AscendC operator implementation from one Ascend NPU generation (arch22, e.g. 910C/V220) to a newer target (arch35, e.g. 950PR/V300) requires manual analysis, reference capture, porting, build, precision verification, and performance benchmarking. This Skill automates that cross-generation porting pipeline through a bundled orchestrator engine. ## Core Features & Use Cases - Natural-language target resolution: Users specify the target architecture in plain language (arch35 / 950PR / A5 / SoC number); the source architecture is auto-detected from the operator code. - Two reference modes: KernelBench-style golden (task .py plus same-stem .json/.jsonl sidecar) as frozen ground truth, or explicit live A3 CANN measurement (a3_live) for fresh on-device truth. - Deterministic pipeline: The engine runs an O0-O6 pipeline (parse, classify, reference capture, port, build, precision verification, performance, report) and writes customer-view results to verification.json. - Use Case: Given an ops-nn source operator directory such as cann/ops-nn/activation/gelu and a KernelBench golden pair, port the operator to arch35 and receive a PASS/FAIL verdict with per-case counts and speedup evidence. ## Quick Start Port the operator in my ops-nn source directory to arch35 using my KernelBench golden task file as the reference and report the verification result.

Frequently Asked Questions about ascendc-cross-gen-port

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I port an AscendC operator from arch22 to arch35?

Provide the arch22 ops-nn operator source directory and a KernelBench-style golden (task .py plus same-stem .json/.jsonl sidecar), then state the target architecture in natural language. The skill invokes the bundled orchestrator engine's port-a3-ops mode, which runs the full port, build, and verification pipeline.

What reference formats does AscendC operator porting accept?

Two reference sources are supported and cannot be mixed: npubench, a frozen KernelBench-style task file pair used as the sole functional truth, and a3_live, an explicit fresh measurement on A3 CANN hardware. TileLang2AscendC project sources only support the npubench golden.

Can I use live A3 hardware as the ground truth for porting?

Yes, but only for regular ops-nn sources and only when explicitly requested via --reference-source a3_live or the PORT_A3_REFERENCE_SOURCE config. Both A3 and A5 must be configured in .ascendc_env, and speedups measured this way are not comparable to npubench-mode speedups.

Why is there no real-time console output when the porting pipeline runs?

The launcher must be started with run_in_background enabled and without trailing ampersands, nohup, shell redirection to log files, or truncating pipes like tail. These detach the process from the task tracker or buffer output, leaving the console dark; progress should be read via the task output instead.

What are the limitations of cross-generation AscendC operator porting?

The skill is a thin entry point; all pipeline logic lives in the bundled engine, and inputs must already be in the required formats since the plugin does not generate golden tasks. Speedup numbers from npubench and a3_live modes use different baselines and cannot be compared directly.