Freeze the bfp16ebs8 toolchain surface and probe plan (#146) - #161
Open
aravishankar-mp wants to merge 9 commits into
Open
Freeze the bfp16ebs8 toolchain surface and probe plan (#146)#161aravishankar-mp wants to merge 9 commits into
aravishankar-mp wants to merge 9 commits into
Conversation
Everything the pinned v2026.08 toolchain reveals about XDNA2's block-8 format, cited to file and line: 8-value blocks, signed 8-bit mantissas with one shared 8-bit exponent (9 bytes/block, 72-byte v64), native 8x8x8 and 8x8x16 MMUL with FP32 accumulation, conversion in through the crrnd-governed to_v64bfp16ebs8, and no conversion out except MMUL against an identity matrix. That identity construction (diagonal 1.0 = mantissa 0x40, exponent 127) is the load-bearing find: it implies int8 mantissas with 6 fractional bits under a bias-127 scale, which is exactly OCP MXINT8's element contract. If silicon confirms it, the #110 mapping hypothesis reduces to block-size decomposition alone. Also material to #145: the MX-shaped mx4/mx6/mx9 family in this AIE API is block-16 and AIE-MLv2-only. XDNA2 has no native MX type at all, so any released TOSA block-32 contract executes here through decomposition — strengthening ADR-0001's separate-labels rule. Six probes (P0-P5) turn the six extracted hypotheses into on-metal verdicts, each a backend-local precompiled artifact through the released Accelerator lifecycle, none touching TOSA admission or the serving compiler helper. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
) The first probe ran on the reference 1022:17f0 NPU through the released Accelerator lifecycle and settled four of the six hypotheses: H1 confirmed: value = m * 2^(e-133) with a two's-complement int8 mantissa and an unsigned shared exponent byte — OCP MXINT8's element contract, differing only in block size. H2 pinned: the native memory layout is the 64-byte mantissa plane then the 8-byte exponent plane; a zero block is e=0, m=0. H3 refuted as assumed: the rounding mode at kernel entry is rnd_floor, not round-to-nearest-even, so an MX-exact kernel must set rnd_conv_even explicitly. H4 sharper than hypothesized: the shared exponent is the max member's IEEE FP32 exponent (the conversion never emits m = -128 and normalizes the max member into |m| in [64, 127]), matching OCP MX v1.0's scale rule on every probed case. The probe pipeline is deliberately standalone under research/bfp16ebs8/ (kernel, IRON driver, runner with its own lockfile, preserved artifact and raw output) so the serving compiler helper stays untouched while the throughput work owns it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
All ten crrnd rounding modes match the reference bit-exactly on every lane, ties included, so round-to-nearest-even is available and exact -- it just is not the default. Post-rounding overflow renormalizes: a mantissa that rounds up to 128 bumps the shared exponent and re-quantizes, and never saturates or wraps. Normalization selects the max member's IEEE FP32 exponent field (verified through e=254), flushes all-subnormal blocks to zero, and is sign-symmetric. Inf and NaN pass through structurally at e=255 with the implicit-one (+-64) and quiet-bit (+-96) mantissa patterns; block neighbors quantize at that scale with per-block isolation. Everything observed fits one model: IEEE exponent-field max, signed 1.fraction mantissas shifted to the shared scale, crrnd rounding, post-rounding renormalization. That model becomes the P4/P5 reference. The remaining silicon questions are the MMUL contract on crafted raw planes and the block-32 MXINT8 decomposition verdict. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…146) P4 pins the matrix-unit contract with host-crafted raw planes that bypass the converter: transposed-B layout (A lane i*8+k, B lane j*8+k, C lane i*8+j, block exponent per row), and mul/mac chains over K=32 reproduce sum(m_a * m_b * 2^(e_a+e_b-266)) bit-exactly in FP32 -- including per-block exponent disagreement and mantissa -128, which the converter never emits but the matrix unit honors as -2.0. P5 answers #110 stage 1: a block-32 MXINT8 dot product decomposed into four equal-exponent block-8 groups is bit-exact against the pinned reference, and (m, e) vs (m/2, e+1) operands produce bit-identical lanes, so results depend on values rather than block normalization. Verdict recorded in the note: exact MX mapping, conditional on rnd_conv_even quantization (the hardware default is rnd_floor), on rejecting e=255 blocks (hardware Inf/NaN encodings outside MXINT8's domain), and on the tier bounding K to integer-exact FP32 accumulation, the same envelope discipline the exact INT8 tier uses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ilicon (#146) model.rs formalizes the characterization as two independent formulations: encode_v64 models the hardware converter exactly as P0-P3 observed it (max-exponent-field selection, subnormal flush, structural Inf/NaN, all ten rounding functions, post-rounding renormalization), and mxint8_quantize_block implements OCP MX v1.0 quantization from the spec. Unit tests replay the recorded silicon planes as fixtures, so the model is verifiable without an NPU; the probe runner additionally asserts live, per case, that silicon planes are bit-identical to the model -- eleven cases including a 64-element pseudorandom sweep, all passing. Two corrections the model surfaced: m = -128 is never a normalization target but floor-rounding a near-max negative member does emit it; and at exact mantissa +-127.5 an up-rounding hardware conversion renormalizes while the OCP procedure saturates, so an MXINT8 tier must quantize with the OCP procedure at that boundary. Both are recorded in the note, which now marks the issue #146 exit criteria met. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…148) The design doc pins what the prototype exposes (block-scaled MATMUL with MXINT8 semantics on the proven block-8 decomposition), the guest-visible numerical contract (bit-exact against an FP32 fold in documented ascending-k order, rather than an overclaimed order-independence), the XBFP experimental container, and the crate-integration sequencing that stays out of the concurrent #162 work until it merges. Step 1 of that sequencing is done on silicon: a K=512 flavor-1 kernel matches the fold-order oracle on all 64 output lanes, on inputs constructed so 51 of the 64 lanes distinguish the FP32 chain from a single-rounded f64 sum -- each later chunk sits just below the running accumulator's half-ULP, so only the documented per-step rounding produces the observed bits. The oracle (dot_fold_f32) rests on the fact that every block-8 MAC result is an integer times a power of two below 2^17 and hence exact in FP32, leaving the chain order as the only rounding source. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Issue #146 (part of #110), probes complete: the pinned toolchain's
bfp16ebs8surface frozen withfile-and-line citations, six hypotheses extracted from it, and all six settled by probes P0–P5 on
the reference
1022:17f0NPU. The probes are backend-local precompiled artifacts driven throughthe released
Acceleratorlifecycle by a standalone pipeline underresearch/bfp16ebs8/(kernelsources, IRON driver, Rust runner with its own lockfile, preserved artifacts and raw outputs) —
nothing touches TOSA admission or the serving compiler helper, which the concurrent #149/#151
work owns.
Verdict (#110 stage 1): exact MX mapping, with three recorded conditions:
value = m · 2^(e−133), two's-complement int8 mantissa,bias-127 shared 8-bit scale; memory layout is the mantissa plane then the exponent plane.
crrndrounding modes are bit-exact against reference, but the hardware default isrnd_floor— an MX-conformant kernel must setrnd_conv_evenexplicitly (condition 1).(never saturates or wraps), matching OCP MX v1.0's scale rule on every probed case; subnormal
FP32 inputs flush to zero.
e = 255(m = ±64/m = ±96) — outside MXINT8'sdomain, so raw-
bfp16ebs8paths must reject or canonicalize them (condition 2).mul_8x8_8x8T/mac_8x8_8x8T, transposed-B layout, FP32 accumulation)reproduces the reference dot product bit-exactly with host-crafted raw planes, including
per-block exponent disagreement, mantissa −128, and — the stage-1 hypothesis itself — a
block-32 MXINT8 operand decomposed into four equal-exponent block-8 groups. Exactness is
proven for integer-exact accumulation envelopes; a tier must bound K accordingly (condition 3).
Also material to #145: this AIE API's MX-shaped
mx4/mx6/mx9family is block-16 andAIE-MLv2-only — XDNA2 has no native MX type, so any released TOSA block-32 contract executes here
through exactly this decomposition.
Per the #146 boundary, nothing is advertised: no
Target, extension bit, capability row, orprotocol value.
Compatibility
standalone research tooling only; no published crate is touched.
Checklist
behavior.
layout.json,vectors.json,scenarios.json,requirements.json, and performance budgetsare still authoritative inputs, not regenerated by accident.
out. There are none.
probe runner is a standalone non-workspace project (
publish = false, own lockfile).unsafecode was added.Verification
On-metal evidence: probes P0–P5 run 2026-08-27 on PCI
1022:17f0rev0x20, Linux7.1.8-200.fc44.x86_64, toolchainamdxdna-hrx-v2026.08(mlir-aie 1.4.1,llvm-aie 21.0.0.2026080301+c9c5ecb7), HRX
hrx-amdxdna-2026.07.30-amdxdna-hal-native. Rawoutputs under
research/bfp16ebs8/results/, compiled probe artifacts underresearch/bfp16ebs8/artifacts/; every run is reproducible viaprobe_compile.py+ the runner(commands in
research/bfp16ebs8/probe_compile.pyand the runner's usage line).