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.