@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/meta/vendor-reference/build-recipe.md

@@ -1,116 +0,0 @@
----
-id: skill-ascendc-direct-launch-build-recipe
-title: "Compiling an Ascend C Kernel for Direct Launch — the bisheng Recipe"
-type: skill
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-evidence_level: measured
-cann_version: '9.0.0/9.1.0'
-confidence: experimental
-applies_to:
-- ascend910b
-scope: >-
-  Compiling a kernel source into an object file with the CANN bisheng compiler,
-  for a build that launches it directly with <<<blocks, l2ctrl, stream>>>. The
-  flags below were exercised on a hand-written minimal kernel; whether an
-  unmodified vendor op_kernel/ directory compiles as-is was NOT tested - see
-  "What was verified and what was not".
-tags:
-- ascendc
-- ai-core
-source:
-- path: spec
-  anchor: CANN bisheng compiler flags
-related:
-- skill-ascend-vendor-reference-sources
-- pitfall-ascendc-matmul-c-to-ub-direct-launch
-aliases:
-- "怎么把官方 kernel 编成直调"
-- "官方 kernel 编译配方"
-- "直调 kernel 编译配方"
-- "bisheng 编译 Ascend C"
-- "npu-arch dav-2201"
-- "-xasc"
-- "ASCEND_HOME_PATH"
----
-
-Three things have to be right at once. Getting two of them right produces an error
-message that points at the third only if you already know it exists.
-
-```bash
-source $ASCEND_HOME/../set_env.sh          # 0. see "The prerequisite" below
-BS=$ASCEND_HOME/ccec_compiler/bin/bisheng
-$BS -O3 -DNDEBUG -std=gnu++17 -fPIC --npu-arch=dav-2201 -xasc -I. \
-    -c xxx_kernel.cpp -o xxx.o
-```
-
-| Flag | Why |
-|---|---|
-| `--npu-arch=dav-2201` | 910B and 910C are both `DAV_2201`. `dav-c220` is rejected. |
-| `-xasc` | Tells bisheng the source is Ascend C, not C++. Without it the AscendC intrinsics are unresolved names. |
-| `-std=gnu++17` | Not optional. Designated initializers - which the vendor arch35 tiling headers use - are an error on non-aggregates under C++11. |
-
-On the host side the same standard has to be forced through a second path:
-**`opbuild`'s code generation does not honour `CMAKE_CXX_STANDARD`**. Set it
-explicitly in the codegen step's `COMPILE_OPTIONS` or the generated tiling
-translation unit compiles under the toolchain default and fails on the same
-designated initializers.
-
-## The prerequisite the recipe used to leave out
-
-If `ASCEND_HOME_PATH` is not in the environment - i.e. `set_env.sh` was never
-sourced - bisheng does not report a configuration error. **It crashes**, and it
-asks you to file an LLVM bug:
-
-```
-LLVM ERROR: PlugIn Err: can not find ASCEND_HOME_PATH.
-PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/
-Stack dump: ...
-```
-
-Nothing in that message names the environment variable as *your* problem. A
-recipe where three things have to be right at once is only as good as its least
-documented step: the one it leaves out is the one that sends you somewhere else
-entirely.
-
-## What was verified and what was not
-
-Measured 2026-09-10 on **910B2C, CANN 9.1.0**, compiling a minimal hand-written
-kernel (one block copied in → `Abs` → copied out):
-
-| Probe | Result |
-|---|---|
-| `--npu-arch=dav-2201` | accepted |
-| `--npu-arch=dav-c220` | rejected |
-| `-xasc` | accepted |
-| `-std=gnu++17` | **required** - the identical source with `-std=c++11` does not compile (control group) |
-| Output | `tiny.o`, 16512 bytes |
-
-The `cann_version` on this page is `9.0.0/9.1.0` on purpose: the recipe was first
-written down under 9.0.0 and re-verified under 9.1.0. Both readings agree.
-
-> ⚠️ **What this does not establish.** The subject of the test was the *compiler
-> flags*, on a kernel written for the purpose. Whether an unmodified vendor
-> `op_kernel/` directory copied in wholesale will compile is a different claim and
-> was **not** tested. The evidence pointing the other way - that vendor
-> implementations pull in internal headers and a build system of their own, so
-> the structure is what you extract rather than the files - still stands. Do not
-> read a green compile of a minimal kernel as a green light for `cp -r`.
-
-## Where this sits
-
-The chain is: find the repository and map the operator name
-([`skill-ascend-vendor-reference-sources`](./sources.md)) → decide what to extract
-from the vendor implementation → convert its tiling entry
-([`skill-ascendc-vendor-tiling-entry-to-direct-launch`](../../compute/matmul-direct-launch/tiling-entry.md))
-→ compile it (this page). How much the vendor implementation is worth on an
-operator you already have source for is quantified in
-[`hw-ascend-porting-910b-to-910c`](../../../hardware/porting-910b-to-910c.md).
-
-The recipe was distilled from getting a vendor **LSTM** kernel to compile end to
-end on 910B/910C (`DAV_2201`).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/meta/vendor-reference/sources.md

@@ -1,49 +0,0 @@
----
-id: skill-ascend-vendor-reference-sources
-title: "Where Huawei's Official Ascend C Operator Implementations Live"
-type: skill
-vendor: ascend
-architectures:
-- ascend910b
-languages:
-- ascendc
-evidence_level: spec
-applies_to:
-- ascend910b
-tags:
-- ascendc
-source:
-- path: spec
-  anchor: Public vendor repositories
-related:
-- routing-ascend-vendor-impl-name-mapping
-- skill-ascendc-direct-launch-build-recipe
-aliases:
-- "华为官方实现 仓库地址"
-- "官方 Ascend C 源码在哪"
----
-
-Huawei publishes its Ascend C operator kernels. This matters for two reasons: it is
-where a CANN-baseline implementation comes from, and it is the only way to see how
-the vendor's own engineers structured an operator before deciding whether to follow
-them.
-
-| Repository | Contents | Kernel files |
-|---|---|---:|
-| `gitcode.com/cann/ops-nn` | general neural-network operators | 3237 |
-| `gitcode.com/cann/ops-transformer` | attention / MoE / positional encoding | 2749 |
-| `gitcode.com/cann/ops-math` | math / indexing / reduction | 1469 |
-| `gitcode.com/cann/ops-cv` | imaging / detection | 338 |
-| `gitee.com/ascend/cann-ops-adv` | higher-level operators | — |
-| `gitee.com/ascend/cann-ops` | — | — |
-
-**Read the licence of anything you port** — a vendor kernel carries its own terms
-into whatever artifact you put it in.
-
-Operator names in these repositories do not map one-to-one onto framework operator
-names; see [`routing-ascend-vendor-impl-name-mapping`](../../../operator-routing/vendor-impl-name-mapping.md)
-before picking a file.
-
-Once you have the file, the flags that turn it into an object file for a
-direct-launch build are in
-[`skill-ascendc-direct-launch-build-recipe`](./build-recipe.md).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/hardware/dav-3510-resource-model.md

@@ -1,103 +0,0 @@
----
-id: hw-ascendc-dav-3510-resource-model
-title: DAV_3510 capabilities and SIMT resource accounting
-type: hardware
-vendor: ascend
-architectures:
-- ascend910b
-- ascend950
-languages:
-- ascendc
-tags:
-- ascendc
-confidence: source-reported
-evidence_level: spec
-scope: Selected cannbot notes at ddea090f28ec863e97a65f71ccc9cc9b956e327a; architecture
-  and implementation conditions are stated per section. No local SDK compilation or
-  device validation.
-sources:
-- blog-cannbot-ascendc-notes
-source:
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-simt-best-practices/SKILL.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-simt-tiling-design/SKILL.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/npu-arch/SKILL.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/npu-arch/references/npu-arch-guide.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/npu-arch/references/npu-hardware-params.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/npu-arch/references/simt-arch-guide.md
-related:
-- hw-ascend-porting-910b-to-910c
-aliases:
-- DAV_3510
-- arch35
-- SIMT
-- LAUNCH_BOUND
-- UB DCache
----
-
-# DAV_3510 capabilities and SIMT resource accounting
-
-Source-reported constraints and adapted algorithms from the [pinned cannbot snapshot](../../../sources/blogs/cannbot-ascendc-notes.md). These notes are not an SDK specification or a device validation record. Existing versioned API and measured pages remain authoritative for their stated scope.
-
-## Identity before capacity
-
-The existing [910B to 910C page](porting-910b-to-910c.md) owns the DAV_2201 relationship; this page adds the DAV_3510 comparison. `NpuArch` describes the ISA/microarchitecture, `SocVersion` the product configuration, and `__NPU_ARCH__` a device compilation branch. Query failures (`DAV_RESV`, `RESERVED_VERSION` in the source) are unknown targets, not defaults.
-
-The source maps 950DT/950PR to 3510 (arch35); the historical macro `__DAV_C310__` also denotes that family, not an Ascend 310 product. Other source mappings include Ascend910=1001, 310P=2002 and 310B=3002. Resolve enumerators against the installed SDK; do not create missing enum values to simulate support.
-
-## Source-reported 3510 additions
-
-The **Status** column records what one `Ascend950PR_9579` host under CANN 9.1.0
-reports back. Field values and the reproduction command are on the
-[measured platform inventory](dav-3510-vs-dav-2201-inventory.md); rows still
-marked source-reported name the specific reason they could not be settled there.
-
-| Capability | Resource or programming consequence | Status on Ascend950PR_9579 |
-|---|---|---|
-| RegBase and SIMT | Separate VF calling and memory domains; not 2201 replacements | **Partly measured** — the INI adds `vector_reg_width=256`, `predicate_reg_width=32`, `wide_reg_width=768`, absent on 910B2. "Separate domains" remains source-reported: no SIMT kernel was compiled |
-| L0C to UB through Fixpipe; UB to L1 | Potentially avoid GM intermediates, but only for supported dtype/layout/API combinations | Source-reported — **no Cube kernel written on this host yet** |
-| L0C reported as 256 KiB | Recompute accumulator and buffering costs; the existing 2201 page reports 128 KiB | **Measured**: `l0_c_size=262144` |
-| Physical UB reported as 256 KiB with 8 KiB reserved | Distinguish physical, allocator-visible and user-available budgets | **Measured**: `ub_size=253952` = 256 KiB − 8 KiB. The INI field is the **per-AIV user-available** budget, so do not subtract the reserve a second time |
-| BT reported as 4 KiB | Account for bias alignment independently of L0C | **Measured**: `bt_size=4096` |
-| NDDMA GM to UB, at most five dimensions | Collapse legal axes or loop over outer dimensions | Source-reported — **no such INI field, and no NDDMA kernel written** |
-| MX data and shared scale | Separate layouts, transfer cadence and buffer lifetimes | Source-reported — **not exercised** |
-
-Three further INI differences are not on the source's list at all and change
-whether a 910B technique has a target on 950: **FB2 and FB3 are 0**, the
-`unzip_engines` group is absent entirely, and **L2 is 128 MiB, smaller than
-910B's 192 MiB**. See the inventory page.
-
-Core counts, clock rates and bandwidth are SKU/runtime properties. Do not copy a full product specification table into tiling constants. This is not a style preference on 950: one CANN 9.1 installation ships **nine** `Ascend950PR_*` INIs spanning 28-36 Cube cores, and on a `_9579` board the CPU-mode stub models `_9599` while `cannsim` models `_9589`. A constant labelled only "Ascend 950" cannot be checked against the card that produced a reading. BufferID `get_buf/rel_buf` is not a mechanical substitution for Set/Wait: preserve ready and reuse dependencies for the actual producer, slot and consumer. See [RegBase/Fixpipe](../api-definitions/ascendc/regbase-fixpipe-contracts.md).
-
-## SIMT only: threads and registers
-
-Irregular GM access and per-thread branching are SIMT candidates; regular bulk operations still need comparison with SIMD. The source describes 32-thread warps. Consecutive addresses across lanes improve access regularity; divergence can reduce throughput. Thread-stride loops still require valid-element bounds.
-
-Keep `LAUNCH_BOUND(N)` and `Simt::Dim3(N)` tied to the same compile-time constant as required by the source templates. Merely keeping the runtime count below a bound does not establish that a different launch configuration is supported.
-
-| Compiled thread bound | Source-reported per-thread register limit |
-|---|---|
-| 1–256 | 127 |
-| 257–512 | 64 |
-| 513–1024 | 32 |
-| 1025–2048 | 16 |
-
-This is a version-dependent compiler resource table, not a hardware performance promise. Check resource/spill reports when changing either parameter. Wider global offsets may be necessary even when local indices fit in 32 bits; widen before multiplication, not after overflow.
-
-`__simt_vf__` / `__simt_callee__` and `__simd_vf__` / `__simd_callee__` are distinct domains. Preserve `__gm__` / `__ubuf__` address spaces; ordinary C++ pointer casts do not establish interoperability.
-
-## SIMT only: one physical budget
-
-```text
-static_UB + dynamic_UB + DCache + reserved <= physical_UB
-source configuration: physical_UB=256 KiB, reserved=8 KiB, DCache>=32 KiB
-```
-
-With no other static allocation, 32 KiB of DCache leaves 216 KiB for user UB; 128 KiB leaves 120 KiB. The source's `SetLocalMemorySize(256-128)` example uses a different or incomplete accounting convention. Do not copy that argument until the SDK's treatment of reserved/static bytes is known; a net-available query must not have the reserve subtracted twice.
-
-Cache capacity and shared tile size compete for the same storage. Compare them jointly against actual reuse and access patterns. These figures do not change the 2201 UB budget or prove a speedup on 950.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/hardware/dav-3510-vs-dav-2201-inventory.md

@@ -1,122 +0,0 @@
----
-id: hw-ascendc-dav-3510-vs-dav-2201-inventory
-title: DAV_3510 vs DAV_2201 measured platform inventory (Ascend950PR_9579)
-type: hardware
-vendor: ascend
-architectures:
-- ascend910b
-- ascend950
-soc:
-- ascend950pr-9579
-languages:
-- ascendc
-tags:
-- ascendc
-- ub
-- ai-core
-confidence: experimental
-evidence_level: measured
-cann_version: "9.1.0"
-scope: One Ascend950PR_9579 host, CANN 9.1.0, driver 25.7.0, read 2026-09-22.
-  Labelled experimental rather than verified on purpose - this wiki reserves
-  'verified' for claims corroborated by an official-doc and an upstream-code
-  evidence_basis entry, and these values have neither -- they are one host's own
-  report of itself. What they do settle is that the claims below are no longer
-  merely source-reported. Field values are read
-  from the platform_config INI files shipped by that CANN installation and compared
-  against Ascend910B2.ini from the same installation. INI values are the vendor's
-  declaration of the part, not a measurement of throughput. Core counts, L2 size and
-  clock are per SKU; the nine Ascend950PR_* variants in this installation differ,
-  so no value here transfers to another 950 SKU without re-reading its INI.
-related:
-- hw-ascendc-dav-3510-resource-model
-- hw-ascend-porting-910b-to-910c
-sources:
-- blog-cannbot-ascendc-notes
-aliases:
-- DAV_3510
-- arch35
-- Ascend950PR_9579
-- AIC-C-310
----
-
-# DAV_3510 vs DAV_2201 measured platform inventory
-
-The [DAV_3510 resource model](dav-3510-resource-model.md) records what the cannbot
-snapshot *says*. This page records what one `Ascend950PR_9579` installation
-*reports*, field by field, and which of the source-reported claims that settles.
-
-Every number below is reproducible in one command:
-
-```bash
-P=$ASCEND_HOME_PATH/x86_64-linux/data/platform_config
-diff <(grep -v '^#' $P/Ascend910B2.ini) <(grep -v '^#' $P/Ascend950PR_9579.ini)
-```
-
-## Ascend950PR is a SKU family, not a part
-
-This installation ships **nine** `Ascend950PR_*.ini` files (`950z 9579 957b 957bx
-957c 957d 9589 958b 9599`) and **25** `Ascend950DT_*`. Within the PR family core
-counts span 28 to 36 Cube — a 28.6% spread. Three toolchains on the same host
-model three different members:
-
-| Source | SOC | Cube / Vector |
-|---|---|---|
-| The board (the only real one) | `Ascend950PR_9579` | 28 / 56 |
-| tikicpulib CPU mode (only option) | `Ascend950PR_9599` | 36 / 72 |
-| `cannsim -s Ascend950` (only option) | `Ascend950PR_9589` | 32 / 64 |
-
-**No offline tool on this host models the board's own SKU.** Any published 950
-constant must therefore carry the SKU it came from; a table row labelled only
-"Ascend 950" cannot be checked. Public tables in circulation list `957b`
-(28/56, 112 MB L2) and `9589` (32/64, 128 MB L2) — neither is `9579`
-(28/56, **128 MB** L2), so matching two of three columns is not identification.
-
-## Field differences that change technique validity
-
-| Field | Ascend910B2 | Ascend950PR_9579 | Consequence |
-|---|---|---|---|
-| `AIC_version` / `NpuArch` / `Chip_type` | AIC-C-220 / 2201 / 5 | **AIC-C-310 / 3510 / 15** | `ccec` target moves `dav-c220-*` → `dav-c310-{cube,vec}` |
-| `fb0/fb1/fb2/fb3_size` | 2048 / 1024 / 2048 / 2048 | **4096 / 2048 / 0 / 0** | **FB2 and FB3 are absent.** Any technique that budgets them fails outright, not gradually |
-| `l2_size` | 192 MiB | **128 MiB** | L2 got **smaller** across generations. An L2-resident tiling ported from 910B may no longer fit; a bandwidth probe sized to escape 910B's L2 still escapes, but one sized to stay inside it may not |
-| `cube_freq` | 1800 | **1650** | Per-core scalar throughput is 8.3% lower; a same-core-count comparison is not a same-clock comparison |
-| `ubbank_num` / `ubbank_group_num` | 64 / 16 | **16 / 8**, plus new `ubsubbank_num=64` | The bank-conflict model differs. 910B UB layout experience does not transfer |
-| `vector_reg_width` / `predicate_reg_width` / `wide_reg_width` | absent | **256 / 32 / 768** | First hard evidence that the SIMD/RegBase register file exists as described |
-| `unzip_engines` and three siblings | present | **entire group absent** | Decompression-engine techniques have no target |
-| `sparsity` | 1 | **0** | This INI does not report a sparsity capability |
-| `padding_size` | 32 | **0** | |
-| `l0a_layout_zN` | absent | **1** | New layout enumerator |
-| `[DieInfo] io_die_num` | absent (no section) | **2** | Multi-die topology is declared at the platform level |
-| `l0_c_size` | 131072 | **262144** | |
-| `ub_size` | 196352 | **253952** (= 256 KiB − 8 KiB) | INI reports the **per-AIV user-available** budget, not the physical size |
-| `bt_size` | — | **4096** | |
-
-## What this settles from the source-reported list
-
-| Source claim | Verdict here |
-|---|---|
-| L0C reported as 256 KiB | **Confirmed**: `l0_c_size=262144` |
-| Physical UB 256 KiB with 8 KiB reserved | **Confirmed**: `ub_size=253952`. The reserved-byte arithmetic matches, but the field is the user-available value — do not subtract the reserve twice |
-| BT reported as 4 KiB | **Confirmed**: `bt_size=4096` |
-| RegBase / SIMT are separate domains | **Partly**: the register widths now have evidence; "separate calling and memory domains" is still source-reported, as no SIMT kernel was compiled here |
-| L0C→UB and UB→L1 passthrough | **Still source-reported**: no Cube kernel was written on this host |
-| NDDMA GM→UB at most five dimensions | **Still source-reported**: no such field in the INI, no NDDMA kernel written |
-| MX data and shared scale | **Still source-reported** |
-
-The three unresolved rows are unresolved for one reason each, stated above —
-not for lack of an INI field in general.
-
-## Toolchain facts from the same host
-
-- `msprof`'s `op_summary.csv` has the **same 48 columns** as on 910B, with the
-  `aiv_*` ratio group populated. Column-name-based analysis carries across
-  generations unchanged; so does `torch_npu.profiler`'s `kernel_details.csv`.
-- `msprof op simulator` fails with `aclrtSetDevice -> 507033`. Two hypotheses
-  were tested and excluded: rebuilding for `Ascend950PR_9599`, and pointing
-  `LD_LIBRARY_PATH` at `tools/simulator/dav_3510/lib`. Root cause unknown.
-- The working simulator entry point is `cannsim record` / `cannsim report`.
-  `-s` accepts only `Ascend950` / `Ascend950DT` / `Ascend960`; `Ascend950`
-  resolves to `Ascend950PR_9589`, recorded in `<archive>/record/.soc-version`.
-
-See the [950PR measurement discipline](../experience/ascend950pr-measurement-discipline.md)
-for what these facts require of a measurement.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/hardware/hw-ascend910-9362.md

@@ -1,110 +0,0 @@
----
-id: hw-ascend910-9362
-title: "Ascend910_9362 NPU 硬件规格"
-type: hardware
-vendor: ascend
-architectures:
-- ascend910b
-languages:
-- '*'
-tags:
-- ai-core
-- cube-unit
-- vector-unit
-- ascendc
-confidence: source-reported
-evidence_level: spec
-related: []
-sources: []
-aliases: []
----
-# Ascend910_9362 NPU 硬件规格
-
-> SoC_version: Ascend910_9362 | AIC_version: AIC-C-220 | Cube/Vector 分离架构
-
-## 芯片配置
-
-- 20 个 AI Core，每个包含: 2 个 VEC + 1 个 CUBE（Cube/Vector 分离）
-- 整个芯片: 40 VEC, 20 CUBE
-- Cube 频率: 1500 MHz
-- AI CPU: 6 个
-
-## 数据通路
-
-- MTE1: L1 → L0A/L0B
-- MTE2: GM → UB/L1/L0A/L0B
-- MTE3: UB → GM, L1 → L2 Cache
-- FixP: L0C → L1/GM（可随路类型转换，支持 NZ→ND 变换）
-- L2 Cache 自动缓存 GM 与 AI Core 间的数据交互
-
-## 存储系统
-
-| 存储层级 | 容量 | 共享范围 | 对齐 | 说明 |
-|---------|------|---------|------|------|
-| GM | 32GB | 全设备 | - | HBM 设备主存储 |
-| L2 Cache | 168MB | 20 个 AI Core | - | 自动缓存，64 页 |
-| L1 Buffer | 512KB | 单 AI Core | 32B | Cube 通用缓存 |
-| L0A | 64KB | 单 Cube | 32B | 左矩阵 A (m0×k0) |
-| L0B | 64KB | 单 Cube | 32B | 右矩阵 B (k0×n0) |
-| L0C | 128KB | 单 Cube | 32B | 结果矩阵 C (m0×n0)，支持累加 |
-| UB | 192KB | 单 VEC | 32B | 向量运算缓存（64 bank × 4KB） |
-
-## 计算单元
-
-### VEC（向量计算单元）
-
-- **性能**: 1 拍处理 128 Bytes 向量计算（每 AI Core 有 2 个 VEC）
-- **约束**:
-  - 数据需放入 UB (192KB)
-  - 支持连续内存或带 mask 访问
-  - 32 Bytes 对齐（UB block size）
-  - 内部按 128 Bytes 分块处理
-
-### CUBE（矩阵计算单元）
-
-- **性能**: 1 拍完成 16×16×16 FP16 矩阵乘（8192 FLOPs/cycle）
-- **支持精度**: FP16×FP16→FP16/FP32, INT8×INT8→INT32, INT4/INT2 量化
-- **工作流程**:
-  1. L0A ← 左矩阵 A (m0×k0)
-  2. L0B ← 右矩阵 B (k0×n0)
-  3. CUBE 执行矩阵乘: C = A × B
-  4. 结果写入 L0C，支持累加
-- **约束**:
-  - `m0 × k0 × sizeof(A.dtype) ≤ 64KB`（L0A）
-  - `k0 × n0 × sizeof(B.dtype) ≤ 64KB`（L0B）
-  - `m0 × n0 × sizeof(C.dtype) ≤ 128KB`（L0C）
-  - 32 Bytes 对齐
-  - 自动按 16×16 分块，尾块自动补 0 计算
-  - 支持稀疏计算（sparsity=1）
-
-### 数据类型 MKN 配置
-
-| 数据类型 | M | K | N |
-|---------|---|---|---|
-| FP16（默认） | 16 | 16 | 16 |
-| INT8/UINT8 | 16 | 32 | 16 |
-| INT4 | 16 | 64 | 16 |
-| INT2/UINT2 | 16 | 128 | 16 |
-| UINT1 | 16 | 256 | 16 |
-
-## 内存带宽（GB/s per AI Core）
-
-| 通路 | 读带宽 | 写带宽 |
-|------|--------|--------|
-| DDR (GM) | 32 | 32 |
-| L2 Cache | 110 | 86 |
-| L1 → L0A | 512 | - |
-| L1 → L0B | 256 | - |
-| L1 ↔ UB | 128 | 128 |
-| L0C → UB | 256 | - |
-| UB → L2/DDR | 64 | 64 |
-
-## 优化策略
-
-- **内存对齐**: 所有数据传输按照 32 Bytes 对齐（UB block size）
-- **数据复用**:
-  - 调整搬运顺序，让频繁访问数据缓存在 L2
-  - L1/UB 双缓冲技术: 一块计算，一块加载
-  - MTE 后台搬运与 CUBE/VEC 计算重叠
-- **并行**: 20 个 AI Core 按需并行分配任务，CUBE 与 VEC 可同时执行不同任务
-- **FixPipe**: 支持 L0C→L1 和 L0C→GM 的随路量化/反量化/类型转换/ReLU/NZ→ND 变换

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/hardware/hw-ascend910-9372.md

@@ -1,111 +0,0 @@
----
-id: hw-ascend910-9372
-title: "Ascend910_9372 NPU 硬件规格"
-type: hardware
-vendor: ascend
-architectures:
-- ascend910b
-languages:
-- '*'
-tags:
-- ai-core
-- cube-unit
-- vector-unit
-- ascendc
-confidence: source-reported
-evidence_level: spec
-related: []
-sources: []
-aliases: []
----
-# Ascend910_9372 NPU 硬件规格
-
-> SoC_version: Ascend910_9372 | AIC_version: AIC-C-220 | Cube/Vector 分离架构
-
-## 芯片配置
-
-- 20 个 AI Core，每个包含: 2 个 VEC + 1 个 CUBE（Cube/Vector 分离）
-- 整个芯片: 40 VEC, 20 CUBE
-- Cube 频率: 1800 MHz
-- AI CPU: 6 个
-
-## 数据通路
-
-- MTE1: L1 → L0A/L0B
-- MTE2: GM → UB/L1/L0A/L0B
-- MTE3: UB → GM, L1 → L2 Cache
-- FixP: L0C → L1/GM（可随路类型转换，支持 NZ→ND 变换）
-- L2 Cache 自动缓存 GM 与 AI Core 间的数据交互（支持 prefetch，prefetch_num=8）
-
-## 存储系统
-
-| 存储层级 | 容量 | 共享范围 | 对齐 | 说明 |
-|---------|------|---------|------|------|
-| GM | 64GB | 全设备 | - | HBM 设备主存储 |
-| L2 Cache | 192MB | 20 个 AI Core | - | 自动缓存，64 页，支持 prefetch |
-| L1 Buffer | 512KB | 单 AI Core | 32B | Cube 通用缓存 |
-| L0A | 64KB | 单 Cube | 32B | 左矩阵 A (m0×k0) |
-| L0B | 64KB | 单 Cube | 32B | 右矩阵 B (k0×n0) |
-| L0C | 128KB | 单 Cube | 32B | 结果矩阵 C (m0×n0)，支持累加 |
-| UB | 192KB | 单 VEC | 32B | 向量运算缓存（64 bank × 4KB） |
-
-## 计算单元
-
-### VEC（向量计算单元）
-
-- **性能**: 1 拍处理 128 Bytes 向量计算（每 AI Core 有 2 个 VEC）
-- **约束**:
-  - 数据需放入 UB (192KB)
-  - 支持连续内存或带 mask 访问
-  - 32 Bytes 对齐（UB block size）
-  - 内部按 128 Bytes 分块处理
-
-### CUBE（矩阵计算单元）
-
-- **性能**: 1 拍完成 16×16×16 FP16 矩阵乘（8192 FLOPs/cycle）
-- **支持精度**: FP16×FP16→FP16/FP32, INT8×INT8→INT32, INT4/INT2 量化
-- **工作流程**:
-  1. L0A ← 左矩阵 A (m0×k0)
-  2. L0B ← 右矩阵 B (k0×n0)
-  3. CUBE 执行矩阵乘: C = A × B
-  4. 结果写入 L0C，支持累加
-- **约束**:
-  - `m0 × k0 × sizeof(A.dtype) ≤ 64KB`（L0A）
-  - `k0 × n0 × sizeof(B.dtype) ≤ 64KB`（L0B）
-  - `m0 × n0 × sizeof(C.dtype) ≤ 128KB`（L0C）
-  - 32 Bytes 对齐
-  - 自动按 16×16 分块，尾块自动补 0 计算
-  - 支持稀疏计算（sparsity=1）
-
-### 数据类型 MKN 配置
-
-| 数据类型 | M | K | N |
-|---------|---|---|---|
-| FP16（默认） | 16 | 16 | 16 |
-| INT8/UINT8 | 16 | 32 | 16 |
-| INT4 | 16 | 64 | 16 |
-| INT2/UINT2 | 16 | 128 | 16 |
-| UINT1 | 16 | 256 | 16 |
-
-## 内存带宽（GB/s per AI Core）
-
-| 通路 | 读带宽 | 写带宽 |
-|------|--------|--------|
-| DDR (GM) | 32 | 32 |
-| L2 Cache | 110 | 86 |
-| L1 → L0A | 512 | - |
-| L1 → L0B | 256 | - |
-| L1 ↔ UB | 128 | 128 |
-| L0C → UB | 256 | - |
-| UB → L2/DDR | 64 | 64 |
-
-## 优化策略
-
-- **内存对齐**: 所有数据传输按照 32 Bytes 对齐（UB block size）
-- **数据复用**:
-  - 调整搬运顺序，让频繁访问数据缓存在 L2
-  - L1/UB 双缓冲技术: 一块计算，一块加载
-  - MTE 后台搬运与 CUBE/VEC 计算重叠
-  - L2 prefetch 可提前加载数据，减少访存延迟
-- **并行**: 20 个 AI Core 按需并行分配任务，CUBE 与 VEC 可同时执行不同任务
-- **FixPipe**: 支持 L0C→L1 和 L0C→GM 的随路量化/反量化/类型转换/ReLU/NZ→ND 变换