MARIANA × POOL image (dual-core)

The MARIANA × POOL firmware image is the NC-v4 generation of the central general-compute engine (engine_idx = 2) — the only one of the five NX engines that ships two distinct firmware cores. This page is a cross-generation DIFF against the committed CAYMAN × POOL baseline (NC-v3); it does not re-derive the dual-dispatch two-core model from scratch — that model, the 178-slot SEQ hub, the kernel_info_table back-end, the 0xF0 reconciliation, and the 41-handler roster mechanics are all established on the CAYMAN page and are diffed here, not rebuilt. Read CAYMAN × POOL first; this page records only what changed across the v3 → v4 gap, for both cores:

1. NX_POOL — the NX-class SEQ sequencer ('S:' dialect). On MARIANA its reset vector shifts +0x1c (06 76 00 00 → 06 7d 00 00), but its handler set, opcode space, and dispatch form are unchanged — POOL already shipped the richest SEQ handler set on CAYMAN, so there was nothing to add at the SEQ layer.
2. Q7_POOL — the per-pool-core compute engine ('P%i:' dialect, kernel_info_table linear scan). Its reset vector is byte-identical to CAYMAN (no +0x1c shift), and its (opcode, spec) key set is byte-for-key identical. The one substantive v4 change lives inside the existing RNG kernel body.

The headline is the RNG arrival. The CAYMAN Q7_POOL ships the Marsaglia Xorwow software path only (Xorwow(SW)). MARIANA Q7_POOL replaces it with the Xorwow(TIE) build variant and adds a second algorithm — LFSR (LfsrGetSeeds / LfsrSetSeeds), selected by a rand_algo fork inside the kernel body — without a new SEQ handler, a new opcode, or a new kernel_info_table row. This is the firmware-image realization of the SW → TIE+LFSR RNG boundary that RNG — Xorwow TIE Path, RNG — LFSR + rand_algo Dispatch, and RNG Seed-State Ops reconstruct at the kernel level.

Confidence/evidence tags follow the project Confidence & Walls Model: HIGH/MED/LOW × OBSERVED/INFERRED/CARRIED. Every device fact is byte-pinned to a carve from libnrtucode_internal.so (sha256 b7c67e89…632fc329b) and decoded with the shipped ncore2gp xtensa-elf-objdump.

NOTE — objects used + the baseline re-carve. Container: …/custom_op/c10/lib/libnrtucode_internal.so (sha256 b7c67e898a116454a8e0ce257b1d6523a23ffa237a6ec21021ecb70632fc329b, ELF64 x86-64 DYN, not stripped). The first R LOAD is the identity map (off 0x0 == vaddr 0x0, filesz 0x9af194), so each _get.data accessor address is simultaneously the .rodata VA and the file offset: carve = so[ptr : ptr+size]. All 46 MARIANA POOL blob VAs (0x34b720…0x5a3480) fall inside this R LOAD. Disassembler: extracted/nested/gpsimd_tools_tgz/tools/XtensaTools/bin/xtensa-elf-objdump (GNU Binutils 2.34.20200201, XTENSA_CORE=ncore2gp, ConfigName Xm_ncore2gp, uarch Cairo, Xtensa24, RI-2022.9, NX1.1.4, FLIX/VLIW 32B). The CAYMAN POOL baseline was re-carved and re-hashed this session for an apples-to-apples diff — all 8 anchor sha256 MATCH the committed CAYMAN × POOL page (NX_DEBUG_IRAM 8e4412b9, NX_DEBUG_DRAM 7bdf6ed7, NX_PERF_IRAM 9049bf8c, NX_PROF_CAM 8fd7e422, NX_PROF_TABLE ce761f81, Q7_DEBUG_IRAM 513a8a22, EXTISA_0_SO 910d41c3, EXTISA_3_SO 052ac31c) — so the diff is against the authentic CAYMAN image, not a paraphrase of it. [HIGH/OBSERVED]

GOTCHA — carve the blobs, not the stubs. The getter accessor lives in .text (e.g. MARIANA_NX_POOL_DEBUG_IRAM_get at .text VA 0x9b4320), and .text carries the 0x2000 VA − file-offset delta. The blob VAs in .rodata are identity-mapped, so the carved blobs are correct as long as you carve at the IMG-PTR (.data accessor address), never the stub. [HIGH/OBSERVED]

1. The cross-gen verdict (per core)

The two cores diverge in how they absorb the generation: the NX SEQ front-end is recompiled and reset-shifted but otherwise frozen; the Q7 compute core grows the RNG kernel. No MARIANA POOL image is byte-identical to its CAYMAN counterpart (20/20 distinct — a full recompile, not a patch), yet the dispatch mechanism, reset-vector form, 0xF0 bridge, KIT key set, ErrorHandler arms, cayman/seq + dispatch.hpp source trees, and the dual-core split are all invariant. A CAYMAN ↔ MARIANA POOL swap is a recompile + the NX +0x1c reset shift + addr_bits.hpp + the Q7 Xorwow(SW)→TIE+LFSR RNG body + re-preallocated/disarmed PROF, not a model change. [HIGH/OBSERVED]

NOTE — POOL is the RNG origin, not a recipient. The cross-engine RNG migration the MARIANA × ACT / MARIANA × DVE pages document (RandGetState/RandSetState appearing on ACT/DVE this gen) runs the other direction: POOL shipped RandGetState/RandSetState as POOL-only handlers on CAYMAN; v4 keeps POOL's handlers and gives DVE/ACT copies. POOL is the origin engine for the RNG handler pair. [HIGH/OBSERVED]

2. The dual-core inventory + carve (46 getters, the SAME shape as CAYMAN)

nm libnrtucode_internal.so | rg -c 'MARIANA_(NX|Q7)_POOL_.*_get$' (excluding PLUS) = 46: 14 NX_POOL + 32 Q7_POOL, identical split to CAYMAN POOL (28 real + 18 zero-size boundary cursors). Each getter is the canonical 4-instruction (img-ptr, size) stub. [HIGH/OBSERVED]

2a. NX_POOL (CLS = NX) — 14 getters (the SEQ sequencer)

2b. Q7_POOL (CLS = Q7) — 32 getters (compute + DKL + EXTISA)

28 real carves + 12/12 spot-reconciled byte-identical (sha256 + cmp -s) to the matching libnrtucode.a member .rodata across NX/Q7/EXTISA/PROF/DKL/JSON; the internal-.so getter blob == the .a member .rodata. [HIGH/OBSERVED]

NOTE — engine ordering confirms POOL is LAST. PE PERF_DRAM ends @0x34b720 == MARIANA NX_POOL PERF_IRAM start — exactly the contiguity cursor the MARIANA × PE carve predicted. The ACT→DVE→PE→POOL layout adjacency holds; the last POOL blob (EXTISA_3_JSON end 0x59c480) precedes the PROF tables @0x5a3080. [HIGH/OBSERVED]

QUIRK — DKL_TEST is DKL_PERF (still). cmp confirms MARIANA DKL_PERF_IRAM == DKL_TEST_IRAM (8a8c927a) and DKL_PERF_DRAM == DKL_TEST_DRAM (0aaa01a7) — the same "DKL has only a DEBUG-vs-release split, no separate TEST flavor" property as CAYMAN. [HIGH/OBSERVED]

3. The reset/boot diff — the +0x1c NX-only shift

The byte-level signature that NX_POOL and Q7_POOL are two separate cores even on MARIANA, and that they absorbed the generation differently: the NX core's reset trampoline shifted, the Q7 core's did not. [HIGH/OBSERVED]

(A) NX_POOL — flat, reset SHIFTED +0x1c (the MARIANA gen change):

IRAM head (all 3 variants byte-identical): 06 7d 00 00 00 00  86 7e 00 00 00 00
  0x000: 06 7d 00   j 0x1f8       ; primary reset -> boot
  0x006: 86 7e 00   j 0x204       ; secondary    -> halt
  0x1f8: const16 a0,0 ; const16 a0,0x90 ; jx a0   -> enter_run @0x90
  0x204: halt 0
DRAM head = 34 cb 99 60                              (header word 0x6099cb34, unchanged)

CAYMAN NX_POOL was 06 76 00 (j 0x1dc) / 86 77 00 (j 0x1e8). The boot targets each moved +0x1c (0x1f8 − 0x1dc = 0x1c; 0x204 − 0x1e8 = 0x1c) — the identical +0x1c shift the MARIANA ACT/DVE/PE carves carry. [HIGH/OBSERVED]

(B) Q7_POOL (incl. DKL) — flat, reset UNCHANGED:

IRAM head (all variants): 06 7f 00 00 00 00  86 80 00 00 00 00
  0x000: 06 7f 00   j 0x200       ; primary reset -> boot   (== CAYMAN, byte-identical)
  0x006: 86 80 00   j 0x20c       ; secondary    -> halt
  0x200: const16 a0,0 ; const16 a0,0x90 ; jx a0   -> enter_run @0x90
  0x20c: halt 0

CAYMAN Q7_POOL was also 06 7f 00 (j 0x200) / 86 80 00 (j 0x20c). The Q7 compute core's reset vector is byte-identical across CAYMAN and MARIANA — the +0x1c MARIANA shift applies only to the NX SEQ core. Both trampolines still converge on enter_run @0x90. [HIGH/OBSERVED]

(C) EXTISA_0..3 SO — real EM_XTENSA ELFs, section geometry == CAYMAN; only .text grew +0x48 (EXTISA_0 .text 0x6f1e→0x6f66), absorbed within the same blob 0xa260 — that +0x48 is the new RNG-fork body. kernel_info_table @0x02000380 size 0x88 (17 entries), .globstruct @0x02000408, .bss @0x02000450 — all == CAYMAN. [HIGH/OBSERVED]

Disassembly proof (shipped ncore2gp objdump, exit 0): NX_POOL DEBUG IRAM decodes 697 entry / 908 retw; NX_POOL PERF IRAM 140 entry / 213 retw / 285 distinct IVP ops; Q7_POOL DEBUG IRAM 432 entry / 577 retw — both cores carry a full FLIX vector compute datapath (same direction as CAYMAN's 150/430). [HIGH/OBSERVED]

GOTCHA — the FLIX desync is a disassembler limit, not a finding. The flat DEBUG IRAM carries no .xt.prop FLIX property table, so densely-scheduled vector bundles desync under the linear sweep. The entry/retw and reset-vector reads are robust; per-bundle micro-op recovery inside the RNG body is MED and so flagged. [HIGH/OBSERVED for the limit]

4. The NX_POOL handler + opcode diff — STABLE (no growth)

MARIANA NX_POOL uses the same SEQ dispatch as CAYMAN — addi-normalization (the DVE form), not the raw-compare chain of PE. Both DEBUG dispatch sites decode instruction-exact and agree: [HIGH/OBSERVED]

SITE A @0x2d0f:  addi a2,a2,-65 ; movi a3,177 ; bgeu a3,a2,0x2d1b ; j 0x3075 (default) ;
                 const16 a3,8 ; const16 a3,0x800 ; addx4 a2,a2,a3 ; ...
SITE B @0x35a5:  addi a2,a2,-65 ; movi a3,177 ; bgeu a3,a2,0x35b1 ; j 0x3911 (default) ;
                 const16 a3,8 ; const16 a3,0xac8 ; addx4 a2,a2,a3 ; ...
CAYMAN  @0x2e5f:  addi a2,a2,-65 ; movi a3,177 ; bgeu a3,a2,0x2e6b ; j 0x3198 (default) ;
                 const16 a3,8 ; const16 a3,0x814 ; ...

• Normalization base 0x41 ('A') — UNCHANGED (addi a2,a2,-65 both gens). Unlike DVE (which shifted its base 0x41→0x30 this gen), POOL keeps 'A'-based normalization; the opcode space did not extend downward. [HIGH/OBSERVED]
• Bound movi a3,177 — UNCHANGED → 177-entry table, indices 0..176. NO growth — contrast PE (25→29) and DVE (opcode bound 170→187). [HIGH/OBSERVED]
• Table base relocated: CAYMAN DRAM file 0x814; MARIANA SITE A @0x800, SITE B @0xac8 (the DEBUG-segmented two-table layout). Default trampoline 0x3198→0x3075. The dispatch log "S: Dispatch opcode=0x%x" moved @0x80e38→@0x80e28 (−0x10). [HIGH/OBSERVED]

Real-vs-default count: 54 real / 123 default on BOTH gens (MARIANA default 0x3075 ×123; CAYMAN default 0x3198 ×123). Every real slot relocated, but the count and pattern are invariant (the 178-bound is 0xf2 − 0x41 + 1; 177 = the index count 0..176, 54 = the non-default slots). [HIGH/OBSERVED]

The handler diff (the structural claim):

Method (CAYMAN-page method, applied here). Extract every single-token "<glue>S: <OpName>" from each DEBUG DRAM, strip the string-pool glued-prefix byte(s), keep single-token names, sort -u, comm-diff. The glue-trap is present and was handled — observed glued prefixes: "PS: EmbeddingUpdate", "PS: EngineNop", "RS: TensorScalarAddr", "RS: TensorScalarAffineSelect", "@S: RandGetState", "@S: Rng", "TS: GetSequenceBounds", "TS: NonzeroWithCount", "VS: TensorGather". A naive ^S:-only diff is wrong; the strict glue-stripped diff gives a clean +0/−0. [HIGH/OBSERVED]

RESULT: MARIANA NX_POOL = 41 handlers; CAYMAN NX_POOL = 41 handlers; ADDED = 0; REMOVED = 0; the 41-handler set is byte-for-name IDENTICAL. [HIGH/OBSERVED]

AluOp BRANCH BranchPrefetchHint ConvLutLoad CrossLaneReduce EXT_BREAK EmbeddingUpdate EngineNop
Event_Semaphore ExtendedInst GetSequenceBounds Halt INS_BREAK INS_FL Iota LoadPoolArgument
MEMSET/RNG MOVE ModifyPoolConfig NOP NOTIFY POLL_SEM Pool RandGetState RandSetState Redirect
SB2SB_Collective SET_OM STRONG_ORDER Sort Tensor-Reduce Tensor-Scalar Tensor-Scalar-PTR
Tensor-Tensor TensorDequantize TensorGather TensorLoad TensorScalarAddr TensorScalarAffineSelect
TensorStore WRITE

= 18 shared-all-5 SEQ control core + 7 shared-with-DVE compute primitives + 16 POOL-only handlers (incl. ExtendedInst = the 0xf0 bridge, and RandGetState/RandSetState = the RNG handlers the new TIE/LFSR kernel routes into). See CAYMAN × POOL §5 for the per-token 5-way roster derivation. [HIGH/OBSERVED]

The key cross-gen finding for the NX core. POOL's SEQ handler set is the richest of the five engines and already shipped on CAYMAN with ALL the general-compute + RNG + ExtendedInst handlers. There was nothing to add at the SEQ layer this gen — so unlike PE (+PeManageSeed/MX) and DVE (+RandGet/SetState/Rand2/Sparsity/QuantizeMx/Exponential), the NX_POOL handler set is unchanged. The v4 RNG expansion lands on the Q7 compute core (§5), reached via the pre-existing RandGetState/RandSetState handlers. [HIGH/OBSERVED]

Both gens also carry the dual-mode SEQ feature ("S: NX in HW Decode mode" / "S: NX in Sunda mode: HW decode disabled"), the ErrorHandler arms ("S: ErrorHandler : Bad Opcode(0x%x)", cayman/seq/src/handlers/exception_handler.hpp), and "S: BEGIN on mariana" (vs CAYMAN's "BEGIN on cayman"). The new source header addr_bits.hpp appears on MARIANA NX_POOL (absent on CAYMAN — the gen-wide MARIANA address-rerouting header also on ACT/DVE/PE); translate_cayman+.hpp is on both gens. No mariana-4062 errata on either POOL core (that patch is DVE-specific). [HIGH/OBSERVED]

5. The Q7_POOL kernel_info_table diff + the MARIANA RNG arrival (the headline)

5a. The KIT key set — BYTE-FOR-KEY IDENTICAL across gens

Entry format (unchanged): 8-byte stride { u8 0; u8 0; u8 spec(+2); u8 opcode(+3); u32_le funcVA(+4) }; native-LE u32 key = (opcode<<24)|(spec<<16). Entry counts identical: EXTISA_0=17, EXTISA_1=1, EXTISA_2=2, EXTISA_3=9 on both gens; the (op,spec) key set is equal in every EXTISA (added=[] removed=[] for all four). The full MARIANA EXTISA_0 table — funcVAs are pure monotonic relocation (+0x0 at low addresses growing to +0x44 at high, the +0x48 .text growth distributed across the function layout); no re-routing, no new entry: [HIGH/OBSERVED]

EXTISA_3 (the cptc/MX family, 9 entries): keys == CAYMAN, funcVAs moved; idx7 0xe4/0 @0x01002260 (the cptc dispatcher), idx8 0xf0/spec7 @0x01003b74 (cptc extended path). The cptc_decode_impl<1..6> DTYPE-selected family lives here, byte-for-name identical on both gens. EXTISA_1 = 1 entry (0x7e iota); EXTISA_2 = 2 entries (0x7c, 0x7d). [HIGH/OBSERVED]

5b. The kernel-body diff — the RNG (the SOLE substantive Q7 change)

Q7_POOL DEBUG DRAM 'P%i:' broad-token set-diff (CAYMAN vs MARIANA): [HIGH/OBSERVED]

ADDED on MARIANA  : Xorwow(TIE) (Init), XorwowRng(TIE), XorwowGetSeeds(TIE),
                    XorwowSetSeeds(TIE), LfsrGetSeeds, LfsrSetSeeds
REMOVED on MARIANA: Xorwow(SW) (Init), XorwowRng(SW), XorwowGetSeeds(SW), XorwowSetSeeds(SW)

Both gens carry "P%i: RandGetState : num_chans = %0d : rand_algo = 0x%x" and the matching RandSetState; "P%i: Decode : ExtendedInstRandGetState" / "…RandSetState"; "P%i: ExtendedInstRand{Get,Set}State : num_tensor_elements = %d". The 'Decode :' kernel-dispatch list (8 names: ExtendedInstCopy, ExtendedInstCptcDecode, ExtendedInstRandGetState, ExtendedInstRandSetState, ExtendedInstTensorTensorArith, GetSequenceBounds, SB2SB_Collective, Sbuf2Sbuf) is identical — ADDED=0, REMOVED=0 at the dispatch-name layer. RNG is the only substantive Q7 change. [HIGH/OBSERVED]

The arrival, reconciled. On CAYMAN POOL the only RNG is the Marsaglia Xorwow software path (Xorwow(SW)). On MARIANA POOL that same Xorwow became the (TIE) build variant AND a second algorithm — LFSR — was added (LfsrGetSeeds/LfsrSetSeeds). Both are reached through the same RandGetState/RandSetState handlers (NX SEQ side) and the same 0xf0-spec3/4 kernel_info_table rows (Q7 side) — the algorithm is selected by the rand_algo fork inside the kernel body, not by a new opcode or a new table entry. This is exactly why the KIT key set is unchanged (5a) yet the Q7 IRAM grew +0x300 (DEBUG): the new LFSR-fork + TIE-variant body was compiled into the existing RandGetState/RandSetState kernel. [HIGH/OBSERVED for the string boundary]

CORRECTION — the additions are an internal fork, NOT new table rows. A first-pass hypothesis expected the RNG arrival to show up as new opcode→funcVA rows. The observed reality is the opposite: the KIT (op,spec) key set is byte-for-key identical across gens; the additions live inside the existing kernel body behind the rand_algo selector. The image-level boundary is therefore "new kernel body", not "new dispatch row". [HIGH/OBSERVED]

5c. The rand_algo fork, as annotated C (the NEW RNG dispatch)

The fork the new MARIANA kernel body adds is reconstructed in RNG — LFSR + rand_algo Dispatch: the full ISA enum is NEURON_ISA_TPB_RAND_ALGORITHM { LFSR=0, PCG32=1, PHILOX=2, XORWOW=3 }; POOL wires exactly two of the four (LFSR(0) and XORWOW(3)); PCG32(1)/PHILOX(2) hit the SEQ "rand_algorithm(0x%x) not currently supported on POOL" arm. The fork is a single bbci in the shared SetSeeds body, driven by a saltu(rand_algo, 1) comparison; there is no separate LfsrRng function and no LFSR opcode — the per-draw advance is shared with the Xorwow(TIE) driver @0xbc78; only the seed init differs (LfsrSetSeeds @0xb700 vs XorwowSetSeeds(TIE) @0xb744). The C below models that fork — this is the new logic the MARIANA Q7 body contains; the surrounding RandGetState/RandSetState decode path is unchanged from CAYMAN:

/* MARIANA Q7_POOL — the NEW rand_algo fork inside the RandSetState kernel body.
 * Reached via the UNCHANGED 0xf0-spec3/4 kernel_info_table rows (§5a) and the
 * pre-existing RandSetState handler (§4). The fork is the v4 RNG arrival: a SECOND
 * algorithm (LFSR) and the (SW)->(TIE) Xorwow build variant. ISA enum:
 *   NEURON_ISA_TPB_RAND_ALGORITHM { LFSR=0, PCG32=1, PHILOX=2, XORWOW=3 }.       */

typedef enum { RAND_LFSR = 0, RAND_PCG32 = 1, RAND_PHILOX = 2, RAND_XORWOW = 3 } rand_algo_t;

void pool_rand_set_seeds(rand_algo_t rand_algo, const rng_seed_t *seed, rng_state_t *st) {
    LOG("P%i: RandSetState : num_chans = %0d : rand_algo = 0x%x", cpu_id, num_chans, rand_algo);

    /* POOL wires ONLY LFSR(0) and XORWOW(3). PCG32/PHILOX are ISA-defined but rejected
     * at the SEQ front-end ("rand_algorithm(0x%x) not currently supported on POOL").    */
    if (rand_algo != RAND_LFSR && rand_algo != RAND_XORWOW)
        return reject_unsupported_algo(rand_algo);          /* SEQ-side arm */

    /* The fork: a single bbci on the rand_algo bit (saltu(rand_algo,1) resolves the
     * 4-value enum down to the two POOL wires). NEW on MARIANA; absent on CAYMAN.        */
    if (rand_algo == RAND_LFSR) {
        /* NEW second algorithm. One u32 word per lane (vs Xorwow's 5-6 words):
         * no memset, no multi-word chain, no Weyl const — frame 192, one FLIX bundle.   */
        lfsr_set_seeds(seed, st);                            /* @0xb700 — NEW on MARIANA */
    } else { /* RAND_XORWOW */
        /* The (SW)->(TIE) build variant: same 5 Marsaglia seeds, byte-identical Weyl
         * const, same DRAM-scratch state model — recompiled under the (TIE) label.       */
        xorwow_set_seeds_tie(seed, st);                      /* @0xb744 — (TIE) on MARIANA */
    }
    /* Per-draw advance is SHARED by both algorithms (only seed init differs).            */
    /* ... advance driver @0xbc78 (XorwowRng(TIE) body) ...                               */
}

NOTE — (TIE) is a build label, not a HW instruction. Per RNG — Xorwow TIE Path, the shipped ncore2gp ISA decode tables contain zero rng/xorwow/lfsr opcode and zero RNG state register; the (TIE) suffix is a generation/build variant label on the same software Xorwow kernel. This page establishes only the firmware-image presence boundary: Xorwow(TIE) + LfsrGet/SetSeeds first appear on the MARIANA Q7_POOL image. The internal fork register is MED, cited from the LFSR-dispatch page. [HIGH/OBSERVED for presence; MED for the exact fork slot]

The seed-state opcodes themselves are gen-stable: 0x77 RAND_GET_STATE / 0x78 RAND_SET_STATE are flagged maintained (// Y) in every gen's aws_neuron_isa_tpb_common.h (mariana L215/216 vs cayman L210/211), each a 64-byte operand struct (D4_RAND get / S1_RAND set, dtype == UINT32) — see RNG Seed-State Ops. The opcodes did not change; the kernel they advance gained the second algorithm. [HIGH/CARRIED from the RNG pages]

The Q7 dispatcher infra is invariant ("P%i: Entering/Exiting Dispatch", "P%i: In dispatch, CPU ID…got opcode 0x%x", "P%i: UNKNOWN OPCODE=0x%x" / "…UNKNOWN EXTENDED OPCODE=%d", source dispatch.hpp): the linear scan by packed (spec,opcode) key, partitioning by get_cpu_id() across pool channels — see CAYMAN × POOL §4b. [HIGH/OBSERVED]

6. The 0xF0 ExtendedInst bridge — UNCHANGED + the dtype/MX footprint

The 0xF0 bridge registers across both cores on MARIANA, unchanged. [HIGH/OBSERVED]

• SEQ side (NX_POOL): index 0xf0 − 0x41 = 0xaf = 175; slot @table + 175·4 reads 0x306d (MARIANA) / 0x3190 (CAYMAN) — both REAL handlers, distinct from the default trampoline (MAR 0x3075, CAY 0x3198). "S: ExtendedInst" present in NX_POOL DRAM both gens (@DRAM file 0x26e5 MARIANA) — POOL-exclusive (the only engine with the bridge).
• Q7 side (EXTISA_0): the five 0xf0+spec rows (specs 0,1,2,4,3) present byte-for-key on both gens (idx 6–10; funcVA relocated +0x20/+0x30). The two-level (opcode<<24)|(spec<<16) escape is structurally invariant; the spec byte sub-selects exactly one of the five rows; there is no third dispatch level.

POOL remains the only engine with both the SEQ 0xf0 bridge and a Q7 compute core — which is exactly why only POOL has the dual-dispatch. The 0xF0 reconciliation is identical to CAYMAN; see CAYMAN × POOL §4c and POOL Extended-Opcode (0xF0) Dispatch. [HIGH/OBSERVED]

dtype / MX footprint: [HIGH/OBSERVED]

• NX_POOL: FP4/CPTC/MXTENSOR/SFP8/fp8_e do not appear as named strings (grep = 0). The only dtype constants are NEURON_ISA_TPB_DTYPE_{UINT32,INT32,FP32} (move.cpp assertion) — byte-identical to CAYMAN. New dtype codes are numeric in the decode path, not named strings (same negative as ACT/DVE/PE).
• Q7_POOL: the MX dequant footprint is present (proc_4bit_mx_8, proc_4bit_non_mx, proc_6bit_non_mx, "Unimplemented dequant format", "unsupported in_dtype/out_dtype for cptc_decode", cptc_decode_impl<1..6>) — but it is byte-for-name IDENTICAL on both gens. The MX/CPTC dequant path is pre-existing on CAYMAN POOL, not a MARIANA addition. POOL has no QuantizeMx handler (that is a DVE handler, gained by DVE this gen); POOL's MX lives in TensorDequantize/cptc, present since CAYMAN. So the MARIANA FP4/MX expansion leaves no new POOL firmware footprint.

7. DKL, PROF, and the dtype/size deltas

DKL — structurally invariant. MARIANA DKL DEBUG DRAM carries the same symbols as CAYMAN: dynamic_kernel_dispatch, dynamic_extended_op_kernel_dispatch, .kernel_info_table, dispatch_wrapper.hpp, "P%i: Corrupted prelink library; NULL start symbol", and "P%i: CustomOps not supported on Cayman". The DKL build also carries the MARIANA TIE+LFSR RNG (LfsrGet/SetSeeds, Xorwow(TIE)). DKL_PERF == DKL_TEST byte-identical (§2b). See External-Library / Prelink Loader. [HIGH/OBSERVED]

QUIRK — "CustomOps not supported on Cayman" survived into MARIANA. The CAYMAN-named source string was not updated for MARIANA — a build-string artifact; the dynamic custom-op path remains gated off. [HIGH/OBSERVED]

PROF — re-preallocated + DISARMED + now per-engine. On CAYMAN all four NX engines shared one 47-record CAM (8fd7e422). On MARIANA POOL the CAM is per-engine and essentially zeroed: [HIGH/OBSERVED]

The CAYMAN shared-CAM property did not survive the generation: PROF is now per-engine, and POOL specifically got a disarmed CAM (contrast MARIANA PE's re-armed 22 PE-specific records). Q7_POOL ships no PROF. (PROF_TABLE field schema not decoded — MED.) See PROF CAM/TABLE Formats. [HIGH/OBSERVED]

CORRECTION — "disarmed" is precise, "0 records" is not. CAYMAN POOL's shared CAM holds 46 real opcode-capture records (enable==1, mask=0xff) plus one trailing null-opcode sentinel (enable==1, opcode=0, mask=0) → a strict enable==1 count of 47. MARIANA POOL's CAM keeps only that same null sentinel (1 strict enable==1, mask=0) and zero real opcode-capture records (mask≠0). So the literal enable==1 count is 1, not 0 — the CAM is "disarmed" because no real capture record is armed, not because the byte is wholly zero. [HIGH/OBSERVED]

Size / sha deltas — 20/20 distinct (full recompile). No MARIANA POOL image is byte-identical to its CAYMAN counterpart. The directional split is the signature of the diff: NX_POOL IRAM SHRANK (the tighter v4 compile), Q7_POOL IRAM GREW (the new TIE/LFSR RNG body): [HIGH/OBSERVED]

The DEBUG/PERF/TEST observability split is invariant (only DEBUG carries the runtime logs: NX 177 S: / Q7 158 P%i:; PERF/TEST strip them); the dispatch mechanism is unchanged across builds. [HIGH/OBSERVED]

8. Adversarial self-verify (the 5 strongest claims, re-challenged)

1. The RNG arrival (the headline). Challenge: is Xorwow(TIE)/LFSR really NEW vs CAYMAN, not a string already present on CAYMAN under a different glue? Re-check: Q7_POOL DEBUG DRAM 'P%i:' set-diff (broad token, both carves this session) — MARIANA ADDS Xorwow(TIE), XorwowRng(TIE), Xorwow{Get,Set}Seeds(TIE), LfsrGetSeeds, LfsrSetSeeds; REMOVES the four (SW) variants. CAYMAN Q7_POOL carries Xorwow(SW) only and zero Lfsr/(TIE) tokens. Corroborated structurally by Q7 IRAM growth +0x300 (DEBUG) and the EXTISA_0 .text +0x48 — the new fork body has a byte cost. PASS. [HIGH/OBSERVED]
2. The +0x1c reset shift. Challenge: is 06 7d vs 06 76 a real +0x1c boot-target shift, not a coincidental opcode byte? Re-check: j 0x1f8 (MARIANA) − j 0x1dc (CAYMAN) = 0x1c; secondary j 0x204 − j 0x1e8 = 0x1c; both still land enter_run @0x90; the +0x1c matches the MARIANA ACT/DVE/PE carves. PASS. [HIGH/OBSERVED]
3. Per-core handler/table deltas. Challenge: is the NX 41==41 a glue-trap artifact, and is the Q7 key set really unchanged? Re-check: the glue-stripped diff (10 documented glued prefixes PS:/RS:/@S:/TS:/VS:) gives +0/−0; the KIT (op,spec) key set is added=[] removed=[] for all four EXTISA, funcVAs pure monotonic relocation +0x0..+0x44. PASS. [HIGH/OBSERVED]
4. The 0xF0 bridge across both cores. Challenge: does the SEQ 0xf0 slot still point to a REAL handler (not the default), and do the five Q7 rows survive? Re-check: SEQ slot 0x306d ≠ default 0x3075; "S: ExtendedInst" present; Q7 five 0xf0+spec{0,1,2,4,3} rows byte-for-key. The two-level escape is structurally invariant. PASS. [HIGH/OBSERVED]
5. The size/sha deltas. Challenge: is the diff a recompile or a patch — and is the baseline authentic? Re-check: 20/20 images distinct from CAYMAN; the CAYMAN baseline was re-carved and 8/8 anchor sha256 MATCH the committed page; the directional split (NX shrank / Q7 grew) is internally consistent with the RNG-body cause. PASS. [HIGH/OBSERVED]

9. Honesty ledger

HIGH / OBSERVED (reproduced this session):

• 46 getters parsed instruction-exact (14 NX + 32 Q7; 28 real + 18 cursors); 12/12 spot-reconciled to libnrtucode.a member .rodata; CAYMAN baseline 8/8 anchors MATCH the committed page.
• Both reset vectors: NX 06 7d 00 (j 0x1f8, +0x1c) / Q7 06 7f 00 (j 0x200, unchanged); both → enter_run @0x90. EXTISA .text +0x48.
• NX dispatch: addi a2,a2,-65 (base 0x41, no shift) + movi a3,177 (no growth) both sites; 54 real / 123 default both gens; default tramp 0x3198→0x3075; table base 0x814→0x800/0xac8.
• NX handler diff 41==41 (+0/−0, glue-trap documented); Q7 KIT key set byte-for-key identical (17/1/2/9; funcVA pure relocation); 0xf0 bridge intact (SEQ slot real both gens; Q7 five rows).
• Q7 RNG diff: ADDED Xorwow(TIE)+LfsrGet/SetSeeds, REMOVED Xorwow(SW); rand_algo selector both gens; the SOLE substantive Q7 change.
• MX/CPTC footprint identical both gens (pre-existing on CAYMAN); NX dtype only UINT32/INT32/FP32.
• PROF disarmed + per-engine (8fd7e422→0951b326, 0 armed); DKL invariant, DKL_PERF==DKL_TEST.
• Size 20/20 distinct (NX IRAM shrank, Q7 IRAM grew).

MED / INFERRED:

• The exact internal rand_algo fork register/slot selecting LFSR vs Xorwow (the fork EXISTS — rand_algo string both gens; the additions are internal, not new rows). Direction HIGH; exact slot CARRIED from RNG — LFSR Dispatch.
• The 0xf0 specs 3/4 → {RandGetState, RandSetState} binding (specs 0/1/2 HIGH; 3/4 route via shared decode_pool, MED).
• PROF "disarmed" = 0 enable==1 records (record-shape INFERRED-HIGH); PROF_TABLE field schema.
• engine_idx = 2 computed at boot (from the boot-identity string + corpus CSR enum POOL=2).

LOW / NOT CLAIMED: which silicon/runtime selects MARIANA vs MARIANA_PLUS (reported byte-identical POOL ucode — a gen-label distinction; not carved here, see MARIANA+ × POOL); DEBUG/PERF/TEST/DKL selection; the exact per-kernel operand layout of the new TIE/LFSR RNG body (per-kernel scope; the RNG pages cover the algorithm).

10. Cross-references

• CAYMAN × POOL — the diff baseline (the dual-core model, the 178-slot SEQ hub, the 41-handler derivation, the KIT format, the 0xF0 reconciliation).
• MARIANA+ × POOL — the v4+ POOL image (reported byte-identical ucode).
• Image Catalog Index — the getter map; the MARIANA POOL rows 327–384.
• RNG — Xorwow TIE Path — the (TIE) build variant (the headline RNG arrival).
• RNG — LFSR + rand_algo Dispatch — the new second algorithm + the rand_algo fork ({LFSR=0, PCG32=1, PHILOX=2, XORWOW=3}).
• RNG Seed-State Ops — 0x77/0x78 get/set state.
• kernel_info_table Binary Layout — the 8-byte record / packed-key format.
• POOL Extended-Opcode (0xF0) Dispatch — the spec sub-dispatch.
• External-Library / Prelink Loader — the DKL layer.
• PROF CAM/TABLE Formats — the now-per-engine profiling resource.
• Sibling MARIANA engines: × ACT, × DVE, × PE.