Add FMA_LZA to choose an LZA or a leading zero counter for FMA normalization

[davidharrishmc]

FMA_LZA chooses how the FMA computes its normalization count: 1 (the default, set in every config) keeps the leading zero anticipator, which works in parallel with the adder; 0 counts the leading zeros of the sum instead, which is smaller but in series after the adder. The counter's count is exact, so the one-bit LZA correction in shiftcorrection never applies. fdqh_lzc_rv64gc and fdqh_lzc_rv32gc (FMA_LZA = 0) pass the testfloat add, sub, mul and fma vectors and are added to the nightly testfloat runs; the standard regression passes with the default. The PR also fixes fpu.sv's fmv.x sign mux, which indexed XE[LLEN-1] and so ran past XE once Zacas made LLEN 128, failing synthesis of rva23's rv64gc.

Impact in TSMC28 (tt 0.9 V, synthDC, rv64gc; the core is syn_sram_rv64gc, caches in SRAM macros):

	LZA (FMA_LZA = 1)	LZC (FMA_LZA = 0)
FMA alone, fastest achievable delay	0.556 ns	0.646 ns (+16%)
Normalization-count logic area (FMA alone, 300-1800 MHz targets)	550-840 µm²	180-590 µm²
Core at 850 MHz: worst slack (HPTW PTE register to D$ SRAM, both runs)	-0.065 ns	-0.057 ns
Core at 850 MHz: slack of the FMA path ending at SCnt	-0.005 ns	-0.048 ns
Core at 850 MHz: FPU / core area	36,037 / 480,956 µm²	35,414 / 480,515 µm²

The FMA's Execute path, which starts at the FP register address and goes through the operand forwarding before the FMA, is among the core's most critical paths. The LZC saves about 600 µm² of FPU (1.7%, 0.1% of the core) but uses up almost all of that path's margin, so it only pays off where the FMA has timing slack; LZA stays the default. Reproduce with make -C synthDC synth DESIGN=wallypipelinedcore CONFIG=syn_sram_rv64gc MOD=lzc TECH=tsmc28 FREQ=850 (MOD=orig for LZA); TSMC28 synthesis needs #1964 on machines whose DC setup does not define SYN_pdk.

🤖 Generated with Claude Code