ascendc-blaze-best-practice

Guides development of MatMul-class operators on Ascend 950 NPU using Blaze and tensor_api.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developing high-performance MatMul-family operators (Basic, Batch, Grouped, Quantized, MX) and MatMul-plus-Vector-Epilogue fused operators on the Ascend 950 / DAV_3510 NPU requires navigating the Blaze/tensor_api component library, strict ABI contracts, and device-side verification gates. This Skill provides a disciplined four-step workflow that turns an operator requirement into a source-backed design, plan, and verified implementation. ## Core Features & Use Cases - Four-Step Development Workflow: Project Setup, Blaze source Investigation, Kernel Design (DESIGN/PLAN generation), and Implementation, each with explicit entry and exit gates. - Route Decision Model: Classifies each project as blaze_native, blaze_custom, or unsupported based on evidence-closed analysis of official Blaze coverage versus native gaps. - Reusable Precision and Device Gates: Enforces Golden dtype-chain freezing, logical-to-physical buffer crosswalks, synchronization lifecycle closure, and layered verification (compile, CPU Golden, device_verified). - Use Case: When asked to implement a BatchMatmulMaxSum-style fused operator on Ascend 950, the Skill investigates the current ops-tensor source tree, produces a frozen DESIGN.md and PLAN.md with ABI crosswalks, then drives implementation with per-case device evidence. ## Quick Start Ask the assistant to develop a MatMul operator on Ascend 950 using the Blaze library and let it run the four-step workflow from project setup through device verification.

Frequently Asked Questions about ascendc-blaze-best-practice

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

FAQPage Schema
How do I develop a MatMul operator on Ascend 950 with Blaze?▼

Follow the four-step workflow: Step 1 sets up the project and read-only Blaze source copies, Step 2 investigates the current ops-tensor source for candidate assemblies, Step 3 freezes DESIGN.md and PLAN.md, and Step 4 implements against the frozen contracts with device verification.

Which operator types does the Blaze Ascend workflow support?▼

It covers Basic, Batch, Grouped, Quantized, and MX MatMul operators, plus MatMul fused with a Vector Epilogue, on Ascend 950 / DAV_3510. Pure Vector operators and A2/A3 platforms are explicitly out of scope.

How is the blaze_native versus blaze_custom route decided?▼

Choose blaze_native when official Blaze components cover all required partitions with source evidence. Choose blaze_custom only when a native gap is evidence-closed and exactly one registered scenario matches; zero or multiple scenario matches result in an unsupported route.

Can part of the operator computation run on the host side?▼

No. All computation steps must execute inside a single device-side Kernel; the host only handles data preparation, Tiling calculation, Kernel launch, and result movement. Excluding non-matmul steps to the host to shrink native_gaps is forbidden.

Why does a CTest run with zero tests not count as passing?▼

A ctest return code of 0 with 'No tests were found' proves nothing was executed. You must confirm expected test registration with ctest -N, run against the current clean build, and cross-check DESIGN, PLAN, and reports for consistent PASS/BLOCKED status before delivery.

What evidence is required before claiming device_verified status?▼

device_verified requires a real device path with recorded sandbox or device-visible context, device node, SoC architecture, full command, return code, and output. Compilation success, CPU Golden passes, or symbol lookup alone cannot be reported as device verification.