skills.rest
WangWindow
WangWindowCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

ascendc-cross-gen-port-light

Migrate AscendC operator projects from DAV_2201 to DAV_3510 NPU architecture.

Updated Sep 15, 2026
Search Tags:#cube#npu#cann#ascendc#operator migration#precision testing#ascend 950
One-click install
npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-cross-gen-port-light-wangwindow
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ascendc-cross-gen-port-light
Source: https://github.com/WangWindow/CANN-BatchMatMulMaxsum/tree/main/.agents/skills/ascendc-cross-gen-port-light
Command: npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-cross-gen-port-light-wangwindow

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires torch, torch_npu, pytest, and includes references (resource) components.

What problem does it solve? Porting existing AscendC operator kernels from Ascend 910b/910_93 (DAV_2201, arch22) to Ascend 950 (DAV_3510, arch35) requires handling API precision differences (subnormal clipping), compatibility breaks (int4 Mmad), performance regressions (vnchwconv/VSLDB/BilinearInterpolation), and Cube-side changes (ZZ-to-NZ fractal, cross-core synchronization protocols). This Skill provides a gated Stage 0-5 workflow that performs this migration without requiring KernelBench golden inputs, synthesizing precision baselines by reverse-engineering the source operator. ## Core Features & Use Cases - Staged migration workflow: Six gated phases (environment validation, assessment/leveling, code transformation, build/install, precision verification, performance collection) with evidence-based GATE tokens that block progression without real artifacts. - Three migration levels: L1 basic adaptation, L2 RegBase MicroAPI rewrite (including AIC low-level direct-run evaluation for Cube operators), and L3 SIMT optimization, selected via a decision tree. - API difference adaptation: Mandatory scanning and adaptation for subnormal precision loss, int4 Mmad incompatibility, and performance-degraded instructions, with regression shapes for performance testing. - Use Case: You have a working BatchMatmul or RMSNorm operator on Ascend 910b and need it running on Ascend 950 with verified precision (30+ test cases via torch.ops.npu bindings) and profiler-based performance data, without an existing golden reference. ## Quick Start Ask the agent to migrate your existing AscendC operator project from the 910b platform to Ascend 950 using the lightweight cross-generation port workflow, providing your CANN installation path and operator project directory.

Frequently Asked Questions about ascendc-cross-gen-port-light

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

FAQPage Schema
How do I migrate an AscendC operator from Ascend 910b to Ascend 950?▼

Follow the Stage 0-5 gated workflow: validate the CANN/torch_npu environment, assess the operator into migration level L1/L2/L3, transform the code (including API difference adaptation), build with the provided script template, then verify precision and performance. Each stage requires evidence before the next gate opens.

What is the difference between ascendc-cross-gen-port and ascendc-cross-gen-port-light?▼

The light variant runs without KernelBench golden inputs and without the orchestration engine, synthesizing precision baselines by reverse-engineering the A2 source code. Use the full ascendc-cross-gen-port when you need engine-driven end-to-end automation with closed-loop build, precision, and performance reporting.

How are AscendC migration levels L1, L2, and L3 decided?▼

A decision tree classifies operators: performance-critical or FP8/quantization-heavy operators go to L2 (RegBase MicroAPI rewrite), Scatter/Gather operators with simple indexing go to L3 (SIMT), and everything else defaults to L1 basic adaptation. All levels additionally require API difference adaptation for subnormal, int4 Mmad, and performance regression risks.

Does Ascend 950 handle subnormal floating-point values differently?▼

Yes, Ascend 950 (A5) clips subnormals, so basic arithmetic APIs like Exp, Ln, Sqrt, Div, Reciprocal, and Rsqrt lose precision on subnormal inputs. The skill mandates risk scanning, evidence-based analysis, and adaptation via eps avoidance, PRECISION_1ULP_FTZ_FALSE template parameters, or high-precision branches.

Why does my migrated Cube operator deadlock on Ascend 950?▼

Cross-core synchronization primitives like CrossCoreSetFlag/WaitFlag have different participation-set semantics on arch35, and the same mode number does not guarantee the same semantics across architectures. The skill requires a per-sync-point audit against target-platform documentation, disabling paths that cannot be statically proven safe.

Can I use PyTorch native interfaces to verify migrated operator precision?▼

No, precision tests must call torch.ops.npu.<op_name> through an EXEC_NPU_CMD-based C++ extension binding, because torch_npu's built-in dispatch may route to non-migrated paths on Ascend 950. Manual aclnn C API calls and import ascend_kernel are also prohibited.

Related Skills

Explore More Software Engineering Skills→
ascend-ai-codingascend-ai-coding
156

ascendc

Implement AscendC transformer operator definitions and kernels for FFN, GMM, and MoE.

Official
Advanced
dongg622dongg622

wan-ascend-adaptation

Migrate Wan-series video diffusion models from CUDA to Huawei Ascend NPU.

Community
Advanced
hw-native-syshw-native-sys
11

ascendc-npu-arch

Map Ascend NPU architectures, generations, and SocVersion references.

Official
Intermediate
AscendAscend
31

ascendc-operator-precision-eval

Generate and run AscendC operator precision tests, outputting Markdown and JSON reports.

Official
Advanced