[hardware] 🐛 Fix NP2 slide hang on chunk-aligned stride

[emiliengnr]

Hello, here is a pull request for a bug I found.

Problem

vslidedown/vslideup with an offset that is a whole-chunk multiple
hangs the slide unit permanently. Examples at VLEN 4096, NrLanes 2:
offset 48 or 96, or a .vi slide with a sign-extended immediate of 16
or more.

The dispatcher computes is_stride_np2 from the popcount of the full
slide offset (ara_req.stride[idx_width(VLENB << 3)-1:0]), but the
SLDU's p2_stride_gen only resolves the within-chunk part of the offset
(idx_width(8*NrLanes) bits). A pure chunk-shift has all-zero
within-chunk bits, so the generator reports popcount 0. When the full
popcount is greater than one the instruction is sent to the NP2 path,
and SLIDE_NP2_RUN waits for p2_stride_gen_popc_q == 1, which never
happens. The slide unit stalls forever with no architectural error, so
unprivileged code can wedge the accelerator.

Fix

Compute is_stride_np2 on the within-chunk offset that p2_stride_gen
actually processes (the element stride shifted down by vsew and
truncated to the generator width). Chunk-level slides then take the
regular power-of-two path.

The same variable underlies issue #340: its offset 514 = 32*16 + 2 has a
nonzero within-chunk part, so the generator still terminates but on the
wrong decomposition, giving a wrong result instead of a hang. Both cases
share this one fix.

Fixes #340

Changelog

Fixed

• Fix slide unit hang when the slide offset is a whole-chunk multiple

Checklist

• Automated tests pass
• Changelog updated
• Code style guideline is observed