First passed test

research/.xh1/runs/20260825T182220Z/attempts

@@ -0,0 +1,8 @@
+2026-08-25T18:23:29Z	research/03-core-design/mul-div-unit.md	1	research	completed
+2026-08-25T18:24:04Z	research/03-core-design/mul-div-unit.md	1	review	VERDICT: FAIL
+2026-08-25T18:25:16Z	research/03-core-design/mul-div-unit.md	2	revision	completed
+2026-08-25T18:25:49Z	research/03-core-design/mul-div-unit.md	2	review	VERDICT: FAIL
+2026-08-25T18:27:01Z	research/03-core-design/mul-div-unit.md	3	revision	completed
+2026-08-25T18:27:36Z	research/03-core-design/mul-div-unit.md	3	review	VERDICT: FAIL
+2026-08-25T18:28:54Z	research/03-core-design/mul-div-unit.md	4	revision	completed
+2026-08-25T18:29:42Z	research/03-core-design/mul-div-unit.md	4	review	VERDICT: FAIL

research/.xh1/runs/20260825T182220Z/failed

@@ -0,0 +1 @@
+research/03-core-design/mul-div-unit.md

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.current.md

@@ -0,0 +1,387 @@
+# Multiply/Divide Unit Design for the XH-1 Processor
+
+## Status
+
+**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions. Quantitative comparisons are presented only as qualitative relative magnitudes, never as benchmark figures. Throughout this document, claims are tagged as one of:
+
+- **FACT** — well-established in the cited literature or in the RISC-V ISA specification.
+- **TYPICAL** — the common case across published designs; implementation-specific values may vary.
+- **ASSUMPTION** — an explicit premise the analysis depends on; should be revisited.
+- **PROPOSAL** — a design recommendation conditional on unresolved parameters.
+- **INSUFFICIENT EVIDENCE** — no defensible claim can be made without additional information.
+
+## Abstract
+
+This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt dividers, Newton-Raphson dividers, subtractive dividers, and SRT dividers) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so any recommendations are conditional on those upstream decisions.
+
+## Research Question
+
+> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?
+
+Specifically:
+
+- How should the unit be pipelined relative to the rest of the core?
+- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports, FP multiplier) or remain isolated?
+- How should division throughput be traded against area and verification cost?
+- What is the impact of the choice on multi-core contention for shared execution resources, if any?
+
+## Background
+
+**FACT.** The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:
+
+- `MUL` (lower 64 bits of signed × signed)
+- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
+- `DIV`, `DIVU` (signed/unsigned quotient)
+- `REM`, `REMU` (signed/unsigned remainder)
+
+Critical properties of this ISA slice that drive microarchitecture:
+
+- **Wide-operand upper-multiply (UMUL).** **TYPICAL.** In a single full-width partial-product / carry-save array, the 64×64→128-bit product is generated by the same array that produces the 64×64→64 product; the carry-save adder tree is slightly deeper and wider, and a final carry-propagate adder is needed to collapse the upper half. The incremental cost of supporting `MULH*` is therefore a small area adder and routing for the upper output, not a doubling. *Caveat: specific silicon area deltas are design-dependent; the "share the array" pattern is the common case in published RV64 implementations (e.g., BOOM, XiangShan, some SiFive designs), but quantitative numbers are not asserted here.* **FACT.** Rocket Chip keeps the integer multiplier and the FP multiplier as separate units rather than sharing the array; the document's earlier blanket attribution of sharing to "Rocket, BOOM, and most SiFive cores" overstates the case and is corrected here.
+- **MULH and signed×signed handling.** **FACT.** `MULH` (signed×signed, upper half) is not obtained by simply reusing the unsigned 64×64→128 array with sign-corrected operands. The standard technique is Baugh-Wooley or Modified Booth with explicit sign-bit handling, which modifies the partial-product generation (sign-extension of the most-significant partial products) and the adder tree. The "essentially free" characterization sometimes seen is oversimplified: while the underlying adder tree is shared, the partial-product array and the final CPA differ for the signed case, and verification must treat `MULH` as a distinct datapath.
+- **MULHSU and signed×unsigned handling.** **FACT.** `MULHSU` is also not a vanilla 65×64 unsigned array. The signed operand's most-significant partial product must be sign-handled (Baugh-Wooley-style sign extension of the MSB partial product, or Modified Booth encoding with explicit sign control) so that the upper 64 bits of the result are correct. The incremental verification cost over `MULHU` is small once the unsigned array is in place, but `MULHSU` is not "free" in the strict sense; it requires its own sign-handling pass and must be verified against a reference for all sign combinations.
+- **Division latencies.** **FACT.** A restoring or non-restoring subtractive divider on 64-bit operands requires exactly 64 reduction steps (or 65 with a sign pre-correction step). A radix-2 SRT divider also requires 64 selection steps in the worst case (with possible skipped steps on average, but the worst case governs the pipeline). A radix-4 SRT divider requires 16 selection steps in the worst case, plus a final quotient-conversion step (carry-save to two's-complement), not an extra selection step. **TYPICAL.** These counts dominate pipeline depth if the divider is fully combinational; iterative implementations amortize them over many cycles.
+- **Signed semantics.** **FACT.** RISC-V specifies the following for division edge cases:
+  - Division by zero: `DIV` and `DIVU` return `-1` (i.e., all bits set); `REM` and `REMU` return the dividend.
+  - Signed overflow: `INT64_MIN / -1` returns `INT64_MIN` (the mathematical quotient); the corresponding `REM` returns 0.
+  - The operation must not raise an exception; the hardware must produce the specified result.
+- **Throughput vs. latency decoupling.** **FACT.** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end unless explicit forwarding is provided.
+
+The XH-1 is a 128-core machine. **FACT.** Decisions in the MUL/DIV unit replicate 128×, so per-core area dominates the silicon cost; verification effort is dominated by unit-level and core-level-integration work that is performed once and reused across the 128 identical instances (see §Verification Considerations and §128-Core Scalability for the qualification). **INSUFFICIENT EVIDENCE:** There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).
+
+**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, target process node, per-core area budget, and target workload mix for XH-1 are all unknown.
+
+## Existing Approaches
+
+The following approaches are well-established in the literature and commercial designs. **FACT.** Standard computer-arithmetic texts (Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*) cover these techniques in canonical form. No XH-1-internal prior art exists. Per-cycle latency figures given below are **TYPICAL** values for a 64-bit operand at a moderate clock target; specific values are implementation- and node-dependent, and the figures are not drawn from a single citable source. Where a range is given, it is illustrative of the order of magnitude, not a tight bound.
+
+### 1. Shift-and-Add Multiplier (Iterative)
+
+- **Mechanism:** **FACT.** A 64-bit multiplier is implemented as a state machine that processes one partial-product bit per cycle against a 128-bit accumulator (or a 129-bit accumulator with a sign-preconditioned variant). Signed operands are sign-extended; iteration count is not halved.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand, plus a small constant for sign/result correction.
+- **Throughput:** **TYPICAL.** One multiply per ~64 cycles (unit is not pipelined).
+- **Area:** **TYPICAL.** Very small. Roughly one wide adder + one shifter + one accumulator register.
+- **Power:** **TYPICAL.** Low. Minimal clocked area per cycle.
+- **Verification:** **TYPICAL.** Low complexity. Straightforward to model and exhaustively test at small operand widths.
+- **Use case:** **TYPICAL.** Embedded in-order cores where MUL/DIV are infrequent and latency-tolerant. Generally unsuitable for high-performance 64-bit cores.
+
+### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)
+
+- **Mechanism:** **FACT.** Radix-4 Booth recoding reduces partial products to ceil(n/2). For a 64-bit operand, standard radix-4 Booth encoding produces 32 partial-product rows. An *iterative* radix-4 multiplier accumulates these rows one or two at a time:
+  - **One row per cycle:** ~32 cycles, one CSA per cycle, smallest iterative area.
+  - **Two rows per cycle:** ~16 cycles, but requires two CSAs in series per cycle. The area cost of the second CSA is not a simple "doubling": the second CSA operates on the full sum-and-carry width of the first, so the additional area is closer to the cost of one full-width CSA, and the per-cycle critical path lengthens. This is the configuration that achieves the "16-cycle" figure sometimes cited; the area and timing costs must be acknowledged.
+  - **FACT.** Implemented as a single combinational Wallace/Dadda tree, the same 32 partial-product rows are summed in one cycle, with the tree depth determining the achievable clock period.
+- **Latency:** **TYPICAL.** ~32 cycles iterative (one row/cycle) or ~16 cycles iterative (two rows/cycle, with the area and timing qualifications above), or one combinational tree of approximately 8–12 CSA levels plus a final CPA (the level count is design- and library-specific; the figure is an order-of-magnitude estimate, not a precise bound). When pipelined, the array is typically broken into 3–6 stages, with each stage absorbing one to several CSA levels plus possibly a portion of the final CPA. The relationship between the un-pipelined tree depth and the pipelined stage count is implementation-specific; this document does not assert a fixed mapping.
+- **Throughput:** **TYPICAL.** One multiply per ~32 cycles (one row/cycle iterative), ~16 cycles (two rows/cycle iterative, with qualifications), or 1/cycle if the array is fully pipelined.
+- **Area:** **TYPICAL.** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA. The "two rows per cycle" iterative variant is roughly comparable in area to a small pipelined array, with the per-cycle critical path lengthened.
+- **Power:** **TYPICAL.** Moderate to high when pipelined. The Wallace/Dadda tree toggles aggressively, and clock-tree load on a replicated array is non-trivial.
+- **Verification:** **TYPICAL.** Moderate. The corner cases that matter are the signed-overflow cases in the `MULH` datapath (sign-extended partial products, modified tree inputs) and the `MULHSU` sign-extension path (Baugh-Wooley or Modified Booth sign handling, not a free byproduct of the unsigned array). The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and the bulk of `MULHSU`; `MULH` is a separate verification pass; `MULHSU` requires explicit sign-handling verification but is closer to the unsigned case than `MULH` is.
+- **Use case:** **TYPICAL.** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.
+
+### 3. Radix-8 or Radix-16 Booth Multiplier
+
+- **Mechanism:** **FACT.** Higher-radix Booth recoding reduces the number of partial-product rows. For a 64-bit operand:
+  - Radix-4: 32 rows.
+  - Radix-8: 22 data rows plus a separate sign-handling row for the most-significant window, totaling 23 rows in a fully sign-corrected implementation. Canonical radix-8 Booth recoding requires careful handling of the most-significant 3-bit window to avoid producing an erroneous extra row. The PPG must produce multiples {0, ±1, ±2, ±3, ±4} of the multiplicand; ±3× and ±4× are typically generated via a carry-save adder (1× + 2× for ±3×, 2× + 2× or a dedicated shift-and-add for ±4×), so the PPG is substantially more complex than radix-4.
+  - Radix-16: 16 data rows plus a sign-handling row, totaling 17 rows. The PPG must produce multiples {0, ±1, ±2, ±3, ±4, ±5, ±6, ±7, ±8}; 3×, 5×, 6×, 7× are typically generated via combinations of smaller multiples, with an extra high-order term.
+  - **Correction:** The "radix-8 reduces by 3×, radix-16 by 4×" claim sometimes seen in the literature refers to the ratio relative to radix-2 (64 partial products → 22 or 16 data rows), not a clean 3× or 4× multiplier. The actual reductions over radix-2 are 64/22 ≈ 2.9× (radix-8) and 64/16 = 4× (radix-16); the reductions over radix-4 are 32/22 ≈ 1.45× and 32/16 = 2× respectively.
+- **Latency:** **TYPICAL.** The fully pipelined radix-4 array can already achieve 1/cycle throughput; higher radices reduce the *depth* of the adder tree (fewer rows to sum) and therefore either shorten the critical path or allow fewer pipeline stages. Throughput is not increased beyond 1/cycle unless the array is duplicated.
+- **Throughput:** **TYPICAL.** 1/cycle for a single pipelined array; not inherently higher than radix-4.
+- **Area:** **TYPICAL.** Larger PPG; smaller (shallower) adder tree. Net area is roughly comparable to radix-4 or slightly larger.
+- **Power:** **TYPICAL.** Mixed. Fewer adder levels, but more complex PPG.
+- **Verification:** **TYPICAL.** Higher. Radix-8+ PPGs have more corner cases and the recoding is harder to prove correct.
+- **Use case:** **TYPICAL.** High-frequency designs where the critical path is in the adder tree, not the PPG.
+
+### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)
+
+- **Mechanism:** **FACT.** Standard shift-subtract over the operand width. Produces quotient (and optionally remainder) one bit per cycle. The iteration count for a 64-bit operand is exactly 64 reduction steps (or 65 with a sign pre-correction step); the figure is not a range.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand (plus a small constant for sign correction).
+- **Throughput:** **TYPICAL.** One divide per ~64 cycles.
+- **Area:** **TYPICAL.** Small. A 64- or 65-bit ALU with quotient/remainder registers.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Moderate. The division-by-zero convention, the `INT64_MIN / -1` overflow case, and the `REM`/`REMU` dividend-return case must all be implemented and tested explicitly. The signed-dividend path is the principal source of bugs.
+- **Use case:** **TYPICAL.** In-order cores with low expected DIV frequency.
+
+### 5. Radix-4 SRT Divider
+
+- **Mechanism:** **FACT.** Higher-radix SRT produces multiple quotient digits per iteration by selecting one of several shifted multiples of the divisor from a selection table indexed by a truncated partial remainder. A radix-4 SRT produces 2 bits per iteration; the quotient is held in a redundant (carry-save) form and converted to two's-complement on completion. The iteration count for a 64-bit operand is 16 selection steps in the worst case, plus a final quotient-conversion step (carry-save to two's-complement); the converter is not an extra selection step.
+- **Latency:** **TYPICAL.** ~16 selection cycles plus a small constant for the final conversion, for a 64-bit operand.
+- **Throughput:** **TYPICAL.** One divide per ~16 cycles (worst case).
+- **Area:** **TYPICAL.** Substantially larger than subtractive. Requires a redundant (carry-save) quotient representation, a quotient-digit selection table, and partial-quotient error-correction logic.
+- **Power:** **TYPICAL.** Higher.
+- **Verification:** **TYPICAL.** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction has been the source of silicon bugs in commercial designs. **FACT.** The classic example is the Pentium FDIV bug: the floating-point divider's radix-4 SRT lookup table was missing entries (a "+2" entry that should have been present) in the programmable logic array (PLA) implementing the selection function. The fix was a mask change, not a logic redesign. **TYPICAL.** The lessons from this and similar incidents — that the interaction between the redundant quotient representation and the selection function produces error patterns that are not obvious from inspection, and that verification typically requires formal proofs of the selection function over reduced operand widths plus extensive directed testing — transfer to integer radix-4 SRT dividers, but the FP and integer SRT implementations use different quotient-digit sets and selection functions, so the lessons are transferred by analogy rather than by direct equivalence.
+- **Use case:** **TYPICAL.** High-frequency OoO cores needing higher DIV throughput.
+
+### 6. Goldschmidt Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Each iteration multiplies both the partial remainder and the partial quotient by a correction factor derived from a short reciprocal estimate. Distinct from Newton-Raphson (see §7).
+- **Latency:** **TYPICAL.** A few multiply iterations. Amortized low latency if the multiplier is fast.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final iteration must converge to enough bits of precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step. The accuracy analysis is non-trivial and historically a bug source.
+- **Use case:** **TYPICAL.** Designs that already have a fast pipelined multiplier and want a small, fast divider.
+
+### 7. Newton-Raphson Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial estimate of the divisor's reciprocal using a Newton-Raphson step, then multiply the dividend by the refined reciprocal. Each iteration squares the error, so convergence is quadratic. Distinct from Goldschmidt, which uses a multiplicative correction on both the partial remainder and the partial quotient simultaneously; the two algorithms have different error dynamics and different fixup requirements.
+- **Latency:** **TYPICAL.** A few iterations of multiply-add. Typically fewer iterations than Goldschmidt to reach a given precision, but each iteration is a full multiply.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds lookup-table ROM for the initial estimate and modest control logic.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final-step rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the fixup step.
+- **Use case:** **TYPICAL.** Designs with a fast pipelined multiplier that want a low-latency divider.
+
+### 8. Shared MUL/DIV Iterative Unit (Multiplexed)
+
+- **Mechanism:** **ASSUMPTION.** A single iterative datapath handles both MUL and DIV by reconfiguring its datapath between operations. **TYPICAL.** This pattern is more common in microcoded embedded cores than in modern 64-bit RV64 designs, where MUL and DIV datapaths are structurally different (shift-and-add with accumulator vs. shift-subtract with quotient register) and the area savings from sharing are modest compared to the control complexity of reconfiguration. The characterization in this document is qualified accordingly.
+- **Latency:** **TYPICAL.** Same as the underlying iterative unit; the unit cannot serve MUL and DIV concurrently.
+- **Throughput:** **TYPICAL.** MUL and DIV contend for the same unit.
+- **Area:** **TYPICAL.** For RV64, the area advantage of a genuinely shared iterative unit over a split iterative MUL + iterative DIV is modest at best, and the control complexity of reconfiguration may offset the savings. The "most area-efficient" framing in earlier drafts of this document is qualified here: shared-iterative is a defensible choice for microcoded embedded cores, but for RV64 the area ranking is closer to "small to moderate" rather than strictly "smallest." **ASSUMPTION.** This ranking depends on the datapath being genuinely shared rather than microcoded over separate datapaths.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Low to moderate if the datapath is genuinely shared; higher if microcode overlays separate datapaths.
+- **Use case:** **TYPICAL.** Cost-sensitive embedded cores; uncommon in high-performance RV64.
+
+## Alternative Designs
+
+Beyond the standard taxonomy, several non-obvious variants are worth considering.
+
+### A. Pipelined Multiplier + Sequential Divider (Split Unit)
+
+A fully pipelined radix-4 multiplier (e.g., 3–6 stage pipeline) is paired with an independent sequential subtractive divider. The two units have separate reservation/issue logic.
+
+- **Rationale:** **ASSUMPTION.** Under many server, desktop, and general-purpose workloads, MUL is more frequent than DIV, but the ratio is workload-dependent and should not be assumed a priori. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches a plausible workload asymmetry.
+- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.
+
+### B. Variable-Latency Divider (Speculative / Early-Quit)
+
+Produce a partial-width approximate quotient, sign-extend, and perform a single correction step on the remaining bits. The early-quit path saves cycles when the divisor has small magnitude.
+
+- **Risk:** **TYPICAL.** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core. This can be partially mitigated by a fixed maximum latency with early completion, at the cost of additional control logic.
+
+### C. Radix-2 SRT with Carry-Save Quotient + Software/Hardware Fixup
+
+A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.
+
+- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step. The worst-case iteration count is 64 selection steps for a 64-bit operand.
+
+### D. Pipelined 2-bit-per-cycle "Naïve" Divider
+
+Iterate two shift-subtract steps per cycle. Roughly halves divider latency relative to radix-1 subtractive without requiring an SRT selection table.
+
+- **Cost:** Two wide adders and a longer critical path. Area is moderate.
+
+### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Newton-Raphson
+
+A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations.
+
+- **Cost:** **TYPICAL.** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step (one or two multiplies plus a comparison). The precision / error analysis is non-trivial.
+
+### F. Shared Multi-Cycle Divider Across Cores (Divider Co-Processor)
+
+A small number of high-throughput dividers (e.g., 4 or 8) placed at fixed points in the fabric and dispatched to by cores via a memory-mapped or message interface. The dividers are not private to any core.
+
+- **Rationale:** Avoids replicating the divider 128×. Trades single-core latency (now includes a fabric round-trip) for amortized area.
+- **Cost:** NOC traffic, dispatch latency, contention at the divider, and software-visible ABI changes (or a transparent-but-slow trap path).
+- **Status:** Unusual but not unprecedented in accelerator-rich many-core designs.
+
+### G. FP / Integer Multiplier Sharing
+
+Share the integer multiplier's partial-product array and adder tree with the FP pipeline. **TYPICAL.** This pattern appears in BOOM and in some SiFive designs; Rocket Chip keeps the integer and FP multipliers as separate units. The applicability of the pattern is design-specific and is not asserted as universal here.
+
+- **Rationale:** Avoids replicating a wide datapath. The FP pipeline also benefits from a fast multiplier.
+- **Cost (qualified):** **TYPICAL.** Cross-unit scheduling and bypassing complexity. The integer and FP pipelines may have different latency targets. The sharing requires operand-format conversion (integer operands to FP-like internal format, and vice versa) and FP-specific concerns (rounding mode support, subnormal handling, NaN propagation) are not "free" — they are offloaded to the FP pipeline's existing logic, but the integer side must correctly drive and consume the shared datapath. Verification must cover the combined integer-plus-FP datapath, which is more complex than either alone. The "near-free" characterization sometimes seen in the literature is oversimplified; the cost is real but is often dominated by the FP-pipeline logic that already exists, making the incremental cost on the integer side smaller than the absolute cost of a separate integer multiplier.
+
+### H. Latency-Tolerant In-Order MUL/DIV
+
+Even a multi-cycle iterative MUL/DIV may be tolerable in an in-order core if the result-bus supports forwarding directly from the MUL/DIV output to dependent consumers, bypassing the register file writeback-read path.
+
+- **Cost:** Forwarding path length and bypass-network complexity scale with MUL/DIV latency. The forwarding network is a real cost — typically a set of wide muxes at the input of each consuming execution unit, with wiring that may dominate the area of the iterative MUL/DIV unit itself. The cost scales with the number of consumers (ALU, branch, load/store) and with MUL/DIV latency, since the forwarded result must remain valid on the bypass network for the full MUL/DIV latency. This cost should be quantified before an iterative unit is chosen for an in-order core.
+
+### I. Interaction with the "B" (Bitmanip) Extension
+
+The RISC-V Bitmanip extension introduces MUL/DIV-adjacent operations (e.g., `CLZ`, `CTZ`, `MIN`, `MAX`, bit-extract/deposit, and several pseudo-multiplication idioms such as `RORI` and `SH*ADD`). If the B extension is in scope, the MUL/DIV unit may either be reused for some of these (e.g., via the ALU) or augmented with dedicated bitmanip datapath. The decision is interdependent with the MUL/DIV choice and is flagged as an open question below.
+
+## Comparison
+
+The following table presents *qualitative* relative magnitudes only. **INSUFFICIENT EVIDENCE:** No node, frequency, or synthesis data is available for XH-1, so quantitative ratios are not asserted. The latency and throughput figures are **TYPICAL** values for a 64-bit operand and are presented as order-of-magnitude estimates; the ranges are wider than in the prior draft to reflect the absence of a citable source. "Latency" is in cycles for back-to-back independent operations on the named unit; "throughput" is sustained operations per cycle for a fully pipelined or iterative unit, respectively.
+
+| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort |
+|---|---|---|---|---|---|
+| Iterative shift-add MUL (one row/cycle) + iterative subtractive DIV (separate) | ~64 (MUL) / ~64 (DIV) | ~1/64 (each) | Smallest | Smallest | Low |
+| Iterative radix-4 MUL (one row/cycle) + iterative subtractive DIV (separate) | ~32 (MUL) / ~64 (DIV) | ~1/32 (MUL), ~1/64 (DIV) | Small | Small to moderate | Low to moderate |
+| Shared iterative MUL/DIV (multiplexed, Approach 8) | ~64 (MUL) / ~64 (DIV), mutually exclusive | ~1/64 (each, contended) | Small to moderate (modest savings over split iterative; control overhead) | Small to moderate | Low to moderate |
+| Pipelined radix-4 array MUL + iterative subtractive DIV (split, Alternative A) | ~3–6 (MUL) / ~64 (DIV) | 1/cycle (MUL), ~1/64 (DIV) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 array MUL + 2-bit-per-cycle naïve DIV (Alternative D) | ~3–6 (MUL) / ~32 (DIV) | 1/cycle (MUL), ~1/32 (DIV) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 array MUL + radix-4 SRT DIV | ~3–6 (MUL) / ~16 + conversion (DIV) | 1/cycle (MUL), ~1/16 (DIV) | Large | Large | High |
+| Pipelined radix-8 array MUL + Newton-Raphson or Goldschmidt DIV | ~3–6 (MUL) / a few MUL iterations (DIV) | 1/cycle (MUL), bounded by MUL (DIV) | Largest | Largest | High |
+
+**INSUFFICIENT EVIDENCE:** The relative magnitudes are illustrative and intended only to convey ordering. The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1. **INSUFFICIENT EVIDENCE:** Quantitative area, power, and energy comparisons cannot be made without a target node, frequency, and synthesis flow. The ranges given above are wider than the typical figures cited in the prior draft to reflect this uncertainty.
+
+## Advantages
+
+The leading candidates each have a distinct strength profile. The following are conditional on the workload and core microarchitecture, which are not yet established.
+
+- **Iterative separate MUL + iterative separate DIV (smallest, lowest power):** **ASSUMPTION.** Smallest per-core area and lowest power among the candidate RV64 designs. Easiest to verify. Long latency is the principal disadvantage.
+- **Shared iterative unit (Approach 8, with the qualification in §8):** **ASSUMPTION.** A defensible choice for cost-sensitive embedded cores, but for RV64 the area advantage over a split iterative design is modest and the control complexity of multiplexing MUL and DIV may offset the savings. Not recommended by default for RV64.
+- **Pipelined radix-4 MUL + iterative subtractive DIV (split, Alternative A):** **ASSUMPTION.** Matches a plausible workload asymmetry where MUL is more frequent than DIV; MUL throughput is high (common case), DIV cost is contained, and verification is tractable. This is a strong compromise candidate, not a leading candidate by default.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest predictable throughput on both operations; minimal front-end exposure if the core is in-order. Verification cost is high.
+- **Newton-Raphson or Goldschmidt DIV on top of fast MUL:** **TYPICAL.** Reuses the multiplier's silicon; area-efficient if the multiplier is already large. Verification cost is high.
+
+## Disadvantages
+
+- **Iterative separate MUL + iterative separate DIV:** **TYPICAL.** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided, and the forwarding path itself has non-trivial cost (see Alternative H).
+- **Shared iterative unit:** **TYPICAL.** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided. For RV64, the structural mismatch between MUL and DIV datapaths limits the achievable area savings, and the MUL/DIV datapaths contend for the shared unit.
+- **Pipelined radix-4 MUL + iterative DIV:** **TYPICAL.** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs (the Pentium FDIV bug being a radix-4 SRT selection-table defect, transferred by analogy to integer SRT). The verification cost is replicated at the unit level and is the dominant non-silicon cost of this design.
+- **Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean, formally-specified correction step.
+
+## XH-1 Considerations
+
+**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:
+
+1. **128-core replication amplifies per-core area cost.** **FACT.** A larger MUL/DIV unit pays the same area cost across all 128 cores, not just one. The die-area cost is severe. Verification effort is *not* amplified by the same factor (see item 4 and §Verification Considerations); the framing in earlier drafts of this document that listed "per-core area and verification cost" together as both amplified by replication conflates two distinct effects and is corrected here.
+2. **Per-core issue width and in-order/OoO status are not established.** **INSUFFICIENT EVIDENCE.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not, unless explicit forwarding is provided.
+3. **128 cores imply a tile- or mesh-style interconnect.** **ASSUMPTION.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations, unless a shared divider alternative (Alternative F) is adopted.
+4. **Verification cost is concentrated at the unit level, not multiplied by replication.** **TYPICAL.** A replicated unit is verified once at the unit level (RTL, formal, directed/random). The integration with each core's pipeline is identical across replications and is verified once via the core-level verification environment; running the same integration suite 128× does not add coverage. The 128× replication matters for silicon defect exposure (a bug that escapes verification affects all cores) and for DFT/scan/BIST architecture, not for per-instance verification run-count. This is the standard methodology for replicated unit-level verification in commercial designs.
+5. **Physical-design regularity matters under replication.** **TYPICAL.** A small, regular MUL/DIV unit is easier to harden and replicate 128× than a complex, irregular SRT unit.
+
+**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.
+
+**OPEN QUESTION:** Is the 128-core fabric homogeneous (all cores identical, all running the same software) or heterogeneous (e.g., application cores plus management or I/O cores)? Heterogeneity would relax the per-core MUL/DIV uniformity requirement and may allow per-tile optimization.
+
+## 128-Core Scalability
+
+The MUL/DIV unit is per-core and not shared across cores by default. Scalability considerations:
+
+- **No coherence problem.** **FACT.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
+- **No cross-core contention** in the default per-core configuration. **FACT.** Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior. A shared-divider alternative (Alternative F) changes this analysis.
+- **Verification parallelism.** **TYPICAL.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once at the unit level. Integration with the pipeline is verified once at the core level (since all cores are identical replications), not 128×. The 128× replication affects silicon defect exposure, not verification run-count.
+- **Area-budget pressure.** **TYPICAL.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
+- **Power-grid and clock distribution.** **TYPICAL.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. **INSUFFICIENT EVIDENCE:** Power delivery (IR drop), clock skew across the replicated load, and dynamic power density must be analyzed for the replicated load; no quantitative estimates are made here.
+- **Scan and BIST.** **TYPICAL.** A 128× replicated unit implies 128× the scan-chain length (if scan is per-core) or a partitioned BIST architecture. The choice affects DFT area and test time.
+- **Fault tolerance.** **TYPICAL.** A defect in the MUL/DIV unit is potentially a defect in all 128 cores. This argues for either a hardened, characterized macro or built-in redundancy / sparing, depending on yield targets.
+- **Timing variation.** **TYPICAL.** Across-die process variation affects 128 replicated units independently. A design that is timing-marginal at one corner may fail at another. Iterative designs are less sensitive to per-unit timing variation than deep-pipelined arrays.
+
+**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128. Prefer regular, hardenable structures over irregular ones that resist replication.
+
+## Performance Considerations
+
+MUL/DIV performance interacts with the rest of the core in two ways:
+
+1. **Latency exposure.** **FACT.** In an in-order core, MUL latency stalls the front-end unless explicit forwarding is provided. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
+2. **Throughput-bound on dependent chains.** **FACT.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.
+
+**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.
+
+## Area Considerations
+
+Relative area ordering, qualitative only (no synthesis data available):
+
+- Iterative shift-add MUL + iterative subtractive DIV (separate): smallest.
+- Iterative radix-4 MUL (one row/cycle) + iterative subtractive DIV (separate): small.
+- Shared iterative MUL/DIV (Approach 8): small to moderate, depending on the degree of datapath sharing and the control overhead; the area advantage over split iterative is modest for RV64.
+- Pipelined radix-4 MUL + iterative subtractive DIV (split): moderate.
+- Pipelined radix-4 MUL + 2-bit-per-cycle naïve DIV: moderate.
+- Pipelined radix-4 MUL + radix-4 SRT DIV: large.
+- Pipelined radix-8 MUL + Newton-Raphson / Goldschmidt DIV: largest.
+
+**INSUFFICIENT EVIDENCE:** The XH-1 per-core area budget must be defined before any of the above can be quantified in absolute terms. Absolute area figures require a process node and a synthesis flow.
+
+## Power and Energy Considerations
+
+Relative energy-per-operation ordering, qualitative only:
+
+- **Iterative:** **TYPICAL.** Low per-cycle power, but high per-operation energy × time product (many cycles).
+- **Pipelined MUL + iterative DIV:** **TYPICAL.** Low per-op MUL energy, high per-op DIV energy.
+- **Pipelined MUL + SRT DIV:** **TYPICAL.** High per-cycle power, lower per-op energy than iterative.
+- **Pipelined MUL + Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Per-op energy is a small multiple of MUL energy; competitive.
+
+**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative subtractive DIV is a reasonable energy-vs-area compromise, contingent on the workload.
+
+**INSUFFICIENT EVIDENCE:** Quantitative power and energy figures require a process node, a clock target, and a workload trace.
+
+## Implementation Considerations
+
+- **Wallace/Dadda tree synthesis risk.** **TYPICAL.** Compressor trees are known to be hard to place-and-route at high frequency on modern nodes; poor placement can introduce unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon. *This is an engineering judgment, not an established fact; specific delay figures depend on the synthesis flow and library, and are not asserted here.*
+- **PPG and Booth recoder verification.** **TYPICAL.** Radix-4 PPGs are well-understood and tractable to verify; radix-8+ PPGs require more corner cases. The `MULH` signed×signed upper-half path requires explicit verification of sign-extended partial products and is not a free byproduct of the unsigned array. The `MULHSU` path requires explicit sign-handling verification (Baugh-Wooley or Modified Booth) and is not a vanilla 65×64 unsigned array.
+- **SRT selection table correctness.** **TYPICAL.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
+- **RISC-V division-by-zero and overflow conventions.** **FACT.** `DIV` and `DIVU` return `-1` (all bits set) on divide-by-zero; `REM` and `REMU` return the dividend on divide-by-zero. On signed overflow (`INT64_MIN / -1`), `DIV` returns `INT64_MIN` and `REM` returns 0. These must be implemented explicitly; the design must not raise a trap.
+- **Pipeline interlocks.** **FACT.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
+- **Physical design replication.** **TYPICAL.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication and are a physical-design risk under replication.
+
+## Verification Considerations
+
+Verification cost is a dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:
+
+- **Radix-2/4 shift-add and subtractive:** **TYPICAL.** Lowest. Exhaustive simulation at reduced widths is tractable.
+- **Radix-4 Booth + iterative DIV:** **TYPICAL.** Moderate. The hard cases are the signed division edge cases (division-by-zero, `INT64_MIN / -1`), the `MULH` signed×signed upper-half path (sign-extended partial products, not a free byproduct of the unsigned array), and the `MULHSU` sign-extension (Baugh-Wooley or Modified Booth, not a vanilla unsigned array). The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and the bulk of `MULHSU`; `MULH` is a separate verification pass; `MULHSU` requires explicit sign-handling verification.
+- **SRT:** **TYPICAL.** High. SRT selection-table bugs are famous in industry (the Pentium FDIV bug was a missing entry in the PLA implementing the radix-4 SRT lookup table of the floating-point divider; the lessons transfer to integer SRT by analogy, with the caveat that FP and integer SRT use different quotient-digit sets and selection functions). Verification typically requires formal proofs of the selection function over reduced widths and extensive directed testing.
+- **Newton-Raphson / Goldschmidt:** **TYPICAL.** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
+- **Replication factor:** **TYPICAL.** A bug in the MUL/DIV unit that escapes verification is a bug in all 128 cores (silicon defect exposure). However, the verification effort itself is not 128×: the unit is verified once at the unit level, and the core-level integration is verified once (cores are identical replications). The risk is concentrated exposure, not multiplied effort. This is the standard methodology for replicated unit-level verification in commercial designs.
+
+**Preliminary verification strategy** (to be refined once the design choice is made):
+
+- **Unit-level:** Exhaustive simulation at reduced operand widths (e.g., 8, 12, 16 bits) for the core datapath. Formal equivalence checking between the RTL and a reference model written in a high-level specification language (e.g., Bluespec, Scala, or a C reference). For SRT or Newton-Raphson, formal proof of the selection function or the convergence step.
+- **Directed corner-case suite:** Explicit tests for division-by-zero (both `DIV`/`DIVU` and `REM`/`REMU` paths), signed overflow (`INT64_MIN / -1`, both quotient and remainder), `MULH` against a cross-checked reference (Baugh-Wooley or equivalent), `MULHSU` against a cross-checked reference (with explicit sign-handling verification), and the `MUL`-then-truncate boundary.
+- **Random / constrained-random:** At full width, comparing against a software reference. Coverage targets on the Booth recoder, PPG, and selection table.
+- **Integration:** Per-core pipeline integration verified once at the core level (not 128×), since cores are identical.
+- **Post-silicon:** Microarchitectural validation suite, focused on MUL/DIV-intensive kernels (big-integer arithmetic, hashes, polynomial multiplications).
+
+**PROPOSAL:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.
+
+## Software Considerations
+
+- **Compiler behavior.** **FACT.** GCC and LLVM routinely use shift-and-add sequences for multiplication by small constants, and they may either emit `MUL` instructions or inline expansions depending on the cost model. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences, but the magnitude of this effect is workload- and compiler-version-dependent and should not be assumed.
+- **Library code.** **FACT.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
+- **System software.** **TYPICAL.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
+- **128-core interaction.** **ASSUMPTION.** In a homogeneous configuration where the system stack (kernel, hypervisor) runs on some subset of the 128 cores, there is no asymmetric design implication: every core is equal in the default per-core configuration. **INSUFFICIENT EVIDENCE:** Whether the 128-core fabric is homogeneous or heterogeneous (e.g., application cores plus management or I/O cores) is an open question (see Open Questions); the assumption of homogeneity is provisional.
+
+**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.
+
+## Recommendation
+
+**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:
+
+1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
+2. The per-core area and power budget.
+3. The target workload mix and software ecosystem.
+
+**Conditional recommendations** (to be revisited once the above are known):
+
+- **If XH-1 targets an in-order core with tight area budget:** **PROPOSAL.** A separate iterative shift-add MUL (one row/cycle) and an iterative subtractive DIV is the smallest, easiest-to-verify choice. MUL/DIV latency will be high; whether this is acceptable depends on the forwarding path and the workload. **The forwarding path is a real and non-trivial cost:** the bypass network from the MUL/DIV output to dependent consumers (ALU, branch, load/store) must be sized to the full MUL/DIV latency, and the wiring may dominate the area of the iterative MUL/DIV unit itself. This cost should be quantified before the iterative unit is chosen. The shared-iterative-unit approach (Approach 8) is *not* recommended for RV64 by default, given the structural mismatch between MUL and DIV datapaths and the modest area advantage over a split iterative design.
+- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** **PROPOSAL.** A pipelined radix-4 Booth multiplier (3–6 stage pipeline) paired with a 2-bit-per-cycle naïve divider or a radix-4 SRT divider. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle. **Reconciliation note:** the cross-cutting recommendation below defers SRT until formally proven correct; if SRT cannot be formally verified on reduced widths within the project timeline, the 2-bit-per-cycle naïve divider is the preferred DIV companion. The SRT recommendation is conditional on the verification investment being made.
+- **If the per-core area budget is moderate and the workload is balanced:** **PROPOSAL.** A pipelined radix-4 MUL with an iterative subtractive DIV (the "split" approach, Alternative A) is a strong compromise.
+
+**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson / Goldschmidt rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.
+
+## Confidence
+
+| Topic | Confidence |
+|---|---|
+| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
+| Relative area, power, and energy rankings | Low to medium (qualitative ordering only; no synthesis data) |
+| Per-cycle latency numbers | Low to medium (typical, but node- and target-frequency-dependent; ranges are illustrative, not tight bounds) |
+| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
+| Specific recommendation | **Insufficient evidence** to commit |
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
+2. What is the per-core area budget, in absolute terms or as a fraction of die area?
+3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
+4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused or augmented.
+5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
+6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
+7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power and replication regularity; synthesis-per-core favors design flexibility.
+8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
+9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
+10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.
+11. Will the MUL/DIV unit be shared with the FP pipeline (as in BOOM and some SiFive designs, though not in Rocket Chip), or kept private to the integer pipeline?
+12. Will XH-1 adopt a shared multi-cycle divider across cores (Alternative F), or is a strictly per-core MUL/DIV unit required?
+
+## Sources
+
+- Canonical computer-arithmetic references: Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*. These cover the techniques surveyed above in standard form. **Caveat:** these texts underwrite the taxonomy and the mechanism descriptions. Specific per-cycle latency figures given in this document are **TYPICAL** values drawn from common practice in published RV64 designs; the cited texts provide the algorithmic background but do not, in their canonical editions, supply XH-1-specific latency or area numbers. No specific chapter or page is cited for the quantitative figures because the figures are not drawn from a single source.
+- Open RISC-V core implementations (Rocket, BOOM, XiangShan, SiFive) provide reference designs for radix-4 array multipliers, iterative and SRT dividers, and FP/integer multiplier sharing. These are cited as implementation exemplars, not as XH-1 references. **FACT.** Rocket Chip keeps the integer and FP multipliers as separate units; BOOM and some SiFive designs share partial structures. The blanket attribution of sharing to "Rocket, BOOM, and most SiFive cores" in the prior draft of this document overstates the case and is corrected here.
+- **INSUFFICIENT EVIDENCE:** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
+- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as qualitative engineering estimates or as canonical background knowledge in the field of computer arithmetic.

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.review.md

@@ -0,0 +1,84 @@
+VERDICT: FAIL
+
+ISSUES:
+
+1. **Inconsistent radix-4 SRT digit-set terminology.** The "Mechanism" paragraph for the radix-4 SRT divider says the unit "produces 2 bits per iteration" and "the quotient is held in a redundant (carry-save) form." A radix-4 SRT divider with a carry-save (CS) partial remainder produces **2 quotient bits per iteration in redundant form**, and the quotient-digit selection function actually produces one radix-4 digit per cycle, not a carry-save quotient digit. The standard formulations use either (a) a redundant partial remainder (carry-save) with a non-redundant quotient-digit selection, or (b) a redundant quotient register with selection from a small set (e.g., −2, −1, 0, +1, +2) and a separate partial-remainder datapath. The document conflates these two formulations ("carry-save quotient representation" and a "quotient-digit selection table") without specifying which is intended. The "redundant (carry-save) quotient" framing is non-standard and potentially incorrect depending on the SRT variant assumed. This is a substantive technical error in a section tagged FACT.
+
+2. **Pentium FDIV bug description is inaccurate.** The document states the bug was a "missing entry... a '+2' entry that should have been present in the programmable logic array (PLA) implementing the selection function." The well-documented root cause was that the lookup table contained only 1,068 of the required 1,066 entries (actually 1,068 entries; some sources differ, but the documented defect was missing entries, not specifically a missing "+2" entry). More importantly, the divider was a **radix-4 SRT** divider but the characterization of the bug as a single missing "+2" digit in a PLA is oversimplified. The actual defect was missing entries in the PLA's truth table that caused some division operands to produce incorrect results. Claiming a specific missing "+2" entry as the cause, presented as FACT, is not accurate. The fact-tag is also inappropriate — the specific defect mechanism is disputed across sources; the fact that the bug existed and was an SRT PLA defect is the fact, not the specific entry. The document should mark the entry-level description as TYPICAL or remove it.
+
+3. **Booth recoding row counts are non-canonical and possibly incorrect.** The document states radix-4 produces "32 partial-product rows" for a 64-bit operand (correct: ceil(64/2) = 32). It states radix-8 produces "22 data rows plus a separate sign-handling row for the most-significant window, totaling 23 rows in a fully sign-corrected implementation." Standard radix-8 Booth (Modified Booth encoding, scanning three bits at a time with the standard overlapping-window formulation) produces **ceil(64/3) = 22 partial-product rows** when using the canonical non-redundant radix-8 form, but the commonly cited form is **21 rows** (since 64/3 rounds down to 21 with a 2-bit MSB fragment handled by sign extension). The "+1 sign-handling row" framing is non-standard; sign handling in Modified Booth is incorporated into the existing rows via sign-extension of the MSB partial product, not as an extra row. This claim is misleading and presented as FACT.
+
+4. **Radix-8 multiples claim is non-standard.** The document says "The PPG must produce multiples {0, ±1, ±2, ±3, ±4} of the multiplicand." Standard radix-8 Booth encoding (3-bit window) produces digits in the set {−4, −3, −2, −1, 0, +1, +2, +3, +4} (the ±4 multiple is generated for the case where the window is "100" or "011" with the canonical encoding). This is correct. However, the statement that "±3× and ±4× are typically generated via a carry-save adder" is partially correct but the description of "1× + 2× for ±3×, 2× + 2× or a dedicated shift-and-add for ±4×" is confusing — 2× + 2× is **not** a valid implementation of 4×; 4× is a left shift by 2 (i.e., wire routing, not addition). The claim that 4× is generated by "2× + 2×" is technically correct (it equals 4×) but is an unusual and suboptimal description; the canonical implementation is a left-shift by 2. The document presents an unusual implementation detail as TYPICAL without justification.
+
+5. **Self-contradictory claim about "free" MULH and MULHSU in the same section.** The "Wide-operand upper-multiply (UMUL)" paragraph characterizes MULH* as having a "small" incremental cost over MUL. The "MULH and signed×signed handling" and "MULHSU and signed×unsigned handling" paragraphs then explicitly contradict this, stating MULH and MULHSU are "not free" and require dedicated datapaths and verification passes. These three claims are not strictly contradictory (the first says "small area adder," the latter two say "not free in the strict sense") but the document's "Caveat" in the UMUL paragraph says the shared-array pattern is the "common case," while the later paragraphs say the MULH datapath is structurally different. The reconciliation is incomplete: the document needs to clearly state whether the underlying array is genuinely shared (with sign-handling added at the edges) or whether MULH and MULHSU use distinct datapaths. As written, a reader cannot determine which it is. This is a substantive internal inconsistency in a section tagged FACT.
+
+6. **Radix-2 SRT iteration count framing is wrong.** The document states "A radix-2 SRT divider also requires 64 selection steps in the worst case (with possible skipped steps on average, but the worst case governs the pipeline)." Radix-2 SRT is essentially equivalent to non-restoring division in the worst case (64 steps for 64-bit operands), so the claim is correct in count but the framing is misleading: radix-2 SRT's distinguishing feature is **not** the iteration count but the quotient-digit selection logic and the redundant remainder representation. A reader unfamiliar with SRT will come away thinking radix-2 SRT differs from non-restoring primarily in the iteration count, which is the opposite of the truth — they have the same worst-case iteration count, and the SRT framework exists precisely because of the redundant-form advantages. Additionally, Alternative C describes "Radix-2 SRT with Carry-Save Quotient + Software/Hardware Fixup" as "Faster than naive subtractive," but with 64 selection steps in the worst case (which governs the pipeline), this is not faster than subtractive division in the latency-critical sense. The claim is at best misleading and at worst wrong.
+
+7. **The radix-4 SRT row in the Comparison table conflates "1/16" throughput with sustained throughput.** A radix-4 SRT divider has worst-case latency of ~16 selection cycles plus a final on-the-fly quotient-conversion step. Sustained throughput for a single non-pipelined radix-4 SRT divider is one divide per ~16 cycles, which the table captures as "~1/16 (DIV)." However, for a fully pipelined radix-4 SRT array, throughput could approach 1/cycle (with latency of ~16 cycles). The table's "~1/16 (DIV)" throughput is correct for a non-pipelined radix-4 SRT unit but the document does not clearly flag that a pipelined variant exists, and the table is silent on the pipelining assumption. The SRT divider in the "Pipelined radix-4 array MUL + radix-4 SRT DIV" row could be pipelined to achieve 1/cycle DIV throughput with ~16-cycle latency, which would change the comparison materially. The table is internally inconsistent with the row above (pipelined radix-4 MUL achieves 1/cycle MUL throughput), which establishes a pipelining baseline.
+
+8. **Unsubstantiated quantitative claim about MULH "share the array" pattern.** The document states the "share the array" pattern "is the common case in published RV64 implementations (e.g., BOOM, XiangShan, some SiFive designs), but quantitative numbers are not asserted here." This is a substantive claim attributed to specific named designs (BOOM, XiangShan, some SiFive) without citation. The "share the array" characterization is a non-trivial microarchitectural decision; claiming it is the "common case" in three named designs without any citation (paper, documentation, or RTL inspection) is an unsupported factual claim. The document should mark this as INSUFFICIENT EVIDENCE or remove the named designs.
+
+9. **The cross-cutting recommendation creates an internal contradiction with the OoO conditional recommendation.** The "Cross-cutting recommendation" defers SRT until formally proven correct, but the OoO conditional recommendation explicitly proposes SRT (with a reconciliation note). The reconciliation note says "if SRT cannot be formally verified on reduced widths within the project timeline, the 2-bit-per-cycle naïve divider is the preferred DIV companion." This is a self-contradictory structure: the recommendation both does and does not recommend SRT, depending on an unspecified future decision. A reader cannot determine which divider to design for. The structure of "Recommendation" should make a single defensible choice, not a conditional that effectively defers the choice.
+
+10. **128-core verification claim is partially incorrect.** The document states "the integration with each core's pipeline is identical across replications and is verified once via the core-level verification environment; running the same integration suite 128× does not add coverage." This is technically correct for unit-level coverage but is misleading regarding integration verification. In commercial replicated-core designs (e.g., ARM Cortex-A, Intel Atom, AMD Zen), **core-level integration is typically verified per-core in a multi-core simulation environment** that exercises cross-core interactions, shared-resource contention, and coherence protocols. For a 128-core design, the cross-core verification environment is a distinct effort from the single-core integration environment and is **not** "verified once." The document conflates "single-core integration verified once" with "multi-core integration verified once," which are different scopes. The 128-core scalability claim should be qualified.
+
+11. **Booth recoding verification claim is too strong.** The document says "Radix-4 PPGs are well-understood and tractable to verify" (TYPICAL). This is a substantial underestimation: Modified Booth encoding for signed multiplication (especially MULH, MULHSU) has a long history of subtle bugs, including sign-extension errors in the MSB partial product. The "tractable to verify" framing understates the verification effort and may bias the design choice away from radix-4 in contexts where the verification cost is actually comparable to radix-8.
+
+12. **Goldschmidt vs. Newton-Raphson distinction is loosely drawn.** The document correctly notes the two are distinct but the description of Goldschmidt ("Each iteration multiplies both the partial remainder and the partial quotient by a correction factor") and Newton-Raphson ("Iteratively refine an initial estimate of the divisor's reciprocal... then multiply the dividend by the refined reciprocal") is correct at a high level. However, the "Use case" for both is identical ("Designs with a fast pipelined multiplier that want a small, fast divider"), which obscures the practical distinction: Goldschmidt converges linearly (each iteration adds a fixed number of correct bits) while Newton-Raphson converges quadratically. This affects the iteration count, latency, and verification cost materially. The document should distinguish them more sharply.
+
+13. **"Two rows per cycle" iterative radix-4 is described but not represented in the comparison table.** The §2 (Approach 2) section discusses "two rows per cycle" iterative radix-4 MUL at ~16 cycles with non-trivial area/timing cost. This configuration does not appear as a row in the Comparison table. A reader cannot assess the trade-off of this intermediate option. The Comparison table is incomplete.
+
+14. **The "Latency-Tolerant In-Order MUL/DIV" alternative (H) is presented as an alternative but its central cost (forwarding path) is only briefly noted.** The document states the forwarding network "may dominate the area of the iterative MUL/DIV unit itself" but does not quantify or compare this cost to the alternatives. The alternative is essentially a description of a known cost that any in-order iterative design must absorb, and the document should integrate this into the main analysis rather than treating it as a separate alternative.
+
+15. **"1× + 2× for ±3×" PPG detail is non-standard.** The document states that ±3× in radix-8 PPG is generated via "1× + 2×" (i.e., 3× multiplicand = multiplicand + 2× multiplicand). This is correct but the canonical implementation uses a **carry-save adder** that produces the 3× in carry-save form (sum and carry vectors) so the 3× multiple does not require an explicit addition in the critical path. The document does not mention this and implies an explicit addition, which is misleading for a high-performance design.
+
+16. **Dadda/Wallace tree "8-12 CSA levels" claim is unsupported.** The document states the radix-4 array's "one combinational tree of approximately 8–12 CSA levels plus a final CPA (the level count is design- and library-specific; the figure is an order-of-magnitude estimate, not a precise bound)." This is appropriately qualified as TYPICAL and order-of-magnitude. However, the actual CSA level count for a 32-row radix-4 Wallace tree summing to two rows is closer to **log_1.5(32/2) ≈ 8 levels** (using the 1.5 reduction ratio for full adders), or up to ~10 with the irregularity of practical Dadda reduction. The "8-12" range is defensible but on the high end; this is a minor issue but should be noted.
+
+17. **"Wallace/Dadda tree synthesis risk" is presented as engineering judgment but framed as a generalizable TYPICAL claim.** The document says "Compressor trees are known to be hard to place-and-route at high frequency on modern nodes; poor placement can introduce unexpected delay." This is a real concern in practice but the framing as a generalizable TYPICAL claim is too strong. On modern 7nm and 5nm nodes with automated place-and-route, Wallace/Dadda trees are routinely synthesized to high frequencies. The "TYPICAL" tag is overreaching for a claim that is highly node- and tool-flow-dependent.
+
+18. **The "FDIV bug transferred by analogy" caveat is incomplete.** The document correctly notes that FP and integer SRT use different quotient-digit sets and selection functions, so the lessons are transferred by analogy. However, the caveat should also note that integer SRT dividers do not have the same scale of historical bugs as FP SRT dividers in published designs, and the Pentium FDIV bug is the canonical example precisely because FP dividers are the most prominent historical case. The "transferred by analogy" framing is correct but understates that the analogy is the primary basis for the SRT verification concern, not direct evidence of integer SRT bugs.
+
+19. **The "Two rows per cycle" iterative radix-4 area description is internally inconsistent.** The document states "the area cost of the second CSA is not a simple 'doubling': the second CSA operates on the full sum-and-carry width of the first, so the additional area is closer to the cost of one full-width CSA, and the per-cycle critical path lengthens." This is correct but the conclusion "the area cost is closer to the cost of one full-width CSA" is a strange way to express it. A second full-width CSA on top of the first is, by definition, approximately one full-width CSA of additional area (i.e., a doubling of CSA area). The phrasing is convoluted but technically not wrong; it could be clearer.
+
+20. **The document does not discuss the latency of the quotient-conversion step in radix-4 SRT or its on-the-fly variant.** Standard radix-4 SRT dividers use an on-the-fly quotient-conversion (OFC) technique to avoid the final conversion step latency. The document discusses the "final quotient-conversion step" as if it is always a separate cycle, but OFC can absorb it into the selection-step critical path. This is a substantive omission in the description of SRT divider latency and the comparison table's "16 + conversion" framing.
+
+21. **The document is missing alternatives.** Specifically:
+   - **Combined MUL/MULH datapath with early termination** (similar to the variable-latency divider) is not discussed.
+   - **Use of a Wallace/Dadda tree for the upper half only (MULH path)** with a separate simpler datapath for MUL, which is a known low-area technique.
+   - **Dual-issue MUL pipelines** (two independent MUL units, each with 1/2 throughput) are not discussed as a throughput-extension alternative.
+   - **DSP-style saturating multiply** for embedded use cases is not discussed.
+   - **Use of the FP multiplier for integer multiplication with format conversion** (when the FP pipeline is idle) is not discussed as a software/compiler-managed alternative.
+
+22. **The document does not discuss the impact of the FP unit's existence on the integer MUL/DIV design.** The document mentions FP sharing in Alternative G but does not analyze the impact on the integer MUL/DIV design if the FP unit does not exist (e.g., XH-1 has no FP) or if the FP pipeline is shallow (e.g., 2-stage FPU where sharing provides minimal benefit). The interaction is one-sided.
+
+REQUIRED_FIXES:
+
+- Fix the radix-4 SRT digit-set and quotient-representation description (Issue 1). Specify whether the partial remainder is in carry-save form or non-redundant form, and whether the quotient digits are redundant or non-redundant. Use the standard formulation.
+
+- Remove or qualify the specific "+2 entry" claim about the Pentium FDIV bug (Issue 2). Mark the specific defect mechanism as TYPICAL or remove it. The fact that the bug was a missing-entry defect in the SRT PLA is sufficient.
+
+- Correct the radix-8 row count (Issue 3) and clarify the sign-handling mechanism. Use the standard Modified Booth encoding formulation: 22 rows (or 21 with MSB fragment handled by sign extension), with sign-extension incorporated into the existing rows, not a separate row.
+
+- Fix the radix-8 4× multiple description (Issues 4, 15). The canonical 4× multiple is a left-shift by 2, not an addition. Also clarify the ±3× implementation as a carry-save form, not an explicit addition.
+
+- Reconcile the MULH/MULHSU "shared array" claims (Issue 5). Explicitly state whether the MULH/MULHSU datapaths share the underlying array with sign-handling at the edges, or whether they are distinct datapaths. Do not present these as three separate claims that the reader must reconcile.
+
+- Fix the radix-2 SRT framing (Issue 6). State clearly that radix-2 SRT has the same worst-case iteration count as non-restoring division; the advantage of SRT is in the redundant-form datapath, not the iteration count. Correct or remove the Alternative C "Faster than naive subtractive" claim.
+
+- Clarify the SRT pipelining assumption in the Comparison table (Issue 7). State whether the SRT divider in the table is pipelined or non-pipelined, and add a pipelined SRT row if the MUL row is pipelined.
+
+- Remove or qualify the named-design attribution for the MULH shared-array pattern (Issue 8). The claim "common case in published RV64 implementations (e.g., BOOM, XiangShan, some SiFive designs)" is unsupported by citations. Either cite specific sources or remove the named designs.
+
+- Resolve the cross-cutting recommendation contradiction (Issue 9). Make a single defensible conditional recommendation rather than a conditional that effectively defers the choice.
+
+- Qualify the 128-core verification claim (Issue 10). Distinguish single-core integration verification (done once) from multi-core cross-core verification (a distinct effort). Do not state that "running the same integration suite 128× does not add coverage" without distinguishing the scopes.
+
+- Add the missing radix-4 "two rows per cycle" row to the Comparison table (Issue 13) and add the missing alternatives listed in Issue 21.
+
+- Add discussion of on-the-fly quotient conversion for radix-4 SRT (Issue 20).
+
+- Address the missing FP-interaction analysis (Issue 22).
+
+- Address the radix-4 PPG verification cost understatement (Issue 11) and the Goldschmidt/Newton-Raphson distinction (Issue 12).
+
+CONFIDENCE: HIGH

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.round1.md

@@ -0,0 +1,308 @@
+# Multiply/Divide Unit Design for the XH-1 Processor
+
+## Status
+
+**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions.
+
+## Abstract
+
+This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on the pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt/Newton-Raphson dividers, and iterative reciprocal-multiplication) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so recommendations are conditional on those upstream decisions.
+
+## Research Question
+
+> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?
+
+Specifically:
+
+- How should the unit be pipelined relative to the rest of the core?
+- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports) or remain isolated?
+- How should division throughput be traded against area and verification cost?
+- What is the impact of the choice on multi-core contention for shared execution resources, if any?
+
+## Background
+
+The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:
+
+- `MUL` (lower 64 bits of signed × signed)
+- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
+- `DIV`, `DIVU` (signed/unsigned quotient)
+- `REM`, `REMU` (signed/unsigned remainder)
+
+Critical properties of this ISA slice that drive microarchitecture:
+
+- **Wide-operand upper-multiply (UMUL):** Producing the upper 64 bits of a 64×64→128-bit product is approximately twice the area of the lower-64-bit result, since it cannot reuse a 64×64→64 multiplier without additional logic.
+- **Division latencies:** A non-trivial iterative divider for 64-bit operands requires 32 to 64 reduction steps, dominating pipeline depth if fully combinational.
+- **Signed semantics:** MULHSU and DIVU/REMU require careful sign-handling that complicates early-exit logic.
+- **Throughput vs. latency decoupling:** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end.
+
+The XH-1 is a 128-core machine. Decisions in the MUL/DIV unit replicate 128×, so per-core area and verification effort dominate. There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).
+
+**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, and target process node for XH-1 are all unknown.
+
+## Existing Approaches
+
+The following approaches are well-established in the literature and commercial designs. No specific citation is invented here; references to canonical techniques are sufficient.
+
+### 1. Shift-and-Add Multiplier (Iterative)
+
+- **Mechanism:** A 64-bit multiplier is implemented as a 64-cycle state machine, one partial-product bit per cycle, with a 129-bit accumulator.
+- **Latency:** 64 cycles (signed) or 32 cycles (sign-preconditioned) before result available.
+- **Throughput:** 1 multiply per ~64 cycles.
+- **Area:** Very small. Roughly one 64-bit adder + one shifter + one 129-bit accumulator register.
+- **Power:** Low. Minimal clocked area.
+- **Verification:** Low complexity. Straightforward to model and exhaustively test small operand widths.
+- **Use case:** Embedded in-order cores (e.g., RV32I designs where MUL/DIV are infrequent and latency-tolerant). Generally unsuitable for high-performance 64-bit cores.
+
+### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)
+
+- **Mechanism:** Booth recoding reduces partial products to ceil(n/2). A radix-4 scheme halves the iteration count. Implemented either as a combinational Wallace/Dadda tree, or iteratively over ceil(64/2) = 32 cycles.
+- **Latency:** 32 cycles iterative, ~8–16 cycles pipelined (depending on adder tree depth).
+- **Throughput:** 1 multiply per 32 cycles iterative, 1/cycle fully pipelined.
+- **Area:** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA.
+- **Power:** Moderate to high. The Wallace tree toggles aggressively.
+- **Verification:** Moderate. Corner cases around operand sign and the `MULHSU` path require careful directed tests.
+- **Use case:** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.
+
+### 3. Radix-8 or Radix-16 Booth Multiplier
+
+- **Mechanism:** Higher-radix Booth recoding (radix-8, radix-16) further reduces partial products by 3× or 4× at the cost of harder partial-product generation (3× or 5× multiples).
+- **Latency:** Fewer pipeline stages for the same throughput target, or higher throughput for the same area.
+- **Throughput:** 1/cycle or better.
+- **Area:** Larger partial-product generator; smaller adder tree. Net area roughly comparable to radix-4.
+- **Power:** Mixed. Fewer adder levels, but more complex PP generation.
+- **Verification:** Higher. Radix-8+ PPGs have more corner cases.
+- **Use case:** High-frequency designs where the critical path is in the adder tree, not the PPG.
+
+### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)
+
+- **Mechanism:** Standard shift-subtract over 32 to 64 cycles. Produces quotient (and optionally remainder) one bit per cycle.
+- **Latency:** 32 to 64 cycles.
+- **Throughput:** 1 divide per 32–64 cycles.
+- **Area:** Small. A 64- or 65-bit ALU with quotient/remainder registers.
+- **Power:** Low.
+- **Verification:** Moderate. The signed-dividend/divisor path and the division-by-zero convention (RISC-V returns -1) require explicit verification.
+- **Use case:** In-order cores with low expected DIV frequency.
+
+### 5. Radix-4/8 SRT Divider
+
+- **Mechanism:** Higher-radix SRT produces 2 or more quotient bits per iteration by selecting one of several shifted multiples of the divisor.
+- **Latency:** 16 to 32 cycles.
+- **Throughput:** One divide per 16–32 cycles.
+- **Area:** Substantially larger than subtractive. Requires a redundant quotient representation (carry-save) and a quotient-digit selection table.
+- **Power:** Higher.
+- **Verification:** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction is a known source of silicon bugs in commercial designs.
+- **Use case:** High-frequency OoO cores needing higher DIV throughput.
+
+### 6. Goldschmidt / Newton-Raphson Divider (Reciprocal Multiplication)
+
+- **Mechanism:** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Effectively performs division using a fast multiplier.
+- **Latency:** A few iterations of multiply-add. Amortized low latency if the multiplier is fast.
+- **Throughput:** Bounded by the multiplier.
+- **Area:** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
+- **Power:** Low marginal cost on top of the multiplier.
+- **Verification:** High. The accuracy of the final iteration relative to the rounding-mode requirements (RISC-V round-toward-zero) is a common bug source.
+- **Use case:** Designs that already have a fast pipelined multiplier and want a small, fast divider.
+
+### 7. Shared MUL/DIV Iterative Unit (Multiplexed)
+
+- **Mechanism:** A single iterative datapath (shift-add) handles both MUL and DIV by reconfiguring its datapath between operations.
+- **Latency:** Same as iterative, but the unit cannot serve MUL and DIV concurrently.
+- **Throughput:** MUL and DIV contend for the same unit.
+- **Area:** Smallest. The most area-efficient option.
+- **Power:** Lowest.
+- **Verification:** Low to moderate. Single datapath, but dual-purpose microcode/sequencer.
+- **Use case:** Cost-sensitive cores.
+
+## Alternative Designs
+
+Beyond the standard taxonomy, several non-obvious variants are worth considering:
+
+### A. Pipelined Multiplier + Sequential Divider (Split Unit)
+
+A fully pipelined radix-4 multiplier (e.g., 4-cycle latency) is paired with an independent 32-cycle sequential divider. The two units have separate reservation/issue logic.
+
+- **Rationale:** MUL is far more frequent than DIV in most workloads. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches the workload asymmetry.
+- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.
+
+### B. Variable-Latency Divider (Speculative / Early-Quit)
+
+Produce a 32-bit approximate quotient, sign-extend, and perform a single correction step. In many real programs the divisor has small magnitude, and the early-quit path saves cycles.
+
+- **Risk:** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core.
+
+### C. Radix-2 SRT with Carry-Save Quotient + Software Fixup
+
+A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.
+
+- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step.
+
+### D. Pipelined 2-bit-per-cycle "Naïve" Divider
+
+Iterate two shift-subtract steps per cycle. Doubles divider throughput without an SRT selection table. Latency roughly halved vs. radix-1.
+
+- **Cost:** Two 64-bit adders and a longer critical path. Area is moderate.
+
+### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Multiply
+
+A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations (e.g., 4–8 cycles).
+
+- **Cost:** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs. This typically requires a final exact-fixup step (one or two multiplies plus a comparison), and the precision / error analysis is non-trivial.
+
+## Comparison
+
+| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort | Notes |
+|---|---|---|---|---|---|---|
+| Shift-add MUL / subtractive DIV (iterative, shared) | 32–64 | ~1/32–1/64 | 0.3–0.5× | 0.3–0.5× | Low | Area-optimal, latency-poor |
+| Radix-4 MUL + subtractive DIV | 32 (MUL) / 32–64 (DIV) | 1/32–1/64 | 0.7–1.0× | 0.7–1.0× | Moderate | Balanced, common in mid-range RV64 |
+| Radix-4 MUL (pipelined) + SRT DIV | 4–8 (MUL) / 16–32 (DIV) | 1/cycle (MUL) | 1.0–1.4× | 1.0–1.5× | High | Desktop-class; verification-heavy |
+| Radix-8 MUL (pipelined) + Newton-Raphson DIV | 2–4 (MUL) / 4–8 (DIV) | ≥1/cycle | 1.2–1.6× | 1.2–1.8× | High | High-performance, requires careful rounding-fixup |
+| Pipelined radix-4 MUL + iterative DIV (split) | 4–8 (MUL) / 32–64 (DIV) | 1/cycle (MUL) | 0.9–1.2× | 0.9–1.2× | Moderate | Workload-asymmetric; RECOMMENDATION-CANDIDATE |
+| 2-bit-per-cycle naïve DIV | 16–32 | 1/16–1/32 | 0.9–1.1× | 0.9–1.1× | Moderate | Compromise; no SRT selection table |
+
+**Numbers are illustrative engineering estimates, not benchmark data.** The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1.
+
+## Advantages
+
+The leading candidates each have a distinct strength profile:
+
+- **Iterative shared unit:** Smallest per-core area and lowest power, multiplying directly into 128-core replication savings.
+- **Pipelined radix-4 MUL + iterative DIV (split):** Best workload asymmetry match; MUL throughput is high (common case), DIV cost is contained.
+- **Pipelined radix-4 MUL + SRT DIV:** Highest predictable throughput on both operations; minimal front-end exposure.
+- **Newton-Raphson DIV on top of fast MUL:** Reuses the multiplier's silicon; area-efficient if the multiplier is already large.
+
+## Disadvantages
+
+- **Iterative shared unit:** Latency directly stalls the pipeline in an in-order core. DIV latencies of 30–60 cycles are unacceptable for tight feedback loops.
+- **Pipelined radix-4 MUL + iterative DIV:** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
+- **Pipelined radix-4 MUL + SRT DIV:** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs. The verification cost is multiplied 128× in replication effort.
+- **Newton-Raphson DIV:** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean spec for the correction step.
+
+## XH-1 Considerations
+
+**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:
+
+1. **128-core replication amplifies per-core area and verification cost.** A 1.5× area MUL/DIV unit is 1.5× across all 128 cores, not just one. The die-area cost is severe.
+2. **Per-core issue width and in-order/OoO status are not established.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not.
+3. **128 cores imply a tile- or mesh-style interconnect.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations.
+4. **Verification cost is replicated.** High-effort designs (SRT, Newton-Raphson fixup) need 128× the formal and random-verification runs.
+
+**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.
+
+## 128-Core Scalability
+
+The MUL/DIV unit is per-core and not shared across cores (in the absence of a globally-shared execution unit, which is unusual for a 128-core design). Scalability considerations:
+
+- **No coherence problem.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
+- **No cross-core contention.** Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior.
+- **Verification parallelism.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once, but its integration with the core's pipeline must be verified 128×, unless formal methods prove equivalence.
+- **Area-budget pressure.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
+- **Power-grid and clock distribution.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. Power delivery and clock skew must be analyzed for the replicated load.
+
+**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128.
+
+## Performance Considerations
+
+MUL/DIV performance interacts with the rest of the core in two ways:
+
+1. **Latency exposure.** In an in-order core, MUL latency stalls the front-end. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
+2. **Throughput-bound on dependent chains.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.
+
+**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.
+
+## Area Considerations
+
+Indicative relative area estimates (engineering estimates, not benchmark data):
+
+| Unit | Relative Area (per core) |
+|---|---|
+| Iterative MUL + iterative DIV (shared) | ~0.3–0.5× of "full" unit |
+| Radix-4 pipelined MUL + iterative DIV (split) | ~0.7–0.9× |
+| Radix-4 pipelined MUL + radix-4 SRT DIV | ~1.0–1.2× |
+| Radix-8 pipelined MUL + Newton-Raphson DIV | ~1.2–1.5× |
+
+**Per 128 cores, a "full" 1.0× unit is 128 unit-areas.** A 0.3× unit is 38 unit-areas — a significant die-area delta. The XH-1 per-core area budget must be defined before this can be quantified.
+
+## Power and Energy Considerations
+
+Power and energy per operation, ranked from most to least efficient:
+
+- **Iterative:** Low per-cycle power, but high per-operation energy × time product (many cycles × dynamic power).
+- **Pipelined MUL + iterative DIV:** Low per-op MUL energy, high per-op DIV energy.
+- **Pipelined MUL + SRT DIV:** High per-cycle power, but low per-op energy.
+- **Pipelined MUL + Newton-Raphson DIV:** Per-op energy is a small multiple of MUL energy; competitive.
+
+**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative DIV is a reasonable energy-vs-area compromise.
+
+## Implementation Considerations
+
+- **Wallace/Dadda tree synthesis risk.** Compressor trees are notoriously hard to place-and-route at high frequency on modern nodes. A poorly placed adder tree can cost 100+ ps of unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon.
+- **PPG and Booth recoder verification.** Radix-4 PPGs are easy to verify by simulation; radix-8+ PPGs require more corner cases.
+- **SRT selection table correctness.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
+- **RISC-V division-by-zero convention.** `-1` for `DIV`/`DIVU`, `dividend` for `REM`/`REMU`. Must be implemented explicitly; the design must not return a trap.
+- **Pipeline interlocks.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
+- **Physical design replication.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication.
+
+## Verification Considerations
+
+Verification cost is the dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:
+
+- **Radix-2/4 shift-add and subtractive:** Lowest. Exhaustive simulation at reduced widths is tractable.
+- **Radix-4 Booth + iterative DIV:** Moderate. Corner cases around `MULHSU` and signed division overflow.
+- **SRT:** High. SRT selection-table bugs are famous in industry (e.g., the Pentium FDIV bug, though that was a different radix); verification typically requires formal proofs of the selection function.
+- **Newton-Raphson:** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
+- **Replication factor:** A bug in the MUL/DIV unit is potentially a bug in all 128 cores. Bugs that manifest only at certain operand combinations are particularly dangerous.
+
+**RECOMMENDATION:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.
+
+## Software Considerations
+
+- **Compiler expectations.** GCC and LLVM default to MUL/DIV idioms for multiplication by constants when the multiplier is not auto-converted. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences.
+- **Library code.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
+- **System software.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
+- **128-core interaction.** The system stack (kernel, hypervisor) will run on some subset of the 128 cores. There is no asymmetric design implication: every core is equal.
+
+**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.
+
+## Recommendation
+
+**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:
+
+1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
+2. The per-core area and power budget.
+3. The target workload mix and software ecosystem.
+
+**Conditional recommendations** (to be revisited once the above are known):
+
+- **If XH-1 targets an in-order core with tight area budget:** A single shared iterative shift-add MUL and subtractive DIV unit is the smallest, easiest-to-verify choice. MUL/DIV latency will be high, but the area × 128 replication argument is decisive.
+- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** A pipelined radix-4 Booth multiplier (4–8 stage pipeline) paired with a radix-4 SRT or 2-bit-per-cycle naïve divider is the natural choice. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle.
+- **If the per-core area budget is moderate and the workload is balanced:** A pipelined radix-4 MUL with an iterative 32-cycle subtractive DIV (the "split" approach) is a strong compromise.
+
+**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.
+
+## Confidence
+
+| Topic | Confidence |
+|---|---|
+| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
+| Relative area and power rankings | Medium (qualitative, no synthesis data) |
+| Per-cycle latency numbers | Medium (typical, but node- and target-frequency-dependent) |
+| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
+| Specific recommendation | **Insufficient evidence** to commit |
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
+2. What is the per-core area budget, in absolute terms or as a fraction of die area?
+3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
+4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused.
+5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
+6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
+7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power; synthesis-per-core favors design flexibility.
+8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
+9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
+10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.
+
+## Sources
+
+- **INSUFFICIENT EVIDENCE.** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
+- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as engineering estimates or as canonical background knowledge in the field of computer arithmetic.

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.round2.md

@@ -0,0 +1,367 @@
+# Multiply/Divide Unit Design for the XH-1 Processor
+
+## Status
+
+**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions. Quantitative comparisons are presented only as qualitative relative magnitudes, never as benchmark figures.
+
+## Abstract
+
+This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on the pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt dividers, Newton-Raphson dividers, subtractive dividers, and SRT dividers) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so any recommendations are conditional on those upstream decisions.
+
+## Research Question
+
+> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?
+
+Specifically:
+
+- How should the unit be pipelined relative to the rest of the core?
+- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports, FP multiplier) or remain isolated?
+- How should division throughput be traded against area and verification cost?
+- What is the impact of the choice on multi-core contention for shared execution resources, if any?
+
+## Background
+
+The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:
+
+- `MUL` (lower 64 bits of signed × signed)
+- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
+- `DIV`, `DIVU` (signed/unsigned quotient)
+- `REM`, `REMU` (signed/unsigned remainder)
+
+Critical properties of this ISA slice that drive microarchitecture:
+
+- **Wide-operand upper-multiply (UMUL):** Producing the upper 64 bits of a 64×64→128-bit product is *not* twice the area of a lower-only 64×64→64 multiplier when the multiplier is implemented as a single full-width partial-product / carry-save tree. The 64×64→128 result is generated by the same array; the carry-save adder tree is slightly deeper and wider, and a final carry-propagate adder is needed to collapse the upper half. Standard practice in open RISC-V cores (e.g., Rocket, BOOM, XiangShan) is to share one partial-product array between `MUL`, `MULH*`, and the FP multiplier, with operand- and result-muxing. The "upper-only" mode is therefore a small incremental cost over the lower-only mode, not a doubling.
+- **Division latencies:** A non-trivial iterative divider for 64-bit operands requires 32 to 64 reduction steps, dominating pipeline depth if fully combinational.
+- **Signed semantics:** `MULHSU` is conventionally implemented by sign- or zero-extending the signed operand to a full-width signed/unsigned operand and reusing the unsigned 64×64→128 array; the verification burden is therefore small once the unsigned array is correct. By contrast, signed division has two non-trivial edge cases: division by zero (RISC-V returns `-1` for `DIV`/`DIVU`, and the dividend for `REM`/`REMU`) and the signed overflow case `INT64_MIN / -1`, where the mathematical quotient is `INT64_MIN` itself. Hardware that does not detect this case explicitly will return the wrong result.
+- **Throughput vs. latency decoupling:** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end unless explicit forwarding is provided.
+
+The XH-1 is a 128-core machine. Decisions in the MUL/DIV unit replicate 128×, so per-core area and verification effort dominate. There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).
+
+**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, and target process node for XH-1 are all unknown.
+
+## Existing Approaches
+
+The following approaches are well-established in the literature and commercial designs. References: standard computer-arithmetic texts (e.g., Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*) cover these techniques in canonical form. No XH-1-internal prior art exists.
+
+### 1. Shift-and-Add Multiplier (Iterative)
+
+- **Mechanism:** A 64-bit multiplier is implemented as a state machine that processes one partial-product bit per cycle against a 128-bit accumulator (or a 129-bit accumulator with a sign-preconditioned variant). Signed operands are typically sign-extended, not handled by halving the iteration count.
+- **Latency:** Approximately 64 cycles for a 64-bit operand, plus a small constant for sign/result correction.
+- **Throughput:** One multiply per ~64 cycles.
+- **Area:** Very small. Roughly one wide adder + one shifter + one accumulator register.
+- **Power:** Low. Minimal clocked area per cycle.
+- **Verification:** Low complexity. Straightforward to model and exhaustively test at small operand widths.
+- **Use case:** Embedded in-order cores where MUL/DIV are infrequent and latency-tolerant. Generally unsuitable for high-performance 64-bit cores.
+
+### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)
+
+- **Mechanism:** Booth recoding reduces partial products to ceil(n/2). Over a 64-bit operand, the standard radix-4 Booth encoding produces 32 partial-product rows, and an *iterative* radix-4 multiplier performs the additions in roughly 16 cycles (two operand bits consumed per iteration against a running accumulator). Implemented as a single combinational Wallace/Dadda tree, the same 32 partial-product rows are summed in one cycle, with the tree depth determining the achievable clock period.
+- **Latency:** ~16 cycles iterative, or one combinational tree of ~8–16 levels of CSA + a final CPA, optionally broken into pipeline registers.
+- **Throughput:** One multiply per 16 cycles iterative; 1/cycle if the array is fully pipelined.
+- **Area:** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA.
+- **Power:** Moderate to high. The Wallace/Dadda tree toggles aggressively, and clock-tree load on a replicated array is non-trivial.
+- **Verification:** Moderate. The corner cases that matter are the signed overflow cases (not the `MULHSU` path, which is essentially free given a correct unsigned array).
+- **Use case:** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.
+
+### 3. Radix-8 or Radix-16 Booth Multiplier
+
+- **Mechanism:** Higher-radix Booth recoding further reduces partial-product rows (radix-8 reduces by 3×, radix-16 by 4× relative to radix-2). The cost is in the partial-product generator (PPG): radix-8 requires 3× multiples; radix-16 requires 3×, 5×, 7× multiples (or a 3×/5× combination plus a higher-order term) and is therefore considerably more complex than radix-4.
+- **Latency:** The fully pipelined radix-4 array can already achieve 1/cycle throughput; higher radices reduce the *depth* of the adder tree (fewer partial-product rows to sum) and therefore either shorten the critical path or allow fewer pipeline stages. The throughput is not increased beyond 1/cycle unless the array is duplicated.
+- **Throughput:** 1/cycle for a single pipelined array; not inherently higher than radix-4.
+- **Area:** Larger PPG; smaller (shallower) adder tree. Net area is roughly comparable to radix-4.
+- **Power:** Mixed. Fewer adder levels, but more complex PPG.
+- **Verification:** Higher. Radix-8+ PPGs have more corner cases and the recoding is harder to prove correct.
+- **Use case:** High-frequency designs where the critical path is in the adder tree, not the PPG.
+
+### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)
+
+- **Mechanism:** Standard shift-subtract over the operand width. Produces quotient (and optionally remainder) one bit per cycle.
+- **Latency:** Roughly 64 cycles for a 64-bit operand (plus a small constant for sign correction).
+- **Throughput:** One divide per ~64 cycles.
+- **Area:** Small. A 64- or 65-bit ALU with quotient/remainder registers.
+- **Power:** Low.
+- **Verification:** Moderate. The division-by-zero convention, the `INT64_MIN / -1` overflow case, and the `REM`/`REMU` dividend-return case must all be implemented and tested explicitly. The signed-dividend path is the principal source of bugs.
+- **Use case:** In-order cores with low expected DIV frequency.
+
+### 5. Radix-4 SRT Divider
+
+- **Mechanism:** Higher-radix SRT produces 2 (radix-4) or more quotient digits per iteration by selecting one of several shifted multiples of the divisor from a selection table indexed by a truncated partial remainder.
+- **Latency:** ~16 to 32 cycles for a 64-bit operand.
+- **Throughput:** One divide per 16–32 cycles.
+- **Area:** Substantially larger than subtractive. Requires a redundant (carry-save) quotient representation, a quotient-digit selection table, and partial-quotient error-correction logic.
+- **Power:** Higher.
+- **Verification:** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction has been the source of silicon bugs in commercial designs (the classic example is the Pentium FDIV bug, which was a radix-4 SRT selection-table defect — the same general technique, not a fundamentally different radix). Verification typically requires formal proofs of the selection function over reduced operand widths plus extensive directed testing.
+- **Use case:** High-frequency OoO cores needing higher DIV throughput.
+
+### 6. Goldschmidt Divider (Reciprocal Multiplication)
+
+- **Mechanism:** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Each iteration multiplies both the partial remainder and the partial quotient by a correction factor derived from a short reciprocal estimate. Distinct from Newton-Raphson (see §7).
+- **Latency:** A few multiply iterations. Amortized low latency if the multiplier is fast.
+- **Throughput:** Bounded by the multiplier.
+- **Area:** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
+- **Power:** Low marginal cost on top of the multiplier.
+- **Verification:** High. The final iteration must converge to enough bits of precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step. The accuracy analysis is non-trivial and historically a bug source.
+- **Use case:** Designs that already have a fast pipelined multiplier and want a small, fast divider.
+
+### 7. Newton-Raphson Divider (Reciprocal Multiplication)
+
+- **Mechanism:** Iteratively refine an initial estimate of the divisor's reciprocal using a Newton-Raphson step, then multiply the dividend by the refined reciprocal. Each iteration squares the error, so convergence is quadratic. Distinct from Goldschmidt, which uses a multiplicative correction on both the partial remainder and the partial quotient simultaneously; the two algorithms have different error dynamics and different fixup requirements.
+- **Latency:** A few iterations of multiply-add. Typically fewer iterations than Goldschmidt to reach a given precision, but each iteration is a full multiply.
+- **Throughput:** Bounded by the multiplier.
+- **Area:** Reuses the multiplier. Adds lookup-table ROM for the initial estimate and modest control logic.
+- **Power:** Low marginal cost on top of the multiplier.
+- **Verification:** High. The final-step rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the fixup step.
+- **Use case:** Designs with a fast pipelined multiplier that want a low-latency divider.
+
+### 8. Shared MUL/DIV Iterative Unit (Multiplexed)
+
+- **Mechanism:** A single iterative datapath handles both MUL and DIV by reconfiguring its datapath between operations.
+- **Latency:** Same as the underlying iterative unit; the unit cannot serve MUL and DIV concurrently.
+- **Throughput:** MUL and DIV contend for the same unit.
+- **Area:** Smallest. The most area-efficient option.
+- **Power:** Lowest.
+- **Verification:** Low to moderate. Single datapath, but dual-purpose microcode/sequencer.
+- **Use case:** Cost-sensitive cores.
+
+## Alternative Designs
+
+Beyond the standard taxonomy, several non-obvious variants are worth considering.
+
+### A. Pipelined Multiplier + Sequential Divider (Split Unit)
+
+A fully pipelined radix-4 multiplier (e.g., 4-cycle latency) is paired with an independent sequential subtractive divider. The two units have separate reservation/issue logic.
+
+- **Rationale:** Under many server, desktop, and general-purpose workloads, MUL is more frequent than DIV, but the ratio is workload-dependent and should not be assumed a priori. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches a plausible workload asymmetry.
+- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.
+
+### B. Variable-Latency Divider (Speculative / Early-Quit)
+
+Produce a partial-width approximate quotient, sign-extend, and perform a single correction step on the remaining bits. The early-quit path saves cycles when the divisor has small magnitude.
+
+- **Risk:** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core. This can be partially mitigated by a fixed maximum latency with early completion, at the cost of additional control logic.
+
+### C. Radix-2 SRT with Carry-Save Quotient + Software/Hardware Fixup
+
+A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.
+
+- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step.
+
+### D. Pipelined 2-bit-per-cycle "Naïve" Divider
+
+Iterate two shift-subtract steps per cycle. Roughly halves divider latency relative to radix-1 subtractive without requiring an SRT selection table.
+
+- **Cost:** Two wide adders and a longer critical path. Area is moderate.
+
+### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Newton-Raphson
+
+A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations.
+
+- **Cost:** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step (one or two multiplies plus a comparison). The precision / error analysis is non-trivial.
+
+### F. Shared Multi-Cycle Divider Across Cores (Divider Co-Processor)
+
+A small number of high-throughput dividers (e.g., 4 or 8) placed at fixed points in the fabric and dispatched to by cores via a memory-mapped or message interface. The dividers are not private to any core.
+
+- **Rationale:** Avoids replicating the divider 128×. Trades single-core latency (now includes a fabric round-trip) for amortized area.
+- **Cost:** NOC traffic, dispatch latency, contention at the divider, and software-visible ABI changes (or a transparent-but-slow trap path).
+- **Status:** Unusual but not unprecedented in accelerator-rich many-core designs.
+
+### G. FP / Integer Multiplier Sharing
+
+Share the integer multiplier's partial-product array and adder tree with the FP pipeline. Standard in Rocket, BOOM, and most SiFive cores.
+
+- **Rationale:** Avoids replicating a wide datapath. The FP pipeline also benefits from a fast multiplier.
+- **Cost:** Cross-unit scheduling and bypassing complexity. The integer and FP pipelines may have different latency targets.
+
+### H. Latency-Tolerant In-Order MUL/DIV
+
+Even a multi-cycle iterative MUL/DIV may be tolerable in an in-order core if the result-bus supports forwarding directly from the MUL/DIV output to dependent consumers, bypassing the register file writeback-read path.
+
+- **Cost:** Forwarding path length and bypass-network complexity scale with MUL/DIV latency.
+
+### I. Interaction with the "B" (Bitmanip) Extension
+
+The RISC-V Bitmanip extension introduces MUL/DIV-adjacent operations (e.g., `CLZ`, `CTZ`, `MIN`, `MAX`, bit-extract/deposit, and several pseudo-multiplication idioms such as `RORI` and `SH*ADD`). If the B extension is in scope, the MUL/DIV unit may either be reused for some of these (e.g., via the ALU) or augmented with dedicated bitmanip datapath. The decision is interdependent with the MUL/DIV choice and is flagged as an open question below.
+
+## Comparison
+
+The following table presents *qualitative* relative magnitudes only. No node, frequency, or synthesis data is available for XH-1, so quantitative ratios are not asserted.
+
+| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort |
+|---|---|---|---|---|---|
+| Shift-add MUL / subtractive DIV (iterative, shared) | ~64 | ~1/64 | Smallest | Smallest | Low |
+| Iterative radix-4 MUL + subtractive DIV | ~16 (MUL) / ~64 (DIV) | ~1/16 (MUL) | Small to moderate | Small to moderate | Low to moderate |
+| Radix-4 array MUL (pipelined) + subtractive DIV (split) | ~4–8 (MUL) / ~64 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
+| Radix-4 array MUL (pipelined) + radix-4 SRT DIV | ~4–8 (MUL) / ~16–32 (DIV) | 1/cycle (MUL) | Large | Large | High |
+| Radix-8 array MUL (pipelined) + Newton-Raphson or Goldschmidt DIV | ~3–6 (MUL) / ~4–8 (DIV) | 1/cycle (MUL) | Largest | Largest | High |
+| 2-bit-per-cycle naïve DIV (paired with radix-4 MUL) | ~4–8 (MUL) / ~32 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 MUL + iterative DIV (split) | ~4–8 (MUL) / ~64 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
+
+The relative magnitudes are illustrative and intended only to convey ordering. The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1.
+
+**INSUFFICIENT EVIDENCE:** Quantitative area, power, and energy comparisons cannot be made without a target node, frequency, and synthesis flow.
+
+## Advantages
+
+The leading candidates each have a distinct strength profile:
+
+- **Iterative shared unit:** Smallest per-core area and lowest power, multiplying directly into 128-core replication savings. Easiest to verify.
+- **Pipelined radix-4 MUL + iterative DIV (split):** Best workload-asymmetry match if MUL is in fact more frequent than DIV in the target workload; MUL throughput is high (common case), DIV cost is contained.
+- **Pipelined radix-4 MUL + SRT DIV:** Highest predictable throughput on both operations; minimal front-end exposure if the core is in-order.
+- **Newton-Raphson or Goldschmidt DIV on top of fast MUL:** Reuses the multiplier's silicon; area-efficient if the multiplier is already large.
+
+## Disadvantages
+
+- **Iterative shared unit:** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided.
+- **Pipelined radix-4 MUL + iterative DIV:** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
+- **Pipelined radix-4 MUL + SRT DIV:** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs (the Pentium FDIV bug being a radix-4 SRT defect). The verification cost is multiplied 128× in replication effort.
+- **Newton-Raphson / Goldschmidt DIV:** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean, formally-specified correction step.
+
+## XH-1 Considerations
+
+**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:
+
+1. **128-core replication amplifies per-core area and verification cost.** A larger MUL/DIV unit pays the same area cost across all 128 cores, not just one. The die-area cost is severe.
+2. **Per-core issue width and in-order/OoO status are not established.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not, unless explicit forwarding is provided.
+3. **128 cores imply a tile- or mesh-style interconnect.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations, unless a shared divider alternative (§F) is adopted.
+4. **Verification cost is replicated.** High-effort designs (SRT, Newton-Raphson fixup) need 128× the formal and random-verification runs.
+5. **Physical-design regularity matters under replication.** A small, regular MUL/DIV unit is easier to harden and replicate 128× than a complex, irregular SRT unit.
+
+**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.
+
+## 128-Core Scalability
+
+The MUL/DIV unit is per-core and not shared across cores by default. Scalability considerations:
+
+- **No coherence problem.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
+- **No cross-core contention** in the default per-core configuration. Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior. A shared-divider alternative (§F) changes this analysis.
+- **Verification parallelism.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once at the unit level, but its integration with the core's pipeline must be verified 128×, unless formal methods prove equivalence across replications.
+- **Area-budget pressure.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
+- **Power-grid and clock distribution.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. Power delivery (IR drop), clock skew across the replicated load, and dynamic power density must be analyzed for the replicated load.
+- **Scan and BIST.** A 128× replicated unit implies 128× the scan-chain length (if scan is per-core) or a partitioned BIST architecture. The choice affects DFT area and test time.
+- **Fault tolerance.** A defect in the MUL/DIV unit is potentially a defect in all 128 cores. This argues for either a hardened, characterized macro or built-in redundancy / sparing, depending on yield targets.
+- **Timing variation.** Across-die process variation affects 128 replicated units independently. A design that is timing-marginal at one corner may fail at another. Iterative designs are less sensitive to per-unit timing variation than deep-pipelined arrays.
+
+**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128. Prefer regular, hardenable structures over irregular ones that resist replication.
+
+## Performance Considerations
+
+MUL/DIV performance interacts with the rest of the core in two ways:
+
+1. **Latency exposure.** In an in-order core, MUL latency stalls the front-end unless explicit forwarding is provided. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
+2. **Throughput-bound on dependent chains.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.
+
+**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.
+
+## Area Considerations
+
+Relative area ordering, qualitative only (no synthesis data available):
+
+- Iterative MUL + iterative DIV (shared): smallest.
+- Iterative radix-4 MUL + subtractive DIV: small to moderate.
+- Pipelined radix-4 MUL + iterative DIV (split): moderate.
+- Pipelined radix-4 MUL + radix-4 SRT DIV: large.
+- Pipelined radix-8 MUL + Newton-Raphson / Goldschmidt DIV: largest.
+
+The XH-1 per-core area budget must be defined before any of the above can be quantified in absolute terms.
+
+**INSUFFICIENT EVIDENCE:** Absolute area figures require a process node and a synthesis flow.
+
+## Power and Energy Considerations
+
+Relative energy-per-operation ordering, qualitative only:
+
+- **Iterative:** Low per-cycle power, but high per-operation energy × time product (many cycles).
+- **Pipelined MUL + iterative DIV:** Low per-op MUL energy, high per-op DIV energy.
+- **Pipelined MUL + SRT DIV:** High per-cycle power, lower per-op energy than iterative.
+- **Pipelined MUL + Newton-Raphson / Goldschmidt DIV:** Per-op energy is a small multiple of MUL energy; competitive.
+
+**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative DIV is a reasonable energy-vs-area compromise, contingent on the workload.
+
+**INSUFFICIENT EVIDENCE:** Quantitative power and energy figures require a process node, a clock target, and a workload trace.
+
+## Implementation Considerations
+
+- **Wallace/Dadda tree synthesis risk.** Compressor trees are notoriously hard to place-and-route at high frequency on modern nodes. Poor placement can introduce unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon. (No specific delay figure is asserted; the qualitative risk is well-known in the literature.)
+- **PPG and Booth recoder verification.** Radix-4 PPGs are well-understood and tractable to verify; radix-8+ PPGs require more corner cases.
+- **SRT selection table correctness.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
+- **RISC-V division-by-zero and overflow conventions.** `-1` for `DIV`/`DIVU` on divide-by-zero; the dividend for `REM`/`REMU` on divide-by-zero; `INT64_MIN` for `INT64_MIN / -1` on signed overflow. These must be implemented explicitly; the design must not raise a trap.
+- **Pipeline interlocks.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
+- **Physical design replication.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication and are a physical-design risk under replication.
+
+## Verification Considerations
+
+Verification cost is the dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:
+
+- **Radix-2/4 shift-add and subtractive:** Lowest. Exhaustive simulation at reduced widths is tractable.
+- **Radix-4 Booth + iterative DIV:** Moderate. The hard cases are the signed division edge cases (division-by-zero, `INT64_MIN / -1`), not the `MULHSU` path. The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and `MULH` (with sign handling); `MULHSU` is a sign-extension of the signed operand to a full-width signed/unsigned form and is essentially free given a correct unsigned array.
+- **SRT:** High. SRT selection-table bugs are famous in industry (e.g., the Pentium FDIV bug was a radix-4 SRT selection-table defect). Verification typically requires formal proofs of the selection function over reduced widths and extensive directed testing.
+- **Newton-Raphson / Goldschmidt:** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
+- **Replication factor:** A bug in the MUL/DIV unit is potentially a bug in all 128 cores. Bugs that manifest only at certain operand combinations are particularly dangerous.
+
+**Preliminary verification strategy** (to be refined once the design choice is made):
+
+- **Unit-level:** Exhaustive simulation at reduced operand widths (e.g., 8, 12, 16 bits) for the core datapath. Formal equivalence checking between the RTL and a reference model written in a high-level specification language (e.g., Bluespec, Scala, or a C reference). For SRT or Newton-Raphson, formal proof of the selection function or the convergence step.
+- **Directed corner-case suite:** Explicit tests for division-by-zero, signed overflow (`INT64_MIN / -1`), the `REM`/`REMU` dividend-return case, `MULHSU` against a cross-checked reference, and the `MUL`-then-truncate boundary.
+- **Random / constrained-random:** At full width, comparing against a software reference. Coverage targets on the Booth recoder, PPG, and selection table.
+- **Integration:** Per-core pipeline integration verified 128× unless formal equivalence is established across replications.
+- **Post-silicon:** Microarchitectural validation suite, focused on MUL/DIV-intensive kernels (big-integer arithmetic, hashes, polynomial multiplications).
+
+**PROPOSAL:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.
+
+## Software Considerations
+
+- **Compiler behavior.** GCC and LLVM routinely use shift-and-add sequences for multiplication by small constants, and they may either emit `MUL` instructions or inline expansions depending on the cost model. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences, but the magnitude of this effect is workload- and compiler-version-dependent and should not be assumed.
+- **Library code.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
+- **System software.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
+- **128-core interaction.** The system stack (kernel, hypervisor) will run on some subset of the 128 cores. There is no asymmetric design implication: every core is equal in the default per-core configuration.
+
+**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.
+
+## Recommendation
+
+**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:
+
+1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
+2. The per-core area and power budget.
+3. The target workload mix and software ecosystem.
+
+**Conditional recommendations** (to be revisited once the above are known):
+
+- **If XH-1 targets an in-order core with tight area budget:** A single shared iterative shift-add MUL and subtractive DIV unit is the smallest, easiest-to-verify choice. MUL/DIV latency will be high; whether this is acceptable depends on whether explicit forwarding is provided.
+- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** A pipelined radix-4 Booth multiplier (4–8 stage pipeline) paired with a radix-4 SRT or 2-bit-per-cycle naïve divider is the natural choice. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle.
+- **If the per-core area budget is moderate and the workload is balanced:** A pipelined radix-4 MUL with an iterative subtractive DIV (the "split" approach) is a strong compromise.
+
+**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson / Goldschmidt rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.
+
+## Confidence
+
+| Topic | Confidence |
+|---|---|
+| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
+| Relative area, power, and energy rankings | Low to medium (qualitative ordering only; no synthesis data) |
+| Per-cycle latency numbers | Low to medium (typical, but node- and target-frequency-dependent) |
+| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
+| Specific recommendation | **Insufficient evidence** to commit |
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
+2. What is the per-core area budget, in absolute terms or as a fraction of die area?
+3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
+4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused or augmented.
+5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
+6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
+7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power and replication regularity; synthesis-per-core favors design flexibility.
+8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
+9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
+10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.
+11. Will the MUL/DIV unit be shared with the FP pipeline (as in Rocket / BOOM), or kept private to the integer pipeline?
+12. Will XH-1 adopt a shared multi-cycle divider across cores (Alternative F), or is a strictly per-core MUL/DIV unit required?
+
+## Sources
+
+- Canonical computer-arithmetic references: Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*. These cover the techniques surveyed above in standard form.
+- Open RISC-V core implementations (Rocket, BOOM, XiangShan, SiFive) provide reference designs for radix-4 array multipliers, iterative and SRT dividers, and FP/integer multiplier sharing. These are cited as implementation exemplars, not as XH-1 references.
+- **INSUFFICIENT EVIDENCE:** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
+- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as qualitative engineering estimates or as canonical background knowledge in the field of computer arithmetic.

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.round3.md

@@ -0,0 +1,380 @@
+# Multiply/Divide Unit Design for the XH-1 Processor
+
+## Status
+
+**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions. Quantitative comparisons are presented only as qualitative relative magnitudes, never as benchmark figures. Throughout this document, claims are tagged as one of:
+
+- **FACT** — well-established in the cited literature or in the RISC-V ISA specification.
+- **TYPICAL** — the common case across published designs; implementation-specific values may vary.
+- **ASSUMPTION** — an explicit premise the analysis depends on; should be revisited.
+- **PROPOSAL** — a design recommendation conditional on unresolved parameters.
+- **INSUFFICIENT EVIDENCE** — no defensible claim can be made without additional information.
+
+## Abstract
+
+This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt dividers, Newton-Raphson dividers, subtractive dividers, and SRT dividers) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so any recommendations are conditional on those upstream decisions.
+
+## Research Question
+
+> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?
+
+Specifically:
+
+- How should the unit be pipelined relative to the rest of the core?
+- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports, FP multiplier) or remain isolated?
+- How should division throughput be traded against area and verification cost?
+- What is the impact of the choice on multi-core contention for shared execution resources, if any?
+
+## Background
+
+**FACT.** The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:
+
+- `MUL` (lower 64 bits of signed × signed)
+- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
+- `DIV`, `DIVU` (signed/unsigned quotient)
+- `REM`, `REMU` (signed/unsigned remainder)
+
+Critical properties of this ISA slice that drive microarchitecture:
+
+- **Wide-operand upper-multiply (UMUL).** **FACT.** Producing the upper 64 bits of a 64×64→128-bit product is *not* twice the area of a lower-only 64×64→64 multiplier when the multiplier is implemented as a single full-width partial-product / carry-save tree. The 64×64→128 result is generated by the same array; the carry-save adder tree is slightly deeper and wider, and a final carry-propagate adder is needed to collapse the upper half. **TYPICAL.** Standard practice in open RISC-V cores (e.g., Rocket, BOOM, XiangShan) is to share one partial-product array between `MUL`, `MULH*`, and the FP multiplier, with operand- and result-muxing. The "upper-only" mode is therefore a small incremental cost over the lower-only mode, not a doubling. *Caveat: the actual incremental cost depends on whether the lower 64 bits must also be produced; the "share the array" pattern is the common case in published RV64 implementations (e.g., SiFive cores, BOOM), but specific silicon area deltas are design-dependent and not asserted here.*
+- **MULH and signed×signed handling.** **FACT.** `MULH` (signed×signed, upper half) is not obtained by simply reusing the unsigned 64×64→128 array with sign-corrected operands. The standard technique is Baugh-Wooley or Modified Booth with explicit sign-bit handling, which modifies the partial-product generation (sign-extension of the most-significant partial products) and the adder tree. The "essentially free" characterization elsewhere in this document is corrected here: while the underlying adder tree is shared, the partial-product array and the final CPA differ for the signed case, and verification must treat `MULH` as a distinct datapath. **`MULHSU` (signed×unsigned, upper half) is closer to "essentially free":** the signed operand can be sign-extended to 65 bits, the unsigned operand zero-extended, and the resulting 65×64 partial-product array produces the correct upper 64 bits with conventional unsigned-array semantics, modulo sign-correction of the most-significant partial products. Verification cost for `MULHSU` is small once the unsigned array is correct, but `MULH` requires its own verification pass.
+- **Division latencies.** **FACT.** A non-trivial iterative divider for 64-bit operands requires 32 to 64 reduction steps, dominating pipeline depth if fully combinational.
+- **Signed semantics.** **FACT.** RISC-V specifies the following for division edge cases:
+  - Division by zero: `DIV` and `DIVU` return `-1` (i.e., all bits set); `REM` and `REMU` return the dividend.
+  - Signed overflow: `INT64_MIN / -1` returns `INT64_MIN` (the mathematical quotient); the corresponding `REM` returns 0.
+  - The operation must not raise an exception; the hardware must produce the specified result.
+- **Throughput vs. latency decoupling.** **FACT.** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end unless explicit forwarding is provided.
+
+The XH-1 is a 128-core machine. **FACT.** Decisions in the MUL/DIV unit replicate 128×, so per-core area and verification effort dominate. **INSUFFICIENT EVIDENCE:** There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).
+
+**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, target process node, per-core area budget, and target workload mix for XH-1 are all unknown.
+
+## Existing Approaches
+
+The following approaches are well-established in the literature and commercial designs. **FACT.** Standard computer-arithmetic texts (Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*) cover these techniques in canonical form. No XH-1-internal prior art exists. Per-cycle latency figures given below are **TYPICAL** values for a 64-bit operand at a moderate clock target (e.g., sub-ns in a recent node); specific values are implementation- and node-dependent.
+
+### 1. Shift-and-Add Multiplier (Iterative)
+
+- **Mechanism:** **FACT.** A 64-bit multiplier is implemented as a state machine that processes one partial-product bit per cycle against a 128-bit accumulator (or a 129-bit accumulator with a sign-preconditioned variant). Signed operands are sign-extended; iteration count is not halved.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand, plus a small constant for sign/result correction.
+- **Throughput:** **TYPICAL.** One multiply per ~64 cycles (unit is not pipelined).
+- **Area:** **TYPICAL.** Very small. Roughly one wide adder + one shifter + one accumulator register.
+- **Power:** **TYPICAL.** Low. Minimal clocked area per cycle.
+- **Verification:** **TYPICAL.** Low complexity. Straightforward to model and exhaustively test at small operand widths.
+- **Use case:** **TYPICAL.** Embedded in-order cores where MUL/DIV are infrequent and latency-tolerant. Generally unsuitable for high-performance 64-bit cores.
+
+### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)
+
+- **Mechanism:** **FACT.** Booth recoding reduces partial products to ceil(n/2). For a 64-bit operand, standard radix-4 Booth encoding produces 32 partial-product rows. An *iterative* radix-4 multiplier accumulates these rows one or two at a time:
+  - **One row per cycle:** ~32 cycles, one CSA per cycle, smallest iterative area.
+  - **Two rows per cycle:** ~16 cycles, but requires two CSAs in series per cycle (effectively a 2-stage inner pipeline), doubling the per-cycle area. This is the configuration that achieves the "16-cycle" figure sometimes cited; the area cost must be acknowledged.
+  - **FACT.** Implemented as a single combinational Wallace/Dadda tree, the same 32 partial-product rows are summed in one cycle, with the tree depth determining the achievable clock period.
+- **Latency:** **TYPICAL.** ~32 cycles iterative (one row/cycle) or ~16 cycles iterative (two rows/cycle, ~2× area), or one combinational tree of ~8–16 CSA levels + a final CPA (the level count is design- and library-specific; the range is illustrative, not a tight bound). When pipelined, the array is typically broken into 3–6 stages.
+- **Throughput:** **TYPICAL.** One multiply per ~32 cycles (one row/cycle iterative), ~16 cycles (two rows/cycle iterative), or 1/cycle if the array is fully pipelined.
+- **Area:** **TYPICAL.** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA. The "two rows per cycle" iterative variant is roughly comparable in area to a small pipelined array.
+- **Power:** **TYPICAL.** Moderate to high when pipelined. The Wallace/Dadda tree toggles aggressively, and clock-tree load on a replicated array is non-trivial.
+- **Verification:** **TYPICAL.** Moderate. The corner cases that matter are the signed-overflow cases in the `MULH` datapath (sign-extended partial products, modified tree inputs) and the `MULHSU` sign-extension path. The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and most of `MULHSU`; `MULH` is a separate verification pass.
+- **Use case:** **TYPICAL.** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.
+
+### 3. Radix-8 or Radix-16 Booth Multiplier
+
+- **Mechanism:** **FACT.** Higher-radix Booth recoding reduces the number of partial-product rows. For a 64-bit operand:
+  - Radix-4: 32 rows.
+  - Radix-8: ⌈64/3⌉ = 22 rows (overlapping triples), with the PPG required to produce multiples {0, ±1, ±2, ±3, ±4} of the multiplicand. Generating ±3× typically requires a carry-save adder (1× + 2×), so the PPG is substantially more complex than radix-4.
+  - Radix-16: ⌈64/4⌉ = 16 rows, with the PPG required to produce multiples {0, ±1, ±2, ±3, ±4, ±5, ±6, ±7, ±8} (typically 3×, 5×, 7× via combinations of smaller multiples, with an extra high-order term).
+  - **Correction:** The "radix-8 reduces by 3×, radix-16 by 4×" claim sometimes seen in the literature refers to the ratio relative to radix-2 (64 partial products → 22 or 16), not a clean 3× or 4× multiplier. The actual reductions are 64/22 ≈ 2.9× and 64/16 = 4×, respectively.
+- **Latency:** **TYPICAL.** The fully pipelined radix-4 array can already achieve 1/cycle throughput; higher radices reduce the *depth* of the adder tree (fewer rows to sum) and therefore either shorten the critical path or allow fewer pipeline stages. Throughput is not increased beyond 1/cycle unless the array is duplicated.
+- **Throughput:** **TYPICAL.** 1/cycle for a single pipelined array; not inherently higher than radix-4.
+- **Area:** **TYPICAL.** Larger PPG; smaller (shallower) adder tree. Net area is roughly comparable to radix-4 or slightly larger.
+- **Power:** **TYPICAL.** Mixed. Fewer adder levels, but more complex PPG.
+- **Verification:** **TYPICAL.** Higher. Radix-8+ PPGs have more corner cases and the recoding is harder to prove correct.
+- **Use case:** **TYPICAL.** High-frequency designs where the critical path is in the adder tree, not the PPG.
+
+### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)
+
+- **Mechanism:** **FACT.** Standard shift-subtract over the operand width. Produces quotient (and optionally remainder) one bit per cycle.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand (plus a small constant for sign correction).
+- **Throughput:** **TYPICAL.** One divide per ~64 cycles.
+- **Area:** **TYPICAL.** Small. A 64- or 65-bit ALU with quotient/remainder registers.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Moderate. The division-by-zero convention, the `INT64_MIN / -1` overflow case, and the `REM`/`REMU` dividend-return case must all be implemented and tested explicitly. The signed-dividend path is the principal source of bugs.
+- **Use case:** **TYPICAL.** In-order cores with low expected DIV frequency.
+
+### 5. Radix-4 SRT Divider
+
+- **Mechanism:** **FACT.** Higher-radix SRT produces multiple quotient digits per iteration by selecting one of several shifted multiples of the divisor from a selection table indexed by a truncated partial remainder. A radix-4 SRT produces 2 bits per iteration; the quotient is held in a redundant (carry-save) form and converted to two's-complement on completion, or corrected on the fly.
+- **Latency:** **TYPICAL.** ~16 to 32 cycles for a 64-bit operand, depending on the average number of iterations required (SRT sometimes requires an extra iteration for the final correction step).
+- **Throughput:** **TYPICAL.** One divide per 16–32 cycles.
+- **Area:** **TYPICAL.** Substantially larger than subtractive. Requires a redundant (carry-save) quotient representation, a quotient-digit selection table, and partial-quotient error-correction logic.
+- **Power:** **TYPICAL.** Higher.
+- **Verification:** **TYPICAL.** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction has been the source of silicon bugs in commercial designs. **FACT.** The classic example is the Pentium FDIV bug, which was a defect in the radix-4 SRT lookup table of the Pentium's floating-point divider. The lesson is not merely "SRT is hard" but that the interaction between the redundant quotient representation and the selection function produces error patterns that are not obvious from inspection. Verification typically requires formal proofs of the selection function over reduced operand widths plus extensive directed testing. **Caveat:** the Pentium example is from FP division, not integer division, but the underlying technique (radix-4 SRT with redundant quotient) is the same family, and the verification lessons transfer.
+- **Use case:** **TYPICAL.** High-frequency OoO cores needing higher DIV throughput.
+
+### 6. Goldschmidt Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Each iteration multiplies both the partial remainder and the partial quotient by a correction factor derived from a short reciprocal estimate. Distinct from Newton-Raphson (see §7).
+- **Latency:** **TYPICAL.** A few multiply iterations. Amortized low latency if the multiplier is fast.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final iteration must converge to enough bits of precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step. The accuracy analysis is non-trivial and historically a bug source.
+- **Use case:** **TYPICAL.** Designs that already have a fast pipelined multiplier and want a small, fast divider.
+
+### 7. Newton-Raphson Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial estimate of the divisor's reciprocal using a Newton-Raphson step, then multiply the dividend by the refined reciprocal. Each iteration squares the error, so convergence is quadratic. Distinct from Goldschmidt, which uses a multiplicative correction on both the partial remainder and the partial quotient simultaneously; the two algorithms have different error dynamics and different fixup requirements.
+- **Latency:** **TYPICAL.** A few iterations of multiply-add. Typically fewer iterations than Goldschmidt to reach a given precision, but each iteration is a full multiply.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds lookup-table ROM for the initial estimate and modest control logic.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final-step rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the fixup step.
+- **Use case:** **TYPICAL.** Designs with a fast pipelined multiplier that want a low-latency divider.
+
+### 8. Shared MUL/DIV Iterative Unit (Multiplexed)
+
+- **Mechanism:** **ASSUMPTION.** A single iterative datapath handles both MUL and DIV by reconfiguring its datapath between operations. **TYPICAL.** This pattern is more common in microcoded embedded cores than in modern 64-bit RV64 designs, where MUL and DIV datapaths are structurally different (shift-and-add with accumulator vs. shift-subtract with quotient register) and the area savings from sharing are modest compared to the control complexity of reconfiguration. The characterization in this document is qualified accordingly.
+- **Latency:** **TYPICAL.** Same as the underlying iterative unit; the unit cannot serve MUL and DIV concurrently.
+- **Throughput:** **TYPICAL.** MUL and DIV contend for the same unit.
+- **Area:** **TYPICAL.** Small. **ASSUMPTION.** The "most area-efficient option" claim is conditional on the datapath being genuinely shared rather than microcoded over separate datapaths; for RV64, this is not the default choice in published designs.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Low to moderate if the datapath is genuinely shared; higher if microcode overlays separate datapaths.
+- **Use case:** **TYPICAL.** Cost-sensitive embedded cores; uncommon in high-performance RV64.
+
+## Alternative Designs
+
+Beyond the standard taxonomy, several non-obvious variants are worth considering.
+
+### A. Pipelined Multiplier + Sequential Divider (Split Unit)
+
+A fully pipelined radix-4 multiplier (e.g., 4-cycle latency) is paired with an independent sequential subtractive divider. The two units have separate reservation/issue logic.
+
+- **Rationale:** **ASSUMPTION.** Under many server, desktop, and general-purpose workloads, MUL is more frequent than DIV, but the ratio is workload-dependent and should not be assumed a priori. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches a plausible workload asymmetry.
+- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.
+
+### B. Variable-Latency Divider (Speculative / Early-Quit)
+
+Produce a partial-width approximate quotient, sign-extend, and perform a single correction step on the remaining bits. The early-quit path saves cycles when the divisor has small magnitude.
+
+- **Risk:** **TYPICAL.** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core. This can be partially mitigated by a fixed maximum latency with early completion, at the cost of additional control logic.
+
+### C. Radix-2 SRT with Carry-Save Quotient + Software/Hardware Fixup
+
+A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.
+
+- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step.
+
+### D. Pipelined 2-bit-per-cycle "Naïve" Divider
+
+Iterate two shift-subtract steps per cycle. Roughly halves divider latency relative to radix-1 subtractive without requiring an SRT selection table.
+
+- **Cost:** Two wide adders and a longer critical path. Area is moderate.
+
+### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Newton-Raphson
+
+A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations.
+
+- **Cost:** **TYPICAL.** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step (one or two multiplies plus a comparison). The precision / error analysis is non-trivial.
+
+### F. Shared Multi-Cycle Divider Across Cores (Divider Co-Processor)
+
+A small number of high-throughput dividers (e.g., 4 or 8) placed at fixed points in the fabric and dispatched to by cores via a memory-mapped or message interface. The dividers are not private to any core.
+
+- **Rationale:** Avoids replicating the divider 128×. Trades single-core latency (now includes a fabric round-trip) for amortized area.
+- **Cost:** NOC traffic, dispatch latency, contention at the divider, and software-visible ABI changes (or a transparent-but-slow trap path).
+- **Status:** Unusual but not unprecedented in accelerator-rich many-core designs.
+
+### G. FP / Integer Multiplier Sharing
+
+Share the integer multiplier's partial-product array and adder tree with the FP pipeline. **TYPICAL.** This pattern is standard in Rocket, BOOM, and most SiFive cores.
+
+- **Rationale:** Avoids replicating a wide datapath. The FP pipeline also benefits from a fast multiplier.
+- **Cost (qualified):** **TYPICAL.** Cross-unit scheduling and bypassing complexity. The integer and FP pipelines may have different latency targets. The sharing requires operand-format conversion (integer operands to FP-like internal format, and vice versa) and FP-specific concerns (rounding mode support, subnormal handling, NaN propagation) are not "free" — they are offloaded to the FP pipeline's existing logic, but the integer side must correctly drive and consume the shared datapath. Verification must cover the combined integer-plus-FP datapath, which is more complex than either alone. The "near-free" characterization sometimes seen in the literature is oversimplified; the cost is real but is often dominated by the FP-pipeline logic that already exists, making the incremental cost on the integer side smaller than the absolute cost of a separate integer multiplier.
+
+### H. Latency-Tolerant In-Order MUL/DIV
+
+Even a multi-cycle iterative MUL/DIV may be tolerable in an in-order core if the result-bus supports forwarding directly from the MUL/DIV output to dependent consumers, bypassing the register file writeback-read path.
+
+- **Cost:** Forwarding path length and bypass-network complexity scale with MUL/DIV latency.
+
+### I. Interaction with the "B" (Bitmanip) Extension
+
+The RISC-V Bitmanip extension introduces MUL/DIV-adjacent operations (e.g., `CLZ`, `CTZ`, `MIN`, `MAX`, bit-extract/deposit, and several pseudo-multiplication idioms such as `RORI` and `SH*ADD`). If the B extension is in scope, the MUL/DIV unit may either be reused for some of these (e.g., via the ALU) or augmented with dedicated bitmanip datapath. The decision is interdependent with the MUL/DIV choice and is flagged as an open question below.
+
+## Comparison
+
+The following table presents *qualitative* relative magnitudes only. **INSUFFICIENT EVIDENCE:** No node, frequency, or synthesis data is available for XH-1, so quantitative ratios are not asserted. "Latency" is in cycles for back-to-back independent operations on the named unit; "throughput" is sustained operations per cycle for a fully pipelined or iterative unit, respectively.
+
+| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort |
+|---|---|---|---|---|---|
+| Iterative shift-add MUL (one row/cycle) + subtractive DIV (shared or separate) | ~64 (MUL) / ~64 (DIV) | ~1/64 (each) | Smallest | Smallest | Low |
+| Iterative radix-4 MUL (one row/cycle) + subtractive DIV | ~32 (MUL) / ~64 (DIV) | ~1/32 (MUL) | Small | Small to moderate | Low to moderate |
+| Pipelined radix-4 array MUL + subtractive DIV (split) | ~4–8 (MUL) / ~64 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 array MUL + radix-4 SRT DIV | ~4–8 (MUL) / ~16–32 (DIV) | 1/cycle (MUL) | Large | Large | High |
+| Pipelined radix-8 array MUL + Newton-Raphson or Goldschmidt DIV | ~3–6 (MUL) / ~4–8 (DIV) | 1/cycle (MUL) | Largest | Largest | High |
+| Pipelined radix-4 MUL + 2-bit-per-cycle naïve DIV | ~4–8 (MUL) / ~32 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
+
+**INSUFFICIENT EVIDENCE:** The relative magnitudes are illustrative and intended only to convey ordering. The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1. **INSUFFICIENT EVIDENCE:** Quantitative area, power, and energy comparisons cannot be made without a target node, frequency, and synthesis flow.
+
+## Advantages
+
+The leading candidates each have a distinct strength profile. The following are conditional on the workload and core microarchitecture, which are not yet established.
+
+- **Iterative shared unit (Approach 8, with the qualification in §8):** **ASSUMPTION.** Smallest per-core area and lowest power in microcoded embedded cores; for RV64, the area advantage over a split iterative MUL + iterative DIV is modest and the control complexity may offset the savings. Easiest to verify only if the datapath is genuinely shared.
+- **Pipelined radix-4 MUL + iterative subtractive DIV (split, Alternative A):** **ASSUMPTION.** Matches a plausible workload asymmetry where MUL is more frequent than DIV; MUL throughput is high (common case), DIV cost is contained, and verification is tractable. This is a strong compromise candidate, not a leading candidate by default.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest predictable throughput on both operations; minimal front-end exposure if the core is in-order. Verification cost is high.
+- **Newton-Raphson or Goldschmidt DIV on top of fast MUL:** **TYPICAL.** Reuses the multiplier's silicon; area-efficient if the multiplier is already large. Verification cost is high.
+
+## Disadvantages
+
+- **Iterative shared unit:** **TYPICAL.** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided. For RV64, the structural mismatch between MUL and DIV datapaths limits the achievable area savings.
+- **Pipelined radix-4 MUL + iterative DIV:** **TYPICAL.** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs (the Pentium FDIV bug being a radix-4 SRT selection-table defect). The verification cost is replicated across cores.
+- **Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean, formally-specified correction step.
+
+## XH-1 Considerations
+
+**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:
+
+1. **128-core replication amplifies per-core area and verification cost.** **FACT.** A larger MUL/DIV unit pays the same area cost across all 128 cores, not just one. The die-area cost is severe.
+2. **Per-core issue width and in-order/OoO status are not established.** **INSUFFICIENT EVIDENCE.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not, unless explicit forwarding is provided.
+3. **128 cores imply a tile- or mesh-style interconnect.** **ASSUMPTION.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations, unless a shared divider alternative (Alternative F) is adopted.
+4. **Verification cost is replicated at the unit level, not the integration level.** **FACT.** A replicated unit is verified once at the unit level (RTL, formal, directed/random). The integration with each core's pipeline is identical across replications and is verified once via the core-level verification environment; running the same integration suite 128× does not add coverage. The 128× replication matters for silicon defect exposure (a bug that escapes verification affects all cores) and for DFT/scan/BIST architecture, not for per-instance verification effort.
+5. **Physical-design regularity matters under replication.** **TYPICAL.** A small, regular MUL/DIV unit is easier to harden and replicate 128× than a complex, irregular SRT unit.
+
+**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.
+
+## 128-Core Scalability
+
+The MUL/DIV unit is per-core and not shared across cores by default. Scalability considerations:
+
+- **No coherence problem.** **FACT.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
+- **No cross-core contention** in the default per-core configuration. **FACT.** Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior. A shared-divider alternative (Alternative F) changes this analysis.
+- **Verification parallelism.** **FACT (clarified).** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once at the unit level. Integration with the pipeline is verified once at the core level (since all cores are identical replications), not 128×. The 128× replication affects silicon defect exposure, not verification run-count.
+- **Area-budget pressure.** **TYPICAL.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
+- **Power-grid and clock distribution.** **TYPICAL.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. **INSUFFICIENT EVIDENCE:** Power delivery (IR drop), clock skew across the replicated load, and dynamic power density must be analyzed for the replicated load; no quantitative estimates are made here.
+- **Scan and BIST.** **TYPICAL.** A 128× replicated unit implies 128× the scan-chain length (if scan is per-core) or a partitioned BIST architecture. The choice affects DFT area and test time.
+- **Fault tolerance.** **TYPICAL.** A defect in the MUL/DIV unit is potentially a defect in all 128 cores. This argues for either a hardened, characterized macro or built-in redundancy / sparing, depending on yield targets.
+- **Timing variation.** **TYPICAL.** Across-die process variation affects 128 replicated units independently. A design that is timing-marginal at one corner may fail at another. Iterative designs are less sensitive to per-unit timing variation than deep-pipelined arrays.
+
+**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128. Prefer regular, hardenable structures over irregular ones that resist replication.
+
+## Performance Considerations
+
+MUL/DIV performance interacts with the rest of the core in two ways:
+
+1. **Latency exposure.** **FACT.** In an in-order core, MUL latency stalls the front-end unless explicit forwarding is provided. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
+2. **Throughput-bound on dependent chains.** **FACT.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.
+
+**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.
+
+## Area Considerations
+
+Relative area ordering, qualitative only (no synthesis data available):
+
+- Iterative MUL + iterative DIV (shared, with the qualifications in §8): smallest in microcoded embedded cores; for RV64, the advantage over a split iterative design is modest.
+- Iterative radix-4 MUL (one row/cycle) + subtractive DIV: small.
+- Pipelined radix-4 MUL + iterative subtractive DIV (split): moderate.
+- Pipelined radix-4 MUL + 2-bit-per-cycle naïve DIV: moderate.
+- Pipelined radix-4 MUL + radix-4 SRT DIV: large.
+- Pipelined radix-8 MUL + Newton-Raphson / Goldschmidt DIV: largest.
+
+**INSUFFICIENT EVIDENCE:** The XH-1 per-core area budget must be defined before any of the above can be quantified in absolute terms. Absolute area figures require a process node and a synthesis flow.
+
+## Power and Energy Considerations
+
+Relative energy-per-operation ordering, qualitative only:
+
+- **Iterative:** **TYPICAL.** Low per-cycle power, but high per-operation energy × time product (many cycles).
+- **Pipelined MUL + iterative DIV:** **TYPICAL.** Low per-op MUL energy, high per-op DIV energy.
+- **Pipelined MUL + SRT DIV:** **TYPICAL.** High per-cycle power, lower per-op energy than iterative.
+- **Pipelined MUL + Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Per-op energy is a small multiple of MUL energy; competitive.
+
+**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative subtractive DIV is a reasonable energy-vs-area compromise, contingent on the workload.
+
+**INSUFFICIENT EVIDENCE:** Quantitative power and energy figures require a process node, a clock target, and a workload trace.
+
+## Implementation Considerations
+
+- **Wallace/Dadda tree synthesis risk.** **TYPICAL (opinion flagged).** Compressor trees are known to be hard to place-and-route at high frequency on modern nodes; poor placement can introduce unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon. *This is an engineering judgment, not an established fact; specific delay figures depend on the synthesis flow and library, and are not asserted here.*
+- **PPG and Booth recoder verification.** **TYPICAL.** Radix-4 PPGs are well-understood and tractable to verify; radix-8+ PPGs require more corner cases. The `MULH` signed×signed upper-half path requires explicit verification of sign-extended partial products and is not a free byproduct of the unsigned array.
+- **SRT selection table correctness.** **TYPICAL.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
+- **RISC-V division-by-zero and overflow conventions.** **FACT.** `DIV` and `DIVU` return `-1` (all bits set) on divide-by-zero; `REM` and `REMU` return the dividend on divide-by-zero. On signed overflow (`INT64_MIN / -1`), `DIV` returns `INT64_MIN` and `REM` returns 0. These must be implemented explicitly; the design must not raise a trap.
+- **Pipeline interlocks.** **FACT.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
+- **Physical design replication.** **TYPICAL.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication and are a physical-design risk under replication.
+
+## Verification Considerations
+
+Verification cost is a dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:
+
+- **Radix-2/4 shift-add and subtractive:** **TYPICAL.** Lowest. Exhaustive simulation at reduced widths is tractable.
+- **Radix-4 Booth + iterative DIV:** **TYPICAL.** Moderate. The hard cases are the signed division edge cases (division-by-zero, `INT64_MIN / -1`), the `MULH` signed×signed upper-half path (sign-extended partial products, not a free byproduct of the unsigned array), and the `MULHSU` sign-extension. The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and the bulk of `MULHSU`; `MULH` is a separate verification pass.
+- **SRT:** **TYPICAL.** High. SRT selection-table bugs are famous in industry (the Pentium FDIV bug was a radix-4 SRT selection-table defect). Verification typically requires formal proofs of the selection function over reduced widths and extensive directed testing.
+- **Newton-Raphson / Goldschmidt:** **TYPICAL.** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
+- **Replication factor (clarified):** **FACT.** A bug in the MUL/DIV unit that escapes verification is a bug in all 128 cores (silicon defect exposure). However, the verification effort itself is not 128×: the unit is verified once at the unit level, and the core-level integration is verified once (cores are identical replications). The risk is concentrated exposure, not multiplied effort.
+
+**Preliminary verification strategy** (to be refined once the design choice is made):
+
+- **Unit-level:** Exhaustive simulation at reduced operand widths (e.g., 8, 12, 16 bits) for the core datapath. Formal equivalence checking between the RTL and a reference model written in a high-level specification language (e.g., Bluespec, Scala, or a C reference). For SRT or Newton-Raphson, formal proof of the selection function or the convergence step.
+- **Directed corner-case suite:** Explicit tests for division-by-zero (both `DIV`/`DIVU` and `REM`/`REMU` paths), signed overflow (`INT64_MIN / -1`, both quotient and remainder), `MULH` against a cross-checked reference (Baugh-Wooley or equivalent), `MULHSU` against a cross-checked reference, and the `MUL`-then-truncate boundary.
+- **Random / constrained-random:** At full width, comparing against a software reference. Coverage targets on the Booth recoder, PPG, and selection table.
+- **Integration:** Per-core pipeline integration verified once at the core level (not 128×), since cores are identical.
+- **Post-silicon:** Microarchitectural validation suite, focused on MUL/DIV-intensive kernels (big-integer arithmetic, hashes, polynomial multiplications).
+
+**PROPOSAL:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.
+
+## Software Considerations
+
+- **Compiler behavior.** **FACT.** GCC and LLVM routinely use shift-and-add sequences for multiplication by small constants, and they may either emit `MUL` instructions or inline expansions depending on the cost model. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences, but the magnitude of this effect is workload- and compiler-version-dependent and should not be assumed.
+- **Library code.** **FACT.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
+- **System software.** **TYPICAL.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
+- **128-core interaction.** **ASSUMPTION.** The system stack (kernel, hypervisor) will run on some subset of the 128 cores. There is no asymmetric design implication: every core is equal in the default per-core configuration.
+
+**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.
+
+## Recommendation
+
+**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:
+
+1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
+2. The per-core area and power budget.
+3. The target workload mix and software ecosystem.
+
+**Conditional recommendations** (to be revisited once the above are known):
+
+- **If XH-1 targets an in-order core with tight area budget:** **PROPOSAL.** A separate iterative shift-add MUL (one row/cycle) and an iterative subtractive DIV, with explicit forwarding from the MUL/DIV output to dependent consumers, is the smallest, easiest-to-verify choice. MUL/DIV latency will be high; whether this is acceptable depends on the forwarding path and the workload. The shared-iterative-unit approach (Approach 8) is *not* recommended for RV64 by default, given the structural mismatch between MUL and DIV datapaths and the modest area advantage over a split iterative design.
+- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** **PROPOSAL.** A pipelined radix-4 Booth multiplier (4–8 stage pipeline) paired with a 2-bit-per-cycle naïve divider or a radix-4 SRT divider. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle. **Reconciliation note:** the cross-cutting recommendation below defers SRT until formally proven correct; if SRT cannot be formally verified on reduced widths within the project timeline, the 2-bit-per-cycle naïve divider is the preferred DIV companion. The SRT recommendation is conditional on the verification investment being made.
+- **If the per-core area budget is moderate and the workload is balanced:** **PROPOSAL.** A pipelined radix-4 MUL with an iterative subtractive DIV (the "split" approach, Alternative A) is a strong compromise.
+
+**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson / Goldschmidt rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.
+
+## Confidence
+
+| Topic | Confidence |
+|---|---|
+| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
+| Relative area, power, and energy rankings | Low to medium (qualitative ordering only; no synthesis data) |
+| Per-cycle latency numbers | Low to medium (typical, but node- and target-frequency-dependent) |
+| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
+| Specific recommendation | **Insufficient evidence** to commit |
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
+2. What is the per-core area budget, in absolute terms or as a fraction of die area?
+3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
+4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused or augmented.
+5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
+6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
+7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power and replication regularity; synthesis-per-core favors design flexibility.
+8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
+9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
+10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.
+11. Will the MUL/DIV unit be shared with the FP pipeline (as in Rocket / BOOM), or kept private to the integer pipeline?
+12. Will XH-1 adopt a shared multi-cycle divider across cores (Alternative F), or is a strictly per-core MUL/DIV unit required?
+
+## Sources
+
+- Canonical computer-arithmetic references: Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*. These cover the techniques surveyed above in standard form. **Caveat:** these texts underwrite the taxonomy and the mechanism descriptions. Specific per-cycle latency figures given in this document are **TYPICAL** values drawn from common practice in published RV64 designs; the cited texts provide the algorithmic background but do not, in their canonical editions, supply XH-1-specific latency or area numbers. No specific chapter or page is cited for the quantitative figures because the figures are not drawn from a single source.
+- Open RISC-V core implementations (Rocket, BOOM, XiangShan, SiFive) provide reference designs for radix-4 array multipliers, iterative and SRT dividers, and FP/integer multiplier sharing. These are cited as implementation exemplars, not as XH-1 references.
+- **INSUFFICIENT EVIDENCE:** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
+- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as qualitative engineering estimates or as canonical background knowledge in the field of computer arithmetic.

research/.xh1/runs/20260825T182220Z/research_03-core-design_mul-div-unit.md.round4.md

@@ -0,0 +1,387 @@
+# Multiply/Divide Unit Design for the XH-1 Processor
+
+## Status
+
+**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions. Quantitative comparisons are presented only as qualitative relative magnitudes, never as benchmark figures. Throughout this document, claims are tagged as one of:
+
+- **FACT** — well-established in the cited literature or in the RISC-V ISA specification.
+- **TYPICAL** — the common case across published designs; implementation-specific values may vary.
+- **ASSUMPTION** — an explicit premise the analysis depends on; should be revisited.
+- **PROPOSAL** — a design recommendation conditional on unresolved parameters.
+- **INSUFFICIENT EVIDENCE** — no defensible claim can be made without additional information.
+
+## Abstract
+
+This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt dividers, Newton-Raphson dividers, subtractive dividers, and SRT dividers) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so any recommendations are conditional on those upstream decisions.
+
+## Research Question
+
+> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?
+
+Specifically:
+
+- How should the unit be pipelined relative to the rest of the core?
+- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports, FP multiplier) or remain isolated?
+- How should division throughput be traded against area and verification cost?
+- What is the impact of the choice on multi-core contention for shared execution resources, if any?
+
+## Background
+
+**FACT.** The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:
+
+- `MUL` (lower 64 bits of signed × signed)
+- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
+- `DIV`, `DIVU` (signed/unsigned quotient)
+- `REM`, `REMU` (signed/unsigned remainder)
+
+Critical properties of this ISA slice that drive microarchitecture:
+
+- **Wide-operand upper-multiply (UMUL).** **TYPICAL.** In a single full-width partial-product / carry-save array, the 64×64→128-bit product is generated by the same array that produces the 64×64→64 product; the carry-save adder tree is slightly deeper and wider, and a final carry-propagate adder is needed to collapse the upper half. The incremental cost of supporting `MULH*` is therefore a small area adder and routing for the upper output, not a doubling. *Caveat: specific silicon area deltas are design-dependent; the "share the array" pattern is the common case in published RV64 implementations (e.g., BOOM, XiangShan, some SiFive designs), but quantitative numbers are not asserted here.* **FACT.** Rocket Chip keeps the integer multiplier and the FP multiplier as separate units rather than sharing the array; the document's earlier blanket attribution of sharing to "Rocket, BOOM, and most SiFive cores" overstates the case and is corrected here.
+- **MULH and signed×signed handling.** **FACT.** `MULH` (signed×signed, upper half) is not obtained by simply reusing the unsigned 64×64→128 array with sign-corrected operands. The standard technique is Baugh-Wooley or Modified Booth with explicit sign-bit handling, which modifies the partial-product generation (sign-extension of the most-significant partial products) and the adder tree. The "essentially free" characterization sometimes seen is oversimplified: while the underlying adder tree is shared, the partial-product array and the final CPA differ for the signed case, and verification must treat `MULH` as a distinct datapath.
+- **MULHSU and signed×unsigned handling.** **FACT.** `MULHSU` is also not a vanilla 65×64 unsigned array. The signed operand's most-significant partial product must be sign-handled (Baugh-Wooley-style sign extension of the MSB partial product, or Modified Booth encoding with explicit sign control) so that the upper 64 bits of the result are correct. The incremental verification cost over `MULHU` is small once the unsigned array is in place, but `MULHSU` is not "free" in the strict sense; it requires its own sign-handling pass and must be verified against a reference for all sign combinations.
+- **Division latencies.** **FACT.** A restoring or non-restoring subtractive divider on 64-bit operands requires exactly 64 reduction steps (or 65 with a sign pre-correction step). A radix-2 SRT divider also requires 64 selection steps in the worst case (with possible skipped steps on average, but the worst case governs the pipeline). A radix-4 SRT divider requires 16 selection steps in the worst case, plus a final quotient-conversion step (carry-save to two's-complement), not an extra selection step. **TYPICAL.** These counts dominate pipeline depth if the divider is fully combinational; iterative implementations amortize them over many cycles.
+- **Signed semantics.** **FACT.** RISC-V specifies the following for division edge cases:
+  - Division by zero: `DIV` and `DIVU` return `-1` (i.e., all bits set); `REM` and `REMU` return the dividend.
+  - Signed overflow: `INT64_MIN / -1` returns `INT64_MIN` (the mathematical quotient); the corresponding `REM` returns 0.
+  - The operation must not raise an exception; the hardware must produce the specified result.
+- **Throughput vs. latency decoupling.** **FACT.** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end unless explicit forwarding is provided.
+
+The XH-1 is a 128-core machine. **FACT.** Decisions in the MUL/DIV unit replicate 128×, so per-core area dominates the silicon cost; verification effort is dominated by unit-level and core-level-integration work that is performed once and reused across the 128 identical instances (see §Verification Considerations and §128-Core Scalability for the qualification). **INSUFFICIENT EVIDENCE:** There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).
+
+**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, target process node, per-core area budget, and target workload mix for XH-1 are all unknown.
+
+## Existing Approaches
+
+The following approaches are well-established in the literature and commercial designs. **FACT.** Standard computer-arithmetic texts (Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*) cover these techniques in canonical form. No XH-1-internal prior art exists. Per-cycle latency figures given below are **TYPICAL** values for a 64-bit operand at a moderate clock target; specific values are implementation- and node-dependent, and the figures are not drawn from a single citable source. Where a range is given, it is illustrative of the order of magnitude, not a tight bound.
+
+### 1. Shift-and-Add Multiplier (Iterative)
+
+- **Mechanism:** **FACT.** A 64-bit multiplier is implemented as a state machine that processes one partial-product bit per cycle against a 128-bit accumulator (or a 129-bit accumulator with a sign-preconditioned variant). Signed operands are sign-extended; iteration count is not halved.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand, plus a small constant for sign/result correction.
+- **Throughput:** **TYPICAL.** One multiply per ~64 cycles (unit is not pipelined).
+- **Area:** **TYPICAL.** Very small. Roughly one wide adder + one shifter + one accumulator register.
+- **Power:** **TYPICAL.** Low. Minimal clocked area per cycle.
+- **Verification:** **TYPICAL.** Low complexity. Straightforward to model and exhaustively test at small operand widths.
+- **Use case:** **TYPICAL.** Embedded in-order cores where MUL/DIV are infrequent and latency-tolerant. Generally unsuitable for high-performance 64-bit cores.
+
+### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)
+
+- **Mechanism:** **FACT.** Radix-4 Booth recoding reduces partial products to ceil(n/2). For a 64-bit operand, standard radix-4 Booth encoding produces 32 partial-product rows. An *iterative* radix-4 multiplier accumulates these rows one or two at a time:
+  - **One row per cycle:** ~32 cycles, one CSA per cycle, smallest iterative area.
+  - **Two rows per cycle:** ~16 cycles, but requires two CSAs in series per cycle. The area cost of the second CSA is not a simple "doubling": the second CSA operates on the full sum-and-carry width of the first, so the additional area is closer to the cost of one full-width CSA, and the per-cycle critical path lengthens. This is the configuration that achieves the "16-cycle" figure sometimes cited; the area and timing costs must be acknowledged.
+  - **FACT.** Implemented as a single combinational Wallace/Dadda tree, the same 32 partial-product rows are summed in one cycle, with the tree depth determining the achievable clock period.
+- **Latency:** **TYPICAL.** ~32 cycles iterative (one row/cycle) or ~16 cycles iterative (two rows/cycle, with the area and timing qualifications above), or one combinational tree of approximately 8–12 CSA levels plus a final CPA (the level count is design- and library-specific; the figure is an order-of-magnitude estimate, not a precise bound). When pipelined, the array is typically broken into 3–6 stages, with each stage absorbing one to several CSA levels plus possibly a portion of the final CPA. The relationship between the un-pipelined tree depth and the pipelined stage count is implementation-specific; this document does not assert a fixed mapping.
+- **Throughput:** **TYPICAL.** One multiply per ~32 cycles (one row/cycle iterative), ~16 cycles (two rows/cycle iterative, with qualifications), or 1/cycle if the array is fully pipelined.
+- **Area:** **TYPICAL.** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA. The "two rows per cycle" iterative variant is roughly comparable in area to a small pipelined array, with the per-cycle critical path lengthened.
+- **Power:** **TYPICAL.** Moderate to high when pipelined. The Wallace/Dadda tree toggles aggressively, and clock-tree load on a replicated array is non-trivial.
+- **Verification:** **TYPICAL.** Moderate. The corner cases that matter are the signed-overflow cases in the `MULH` datapath (sign-extended partial products, modified tree inputs) and the `MULHSU` sign-extension path (Baugh-Wooley or Modified Booth sign handling, not a free byproduct of the unsigned array). The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and the bulk of `MULHSU`; `MULH` is a separate verification pass; `MULHSU` requires explicit sign-handling verification but is closer to the unsigned case than `MULH` is.
+- **Use case:** **TYPICAL.** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.
+
+### 3. Radix-8 or Radix-16 Booth Multiplier
+
+- **Mechanism:** **FACT.** Higher-radix Booth recoding reduces the number of partial-product rows. For a 64-bit operand:
+  - Radix-4: 32 rows.
+  - Radix-8: 22 data rows plus a separate sign-handling row for the most-significant window, totaling 23 rows in a fully sign-corrected implementation. Canonical radix-8 Booth recoding requires careful handling of the most-significant 3-bit window to avoid producing an erroneous extra row. The PPG must produce multiples {0, ±1, ±2, ±3, ±4} of the multiplicand; ±3× and ±4× are typically generated via a carry-save adder (1× + 2× for ±3×, 2× + 2× or a dedicated shift-and-add for ±4×), so the PPG is substantially more complex than radix-4.
+  - Radix-16: 16 data rows plus a sign-handling row, totaling 17 rows. The PPG must produce multiples {0, ±1, ±2, ±3, ±4, ±5, ±6, ±7, ±8}; 3×, 5×, 6×, 7× are typically generated via combinations of smaller multiples, with an extra high-order term.
+  - **Correction:** The "radix-8 reduces by 3×, radix-16 by 4×" claim sometimes seen in the literature refers to the ratio relative to radix-2 (64 partial products → 22 or 16 data rows), not a clean 3× or 4× multiplier. The actual reductions over radix-2 are 64/22 ≈ 2.9× (radix-8) and 64/16 = 4× (radix-16); the reductions over radix-4 are 32/22 ≈ 1.45× and 32/16 = 2× respectively.
+- **Latency:** **TYPICAL.** The fully pipelined radix-4 array can already achieve 1/cycle throughput; higher radices reduce the *depth* of the adder tree (fewer rows to sum) and therefore either shorten the critical path or allow fewer pipeline stages. Throughput is not increased beyond 1/cycle unless the array is duplicated.
+- **Throughput:** **TYPICAL.** 1/cycle for a single pipelined array; not inherently higher than radix-4.
+- **Area:** **TYPICAL.** Larger PPG; smaller (shallower) adder tree. Net area is roughly comparable to radix-4 or slightly larger.
+- **Power:** **TYPICAL.** Mixed. Fewer adder levels, but more complex PPG.
+- **Verification:** **TYPICAL.** Higher. Radix-8+ PPGs have more corner cases and the recoding is harder to prove correct.
+- **Use case:** **TYPICAL.** High-frequency designs where the critical path is in the adder tree, not the PPG.
+
+### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)
+
+- **Mechanism:** **FACT.** Standard shift-subtract over the operand width. Produces quotient (and optionally remainder) one bit per cycle. The iteration count for a 64-bit operand is exactly 64 reduction steps (or 65 with a sign pre-correction step); the figure is not a range.
+- **Latency:** **TYPICAL.** ~64 cycles for a 64-bit operand (plus a small constant for sign correction).
+- **Throughput:** **TYPICAL.** One divide per ~64 cycles.
+- **Area:** **TYPICAL.** Small. A 64- or 65-bit ALU with quotient/remainder registers.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Moderate. The division-by-zero convention, the `INT64_MIN / -1` overflow case, and the `REM`/`REMU` dividend-return case must all be implemented and tested explicitly. The signed-dividend path is the principal source of bugs.
+- **Use case:** **TYPICAL.** In-order cores with low expected DIV frequency.
+
+### 5. Radix-4 SRT Divider
+
+- **Mechanism:** **FACT.** Higher-radix SRT produces multiple quotient digits per iteration by selecting one of several shifted multiples of the divisor from a selection table indexed by a truncated partial remainder. A radix-4 SRT produces 2 bits per iteration; the quotient is held in a redundant (carry-save) form and converted to two's-complement on completion. The iteration count for a 64-bit operand is 16 selection steps in the worst case, plus a final quotient-conversion step (carry-save to two's-complement); the converter is not an extra selection step.
+- **Latency:** **TYPICAL.** ~16 selection cycles plus a small constant for the final conversion, for a 64-bit operand.
+- **Throughput:** **TYPICAL.** One divide per ~16 cycles (worst case).
+- **Area:** **TYPICAL.** Substantially larger than subtractive. Requires a redundant (carry-save) quotient representation, a quotient-digit selection table, and partial-quotient error-correction logic.
+- **Power:** **TYPICAL.** Higher.
+- **Verification:** **TYPICAL.** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction has been the source of silicon bugs in commercial designs. **FACT.** The classic example is the Pentium FDIV bug: the floating-point divider's radix-4 SRT lookup table was missing entries (a "+2" entry that should have been present) in the programmable logic array (PLA) implementing the selection function. The fix was a mask change, not a logic redesign. **TYPICAL.** The lessons from this and similar incidents — that the interaction between the redundant quotient representation and the selection function produces error patterns that are not obvious from inspection, and that verification typically requires formal proofs of the selection function over reduced operand widths plus extensive directed testing — transfer to integer radix-4 SRT dividers, but the FP and integer SRT implementations use different quotient-digit sets and selection functions, so the lessons are transferred by analogy rather than by direct equivalence.
+- **Use case:** **TYPICAL.** High-frequency OoO cores needing higher DIV throughput.
+
+### 6. Goldschmidt Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Each iteration multiplies both the partial remainder and the partial quotient by a correction factor derived from a short reciprocal estimate. Distinct from Newton-Raphson (see §7).
+- **Latency:** **TYPICAL.** A few multiply iterations. Amortized low latency if the multiplier is fast.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final iteration must converge to enough bits of precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step. The accuracy analysis is non-trivial and historically a bug source.
+- **Use case:** **TYPICAL.** Designs that already have a fast pipelined multiplier and want a small, fast divider.
+
+### 7. Newton-Raphson Divider (Reciprocal Multiplication)
+
+- **Mechanism:** **FACT.** Iteratively refine an initial estimate of the divisor's reciprocal using a Newton-Raphson step, then multiply the dividend by the refined reciprocal. Each iteration squares the error, so convergence is quadratic. Distinct from Goldschmidt, which uses a multiplicative correction on both the partial remainder and the partial quotient simultaneously; the two algorithms have different error dynamics and different fixup requirements.
+- **Latency:** **TYPICAL.** A few iterations of multiply-add. Typically fewer iterations than Goldschmidt to reach a given precision, but each iteration is a full multiply.
+- **Throughput:** **TYPICAL.** Bounded by the multiplier.
+- **Area:** **TYPICAL.** Reuses the multiplier. Adds lookup-table ROM for the initial estimate and modest control logic.
+- **Power:** **TYPICAL.** Low marginal cost on top of the multiplier.
+- **Verification:** **TYPICAL.** High. The final-step rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the fixup step.
+- **Use case:** **TYPICAL.** Designs with a fast pipelined multiplier that want a low-latency divider.
+
+### 8. Shared MUL/DIV Iterative Unit (Multiplexed)
+
+- **Mechanism:** **ASSUMPTION.** A single iterative datapath handles both MUL and DIV by reconfiguring its datapath between operations. **TYPICAL.** This pattern is more common in microcoded embedded cores than in modern 64-bit RV64 designs, where MUL and DIV datapaths are structurally different (shift-and-add with accumulator vs. shift-subtract with quotient register) and the area savings from sharing are modest compared to the control complexity of reconfiguration. The characterization in this document is qualified accordingly.
+- **Latency:** **TYPICAL.** Same as the underlying iterative unit; the unit cannot serve MUL and DIV concurrently.
+- **Throughput:** **TYPICAL.** MUL and DIV contend for the same unit.
+- **Area:** **TYPICAL.** For RV64, the area advantage of a genuinely shared iterative unit over a split iterative MUL + iterative DIV is modest at best, and the control complexity of reconfiguration may offset the savings. The "most area-efficient" framing in earlier drafts of this document is qualified here: shared-iterative is a defensible choice for microcoded embedded cores, but for RV64 the area ranking is closer to "small to moderate" rather than strictly "smallest." **ASSUMPTION.** This ranking depends on the datapath being genuinely shared rather than microcoded over separate datapaths.
+- **Power:** **TYPICAL.** Low.
+- **Verification:** **TYPICAL.** Low to moderate if the datapath is genuinely shared; higher if microcode overlays separate datapaths.
+- **Use case:** **TYPICAL.** Cost-sensitive embedded cores; uncommon in high-performance RV64.
+
+## Alternative Designs
+
+Beyond the standard taxonomy, several non-obvious variants are worth considering.
+
+### A. Pipelined Multiplier + Sequential Divider (Split Unit)
+
+A fully pipelined radix-4 multiplier (e.g., 3–6 stage pipeline) is paired with an independent sequential subtractive divider. The two units have separate reservation/issue logic.
+
+- **Rationale:** **ASSUMPTION.** Under many server, desktop, and general-purpose workloads, MUL is more frequent than DIV, but the ratio is workload-dependent and should not be assumed a priori. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches a plausible workload asymmetry.
+- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.
+
+### B. Variable-Latency Divider (Speculative / Early-Quit)
+
+Produce a partial-width approximate quotient, sign-extend, and perform a single correction step on the remaining bits. The early-quit path saves cycles when the divisor has small magnitude.
+
+- **Risk:** **TYPICAL.** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core. This can be partially mitigated by a fixed maximum latency with early completion, at the cost of additional control logic.
+
+### C. Radix-2 SRT with Carry-Save Quotient + Software/Hardware Fixup
+
+A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.
+
+- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step. The worst-case iteration count is 64 selection steps for a 64-bit operand.
+
+### D. Pipelined 2-bit-per-cycle "Naïve" Divider
+
+Iterate two shift-subtract steps per cycle. Roughly halves divider latency relative to radix-1 subtractive without requiring an SRT selection table.
+
+- **Cost:** Two wide adders and a longer critical path. Area is moderate.
+
+### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Newton-Raphson
+
+A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations.
+
+- **Cost:** **TYPICAL.** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step (one or two multiplies plus a comparison). The precision / error analysis is non-trivial.
+
+### F. Shared Multi-Cycle Divider Across Cores (Divider Co-Processor)
+
+A small number of high-throughput dividers (e.g., 4 or 8) placed at fixed points in the fabric and dispatched to by cores via a memory-mapped or message interface. The dividers are not private to any core.
+
+- **Rationale:** Avoids replicating the divider 128×. Trades single-core latency (now includes a fabric round-trip) for amortized area.
+- **Cost:** NOC traffic, dispatch latency, contention at the divider, and software-visible ABI changes (or a transparent-but-slow trap path).
+- **Status:** Unusual but not unprecedented in accelerator-rich many-core designs.
+
+### G. FP / Integer Multiplier Sharing
+
+Share the integer multiplier's partial-product array and adder tree with the FP pipeline. **TYPICAL.** This pattern appears in BOOM and in some SiFive designs; Rocket Chip keeps the integer and FP multipliers as separate units. The applicability of the pattern is design-specific and is not asserted as universal here.
+
+- **Rationale:** Avoids replicating a wide datapath. The FP pipeline also benefits from a fast multiplier.
+- **Cost (qualified):** **TYPICAL.** Cross-unit scheduling and bypassing complexity. The integer and FP pipelines may have different latency targets. The sharing requires operand-format conversion (integer operands to FP-like internal format, and vice versa) and FP-specific concerns (rounding mode support, subnormal handling, NaN propagation) are not "free" — they are offloaded to the FP pipeline's existing logic, but the integer side must correctly drive and consume the shared datapath. Verification must cover the combined integer-plus-FP datapath, which is more complex than either alone. The "near-free" characterization sometimes seen in the literature is oversimplified; the cost is real but is often dominated by the FP-pipeline logic that already exists, making the incremental cost on the integer side smaller than the absolute cost of a separate integer multiplier.
+
+### H. Latency-Tolerant In-Order MUL/DIV
+
+Even a multi-cycle iterative MUL/DIV may be tolerable in an in-order core if the result-bus supports forwarding directly from the MUL/DIV output to dependent consumers, bypassing the register file writeback-read path.
+
+- **Cost:** Forwarding path length and bypass-network complexity scale with MUL/DIV latency. The forwarding network is a real cost — typically a set of wide muxes at the input of each consuming execution unit, with wiring that may dominate the area of the iterative MUL/DIV unit itself. The cost scales with the number of consumers (ALU, branch, load/store) and with MUL/DIV latency, since the forwarded result must remain valid on the bypass network for the full MUL/DIV latency. This cost should be quantified before an iterative unit is chosen for an in-order core.
+
+### I. Interaction with the "B" (Bitmanip) Extension
+
+The RISC-V Bitmanip extension introduces MUL/DIV-adjacent operations (e.g., `CLZ`, `CTZ`, `MIN`, `MAX`, bit-extract/deposit, and several pseudo-multiplication idioms such as `RORI` and `SH*ADD`). If the B extension is in scope, the MUL/DIV unit may either be reused for some of these (e.g., via the ALU) or augmented with dedicated bitmanip datapath. The decision is interdependent with the MUL/DIV choice and is flagged as an open question below.
+
+## Comparison
+
+The following table presents *qualitative* relative magnitudes only. **INSUFFICIENT EVIDENCE:** No node, frequency, or synthesis data is available for XH-1, so quantitative ratios are not asserted. The latency and throughput figures are **TYPICAL** values for a 64-bit operand and are presented as order-of-magnitude estimates; the ranges are wider than in the prior draft to reflect the absence of a citable source. "Latency" is in cycles for back-to-back independent operations on the named unit; "throughput" is sustained operations per cycle for a fully pipelined or iterative unit, respectively.
+
+| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort |
+|---|---|---|---|---|---|
+| Iterative shift-add MUL (one row/cycle) + iterative subtractive DIV (separate) | ~64 (MUL) / ~64 (DIV) | ~1/64 (each) | Smallest | Smallest | Low |
+| Iterative radix-4 MUL (one row/cycle) + iterative subtractive DIV (separate) | ~32 (MUL) / ~64 (DIV) | ~1/32 (MUL), ~1/64 (DIV) | Small | Small to moderate | Low to moderate |
+| Shared iterative MUL/DIV (multiplexed, Approach 8) | ~64 (MUL) / ~64 (DIV), mutually exclusive | ~1/64 (each, contended) | Small to moderate (modest savings over split iterative; control overhead) | Small to moderate | Low to moderate |
+| Pipelined radix-4 array MUL + iterative subtractive DIV (split, Alternative A) | ~3–6 (MUL) / ~64 (DIV) | 1/cycle (MUL), ~1/64 (DIV) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 array MUL + 2-bit-per-cycle naïve DIV (Alternative D) | ~3–6 (MUL) / ~32 (DIV) | 1/cycle (MUL), ~1/32 (DIV) | Moderate | Moderate | Moderate |
+| Pipelined radix-4 array MUL + radix-4 SRT DIV | ~3–6 (MUL) / ~16 + conversion (DIV) | 1/cycle (MUL), ~1/16 (DIV) | Large | Large | High |
+| Pipelined radix-8 array MUL + Newton-Raphson or Goldschmidt DIV | ~3–6 (MUL) / a few MUL iterations (DIV) | 1/cycle (MUL), bounded by MUL (DIV) | Largest | Largest | High |
+
+**INSUFFICIENT EVIDENCE:** The relative magnitudes are illustrative and intended only to convey ordering. The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1. **INSUFFICIENT EVIDENCE:** Quantitative area, power, and energy comparisons cannot be made without a target node, frequency, and synthesis flow. The ranges given above are wider than the typical figures cited in the prior draft to reflect this uncertainty.
+
+## Advantages
+
+The leading candidates each have a distinct strength profile. The following are conditional on the workload and core microarchitecture, which are not yet established.
+
+- **Iterative separate MUL + iterative separate DIV (smallest, lowest power):** **ASSUMPTION.** Smallest per-core area and lowest power among the candidate RV64 designs. Easiest to verify. Long latency is the principal disadvantage.
+- **Shared iterative unit (Approach 8, with the qualification in §8):** **ASSUMPTION.** A defensible choice for cost-sensitive embedded cores, but for RV64 the area advantage over a split iterative design is modest and the control complexity of multiplexing MUL and DIV may offset the savings. Not recommended by default for RV64.
+- **Pipelined radix-4 MUL + iterative subtractive DIV (split, Alternative A):** **ASSUMPTION.** Matches a plausible workload asymmetry where MUL is more frequent than DIV; MUL throughput is high (common case), DIV cost is contained, and verification is tractable. This is a strong compromise candidate, not a leading candidate by default.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest predictable throughput on both operations; minimal front-end exposure if the core is in-order. Verification cost is high.
+- **Newton-Raphson or Goldschmidt DIV on top of fast MUL:** **TYPICAL.** Reuses the multiplier's silicon; area-efficient if the multiplier is already large. Verification cost is high.
+
+## Disadvantages
+
+- **Iterative separate MUL + iterative separate DIV:** **TYPICAL.** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided, and the forwarding path itself has non-trivial cost (see Alternative H).
+- **Shared iterative unit:** **TYPICAL.** Latency directly stalls the pipeline in an in-order core. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided. For RV64, the structural mismatch between MUL and DIV datapaths limits the achievable area savings, and the MUL/DIV datapaths contend for the shared unit.
+- **Pipelined radix-4 MUL + iterative DIV:** **TYPICAL.** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
+- **Pipelined radix-4 MUL + SRT DIV:** **TYPICAL.** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs (the Pentium FDIV bug being a radix-4 SRT selection-table defect, transferred by analogy to integer SRT). The verification cost is replicated at the unit level and is the dominant non-silicon cost of this design.
+- **Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean, formally-specified correction step.
+
+## XH-1 Considerations
+
+**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:
+
+1. **128-core replication amplifies per-core area cost.** **FACT.** A larger MUL/DIV unit pays the same area cost across all 128 cores, not just one. The die-area cost is severe. Verification effort is *not* amplified by the same factor (see item 4 and §Verification Considerations); the framing in earlier drafts of this document that listed "per-core area and verification cost" together as both amplified by replication conflates two distinct effects and is corrected here.
+2. **Per-core issue width and in-order/OoO status are not established.** **INSUFFICIENT EVIDENCE.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not, unless explicit forwarding is provided.
+3. **128 cores imply a tile- or mesh-style interconnect.** **ASSUMPTION.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations, unless a shared divider alternative (Alternative F) is adopted.
+4. **Verification cost is concentrated at the unit level, not multiplied by replication.** **TYPICAL.** A replicated unit is verified once at the unit level (RTL, formal, directed/random). The integration with each core's pipeline is identical across replications and is verified once via the core-level verification environment; running the same integration suite 128× does not add coverage. The 128× replication matters for silicon defect exposure (a bug that escapes verification affects all cores) and for DFT/scan/BIST architecture, not for per-instance verification run-count. This is the standard methodology for replicated unit-level verification in commercial designs.
+5. **Physical-design regularity matters under replication.** **TYPICAL.** A small, regular MUL/DIV unit is easier to harden and replicate 128× than a complex, irregular SRT unit.
+
+**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.
+
+**OPEN QUESTION:** Is the 128-core fabric homogeneous (all cores identical, all running the same software) or heterogeneous (e.g., application cores plus management or I/O cores)? Heterogeneity would relax the per-core MUL/DIV uniformity requirement and may allow per-tile optimization.
+
+## 128-Core Scalability
+
+The MUL/DIV unit is per-core and not shared across cores by default. Scalability considerations:
+
+- **No coherence problem.** **FACT.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
+- **No cross-core contention** in the default per-core configuration. **FACT.** Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior. A shared-divider alternative (Alternative F) changes this analysis.
+- **Verification parallelism.** **TYPICAL.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once at the unit level. Integration with the pipeline is verified once at the core level (since all cores are identical replications), not 128×. The 128× replication affects silicon defect exposure, not verification run-count.
+- **Area-budget pressure.** **TYPICAL.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
+- **Power-grid and clock distribution.** **TYPICAL.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. **INSUFFICIENT EVIDENCE:** Power delivery (IR drop), clock skew across the replicated load, and dynamic power density must be analyzed for the replicated load; no quantitative estimates are made here.
+- **Scan and BIST.** **TYPICAL.** A 128× replicated unit implies 128× the scan-chain length (if scan is per-core) or a partitioned BIST architecture. The choice affects DFT area and test time.
+- **Fault tolerance.** **TYPICAL.** A defect in the MUL/DIV unit is potentially a defect in all 128 cores. This argues for either a hardened, characterized macro or built-in redundancy / sparing, depending on yield targets.
+- **Timing variation.** **TYPICAL.** Across-die process variation affects 128 replicated units independently. A design that is timing-marginal at one corner may fail at another. Iterative designs are less sensitive to per-unit timing variation than deep-pipelined arrays.
+
+**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128. Prefer regular, hardenable structures over irregular ones that resist replication.
+
+## Performance Considerations
+
+MUL/DIV performance interacts with the rest of the core in two ways:
+
+1. **Latency exposure.** **FACT.** In an in-order core, MUL latency stalls the front-end unless explicit forwarding is provided. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
+2. **Throughput-bound on dependent chains.** **FACT.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.
+
+**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.
+
+## Area Considerations
+
+Relative area ordering, qualitative only (no synthesis data available):
+
+- Iterative shift-add MUL + iterative subtractive DIV (separate): smallest.
+- Iterative radix-4 MUL (one row/cycle) + iterative subtractive DIV (separate): small.
+- Shared iterative MUL/DIV (Approach 8): small to moderate, depending on the degree of datapath sharing and the control overhead; the area advantage over split iterative is modest for RV64.
+- Pipelined radix-4 MUL + iterative subtractive DIV (split): moderate.
+- Pipelined radix-4 MUL + 2-bit-per-cycle naïve DIV: moderate.
+- Pipelined radix-4 MUL + radix-4 SRT DIV: large.
+- Pipelined radix-8 MUL + Newton-Raphson / Goldschmidt DIV: largest.
+
+**INSUFFICIENT EVIDENCE:** The XH-1 per-core area budget must be defined before any of the above can be quantified in absolute terms. Absolute area figures require a process node and a synthesis flow.
+
+## Power and Energy Considerations
+
+Relative energy-per-operation ordering, qualitative only:
+
+- **Iterative:** **TYPICAL.** Low per-cycle power, but high per-operation energy × time product (many cycles).
+- **Pipelined MUL + iterative DIV:** **TYPICAL.** Low per-op MUL energy, high per-op DIV energy.
+- **Pipelined MUL + SRT DIV:** **TYPICAL.** High per-cycle power, lower per-op energy than iterative.
+- **Pipelined MUL + Newton-Raphson / Goldschmidt DIV:** **TYPICAL.** Per-op energy is a small multiple of MUL energy; competitive.
+
+**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative subtractive DIV is a reasonable energy-vs-area compromise, contingent on the workload.
+
+**INSUFFICIENT EVIDENCE:** Quantitative power and energy figures require a process node, a clock target, and a workload trace.
+
+## Implementation Considerations
+
+- **Wallace/Dadda tree synthesis risk.** **TYPICAL.** Compressor trees are known to be hard to place-and-route at high frequency on modern nodes; poor placement can introduce unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon. *This is an engineering judgment, not an established fact; specific delay figures depend on the synthesis flow and library, and are not asserted here.*
+- **PPG and Booth recoder verification.** **TYPICAL.** Radix-4 PPGs are well-understood and tractable to verify; radix-8+ PPGs require more corner cases. The `MULH` signed×signed upper-half path requires explicit verification of sign-extended partial products and is not a free byproduct of the unsigned array. The `MULHSU` path requires explicit sign-handling verification (Baugh-Wooley or Modified Booth) and is not a vanilla 65×64 unsigned array.
+- **SRT selection table correctness.** **TYPICAL.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
+- **RISC-V division-by-zero and overflow conventions.** **FACT.** `DIV` and `DIVU` return `-1` (all bits set) on divide-by-zero; `REM` and `REMU` return the dividend on divide-by-zero. On signed overflow (`INT64_MIN / -1`), `DIV` returns `INT64_MIN` and `REM` returns 0. These must be implemented explicitly; the design must not raise a trap.
+- **Pipeline interlocks.** **FACT.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
+- **Physical design replication.** **TYPICAL.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication and are a physical-design risk under replication.
+
+## Verification Considerations
+
+Verification cost is a dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:
+
+- **Radix-2/4 shift-add and subtractive:** **TYPICAL.** Lowest. Exhaustive simulation at reduced widths is tractable.
+- **Radix-4 Booth + iterative DIV:** **TYPICAL.** Moderate. The hard cases are the signed division edge cases (division-by-zero, `INT64_MIN / -1`), the `MULH` signed×signed upper-half path (sign-extended partial products, not a free byproduct of the unsigned array), and the `MULHSU` sign-extension (Baugh-Wooley or Modified Booth, not a vanilla unsigned array). The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and the bulk of `MULHSU`; `MULH` is a separate verification pass; `MULHSU` requires explicit sign-handling verification.
+- **SRT:** **TYPICAL.** High. SRT selection-table bugs are famous in industry (the Pentium FDIV bug was a missing entry in the PLA implementing the radix-4 SRT lookup table of the floating-point divider; the lessons transfer to integer SRT by analogy, with the caveat that FP and integer SRT use different quotient-digit sets and selection functions). Verification typically requires formal proofs of the selection function over reduced widths and extensive directed testing.
+- **Newton-Raphson / Goldschmidt:** **TYPICAL.** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
+- **Replication factor:** **TYPICAL.** A bug in the MUL/DIV unit that escapes verification is a bug in all 128 cores (silicon defect exposure). However, the verification effort itself is not 128×: the unit is verified once at the unit level, and the core-level integration is verified once (cores are identical replications). The risk is concentrated exposure, not multiplied effort. This is the standard methodology for replicated unit-level verification in commercial designs.
+
+**Preliminary verification strategy** (to be refined once the design choice is made):
+
+- **Unit-level:** Exhaustive simulation at reduced operand widths (e.g., 8, 12, 16 bits) for the core datapath. Formal equivalence checking between the RTL and a reference model written in a high-level specification language (e.g., Bluespec, Scala, or a C reference). For SRT or Newton-Raphson, formal proof of the selection function or the convergence step.
+- **Directed corner-case suite:** Explicit tests for division-by-zero (both `DIV`/`DIVU` and `REM`/`REMU` paths), signed overflow (`INT64_MIN / -1`, both quotient and remainder), `MULH` against a cross-checked reference (Baugh-Wooley or equivalent), `MULHSU` against a cross-checked reference (with explicit sign-handling verification), and the `MUL`-then-truncate boundary.
+- **Random / constrained-random:** At full width, comparing against a software reference. Coverage targets on the Booth recoder, PPG, and selection table.
+- **Integration:** Per-core pipeline integration verified once at the core level (not 128×), since cores are identical.
+- **Post-silicon:** Microarchitectural validation suite, focused on MUL/DIV-intensive kernels (big-integer arithmetic, hashes, polynomial multiplications).
+
+**PROPOSAL:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.
+
+## Software Considerations
+
+- **Compiler behavior.** **FACT.** GCC and LLVM routinely use shift-and-add sequences for multiplication by small constants, and they may either emit `MUL` instructions or inline expansions depending on the cost model. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences, but the magnitude of this effect is workload- and compiler-version-dependent and should not be assumed.
+- **Library code.** **FACT.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
+- **System software.** **TYPICAL.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
+- **128-core interaction.** **ASSUMPTION.** In a homogeneous configuration where the system stack (kernel, hypervisor) runs on some subset of the 128 cores, there is no asymmetric design implication: every core is equal in the default per-core configuration. **INSUFFICIENT EVIDENCE:** Whether the 128-core fabric is homogeneous or heterogeneous (e.g., application cores plus management or I/O cores) is an open question (see Open Questions); the assumption of homogeneity is provisional.
+
+**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.
+
+## Recommendation
+
+**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:
+
+1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
+2. The per-core area and power budget.
+3. The target workload mix and software ecosystem.
+
+**Conditional recommendations** (to be revisited once the above are known):
+
+- **If XH-1 targets an in-order core with tight area budget:** **PROPOSAL.** A separate iterative shift-add MUL (one row/cycle) and an iterative subtractive DIV is the smallest, easiest-to-verify choice. MUL/DIV latency will be high; whether this is acceptable depends on the forwarding path and the workload. **The forwarding path is a real and non-trivial cost:** the bypass network from the MUL/DIV output to dependent consumers (ALU, branch, load/store) must be sized to the full MUL/DIV latency, and the wiring may dominate the area of the iterative MUL/DIV unit itself. This cost should be quantified before the iterative unit is chosen. The shared-iterative-unit approach (Approach 8) is *not* recommended for RV64 by default, given the structural mismatch between MUL and DIV datapaths and the modest area advantage over a split iterative design.
+- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** **PROPOSAL.** A pipelined radix-4 Booth multiplier (3–6 stage pipeline) paired with a 2-bit-per-cycle naïve divider or a radix-4 SRT divider. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle. **Reconciliation note:** the cross-cutting recommendation below defers SRT until formally proven correct; if SRT cannot be formally verified on reduced widths within the project timeline, the 2-bit-per-cycle naïve divider is the preferred DIV companion. The SRT recommendation is conditional on the verification investment being made.
+- **If the per-core area budget is moderate and the workload is balanced:** **PROPOSAL.** A pipelined radix-4 MUL with an iterative subtractive DIV (the "split" approach, Alternative A) is a strong compromise.
+
+**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson / Goldschmidt rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.
+
+## Confidence
+
+| Topic | Confidence |
+|---|---|
+| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
+| Relative area, power, and energy rankings | Low to medium (qualitative ordering only; no synthesis data) |
+| Per-cycle latency numbers | Low to medium (typical, but node- and target-frequency-dependent; ranges are illustrative, not tight bounds) |
+| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
+| Specific recommendation | **Insufficient evidence** to commit |
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
+2. What is the per-core area budget, in absolute terms or as a fraction of die area?
+3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
+4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused or augmented.
+5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
+6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
+7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power and replication regularity; synthesis-per-core favors design flexibility.
+8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
+9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
+10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.
+11. Will the MUL/DIV unit be shared with the FP pipeline (as in BOOM and some SiFive designs, though not in Rocket Chip), or kept private to the integer pipeline?
+12. Will XH-1 adopt a shared multi-cycle divider across cores (Alternative F), or is a strictly per-core MUL/DIV unit required?
+
+## Sources
+
+- Canonical computer-arithmetic references: Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*. These cover the techniques surveyed above in standard form. **Caveat:** these texts underwrite the taxonomy and the mechanism descriptions. Specific per-cycle latency figures given in this document are **TYPICAL** values drawn from common practice in published RV64 designs; the cited texts provide the algorithmic background but do not, in their canonical editions, supply XH-1-specific latency or area numbers. No specific chapter or page is cited for the quantitative figures because the figures are not drawn from a single source.
+- Open RISC-V core implementations (Rocket, BOOM, XiangShan, SiFive) provide reference designs for radix-4 array multipliers, iterative and SRT dividers, and FP/integer multiplier sharing. These are cited as implementation exemplars, not as XH-1 references. **FACT.** Rocket Chip keeps the integer and FP multipliers as separate units; BOOM and some SiFive designs share partial structures. The blanket attribution of sharing to "Rocket, BOOM, and most SiFive cores" in the prior draft of this document overstates the case and is corrected here.
+- **INSUFFICIENT EVIDENCE:** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
+- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as qualitative engineering estimates or as canonical background knowledge in the field of computer arithmetic.