Function tensor_load_b 

pub unsafe fn tensor_load_b(
    addr: usize,
    rows: u8,
    coop: bool,
    stride: u64,
    id: bool,
)

Initiate an asynchronous TensorLoadB from memory into the TenB register file.

Loads rows + 1 consecutive rows of 64 bytes each from memory into the dedicated TenB buffer. This forward-pairs with the next tensor_fma32 call that uses tenb = true; the FMA waits internally for the load to complete, so no explicit tensor_wait is needed between LoadB and FMA.

Parameters

• addr: 64-byte aligned virtual address of the first B row in memory.
• rows: B rows to load minus one (ACOLS of the subsequent FMA, 0..=15).
• coop: set for cooperative multi-hart loading (advanced; leave false).
• stride: row stride of B in bytes (64-byte aligned); placed in x31.
• id: load event identifier placed in bit 0 of x31 (false = Load0, true = Load1). Use Load1 when a tensor_load with id: false is also in flight, so that tensor_wait(Load0) waits only for the A tile and not for the B DMA (which forward-pairs with the FMA anyway).

Note: TenB path has no hardware interleave variant

The TenB register-file path (xs bit 52 = 1) does not support hardware interleaving of consecutive fp16 rows. B must be pre-packed host-side into the 2-row-interleaved layout that FMA16A32 expects before upload. tensor_load_interleave16 (xs bits 61:59 = 010, xs bit 52 = 0) interleaves from plain row-major fp16 in DRAM into the L1 scratchpad, but it targets the scratchpad path only, not the TenB register file; there is no interleave variant for the TenB path.

Safety

Same alignment and primary-hart constraints as tensor_load.