et-backend: F16 vecdot GEMV + matrix-engine GEMM

[RehanQasim-dev]

Overview

Improves the ET backend's F16 MUL_MAT path for both decode (GEMV) and prefill (GEMM):

GEMV (decode, N <= 2): Stripes output elements across every hart of all 32 shires instead of blocking work into 16-element chunks, which only filled 8 shires for a typical decode GEMV. Adds a register-resident f16 row-dot helper and stages the reused B activation vector into per-shire L2 SCP so it survives weight-matrix streaming.

GEMM (prefill, N > 2): Adds a double-buffered weight-reuse F16 matrix-engine kernel with L1 activation double-buffering and software L2 prefetching, achieving 5.25 TFLOPS.

Also fixes the MUL_MAT dispatch check for F16, which compared src1->ne[0] (K) instead of src1->ne[1] (N) and so never actually distinguished decode from prefill when activations are F16-typed. Dispatch now routes N <= 2 to the vecdot GEMV kernel and N > 2 to the matrix-engine GEMM kernel.

Additional information

Performance (Llama-3.2-1B-Instruct FP16, ET-SoC-1):

Prefill t/s

N	et	optimized	speedup
100	38.88	74.75	1.92x
220	40.17	76.47	1.90x
512	39.13	74.55	1.91x
700	39.19	74.56	1.90x
900	39.10	74.31	1.90x

Verified with llama-bench on ET-SoC-1 hardware (Llama-3.2-1B-Instruct FP16), comparing this branch ("optimized") against unmodified et ("et") at the same prompt sizes used in the Q4_0/Q8_0 matrix-engine PRs.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES - the optimization strategies and design decisions are my own. AI assisted with understanding the hardware reference manual, some pieces of code implementation and guided debugging. I have thoroughly reviewed the code.