Implement Zfbfmin BF16 converts

[davidharrishmc]

Adds the two Zfbfmin scalar instructions, fcvt.bf16.s and fcvt.s.bf16, and enables the extension on rv32gc and rv64gc.

Approach

BF16 shares single precision's sign bit, 8-bit exponent field and bias, differing only in fraction width (7 vs 23). Both converts therefore run down the existing single precision convert path — fcvt feeding the postprocessor — rather than becoming a format of their own:

• A BF16 source is widened to single before the unpacker ({bf16, 16'b0} is bit-identical to the single value), so unpackinput is untouched.
• A Bf16Dst flag swaps the fraction width where the rounder needs it.
• Because the fraction is genuinely rounded to 7 bits, a BF16 result is the top half of the single precision result, so specialcase packs it with a rebox rather than seven per-field overrides.

Fmt/OutFmt stay at single throughout, which is what keeps this cheap: the exponent datapath, flags.sv and the overflow/underflow thresholds are all correct with no changes at all.

Cost

118 insertions, 32 deletions across 20 files. What is added:

• round.sv (24+/5−) — guard/round/LSB, sticky and RoundAdd, each folded into the signal where it is defined, so the hand-unrolled per-format logic is untouched and every consumer reads one signal. Load-bearing: without rounding at 7 bits the rebox would be a truncation.
• specialcase.sv (27+/11−) — the single precision result reboxed to BF16 on the way out, plus the underflow result, whose single precision LSB the rebox would otherwise drop.
• cvtshiftcalc.sv (6+/1−) — the underflow threshold, -7 for BF16 against -23 for single.
• unpack.sv (11+/1−) — one mux widening a BF16 source.
• fcvt.sv (10+/3−) — one extra input to an adder that already sums three terms.

No new wide muxes on the result path and no added logic depth: Guard is format-mux to BF16-mux to CvtToInt-mux either way, and RoundAdd is mux-then-adder either way. This is a gate-level argument, not a synthesis result.

Each BF16 case sits with the signal it belongs to rather than at the point of use: ResNegNF, NormSticky, FpGuard, FpLsbRes, FpRound and RoundAdd each feed a Dst-prefixed signal that accounts for BF16, so CvtResUf, Sticky, Guard/LsbRes/Round and the final rounding add are unchanged from master and a future second consumer of any of those signals gets BF16 for free. The sticky bit is the one value that cannot come from a format arm: those ranges are nested, so a fifth fraction width moves every boundary in each FPSIZES/XLENPOS variant.

Subnormal convert fix

Routing these through fcvt exposed a latent bug in shared logic, fixed here in the same commit.

When a subnormal source produces a subnormal result, LeadingZeros normalizes the significand but ShiftAmt = NF-1+Ce never undoes it, so the fraction lands mis-aligned. Concretely for single 0x007fffff: the unpacked Man has hidden bit 0, LeadingZeros is 1, Ce is 0, and shifting by 51 leaves the zero hidden bit at the top of Mf, so the fraction reads back as 0x3F8000 instead of 0x7F0000.

That combination is only reachable for a same precision convert — narrowing flushes a subnormal source to zero (a subnormal double is ~2^-1022, far below single's 2^-149 minimum) and widening turns one into a normal — and fctrl rejects Rs2D[1:0] != 2'b00. BF16 against single is the first case with equal exponent ranges, which is why this has lain dormant.

The fix adds LeadingZeros back into ShiftAmt on the subnormal branch. No condition is needed: LeadingZeros is already zero for a normal source, since the leading zero count runs on the mantissa including the hidden bit.

Encodings

From binutils' own test (gas/testsuite/gas/riscv/zfbfmin.d), confirmed by assembling and disassembling:

instruction	funct5	fmt	rs2
fcvt.bf16.s	01000	10	01000
fcvt.s.bf16	01000	00	00110

Testing

riscv-arch-test against Sail-generated signatures on the RTL. The wider runs are what cover the shared ShiftAmt change, exercising the existing F/D/Zfh/Zfa converts:

suite	config	result
Zfbfmin	cvw-rv64gc / cvw-rv32gc	All 6 pass, both
F, D, Zfh, Zfhmin, Zfa, Zfbfmin	cvw-rv64gc	All 297 pass
F, D, Zfh, Zfhmin, Zfa, Zfbfmin	cvw-rv32gc	All 279 pass

Verilator lint clean on rv64gc, rv32gc and rv32i — no errors, no new warnings.

Requires the companion riscv-arch-test change enabling Zfbfmin on the cvw configs (riscv/riscv-arch-test#2379).

🤖 Generated with Claude Code

[davidharrishmc]

Still in review. Do not yet merge.

[davidharrishmc]

Ready for review.

[davidharrishmc]

Simplifications added thanks to @kparry4