examples(swiglu_mx_quant): CCE + VMI

[MirkoDeVita98]

swiglu_mx_quant: CCE + VMI kernel-test, cannsim cycle comparison + CCE multi-row DMA fix

Summary

Adds a swiglu_mx_quant kernel to the kernel-test framework with both a CCE
reference and a 1:1 PTODSL/VMI port (bf16 in, e4m3, OCP scale, swigluMode 0),
plus a cannsim-based cycle comparison. Along the way it fixes a real multi-row
correctness bug in the CCE reference.

Both backends are byte-exact vs the golden at every swept shape. On cannsim
cycles the two are close, with a crossover: VMI is faster at small shapes, CCE
faster at large ones.

What's included

• Kernel-test harness (kernels/swiglu_mx_quant/): spec, reference (numpy
  golden — SwiGLU silu-gate + per-32-block MX-fp8 quant + a byte-exact port of the
  CCE tiling calc), runtime, tile_config, cce/ + vmi/ backends,
  cycle_metrics.
• VMI port (vmi/backend.py, PTODSL): per-32-block MX scaling via grouped
  vcmax(group=NBLK) + vbrc(group=NBLK); e8m0/recip bit-math; vcvt f8e4m3;
  double-buffered (per-tile MTE2/MTE3 DMA overlapped with vector compute) for
  shapes with ≥2 rows/core. VEXP/VDIV op counts match CCE exactly (equal work).
• CCE reference (cce/, lifted from a5) + its bisheng CMakeLists.

CCE correctness fix

The CCE reference produced wrong output for shapes with >1 row per core
(rows > 64): a core wrote only its first row; later rows read as zero (y 72%→54%,
scale 50%→0% as rows/core grew). Root cause: copy_ubuf_to_gm_align_v2 drops all
but the first burst when nBurst>1 on this cannsim/bisheng target — hitting both
the scale and data DMAs. Fix: DmaUb2GmScale and DmaUb2GmY now issue one
nBurst=1 burst per row (UB source advances contiguously, GM dest by the row
stride). DMA-only; compute and tiling unchanged; batched tiling preserved.

Result — cannsim, bf16_e4m3_rint_ocp, all shapes now y = scale = 100%:

shape	before (y / scale)	after
128×512	72% / 50%	100% / 100%
256×512	59% / —	100% / 100%
512×1024	56% / —	100% / 100%
1024×2048	54% / —	100% / 100%

Fair cycle comparison

Both backends byte-exact. Metric = total kernel instruction span (per-core,
blkDim=64) as the cannsim wall-clock proxy; fresh consistent sweep:

shape	CCE span	VMI span	faster
64×512	5627	2038	VMI 2.76×
128×512	6668	3475	VMI 1.92×
256×512	6302	5019	VMI 1.26×
512×1024	7589	8071	CCE 1.06×
1024×2048	11857	16083	CCE 1.36×

Crossover ~256–512: VMI wins on the small shapes (fixed per-tile overhead
dominates there and VMI's pipeline is tighter), CCE wins at scale (its vector-engine
work is very compact — e.g. RVEC span 3287 vs VMI 14115 at 1024×2048 — while VMI's
span grows with the wider MX-scale vector work).

Caveats

• The nBurst>1 burst-drop is likely a cannsim limitation, not real hardware;
  on hardware the original single-multi-burst CCE DMA would work without the
  per-row-burst workaround (which adds some MTE3 overhead), so CCE's true hardware
  span could be lower. This comparison is cannsim-specific.
• RVEC/VF span is not comparable across backends (CCE __simd_vf__/bisheng
  packs vector ops differently from VMI's VPTO lowering); total instruction span is
  the fair cross-backend proxy.
• Scope: bf16 / e4m3 / OCP / swigluMode 0. fp4 (e2m1/e1m2), f16 input, and
  swigluMode 1 are not yet exercised by the VMI backend.

Reproduce

Everything runs under cannsim . Commands from
test/kernel-test/.

Env (CANN + ptoas source build):

set +u; source /usr/local/Ascend/cann-9.0.0/bin/setenv.bash   # set +u: setenv breaks under -u
export ASCEND_HOME_PATH=/usr/local/Ascend/cann-9.0.0
export ASCEND_DRIVER_PATH=/usr/local/Ascend/driver
# ptoas source build on PYTHONPATH (build/python + MLIR core python pkg + ptodsl); PTOAS_BIN -> build/tools/ptoas/ptoas
# (or use the released ptoas wheel: `ptoas` on PATH + `ptodsl` importable)
python3 -c "from ptodsl import pto; print('ptodsl ok')"

Build the CCE reference (bisheng):

cmake -S kernels/swiglu_mx_quant/cce -B kernels/swiglu_mx_quant/cce/build \
      -DASCEND_HOME_PATH="$ASCEND_HOME_PATH" -DASCEND_DRIVER_PATH="$ASCEND_DRIVER_PATH"
cmake --build kernels/swiglu_mx_quant/cce/build --target swiglu_mx_quant_cce

Correctness (byte-exact y + scale vs the numpy golden):

scripts/run_sim.sh --output sim_outputs/smx/<be>_<shape> \
  run.py -- --op swiglu_mx_quant --backend <cce|vmi> \
             --workflow correctness --case bf16_e4m3_rint_ocp_<shape>
# prints:  y_match=…% scale_match=…%   (pass gate 99%)

Cases/shapes: bf16_e4m3_rint_ocp_{64x512,128x512,256x512,512x1024,1024x2048}.

Cycles + Perfetto trace:

scripts/run_sim.sh --output sim_outputs/smx/cyc_<be>_<shape> \
  run.py -- --op swiglu_mx_quant --backend <cce|vmi> \
             --workflow cycle --case bf16_e4m3_rint_ocp_<shape>
python3 kernels/swiglu_mx_quant/cycle_metrics.py    # RVEC / span
# Chrome-trace for Perfetto (ui.perfetto.dev):
#   sim_outputs/smx/cyc_<be>_<shape>/cannsim_*/report/trace_core0.json
# total instr-span = max(ts+dur) - min(ts) over all "ph":"X" events in that trace.

[MirkoDeVita98]

Traces for 1024 x 2048:

vmi:
vmi_1024x2048_trace.json

cce:

cce_1024x2048_trace.json