gen-verilog: slice params ([]T) lower to single scalars — mac_dot_product is silently wrong for len>1

[gHashTag]

Found while growing the conformance vvp registry (#2241): fn mac_dot_product(a: []TernaryWord, b: []TernaryWord, len, unit) lowers to 'input [31:0] a; input [31:0] b;' — the slice becomes ONE word, so the loop's per-element access indexes bits of a scalar and the function is semantically wrong for any len > 1 (the vector cases use len 2). Same class as the historical 'array-param indexing read 1 bit' defect (#1748), but for slice-typed params, which never got the packed-vector treatment. The two remaining mac vector groups (mac_dot_product, mac_matrix_vector) stay as NAMED debt in the registry until slices lower as packed vectors with part-select indexing; executing them today would fail on a known unimplemented feature rather than a regression. Refs #2241.

[gHashTag]

Blast radius measured before any attempt: 2,313 slice-param occurrences across 237 specs. A lowering change is therefore a corpus-wide semantic decision (packed vector with a declared cap vs a length-carrying convention), not a patch — and every choice shifts generated output for a third of the corpus (seal drift + regression surface). Recommendation for the near-term: spec-level fixed-arity wrappers where a single test needs unblocking (mac's last self-test test), and the language decision for []T-in-hardware goes to the owner. Current state after the three self-contained fixes (#2412 plumbing, #2416 len-fold, #2418 residual-skip): mac self-test is at 5 elaboration errors, ALL from the one slice-dependent test — this issue is the single remaining blocker of full spec self-testing for elaborating modules.

[gHashTag]

Precedent worth having before deciding []T semantics. Verified from Chisel's documentation: a Vec's size is fixed at elaboration, and the language warns when a dynamic index is not log2(size) wide — i.e. the SIZE is always a compile-time property, and only the index is runtime (chisel-lang.org, Bundles and Vecs / Warnings). My reading, not a citation: SpinalHDL's Vec(T, n) and Amaranth's array layouts behave the same way; none of the three ecosystems has a port whose element count is unknown at elaboration.

That maps cleanly onto what this repo already has. [N]T with a constant N is the supported form, and since #2402 the N may be a CONST NAME (the symbolic-dimension resolver), so [NUM_MAC_UNITS]MACUnit now lowers correctly. The gap is only the unsized []T / [T] spelling, which has no HDL analogue as a port.

So the cheapest resolution consistent with every neighbouring language is: reject unsized array params in Verilog-reachable functions at typecheck, naming the function and the parameter, and point the author at [N]T. The corpus measurement I posted earlier (2,313 occurrences across 237 specs) is the migration cost — but the fpga-reachable subset is far smaller: the unsized-param reads currently costing elaboration errors are changes_timestamp_ps (5), paths_total_delay_ps (2) and a few siblings. mac_dot_product and mac_matrix_vector — the two vector groups still unexecuted — are in that same small set.