triton-operator-design

Triton Operator Requirement Document Generation

Workflow

1. Requirements Analysis → Outputs: function definition, mathematical formulas, competitor comparison
2. Prototype Design → Outputs: API interface definition
3. Specification Constraints → Outputs: input/output constraints, hardware limitations
4. Feature Implementation → Outputs: Tiling strategy, Kernel implementation plan

Reference Resource Loading

Stage	Must load	Do not load
Requirements Analysis	ascend-terminology.md	template, tiling-strategies
Prototype Design	triton-api-reference.md	tiling-strategies
Feature Implementation	tiling-strategies.md, triton-operator-template.md	ascend-terminology

MANDATORY: Before Stage 4, read in full tiling-strategies.md and triton-operator-template.md, with no line limit. Output the document in the template format.

Key Terms

• GM: Global memory (DDR),UB: Vector Core high-speed cache (192KB),L1: Cube Core cache (~1MB)
• AI Core: A2/A3 has 24, containing 1 Cube + 2 Vector
• Reduction operations must be upcast to FP32

Absolutely Do Not Do

• ❌ Use vague terms ("appropriate splitting", "reasonable allocation") — specific calculation methods must be given
• ❌ Ignore UB size (192KB) and alignment requirements (32B)
• ❌ Do not distinguish Vector Core (vector computation) and Cube Core (matrix computation)
• ❌ Do not annotate data types and GM↔UB transfers in the data flow diagram
• ❌ Do not explain the upcast strategy for reduction operations

Common Pitfalls

Pitfall	Symptom	Solution
UB overflow	Plan is infeasible	Total buffer size < 192KB
Memory misalignment	Hardware error	UB buffers 32B aligned, single-value buffers allocated 32B
Precision loss	Inaccurate FP16 results	Upcast to FP32 before reduction, downcast after completion
Unreasonable Tiling	Poor performance/large shapes unsupported	Split by dimension, avoid cross-Core data dependencies