setup

research/.xh1/runs/20260825T181402Z/attempts

@@ -0,0 +1 @@
+2026-08-25T18:15:25Z	research/03-core-design/mul-div-unit.md	1	research	completed

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

@@ -0,0 +1,338 @@
+# XH-1 Multiply/Divide Unit (MDU) Research
+
+## Status
+
+Stub document. Repository context for XH-1 does not establish:
+- Pipeline depth of the base integer pipeline
+- Whether cores are in-order or out-of-order
+- Target clock frequency, process node, or PDK
+- ISA extensions ratified (e.g., RV64IM, M-extension always assumed; F/D, V, B, K, H absent without evidence)
+- Performance targets (IPC, target workload mix)
+- Area, power, or energy budgets
+- Memory hierarchy parameters
+
+This document therefore proposes structures and trade-offs but cannot validate them against a concrete XH-1 baseline. All quantitative claims are labeled estimates and should be re-derived once baseline parameters are fixed.
+
+## Abstract
+
+The multiply/divide unit (MDU) is responsible for integer multiplication, division, and remainder operations defined in the RISC-V M-extension (and the optional Zmmul/Zihintpause subsets). For a 128-core design, the MDU is a critical area and latency bottleneck: it is one of the most area-intensive execution units in an integer datapath, and its long latency for division operations interacts with the pipeline, the register file read/write ports, and the scoreboard/issue logic. Because the MDU is also replicated 128 times, even modest per-core area or power inefficiency is multiplied across the die.
+
+This document surveys common MDU microarchitectures (iterative subtract-and-shift, SRT radix-4/radix-8, radix-2 non-restoring, array multipliers, Wallace/Dadda trees, Booth-encoded array multipliers, combined multiply-accumulate, and pipelined iterative dividers) and analyzes their suitability for XH-1. The analysis is grounded in widely known textbook and industrial design patterns rather than any specific XH-1 measurement.
+
+## Research Question
+
+What is the appropriate microarchitecture for the integer multiply/divide unit in each XH-1 core, given:
+1. Unknown core pipeline depth and issue order
+2. 128-core replication constraint
+3. Unknown frequency, area, power, and energy targets
+4. The need to support RV32M/RV64M instructions: MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU (RV64 also: DIVW, DIVUW, REMW, REMUW, MULW)
+
+Sub-questions:
+- What multiplier architecture best balances latency, area, and power at unknown frequency targets?
+- What divider architecture provides acceptable latency without inflating critical path or area?
+- Should the MDU be pipelined, multi-cycle iterative, or a hybrid?
+- How does the MDU interact with the register file, bypass network, and issue/arbitration logic?
+- What is the right way to handle 64-bit × 64-bit → 128-bit (MULH family) and the W-suffixed 32-bit ops in RV64?
+- What division algorithm handles signed division correctly without an extra correction cycle?
+
+## Background
+
+### RISC-V M-Extension Semantics
+
+FACT: The RISC-V M-extension defines eight base multiplication instructions and eight division/remainder instructions on RV32. On RV64, the W-suffixed variants operate on 32-bit values sign- or zero-extended to 64 bits, and the unsigned W forms (DIVUW, REMUW) must round toward zero. The MULH family returns the upper 64 bits of a 128-bit product.
+
+The M-extension operation summary (RV64 base form):
+- MUL, MULW: low 64/32 bits of product, lower XLEN bits written
+- MULH: signed × signed, upper XLEN bits
+- MULHU: unsigned × unsigned, upper XLEN bits
+- MULHSU: signed × unsigned, upper XLEN bits
+- DIV/DIVU, DIVW/DIVUW: signed/unsigned quotient, round-to-zero semantics
+- REM/REMU, REMW/REMUW: signed/unsigned remainder, sign follows the dividend (not the divisor), defined such that `d = (d / q) * q + (d % q)`
+
+### Why the MDU Matters
+
+ASSUMPTION: Most non-trivial programs perform at least some integer multiplications. Division is rarer but has high latency penalties when it stalls the pipeline. SPEC CPU integer and most server workloads have a small but non-negligible fraction of MUL/DIV (typically a few percent of dynamic instructions, with division being one to two orders of magnitude less frequent than multiplication).
+
+### Latency Classes
+
+The MDU typically has two distinct latency classes:
+- Multiply: low latency (1–4 cycles) for low-half, higher (3–5) for high-half MULH
+- Divide: long latency (4–35+ cycles depending on radix, operands, and whether signed/unsigned)
+
+This bimodal latency profile is a key design driver: it dictates issue logic complexity, scoreboard behavior, and how the unit is replicated.
+
+## Existing Approaches
+
+### Multipliers
+
+1. **Array multiplier (basic)**
+   - Carry-save array of full adders. Critical path O(n) full-adder delays.
+   - PROPOSAL: low-frequency, area-tolerant baseline.
+   - DISADVANTAGE: poor performance at high frequency; high energy per op.
+
+2. **Wallace tree**
+   - Counter-tree reduction of partial products; final carry-propagate adder (CPA) for the final sum.
+   - ADVANTAGE: logarithmic depth (O(log n)).
+   - DISADVANTAGE: irregular layout, complex routing, harder to verify.
+
+3. **Dadda tree**
+   - Variant of Wallace; reduces the number of longer counters. Slightly fewer gates than Wallace for the same delay in some implementations.
+
+4. **Booth-encoded array / tree multiplier**
+   - Radix-4 (or higher) Booth recoding halves (or quarters) the number of partial products.
+   - For 64-bit operands, radix-4 Booth yields 32 partial products; radix-8 yields ~22.
+   - Reduces tree height, area, and dynamic capacitance at the cost of Booth-encoder logic and signed-correction terms.
+
+5. **Carry-save multiplier with final CPA**
+   - Keeps internal representation in carry-save form; one CPA at the end.
+   - Common in pipelined designs.
+
+6. **Iterative shift-and-add multiplier**
+   - One cycle per bit of operand. Very small area, very long latency.
+   - Inappropriate for any high-performance core; may be acceptable in tiny embedded cores.
+
+7. **Pipelined multiplier**
+   - Multiple pipeline stages; one multiplication initiated per cycle after fill.
+   - Throughput = 1/cycle, but latency grows.
+   - Interacts with main pipeline depth: should typically be 1–3 cycles for a 64-bit multiplier at typical embedded-class frequencies, or 2–4 cycles for high-frequency designs.
+
+### Dividers
+
+1. **Subtract-and-shift (radix-2 restoring)**
+   - One bit of quotient per cycle; ~32 or 64 cycles for 32/64-bit division.
+   - Tiny area; very long latency.
+
+2. **Radix-2 non-restoring**
+   - One bit per cycle; constant-time datapath; needs a final correction step for sign and remainder.
+   - Marginally smaller than restoring; same throughput.
+
+3. **SRT radix-4**
+   - Two quotient bits per cycle; ~16/32 cycles for 32/64-bit.
+   - Lookup table of redundant quotient digits; more complex than radix-2.
+   - Common in high-performance cores (e.g., as discussed in Hennessy & Patterson).
+
+4. **SRT radix-8 / radix-16**
+   - 3–4 bits per cycle; ~8–17 cycles for 64-bit.
+   - Larger tables; more area; more difficult to verify.
+   - Used in some superscalar/OoO cores.
+
+5. **Newton–Raphson reciprocal + multiply**
+   - Iteratively refine reciprocal, then one final multiply. Fast (5–8 cycles for 64-bit).
+   - High area (table lookup, multiplier reused for the final multiply). Better for OoO cores that already have a fast multiplier.
+
+6. **Goldschmidt division**
+   - Similar to Newton–Raphson; uses multiplication by precomputed factors. Same trade-off.
+
+7. **Combined multiply/divide (e.g., shared CSA tree)**
+   - Reuse the multiplier hardware as the divider datapath. Common in modern cores; saves area at the cost of tying two units' schedules together.
+
+8. **Pipelined iterative divider**
+   - Pipelined SRT or radix-N; divides one operand every cycle after fill. Latency is the depth, throughput is 1/cycle. Best for high-throughput OoO cores.
+
+### Multiply–Accumulate
+
+ASSUMPTION: Some cores fuse MUL+MULH or MUL+ADD into a MAC operation. RISC-V does not define such an instruction in the base ISA, but vendor extensions or a custom XH-1 extension could. Not in scope of base MDU.
+
+## Alternative Designs
+
+For each XH-1 core, the MDU is a candidate for one of the following microarchitectural envelopes:
+
+### Option A: Iterative Radix-2 Combined MDU
+- Multiplier: 1 cycle per bit (~32 cycles for MUL, 64 for MULH).
+- Divider: 1 bit per cycle, 32/64 cycles.
+- One shared CSA datapath.
+- Very small area; no pipelining.
+- Latency dominates; not viable for a 128-core design where even moderate per-core performance matters.
+
+### Option B: Single-Cycle Radix-4 Booth × Array, Multi-Cycle Iterative Divider
+- Multiplier: 64×64→128 in 1–2 cycles, low half in 1 cycle.
+- Divider: radix-2 non-restoring, 1 bit/cycle, 32/64 cycles.
+- Moderate area; multiplier is the long-path concern; divider is area-cheap.
+- Reasonable for embedded-class frequencies.
+
+### Option C: Pipelined Radix-4/8 Booth Tree, Pipelined Radix-4 SRT Divider
+- Multiplier: 2–4 pipeline stages, 1 multiply per cycle after fill.
+- Divider: pipelined SRT radix-4, 1 division per ~8–10 cycles.
+- Larger area; better throughput; more ports on the register file, more bypass paths.
+- Fits OoO or wide-issue cores.
+
+### Option D: Pipelined Radix-8 Multiplier, Newton–Raphson Divider
+- Multiplier: 2–3 stage radix-8 Booth.
+- Divider: table-init + 2 NR iterations + 1 final multiply.
+- Best division latency; highest area; requires sharing the multiplier between divide and multiply paths.
+
+### Option E: Configurable Radix (low-power mode)
+- Optional: throttle divider radix to save power in low-utilization scenarios.
+- Not standard in commercial cores; adds verification burden.
+
+## Comparison
+
+Comparison axes (per core, qualitative; quantitative figures are estimates without a fixed PDK/target):
+
+| Option | Mul latency | Mul throughput | Div latency (64-bit, uns) | Area (rel.) | Power (rel.) | Complexity | Verif. burden |
+|--------|-------------|----------------|----------------------------|-------------|--------------|------------|---------------|
+| A: Radix-2 iterative | ~64 cyc | 1/64 cyc | ~64 cyc | Very low | Very low | Low | Low |
+| B: Radix-4 array + radix-2 div | 1–2 cyc | 1/1–2 cyc | ~64 cyc | Moderate | Moderate | Moderate | Moderate |
+| C: Pipelined Booth + SRT-4 | 2–4 cyc | 1/cyc | ~16 cyc | High | High | High | High |
+| D: Radix-8 + NR divider | 2–3 cyc | 1/cyc | ~5–8 cyc | Highest | Highest | Highest | Highest |
+| E: Configurable | (variable) | (variable) | (variable) | High+ | High+ | Highest | Highest |
+
+PROPOSAL: For an unknown baseline, Option B and Option C are the most defensible starting points. Option A is appropriate only for an explicitly area-constrained embedded profile. Option D is appropriate only if the core is OoO with high issue width and division latency is on the critical performance path.
+
+## Advantages
+
+- **Option A**: smallest area, easiest to verify, lowest power per core. Good for area-bound 128-core dies.
+- **Option B**: balanced; multiplier is fast enough to be single-issue in most pipelines; divider is the weak link but small.
+- **Option C**: high throughput on both mul and div; aligned with OoO or wide superscalar cores.
+- **Option D**: lowest division latency; NR is a well-understood algorithm.
+
+## Disadvantages
+
+- **Option A**: division latency will dominate any long-latency operation count; FMA-heavy or hash-heavy code stalls. For 128 cores replicated, the per-core penalty multiplies.
+- **Option B**: divider stalls the issue logic for tens of cycles; reservation stations/scoreboards must hold operands; the issue queue depth must absorb this.
+- **Option C**: register file pressure: pipelined iterative divider may want to read 64-bit operands once and write 64-bit result later, but it must also accept new operands. The issue/arbitration logic must prevent structural hazards on the divider.
+- **Option D**: NR requires an initial reciprocal table (1–2 KB) per core, replicated 128 times = 128–256 KB total for the table. Significant area at large scale. Must be carefully designed for low static power.
+
+## XH-1 Considerations
+
+Without confirmed XH-1 core order (in-order vs out-of-order), pipeline depth, or frequency target, the following sub-recommendations apply:
+
+ASSUMPTION: XH-1 targets a balanced general-purpose or server-class workload, not a microcontroller class. A 128-core die implies a focus on throughput, not single-thread peak.
+
+If XH-1 is in-order (per core):
+- A long-latency divider stalls the pipeline for the entire division. Either the core must have deep OOO machinery at the issue stage, or division latency must be bounded.
+- Option B (multi-cycle iterative divider) is more realistic than C/D.
+- MULH latency matters: if it is 1–2 cycles, the bypass network from MDU to ALU must include a fast path. If 3+ cycles, a one-cycle bubble is acceptable in a shallow in-order pipeline.
+
+If XH-1 is out-of-order:
+- Division latency can be hidden by speculation if the divisor is known early.
+- Option C or D is more attractive; the cost of the long-latency unit is amortized by IPC.
+- Issue queue must handle the unit's variable latency.
+
+PROPOSAL: Until core order is fixed, design the MDU to be **modular**: a radix-4 Booth multiplier (low half in 1 cycle, full 64×64 in 2 cycles) shared with a radix-2 non-restoring divider, with the divider exposed as a single multi-cycle functional unit. This is consistent with Option B and is incrementally upgradeable to Option C if a pipelined divider is added later.
+
+## 128-Core Scalability
+
+Each MDU is replicated 128 times. Scalability concerns:
+
+- **Area**: The MDU is one of the larger non-frontend units. If the multiplier alone is ~0.05–0.15 mm² and the divider ~0.02–0.05 mm² at a modern node (estimate; depends on process and frequency), 128× MDU area is 9–25 mm² total (estimate). This is significant but not dominant compared to caches/interconnect.
+- **Power**: Multipliers and especially SRT dividers are dynamic-power-heavy during computation. With 128 cores potentially issuing MUL/DIV, peak power in the MDU array may be a non-trivial slice of the die's power budget (INSUFFICIENT EVIDENCE for a precise fraction).
+- **Clock distribution**: A long combinational path through a tree multiplier is a clock-tree risk. A pipelined multiplier breaks the path but adds register area and clock load.
+- **Verification**: 128 identical units are verified in parallel; this is favorable. The MDU verification focus should be on **mathematical correctness** of division (signed, round-to-zero, edge cases) rather than replication.
+- **Yield**: A defect in the MDU logic is replicated 128×, so its fault coverage must be very high. Recommend formal verification of the divider's quotient/remainder invariants.
+
+PROPOSAL: Keep the MDU small and well-isolated. Do not let it become the critical path that dictates the global clock period. If the only way to meet timing is to pipeline the multiplier, do so; the cost is one cycle of latency and one extra write port on the integer register file.
+
+## Performance Considerations
+
+- **MUL throughput**: At 1 multiply/cycle per core (pipelined), 128 cores can issue up to 128 multiplies per cycle across the die. Aggregate multiply bandwidth is high; the more pressing concern is per-core latency hiding.
+- **MULH throughput**: MULH uses a 64×64→128 multiplier. On RV64, a 128-bit result requires either a wider datapath or two cycle reuse of a 64-bit multiplier. The former doubles MDU area; the latter doubles MULH latency. PROPOSAL: prefer a true 64×64→128 datapath (single cycle) since the alternative doubles register-file read pressure.
+- **DIV throughput**: 1 per 16 cycles (SRT-4) or 1 per 64 cycles (radix-2) per core. Across 128 cores, average DIV throughput is high in aggregate but per-thread latency is the user-visible metric.
+- **MUL–MULH coupling**: A common implementation is to compute the full 128-bit product once, then take either low or high half. This is a clean reuse strategy.
+- **DIV–REM coupling**: In non-restoring or SRT, quotient and remainder come out together. The MDU can expose both at the same latency. RISC-V requires both with consistent semantics.
+- **W-suffixed ops in RV64**: Operands are sign- or zero-extended from 32 to 64. The MDU can simply perform 64-bit ops with the upper 32 bits forced to zero/sign-extended. No special hardware is needed if the register file read provides the correct extension (which the standard RF does on RISC-V).
+
+## Area Considerations
+
+Estimated relative area, normalized to a baseline radix-2 iterative combined MDU (very rough, no PDK):
+
+| Design | Relative area (rough) |
+|--------|------------------------|
+| Radix-2 iterative (A) | 1.0× |
+| Radix-4 array + radix-2 div (B) | ~3–5× |
+| Pipelined radix-4 + SRT-4 (C) | ~6–10× |
+| Radix-8 + NR divider (D) | ~8–12× |
+
+These are estimates. Actual area depends heavily on:
+- Multiplier radix and Booth encoding depth
+- Whether CSA is retained to the final CPA
+- Divider's choice of redundant representation and on-the-fly quotient conversion
+- Pipeline register count
+- Whether a 64×64→128 result is held in a single 128-bit register or two 64-bit latches
+
+PROPOSAL: For a 128-core design, choose the smallest MDU that meets per-core latency targets. Area scaling is multiplicative across cores; a 10× MDU is 10× cost across the die.
+
+## Power and Energy Considerations
+
+- **Static power**: A large MDU (Option C/D) has more leakage. Across 128 cores, leakage adds up. Clock-gating the MDU when no MUL/DIV is in flight is essentially mandatory; consider also input-gating operand muxes to prevent toggling.
+- **Dynamic power**: A pipelined multiplier toggles every cycle when active. A non-pipelined iterative multiplier toggles only during active cycles but for longer. Per-operation energy is generally lower for the non-pipelined option at low utilization.
+- **NR divider**: The initial reciprocal table lookups can be gated; iteration multiplies are power-hungry but brief.
+- **Energy per op**: For low-utilization workloads, smaller/iterative MDUs are more energy-efficient per operation. For high-utilization workloads, pipelined MDUs amortize the per-op energy.
+
+INSUFFICIENT EVIDENCE to recommend a specific energy target without workload mix and frequency data.
+
+## Implementation Considerations
+
+- **Operand alignment**: The MDU takes two XLEN-bit operands and produces either XLEN or 2*XLEN bits. The result muxes must be carefully timed; the 128-bit result for MULH is on the critical path to the register file write port.
+- **Bypass network**: MUL result must be bypassable to dependent operations. MUL→ADD, MUL→MUL, MUL→branch (for select-on-result patterns) all need bypass paths.
+- **Scoreboard / wakeup**: In an OoO core, the MDU must signal completion to wake up dependent instructions. Variable latency (mul vs div) requires tagged completion events.
+- **Flush behavior**: On branch mispredict or exception, in-flight MDU operations must be killed. Pipelined iterative units must be safely drainable.
+- **Special values**: DIV/REM with divisor=0 raises a divide-by-zero exception; the quotient register is written with -1 (signed) or 2^XLEN-1 (unsigned), remainder with the dividend. The MDU must produce these values even on the exception path. The simplest implementation: detect divisor=0, force the result muxes, raise the exception flag.
+- **Overflow**: Signed DIV/REM is defined to overflow when the dividend is -2^(XLEN-1) and the divisor is -1; quotient is -2^(XLEN-1), remainder is 0. This is a known corner case.
+- **Sign handling for non-restoring/SRT**: The quotient bits come out in a redundant form; the on-the-fly conversion (or final correction) must apply the sign correction. This is a well-known source of bugs.
+- **W-suffixed ops**: The result of MULW is the low 32 bits sign-extended to 64. The MDU can compute the full 64-bit product and just route the low 32 bits with sign-extension, or compute a 32×32→64 product. The former is simpler and reuses the 64-bit datapath; recommended.
+
+## Verification Considerations
+
+- **Mathematical correctness**: Division is a top source of MDU bugs across the industry. Strongly recommend:
+  - Random testing with a slow software reference (e.g., a software DIV routine) across the full input space, including all corner cases: 0 divisor, -1 divisor, INT_MIN dividend, INT_MIN/INT_MIN, INT_MIN/-1, alternating bit patterns.
+  - Formal verification of quotient/remainder invariants (`q*d + r == n` and `|r| < |d|` and sign-of-r-follows-n).
+- **Self-consistency**: For every (a, b), the MDU must satisfy `MDU_DIV(a, b) * b + MDU_REM(a, b) == a` (with sign handling).
+- **MULH/MUL consistency**: For signed × signed, `MULHSU(a, b)` and `MULHU(|a|, b)` (with sign correction) must agree.
+- **W-op consistency**: DIVW(a, b) should equal sign-extend32(DIV(sign-extend32(a), sign-extend32(b))). Random differential testing.
+- **Coverage**: Target 100% code and toggle coverage on the MDU; FSM coverage on the divider state machine.
+- **Cross-core**: A defect in the MDU RTL hits 128 instances. The verification cost is paid once but the fault-coverage target must be high.
+- **Latency timing**: Verify the latency contract (1/2/N cycles) at the interface level so that downstream issue/retire logic is correct.
+
+## Software Considerations
+
+- **Compiler**: GCC/LLVM emit MUL/DIV/REM for the corresponding C operators. Idiomatic C rarely exposes division; the issue is more around hash functions, big-integer arithmetic, and base conversions.
+- **Libraries**: libgcc / compiler-rt provide software fallbacks for division if the hardware path is unavailable. The MDU should match the ABI (M-extension) expectations; otherwise the OS or runtime must emulate.
+- **Constant division**: A compiler strength-reduction pass converts division by a power of 2 into a shift. For non-power-of-2 constants, some compilers (e.g., GCC) can emit a multiply-by-reciprocal sequence if the hardware division is too slow. This affects what hardware division latency is "good enough".
+- **Builtins**: __builtin_mul_overflow etc. on GCC/Clang map to MUL/branch sequences. Performance of these depends on MDU latency.
+- **OS context switch**: MDU has no architectural state; context switch does not interact with the MDU.
+- **Vector / SIMD**: RISC-V V-extension is out of scope unless XH-1 adopts it. If V is added later, the MDU does not change but vector multiply-accumulate units (independent hardware) will.
+
+## Recommendation
+
+PROPOSAL: Adopt a design in the **Option B** family for the initial XH-1 MDU:
+- **Multiplier**: 64×64→128-bit radix-4 Booth-encoded CSA tree, single-cycle low-half result, two-cycle high-half (MULH) result, both written to the register file in 2 cycles total. The CSA tree is followed by a final CPA. 64×64 partial product count is 32 (radix-4), manageable for a single combinational stage at moderate frequency. If the critical path is too long for the target clock, add a single pipeline register between CSA tree and CPA; this becomes Option C-lite.
+- **Divider**: Radix-2 non-restoring, 64 cycles for RV64 / 32 cycles for RV32 / 32 cycles for W-ops. Constant-time datapath; quotient and remainder produced in the same iteration. Final sign-correction and round-to-zero applied in the last cycle.
+- **Shared datapath**: The CSA tree and partial-product reduction are reused where possible. The divider is otherwise independent of the multiplier to keep verification simple.
+- **Latency contract**: MUL/MULW = 1 cycle; MULH family = 2 cycles; DIV/DIVU/REM/REMU and W-suffixed variants = N+1 cycles (where N is operand width) plus a final correction cycle, ≈ 33/65 cycles for RV32/RV64. The scoreboard/issue logic is designed against these numbers.
+- **Special-case handling**: DIV/REM by 0 and overflow paths produce architecturally defined result values and raise exceptions. The MDU has a small input-gate to zero-out internal state when the operation completes early on a trap.
+
+This recommendation is provisional and is conditional on:
+- Confirmation of the core order (in-order vs out-of-order). For OoO, re-evaluate toward Option C.
+- Confirmation of the target frequency. If a higher frequency is set, the multiplier may need to be pipelined.
+- Confirmation of the area budget. If the budget is tight, fall back toward Option A's divider.
+
+## Confidence
+
+- **High confidence**: The M-extension semantics, the standard algorithms (radix-2 non-restoring, radix-4 Booth, SRT-4), the corner cases (div by 0, INT_MIN/-1, sign of remainder), the general area/latency trade-off directions.
+- **Medium confidence**: The relative-area and relative-power tables; they are estimates and depend on the unknown PDK and frequency.
+- **Low confidence**: Any specific cycle-count or area number for XH-1; no XH-1 measurements are available.
+- **Very low confidence**: Recommendations about pipelined vs non-pipelined without knowing core order and frequency.
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? (Foundational; drives all MDU trade-offs.)
+2. What is the target pipeline depth and clock frequency? (Drives multiplier pipelining decision.)
+3. Is the XH-1 ISA RV32 or RV64, and which extensions are ratified?
+4. What is the per-core area budget for execution units (ALU + MDU + branch + LSU)?
+5. What is the target workload mix? (Division-heavy workloads change the divider trade-off.)
+6. Is there a custom XH-1 extension that would change the MDU's responsibilities (e.g., a fused MAC)?
+7. Does XH-1 adopt the V-extension? (If yes, the scalar MDU stays as is, but a vector MAC unit is needed separately.)
+8. What is the static-power budget at the target process node? (Affects whether large array multipliers are acceptable.)
+9. Is the MDU expected to be fault-tolerant or SECDED-protected? (Affects pipeline register design.)
+10. Does the issue/arbitration logic treat the MDU as a single multi-cycle unit, or as separate mul and div functional units? (Affects which microarchitecture is compatible with the rest of the core.)
+
+## Sources
+
+INSUFFICIENT EVIDENCE for XH-1-specific sources; the design space and algorithms referenced here are textbook material:
+
+- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (general sections on multiplier/divider design; editions vary; no specific edition cited here).
+- RISC-V *Unprivileged ISA Specification* (M-extension semantics, division corner cases, W-suffixed ops on RV64). Publicly available at riscv.org; specific version numbers and page references are not cited here.
+- Standard references on SRT division and Booth recoding are not cited specifically; the algorithms are well-known.
+
+No XH-1 measurements, no third-party benchmarks, and no external papers are cited because none are available in the repository context. Any quantitative claim in this document is an estimate and should be re-derived when the XH-1 baseline parameters are fixed.

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

@@ -0,0 +1,338 @@
+# XH-1 Multiply/Divide Unit (MDU) Research
+
+## Status
+
+Stub document. Repository context for XH-1 does not establish:
+- Pipeline depth of the base integer pipeline
+- Whether cores are in-order or out-of-order
+- Target clock frequency, process node, or PDK
+- ISA extensions ratified (e.g., RV64IM, M-extension always assumed; F/D, V, B, K, H absent without evidence)
+- Performance targets (IPC, target workload mix)
+- Area, power, or energy budgets
+- Memory hierarchy parameters
+
+This document therefore proposes structures and trade-offs but cannot validate them against a concrete XH-1 baseline. All quantitative claims are labeled estimates and should be re-derived once baseline parameters are fixed.
+
+## Abstract
+
+The multiply/divide unit (MDU) is responsible for integer multiplication, division, and remainder operations defined in the RISC-V M-extension (and the optional Zmmul/Zihintpause subsets). For a 128-core design, the MDU is a critical area and latency bottleneck: it is one of the most area-intensive execution units in an integer datapath, and its long latency for division operations interacts with the pipeline, the register file read/write ports, and the scoreboard/issue logic. Because the MDU is also replicated 128 times, even modest per-core area or power inefficiency is multiplied across the die.
+
+This document surveys common MDU microarchitectures (iterative subtract-and-shift, SRT radix-4/radix-8, radix-2 non-restoring, array multipliers, Wallace/Dadda trees, Booth-encoded array multipliers, combined multiply-accumulate, and pipelined iterative dividers) and analyzes their suitability for XH-1. The analysis is grounded in widely known textbook and industrial design patterns rather than any specific XH-1 measurement.
+
+## Research Question
+
+What is the appropriate microarchitecture for the integer multiply/divide unit in each XH-1 core, given:
+1. Unknown core pipeline depth and issue order
+2. 128-core replication constraint
+3. Unknown frequency, area, power, and energy targets
+4. The need to support RV32M/RV64M instructions: MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU (RV64 also: DIVW, DIVUW, REMW, REMUW, MULW)
+
+Sub-questions:
+- What multiplier architecture best balances latency, area, and power at unknown frequency targets?
+- What divider architecture provides acceptable latency without inflating critical path or area?
+- Should the MDU be pipelined, multi-cycle iterative, or a hybrid?
+- How does the MDU interact with the register file, bypass network, and issue/arbitration logic?
+- What is the right way to handle 64-bit × 64-bit → 128-bit (MULH family) and the W-suffixed 32-bit ops in RV64?
+- What division algorithm handles signed division correctly without an extra correction cycle?
+
+## Background
+
+### RISC-V M-Extension Semantics
+
+FACT: The RISC-V M-extension defines eight base multiplication instructions and eight division/remainder instructions on RV32. On RV64, the W-suffixed variants operate on 32-bit values sign- or zero-extended to 64 bits, and the unsigned W forms (DIVUW, REMUW) must round toward zero. The MULH family returns the upper 64 bits of a 128-bit product.
+
+The M-extension operation summary (RV64 base form):
+- MUL, MULW: low 64/32 bits of product, lower XLEN bits written
+- MULH: signed × signed, upper XLEN bits
+- MULHU: unsigned × unsigned, upper XLEN bits
+- MULHSU: signed × unsigned, upper XLEN bits
+- DIV/DIVU, DIVW/DIVUW: signed/unsigned quotient, round-to-zero semantics
+- REM/REMU, REMW/REMUW: signed/unsigned remainder, sign follows the dividend (not the divisor), defined such that `d = (d / q) * q + (d % q)`
+
+### Why the MDU Matters
+
+ASSUMPTION: Most non-trivial programs perform at least some integer multiplications. Division is rarer but has high latency penalties when it stalls the pipeline. SPEC CPU integer and most server workloads have a small but non-negligible fraction of MUL/DIV (typically a few percent of dynamic instructions, with division being one to two orders of magnitude less frequent than multiplication).
+
+### Latency Classes
+
+The MDU typically has two distinct latency classes:
+- Multiply: low latency (1–4 cycles) for low-half, higher (3–5) for high-half MULH
+- Divide: long latency (4–35+ cycles depending on radix, operands, and whether signed/unsigned)
+
+This bimodal latency profile is a key design driver: it dictates issue logic complexity, scoreboard behavior, and how the unit is replicated.
+
+## Existing Approaches
+
+### Multipliers
+
+1. **Array multiplier (basic)**
+   - Carry-save array of full adders. Critical path O(n) full-adder delays.
+   - PROPOSAL: low-frequency, area-tolerant baseline.
+   - DISADVANTAGE: poor performance at high frequency; high energy per op.
+
+2. **Wallace tree**
+   - Counter-tree reduction of partial products; final carry-propagate adder (CPA) for the final sum.
+   - ADVANTAGE: logarithmic depth (O(log n)).
+   - DISADVANTAGE: irregular layout, complex routing, harder to verify.
+
+3. **Dadda tree**
+   - Variant of Wallace; reduces the number of longer counters. Slightly fewer gates than Wallace for the same delay in some implementations.
+
+4. **Booth-encoded array / tree multiplier**
+   - Radix-4 (or higher) Booth recoding halves (or quarters) the number of partial products.
+   - For 64-bit operands, radix-4 Booth yields 32 partial products; radix-8 yields ~22.
+   - Reduces tree height, area, and dynamic capacitance at the cost of Booth-encoder logic and signed-correction terms.
+
+5. **Carry-save multiplier with final CPA**
+   - Keeps internal representation in carry-save form; one CPA at the end.
+   - Common in pipelined designs.
+
+6. **Iterative shift-and-add multiplier**
+   - One cycle per bit of operand. Very small area, very long latency.
+   - Inappropriate for any high-performance core; may be acceptable in tiny embedded cores.
+
+7. **Pipelined multiplier**
+   - Multiple pipeline stages; one multiplication initiated per cycle after fill.
+   - Throughput = 1/cycle, but latency grows.
+   - Interacts with main pipeline depth: should typically be 1–3 cycles for a 64-bit multiplier at typical embedded-class frequencies, or 2–4 cycles for high-frequency designs.
+
+### Dividers
+
+1. **Subtract-and-shift (radix-2 restoring)**
+   - One bit of quotient per cycle; ~32 or 64 cycles for 32/64-bit division.
+   - Tiny area; very long latency.
+
+2. **Radix-2 non-restoring**
+   - One bit per cycle; constant-time datapath; needs a final correction step for sign and remainder.
+   - Marginally smaller than restoring; same throughput.
+
+3. **SRT radix-4**
+   - Two quotient bits per cycle; ~16/32 cycles for 32/64-bit.
+   - Lookup table of redundant quotient digits; more complex than radix-2.
+   - Common in high-performance cores (e.g., as discussed in Hennessy & Patterson).
+
+4. **SRT radix-8 / radix-16**
+   - 3–4 bits per cycle; ~8–17 cycles for 64-bit.
+   - Larger tables; more area; more difficult to verify.
+   - Used in some superscalar/OoO cores.
+
+5. **Newton–Raphson reciprocal + multiply**
+   - Iteratively refine reciprocal, then one final multiply. Fast (5–8 cycles for 64-bit).
+   - High area (table lookup, multiplier reused for the final multiply). Better for OoO cores that already have a fast multiplier.
+
+6. **Goldschmidt division**
+   - Similar to Newton–Raphson; uses multiplication by precomputed factors. Same trade-off.
+
+7. **Combined multiply/divide (e.g., shared CSA tree)**
+   - Reuse the multiplier hardware as the divider datapath. Common in modern cores; saves area at the cost of tying two units' schedules together.
+
+8. **Pipelined iterative divider**
+   - Pipelined SRT or radix-N; divides one operand every cycle after fill. Latency is the depth, throughput is 1/cycle. Best for high-throughput OoO cores.
+
+### Multiply–Accumulate
+
+ASSUMPTION: Some cores fuse MUL+MULH or MUL+ADD into a MAC operation. RISC-V does not define such an instruction in the base ISA, but vendor extensions or a custom XH-1 extension could. Not in scope of base MDU.
+
+## Alternative Designs
+
+For each XH-1 core, the MDU is a candidate for one of the following microarchitectural envelopes:
+
+### Option A: Iterative Radix-2 Combined MDU
+- Multiplier: 1 cycle per bit (~32 cycles for MUL, 64 for MULH).
+- Divider: 1 bit per cycle, 32/64 cycles.
+- One shared CSA datapath.
+- Very small area; no pipelining.
+- Latency dominates; not viable for a 128-core design where even moderate per-core performance matters.
+
+### Option B: Single-Cycle Radix-4 Booth × Array, Multi-Cycle Iterative Divider
+- Multiplier: 64×64→128 in 1–2 cycles, low half in 1 cycle.
+- Divider: radix-2 non-restoring, 1 bit/cycle, 32/64 cycles.
+- Moderate area; multiplier is the long-path concern; divider is area-cheap.
+- Reasonable for embedded-class frequencies.
+
+### Option C: Pipelined Radix-4/8 Booth Tree, Pipelined Radix-4 SRT Divider
+- Multiplier: 2–4 pipeline stages, 1 multiply per cycle after fill.
+- Divider: pipelined SRT radix-4, 1 division per ~8–10 cycles.
+- Larger area; better throughput; more ports on the register file, more bypass paths.
+- Fits OoO or wide-issue cores.
+
+### Option D: Pipelined Radix-8 Multiplier, Newton–Raphson Divider
+- Multiplier: 2–3 stage radix-8 Booth.
+- Divider: table-init + 2 NR iterations + 1 final multiply.
+- Best division latency; highest area; requires sharing the multiplier between divide and multiply paths.
+
+### Option E: Configurable Radix (low-power mode)
+- Optional: throttle divider radix to save power in low-utilization scenarios.
+- Not standard in commercial cores; adds verification burden.
+
+## Comparison
+
+Comparison axes (per core, qualitative; quantitative figures are estimates without a fixed PDK/target):
+
+| Option | Mul latency | Mul throughput | Div latency (64-bit, uns) | Area (rel.) | Power (rel.) | Complexity | Verif. burden |
+|--------|-------------|----------------|----------------------------|-------------|--------------|------------|---------------|
+| A: Radix-2 iterative | ~64 cyc | 1/64 cyc | ~64 cyc | Very low | Very low | Low | Low |
+| B: Radix-4 array + radix-2 div | 1–2 cyc | 1/1–2 cyc | ~64 cyc | Moderate | Moderate | Moderate | Moderate |
+| C: Pipelined Booth + SRT-4 | 2–4 cyc | 1/cyc | ~16 cyc | High | High | High | High |
+| D: Radix-8 + NR divider | 2–3 cyc | 1/cyc | ~5–8 cyc | Highest | Highest | Highest | Highest |
+| E: Configurable | (variable) | (variable) | (variable) | High+ | High+ | Highest | Highest |
+
+PROPOSAL: For an unknown baseline, Option B and Option C are the most defensible starting points. Option A is appropriate only for an explicitly area-constrained embedded profile. Option D is appropriate only if the core is OoO with high issue width and division latency is on the critical performance path.
+
+## Advantages
+
+- **Option A**: smallest area, easiest to verify, lowest power per core. Good for area-bound 128-core dies.
+- **Option B**: balanced; multiplier is fast enough to be single-issue in most pipelines; divider is the weak link but small.
+- **Option C**: high throughput on both mul and div; aligned with OoO or wide superscalar cores.
+- **Option D**: lowest division latency; NR is a well-understood algorithm.
+
+## Disadvantages
+
+- **Option A**: division latency will dominate any long-latency operation count; FMA-heavy or hash-heavy code stalls. For 128 cores replicated, the per-core penalty multiplies.
+- **Option B**: divider stalls the issue logic for tens of cycles; reservation stations/scoreboards must hold operands; the issue queue depth must absorb this.
+- **Option C**: register file pressure: pipelined iterative divider may want to read 64-bit operands once and write 64-bit result later, but it must also accept new operands. The issue/arbitration logic must prevent structural hazards on the divider.
+- **Option D**: NR requires an initial reciprocal table (1–2 KB) per core, replicated 128 times = 128–256 KB total for the table. Significant area at large scale. Must be carefully designed for low static power.
+
+## XH-1 Considerations
+
+Without confirmed XH-1 core order (in-order vs out-of-order), pipeline depth, or frequency target, the following sub-recommendations apply:
+
+ASSUMPTION: XH-1 targets a balanced general-purpose or server-class workload, not a microcontroller class. A 128-core die implies a focus on throughput, not single-thread peak.
+
+If XH-1 is in-order (per core):
+- A long-latency divider stalls the pipeline for the entire division. Either the core must have deep OOO machinery at the issue stage, or division latency must be bounded.
+- Option B (multi-cycle iterative divider) is more realistic than C/D.
+- MULH latency matters: if it is 1–2 cycles, the bypass network from MDU to ALU must include a fast path. If 3+ cycles, a one-cycle bubble is acceptable in a shallow in-order pipeline.
+
+If XH-1 is out-of-order:
+- Division latency can be hidden by speculation if the divisor is known early.
+- Option C or D is more attractive; the cost of the long-latency unit is amortized by IPC.
+- Issue queue must handle the unit's variable latency.
+
+PROPOSAL: Until core order is fixed, design the MDU to be **modular**: a radix-4 Booth multiplier (low half in 1 cycle, full 64×64 in 2 cycles) shared with a radix-2 non-restoring divider, with the divider exposed as a single multi-cycle functional unit. This is consistent with Option B and is incrementally upgradeable to Option C if a pipelined divider is added later.
+
+## 128-Core Scalability
+
+Each MDU is replicated 128 times. Scalability concerns:
+
+- **Area**: The MDU is one of the larger non-frontend units. If the multiplier alone is ~0.05–0.15 mm² and the divider ~0.02–0.05 mm² at a modern node (estimate; depends on process and frequency), 128× MDU area is 9–25 mm² total (estimate). This is significant but not dominant compared to caches/interconnect.
+- **Power**: Multipliers and especially SRT dividers are dynamic-power-heavy during computation. With 128 cores potentially issuing MUL/DIV, peak power in the MDU array may be a non-trivial slice of the die's power budget (INSUFFICIENT EVIDENCE for a precise fraction).
+- **Clock distribution**: A long combinational path through a tree multiplier is a clock-tree risk. A pipelined multiplier breaks the path but adds register area and clock load.
+- **Verification**: 128 identical units are verified in parallel; this is favorable. The MDU verification focus should be on **mathematical correctness** of division (signed, round-to-zero, edge cases) rather than replication.
+- **Yield**: A defect in the MDU logic is replicated 128×, so its fault coverage must be very high. Recommend formal verification of the divider's quotient/remainder invariants.
+
+PROPOSAL: Keep the MDU small and well-isolated. Do not let it become the critical path that dictates the global clock period. If the only way to meet timing is to pipeline the multiplier, do so; the cost is one cycle of latency and one extra write port on the integer register file.
+
+## Performance Considerations
+
+- **MUL throughput**: At 1 multiply/cycle per core (pipelined), 128 cores can issue up to 128 multiplies per cycle across the die. Aggregate multiply bandwidth is high; the more pressing concern is per-core latency hiding.
+- **MULH throughput**: MULH uses a 64×64→128 multiplier. On RV64, a 128-bit result requires either a wider datapath or two cycle reuse of a 64-bit multiplier. The former doubles MDU area; the latter doubles MULH latency. PROPOSAL: prefer a true 64×64→128 datapath (single cycle) since the alternative doubles register-file read pressure.
+- **DIV throughput**: 1 per 16 cycles (SRT-4) or 1 per 64 cycles (radix-2) per core. Across 128 cores, average DIV throughput is high in aggregate but per-thread latency is the user-visible metric.
+- **MUL–MULH coupling**: A common implementation is to compute the full 128-bit product once, then take either low or high half. This is a clean reuse strategy.
+- **DIV–REM coupling**: In non-restoring or SRT, quotient and remainder come out together. The MDU can expose both at the same latency. RISC-V requires both with consistent semantics.
+- **W-suffixed ops in RV64**: Operands are sign- or zero-extended from 32 to 64. The MDU can simply perform 64-bit ops with the upper 32 bits forced to zero/sign-extended. No special hardware is needed if the register file read provides the correct extension (which the standard RF does on RISC-V).
+
+## Area Considerations
+
+Estimated relative area, normalized to a baseline radix-2 iterative combined MDU (very rough, no PDK):
+
+| Design | Relative area (rough) |
+|--------|------------------------|
+| Radix-2 iterative (A) | 1.0× |
+| Radix-4 array + radix-2 div (B) | ~3–5× |
+| Pipelined radix-4 + SRT-4 (C) | ~6–10× |
+| Radix-8 + NR divider (D) | ~8–12× |
+
+These are estimates. Actual area depends heavily on:
+- Multiplier radix and Booth encoding depth
+- Whether CSA is retained to the final CPA
+- Divider's choice of redundant representation and on-the-fly quotient conversion
+- Pipeline register count
+- Whether a 64×64→128 result is held in a single 128-bit register or two 64-bit latches
+
+PROPOSAL: For a 128-core design, choose the smallest MDU that meets per-core latency targets. Area scaling is multiplicative across cores; a 10× MDU is 10× cost across the die.
+
+## Power and Energy Considerations
+
+- **Static power**: A large MDU (Option C/D) has more leakage. Across 128 cores, leakage adds up. Clock-gating the MDU when no MUL/DIV is in flight is essentially mandatory; consider also input-gating operand muxes to prevent toggling.
+- **Dynamic power**: A pipelined multiplier toggles every cycle when active. A non-pipelined iterative multiplier toggles only during active cycles but for longer. Per-operation energy is generally lower for the non-pipelined option at low utilization.
+- **NR divider**: The initial reciprocal table lookups can be gated; iteration multiplies are power-hungry but brief.
+- **Energy per op**: For low-utilization workloads, smaller/iterative MDUs are more energy-efficient per operation. For high-utilization workloads, pipelined MDUs amortize the per-op energy.
+
+INSUFFICIENT EVIDENCE to recommend a specific energy target without workload mix and frequency data.
+
+## Implementation Considerations
+
+- **Operand alignment**: The MDU takes two XLEN-bit operands and produces either XLEN or 2*XLEN bits. The result muxes must be carefully timed; the 128-bit result for MULH is on the critical path to the register file write port.
+- **Bypass network**: MUL result must be bypassable to dependent operations. MUL→ADD, MUL→MUL, MUL→branch (for select-on-result patterns) all need bypass paths.
+- **Scoreboard / wakeup**: In an OoO core, the MDU must signal completion to wake up dependent instructions. Variable latency (mul vs div) requires tagged completion events.
+- **Flush behavior**: On branch mispredict or exception, in-flight MDU operations must be killed. Pipelined iterative units must be safely drainable.
+- **Special values**: DIV/REM with divisor=0 raises a divide-by-zero exception; the quotient register is written with -1 (signed) or 2^XLEN-1 (unsigned), remainder with the dividend. The MDU must produce these values even on the exception path. The simplest implementation: detect divisor=0, force the result muxes, raise the exception flag.
+- **Overflow**: Signed DIV/REM is defined to overflow when the dividend is -2^(XLEN-1) and the divisor is -1; quotient is -2^(XLEN-1), remainder is 0. This is a known corner case.
+- **Sign handling for non-restoring/SRT**: The quotient bits come out in a redundant form; the on-the-fly conversion (or final correction) must apply the sign correction. This is a well-known source of bugs.
+- **W-suffixed ops**: The result of MULW is the low 32 bits sign-extended to 64. The MDU can compute the full 64-bit product and just route the low 32 bits with sign-extension, or compute a 32×32→64 product. The former is simpler and reuses the 64-bit datapath; recommended.
+
+## Verification Considerations
+
+- **Mathematical correctness**: Division is a top source of MDU bugs across the industry. Strongly recommend:
+  - Random testing with a slow software reference (e.g., a software DIV routine) across the full input space, including all corner cases: 0 divisor, -1 divisor, INT_MIN dividend, INT_MIN/INT_MIN, INT_MIN/-1, alternating bit patterns.
+  - Formal verification of quotient/remainder invariants (`q*d + r == n` and `|r| < |d|` and sign-of-r-follows-n).
+- **Self-consistency**: For every (a, b), the MDU must satisfy `MDU_DIV(a, b) * b + MDU_REM(a, b) == a` (with sign handling).
+- **MULH/MUL consistency**: For signed × signed, `MULHSU(a, b)` and `MULHU(|a|, b)` (with sign correction) must agree.
+- **W-op consistency**: DIVW(a, b) should equal sign-extend32(DIV(sign-extend32(a), sign-extend32(b))). Random differential testing.
+- **Coverage**: Target 100% code and toggle coverage on the MDU; FSM coverage on the divider state machine.
+- **Cross-core**: A defect in the MDU RTL hits 128 instances. The verification cost is paid once but the fault-coverage target must be high.
+- **Latency timing**: Verify the latency contract (1/2/N cycles) at the interface level so that downstream issue/retire logic is correct.
+
+## Software Considerations
+
+- **Compiler**: GCC/LLVM emit MUL/DIV/REM for the corresponding C operators. Idiomatic C rarely exposes division; the issue is more around hash functions, big-integer arithmetic, and base conversions.
+- **Libraries**: libgcc / compiler-rt provide software fallbacks for division if the hardware path is unavailable. The MDU should match the ABI (M-extension) expectations; otherwise the OS or runtime must emulate.
+- **Constant division**: A compiler strength-reduction pass converts division by a power of 2 into a shift. For non-power-of-2 constants, some compilers (e.g., GCC) can emit a multiply-by-reciprocal sequence if the hardware division is too slow. This affects what hardware division latency is "good enough".
+- **Builtins**: __builtin_mul_overflow etc. on GCC/Clang map to MUL/branch sequences. Performance of these depends on MDU latency.
+- **OS context switch**: MDU has no architectural state; context switch does not interact with the MDU.
+- **Vector / SIMD**: RISC-V V-extension is out of scope unless XH-1 adopts it. If V is added later, the MDU does not change but vector multiply-accumulate units (independent hardware) will.
+
+## Recommendation
+
+PROPOSAL: Adopt a design in the **Option B** family for the initial XH-1 MDU:
+- **Multiplier**: 64×64→128-bit radix-4 Booth-encoded CSA tree, single-cycle low-half result, two-cycle high-half (MULH) result, both written to the register file in 2 cycles total. The CSA tree is followed by a final CPA. 64×64 partial product count is 32 (radix-4), manageable for a single combinational stage at moderate frequency. If the critical path is too long for the target clock, add a single pipeline register between CSA tree and CPA; this becomes Option C-lite.
+- **Divider**: Radix-2 non-restoring, 64 cycles for RV64 / 32 cycles for RV32 / 32 cycles for W-ops. Constant-time datapath; quotient and remainder produced in the same iteration. Final sign-correction and round-to-zero applied in the last cycle.
+- **Shared datapath**: The CSA tree and partial-product reduction are reused where possible. The divider is otherwise independent of the multiplier to keep verification simple.
+- **Latency contract**: MUL/MULW = 1 cycle; MULH family = 2 cycles; DIV/DIVU/REM/REMU and W-suffixed variants = N+1 cycles (where N is operand width) plus a final correction cycle, ≈ 33/65 cycles for RV32/RV64. The scoreboard/issue logic is designed against these numbers.
+- **Special-case handling**: DIV/REM by 0 and overflow paths produce architecturally defined result values and raise exceptions. The MDU has a small input-gate to zero-out internal state when the operation completes early on a trap.
+
+This recommendation is provisional and is conditional on:
+- Confirmation of the core order (in-order vs out-of-order). For OoO, re-evaluate toward Option C.
+- Confirmation of the target frequency. If a higher frequency is set, the multiplier may need to be pipelined.
+- Confirmation of the area budget. If the budget is tight, fall back toward Option A's divider.
+
+## Confidence
+
+- **High confidence**: The M-extension semantics, the standard algorithms (radix-2 non-restoring, radix-4 Booth, SRT-4), the corner cases (div by 0, INT_MIN/-1, sign of remainder), the general area/latency trade-off directions.
+- **Medium confidence**: The relative-area and relative-power tables; they are estimates and depend on the unknown PDK and frequency.
+- **Low confidence**: Any specific cycle-count or area number for XH-1; no XH-1 measurements are available.
+- **Very low confidence**: Recommendations about pipelined vs non-pipelined without knowing core order and frequency.
+
+## Open Questions
+
+1. Is the XH-1 core in-order or out-of-order? (Foundational; drives all MDU trade-offs.)
+2. What is the target pipeline depth and clock frequency? (Drives multiplier pipelining decision.)
+3. Is the XH-1 ISA RV32 or RV64, and which extensions are ratified?
+4. What is the per-core area budget for execution units (ALU + MDU + branch + LSU)?
+5. What is the target workload mix? (Division-heavy workloads change the divider trade-off.)
+6. Is there a custom XH-1 extension that would change the MDU's responsibilities (e.g., a fused MAC)?
+7. Does XH-1 adopt the V-extension? (If yes, the scalar MDU stays as is, but a vector MAC unit is needed separately.)
+8. What is the static-power budget at the target process node? (Affects whether large array multipliers are acceptable.)
+9. Is the MDU expected to be fault-tolerant or SECDED-protected? (Affects pipeline register design.)
+10. Does the issue/arbitration logic treat the MDU as a single multi-cycle unit, or as separate mul and div functional units? (Affects which microarchitecture is compatible with the rest of the core.)
+
+## Sources
+
+INSUFFICIENT EVIDENCE for XH-1-specific sources; the design space and algorithms referenced here are textbook material:
+
+- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (general sections on multiplier/divider design; editions vary; no specific edition cited here).
+- RISC-V *Unprivileged ISA Specification* (M-extension semantics, division corner cases, W-suffixed ops on RV64). Publicly available at riscv.org; specific version numbers and page references are not cited here.
+- Standard references on SRT division and Booth recoding are not cited specifically; the algorithms are well-known.
+
+No XH-1 measurements, no third-party benchmarks, and no external papers are cited because none are available in the repository context. Any quantitative claim in this document is an estimate and should be re-derived when the XH-1 baseline parameters are fixed.