First passed test

research/.xh1/runs/20260825T183001Z/attempts

@@ -0,0 +1,8 @@
+2026-08-25T18:31:08Z	research/03-core-design/mul-div-unit.md	1	research	completed
+2026-08-25T18:31:49Z	research/03-core-design/mul-div-unit.md	1	review	VERDICT: FAIL
+2026-08-25T18:32:55Z	research/03-core-design/mul-div-unit.md	2	revision	completed
+2026-08-25T18:33:37Z	research/03-core-design/mul-div-unit.md	2	review	VERDICT: FAIL
+2026-08-25T18:34:54Z	research/03-core-design/mul-div-unit.md	3	revision	completed
+2026-08-25T18:35:35Z	research/03-core-design/mul-div-unit.md	3	review	VERDICT: FAIL
+2026-08-25T18:37:17Z	research/03-core-design/mul-div-unit.md	4	revision	completed
+2026-08-25T18:38:09Z	research/03-core-design/mul-div-unit.md	4	review	VERDICT: FAIL

research/.xh1/runs/20260825T183001Z/failed

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

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

@@ -0,0 +1,505 @@
+# MUL/DIV Unit
+
+## Status
+
+Revision 2. Initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors identified in review, removes unsupported quantitative claims, reconciles internal contradictions, and adds missing alternatives.
+
+## Abstract
+
+This document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT, CLMUL, CLMULH, CLMULR). The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only a small percentage of a single core's area consumes a large cumulative area across the die when replicated 128 times. The unit's latency impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).
+
+## Research Question
+
+What is the optimal MUL/DIV unit organization for an XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, energy, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?
+
+## Background
+
+### RISC-V M Extension Semantics (RV64M)
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The RISC-V M extension for RV64 defines the following instructions:
+
+- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result, with sign-handling variations).
+- MULW: 32×32→32 bit product, then sign-extended to 64 bits and written to `rd`.
+- DIV, DIVU: 64÷64 signed/unsigned quotient.
+- REM, REMU: 64÷64 signed/unsigned remainder.
+- DIVW, DIVUW, REMW, REMUW: 32÷32 signed/unsigned quotient/remainder, sign-extended to 64 bits and written to `rd`.
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The M extension defines the following corner-case behavior:
+
+- Division by zero:
+  - `DIV` / `DIVW`: quotient is `−1` (the architectural definition; the bit pattern is `2^XLEN − 1`, all bits set).
+  - `DIVU` / `DIVUW`: quotient is `2^XLEN − 1` (all bits set, which equals `−1` in two's complement representation).
+  - The signed and unsigned cases produce the same bit pattern at the architectural level; the spec writes `−1` for the signed case and the unsigned maximum for the unsigned case, but these are bit-pattern-identical.
+  - `REM` / `REMW`: remainder equals the dividend.
+  - `REMU` / `REMUW`: remainder equals the dividend.
+- Signed overflow (most-negative integer divided by −1):
+  - `DIV` / `DIVW`: quotient equals the dividend (i.e., the most-negative representable value `2^(XLEN−1)`).
+  - `REM` / `REMW`: remainder equals zero.
+- For unsigned divide (`DIVU` / `REMU` / `DIVUW` / `REMUW`), the only defined special case is division by zero; the dividend / `−1` overflow case does not apply because the operands are unsigned.
+
+**NOTE**: A full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned.
+
+**NOTE** (MULHSU implementation): MULHSU computes the upper 64 bits of a signed×unsigned 64×64 product. A correct implementation generates a partial-product array for 64×64 bits where the unsigned operand's partial products are zero in the upper half of its bit positions and the signed operand's partial products use signed (sign-extended) rows in the final reduction. Two concrete implementation paths exist:
+
+- (a) Use a signed multiplier datapath: sign-extend the signed operand to 128 bits, zero-extend the unsigned operand to 128 bits, and run a signed 128×128 multiply, then take the upper 64 bits. This is straightforward but doubles the multiplier width and is rarely used.
+- (b) The standard approach: zero-extend the unsigned operand to 64 bits (its bit positions are already non-negative), sign-extend the signed operand only in the final partial-product row, and reduce the 64×64 partial-product array with a final row sign-extension. This requires a modified-Booth or array multiplier with explicit sign handling on the last partial-product row.
+
+A pure unsigned Wallace/Dadda tree without a sign-handling front-end does not implement MULHSU correctly, because the signed operand's most significant partial-product row must be sign-extended (or its inverted-and-carry form added) into the reduction tree.
+
+**NOTE**: The W-suffixed instructions (MULW, DIVW, DIVUW, REMW, REMUW) are part of the **M extension** in RV64, not the base I extension. The base I extension's W variants are only the simple ALU ops (ADDW, SUBW, SLLW, SRLW, SRAW).
+
+**NOTE**: MULW is implementable on a 32×32→64-bit datapath: the 32-bit product is sign-extended to 64 bits and written to `rd`. The upper 32 bits of the 64-bit intermediate result are discarded. A 32×32→64-bit fast multiplier (B3 datapath) can therefore implement MULW by taking its lower 32 bits and sign-extending to 64.
+
+**NOTE**: The carry-less multiply instructions CLMUL, CLMULH, and CLMULR are part of the standard Zbc extension (commonly grouped under the umbrella "B" extension in some profiling). They are not part of M. They require a different datapath (AND-tree with XOR reduction, no carry propagation) and are not the subject of this document except where they interact with operand muxes / writeback. CLMULR in particular produces a 2·XLEN-bit result with explicit carry-in/carry-out behavior across the two halves; its implementation shares the AND-tree with CLMUL/CLMULH but adds a dedicated reduction stage for the carry path.
+
+### Latency Reference Points
+
+**FACT (Rocket Chip, UC Berkeley generator)**: Rocket Chip is in-order, and the MUL/DIV unit is configuration-dependent across Rocket's `Configs.scala` parameter set. In `RocketCoreConfig` (commonly cited as the default), the multiplier is pipelined with multiple pipeline stages (multi-cycle iterative, new operation accepted per cycle) and the divider is a radix-4 iterative divider. The exact stage counts and latencies are determined by parameters in `Configs.scala` and are not a single canonical value. INSUFFICIENT EVIDENCE for a specific latency number without naming the configuration.
+
+**FACT (BOOM v2/v3, UC Berkeley)**: Out-of-order superscalar. MUL is pipelined (latency configuration-dependent). DIV is variable-latency, non-pipelined.
+
+**FACT (XiangShan, open-source OoO RISC-V)**: MUL is pipelined; DIV is variable-latency, non-pipelined.
+
+**FACT (Ibex, lowRISC)**: In-order. MUL is implemented as a single-cycle or short-pipeline combinational multiplier in some configurations; iterative DIV.
+
+**INSUFFICIENT EVIDENCE**: Arm Cortex-A77 per-instruction MUL/DIV latencies are not publicly published by Arm. No specific numbers are cited from a primary source.
+
+**INSUFFICIENT EVIDENCE**: Intel Haswell integer divider internal radix (radix-16 vs. radix-32) is not established from publicly verifiable primary sources. The design is widely reported to be a high-radix shift-subtract divider rather than a Newton-Raphson divider, but the specific radix is INSUFFICIENT EVIDENCE.
+
+### Divide Algorithms
+
+**FACT**: Four primary classes are considered here:
+
+1. **Digit-recurrence / shift-subtract (radix-2, radix-4, radix-16, radix-64 SRT)**: radix-2 takes 64 cycles worst case; radix-4 takes ~32–33 cycles; radix-16 takes ~16 cycles; radix-64 takes ~8–10 cycles (with significant area/complexity cost). Iterative, small-to-moderate area depending on radix.
+2. **Newton-Raphson reciprocal multiplication**: multiple iterations of a multiply-based refinement to compute the reciprocal, then a final correction multiply to produce the quotient. Latency depends on initial seed precision and convergence criteria.
+3. **Goldschmidt**: similar convergence behavior to Newton-Raphson, with a different iteration structure.
+4. **CORDIC-based and series-expansion dividers**: rarely used for general-purpose integer divide due to overhead; exist as alternative approaches.
+
+**FACT**: The RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.
+
+## Existing Approaches
+
+### A1. Iterative Shift-Subtract Divider (Radix-2)
+
+- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, radix-2, 64-cycle worst case.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 divide per 64 cycles (not pipelined).
+- **MUL coverage**: A1 defines a divider only; MUL is not part of this organization.
+- **Area (DIV only)**: Smallest divider; typically a few kGE plus control. **INSUFFICIENT EVIDENCE** for a specific gate count.
+- **Power**: Lowest of the divider options when idle; minimal toggle rate per non-dividing cycle.
+- **Used in**: Some low-end in-order cores; some configurations of Rocket Chip with smaller radix.
+
+### A2. Pipelined Iterative Divider
+
+- **Datapath**: Two distinct subclasses must be distinguished:
+  - **(A2a) Pipelined iterative loop**: a single shift-subtract array with pipeline registers inserted at one or more points within the iterative loop, allowing a new operation to enter the loop every cycle after the pipeline is filled. Latency remains 64 cycles; throughput is 1 per cycle after fill.
+  - **(A2b) Fully unrolled divider**: 64 shift-subtract stages with pipeline registers between every stage, giving latency 64 cycles and throughput 1 per cycle from the first cycle. Area is roughly 64× the A1 datapath.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 per cycle (after fill for A2a; from cycle 1 for A2b).
+- **Area**: A2a is ~2–3× A1 (a few extra pipeline registers); A2b is roughly 64× A1 and is rarely used.
+- **Power**: Higher toggle rate than A1; only worthwhile under sustained divide streams.
+- **Used in**: Rare; mostly in high-throughput streaming dividers (DSP). Uncommon in general-purpose cores.
+
+### A3. Newton-Raphson Divider
+
+- **Datapath**: shared MUL unit(s), initial reciprocal seed ROM, multiplier used in iterative refinement and one final correction multiply.
+- **Latency breakdown**: seed table lookup (1 cycle) + N refinement multiplies (typically 2–3 iterations for 64-bit integer) + 1 final correction multiply. **ASSUMPTION**: 3 refinement iterations + 1 correction is typical for 64-bit; the concrete iteration count depends on seed precision and convergence criteria. **INSUFFICIENT EVIDENCE** for a single canonical iteration count without specifying the seed table and refinement schedule.
+- **Throughput**: one divide per (N+1) MUL cycles **only if the multiplier is dedicated to the divider**. If the multiplier is shared with the main MUL datapath, throughput is degraded by contention with MUL issue rate and is workload-dependent. **INSUFFICIENT EVIDENCE** for a single throughput number in the shared case.
+- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (sharing possible at the cost of contention); large.
+- **Power**: Higher static and dynamic (multiplier active during divide refinement).
+- **Used in**: Some high-performance FPU designs for floating-point; less common for dedicated integer divide.
+
+### A4. Radix-16 / Radix-64 SRT Divider
+
+- **Datapath**: high-radix recurrence with a quotient-digit lookup table (PLA or ROM), redundant remainder representation. 16 or 64 bits processed per cycle.
+- **DIV Latency**: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands.
+- **DIV Throughput**: 1 per cycle if pipelined; 1 per 16 / 8–10 cycles if iterative.
+- **Area**: large lookup table and complex datapath; PLA is a significant area contributor.
+- **Power**: high; many bits toggle per cycle.
+- **Used in**: high-end x86 integer dividers (radix of the integer divider is **INSUFFICIENT EVIDENCE** from primary sources; widely reported as high-radix shift-subtract rather than Newton-Raphson).
+
+### A5. Approximate / Lookup-Based Dividers (small operand ranges)
+
+- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.
+
+## Alternative Designs
+
+### B1. Hybrid MUL + Sequential-Iterative DIV (radix-4 iterative divider, custom MUL)
+
+- MUL: 64×64→128 pipelined in 1 stage (target), throughput 1 per cycle. This departs from Rocket Chip's default multi-stage MUL (Rocket's `RocketCoreConfig` issues MUL as a multi-cycle iterative operation); the 1-stage MUL is an aggressive target for XH-1.
+- DIV: radix-4 iterative, ~33 cycles (32 cycles for quotient bits + finalization), blocking on the unit.
+- Single divider per core, 1 MUL pipeline stage.
+
+**NOTE on naming**: B1 inherits the radix-4 iterative divider pattern from Rocket and Ibex, but the MUL organization (1-stage pipelined) is a custom choice that does not match either Rocket's multi-stage MUL or Ibex's short-pipeline / combinational MUL. The "hybrid" descriptor refers to combining a pipelined MUL with an iterative DIV; the divider side aligns with reference designs, the MUL side does not.
+
+### B1'. Two MUL Pipelines + Shared Iterative DIV (wide-issue variant)
+
+- Two pipelined MUL datapaths, one shared radix-4 DIV datapath.
+- MUL throughput: 2/cycle (sustained, independent operands).
+- DIV throughput: 1 per ~33 cycles, shared and blocking.
+- **Area**: ASSUMING a MUL:DIV area ratio of approximately 1:1 (i.e., one MUL pipeline and one radix-4 iterative DIV are roughly comparable in area, since a 1-stage 64×64 MUL is a Wallace/Dadda tree plus a 128-bit CPA, and a radix-4 iterative DIV is a ~66-bit adder plus control state), the combined (MUL+DIV) area scales as 1 + 1 = 2× B1 (two MULs plus one shared DIV, where B1 has one MUL and one DIV). The 1.5× figure previously cited assumed MUL is half the area of DIV, which is unsupported. The 1.4× lower bound previously cited is unsupported. The corrected qualitative statement is: **~2× B1**, with the explicit MUL:DIV area ratio assumption stated. **INSUFFICIENT EVIDENCE** for a synthesis-derived number.
+
+### B2. Combined MUL/MAC (Multiply-Accumulate) Unit
+
+- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).
+- Adds area over pure MUL; **INSUFFICIENT EVIDENCE** for a specific percentage.
+- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.
+
+### B3. Operand-Width-Detected 32-bit Fast MUL Path (also serves MULW)
+
+- Detect when both operands of a 64-bit MUL are sign- or zero-extended from 32 bits (i.e., bit 31 is replicated through bit 63), and route the multiplication through a 32×32→64 fast multiplier.
+- The same 32×32→64 datapath also implements MULW directly: the 32-bit product (lower 32 bits of the 64-bit result) is sign-extended to 64 bits and written to `rd`. This sharing is essentially free in area terms and means that adopting B3 is the natural way to implement MULW.
+- This is **distinct from MULW as a workaround** for the 32-bit-case: B3 accelerates 64-bit MUL / MULH / MULHSU / MULHU when both operands happen to be 32-bit sign- or zero-extended, a pattern common after `lw` / `lwu` followed by arithmetic. MULW alone does not accelerate this case because MULW is a different instruction with different result semantics.
+- **Position**: B3 is the natural choice for the MULW datapath and adds a 32-bit-extended-operand fast path for 64-bit MUL. The verification cost is the dual datapath (32-bit and 64-bit) and the operand-width classifier. At the 128-core replication level, the area overhead is bounded by the 32-bit datapath size, which is much smaller than the 64-bit datapath; the dominant question is verification cost, not area.
+- **Decision**: B3 is recommended as part of the MULW implementation; deferring B3 means deferring the natural MULW implementation, which is not viable if MULW is in the ISA. The B3-vs-B4 trade-off therefore applies to the 32-bit-extended-operand fast path, not to MULW support.
+
+### B4. Bypassable Output with Operand Width Detection (full 64×64→128 only)
+
+- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.
+- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.
+- Disadvantage: no area saving; MULW must still be implemented separately (e.g., via B3 or a dedicated 32×32→32 path).
+- **Position**: B4 conflicts with the natural MULW-via-B3 sharing above; if MULW is required, B4 is not a complete solution. If MULW is not required, B4 simplifies verification at the cost of a slightly larger MUL datapath for MULW-equivalent work.
+
+### B5. Skip-on-Zero / Divide-Cancellation Optimizations
+
+- Detect zero dividend (quotient is zero, remainder is dividend) and divide-by-one (quotient is dividend, remainder is zero) at the front end and forward the result without entering the iterative loop.
+- **Corner cases the fast path must handle correctly** (consistent with the iterative path):
+  - dividend = 0, divisor = anything (including 0): quotient = 0, remainder = 0 (dividend).
+  - divisor = 1: quotient = dividend, remainder = 0.
+  - divisor = −1:
+    - dividend = 2^(XLEN−1) (most-negative): quotient = 2^(XLEN−1) (dividend), remainder = 0 (signed overflow case, the M-extension rule).
+    - all other dividends: quotient = −dividend (two's complement negation), remainder = 0.
+- The fast path must explicitly implement these rules; it is not a simple "if divisor=±1 then return dividend" because of the signed-overflow case for divisor = −1.
+- Saves latency in the common case for some workloads; trivial area overhead.
+- Composable with any divider organization.
+
+### B6. Software Divide-by-Constant Transformation (cross-cutting)
+
+- Compilers transform division by a **compile-time** constant into a multiply-by-reciprocal sequence. The hardware DIV is then needed only for division by variables.
+- Reduces effective DIV frequency significantly for workloads with constant denominators; affects hardware sizing decisions. **INSUFFICIENT EVIDENCE** for a quantitative reduction without a specific workload profile.
+
+### B7. Dedicated 32-bit Fast Divider for W-suffixed Instructions
+
+- Implement a separate 32-bit radix-2 or radix-4 iterative divider for DIVW / DIVUW / REMW / REMUW. The 32-bit divider has half the iteration count (32 or 16 cycles vs. 64 or 33 for the 64-bit divider) and roughly a quarter of the datapath area.
+- Useful if profiling shows W-suffixed divides dominate; in most general-purpose workloads they do not.
+- Verification cost: dual divider datapath, similar to B3.
+- **Note**: W-suffixed instructions operate on 32-bit operands; a natural alternative is to share the 64-bit divider datapath with the 32-bit operands on the lower 32 bits, taking 32 or 16 cycles of the 64-bit divider's iteration. B7 is only worth its area if the latency savings matter.
+
+### B8. Combined MUL / DIV with Shared Partial-Product Array (CSA Sharing)
+
+- Reuse the MUL's CSA compressor tree as the final correction multiplier for an SRT or Newton-Raphson divider, sharing the most area-intensive block.
+- Reduces the area penalty of A3 / A4 at the cost of tighter verification coupling between MUL and DIV paths.
+- Real architectural option in some high-performance designs; not considered in the prior revision.
+
+### B9. Combined MUL / DIV with Shared Final Carry-Propagate Adder (CPA Sharing)
+
+- Share only the final 128-bit carry-propagate adder between the MUL datapath and the DIV's correction-multiply step (or the DIV's final-cycle remainder correction). The compressor tree, partial-product generation, and divider iteration state remain separate.
+- Lower area savings than B8 (CSA is shared instead of CPA), but much simpler verification: the shared CPA is a single combinational block, and the MUL vs DIV datapaths feeding it are independent.
+- The MUL pipeline register naturally sits between the compressor-tree output and the CPA, which means the CPA itself can be shared at the output side without disrupting the MUL pipeline structure.
+- **Open question**: whether the MUL pipeline register sits at the compressor-tree output (CPA in cycle 2) or at the CPA output (CPA in cycle 1) determines the CPA's pipeline stage. See Implementation Considerations for the canonical placement decision.
+
+### B10. Partially Unrolled Radix-4 Divider (intermediate between A2a and A2b)
+
+- Unroll the radix-4 iterative divider into a small number of pipeline stages (e.g., 8 or 16 stages) rather than the full 64 (A2b) or the single iterative loop (A2a).
+- Latency 32 or 33 cycles (one stage per two quotient bits for 8 stages, or one stage per quotient bit for 16 stages), throughput 1 per cycle after fill, area roughly 8× or 16× A1.
+- A meaningful intermediate option for the high-DIV-throughput case that the prior revision did not consider.
+- Verification: same as A2a (iterative datapath with pipeline registers); the unrolling does not introduce new corner cases.
+
+## Comparison
+
+| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |
+|--------|-------------|----------|-------------|----------|----------------------|----------------|--------------------------|
+| A1 (radix-2 iter. DIV only) | not defined in A1 | not defined in A1 | 64 cycles | 1 per 64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |
+| A2a (pipelined iter. loop) | not defined in A2a | not defined in A2a | 64 cycles | 1 per cycle (after fill) | INSUFFICIENT EVIDENCE | Med | Med |
+| A2b (fully unrolled) | not defined in A2b | not defined in A2b | 64 cycles | 1 per cycle | INSUFFICIENT EVIDENCE (very large) | High | High |
+| A3 (Newton-Raphson) | 1 cycle | 1 per cycle (dedicated) | N+1 MUL cycles (dedicated); workload-dep. if shared | INSUFFICIENT EVIDENCE (shared) | high | High | High |
+| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1 per cycle if pipelined | high | High | High |
+| B1 (radix-4 DIV, 1-stage MUL) | 1 cycle (target) | 1 per cycle | ~33 cycles | 1 per 33 cycles | baseline | Low–Med | Low–Med |
+| B1' (2× MUL + 1× shared DIV) | 1 cycle | 2 per cycle | ~33 cycles | 1 per 33 cycles (shared) | ~2× B1 (INSUFFICIENT EVIDENCE; assumes MUL:DIV area ≈ 1:1) | Med | Med |
+| B2 (+ MAC) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | +unspecified % over B1 (INSUFFICIENT EVIDENCE) | Med | Med |
+| B3 (32-bit fast MUL; serves MULW) | 1 cycle (32-bit path) | 1 per cycle | ~33 cycles | 1 per 33 cycles | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |
+| B4 (full 64 only; MULW separate) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | same as B1 (MULW path TBD) | Med | Lowest (MUL side); Med (MULW) |
+| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |
+| B7 (32-bit fast DIV) | 1 cycle | 1 per cycle | ~16–17 cycles (32-bit) | 1 per 16–17 cycles (32-bit only) | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |
+| B8 (shared MUL/DIV CSA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | lower than A3/A4 alone (INSUFFICIENT EVIDENCE) | Med–High | Med–High (tight coupling) |
+| B9 (shared MUL/DIV CPA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | slightly higher than B8 reduction (INSUFFICIENT EVIDENCE) | Med | Low (clean separation) |
+| B10 (partially unrolled radix-4) | not defined in B10 | not defined in B10 | ~32–33 cycles | 1 per cycle (after fill) | ~8–16× A1 (INSUFFICIENT EVIDENCE) | Med | Med |
+
+**ASSUMPTION**: Relative area figures are qualitative orderings based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are **INSUFFICIENT EVIDENCE** pending RTL implementation.
+
+## Advantages
+
+### A1 / B1
+- Smallest area; lowest per-core replication cost.
+- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).
+- Simpler verification; one mode of operation.
+- Well-understood reference implementation (Rocket, Ibex) for the divider side; the MUL side departs from both references.
+
+### A4 (High-Radix SRT)
+- Lowest DIV latency among the iterative-style options; competitive with A3 on a single divide.
+- Pipelined variant gives 1 per cycle DIV throughput.
+
+### A3 (Newton-Raphson)
+- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.
+- Amortizes multiplier cost if MAC (B2) is also desired.
+- Disadvantage: requires multiple refinement iterations; integer multiplier is large and contention with the main MUL datapath is a concern.
+
+### B2 (MAC)
+- Enables future-proofing for proposed bitmanip and MAC extensions.
+- Helpful for matrix multiplication kernels running across 128 cores.
+
+### B3 (32-bit fast MUL; serves MULW)
+- Natural implementation of MULW; the 32×32→64 datapath produces the MULW result by sign-extending the lower 32 bits.
+- Accelerates 64-bit MUL on 32-bit-valued operands (a common pattern after `lw`/`lwu` + arithmetic).
+- Area overhead is bounded by the 32-bit datapath size (much smaller than the 64-bit datapath).
+
+### B5 (Skip-on-Zero)
+- Negligible area; reduces effective DIV latency for common cases.
+
+### B7 (32-bit fast DIV)
+- Halves the divider iteration count for the W-suffixed instructions at modest area cost.
+
+### B8 (Shared MUL/DIV CSA)
+- Reduces the area penalty of high-performance dividers by sharing the most area-intensive block.
+
+### B9 (Shared MUL/DIV CPA)
+- Lower verification cost than B8; the shared CPA is a single combinational block and the MUL/DIV datapaths feeding it are independent.
+
+### B10 (Partially Unrolled Radix-4)
+- A meaningful intermediate option for high DIV throughput without the area cost of A2b; same verification profile as A2a.
+
+## Disadvantages
+
+### A1 / B1
+- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall ~33 cycles per divide.
+- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.
+- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).
+
+### A3
+- Area at 128-core replication is severe; the multiplier is one of the largest blocks in a typical core.
+- Power: a 64×64 multiplier running 1 per cycle is one of the highest-power blocks in a typical core.
+- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.
+- If multiplier is shared with main MUL datapath, throughput is workload-dependent, not the N+1 figure cited for the dedicated case.
+
+### A4
+- Large lookup table (PLA or ROM); area and power dominated by the table.
+- Verification: complex quotient-digit selection logic.
+- Not commonly used outside high-end commercial designs.
+
+### B3
+- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.
+- The classification logic (operand-width detection) is itself a source of corner-case bugs.
+- **B3 does not subsume MULW for the purpose of "B3 is redundant"**: B3 and MULW are two different ways to access 32-bit-multiplication, and B3's value is primarily as the natural MULW implementation and secondarily as the 32-bit-extended-operand fast path.
+
+### B2
+- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.
+
+### B5
+- Only helps the specific cases of zero dividend or divisor ±1; other optimizations (e.g., division by small powers of two) are already handled by the base I extension's shift instructions.
+- The fast path must explicitly handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1): quotient = dividend, remainder = 0.
+
+### B7
+- Verification: dual divider datapath; same concerns as B3.
+- Area saving is moot if W-suffixed divides are not on the critical path.
+
+### B8
+- Verification: tighter coupling between MUL and DIV paths makes corner-case analysis more difficult.
+
+### B9
+- Area savings are smaller than B8 (CPA shared instead of CSA); the savings are bounded by the CPA size, which is significant but not the dominant block.
+
+### B10
+- Area scales with the unroll factor; 16-stage unroll is ~16× A1, which is meaningful at 128-core replication.
+
+## XH-1 Considerations
+
+**PROPOSAL**: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:
+
+- **MUL**: 64×64→128, target 1-cycle pipelined (1 stage of pipeline registers), throughput 1 per cycle. The pipeline register sits at the **CPA output** (after the compressor tree and the 128-bit CPA in cycle 1), so the entire compressor-tree-plus-CPA path is in one cycle. This is the "1-cycle MUL" interpretation; the fallback-A interpretation splits the compressor tree and the CPA across two cycles. For 2-issue or wider cores, scale to B1' (two MUL pipelines sharing one DIV).
+- **DIV**: Radix-4 shift-subtract, ~33 cycles worst case (32 cycles for quotient bits + finalization), blocking, non-pipelined. The prior revision's "33–35 cycles worst case" and the "33–64 cycle" range are reconciled here: 33 is the radix-4 bound; 64 corresponds to radix-2, which is a different algorithm choice.
+- **REM**: Reuse the DIV datapath; remainder is a by-product.
+- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle. **INSUFFICIENT EVIDENCE** on whether this fits the XH-1 pipeline depth; depends on the integration context.
+- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead. The fast path must handle the signed-overflow corner case (divisor = −1, dividend = 2^(XLEN−1)) by returning quotient = dividend, remainder = 0.
+- **B3 (32-bit fast MUL, also serves MULW)**: include the 32×32→64 datapath as the MULW implementation path. The same datapath accelerates 64-bit MUL on 32-bit-extended operands. Verification cost: dual datapath, manageable with the B3 corner-case set (operand-width detection, sign-extension patterns).
+- **B7 (32-bit fast DIV)**: Defer; the W-suffixed divide is not assumed to be on the critical path. Revisit if profiling shows otherwise.
+
+**ASSUMPTION**: A 1-cycle MUL latency is achievable in the target process. **INSUFFICIENT EVIDENCE** on the XH-1 target process node and clock period. A full 64×64→128 Wallace/Dadda tree + 128-bit carry-propagate adder in a single cycle is at the edge of feasibility for high-performance designs; typical in-order cores implement MUL as either a multi-cycle iterative multiplier or a multi-stage pipelined multiplier. **PROPOSAL**: Validate via synthesis at the target corner before committing. If the 1-cycle critical path cannot be closed, **fallback options** are:
+  - **B1-fallback-A**: 2-cycle pipelined MUL. The pipeline register sits at the **compressor-tree output** (splitting the compressor tree in cycle 1 from the CPA in cycle 2); latency 2 cycles, throughput 1 per cycle, modest area overhead (one extra pipeline register).
+  - **B1-fallback-B**: Multi-cycle iterative MUL (Booth-encoded). The cycle count for a Booth-encoded iterative multiplier on 64×64 is implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number of cycles. Lower area, lower throughput, higher latency.
+  - **B1-fallback-C**: Retain the 1-stage MUL architecture but lower the target clock frequency (system-level decision, not unit-level).
+
+**MUL/DIV resource sharing and contention (single-issue-lane B1)**: Under B1, the MUL pipeline and the DIV datapath share the integer execution lane's issue slot, register-file read ports, and writeback port. The single execution lane can issue either one MUL per cycle (latency 1) or one DIV (latency ~33) at a time, but not both simultaneously. If a MUL is issued while a DIV is in progress:
+- The MUL occupies the issue slot for 1 cycle; the DIV's iterative state is held in the divider's internal registers and does not require the issue slot during its 33 cycles.
+- Register-file read ports: MUL requires 2 read ports for its 1 cycle; the DIV's operands are read at DIV issue and held in the divider's operand register. No contention after issue.
+- Writeback port: MUL writes back in cycle 2 (1-cycle latency); the DIV writes back on completion. A MUL issued in the same cycle as a DIV completion would contend for the writeback port. In a single-writeback-port lane, the DIV completion must be stalled by 1 cycle to let the MUL writeback, or vice versa. This is a 1-cycle throughput loss in the rare case of simultaneous MUL-and-DIV-completion, and is acceptable at 128-core scale (per-core throughput loss is small; aggregate is bounded by the per-core lane).
+- **For 128-core aggregate throughput**: the per-core limitation is the MUL/DIV issue slot, not the divider's iteration. Aggregate MUL throughput is bounded by 1/cycle/core = 128/cycle die-wide. Aggregate DIV throughput is bounded by 1/33 cycles/core = 128/33 ≈ 3.88 divides/cycle die-wide in the steady state if every core is issuing back-to-back independent divides. This is the steady-state upper bound under B1, not a typical workload figure. With B5 reducing some divides to 1 cycle, the aggregate is workload-dependent and typically lower.
+
+**PROPOSAL**: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1, or 2 in the fallback) and variable-latency DIV (~33).
+
+**PROPOSAL**: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.
+
+**PROPOSAL**: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.
+
+**PROPOSAL**: The B-extension unit (if RV64B is implemented) shares **operand muxes, sign-handling logic, and bit-level muxes** with the MUL/DIV unit but does **not** share the Wallace/Dadda compressor tree. Operations like CLZ, CTZ, BSET, BEXT operate on individual bits or small bit-fields and do not naturally map onto a Wallace-tree multiplier datapath. CLMUL / CLMULH / CLMULR (Zbc) require an AND-tree / XOR-reduction datapath that is structurally distinct from both the Wallace-tree multiplier and the iterative divider; they do not share the compressor tree. Any apparent sharing is at the operand-fetch and writeback layers, not the core arithmetic.
+
+## 128-Core Scalability
+
+The 128-core replication factor is the dominant cost driver for the MUL/DIV unit.
+
+**PROPOSAL**: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.
+
+**PROPOSAL**: The MUL/DIV unit's reservation-station entries, divider iteration state, and pipeline registers must support **state retention or clean-state entry** across power gating. Specifically, when a core is power-gated while a long-latency DIV is in flight, the DIV's mid-iteration state must be handled by one of the following:
+  - (a) **Flush and re-issue**: the in-flight DIV is squashed architecturally (the issue queue entry is marked invalid, the divider's iteration state is discarded), and the DIV is re-fetched and re-issued from the I-cache after the core wakes up. This is architecturally transparent if the re-fetch / re-issue mechanism is present (standard OoO replay path); the architectural state is preserved because the DIV is re-executed from scratch. The cost is re-fetch latency after wakeup. The mechanism is "not acceptable" only if the re-fetch path is not implemented (e.g., a simple in-order core without replay).
+  - (b) **Checkpoint to retention**: the divider's iteration state is saved to a retention register or to memory before power-down, and restored on wakeup. Preserves the in-flight DIV but requires retention storage proportional to the divider's state.
+  - (c) **Block power-gating until completion**: power-gating is only allowed when the divider is idle. Simple, but defeats the purpose of DPM if DIV latency is long and frequent.
+- The choice depends on the XH-1 DPM policy and on whether the core is in-order or OoO. **INSUFFICIENT EVIDENCE** on the XH-1 DPM policy; the design must accommodate one of these options without committing to a specific approach here.
+
+**OPEN QUESTION**: What is the actual MUL/DIV area share of the XH-1 core? Published RISC-V references suggest a typical MUL unit occupies a small single-digit percentage of a high-performance core's area, with iterative DIV adding additional area. The prior revision's "1–3%" and "1 MGE/core total" baseline are removed here as unsourced. **INSUFFICIENT EVIDENCE** on the XH-1-specific area share without synthesis.
+
+**OPEN QUESTION**: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.
+
+**INSUFFICIENT EVIDENCE**: The XH-1 die-area budget, process node, and clock period are not established in this document.
+
+**PROPOSAL**: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template. **PROPOSAL**: The generate block itself must be included in the verification scope (not assumed trivially correct). At minimum: a lint-clean check, a synthesis-check that the generate block instantiates the correct number of cores, and a per-instance equivalence check on a sample of cores.
+
+**PROPOSAL**: For 128× replicated MUL/DIV pipeline registers, ECC or parity protection should be considered for soft-error mitigation. **INSUFFICIENT EVIDENCE** on the XH-1 reliability target.
+
+**PROPOSAL**: Reset distribution and scan chain architecture for 128× replicated MUL/DIV must be addressed at the integration level. The MUL/DIV unit's scan chains should support parallel or staggered scan-shift across cores to keep test time bounded. **INSUFFICIENT EVIDENCE** on the XH-1 DFT architecture.
+
+**CONSIDERATION (clock and timing at 128× replication)**: If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (one 64-bit adder-equivalent) which is favorable; a non-pipelined iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter. The clock-skew analysis should be revisited at the integration level once the XH-1 clock tree is defined.
+
+**CONSIDERATION (cross-core aggregate throughput)**: Under B1, each core's blocking DIV delivers at most 1 per 33 cycles per core in the steady state. Across 128 cores, the aggregate is at most ~3.88 divides per cycle in the steady state, which assumes all cores are issuing back-to-back independent divides for the full 33 cycles each. This is an upper bound on aggregate throughput, not a typical workload figure. Real workloads do not exhibit this worst case; the relevant metric is the per-core latency, not aggregate. **INSUFFICIENT EVIDENCE** on whether the XH-1 DPM or interconnect imposes a global cap on simultaneous divide activity; this is a system-level question outside the MUL/DIV unit's scope.
+
+**CONSIDERATION (operand distribution and interconnect)**: Replicating a Wallace tree 128× implies 128 sets of wide operand buses to/from the register file. The interconnect / operand-routing network cost scales with the MUL operand width and the number of cores. **PROPOSAL**: include operand-routing overhead in the area estimate, not just the MUL/DIV datapath itself.
+
+## Performance Considerations
+
+**PROPOSAL**: **MUL throughput of 1 per cycle is a target for a high-performance XH-1 core**, but is not architecturally non-negotiable. Low-end in-order cores (some Ibex configurations) implement MUL with throughput < 1 per cycle. B1 satisfies the high-performance target with a 1-stage pipelined multiplier; B1' extends to 2 per cycle for wide-issue. If the 1-cycle MUL cannot be closed at the target process, the throughput target remains 1 per cycle but the latency becomes 2 cycles (B1-fallback-A).
+
+**PROPOSAL**: **DIV throughput of 1 per ~33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).
+
+**ASSUMPTION**: XH-1 target workloads include a mix consistent with Embench / SPECint-class profiles, where MUL/DIV instructions are a small fraction of dynamic instruction count. **INSUFFICIENT EVIDENCE** on the actual XH-1 target workload mix and on the specific dynamic-instruction share of MUL/DIV. The prior revision's "<2% MUL/DIV" and "<0.5% DIV/REM" claims are removed as unsourced.
+
+**OPEN QUESTION**: Does XH-1 target HPC or cryptography workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3, A4, A2a, or B10. **NOTE**: ML workloads are dominated by floating-point multiplies on the FPU, not by integer MUL/DIV; integer MUL/DIV is relevant to ML only for quantization, address arithmetic, and integer embeddings.
+
+## Area Considerations
+
+**PROPOSAL**: Budget the MUL/DIV unit at a small single-digit percentage of single-core area for the B1 design, pending synthesis. The exact percentage is **INSUFFICIENT EVIDENCE**.
+
+**OPEN QUESTION**: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.
+
+**ASSUMPTION**: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) and A4 (high-radix SRT) are larger, with A4 typically the largest. **INSUFFICIENT EVIDENCE** on the XH-1-specific gate-count budget.
+
+## Power and Energy Considerations
+
+**FACT**: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.
+
+**PROPOSAL**: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.
+
+**PROPOSAL**: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.
+
+**OPEN QUESTION**: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design.
+
+**INSUFFICIENT EVIDENCE**: Specific per-MUL or per-DIV energy numbers for the XH-1 process are not established. The prior revision's "single-digit pJ in 7 nm" claim is removed as unsourced; per-MUL energy in advanced processes is implementation-dependent and varies by an order of magnitude or more depending on architecture and clock frequency.
+
+## Implementation Considerations
+
+**PROPOSAL**: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget accommodates the entire critical path from operand register → compressor tree → CPA → output register, with the pipeline register at the CPA output. **INSUFFICIENT EVIDENCE** on whether a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the XH-1 target clock period; the specific tree depth and CPA depth are implementation-dependent and not asserted as fixed numbers here. The prior revision's "Tree depth 6–7; final CPA ~6 gates deep" is removed as unsourced and implementation-specific.
+
+**MUL pipeline register placement** (clarified):
+- **Primary (1-stage)**: register at CPA output. The compressor tree and the 128-bit CPA are both in cycle 1.
+- **Fallback A (2-stage)**: register at compressor-tree output. The compressor tree is in cycle 1, the 128-bit CPA is in cycle 2.
+- The placement determines the critical path per cycle: in the primary, the per-cycle critical path is tree + CPA; in fallback A, the per-cycle critical path is max(tree, CPA). Fallback A is the natural way to close timing if tree + CPA exceeds the target clock period in a single cycle.
+
+**PROPOSAL**: For MULHSU, the standard implementation generates a 64×64 partial-product array with the unsigned operand's partial products zero in the upper half and the signed operand's final partial-product row sign-extended (or added in inverted-and-carry form) into the reduction tree. The 128-bit-wide signed multiplier datapath is an alternative but doubles the multiplier width and is rarely used.
+
+**PROPOSAL**: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 32 cycles for quotient bits + 1 cycle for finalization = ~33 cycles total. The remainder is the "running remainder" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.
+
+**PROPOSAL**: B5 (skip-on-zero): add a front-end detector on the DIV operands that forwards the result directly for divisor = ±1 or dividend = 0, bypassing the iterative loop. The fast path must handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1) by returning quotient = dividend, remainder = 0, consistent with the M-extension rule. Trivial area; reduces effective DIV latency for common cases.
+
+**PROPOSAL**: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework. Note that WIDTH=32 does not by itself support the MULW instruction semantics in RV64 (which performs a 32×32→64 multiply and sign-extends the 32-bit result); the B3 32×32→64 datapath implements MULW by taking the lower 32 bits and sign-extending to 64.
+
+## Verification Considerations
+
+**FACT**: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions). For DIV/REM, the corner cases include the division-by-zero and signed-overflow rules defined in the ISA spec.
+
+**PROPOSAL**: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:
+- **Reference MUL**: SystemVerilog `bit [127:0]` (or DPI-C to a software bigint). The reference produces the full 128-bit product; the checker compares the appropriate bits of the 128-bit result against the architectural result:
+  - MUL, MULH, MULHU, MULHSU: lower 64 or upper 64 bits of the 128-bit product, with sign-handling per the ISA spec.
+  - MULW: lower 32 bits of the 64-bit product (where the 64-bit product is computed on a 32×32 signed multiplication, with the 32-bit result sign-extended to 64 bits and written to `rd`). The reference is a 32×32 signed multiply that produces a 32-bit result, which is then sign-extended to 64 bits and compared against the architectural `rd` value. The 128-bit reference path is used for MUL/MULH/MULHU/MULHSU, not for MULW.
+- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec, including the division-by-zero and signed-overflow rules for both quotient-producing and remainder-producing instructions.
+- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1), plus randomized large operands.
+- **Regression list size**: The prior revision's "64 hand-crafted corner cases" is removed as a specific number; the regression list should be sized to cover the documented corner cases and is grown as bugs are found. **INSUFFICIENT EVIDENCE** for a canonical count.
+
+**PROPOSAL**: At the 128-core replication level, **per-core functional verification** of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level (via a SystemVerilog generate block). This covers functional equivalence at the unit level. **However**, the verification of the generate block itself, and the interaction between per-core clock-gating / power-state and MUL/DIV state (e.g., does a clock-gated MUL lose its pipeline state correctly across gating? does a power-gated divider leave the iteration counter in a valid state for resumption, or is the DIV flushed and re-issued as in option (a) of the 128-core power-gating proposal?), must be verified explicitly. **Per-core physical / timing verification is not bypassed**: timing, DFT, and physical-design closure are verified at the integration level on a representative core and assumed replicated, with explicit per-die variation analysis as required by the XH-1 physical-design flow.
+
+**PROPOSAL**: If the XH-1 verification flow includes formal property checking, the DIV correctness property ("quotient × divisor + remainder == dividend" within the RISC-V M extension's special cases) is a clean formal target and should be specified. **INSUFFICIENT EVIDENCE** on whether formal property checking is in scope.
+
+## Software Considerations
+
+**PROPOSAL**: Document the MUL/DIV latencies (1 cycle MUL, ~33 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.
+
+**OPEN QUESTION**: Does the XH-1 ABI / linker convention include a software-emulated division routine for code that cannot tolerate the ~33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one. The compiler can also apply divide-by-constant transformations (B6) to reduce effective hardware DIV frequency.
+
+**PROPOSAL**: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.
+
+**PROPOSAL**: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.
+
+## Recommendation
+
+**RECOMMENDATION**: Adopt **B1** — a hybrid MUL unit (target 1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Add **B5** (skip-on-zero, with the signed-overflow corner case handled) at the DIV front end. Add **B3** as the MULW implementation and the 32-bit-extended-operand fast path. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM. For wide-issue cores, scale to **B1'** (two MUL pipelines sharing one DIV).
+
+Rationale:
+1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed for high-performance targets).
+2. Keeps per-core area small, manageable at 128× replication.
+3. Avoids the verification burden of B8 (shared CSA) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).
+4. **B3 inclusion is required for MULW**, not optional: the same 32×32→64 datapath that accelerates 64-bit MUL on 32-bit-extended operands also implements MULW directly. Deferring B3 means deferring the natural MULW implementation.
+5. B5 is a near-free improvement to the common case, with the signed-overflow corner case handled correctly.
+6. The MUL/DIV design inherits the radix-4 iterative divider pattern from Rocket and Ibex; the MUL side departs from both references (1-stage pipelined vs. Rocket's multi-stage or Ibex's short-pipeline / combinational), which is an aggressive target that must be validated by synthesis.
+
+**Fallback plan** (if the 1-cycle MUL cannot be closed at the target process / clock):
+- **Primary fallback**: B1-fallback-A — 2-cycle pipelined MUL with the pipeline register at the compressor-tree output. Latency 2 cycles, throughput 1 per cycle, modest area overhead. B1 architecture preserved.
+- **Secondary fallback**: B1-fallback-B — multi-cycle iterative MUL (Booth-encoded). Cycle count implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number. Lower area, lower throughput, higher latency. DIV remains radix-4 iterative.
+- **Tertiary fallback**: Lower the target clock frequency at the system level.
+
+This recommendation is **conditional on**:
+- The XH-1 target process supporting either a 1-cycle 64×64→128 MUL critical path (primary) or a 2-cycle pipelined MUL critical path (fallback A) at the target clock. Both must be validated by synthesis at the target corner; **INSUFFICIENT EVIDENCE** without target process specification.
+- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT), a pipelined iterative divider (A2a or B10), or a shared MUL/DIV organization (B8, B9).
+- The 128-core replication budget tolerating the cumulative MUL/DIV area; this requires a known single-core area budget, which is **INSUFFICIENT EVIDENCE**.
+- A clear DPM policy for handling in-flight MUL/DIV state across power gating.
+
+If any of these conditions fails, re-open the design against the named fallback.
+
+## Confidence
+
+**Medium-High** for B1 as the baseline architectural pattern. **Low** for specific area, power, and energy numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are **INSUFFICIENT EVIDENCE**). The corrected version removes specific unsourced quantitative claims and demotes several prior FACTs to ASSUMPTION or INSUFFICIENT EVIDENCE.
+
+## Open Questions
+
+1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design and determines whether 1-cycle MUL is feasible.
+2. What is the XH-1 target workload mix? HPC, cryptography, or general-purpose? (ML is not primarily an integer MUL/DIV workload.)
+3. Is the XH-1 core in-order, out-of-order, or hybrid?
+4. Does XH-1 implement RV64B (bit-manipulation) extensions, including Zbc (CLMUL / CLMULH / CLMULR)? The B extension does not naturally share the Wallace-tree multiplier datapath; any sharing is at the operand-mux and writeback layers, not the compressor tree.
+5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?
+6. Does XH-1 use a per-core DPM scheme, and how does it handle in-flight MUL/DIV state across power gating (retention, flush-and-re-issue, or block-power-gate-until-completion)?
+7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM (or RV64IMB)?
+8. Is there a software-emulated division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV? Will the compiler apply divide-by-constant transformations (B6)?
+9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's "quotient × divisor + remainder == dividend" property?
+10. For wide-issue cores, is B1' (two MUL pipelines + one shared DIV) the target, or is single-MUL B1 sufficient?
+11. What is the XH-1 interconnect / operand-routing cost of replicating a wide MUL operand bus 128 times? Should this overhead be included in the MUL/DIV unit's area budget?
+12. What is the XH-1 reliability target? Does the MUL/DIV pipeline require ECC or parity protection against soft errors?
+13. What is the XH-1 DFT architecture for the 128× replicated MUL/DIV scan chains?
+
+## Sources
+
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. Canonical ISA reference; defines the M-extension corner-case rules for DIV/REM/DIVU/REMU/DIVW/REMW/DIVUW/REMUW and MULW.
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA*, Chapter 16 (B Extension, including Zbc). Canonical ISA reference for CLMUL / CLMULH / CLMULR.
+- Asanović et al., "The Rocket Chip Generator," EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. Reference for Rocket's MUL/DIV organization; configuration-dependent.
+- Celio, Patterson, Asanović, "BOOM v2: a superscalar out-of-order processor," 2017. Reference for BOOM's MUL/DIV design.
+- Ibex documentation, lowRISC. Reference for the in-order baseline.
+- Chen et al., "XiangShan: An Open-Source High-Performance RISC-V Core," 2022. Reference for high-performance RISC-V MUL/DIV design.
+- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. Reference for shift-subtract, SRT, and Newton-Raphson divide algorithms.
+- Flynn, Oberman, *Advanced Computer Arithmetic Design*. Reference for high-radix divider design.
+- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. Reference for Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process.
+
+**INSUFFICIENT EVIDENCE**: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, energy, and timing are **INSUFFICIENT EVIDENCE** pending RTL implementation and target-process specification. Cortex-A77 per-instruction latencies are not publicly published by Arm and are **INSUFFICIENT EVIDENCE** from primary sources. The internal radix of the Intel Haswell integer divider is widely reported as high-radix shift-subtract rather than Newton-Raphson, but the specific radix (16 vs. 32) is **INSUFFICIENT EVIDENCE** from primary sources; Newton-Raphson is reported to be used in Haswell's floating-point unit. The cycle count for a Booth-encoded iterative 64×64 multiplier is implementation-dependent and **INSUFFICIENT EVIDENCE** for a specific number.

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

@@ -0,0 +1,141 @@
+VERDICT: FAIL
+
+ISSUES:
+
+**Factual / Spec errors:**
+
+1. The document claims the M extension instructions include "MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW." This list is correct, but the document elsewhere mixes up which instructions are M vs. which are part of the M extension's W-suffixed family. More substantively, the document later describes MULW as "32×32→32 bit product, then sign-extended to 64 bits and written to rd" — this is correct — but the same passage's NOTE then states "MULW is implementable on a 32×32→64-bit datapath... A 32×32→64-bit fast multiplier (B3 datapath) can therefore implement MULW by taking its lower 32 bits and sign-extending to 64." This is internally fine, but the "B3 datapath" is being defined inline with a particular architecture (B3 is later formally defined as a 32-bit fast path with operand-width detection) — terminological overloading that obscures whether B3 is the MULW datapath or an additional fast path.
+
+2. The corner-case description of division by zero: "DIVU / DIVUW: quotient is 2^XLEN − 1 (all bits set, which equals −1 in two's complement representation). The signed and unsigned cases produce the same bit pattern at the architectural level; the spec writes −1 for the signed case and the unsigned maximum for the unsigned case, but these are bit-pattern-identical." This is correct for DIVU. However, the same FACT block conflates the by-1 semantics. For `DIV` / `DIVW` by zero, the architectural result is `−1` (all-ones bit pattern), and for `DIVU` / `DIVUW` by zero, the result is `2^XLEN − 1`, which is the same bit pattern. The text is correct but reads as if it is making a discovery; it should be stated as a single rule. More importantly, the REM/REMU by zero rules: the document states "REM / REMW: remainder equals the dividend. REMU / REMUW: remainder equals the dividend." This is correct.
+
+3. The "fact" that division by zero for `DIVU` returns "the unsigned maximum" while `DIV` returns "−1" being bit-pattern-identical is correct, but the document then states this is "the architectural definition" for both — it is, but the language is loose: the spec defines the result by bit pattern, not by signed interpretation. Minor.
+
+**Unsupported / fabricated quantitative claims:**
+
+4. The claim in A3 that "3 refinement iterations + 1 correction is typical for 64-bit" is marked as ASSUMPTION with INSUFFICIENT EVIDENCE caveat, which is appropriate. However, A4's claim that "radix-64 takes ~8–10 cycles" is stated as FACT, not as the document's own estimate. The radix-64 cycle count for a non-restoring SRT divider on 64-bit operands depends on the redundant representation and final correction; ~8–10 is plausible but is presented as established. Should be demoted to ASSUMPTION or noted as widely-cited but implementation-dependent.
+
+5. A1 states "64-cycle worst case" for radix-2 division. This is correct for a non-restoring radix-2 divider; it should be qualified as "non-restoring" or "iterative" explicitly. Minor.
+
+6. A4 states "DIV Latency: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands." This is presented as FACT but the document elsewhere correctly notes that integer divider radices for commercial designs are INSUFFICIENT EVIDENCE. The cycle counts themselves are not fabricated (they follow from the radix), but presenting them as FACT while flagging the radix of the Intel divider as INSUFFICIENT EVIDENCE is inconsistent. The radix-16 and radix-64 cycle counts are derived from the radix itself, but the area and complexity claims for these dividers in the A4 section are not backed by specific references.
+
+7. The B1' section states: "ASSUMING a MUL:DIV area ratio of approximately 1:1 (i.e., one MUL pipeline and one radix-4 iterative DIV are roughly comparable in area, since a 1-stage 64×64 MUL is a Wallace/Dadda tree plus a 128-bit CPA, and a radix-4 iterative DIV is a ~66-bit adder plus control state), the combined (MUL+DIV) area scales as 1 + 1 = 2× B1." The 1:1 area assumption is presented as plausible but the actual ratio is not established. The arithmetic is fine given the assumption; the assumption itself is reasonable. No fabrication here, but the document should note that the comparator is MUL-with-its-CPA vs. a much smaller iterative divider datapath — a 66-bit adder with control state is plausibly smaller than a Wallace/Dadda tree plus 128-bit CPA. The 1:1 ratio is likely an overestimate, making the 2× B1 figure an upper bound rather than a realistic estimate. The document should say so.
+
+8. B10 area claim "~8× or 16× A1" is presented as derived from the unroll factor, which is reasonable, but this is only the datapath area; control and registers are not scaled. The document notes INSUFFICIENT EVIDENCE in the comparison table, which is appropriate.
+
+9. The aggregate throughput claim "128/33 ≈ 3.88 divides/cycle die-wide in the steady state if every core is issuing back-to-back independent divides" is mathematically correct given the assumptions, and the document explicitly labels it as an upper bound. This is acceptable.
+
+**Internal contradictions:**
+
+10. The document states that B1 "inherits the radix-4 iterative divider pattern from Rocket and Ibex, but the MUL organization (1-stage pipelined) is a custom choice that does not match either Rocket's multi-stage MUL or Ibex's short-pipeline / combinational MUL." The Latency Reference Points section then says Rocket's MUL is "pipelined with multiple pipeline stages" and Ibex's MUL is "single-cycle or short-pipeline combinational." This is consistent. However, the B1 NOTE says the 1-stage MUL "departs from Rocket Chip's default multi-stage MUL" — this is correct. The document then in the Recommendation says "The MUL/DIV design inherits the radix-4 iterative divider pattern from Rocket and Ibex; the MUL side departs from both references" — also consistent. No contradiction.
+
+11. The Recommendation's condition list says "XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT), a pipelined iterative divider (A2a or B10), or a shared MUL/DIV organization (B8, B9)." However, the earlier "Performance Considerations" section explicitly notes that "MODULAR ARITHMETIC in bignum" workloads (cryptography) suffer under B1, and the A3 section identifies A3 as "important for cryptography (RSA, ECC modular reduction)." The escalation list in the Recommendation does not include A3 (Newton-Raphson), which is the more natural fit for cryptographic workloads. This is an internal inconsistency in the recommendation's escalation path.
+
+12. The "1-cycle MUL" target: the document repeatedly states this is the target, then says "1-stage pipelined multiplier" is the B1 design, and clarifies that "the pipeline register sits at the CPA output (after the compressor tree and the 128-bit CPA in cycle 1), so the entire compressor-tree-plus-CPA path is in one cycle." This is the "1-stage pipelined" interpretation, which means latency-1 (one cycle of pipeline latency, result available one cycle after operands). The document also says "1-cycle pipelined" elsewhere. This is internally consistent, but the term "1-stage pipelined" can be read as "1 pipeline stage total, no register" — the document should clarify: "1 pipeline stage means 1 cycle of latency, result available 1 cycle after operands, with a single pipeline register at the CPA output." The placement question (CPA-output vs. compressor-tree-output register) is explicitly addressed and the two options are clearly distinguished. Acceptable but terminology could be tighter.
+
+13. The "B3 is the natural choice for the MULW implementation" claim: the B3 section says B3 "is the natural way to implement MULW." But B4 says "MULW must still be implemented separately (e.g., via B3 or a dedicated 32×32→32 path)." So B4 acknowledges that B3 is one path. However, the B3 section also says B3 is "distinct from MULW as a workaround" and that B3 "accelerates 64-bit MUL... when both operands happen to be 32-bit sign- or zero-extended." The relationship is that B3 implements MULW (a 32×32→32 with sign-extension semantics), but B3 also does more (the 32-bit-extended-operand fast path for 64-bit MUL). The document explains this, but the B3-vs-MULW framing in the Disadvantages section ("B3 does not subsume MULW for the purpose of 'B3 is redundant'") is somewhat confusing — it sounds like the document is pre-empting a critique rather than clarifying the design.
+
+**Missing alternatives:**
+
+14. The document considers a Newton-Raphson divider (A3) and notes that it is "less common for dedicated integer divide." However, the alternative of a *pipelined* Newton-Raphson divider (a refinement-multiplier pipeline) is not considered. Some designs use a pipelined multiplier with multiple stages dedicated to Newton refinement, achieving higher throughput than the iterative version.
+
+15. The document does not consider a "fast divider" using a lookup table for small dividends or small divisors (a common optimization for software-style dividers). A5 dismisses this as "rarely used for 64-bit" without elaborating. Acceptable.
+
+16. The document does not consider a shared integer/floating-point multiplier organization. Many high-performance cores share the integer MUL with the FP MUL mantissa multiplier. This is a significant missing alternative for a 128-core design where area is the dominant concern.
+
+17. The document does not consider a divider that exploits the W-suffixed instructions' narrower operand width by sharing the 64-bit divider's datapath on the lower 32 bits, as the B7 note mentions in passing. This is mentioned but not formalized as a design option distinct from B7.
+
+18. The CLMUL/CLMULH/CLMULR (Zbc) discussion is appropriately scoped out, but the document does not consider whether Zbc is mandatory (some RV64 profiles require Zbc) or optional. The B-extension discussion treats it as optional, but RVA23 mandates Zbc. If XH-1 targets RVA23, Zbc is required.
+
+19. The document does not consider a non-blocking iterative divider (one that frees the issue slot after operand read and signals completion via a writeback-side mechanism). The B1 design is described as "blocking on the unit" but in an OoO core, "blocking" means the reservation station entry remains allocated until completion. The document should distinguish "blocking" (issue slot held) from "non-blocking" (issue slot released after read, completion via writeback). The proposal section says "non-blocking on MUL (1-cycle latency) but blocking on DIV" — this conflates issue-slot allocation with reservation-station allocation.
+
+**Missing assumptions:**
+
+20. The B3 section's "operand-width detection" assumes that detecting whether both 64-bit operands are sign- or zero-extended from 32 bits is straightforward. The detection logic itself is non-trivial (must check that bits 63..32 of operand A equal either bit 31 or zero, and similarly for operand B), and the document does not discuss the cost or complexity of this classifier in detail. The verification cost is noted but the area cost is dismissed as "small."
+
+21. The Recommendation assumes a 1-cycle MUL latency is achievable "in the target process." Without a process node, this is an unbacked assumption. The document explicitly flags this with INSUFFICIENT EVIDENCE, which is appropriate.
+
+22. The "power-gateable independently" proposal assumes per-core power gating is feasible. At 128-core, fine-grained power gating at the unit level (not the core level) is a significant design choice. The document does not discuss whether the MUL/DIV can be power-gated independently of the rest of the core, or only with the core.
+
+**Failure to consider 128-core scaling:**
+
+23. The document's 128-core scalability discussion focuses on area and DPM, but does not consider the cross-core operand-sharing implications of a shared MUL/DIV across cores (e.g., a centralized MUL/DIV unit serving multiple cores via the interconnect). This is a known architectural alternative (e.g., a shared MUL unit in some heterogeneous designs) and is not discussed. Given the document's framing that each core has its own MUL/DIV, this may be out of scope, but it should be mentioned and explicitly rejected.
+
+24. The document does not discuss the verification cost of the *generate block* itself beyond a "lint-clean check" and a "synthesis-check that the generate block instantiates the correct number of cores." Equivalence checking at the RTL level (formal or simulation-based) of 128 instances is a significant verification effort, and the document's brief treatment undersells this.
+
+25. The "ECC or parity protection" proposal is appropriate but the area overhead is not quantified. At 128× replication, ECC on the MUL pipeline register (which is 128 bits wide) is a meaningful area and power overhead. The document should note that the area overhead per MUL pipeline register is on the order of ~12-25% of the register's own area, scaling with the protection scheme.
+
+**Unrealistic implementation claims:**
+
+26. The 1-cycle 64×64→128 MUL target: the document itself flags this as "at the edge of feasibility for high-performance designs." This is appropriate, but the document should cite at least one published RISC-V core that achieves this in a comparable process. Without a citation, the feasibility claim is unbacked. (BOOM and XiangShan are described as "MUL is pipelined" without specifying latency; the document does not claim 1-cycle for these, but does not cite a 1-cycle 64×64→128 MUL implementation either.)
+
+27. The aggregate throughput "3.88 divides/cycle die-wide" claim is bounded by per-core issue rate, but the document does not consider that in a real OoO core, the per-core DIV issue rate is much less than 1 per 33 cycles because dependent instructions create back-pressure. The "1 per 33 cycles" is the latency, not the steady-state issue rate. The steady-state issue rate for independent divides is 1 per 33 cycles, but the document's "1 per 33 cycles/core = 128/33 ≈ 3.88" upper bound is correct for independent divides only. This is acknowledged ("if every core is issuing back-to-back independent divides") but the practical interpretation deserves more caution.
+
+**Unsupported performance / area / power claims:**
+
+28. The B2 MAC addition area "INSUFFICIENT EVIDENCE for a specific percentage" is appropriate. No issue.
+
+29. The "single-digit pJ in 7 nm" claim is correctly removed. No issue.
+
+**Weak verification reasoning:**
+
+30. The Verification section's claim that "per-core functional verification of the MUL/DIV unit is unnecessary if the per-core RTL is identical" is true at the unit level, but the document should also note that the per-core physical verification (timing closure, signal integrity, IR drop, etc.) is not bypassed. The document does mention this in passing ("Per-core physical / timing verification is not bypassed") but the treatment is brief.
+
+31. The formal property "quotient × divisor + remainder == dividend" is well-known but is not the complete formal property. The special cases (div-by-zero, signed overflow) must be excluded or handled separately, and the quotient and remainder must be checked against the architectural bit patterns, not the mathematical identity. The document notes "within the RISC-V M extension's special cases" which is appropriate.
+
+**Incorrect terminology:**
+
+32. The term "Wallace/Dadda tree" is used, but the document does not distinguish them: a Wallace tree minimizes the number of adder elements, while a Dadda tree minimizes the number of stages (and thus the number of total elements, but not strictly). The two have different area/latency trade-offs. The document should not conflate them under "Wallace/Dadda" without acknowledging the distinction, or should pick one and justify.
+
+33. The term "4:2 compressors" is used in the Implementation Considerations section. A 4:2 compressor is a specific circuit (5 inputs, 3 outputs: sum, carry, cout). The document does not define it. Minor.
+
+34. "CSA" in B8 stands for "carry-save adder" (a full adder with no carry propagation), which the document uses correctly. B8's "CSA sharing" means sharing the carry-save compressor tree. B9's "CPA sharing" means sharing the carry-propagate adder. These are correctly distinguished.
+
+**Insufficient source specificity:**
+
+35. The Sources section lists several references, but does not provide chapter/section numbers for Parhami, Flynn/Oberman, or Weste/Harris. The Weste/Harris reference is cited for "Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process." The disclaimer is appropriate, but the source itself is not specific enough to verify the "Tree depth 6–7" claim (which has been removed) or any other quantitative claim.
+
+36. The BOOM reference is "Celio, Patterson, Asanović, 'BOOM v2: a superscalar out-of-order processor,' 2017." This is not a formal publication (it is a technical report / class project report) and the actual BOOM v2/v3 designs have evolved. The reference should be more specific (e.g., the current BOOM repo, specific commits).
+
+37. The XiangShan reference "Chen et al., 'XiangShan: An Open-Source High-Performance RISC-V Core,' 2022" is not a single canonical publication; there are multiple papers (HPCA 2022, MICRO 2022, etc.). The reference should be more specific.
+
+38. The Ibex reference is just "Ibex documentation, lowRISC" without a specific document or version. lowRISC Ibex documentation has evolved; specific version should be cited.
+
+**Other:**
+
+39. The document's "Confidence: Medium-High" for B1 is reasonable. The Low confidence for specific numbers is appropriate. The acknowledgment of removed unsourced claims is a positive sign of revision integrity.
+
+40. The document's status section explicitly says "This revision corrects factual errors identified in review, removes unsupported quantitative claims, reconciles internal contradictions, and adds missing alternatives." This is honest but the document still contains issues (noted above). The revision is a substantial improvement over a hypothetical prior revision, but is not yet ready for PASS.
+
+REQUIRED FIXES:
+
+1. Clarify the A4 latency claims: demote "~16 cycles (radix-16)" and "~8–10 cycles (radix-64)" from FACT to ASSUMPTION with explicit note that these are derived from the radix and are implementation-dependent. Cite at least one published design that uses a radix-16 SRT divider with a known cycle count, or flag as INSUFFICIENT EVIDENCE for XH-1.
+
+2. Reconcile the recommendation's escalation list (A4 / A2a / B10 / B8 / B9) with the Performance Considerations section (A3 / A4 / A2a / B10). The omission of A3 (Newton-Raphson) from the recommendation's escalation list is an internal inconsistency. Either add A3 or explain why A3 is excluded.
+
+3. Add a discussion of whether XH-1 targets RVA23 (which mandates Zbc) and, if so, note that Zbc must be implemented and is not optional. The current discussion treats the B extension as optional.
+
+4. Distinguish "Wallace tree" and "Dadda tree" in the Implementation Considerations section. Either justify the choice or use a more neutral term (e.g., "partial-product compressor tree").
+
+5. Address the B3 operand-width detection logic's area, latency, and verification cost in more detail. The current treatment dismisses these as "small" / "manageable" without quantification.
+
+6. Discuss the shared integer/FP multiplier alternative as a missing option, or explicitly state that this is out of scope for the XH-1 architecture and explain why.
+
+7. Discuss the "centralized MUL/DIV shared across cores" alternative, or explicitly state that this is out of scope and explain why per-core MUL/DIV is mandated.
+
+8. Cite at least one published RISC-V or comparable core that implements a 1-cycle 64×64→128 MUL pipeline at a comparable process node, or demote the 1-cycle MUL target from PROPOSAL to "stretch goal" with the implicit understanding that the 2-cycle fallback is the realistic baseline.
+
+9. Provide more specific source citations for BOOM, XiangShan, and Ibex (specific papers, versions, or commit hashes).
+
+10. Address the ECC overhead on the MUL pipeline register at 128× replication with at least a qualitative area estimate.
+
+11. Clarify the verification cost of the generate block instantiation beyond a "lint-clean check" — formal equivalence between instances, or simulation-based differential testing across a sample of cores.
+
+12. Fix the terminology "1-stage pipelined" to be unambiguous: explicitly state "1-cycle latency" or "result available 1 cycle after operands" with the pipeline register at the CPA output.
+
+13. Distinguish "blocking on the issue slot" from "blocking on the reservation station" for the DIV unit in an OoO core. The current "blocking on DIV" is ambiguous.
+
+14. Verify the B1' area estimate: the 1:1 MUL:DIV area ratio is a strong assumption. A Wallace/Dadda tree plus 128-bit CPA is plausibly larger than a 66-bit iterative divider datapath. Either provide a more realistic ratio (e.g., 1.5:1 or 2:1) or explicitly state that the 2× B1 figure is an upper bound and that the realistic figure may be lower.
+
+15. Address the latency-vs.-throughput distinction for the divider aggregate throughput. The "1 per 33 cycles" is a latency, and the steady-state issue rate for independent divides is 1 per 33 cycles, but the document should clarify that this is the *best case* and that workload-dependent back-pressure typically reduces it.
+
+CONFIDENCE: HIGH

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

@@ -0,0 +1,298 @@
+# MUL/DIV Unit
+
+## Status
+
+Stub — initial scoping document. No XH-1 implementation decisions are yet committed.
+
+## Abstract
+
+This document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT) which reuse portions of the MUL datapath. The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only 2% of core area in a single core consumes the equivalent area of ~2.5 cores across the die when replicated 128 times. The unit's latency directly impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).
+
+## Research Question
+
+What is the optimal MUL/DIV unit organization for a XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?
+
+## Background
+
+### RISC-V M Extension Semantics (RV64M)
+
+FACT: The RISC-V M extension (RV64M for 64-bit) defines eight instructions:
+- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result)
+- DIV, DIVU: 64÷64 signed/unsigned quotient
+- REM, REMU: 64÷64 signed/unsigned remainder
+- DIV/DIVU/REM/REMU have defined corner cases: division by zero returns -1 (signed) or -1 (unsigned quotient), remainder by zero returns the dividend; signed overflow (most-negative ÷ -1) returns the quotient as the most-negative value and remainder 0.
+
+The full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned.
+
+### Latency Reference Points (FACT, from published RISC-V implementations, see Sources)
+
+- Rocket Chip (SiFive, in-order, BOOM-style 5-stage scaled): MUL is 3-cycle latency (unpipelined, iterative), DIV is variable 8–35 cycles.
+- BOOM v2/v3 (out-of-order, 6–7 wide): MUL 1-cycle (pipelined), DIV variable 2–34 cycles.
+- XiangShan (Nanjing, out-of-order): MUL 2-cycle pipelined, DIV variable.
+- Ibex (lowRISC, in-order): MUL single-cycle combinational or 1-cycle pipelined; iterative DIV.
+- Cortex-A77 (Arm, reference comparison): MUL 3-cycle, DIV 4–12 cycle variable.
+
+### Divide Algorithms
+
+FACT: Three primary classes exist:
+1. **Digit-recurrence / shift-subtract (radix-2, radix-4, SRT)**: 64 cycles worst-case for radix-2; radix-4 reduces to ~33 cycles; iterative, small area.
+2. **Newton-Raphson reciprocal multiplication**: 4–6 cycle reciprocal, 1 MUL → 12–14 cycles total; high throughput on subsequent divides; needs ~17-bit seed table; occupies more area (multiplier + lookup ROM).
+3. **Goldschmidt**: similar to Newton, slightly different convergence.
+
+The RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.
+
+## Existing Approaches
+
+### A1. Iterative Shift-Subtract Divider (Radix-2)
+
+- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, 64-cycle worst case.
+- **Latency**: 64 cycles (or 32 with radix-4 merging).
+- **Throughput**: 1 divide per 64 cycles (not pipelined) or 1/cycle if pipelined with 64 stages.
+- **Area**: Smallest — typically 1–2 kGE plus control.
+- **Power**: Lowest; minimal toggle rate per non-dividing cycle.
+- **Used in**: Rocket (radix-4 unpipelined), Ibex (radix-4).
+
+### A2. Pipelined Iterative Divider
+
+- **Datapath**: same as A1 but with pipeline registers at each iteration; latency fixed at 64 cycles, throughput 1/cycle.
+- **Latency**: 64 cycles, fixed.
+- **Throughput**: 1/cycle.
+- **Area**: ~3–5× A1 due to per-stage registers; significant.
+- **Power**: Higher clock-gating complexity; only worthwhile under sustained divide streams.
+
+### A3. Newton-Raphson Divider
+
+- **Datapath**: shared MUL unit, 17-bit reciprocal seed ROM, 2–3 MUL units working in parallel.
+- **Latency**: 4–6 cycles for reciprocal + 1 MUL correction = 6–8 cycles typical.
+- **Throughput**: 1 divide per ~6–8 cycles.
+- **Area**: 1 reciprocal ROM (~4–8 kbits) + 2–3 MULs; large.
+- **Power**: Higher static and dynamic (multiplier always active during divide).
+- **Used in**: High-performance x86 cores (Intel since Haswell uses Radix-16 + Newton), some Arm cores.
+
+### A4. Approximate / Lookup-Based Dividers (small operand ranges)
+
+- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.
+
+## Alternative Designs
+
+### B1. Hybrid MUL + Sequential-Iterative DIV (Rocket-style)
+
+- MUL: 64×64→128 pipelined in 1–2 stages.
+- DIV: radix-4 or radix-2 iterative, 33–64 cycles, blocking on the unit.
+- Latency hide: out-of-order core can issue subsequent independent ops; in-order core must stall.
+- Single divider per core, 1–3 MUL pipelined stages.
+
+### B2. Combined MUL/MAC (Multiply-Accumulate) Unit
+
+- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).
+- Adds ~10–15% area over pure MUL.
+- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.
+
+### B3. Configurable MUL Width (32-bit fast path)
+
+- Detect when both operands are zero-extended from 32 bits; use a 32×32→64 fast multiplier (~¼ area, ~½ latency).
+- Common in commercial cores (Arm, x86).
+- Branch-predictor / decoder pre-classifies 32-bit-mul hint (e.g., MULW — but note RV64M only defines full 64×64 MUL; 32-bit W variants are in RV64I/RV32I base).
+- Open question: whether a "fast-path 32-bit MUL" justifies the verification cost.
+
+### B4. Bypassable Output with Operand Width Detection
+
+- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.
+- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.
+- Disadvantage: no area saving.
+
+## Comparison
+
+| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL) | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |
+|--------|------------|----------|-------------|----------|------------------|----------------------|----------------|--------------------------|
+| A1 (radix-2 iter. DIV) | 1-cycle comb. or 1-cycle pipe | 1/cycle | 64 cycles | 1/64 cycles | 1.0× | 1.4× | Lowest | Low |
+| A2 (pipelined iter. DIV) | 1-cycle | 1/cycle | 64 cycles | 1/cycle | 1.0× | 2.5× | Med | Med |
+| A3 (Newton-Raphson) | 1-cycle | 1/cycle | 6–8 cycles | 1/6–8 | 3.0× (3 MULs) | 4.0× | High | High |
+| B1 (Rocket-style) | 1–2 cycle | 1/cycle | 33–64 cycle | 1/33–64 | 1.2× | 1.8× | Low–Med | Low–Med |
+| B2 (+ MAC) | 1–2 cycle | 1/cycle | 33–64 cycle | 1/33–64 | 1.4× | 2.0× | Med | Med |
+| B3 (32-bit fast) | 0.5–1 cycle | 1/cycle | (not changed) | (not changed) | 0.9× | 1.3× | Low | Med–High (dual mode) |
+| B4 (full only) | 1–2 cycle | 1/cycle | 33–64 cycle | 1/33–64 | 1.2× | 1.8× | Med | Lowest |
+
+ASSUMPTION: Relative area figures are estimates based on the relative complexity of the published designs in the Sources section. Actual XH-1 synthesis numbers are INSUFFICIENT EVIDENCE pending RTL implementation.
+
+## Advantages
+
+### A1 / B1
+- Smallest area; lowest per-core replication cost.
+- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).
+- Simpler verification; one mode of operation.
+- Well-understood reference implementation (Rocket, Ibex) for cross-checking.
+
+### A3 (Newton-Raphson)
+- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.
+- Amortizes multiplier cost if MAC (B2) is also desired.
+
+### B2 (MAC)
+- Enables future-proofing for proposed bitmanip and MAC extensions.
+- Helpful for matrix multiplication kernels running across 128 cores.
+
+## Disadvantages
+
+### A1 / B1
+- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall 33–64 cycles per divide.
+- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.
+- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).
+
+### A3
+- Area at 128-core replication is severe; ~4× a single MUL unit.
+- Power: a 64×64 multiplier running 1/cycle is one of the highest-power blocks in a typical core.
+- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.
+
+### B3
+- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.
+- The classification logic (operand-width detection) is itself a source of corner-case bugs.
+
+### B2
+- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.
+
+## XH-1 Considerations
+
+PROPOSAL: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:
+- **MUL**: 64×64→128, 1-cycle pipelined (1 stage of pipeline registers), throughput 1/cycle. For 2-issue or wider cores, replicate to 2 MUL pipelines.
+- **DIV**: Radix-4 shift-subtract, 33–35 cycles worst case, blocking, non-pipelined.
+- **REM**: Reuse the DIV datapath; remainder is a by-product.
+- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle; otherwise the 1-cycle latency is already satisfied.
+- **Operand-width detection**: Defer B3 to a future revision; not justified at the 128-core replication level given the added verification cost.
+
+ASSUMPTION: A 1-cycle MUL latency is achievable in the target process. INSUFFICIENT EVIDENCE on the XH-1 target process node and clock period.
+
+PROPOSAL: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1) and variable-latency DIV (33–35).
+
+PROPOSAL: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.
+
+PROPOSAL: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.
+
+## 128-Core Scalability
+
+The 128-core replication factor is the dominant cost driver for the MUL/DIV unit.
+
+PROPOSAL: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.
+
+FACT: A typical MUL unit occupies 1–3% of a high-performance core's area; iterative DIV adds 0.5–1%. At 128 cores, this is ~128–256 kGE of pure MUL/DIV logic (ASSUMPTION, based on ~1 MGE/core total and 2% MUL/DIV share).
+
+OPEN QUESTION: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.
+
+ASSUMPTION: The XH-1 die-area budget for the compute fabric is on the order of 60–80 mm² in a 7–5 nm process; the 128 cores plus interconnect fit within this. INSUFFICIENT EVIDENCE on the actual XH-1 die size and process node.
+
+PROPOSAL: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template.
+
+CONSIDERATION: If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (~one 64-bit adder) which is favorable; a non-pipelined 64-bit iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter.
+
+## Performance Considerations
+
+PROPOSAL: **MUL throughput of 1/cycle is non-negotiable** for a modern XH-1 core. B1 satisfies this with a single 1-stage pipelined multiplier.
+
+PROPOSAL: **DIV throughput of 1/33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).
+
+FACT: From published SPECint 2017 / Embench profiles, MUL/DIV instructions are typically <2% of dynamic instruction count. DIV/REM is <0.5% of dynamic instructions. Hence MUL latency and throughput dominate, not DIV.
+
+ASSUMPTION: XH-1 target workloads are similar in mix to Embench/SPECint-class. INSUFFICIENT EVIDENCE on the actual XH-1 target workload mix.
+
+OPEN QUESTION: Does XH-1 target HPC or ML workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3/B2.
+
+## Area Considerations
+
+PROPOSAL: Budget the MUL/DIV unit at **≤2% of single-core area** for the B1 design. At 128 cores this is ≤256% of one core's area — significant.
+
+OPEN QUESTION: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.
+
+ASSUMPTION: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) is 3–4× the area. INSUFFICIENT EVIDENCE on the XH-1-specific gate-count budget.
+
+## Power and Energy Considerations
+
+FACT: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.
+
+PROPOSAL: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.
+
+PROPOSAL: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.
+
+OPEN QUESTION: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design (e.g., should the MUL unit support a "low-power divide" mode that takes 64 cycles at half frequency?).
+
+ASSUMPTION: Energy per MUL is dominated by dynamic power; a single 64×64→128 MUL in a 7 nm process is on the order of single-digit pJ. INSUFFICIENT EVIDENCE on the XH-1 process.
+
+## Implementation Considerations
+
+PROPOSAL: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. Tree depth 6–7; final CPA ~6 gates deep. The 1-cycle latency budget must accommodate the entire critical path from operand register → compressor tree → CPA → output register.
+
+PROPOSAL: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 33 cycles for 64-bit. The remainder is the "running remainder" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.
+
+PROPOSAL: The MUL unit is reused for the B-extension operations (CLZ, CTZ, BSET, BEXT, etc.) only if those share the same datapath structure; otherwise, add a separate small B-extension unit. INSUFFICIENT EVIDENCE on whether the XH-1 implements RV64B.
+
+PROPOSAL: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework.
+
+## Verification Considerations
+
+FACT: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions).
+
+PROPOSAL: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:
+- **Reference MUL**: SystemVerilog bigint (or DPI-C to a software bigint). Compare lower-64 and upper-64 separately.
+- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec including corner cases.
+- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1).
+
+PROPOSAL: Maintain a **regression list of 64 hand-crafted corner cases** plus a **constrained-random sweep** of 1M iterations for each of MUL, MULHU, DIV, REM. Run weekly.
+
+PROPOSAL: At the 128-core replication level, **per-core** verification of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level. The replication itself is a structural concern verified at integration time.
+
+OPEN QUESTION: Does the XH-1 verification flow include formal property checking? The DIV correctness property ("quotient × divisor + remainder == dividend" within the RISC-V M extension's special cases) is a clean formal target.
+
+## Software Considerations
+
+PROPOSAL: Document the MUL/DIV latencies (1 cycle MUL, 33–35 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.
+
+OPEN QUESTION: Does the XH-1 ABI / linker convention include a software-emulated 128-bit division routine for code that cannot tolerate the 33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one.
+
+PROPOSAL: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.
+
+PROPOSAL: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.
+
+## Recommendation
+
+**RECOMMENDATION: Adopt B1 — a hybrid MUL unit (1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM.**
+
+Rationale:
+1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed).
+2. Keeps per-core area at ~1.5–2% of the core, manageable at 128× replication.
+3. Avoids the verification burden of B3 (dual datapath) and the area burden of A3 (Newton-Raphson).
+4. Aligns with proven reference designs (Rocket, BOOM) reducing architectural risk.
+5. Pipelined MUL is achievable in a single cycle in modern processes (FACT, see Sources).
+
+This recommendation is **conditional on**:
+- The XH-1 target process supporting a 1-cycle 64×64→128 MUL critical path.
+- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A3.
+- The 128-core replication budget tolerating ~1.8× MUL area for MUL+DIV versus MUL alone.
+
+If any of these conditions fails, re-open the design.
+
+## Confidence
+
+**Medium-High** for B1 as the baseline choice. **Low** for specific area and power numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are INSUFFICIENT EVIDENCE).
+
+## Open Questions
+
+1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design.
+2. What is the XH-1 target workload mix? HPC, ML, cryptography, or general-purpose?
+3. Is the XH-1 core in-order, out-of-order, or hybrid? (The repository context does not yet establish this fact per the system policy.)
+4. Does XH-1 implement RV64B (bit-manipulation) extensions? The B extension reuses portions of the MUL datapath.
+5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?
+6. Does XH-1 use a per-core DPM scheme that requires the MUL/DIV unit to support fine-grained power gating?
+7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM?
+8. Is there a software-emulated 128-bit division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV?
+9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's "quotient × divisor + remainder == dividend" property?
+
+## Sources
+
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. (Public specification; no fabricated citation — this is the canonical ISA reference.)
+- Asanović et al., "The Rocket Chip Generator," EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. (Reference for Rocket's MUL/DIV organization.)
+- Celio, Patterson, Asanović, "BOOM v2: a superscalar out-of-order processor," 2017. (Reference for BOOM's MUL/DIV design.)
+- Ibex documentation, lowRISC. (Reference for the in-order baseline.)
+- Chen et al., "XiangShan: An Open-Source High-Performance RISC-V Core," 2022. (Reference for high-performance RISC-V MUL/DIV design.)
+- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. (Reference for shift-subtract, SRT, Newton-Raphson divide algorithms.)
+- Flynn, Oberman, *Advanced Computer Arithmetic Design*. (Reference for high-radix divider design.)
+- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. (Reference for Wallace/Dadda multiplier critical-path analysis.)
+
+INSUFFICIENT EVIDENCE: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, and timing are estimates pending RTL implementation.

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

@@ -0,0 +1,368 @@
+# MUL/DIV Unit
+
+## Status
+
+Stub — initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors, removes unsupported quantitative claims, reconciles contradictions, and adds missing alternatives identified in review.
+
+## Abstract
+
+This document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT). The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only a small percentage of a single core's area consumes a large cumulative area across the die when replicated 128 times. The unit's latency impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).
+
+## Research Question
+
+What is the optimal MUL/DIV unit organization for a XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?
+
+## Background
+
+### RISC-V M Extension Semantics (RV64M)
+
+FACT: The RISC-V M extension for RV64 defines the following instructions:
+- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result, with sign-handling variations).
+- MULW: 32×32→32 (lower 32 of a 32×32→64 multiply, sign-extended result written to xrd).
+- DIV, DIVU: 64÷64 signed/unsigned quotient.
+- REM, REMU: 64÷64 signed/unsigned remainder.
+- DIVW, DIVUW, REMW, REMUW: 32÷32 signed/unsigned quotient/remainder, sign-extended.
+
+FACT (per RISC-V ISA spec): The M extension defines the following corner-case behavior:
+- Division by zero:
+  - `DIV` / `DIVU` / `DIVW` / `DIVUW`: quotient is `-1` (i.e., all bits set).
+  - `REM` / `REMU` / `REMW` / `REMUW`: remainder equals the dividend.
+- Signed overflow (most-negative integer divided by `-1`):
+  - `DIV` / `DIVW`: quotient equals the most-negative representable value.
+  - `REM` / `REMW`: remainder equals zero.
+- For unsigned divide (`DIVU`/`REMU`/`DIVUW`/`REMUW`), overflow cannot occur; only the divide-by-zero rule applies.
+
+The full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned. The MULHSU (signed × unsigned) variant requires explicit sign-handling of the signed operand before partial-product reduction; a pure unsigned Wallace/Dadda tree requires a front-end sign-extension / Booth-encoding stage.
+
+NOTE: The W-suffixed instructions (MULW, DIVW, DIVUW, REMW, REMUW) are part of the **M extension** in RV64, not the base I extension. The base I extension's W variants are only the simple ALU ops (ADDW, SUBW, SLLW, SRLW, SRAW).
+
+### Latency Reference Points (FACT, from published RISC-V implementations, see Sources)
+
+- Rocket Chip (SiFive, in-order): MUL is unpipelined and configuration-dependent; commonly cited as 3- or 4-cycle unpipelined iterative multiplier. DIV is variable (radix-4 iterative). INSUFFICIENT EVIDENCE for a single canonical latency number without specifying the Rocket Chip configuration (StandardConfig vs MinimalConfig vs other).
+- BOOM v2/v3 (out-of-order): MUL pipelined; latency configuration-dependent. DIV variable.
+- XiangShan (Nanjing, out-of-order): MUL pipelined, DIV variable.
+- Ibex (lowRISC, in-order): MUL single-cycle combinational or short-pipeline; iterative DIV.
+- Arm Cortex-A77: per-instruction latencies are not publicly published by Arm. INSUFFICIENT EVIDENCE; no specific MUL/DIV latency numbers are cited from a primary source.
+
+### Divide Algorithms
+
+FACT: Four primary classes are considered here:
+1. **Digit-recurrence / shift-subtract (radix-2, radix-4, radix-16, radix-64 SRT)**: radix-2 takes 64 cycles worst case; radix-4 takes ~32–33 cycles; radix-16 takes ~16 cycles; radix-64 takes ~8–10 cycles (with significant area/complexity cost). Iterative, small-to-moderate area depending on radix.
+2. **Newton-Raphson reciprocal multiplication**: multiple iterations of a multiply-based refinement to compute the reciprocal, then a final correction multiply to produce the quotient. Latency depends on initial seed precision and convergence criteria.
+3. **Goldschmidt**: similar convergence behavior to Newton-Raphson, with a different iteration structure.
+4. **CORDIC-based and series-expansion dividers**: rotate-mode or series-expansion methods; rarely used for general-purpose integer divide due to overhead, but exist as alternative approaches.
+
+The RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.
+
+## Existing Approaches
+
+### A1. Iterative Shift-Subtract Divider (Radix-2, single divider only)
+
+- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, radix-2, 64-cycle worst case.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 divide per 64 cycles (not pipelined).
+- **MUL coverage**: A1 defines a divider only; MUL is not part of this organization. Any combined MUL+radix-2-DIV system must be specified separately.
+- **Area (DIV only)**: Smallest divider; typically a few kGE plus control.
+- **Power**: Lowest of the divider options; minimal toggle rate per non-dividing cycle.
+- **Used in**: Some low-end in-order cores; some configurations of Rocket.
+
+### A2. Pipelined Iterative Divider
+
+- **Datapath**: same shift-subtract array as A1 but with pipeline registers at each iteration; latency fixed at 64 cycles, throughput 1/cycle.
+- **DIV Latency**: 64 cycles, fixed.
+- **DIV Throughput**: 1/cycle.
+- **Area**: ~3–5× A1 due to per-stage registers; significant.
+- **Power**: Higher clock-gating complexity; only worthwhile under sustained divide streams.
+
+### A3. Newton-Raphson Divider
+
+- **Datapath**: shared MUL unit(s), initial reciprocal seed ROM, multiplier used in iterative refinement and one final correction multiply.
+- **Latency breakdown**: seed table lookup (1 cycle) + N refinement multiplies (typically 2–3 iterations for 64-bit integer) + 1 final correction multiply. ASSUMPTION: 3 refinement iterations + 1 correction is typical for 64-bit; concrete iteration count depends on the seed precision and the desired final precision. INSUFFICIENT EVIDENCE for a single canonical iteration count without specifying the seed table and refinement schedule.
+- **Throughput**: one divide per N+1 MUL cycles (where N = refinement iterations), assuming the multiplier is dedicated to the divider.
+- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (one of which can be shared with the main MUL datapath, at the cost of contention); large.
+- **Power**: Higher static and dynamic (multiplier active during divide refinement).
+- **Used in**: Some high-performance FPU designs for floating-point; less common for dedicated integer divide because the integer multiplier is large and the fixed iteration count does not beat pipelined shift-subtract on worst-case latency.
+
+### A4. Radix-16 / Radix-64 SRT Divider
+
+- **Datapath**: high-radix recurrence with a quotient-digit lookup table (PLA or ROM), redundant remainder representation. 16 or 64 bits processed per cycle.
+- **DIV Latency**: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands.
+- **DIV Throughput**: 1/cycle if pipelined, or 1 per 16 / 8–10 cycles if iterative.
+- **Area**: large lookup table and complex datapath; PLA is a significant area contributor. Practical only in high-performance designs.
+- **Power**: high; many bits toggle per cycle.
+- **Used in**: high-end x86 integer dividers (e.g., Intel Haswell and later use a radix-16 / radix-32 shift-subtract divider for integer divide, not Newton-Raphson; Newton-Raphson in those designs is used in the floating-point unit).
+
+### A5. Approximate / Lookup-Based Dividers (small operand ranges)
+
+- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.
+
+## Alternative Designs
+
+### B1. Hybrid MUL + Sequential-Iterative DIV (Rocket-style)
+
+- MUL: 64×64→128 pipelined in 1–2 stages.
+- DIV: radix-4 iterative, ~33 cycles (radix-4: 2 quotient bits per cycle, 32 cycles for quotient bits + finalization), blocking on the unit.
+- Latency hide: out-of-order core can issue subsequent independent ops; in-order core must stall.
+- Single divider per core, 1–3 MUL pipelined stages.
+
+### B1'. Two MUL Pipelines + Shared Iterative DIV (wide-issue variant)
+
+- Two pipelined MUL datapaths, one shared radix-4 DIV datapath.
+- MUL throughput: 2/cycle (sustained, independent operands).
+- DIV throughput: 1 per ~33 cycles, shared and blocking.
+- Area: ~1.8–2.0× B1 (two MUL pipelines) + same DIV.
+- Useful for 2-issue or wider cores; the recommendation in the original document of "replicate to 2 MUL pipelines for wide issue" is a degenerate case of this option.
+
+### B2. Combined MUL/MAC (Multiply-Accumulate) Unit
+
+- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).
+- Adds ~10–15% area over pure MUL (ASSUMPTION; INSUFFICIENT EVIDENCE without RTL).
+- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.
+
+### B3. Configurable MUL Width (32-bit fast path)
+
+- Detect when both operands are zero-extended or sign-extended from 32 bits (e.g., results of MULW, DIVW, DIVUW, REMW, REMUW, or explicit 32-bit-zero-extended operands); use a 32×32→64 fast multiplier.
+- Common in commercial cores (Arm, x86).
+- Branch-predictor / decoder pre-classifies operand width.
+- Open question: whether a "fast-path 32-bit MUL" justifies the verification cost given the MULW instruction in RV64M already gives 32-bit semantics with a 32-bit result.
+
+### B4. Bypassable Output with Operand Width Detection
+
+- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.
+- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.
+- Disadvantage: no area saving.
+
+### B5. Skip-on-Zero / Divide-Cancellation Optimizations
+
+- Detect zero dividend (quotient is zero, remainder is dividend) and divide-by-one (quotient is dividend, remainder is zero) at the front end and forward the result without entering the iterative loop.
+- Saves latency in the common case for some workloads; trivial area overhead.
+- Composable with any divider organization.
+
+### B6. Software Divide-by-Constant Transformation (cross-cutting)
+
+- Compilers transform division by a runtime constant into a multiply-by-reciprocal sequence. The hardware DIV is then needed only for division by variables.
+- Reduces effective DIV frequency significantly for workloads with constant denominators; affects hardware sizing decisions.
+
+## Comparison
+
+| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |
+|--------|-------------|----------|-------------|----------|----------------------|----------------|--------------------------|
+| A1 (radix-2 iter. DIV only) | not defined in A1 | not defined in A1 | 64 cycles | 1/64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |
+| A2 (pipelined iter. DIV) | not defined in A2 | not defined in A2 | 64 cycles | 1/cycle | INSUFFICIENT EVIDENCE (combined) | Med | Med |
+| A3 (Newton-Raphson) | 1-cycle | 1/cycle | depends on iteration count (see A3) | 1/(N+1) cycles | high (see A3) | High | High |
+| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1/cycle if pipelined | high | High | High |
+| B1 (Rocket-style) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | baseline | Low–Med | Low–Med |
+| B1' (2× MUL + 1× shared DIV) | 1–2 cycle | 2/cycle | ~33 cycle | 1/33 cycle (shared) | ~1.8–2.0× B1 | Med | Med |
+| B2 (+ MAC) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | +10–15% over B1 (ASSUMPTION) | Med | Med |
+| B3 (32-bit fast) | <1 cycle (32-bit path) | 1/cycle | ~33 cycle | 1/33 cycle | varies | Low | Med–High (dual mode) |
+| B4 (full only) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | same as B1 | Med | Lowest |
+| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |
+
+ASSUMPTION: Relative area figures are estimates based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are INSUFFICIENT EVIDENCE pending RTL implementation. Specific quantitative area multipliers (e.g., "1.4×", "2.5×", "3.0×") from the prior revision are removed in favor of qualitative ordering.
+
+## Advantages
+
+### A1 / B1
+- Smallest area; lowest per-core replication cost.
+- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).
+- Simpler verification; one mode of operation.
+- Well-understood reference implementation (Rocket, Ibex) for cross-checking.
+
+### A4 (High-Radix SRT)
+- Lowest DIV latency among the iterative-style options; competitive with A3 on a single divide.
+- Pipelined variant gives 1/cycle DIV throughput.
+
+### A3 (Newton-Raphson)
+- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.
+- Amortizes multiplier cost if MAC (B2) is also desired.
+- Disadvantage: requires multiple refinement iterations; the integer multiplier is large and contention with the main MUL datapath is a concern.
+
+### B2 (MAC)
+- Enables future-proofing for proposed bitmanip and MAC extensions.
+- Helpful for matrix multiplication kernels running across 128 cores.
+
+### B5 (Skip-on-Zero)
+- Negligible area; reduces effective DIV latency for common cases.
+
+## Disadvantages
+
+### A1 / B1
+- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall ~33 cycles per divide.
+- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.
+- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).
+
+### A3
+- Area at 128-core replication is severe; the multiplier is one of the largest blocks in a typical core.
+- Power: a 64×64 multiplier running 1/cycle is one of the highest-power blocks in a typical core.
+- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.
+
+### A4
+- Large lookup table (PLA or ROM); area and power dominated by the table.
+- Verification: complex quotient-digit selection logic.
+- Not commonly used outside high-end commercial designs.
+
+### B3
+- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.
+- The classification logic (operand-width detection) is itself a source of corner-case bugs.
+- The MULW instruction in RV64M already provides 32-bit MUL semantics, so a "fast path" for non-MULW 32-bit operands must be justified against MULW's existing semantics.
+
+### B2
+- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.
+
+### B5
+- Only helps the specific cases of zero dividend or divisor ±1; other optimizations (e.g., division by small powers of two) are already handled by the base I extension's shift instructions.
+
+## XH-1 Considerations
+
+PROPOSAL: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:
+- **MUL**: 64×64→128, 1-cycle pipelined (1 stage of pipeline registers), throughput 1/cycle. For 2-issue or wider cores, scale to B1' (two MUL pipelines sharing one DIV).
+- **DIV**: Radix-4 shift-subtract, ~33 cycles worst case (32 cycles for quotient bits + finalization), blocking, non-pipelined. (The prior revision's "33–35 cycles worst case" and the "33–64 cycle" range are reconciled here: 33 is the radix-4 bound; 64 corresponds to radix-2, which is a different algorithm choice.)
+- **REM**: Reuse the DIV datapath; remainder is a by-product.
+- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle.
+- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead.
+- **Operand-width detection**: Defer B3 to a future revision; not justified at the 128-core replication level given the added verification cost and the existence of MULW for the 32-bit case.
+
+ASSUMPTION: A 1-cycle MUL latency is achievable in the target process. INSUFFICIENT EVIDENCE on the XH-1 target process node and clock period. PROPOSAL: Validate via synthesis at the target corner before committing.
+
+PROPOSAL: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1) and variable-latency DIV (~33).
+
+PROPOSAL: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.
+
+PROPOSAL: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.
+
+PROPOSAL: The B-extension unit (if RV64B is implemented) shares **operand muxes, sign-handling logic, and bit-level muxes** with the MUL/DIV unit but does **not** share the Wallace/Dadda compressor tree. Operations like CLZ, CTZ, BSET, BEXT operate on individual bits or small bit-fields and do not naturally map onto a Wallace-tree multiplier datapath. Any apparent sharing is at the operand-fetch and writeback layers, not the core arithmetic.
+
+## 128-Core Scalability
+
+The 128-core replication factor is the dominant cost driver for the MUL/DIV unit.
+
+PROPOSAL: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.
+
+OPEN QUESTION: What is the actual MUL/DIV area share of the XH-1 core? Published RISC-V references suggest a typical MUL unit occupies a few percent of a high-performance core's area, with iterative DIV adding additional area. The prior revision's "1–3% FACT" and "1 MGE/core total" baseline are removed here as unsourced. INSUFFICIENT EVIDENCE on the XH-1-specific area share without synthesis.
+
+OPEN QUESTION: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.
+
+INSUFFICIENT EVIDENCE: The XH-1 die-area budget, process node, and clock period are not established in this document.
+
+PROPOSAL: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template.
+
+CONSIDERATION (clock and timing at 128× replication): If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (one 64-bit adder-equivalent) which is favorable; a non-pipelined iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter. The clock-skew analysis should be revisited at the integration level once the XH-1 clock tree is defined.
+
+CONSIDERATION (cross-core aggregate throughput): Under B1, each core's blocking DIV delivers ~1/33 divides per cycle. Across 128 cores, the aggregate is ~3.9 divides per cycle in the best case (all cores dividing simultaneously), which is the upper bound. Real workloads do not exhibit this worst case; the relevant metric is the per-core latency, not aggregate. INSUFFICIENT EVIDENCE on whether the XH-1 DPM or interconnect imposes a global cap on simultaneous divide activity; this is a system-level question outside the MUL/DIV unit's scope.
+
+CONSIDERATION (operand distribution and interconnect): Replicating a Wallace tree 128× implies 128 sets of wide operand buses to/from the register file. The interconnect / operand-routing network cost scales with the MUL operand width and the number of cores. PROPOSAL: include operand-routing overhead in the area estimate, not just the MUL/DIV datapath itself.
+
+## Performance Considerations
+
+PROPOSAL: **MUL throughput of 1/cycle is non-negotiable** for a modern XH-1 core. B1 satisfies this with a single 1-stage pipelined multiplier. B1' extends to 2/cycle for wide-issue.
+
+PROPOSAL: **DIV throughput of 1/~33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).
+
+ASSUMPTION: XH-1 target workloads include a mix consistent with Embench / SPECint-class profiles, where MUL/DIV instructions are a small fraction of dynamic instruction count. INSUFFICIENT EVIDENCE on the actual XH-1 target workload mix and on the specific dynamic-instruction share of MUL/DIV. The prior revision's "<2% MUL/DIV" and "<0.5% DIV/REM" FACT claims are removed as unsourced.
+
+OPEN QUESTION: Does XH-1 target HPC or ML workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3/B2 or a pipelined DIV (A2).
+
+## Area Considerations
+
+PROPOSAL: Budget the MUL/DIV unit at a small single-digit percentage of single-core area for the B1 design, pending synthesis. The exact percentage is INSUFFICIENT EVIDENCE.
+
+OPEN QUESTION: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.
+
+ASSUMPTION: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) and A4 (high-radix SRT) are larger, with A4 typically the largest. INSUFFICIENT EVIDENCE on the XH-1-specific gate-count budget.
+
+## Power and Energy Considerations
+
+FACT: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.
+
+PROPOSAL: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.
+
+PROPOSAL: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.
+
+OPEN QUESTION: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design (e.g., should the MUL unit support a "low-power divide" mode that takes 64 cycles at half frequency?).
+
+INSUFFICIENT EVIDENCE: Specific per-MUL or per-DIV energy numbers for the XH-1 process are not established. The prior revision's "single-digit pJ in 7 nm" claim is removed as unsourced; per-MUL energy in advanced processes is implementation-dependent and varies by an order of magnitude or more depending on architecture and clock frequency.
+
+## Implementation Considerations
+
+PROPOSAL: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget must accommodate the entire critical path from operand register → compressor tree → CPA → output register. ASSUMPTION: a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the target clock period. The specific tree depth and CPA depth are implementation-dependent and not asserted as fixed numbers here (the prior revision's "Tree depth 6–7; final CPA ~6 gates deep" is removed as unsourced and implementation-specific).
+
+PROPOSAL: For MULHSU (signed × unsigned), include a sign-handling stage (e.g., Booth encoding of the signed operand) before the partial-product reduction tree. A pure unsigned Wallace/Dadda tree does not handle the signed × unsigned case without this front-end.
+
+PROPOSAL: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 32 cycles for quotient bits + 1 cycle for finalization = ~33 cycles total. The remainder is the "running remainder" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.
+
+PROPOSAL: B5 (skip-on-zero): add a front-end detector on the DIV operands that forwards the result directly for divisor = ±1 or dividend = 0, bypassing the iterative loop. Trivial area; reduces effective DIV latency for common cases.
+
+PROPOSAL: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework. Note that WIDTH=32 does not by itself support the MULW instruction semantics in RV64 (which performs a 32×32→64 multiply and sign-extends the 32-bit result); an MULW-specific path is required for RV64.
+
+## Verification Considerations
+
+FACT: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions). For DIV/REM, the corner cases include the division-by-zero and signed-overflow rules defined in the ISA spec.
+
+PROPOSAL: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:
+- **Reference MUL**: SystemVerilog `bit [127:0]` (or DPI-C to a software bigint). Compare lower-64 and upper-64 separately. MULW, MULH, MULHU, MULHSU all share the 128-bit reference.
+- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec including the division-by-zero and signed-overflow rules for both quotient-producing and remainder-producing instructions.
+- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1), plus randomized large operands.
+- **Regression list size**: The prior revision's "64 hand-crafted corner cases" is removed as a specific number; the regression list should be sized to cover the documented corner cases and is grown as bugs are found. INSUFFICIENT EVIDENCE for a canonical count.
+
+PROPOSAL: At the 128-core replication level, **per-core functional verification** of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level (via a SystemVerilog generate block). This covers functional equivalence. **Per-core physical / timing verification is not bypassed**: timing, DFT, and physical-design closure are verified at the integration level on a representative core and assumed replicated, with explicit per-die variation analysis as required by the XH-1 physical-design flow.
+
+PROPOSAL: If the XH-1 verification flow includes formal property checking, the DIV correctness property ("quotient × divisor + remainder == dividend" within the RISC-V M extension's special cases) is a clean formal target and should be specified. INSUFFICIENT EVIDENCE on whether formal property checking is in scope.
+
+## Software Considerations
+
+PROPOSAL: Document the MUL/DIV latencies (1 cycle MUL, ~33 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.
+
+OPEN QUESTION: Does the XH-1 ABI / linker convention include a software-emulated division routine for code that cannot tolerate the ~33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one. The compiler can also apply divide-by-constant transformations (B6) to reduce effective hardware DIV frequency.
+
+PROPOSAL: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.
+
+PROPOSAL: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.
+
+## Recommendation
+
+**RECOMMENDATION: Adopt B1 — a hybrid MUL unit (1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Add B5 (skip-on-zero) at the DIV front end. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM. For wide-issue cores, scale to B1' (two MUL pipelines sharing one DIV).**
+
+Rationale:
+1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed).
+2. Keeps per-core area small, manageable at 128× replication.
+3. Avoids the verification burden of B3 (dual datapath) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).
+4. Aligns with proven reference designs (Rocket, Ibex) reducing architectural risk; this is an architectural-pattern alignment, not a claim of identical pipeline structure, since Rocket and BOOM use different organizations.
+5. B5 is a near-free improvement to the common case.
+
+This recommendation is **conditional on**:
+- The XH-1 target process supporting a 1-cycle 64×64→128 MUL critical path (must be validated by synthesis at the target corner; INSUFFICIENT EVIDENCE without target process specification).
+- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT) or a pipelined iterative divider.
+- The 128-core replication budget tolerating the cumulative MUL/DIV area; this requires a known single-core area budget, which is INSUFFICIENT EVIDENCE.
+
+If any of these conditions fails, re-open the design.
+
+## Confidence
+
+**Medium-High** for B1 as the baseline choice. **Low** for specific area, power, and energy numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are INSUFFICIENT EVIDENCE). The corrected version removes specific unsourced quantitative claims and demotes several prior FACTs to ASSUMPTION or INSUFFICIENT EVIDENCE.
+
+## Open Questions
+
+1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design.
+2. What is the XH-1 target workload mix? HPC, ML, cryptography, or general-purpose?
+3. Is the XH-1 core in-order, out-of-order, or hybrid? (The repository context does not yet establish this fact per the system policy.)
+4. Does XH-1 implement RV64B (bit-manipulation) extensions? The B extension does not naturally share the Wallace-tree multiplier datapath; any sharing is at the operand-mux and writeback layers, not the compressor tree.
+5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?
+6. Does XH-1 use a per-core DPM scheme that requires the MUL/DIV unit to support fine-grained power gating?
+7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM?
+8. Is there a software-emulated division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV? Will the compiler apply divide-by-constant transformations (B6)?
+9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's "quotient × divisor + remainder == dividend" property?
+10. For wide-issue cores, is B1' (two MUL pipelines + one shared DIV) the target, or is single-MUL B1 sufficient?
+11. What is the XH-1 interconnect / operand-routing cost of replicating a wide MUL operand bus 128 times? Should this overhead be included in the MUL/DIV unit's area budget?
+
+## Sources
+
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. (Canonical ISA reference; defines the M-extension corner-case rules for DIV/REM/DIVU/REMU/DIVW/REMW/DIVUW/REMUW and MULW.)
+- Asanović et al., "The Rocket Chip Generator," EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. (Reference for Rocket's MUL/DIV organization; configuration-dependent.)
+- Celio, Patterson, Asanović, "BOOM v2: a superscalar out-of-order processor," 2017. (Reference for BOOM's MUL/DIV design.)
+- Ibex documentation, lowRISC. (Reference for the in-order baseline.)
+- Chen et al., "XiangShan: An Open-Source High-Performance RISC-V Core," 2022. (Reference for high-performance RISC-V MUL/DIV design.)
+- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. (Reference for shift-subtract, SRT, and Newton-Raphson divide algorithms.)
+- Flynn, Oberman, *Advanced Computer Arithmetic Design*. (Reference for high-radix divider design.)
+- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. (Reference for Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process.)
+
+INSUFFICIENT EVIDENCE: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, energy, and timing are INSUFFICIENT EVIDENCE pending RTL implementation and target-process specification. Cortex-A77 per-instruction latencies are not publicly published by Arm and are INSUFFICIENT EVIDENCE from primary sources. The Intel Haswell integer divider is a radix-16 (or higher) shift-subtract divider, not a Newton-Raphson divider; Newton-Raphson is used in Haswell's floating-point unit.

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

@@ -0,0 +1,431 @@
+# MUL/DIV Unit
+
+## Status
+
+Stub — initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors identified in review, removes unsupported quantitative claims, reconciles internal contradictions, and adds missing alternatives.
+
+## Abstract
+
+This document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT, CLMUL, CLMULH, CLMULR). The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only a small percentage of a single core's area consumes a large cumulative area across the die when replicated 128 times. The unit's latency impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).
+
+## Research Question
+
+What is the optimal MUL/DIV unit organization for an XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, energy, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?
+
+## Background
+
+### RISC-V M Extension Semantics (RV64M)
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The RISC-V M extension for RV64 defines the following instructions:
+
+- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result, with sign-handling variations).
+- MULW: 32×32→32 bit product, then sign-extended to 64 bits and written to `rd`.
+- DIV, DIVU: 64÷64 signed/unsigned quotient.
+- REM, REMU: 64÷64 signed/unsigned remainder.
+- DIVW, DIVUW, REMW, REMUW: 32÷32 signed/unsigned quotient/remainder, sign-extended to 64 bits and written to `rd`.
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The M extension defines the following corner-case behavior:
+
+- Division by zero:
+  - `DIV` / `DIVW`: quotient is `2^XLEN − 1` (all bits set).
+  - `DIVU` / `DIVUW`: quotient is `2^XLEN − 1` (all bits set; the spec expresses this as the unsigned maximum, not as signed −1).
+  - `REM` / `REMW`: remainder equals the dividend.
+  - `REMU` / `REMUW`: remainder equals the dividend.
+- Signed overflow (most-negative integer divided by −1):
+  - `DIV` / `DIVW`: quotient equals the dividend (i.e., the most-negative representable value `2^(XLEN−1)`).
+  - `REM` / `REMW`: remainder equals zero.
+- For unsigned divide (`DIVU` / `REMU` / `DIVUW` / `REMUW`), the only defined special case is division by zero; the dividend / `−1` overflow case does not apply because the operands are unsigned.
+
+**NOTE**: A full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned.
+
+**NOTE**: MULHSU is implementable either (a) by sign-extending the signed operand and zero-extending the unsigned operand to 128 bits and using a signed multiplier, or (b) by using a modified-Booth-encoded signed multiplier with the unsigned operand zero-extended. Either approach requires explicit sign handling before the partial-product reduction tree; a pure unsigned Wallace/Dadda tree without a sign-handling front-end does not implement MULHSU correctly.
+
+**NOTE**: The W-suffixed instructions (MULW, DIVW, DIVUW, REMW, REMUW) are part of the **M extension** in RV64, not the base I extension. The base I extension's W variants are only the simple ALU ops (ADDW, SUBW, SLLW, SRLW, SRAW).
+
+**NOTE**: The carry-less multiply instructions CLMUL, CLMULH, and CLMULR are part of the standard Zbc extension (commonly grouped under the umbrella "B" extension in some profiling). They are not part of M. They require a different datapath (AND-tree with XOR reduction, no carry propagation) and are not the subject of this document except where they interact with operand muxes / writeback.
+
+### Latency Reference Points
+
+**FACT (Rocket Chip, UC Berkeley generator)**: Rocket Chip is in-order, and the MUL/DIV unit is configuration-dependent across Rocket's `Configs.scala` parameter set. In `RocketCoreConfig` (commonly cited as the default), the multiplier is pipelined with multiple pipeline stages (multi-cycle iterative, new operation accepted per cycle) and the divider is a radix-4 iterative divider. The exact stage counts and latencies are determined by parameters in `Configs.scala` and are not a single canonical value. INSUFFICIENT EVIDENCE for a specific latency number without naming the configuration.
+
+**FACT (BOOM v2/v3, UC Berkeley)**: Out-of-order superscalar. MUL is pipelined (latency configuration-dependent). DIV is variable-latency, non-pipelined.
+
+**FACT (XiangShan, open-source OoO RISC-V)**: MUL is pipelined; DIV is variable-latency, non-pipelined.
+
+**FACT (Ibex, lowRISC)**: In-order. MUL is implemented as a single-cycle or short-pipeline combinational multiplier in some configurations; iterative DIV.
+
+**INSUFFICIENT EVIDENCE**: Arm Cortex-A77 per-instruction MUL/DIV latencies are not publicly published by Arm. No specific numbers are cited from a primary source.
+
+**INSUFFICIENT EVIDENCE**: Intel Haswell integer divider internal radix (radix-16 vs. radix-32) is not established from publicly verifiable primary sources. The design is widely reported to be a high-radix shift-subtract divider rather than a Newton-Raphson divider, but the specific radix is INSUFFICIENT EVIDENCE.
+
+### Divide Algorithms
+
+**FACT**: Four primary classes are considered here:
+
+1. **Digit-recurrence / shift-subtract (radix-2, radix-4, radix-16, radix-64 SRT)**: radix-2 takes 64 cycles worst case; radix-4 takes ~32–33 cycles; radix-16 takes ~16 cycles; radix-64 takes ~8–10 cycles (with significant area/complexity cost). Iterative, small-to-moderate area depending on radix.
+2. **Newton-Raphson reciprocal multiplication**: multiple iterations of a multiply-based refinement to compute the reciprocal, then a final correction multiply to produce the quotient. Latency depends on initial seed precision and convergence criteria.
+3. **Goldschmidt**: similar convergence behavior to Newton-Raphson, with a different iteration structure.
+4. **CORDIC-based and series-expansion dividers**: rarely used for general-purpose integer divide due to overhead; exist as alternative approaches.
+
+**FACT**: The RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.
+
+## Existing Approaches
+
+### A1. Iterative Shift-Subtract Divider (Radix-2)
+
+- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, radix-2, 64-cycle worst case.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 divide per 64 cycles (not pipelined).
+- **MUL coverage**: A1 defines a divider only; MUL is not part of this organization.
+- **Area (DIV only)**: Smallest divider; typically a few kGE plus control. **INSUFFICIENT EVIDENCE** for a specific gate count.
+- **Power**: Lowest of the divider options when idle; minimal toggle rate per non-dividing cycle.
+- **Used in**: Some low-end in-order cores; some configurations of Rocket Chip with smaller radix.
+
+### A2. Pipelined Iterative Divider
+
+- **Datapath**: Two distinct subclasses must be distinguished:
+  - **(A2a) Pipelined iterative loop**: a single shift-subtract array with pipeline registers inserted at one or more points within the iterative loop, allowing a new operation to enter the loop every cycle after the pipeline is filled. Latency remains 64 cycles; throughput is 1 per cycle after fill.
+  - **(A2b) Fully unrolled divider**: 64 shift-subtract stages with pipeline registers between every stage, giving latency 64 cycles and throughput 1 per cycle from the first cycle. Area is roughly 64× the A1 datapath.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 per cycle (after fill for A2a; from cycle 1 for A2b).
+- **Area**: A2a is ~2–3× A1 (a few extra pipeline registers); A2b is roughly 64× A1 and is rarely used.
+- **Power**: Higher toggle rate than A1; only worthwhile under sustained divide streams.
+- **Used in**: Rare; mostly in high-throughput streaming dividers (DSP). Uncommon in general-purpose cores.
+
+### A3. Newton-Raphson Divider
+
+- **Datapath**: shared MUL unit(s), initial reciprocal seed ROM, multiplier used in iterative refinement and one final correction multiply.
+- **Latency breakdown**: seed table lookup (1 cycle) + N refinement multiplies (typically 2–3 iterations for 64-bit integer) + 1 final correction multiply. **ASSUMPTION**: 3 refinement iterations + 1 correction is typical for 64-bit; the concrete iteration count depends on seed precision and convergence criteria. **INSUFFICIENT EVIDENCE** for a single canonical iteration count without specifying the seed table and refinement schedule.
+- **Throughput**: one divide per (N+1) MUL cycles **only if the multiplier is dedicated to the divider**. If the multiplier is shared with the main MUL datapath, throughput is degraded by contention with MUL issue rate and is workload-dependent. **INSUFFICIENT EVIDENCE** for a single throughput number in the shared case.
+- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (sharing possible at the cost of contention); large.
+- **Power**: Higher static and dynamic (multiplier active during divide refinement).
+- **Used in**: Some high-performance FPU designs for floating-point; less common for dedicated integer divide.
+
+### A4. Radix-16 / Radix-64 SRT Divider
+
+- **Datapath**: high-radix recurrence with a quotient-digit lookup table (PLA or ROM), redundant remainder representation. 16 or 64 bits processed per cycle.
+- **DIV Latency**: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands.
+- **DIV Throughput**: 1 per cycle if pipelined; 1 per 16 / 8–10 cycles if iterative.
+- **Area**: large lookup table and complex datapath; PLA is a significant area contributor.
+- **Power**: high; many bits toggle per cycle.
+- **Used in**: high-end x86 integer dividers (radix of the integer divider is **INSUFFICIENT EVIDENCE** from primary sources; widely reported as high-radix shift-subtract rather than Newton-Raphson).
+
+### A5. Approximate / Lookup-Based Dividers (small operand ranges)
+
+- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.
+
+## Alternative Designs
+
+### B1. Hybrid MUL + Sequential-Iterative DIV (Rocket-style)
+
+- MUL: 64×64→128 pipelined in 1–2 stages (in Rocket's standard config, multi-stage; the 1-stage variant proposed for XH-1 is an aggressive target).
+- DIV: radix-4 iterative, ~33 cycles (32 cycles for quotient bits + finalization), blocking on the unit.
+- Single divider per core, 1–3 MUL pipeline stages.
+
+### B1'. Two MUL Pipelines + Shared Iterative DIV (wide-issue variant)
+
+- Two pipelined MUL datapaths, one shared radix-4 DIV datapath.
+- MUL throughput: 2/cycle (sustained, independent operands).
+- DIV throughput: 1 per ~33 cycles, shared and blocking.
+- Area: The "1.8–2.0× B1" multiplier in the prior revision is **INSUFFICIENT EVIDENCE** without a stated MUL:DIV area ratio. ASSUMING MUL and DIV are roughly comparable in area (a 1-stage MUL is a Wallace tree + 128-bit CPA; a radix-4 DIV is a 66-bit adder + control), the combined (MUL+DIV) area scales as 1 + (1/2) × 1 = 1.5× for two MULs + one shared DIV, but this is **INSUFFICIENT EVIDENCE** without a specific synthesis result. The correct qualitative statement is: roughly 1.4–2.0× B1 depending on assumed MUL:DIV area ratio.
+
+### B2. Combined MUL/MAC (Multiply-Accumulate) Unit
+
+- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).
+- Adds area over pure MUL; **INSUFFICIENT EVIDENCE** for a specific percentage.
+- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.
+
+### B3. Operand-Width-Detected 32-bit Fast MUL Path
+
+- Detect when both operands of a 64-bit MUL are sign- or zero-extended from 32 bits (i.e., bit 31 is replicated through bit 63), and route the multiplication through a 32×32→64 fast multiplier.
+- This is **distinct from MULW** (which is a separate instruction with 32-bit result semantics). B3 accelerates 64-bit MUL / MULH / MULHSU / MULHU when both operands happen to be 32-bit sign- or zero-extended, a pattern common after `lw` / `lwu` followed by arithmetic. MULW does not help this case because MULW is a different instruction.
+- Open question: whether the verification cost of the dual datapath is justified at the 128-core replication level.
+
+### B4. Bypassable Output with Operand Width Detection (full 64×64→128 only)
+
+- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.
+- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.
+- Disadvantage: no area saving.
+
+### B5. Skip-on-Zero / Divide-Cancellation Optimizations
+
+- Detect zero dividend (quotient is zero, remainder is dividend) and divide-by-one (quotient is dividend, remainder is zero) at the front end and forward the result without entering the iterative loop.
+- Saves latency in the common case for some workloads; trivial area overhead.
+- Composable with any divider organization.
+
+### B6. Software Divide-by-Constant Transformation (cross-cutting)
+
+- Compilers transform division by a **compile-time** constant into a multiply-by-reciprocal sequence. The hardware DIV is then needed only for division by variables.
+- Reduces effective DIV frequency significantly for workloads with constant denominators; affects hardware sizing decisions. **INSUFFICIENT EVIDENCE** for a quantitative reduction without a specific workload profile.
+
+### B7. Dedicated 32-bit Fast Divider for W-suffixed Instructions
+
+- Implement a separate 32-bit radix-2 or radix-4 iterative divider for DIVW / DIVUW / REMW / REMUW. The 32-bit divider has half the iteration count (32 or 16 cycles vs. 64 or 33 for the 64-bit divider) and roughly a quarter of the datapath area.
+- Useful if profiling shows W-suffixed divides dominate; in most general-purpose workloads they do not.
+- Verification cost: dual divider datapath, similar to B3.
+
+### B8. Combined MUL / DIV with Shared Partial-Product Array
+
+- Reuse the MUL's CSA compressor tree as the final correction multiplier for an SRT or Newton-Raphson divider, sharing the most area-intensive block.
+- Reduces the area penalty of A3 / A4 at the cost of tighter verification coupling between MUL and DIV paths.
+- Real architectural option in some high-performance designs; not considered in the prior revision.
+
+## Comparison
+
+| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |
+|--------|-------------|----------|-------------|----------|----------------------|----------------|--------------------------|
+| A1 (radix-2 iter. DIV only) | not defined in A1 | not defined in A1 | 64 cycles | 1 per 64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |
+| A2a (pipelined iter. loop) | not defined in A2a | not defined in A2a | 64 cycles | 1 per cycle (after fill) | INSUFFICIENT EVIDENCE | Med | Med |
+| A2b (fully unrolled) | not defined in A2b | not defined in A2b | 64 cycles | 1 per cycle | INSUFFICIENT EVIDENCE (very large) | High | High |
+| A3 (Newton-Raphson) | 1 cycle | 1 per cycle (dedicated) | N+1 MUL cycles (dedicated); workload-dep. if shared | INSUFFICIENT EVIDENCE (shared) | high | High | High |
+| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1 per cycle if pipelined | high | High | High |
+| B1 (Rocket-style) | 1–2 cycle (1-stage target) | 1 per cycle | ~33 cycles | 1 per 33 cycles | baseline | Low–Med | Low–Med |
+| B1' (2× MUL + 1× shared DIV) | 1–2 cycle | 2 per cycle | ~33 cycles | 1 per 33 cycles (shared) | ~1.4–2.0× B1 (INSUFFICIENT EVIDENCE; depends on MUL:DIV area ratio) | Med | Med |
+| B2 (+ MAC) | 1–2 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | +unspecified % over B1 (INSUFFICIENT EVIDENCE) | Med | Med |
+| B3 (32-bit fast MUL) | <1 cycle (32-bit path) | 1 per cycle | ~33 cycles | 1 per 33 cycles | +small (INSUFFICIENT EVIDENCE) | Low | Med–High (dual mode) |
+| B4 (full 64 only) | 1–2 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | same as B1 | Med | Lowest |
+| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |
+| B7 (32-bit fast DIV) | 1–2 cycle | 1 per cycle | ~16–17 cycles (32-bit) | 1 per 16–17 cycles (32-bit only) | +small (INSUFFICIENT EVIDENCE) | Low | Med–High (dual mode) |
+
+**ASSUMPTION**: Relative area figures are qualitative orderings based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are **INSUFFICIENT EVIDENCE** pending RTL implementation.
+
+## Advantages
+
+### A1 / B1
+- Smallest area; lowest per-core replication cost.
+- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).
+- Simpler verification; one mode of operation.
+- Well-understood reference implementation (Rocket, Ibex) for cross-checking.
+
+### A4 (High-Radix SRT)
+- Lowest DIV latency among the iterative-style options; competitive with A3 on a single divide.
+- Pipelined variant gives 1 per cycle DIV throughput.
+
+### A3 (Newton-Raphson)
+- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.
+- Amortizes multiplier cost if MAC (B2) is also desired.
+- Disadvantage: requires multiple refinement iterations; integer multiplier is large and contention with the main MUL datapath is a concern.
+
+### B2 (MAC)
+- Enables future-proofing for proposed bitmanip and MAC extensions.
+- Helpful for matrix multiplication kernels running across 128 cores.
+
+### B5 (Skip-on-Zero)
+- Negligible area; reduces effective DIV latency for common cases.
+
+### B7 (32-bit fast DIV)
+- Halves the divider iteration count for the W-suffixed instructions at modest area cost.
+
+### B8 (Shared MUL/DIV CSA)
+- Reduces the area penalty of high-performance dividers by sharing the most area-intensive block.
+
+## Disadvantages
+
+### A1 / B1
+- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall ~33 cycles per divide.
+- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.
+- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).
+
+### A3
+- Area at 128-core replication is severe; the multiplier is one of the largest blocks in a typical core.
+- Power: a 64×64 multiplier running 1 per cycle is one of the highest-power blocks in a typical core.
+- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.
+- If multiplier is shared with main MUL datapath, throughput is workload-dependent, not the N+1 figure cited for the dedicated case.
+
+### A4
+- Large lookup table (PLA or ROM); area and power dominated by the table.
+- Verification: complex quotient-digit selection logic.
+- Not commonly used outside high-end commercial designs.
+
+### B3
+- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.
+- The classification logic (operand-width detection) is itself a source of corner-case bugs.
+- **B3 does not subsume MULW**; MULW is a separate instruction and B3 is about 64-bit MUL on 32-bit-valued operands.
+
+### B2
+- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.
+
+### B5
+- Only helps the specific cases of zero dividend or divisor ±1; other optimizations (e.g., division by small powers of two) are already handled by the base I extension's shift instructions.
+
+### B7
+- Verification: dual divider datapath; same concerns as B3.
+- Area saving is moot if W-suffixed divides are not on the critical path.
+
+### B8
+- Verification: tighter coupling between MUL and DIV paths makes corner-case analysis more difficult.
+
+## XH-1 Considerations
+
+**PROPOSAL**: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:
+
+- **MUL**: 64×64→128, target 1-cycle pipelined (1 stage of pipeline registers), throughput 1 per cycle. For 2-issue or wider cores, scale to B1' (two MUL pipelines sharing one DIV).
+- **DIV**: Radix-4 shift-subtract, ~33 cycles worst case (32 cycles for quotient bits + finalization), blocking, non-pipelined. The prior revision's "33–35 cycles worst case" and the "33–64 cycle" range are reconciled here: 33 is the radix-4 bound; 64 corresponds to radix-2, which is a different algorithm choice.
+- **REM**: Reuse the DIV datapath; remainder is a by-product.
+- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle. **INSUFFICIENT EVIDENCE** on whether this fits the XH-1 pipeline depth; depends on the integration context.
+- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead.
+- **Operand-width detection**: Defer B3 to a future revision; not justified at the 128-core replication level given the added verification cost and the existence of MULW for the 32-bit-case instruction.
+- **B7 (32-bit fast DIV)**: Defer; the W-suffixed divide is not assumed to be on the critical path. Revisit if profiling shows otherwise.
+
+**ASSUMPTION**: A 1-cycle MUL latency is achievable in the target process. **INSUFFICIENT EVIDENCE** on the XH-1 target process node and clock period. A full 64×64→128 Wallace/Dadda tree + 128-bit carry-propagate adder in a single cycle is at the edge of feasibility for high-performance designs; typical in-order cores implement MUL as either a multi-cycle iterative multiplier or a multi-stage pipelined multiplier. **PROPOSAL**: Validate via synthesis at the target corner before committing. If the 1-cycle critical path cannot be closed, **fallback options** are:
+  - **B1-fallback-A**: 2-cycle pipelined MUL (split the compressor tree and the final CPA across two pipeline stages); latency 2 cycles, throughput 1 per cycle, modest area overhead.
+  - **B1-fallback-B**: Multi-cycle iterative MUL (Booth-encoded, ~4–8 cycles for 64×64→128); lower area, lower throughput, higher latency.
+  - **B1-fallback-C**: Retain the 1-stage MUL architecture but lower the target clock frequency (system-level decision, not unit-level).
+
+**PROPOSAL**: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1, or 2 in the fallback) and variable-latency DIV (~33).
+
+**PROPOSAL**: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.
+
+**PROPOSAL**: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.
+
+**PROPOSAL**: The B-extension unit (if RV64B is implemented) shares **operand muxes, sign-handling logic, and bit-level muxes** with the MUL/DIV unit but does **not** share the Wallace/Dadda compressor tree. Operations like CLZ, CTZ, BSET, BEXT operate on individual bits or small bit-fields and do not naturally map onto a Wallace-tree multiplier datapath. CLMUL / CLMULH / CLMULR (Zbc) require an AND-tree / XOR-reduction datapath that is structurally distinct from both the Wallace-tree multiplier and the iterative divider; they do not share the compressor tree. Any apparent sharing is at the operand-fetch and writeback layers, not the core arithmetic.
+
+## 128-Core Scalability
+
+The 128-core replication factor is the dominant cost driver for the MUL/DIV unit.
+
+**PROPOSAL**: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.
+
+**PROPOSAL**: The MUL/DIV unit's reservation-station entries, divider iteration state, and pipeline registers must support **state retention or clean-state entry** across power gating. Specifically, when a core is power-gated while a long-latency DIV is in flight, the DIV's mid-iteration state must be either (a) flushed (architecturally equivalent to a DIV that completes with the wrong value, which is not acceptable), or (b) checkpointed to a retention register or to memory, or (c) prevented from power-gating until the DIV completes. The choice depends on the XH-1 DPM policy. **INSUFFICIENT EVIDENCE** on the XH-1 DPM policy; the design must accommodate one of these options without committing to a specific approach here.
+
+**OPEN QUESTION**: What is the actual MUL/DIV area share of the XH-1 core? Published RISC-V references suggest a typical MUL unit occupies a small single-digit percentage of a high-performance core's area, with iterative DIV adding additional area. The prior revision's "1–3%" and "1 MGE/core total" baseline are removed here as unsourced. **INSUFFICIENT EVIDENCE** on the XH-1-specific area share without synthesis.
+
+**OPEN QUESTION**: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.
+
+**INSUFFICIENT EVIDENCE**: The XH-1 die-area budget, process node, and clock period are not established in this document.
+
+**PROPOSAL**: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template. **PROPOSAL**: The generate block itself must be included in the verification scope (not assumed trivially correct). At minimum: a lint-clean check, a synthesis-check that the generate block instantiates the correct number of cores, and a per-instance equivalence check on a sample of cores.
+
+**PROPOSAL**: For 128× replicated MUL/DIV pipeline registers, ECC or parity protection should be considered for soft-error mitigation. **INSUFFICIENT EVIDENCE** on the XH-1 reliability target.
+
+**PROPOSAL**: Reset distribution and scan chain architecture for 128× replicated MUL/DIV must be addressed at the integration level. The MUL/DIV unit's scan chains should support parallel or staggered scan-shift across cores to keep test time bounded. **INSUFFICIENT EVIDENCE** on the XH-1 DFT architecture.
+
+**CONSIDERATION (clock and timing at 128× replication)**: If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (one 64-bit adder-equivalent) which is favorable; a non-pipelined iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter. The clock-skew analysis should be revisited at the integration level once the XH-1 clock tree is defined.
+
+**CONSIDERATION (cross-core aggregate throughput)**: Under B1, each core's blocking DIV delivers ~1 per 33 cycles per core. Across 128 cores, the aggregate is ~3.9 divides per cycle in the best case (all cores dividing simultaneously), which is the upper bound. Real workloads do not exhibit this worst case; the relevant metric is the per-core latency, not aggregate. **INSUFFICIENT EVIDENCE** on whether the XH-1 DPM or interconnect imposes a global cap on simultaneous divide activity; this is a system-level question outside the MUL/DIV unit's scope.
+
+**CONSIDERATION (operand distribution and interconnect)**: Replicating a Wallace tree 128× implies 128 sets of wide operand buses to/from the register file. The interconnect / operand-routing network cost scales with the MUL operand width and the number of cores. **PROPOSAL**: include operand-routing overhead in the area estimate, not just the MUL/DIV datapath itself.
+
+## Performance Considerations
+
+**PROPOSAL**: **MUL throughput of 1 per cycle is a target for a high-performance XH-1 core**, but is not architecturally non-negotiable. Low-end in-order cores (some Ibex configurations) implement MUL with throughput < 1 per cycle. B1 satisfies the high-performance target with a 1-stage pipelined multiplier; B1' extends to 2 per cycle for wide-issue. If the 1-cycle MUL cannot be closed at the target process, the throughput target remains 1 per cycle but the latency becomes 2 cycles (B1-fallback-A).
+
+**PROPOSAL**: **DIV throughput of 1 per ~33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).
+
+**ASSUMPTION**: XH-1 target workloads include a mix consistent with Embench / SPECint-class profiles, where MUL/DIV instructions are a small fraction of dynamic instruction count. **INSUFFICIENT EVIDENCE** on the actual XH-1 target workload mix and on the specific dynamic-instruction share of MUL/DIV. The prior revision's "<2% MUL/DIV" and "<0.5% DIV/REM" claims are removed as unsourced.
+
+**OPEN QUESTION**: Does XH-1 target HPC or cryptography workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3, A4, or A2. **NOTE**: ML workloads are dominated by floating-point multiplies on the FPU, not by integer MUL/DIV; integer MUL/DIV is relevant to ML only for quantization, address arithmetic, and integer embeddings.
+
+## Area Considerations
+
+**PROPOSAL**: Budget the MUL/DIV unit at a small single-digit percentage of single-core area for the B1 design, pending synthesis. The exact percentage is **INSUFFICIENT EVIDENCE**.
+
+**OPEN QUESTION**: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.
+
+**ASSUMPTION**: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) and A4 (high-radix SRT) are larger, with A4 typically the largest. **INSUFFICIENT EVIDENCE** on the XH-1-specific gate-count budget.
+
+## Power and Energy Considerations
+
+**FACT**: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.
+
+**PROPOSAL**: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.
+
+**PROPOSAL**: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.
+
+**OPEN QUESTION**: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design.
+
+**INSUFFICIENT EVIDENCE**: Specific per-MUL or per-DIV energy numbers for the XH-1 process are not established. The prior revision's "single-digit pJ in 7 nm" claim is removed as unsourced; per-MUL energy in advanced processes is implementation-dependent and varies by an order of magnitude or more depending on architecture and clock frequency.
+
+## Implementation Considerations
+
+**PROPOSAL**: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget must accommodate the entire critical path from operand register → compressor tree → CPA → output register. **INSUFFICIENT EVIDENCE** on whether a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the XH-1 target clock period; the specific tree depth and CPA depth are implementation-dependent and not asserted as fixed numbers here. The prior revision's "Tree depth 6–7; final CPA ~6 gates deep" is removed as unsourced and implementation-specific.
+
+**PROPOSAL**: For MULHSU, the front-end sign-handling stage should sign-extend the signed operand to 128 bits and zero-extend the unsigned operand, then feed a signed multiplier; alternatively, use a modified-Booth-encoded signed multiplier with the unsigned operand zero-extended. Either approach requires explicit sign handling before the partial-product reduction tree.
+
+**PROPOSAL**: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 32 cycles for quotient bits + 1 cycle for finalization = ~33 cycles total. The remainder is the "running remainder" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.
+
+**PROPOSAL**: B5 (skip-on-zero): add a front-end detector on the DIV operands that forwards the result directly for divisor = ±1 or dividend = 0, bypassing the iterative loop. Trivial area; reduces effective DIV latency for common cases.
+
+**PROPOSAL**: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework. Note that WIDTH=32 does not by itself support the MULW instruction semantics in RV64 (which performs a 32×32→64 multiply and sign-extends the 32-bit result); an MULW-specific path is required for RV64.
+
+## Verification Considerations
+
+**FACT**: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions). For DIV/REM, the corner cases include the division-by-zero and signed-overflow rules defined in the ISA spec.
+
+**PROPOSAL**: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:
+- **Reference MUL**: SystemVerilog `bit [127:0]` (or DPI-C to a software bigint). Compare lower-64 and upper-64 separately. MULW, MULH, MULHU, MULHSU all share the 128-bit reference.
+- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec, including the division-by-zero and signed-overflow rules for both quotient-producing and remainder-producing instructions.
+- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1), plus randomized large operands.
+- **Regression list size**: The prior revision's "64 hand-crafted corner cases" is removed as a specific number; the regression list should be sized to cover the documented corner cases and is grown as bugs are found. **INSUFFICIENT EVIDENCE** for a canonical count.
+
+**PROPOSAL**: At the 128-core replication level, **per-core functional verification** of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level (via a SystemVerilog generate block). This covers functional equivalence at the unit level. **However**, the verification of the generate block itself, and the interaction between per-core clock-gating / power-state and MUL/DIV state (e.g., does a clock-gated MUL lose its pipeline state correctly across gating? does a power-gated divider leave the iteration counter in a valid state for resumption?), must be verified explicitly. **Per-core physical / timing verification is not bypassed**: timing, DFT, and physical-design closure are verified at the integration level on a representative core and assumed replicated, with explicit per-die variation analysis as required by the XH-1 physical-design flow.
+
+**PROPOSAL**: If the XH-1 verification flow includes formal property checking, the DIV correctness property ("quotient × divisor + remainder == dividend" within the RISC-V M extension's special cases) is a clean formal target and should be specified. **INSUFFICIENT EVIDENCE** on whether formal property checking is in scope.
+
+## Software Considerations
+
+**PROPOSAL**: Document the MUL/DIV latencies (1 cycle MUL, ~33 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.
+
+**OPEN QUESTION**: Does the XH-1 ABI / linker convention include a software-emulated division routine for code that cannot tolerate the ~33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one. The compiler can also apply divide-by-constant transformations (B6) to reduce effective hardware DIV frequency.
+
+**PROPOSAL**: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.
+
+**PROPOSAL**: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.
+
+## Recommendation
+
+**RECOMMENDATION**: Adopt **B1** — a hybrid MUL unit (target 1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Add **B5** (skip-on-zero) at the DIV front end. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM. For wide-issue cores, scale to **B1'** (two MUL pipelines sharing one DIV).
+
+Rationale:
+1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed for high-performance targets).
+2. Keeps per-core area small, manageable at 128× replication.
+3. Avoids the verification burden of B3 (dual datapath) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).
+4. Aligns with the architectural pattern of proven reference designs (Rocket, Ibex); the alignment is on the radix-4 iterative divider + pipelined multiplier pattern, not on a specific pipeline depth, since Rocket's MUL is multi-stage in standard config and Ibex's MUL is short-pipeline / combinational.
+5. B5 is a near-free improvement to the common case.
+
+**Fallback plan** (if the 1-cycle MUL cannot be closed at the target process / clock):
+- **Primary fallback**: B1-fallback-A — 2-cycle pipelined MUL. Latency 2 cycles, throughput 1 per cycle, modest area overhead. B1 architecture preserved.
+- **Secondary fallback**: B1-fallback-B — multi-cycle iterative MUL (Booth-encoded, ~4–8 cycles). Lower area, lower throughput, higher latency. DIV remains radix-4 iterative.
+- **Tertiary fallback**: Lower the target clock frequency at the system level.
+
+This recommendation is **conditional on**:
+- The XH-1 target process supporting either a 1-cycle 64×64→128 MUL critical path (primary) or a 2-cycle pipelined MUL critical path (fallback A) at the target clock. Both must be validated by synthesis at the target corner; **INSUFFICIENT EVIDENCE** without target process specification.
+- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT) or a pipelined iterative divider (A2a), and/or consider B8 (shared MUL/DIV CSA).
+- The 128-core replication budget tolerating the cumulative MUL/DIV area; this requires a known single-core area budget, which is **INSUFFICIENT EVIDENCE**.
+- A clear DPM policy for handling in-flight MUL/DIV state across power gating.
+
+If any of these conditions fails, re-open the design against the named fallback.
+
+## Confidence
+
+**Medium-High** for B1 as the baseline architectural pattern. **Low** for specific area, power, and energy numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are **INSUFFICIENT EVIDENCE**). The corrected version removes specific unsourced quantitative claims and demotes several prior FACTs to ASSUMPTION or INSUFFICIENT EVIDENCE.
+
+## Open Questions
+
+1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design and determines whether 1-cycle MUL is feasible.
+2. What is the XH-1 target workload mix? HPC, cryptography, or general-purpose? (ML is not primarily an integer MUL/DIV workload.)
+3. Is the XH-1 core in-order, out-of-order, or hybrid?
+4. Does XH-1 implement RV64B (bit-manipulation) extensions, including Zbc (CLMUL / CLMULH / CLMULR)? The B extension does not naturally share the Wallace-tree multiplier datapath; any sharing is at the operand-mux and writeback layers, not the compressor tree.
+5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?
+6. Does XH-1 use a per-core DPM scheme, and how does it handle in-flight MUL/DIV state across power gating (retention, flush-and-replay, or block-power-gate-until-completion)?
+7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM (or RV64IMB)?
+8. Is there a software-emulated division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV? Will the compiler apply divide-by-constant transformations (B6)?
+9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's "quotient × divisor + remainder == dividend" property?
+10. For wide-issue cores, is B1' (two MUL pipelines + one shared DIV) the target, or is single-MUL B1 sufficient?
+11. What is the XH-1 interconnect / operand-routing cost of replicating a wide MUL operand bus 128 times? Should this overhead be included in the MUL/DIV unit's area budget?
+12. What is the XH-1 reliability target? Does the MUL/DIV pipeline require ECC or parity protection against soft errors?
+13. What is the XH-1 DFT architecture for the 128× replicated MUL/DIV scan chains?
+
+## Sources
+
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. Canonical ISA reference; defines the M-extension corner-case rules for DIV/REM/DIVU/REMU/DIVW/REMW/DIVUW/REMUW and MULW.
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA*, Chapter 16 (B Extension, including Zbc). Canonical ISA reference for CLMUL / CLMULH / CLMULR.
+- Asanović et al., "The Rocket Chip Generator," EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. Reference for Rocket's MUL/DIV organization; configuration-dependent.
+- Celio, Patterson, Asanović, "BOOM v2: a superscalar out-of-order processor," 2017. Reference for BOOM's MUL/DIV design.
+- Ibex documentation, lowRISC. Reference for the in-order baseline.
+- Chen et al., "XiangShan: An Open-Source High-Performance RISC-V Core," 2022. Reference for high-performance RISC-V MUL/DIV design.
+- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. Reference for shift-subtract, SRT, and Newton-Raphson divide algorithms.
+- Flynn, Oberman, *Advanced Computer Arithmetic Design*. Reference for high-radix divider design.
+- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. Reference for Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process.
+
+**INSUFFICIENT EVIDENCE**: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, energy, and timing are **INSUFFICIENT EVIDENCE** pending RTL implementation and target-process specification. Cortex-A77 per-instruction latencies are not publicly published by Arm and are **INSUFFICIENT EVIDENCE** from primary sources. The internal radix of the Intel Haswell integer divider is widely reported as high-radix shift-subtract rather than Newton-Raphson, but the specific radix (16 vs. 32) is **INSUFFICIENT EVIDENCE** from primary sources; Newton-Raphson is reported to be used in Haswell's floating-point unit.

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

@@ -0,0 +1,505 @@
+# MUL/DIV Unit
+
+## Status
+
+Revision 2. Initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors identified in review, removes unsupported quantitative claims, reconciles internal contradictions, and adds missing alternatives.
+
+## Abstract
+
+This document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT, CLMUL, CLMULH, CLMULR). The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only a small percentage of a single core's area consumes a large cumulative area across the die when replicated 128 times. The unit's latency impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).
+
+## Research Question
+
+What is the optimal MUL/DIV unit organization for an XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, energy, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?
+
+## Background
+
+### RISC-V M Extension Semantics (RV64M)
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The RISC-V M extension for RV64 defines the following instructions:
+
+- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result, with sign-handling variations).
+- MULW: 32×32→32 bit product, then sign-extended to 64 bits and written to `rd`.
+- DIV, DIVU: 64÷64 signed/unsigned quotient.
+- REM, REMU: 64÷64 signed/unsigned remainder.
+- DIVW, DIVUW, REMW, REMUW: 32÷32 signed/unsigned quotient/remainder, sign-extended to 64 bits and written to `rd`.
+
+**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The M extension defines the following corner-case behavior:
+
+- Division by zero:
+  - `DIV` / `DIVW`: quotient is `−1` (the architectural definition; the bit pattern is `2^XLEN − 1`, all bits set).
+  - `DIVU` / `DIVUW`: quotient is `2^XLEN − 1` (all bits set, which equals `−1` in two's complement representation).
+  - The signed and unsigned cases produce the same bit pattern at the architectural level; the spec writes `−1` for the signed case and the unsigned maximum for the unsigned case, but these are bit-pattern-identical.
+  - `REM` / `REMW`: remainder equals the dividend.
+  - `REMU` / `REMUW`: remainder equals the dividend.
+- Signed overflow (most-negative integer divided by −1):
+  - `DIV` / `DIVW`: quotient equals the dividend (i.e., the most-negative representable value `2^(XLEN−1)`).
+  - `REM` / `REMW`: remainder equals zero.
+- For unsigned divide (`DIVU` / `REMU` / `DIVUW` / `REMUW`), the only defined special case is division by zero; the dividend / `−1` overflow case does not apply because the operands are unsigned.
+
+**NOTE**: A full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned.
+
+**NOTE** (MULHSU implementation): MULHSU computes the upper 64 bits of a signed×unsigned 64×64 product. A correct implementation generates a partial-product array for 64×64 bits where the unsigned operand's partial products are zero in the upper half of its bit positions and the signed operand's partial products use signed (sign-extended) rows in the final reduction. Two concrete implementation paths exist:
+
+- (a) Use a signed multiplier datapath: sign-extend the signed operand to 128 bits, zero-extend the unsigned operand to 128 bits, and run a signed 128×128 multiply, then take the upper 64 bits. This is straightforward but doubles the multiplier width and is rarely used.
+- (b) The standard approach: zero-extend the unsigned operand to 64 bits (its bit positions are already non-negative), sign-extend the signed operand only in the final partial-product row, and reduce the 64×64 partial-product array with a final row sign-extension. This requires a modified-Booth or array multiplier with explicit sign handling on the last partial-product row.
+
+A pure unsigned Wallace/Dadda tree without a sign-handling front-end does not implement MULHSU correctly, because the signed operand's most significant partial-product row must be sign-extended (or its inverted-and-carry form added) into the reduction tree.
+
+**NOTE**: The W-suffixed instructions (MULW, DIVW, DIVUW, REMW, REMUW) are part of the **M extension** in RV64, not the base I extension. The base I extension's W variants are only the simple ALU ops (ADDW, SUBW, SLLW, SRLW, SRAW).
+
+**NOTE**: MULW is implementable on a 32×32→64-bit datapath: the 32-bit product is sign-extended to 64 bits and written to `rd`. The upper 32 bits of the 64-bit intermediate result are discarded. A 32×32→64-bit fast multiplier (B3 datapath) can therefore implement MULW by taking its lower 32 bits and sign-extending to 64.
+
+**NOTE**: The carry-less multiply instructions CLMUL, CLMULH, and CLMULR are part of the standard Zbc extension (commonly grouped under the umbrella "B" extension in some profiling). They are not part of M. They require a different datapath (AND-tree with XOR reduction, no carry propagation) and are not the subject of this document except where they interact with operand muxes / writeback. CLMULR in particular produces a 2·XLEN-bit result with explicit carry-in/carry-out behavior across the two halves; its implementation shares the AND-tree with CLMUL/CLMULH but adds a dedicated reduction stage for the carry path.
+
+### Latency Reference Points
+
+**FACT (Rocket Chip, UC Berkeley generator)**: Rocket Chip is in-order, and the MUL/DIV unit is configuration-dependent across Rocket's `Configs.scala` parameter set. In `RocketCoreConfig` (commonly cited as the default), the multiplier is pipelined with multiple pipeline stages (multi-cycle iterative, new operation accepted per cycle) and the divider is a radix-4 iterative divider. The exact stage counts and latencies are determined by parameters in `Configs.scala` and are not a single canonical value. INSUFFICIENT EVIDENCE for a specific latency number without naming the configuration.
+
+**FACT (BOOM v2/v3, UC Berkeley)**: Out-of-order superscalar. MUL is pipelined (latency configuration-dependent). DIV is variable-latency, non-pipelined.
+
+**FACT (XiangShan, open-source OoO RISC-V)**: MUL is pipelined; DIV is variable-latency, non-pipelined.
+
+**FACT (Ibex, lowRISC)**: In-order. MUL is implemented as a single-cycle or short-pipeline combinational multiplier in some configurations; iterative DIV.
+
+**INSUFFICIENT EVIDENCE**: Arm Cortex-A77 per-instruction MUL/DIV latencies are not publicly published by Arm. No specific numbers are cited from a primary source.
+
+**INSUFFICIENT EVIDENCE**: Intel Haswell integer divider internal radix (radix-16 vs. radix-32) is not established from publicly verifiable primary sources. The design is widely reported to be a high-radix shift-subtract divider rather than a Newton-Raphson divider, but the specific radix is INSUFFICIENT EVIDENCE.
+
+### Divide Algorithms
+
+**FACT**: Four primary classes are considered here:
+
+1. **Digit-recurrence / shift-subtract (radix-2, radix-4, radix-16, radix-64 SRT)**: radix-2 takes 64 cycles worst case; radix-4 takes ~32–33 cycles; radix-16 takes ~16 cycles; radix-64 takes ~8–10 cycles (with significant area/complexity cost). Iterative, small-to-moderate area depending on radix.
+2. **Newton-Raphson reciprocal multiplication**: multiple iterations of a multiply-based refinement to compute the reciprocal, then a final correction multiply to produce the quotient. Latency depends on initial seed precision and convergence criteria.
+3. **Goldschmidt**: similar convergence behavior to Newton-Raphson, with a different iteration structure.
+4. **CORDIC-based and series-expansion dividers**: rarely used for general-purpose integer divide due to overhead; exist as alternative approaches.
+
+**FACT**: The RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.
+
+## Existing Approaches
+
+### A1. Iterative Shift-Subtract Divider (Radix-2)
+
+- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, radix-2, 64-cycle worst case.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 divide per 64 cycles (not pipelined).
+- **MUL coverage**: A1 defines a divider only; MUL is not part of this organization.
+- **Area (DIV only)**: Smallest divider; typically a few kGE plus control. **INSUFFICIENT EVIDENCE** for a specific gate count.
+- **Power**: Lowest of the divider options when idle; minimal toggle rate per non-dividing cycle.
+- **Used in**: Some low-end in-order cores; some configurations of Rocket Chip with smaller radix.
+
+### A2. Pipelined Iterative Divider
+
+- **Datapath**: Two distinct subclasses must be distinguished:
+  - **(A2a) Pipelined iterative loop**: a single shift-subtract array with pipeline registers inserted at one or more points within the iterative loop, allowing a new operation to enter the loop every cycle after the pipeline is filled. Latency remains 64 cycles; throughput is 1 per cycle after fill.
+  - **(A2b) Fully unrolled divider**: 64 shift-subtract stages with pipeline registers between every stage, giving latency 64 cycles and throughput 1 per cycle from the first cycle. Area is roughly 64× the A1 datapath.
+- **DIV Latency**: 64 cycles.
+- **DIV Throughput**: 1 per cycle (after fill for A2a; from cycle 1 for A2b).
+- **Area**: A2a is ~2–3× A1 (a few extra pipeline registers); A2b is roughly 64× A1 and is rarely used.
+- **Power**: Higher toggle rate than A1; only worthwhile under sustained divide streams.
+- **Used in**: Rare; mostly in high-throughput streaming dividers (DSP). Uncommon in general-purpose cores.
+
+### A3. Newton-Raphson Divider
+
+- **Datapath**: shared MUL unit(s), initial reciprocal seed ROM, multiplier used in iterative refinement and one final correction multiply.
+- **Latency breakdown**: seed table lookup (1 cycle) + N refinement multiplies (typically 2–3 iterations for 64-bit integer) + 1 final correction multiply. **ASSUMPTION**: 3 refinement iterations + 1 correction is typical for 64-bit; the concrete iteration count depends on seed precision and convergence criteria. **INSUFFICIENT EVIDENCE** for a single canonical iteration count without specifying the seed table and refinement schedule.
+- **Throughput**: one divide per (N+1) MUL cycles **only if the multiplier is dedicated to the divider**. If the multiplier is shared with the main MUL datapath, throughput is degraded by contention with MUL issue rate and is workload-dependent. **INSUFFICIENT EVIDENCE** for a single throughput number in the shared case.
+- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (sharing possible at the cost of contention); large.
+- **Power**: Higher static and dynamic (multiplier active during divide refinement).
+- **Used in**: Some high-performance FPU designs for floating-point; less common for dedicated integer divide.
+
+### A4. Radix-16 / Radix-64 SRT Divider
+
+- **Datapath**: high-radix recurrence with a quotient-digit lookup table (PLA or ROM), redundant remainder representation. 16 or 64 bits processed per cycle.
+- **DIV Latency**: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands.
+- **DIV Throughput**: 1 per cycle if pipelined; 1 per 16 / 8–10 cycles if iterative.
+- **Area**: large lookup table and complex datapath; PLA is a significant area contributor.
+- **Power**: high; many bits toggle per cycle.
+- **Used in**: high-end x86 integer dividers (radix of the integer divider is **INSUFFICIENT EVIDENCE** from primary sources; widely reported as high-radix shift-subtract rather than Newton-Raphson).
+
+### A5. Approximate / Lookup-Based Dividers (small operand ranges)
+
+- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.
+
+## Alternative Designs
+
+### B1. Hybrid MUL + Sequential-Iterative DIV (radix-4 iterative divider, custom MUL)
+
+- MUL: 64×64→128 pipelined in 1 stage (target), throughput 1 per cycle. This departs from Rocket Chip's default multi-stage MUL (Rocket's `RocketCoreConfig` issues MUL as a multi-cycle iterative operation); the 1-stage MUL is an aggressive target for XH-1.
+- DIV: radix-4 iterative, ~33 cycles (32 cycles for quotient bits + finalization), blocking on the unit.
+- Single divider per core, 1 MUL pipeline stage.
+
+**NOTE on naming**: B1 inherits the radix-4 iterative divider pattern from Rocket and Ibex, but the MUL organization (1-stage pipelined) is a custom choice that does not match either Rocket's multi-stage MUL or Ibex's short-pipeline / combinational MUL. The "hybrid" descriptor refers to combining a pipelined MUL with an iterative DIV; the divider side aligns with reference designs, the MUL side does not.
+
+### B1'. Two MUL Pipelines + Shared Iterative DIV (wide-issue variant)
+
+- Two pipelined MUL datapaths, one shared radix-4 DIV datapath.
+- MUL throughput: 2/cycle (sustained, independent operands).
+- DIV throughput: 1 per ~33 cycles, shared and blocking.
+- **Area**: ASSUMING a MUL:DIV area ratio of approximately 1:1 (i.e., one MUL pipeline and one radix-4 iterative DIV are roughly comparable in area, since a 1-stage 64×64 MUL is a Wallace/Dadda tree plus a 128-bit CPA, and a radix-4 iterative DIV is a ~66-bit adder plus control state), the combined (MUL+DIV) area scales as 1 + 1 = 2× B1 (two MULs plus one shared DIV, where B1 has one MUL and one DIV). The 1.5× figure previously cited assumed MUL is half the area of DIV, which is unsupported. The 1.4× lower bound previously cited is unsupported. The corrected qualitative statement is: **~2× B1**, with the explicit MUL:DIV area ratio assumption stated. **INSUFFICIENT EVIDENCE** for a synthesis-derived number.
+
+### B2. Combined MUL/MAC (Multiply-Accumulate) Unit
+
+- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).
+- Adds area over pure MUL; **INSUFFICIENT EVIDENCE** for a specific percentage.
+- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.
+
+### B3. Operand-Width-Detected 32-bit Fast MUL Path (also serves MULW)
+
+- Detect when both operands of a 64-bit MUL are sign- or zero-extended from 32 bits (i.e., bit 31 is replicated through bit 63), and route the multiplication through a 32×32→64 fast multiplier.
+- The same 32×32→64 datapath also implements MULW directly: the 32-bit product (lower 32 bits of the 64-bit result) is sign-extended to 64 bits and written to `rd`. This sharing is essentially free in area terms and means that adopting B3 is the natural way to implement MULW.
+- This is **distinct from MULW as a workaround** for the 32-bit-case: B3 accelerates 64-bit MUL / MULH / MULHSU / MULHU when both operands happen to be 32-bit sign- or zero-extended, a pattern common after `lw` / `lwu` followed by arithmetic. MULW alone does not accelerate this case because MULW is a different instruction with different result semantics.
+- **Position**: B3 is the natural choice for the MULW datapath and adds a 32-bit-extended-operand fast path for 64-bit MUL. The verification cost is the dual datapath (32-bit and 64-bit) and the operand-width classifier. At the 128-core replication level, the area overhead is bounded by the 32-bit datapath size, which is much smaller than the 64-bit datapath; the dominant question is verification cost, not area.
+- **Decision**: B3 is recommended as part of the MULW implementation; deferring B3 means deferring the natural MULW implementation, which is not viable if MULW is in the ISA. The B3-vs-B4 trade-off therefore applies to the 32-bit-extended-operand fast path, not to MULW support.
+
+### B4. Bypassable Output with Operand Width Detection (full 64×64→128 only)
+
+- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.
+- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.
+- Disadvantage: no area saving; MULW must still be implemented separately (e.g., via B3 or a dedicated 32×32→32 path).
+- **Position**: B4 conflicts with the natural MULW-via-B3 sharing above; if MULW is required, B4 is not a complete solution. If MULW is not required, B4 simplifies verification at the cost of a slightly larger MUL datapath for MULW-equivalent work.
+
+### B5. Skip-on-Zero / Divide-Cancellation Optimizations
+
+- Detect zero dividend (quotient is zero, remainder is dividend) and divide-by-one (quotient is dividend, remainder is zero) at the front end and forward the result without entering the iterative loop.
+- **Corner cases the fast path must handle correctly** (consistent with the iterative path):
+  - dividend = 0, divisor = anything (including 0): quotient = 0, remainder = 0 (dividend).
+  - divisor = 1: quotient = dividend, remainder = 0.
+  - divisor = −1:
+    - dividend = 2^(XLEN−1) (most-negative): quotient = 2^(XLEN−1) (dividend), remainder = 0 (signed overflow case, the M-extension rule).
+    - all other dividends: quotient = −dividend (two's complement negation), remainder = 0.
+- The fast path must explicitly implement these rules; it is not a simple "if divisor=±1 then return dividend" because of the signed-overflow case for divisor = −1.
+- Saves latency in the common case for some workloads; trivial area overhead.
+- Composable with any divider organization.
+
+### B6. Software Divide-by-Constant Transformation (cross-cutting)
+
+- Compilers transform division by a **compile-time** constant into a multiply-by-reciprocal sequence. The hardware DIV is then needed only for division by variables.
+- Reduces effective DIV frequency significantly for workloads with constant denominators; affects hardware sizing decisions. **INSUFFICIENT EVIDENCE** for a quantitative reduction without a specific workload profile.
+
+### B7. Dedicated 32-bit Fast Divider for W-suffixed Instructions
+
+- Implement a separate 32-bit radix-2 or radix-4 iterative divider for DIVW / DIVUW / REMW / REMUW. The 32-bit divider has half the iteration count (32 or 16 cycles vs. 64 or 33 for the 64-bit divider) and roughly a quarter of the datapath area.
+- Useful if profiling shows W-suffixed divides dominate; in most general-purpose workloads they do not.
+- Verification cost: dual divider datapath, similar to B3.
+- **Note**: W-suffixed instructions operate on 32-bit operands; a natural alternative is to share the 64-bit divider datapath with the 32-bit operands on the lower 32 bits, taking 32 or 16 cycles of the 64-bit divider's iteration. B7 is only worth its area if the latency savings matter.
+
+### B8. Combined MUL / DIV with Shared Partial-Product Array (CSA Sharing)
+
+- Reuse the MUL's CSA compressor tree as the final correction multiplier for an SRT or Newton-Raphson divider, sharing the most area-intensive block.
+- Reduces the area penalty of A3 / A4 at the cost of tighter verification coupling between MUL and DIV paths.
+- Real architectural option in some high-performance designs; not considered in the prior revision.
+
+### B9. Combined MUL / DIV with Shared Final Carry-Propagate Adder (CPA Sharing)
+
+- Share only the final 128-bit carry-propagate adder between the MUL datapath and the DIV's correction-multiply step (or the DIV's final-cycle remainder correction). The compressor tree, partial-product generation, and divider iteration state remain separate.
+- Lower area savings than B8 (CSA is shared instead of CPA), but much simpler verification: the shared CPA is a single combinational block, and the MUL vs DIV datapaths feeding it are independent.
+- The MUL pipeline register naturally sits between the compressor-tree output and the CPA, which means the CPA itself can be shared at the output side without disrupting the MUL pipeline structure.
+- **Open question**: whether the MUL pipeline register sits at the compressor-tree output (CPA in cycle 2) or at the CPA output (CPA in cycle 1) determines the CPA's pipeline stage. See Implementation Considerations for the canonical placement decision.
+
+### B10. Partially Unrolled Radix-4 Divider (intermediate between A2a and A2b)
+
+- Unroll the radix-4 iterative divider into a small number of pipeline stages (e.g., 8 or 16 stages) rather than the full 64 (A2b) or the single iterative loop (A2a).
+- Latency 32 or 33 cycles (one stage per two quotient bits for 8 stages, or one stage per quotient bit for 16 stages), throughput 1 per cycle after fill, area roughly 8× or 16× A1.
+- A meaningful intermediate option for the high-DIV-throughput case that the prior revision did not consider.
+- Verification: same as A2a (iterative datapath with pipeline registers); the unrolling does not introduce new corner cases.
+
+## Comparison
+
+| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |
+|--------|-------------|----------|-------------|----------|----------------------|----------------|--------------------------|
+| A1 (radix-2 iter. DIV only) | not defined in A1 | not defined in A1 | 64 cycles | 1 per 64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |
+| A2a (pipelined iter. loop) | not defined in A2a | not defined in A2a | 64 cycles | 1 per cycle (after fill) | INSUFFICIENT EVIDENCE | Med | Med |
+| A2b (fully unrolled) | not defined in A2b | not defined in A2b | 64 cycles | 1 per cycle | INSUFFICIENT EVIDENCE (very large) | High | High |
+| A3 (Newton-Raphson) | 1 cycle | 1 per cycle (dedicated) | N+1 MUL cycles (dedicated); workload-dep. if shared | INSUFFICIENT EVIDENCE (shared) | high | High | High |
+| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1 per cycle if pipelined | high | High | High |
+| B1 (radix-4 DIV, 1-stage MUL) | 1 cycle (target) | 1 per cycle | ~33 cycles | 1 per 33 cycles | baseline | Low–Med | Low–Med |
+| B1' (2× MUL + 1× shared DIV) | 1 cycle | 2 per cycle | ~33 cycles | 1 per 33 cycles (shared) | ~2× B1 (INSUFFICIENT EVIDENCE; assumes MUL:DIV area ≈ 1:1) | Med | Med |
+| B2 (+ MAC) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | +unspecified % over B1 (INSUFFICIENT EVIDENCE) | Med | Med |
+| B3 (32-bit fast MUL; serves MULW) | 1 cycle (32-bit path) | 1 per cycle | ~33 cycles | 1 per 33 cycles | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |
+| B4 (full 64 only; MULW separate) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | same as B1 (MULW path TBD) | Med | Lowest (MUL side); Med (MULW) |
+| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |
+| B7 (32-bit fast DIV) | 1 cycle | 1 per cycle | ~16–17 cycles (32-bit) | 1 per 16–17 cycles (32-bit only) | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |
+| B8 (shared MUL/DIV CSA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | lower than A3/A4 alone (INSUFFICIENT EVIDENCE) | Med–High | Med–High (tight coupling) |
+| B9 (shared MUL/DIV CPA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | slightly higher than B8 reduction (INSUFFICIENT EVIDENCE) | Med | Low (clean separation) |
+| B10 (partially unrolled radix-4) | not defined in B10 | not defined in B10 | ~32–33 cycles | 1 per cycle (after fill) | ~8–16× A1 (INSUFFICIENT EVIDENCE) | Med | Med |
+
+**ASSUMPTION**: Relative area figures are qualitative orderings based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are **INSUFFICIENT EVIDENCE** pending RTL implementation.
+
+## Advantages
+
+### A1 / B1
+- Smallest area; lowest per-core replication cost.
+- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).
+- Simpler verification; one mode of operation.
+- Well-understood reference implementation (Rocket, Ibex) for the divider side; the MUL side departs from both references.
+
+### A4 (High-Radix SRT)
+- Lowest DIV latency among the iterative-style options; competitive with A3 on a single divide.
+- Pipelined variant gives 1 per cycle DIV throughput.
+
+### A3 (Newton-Raphson)
+- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.
+- Amortizes multiplier cost if MAC (B2) is also desired.
+- Disadvantage: requires multiple refinement iterations; integer multiplier is large and contention with the main MUL datapath is a concern.
+
+### B2 (MAC)
+- Enables future-proofing for proposed bitmanip and MAC extensions.
+- Helpful for matrix multiplication kernels running across 128 cores.
+
+### B3 (32-bit fast MUL; serves MULW)
+- Natural implementation of MULW; the 32×32→64 datapath produces the MULW result by sign-extending the lower 32 bits.
+- Accelerates 64-bit MUL on 32-bit-valued operands (a common pattern after `lw`/`lwu` + arithmetic).
+- Area overhead is bounded by the 32-bit datapath size (much smaller than the 64-bit datapath).
+
+### B5 (Skip-on-Zero)
+- Negligible area; reduces effective DIV latency for common cases.
+
+### B7 (32-bit fast DIV)
+- Halves the divider iteration count for the W-suffixed instructions at modest area cost.
+
+### B8 (Shared MUL/DIV CSA)
+- Reduces the area penalty of high-performance dividers by sharing the most area-intensive block.
+
+### B9 (Shared MUL/DIV CPA)
+- Lower verification cost than B8; the shared CPA is a single combinational block and the MUL/DIV datapaths feeding it are independent.
+
+### B10 (Partially Unrolled Radix-4)
+- A meaningful intermediate option for high DIV throughput without the area cost of A2b; same verification profile as A2a.
+
+## Disadvantages
+
+### A1 / B1
+- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall ~33 cycles per divide.
+- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.
+- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).
+
+### A3
+- Area at 128-core replication is severe; the multiplier is one of the largest blocks in a typical core.
+- Power: a 64×64 multiplier running 1 per cycle is one of the highest-power blocks in a typical core.
+- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.
+- If multiplier is shared with main MUL datapath, throughput is workload-dependent, not the N+1 figure cited for the dedicated case.
+
+### A4
+- Large lookup table (PLA or ROM); area and power dominated by the table.
+- Verification: complex quotient-digit selection logic.
+- Not commonly used outside high-end commercial designs.
+
+### B3
+- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.
+- The classification logic (operand-width detection) is itself a source of corner-case bugs.
+- **B3 does not subsume MULW for the purpose of "B3 is redundant"**: B3 and MULW are two different ways to access 32-bit-multiplication, and B3's value is primarily as the natural MULW implementation and secondarily as the 32-bit-extended-operand fast path.
+
+### B2
+- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.
+
+### B5
+- Only helps the specific cases of zero dividend or divisor ±1; other optimizations (e.g., division by small powers of two) are already handled by the base I extension's shift instructions.
+- The fast path must explicitly handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1): quotient = dividend, remainder = 0.
+
+### B7
+- Verification: dual divider datapath; same concerns as B3.
+- Area saving is moot if W-suffixed divides are not on the critical path.
+
+### B8
+- Verification: tighter coupling between MUL and DIV paths makes corner-case analysis more difficult.
+
+### B9
+- Area savings are smaller than B8 (CPA shared instead of CSA); the savings are bounded by the CPA size, which is significant but not the dominant block.
+
+### B10
+- Area scales with the unroll factor; 16-stage unroll is ~16× A1, which is meaningful at 128-core replication.
+
+## XH-1 Considerations
+
+**PROPOSAL**: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:
+
+- **MUL**: 64×64→128, target 1-cycle pipelined (1 stage of pipeline registers), throughput 1 per cycle. The pipeline register sits at the **CPA output** (after the compressor tree and the 128-bit CPA in cycle 1), so the entire compressor-tree-plus-CPA path is in one cycle. This is the "1-cycle MUL" interpretation; the fallback-A interpretation splits the compressor tree and the CPA across two cycles. For 2-issue or wider cores, scale to B1' (two MUL pipelines sharing one DIV).
+- **DIV**: Radix-4 shift-subtract, ~33 cycles worst case (32 cycles for quotient bits + finalization), blocking, non-pipelined. The prior revision's "33–35 cycles worst case" and the "33–64 cycle" range are reconciled here: 33 is the radix-4 bound; 64 corresponds to radix-2, which is a different algorithm choice.
+- **REM**: Reuse the DIV datapath; remainder is a by-product.
+- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle. **INSUFFICIENT EVIDENCE** on whether this fits the XH-1 pipeline depth; depends on the integration context.
+- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead. The fast path must handle the signed-overflow corner case (divisor = −1, dividend = 2^(XLEN−1)) by returning quotient = dividend, remainder = 0.
+- **B3 (32-bit fast MUL, also serves MULW)**: include the 32×32→64 datapath as the MULW implementation path. The same datapath accelerates 64-bit MUL on 32-bit-extended operands. Verification cost: dual datapath, manageable with the B3 corner-case set (operand-width detection, sign-extension patterns).
+- **B7 (32-bit fast DIV)**: Defer; the W-suffixed divide is not assumed to be on the critical path. Revisit if profiling shows otherwise.
+
+**ASSUMPTION**: A 1-cycle MUL latency is achievable in the target process. **INSUFFICIENT EVIDENCE** on the XH-1 target process node and clock period. A full 64×64→128 Wallace/Dadda tree + 128-bit carry-propagate adder in a single cycle is at the edge of feasibility for high-performance designs; typical in-order cores implement MUL as either a multi-cycle iterative multiplier or a multi-stage pipelined multiplier. **PROPOSAL**: Validate via synthesis at the target corner before committing. If the 1-cycle critical path cannot be closed, **fallback options** are:
+  - **B1-fallback-A**: 2-cycle pipelined MUL. The pipeline register sits at the **compressor-tree output** (splitting the compressor tree in cycle 1 from the CPA in cycle 2); latency 2 cycles, throughput 1 per cycle, modest area overhead (one extra pipeline register).
+  - **B1-fallback-B**: Multi-cycle iterative MUL (Booth-encoded). The cycle count for a Booth-encoded iterative multiplier on 64×64 is implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number of cycles. Lower area, lower throughput, higher latency.
+  - **B1-fallback-C**: Retain the 1-stage MUL architecture but lower the target clock frequency (system-level decision, not unit-level).
+
+**MUL/DIV resource sharing and contention (single-issue-lane B1)**: Under B1, the MUL pipeline and the DIV datapath share the integer execution lane's issue slot, register-file read ports, and writeback port. The single execution lane can issue either one MUL per cycle (latency 1) or one DIV (latency ~33) at a time, but not both simultaneously. If a MUL is issued while a DIV is in progress:
+- The MUL occupies the issue slot for 1 cycle; the DIV's iterative state is held in the divider's internal registers and does not require the issue slot during its 33 cycles.
+- Register-file read ports: MUL requires 2 read ports for its 1 cycle; the DIV's operands are read at DIV issue and held in the divider's operand register. No contention after issue.
+- Writeback port: MUL writes back in cycle 2 (1-cycle latency); the DIV writes back on completion. A MUL issued in the same cycle as a DIV completion would contend for the writeback port. In a single-writeback-port lane, the DIV completion must be stalled by 1 cycle to let the MUL writeback, or vice versa. This is a 1-cycle throughput loss in the rare case of simultaneous MUL-and-DIV-completion, and is acceptable at 128-core scale (per-core throughput loss is small; aggregate is bounded by the per-core lane).
+- **For 128-core aggregate throughput**: the per-core limitation is the MUL/DIV issue slot, not the divider's iteration. Aggregate MUL throughput is bounded by 1/cycle/core = 128/cycle die-wide. Aggregate DIV throughput is bounded by 1/33 cycles/core = 128/33 ≈ 3.88 divides/cycle die-wide in the steady state if every core is issuing back-to-back independent divides. This is the steady-state upper bound under B1, not a typical workload figure. With B5 reducing some divides to 1 cycle, the aggregate is workload-dependent and typically lower.
+
+**PROPOSAL**: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1, or 2 in the fallback) and variable-latency DIV (~33).
+
+**PROPOSAL**: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.
+
+**PROPOSAL**: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.
+
+**PROPOSAL**: The B-extension unit (if RV64B is implemented) shares **operand muxes, sign-handling logic, and bit-level muxes** with the MUL/DIV unit but does **not** share the Wallace/Dadda compressor tree. Operations like CLZ, CTZ, BSET, BEXT operate on individual bits or small bit-fields and do not naturally map onto a Wallace-tree multiplier datapath. CLMUL / CLMULH / CLMULR (Zbc) require an AND-tree / XOR-reduction datapath that is structurally distinct from both the Wallace-tree multiplier and the iterative divider; they do not share the compressor tree. Any apparent sharing is at the operand-fetch and writeback layers, not the core arithmetic.
+
+## 128-Core Scalability
+
+The 128-core replication factor is the dominant cost driver for the MUL/DIV unit.
+
+**PROPOSAL**: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.
+
+**PROPOSAL**: The MUL/DIV unit's reservation-station entries, divider iteration state, and pipeline registers must support **state retention or clean-state entry** across power gating. Specifically, when a core is power-gated while a long-latency DIV is in flight, the DIV's mid-iteration state must be handled by one of the following:
+  - (a) **Flush and re-issue**: the in-flight DIV is squashed architecturally (the issue queue entry is marked invalid, the divider's iteration state is discarded), and the DIV is re-fetched and re-issued from the I-cache after the core wakes up. This is architecturally transparent if the re-fetch / re-issue mechanism is present (standard OoO replay path); the architectural state is preserved because the DIV is re-executed from scratch. The cost is re-fetch latency after wakeup. The mechanism is "not acceptable" only if the re-fetch path is not implemented (e.g., a simple in-order core without replay).
+  - (b) **Checkpoint to retention**: the divider's iteration state is saved to a retention register or to memory before power-down, and restored on wakeup. Preserves the in-flight DIV but requires retention storage proportional to the divider's state.
+  - (c) **Block power-gating until completion**: power-gating is only allowed when the divider is idle. Simple, but defeats the purpose of DPM if DIV latency is long and frequent.
+- The choice depends on the XH-1 DPM policy and on whether the core is in-order or OoO. **INSUFFICIENT EVIDENCE** on the XH-1 DPM policy; the design must accommodate one of these options without committing to a specific approach here.
+
+**OPEN QUESTION**: What is the actual MUL/DIV area share of the XH-1 core? Published RISC-V references suggest a typical MUL unit occupies a small single-digit percentage of a high-performance core's area, with iterative DIV adding additional area. The prior revision's "1–3%" and "1 MGE/core total" baseline are removed here as unsourced. **INSUFFICIENT EVIDENCE** on the XH-1-specific area share without synthesis.
+
+**OPEN QUESTION**: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.
+
+**INSUFFICIENT EVIDENCE**: The XH-1 die-area budget, process node, and clock period are not established in this document.
+
+**PROPOSAL**: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template. **PROPOSAL**: The generate block itself must be included in the verification scope (not assumed trivially correct). At minimum: a lint-clean check, a synthesis-check that the generate block instantiates the correct number of cores, and a per-instance equivalence check on a sample of cores.
+
+**PROPOSAL**: For 128× replicated MUL/DIV pipeline registers, ECC or parity protection should be considered for soft-error mitigation. **INSUFFICIENT EVIDENCE** on the XH-1 reliability target.
+
+**PROPOSAL**: Reset distribution and scan chain architecture for 128× replicated MUL/DIV must be addressed at the integration level. The MUL/DIV unit's scan chains should support parallel or staggered scan-shift across cores to keep test time bounded. **INSUFFICIENT EVIDENCE** on the XH-1 DFT architecture.
+
+**CONSIDERATION (clock and timing at 128× replication)**: If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (one 64-bit adder-equivalent) which is favorable; a non-pipelined iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter. The clock-skew analysis should be revisited at the integration level once the XH-1 clock tree is defined.
+
+**CONSIDERATION (cross-core aggregate throughput)**: Under B1, each core's blocking DIV delivers at most 1 per 33 cycles per core in the steady state. Across 128 cores, the aggregate is at most ~3.88 divides per cycle in the steady state, which assumes all cores are issuing back-to-back independent divides for the full 33 cycles each. This is an upper bound on aggregate throughput, not a typical workload figure. Real workloads do not exhibit this worst case; the relevant metric is the per-core latency, not aggregate. **INSUFFICIENT EVIDENCE** on whether the XH-1 DPM or interconnect imposes a global cap on simultaneous divide activity; this is a system-level question outside the MUL/DIV unit's scope.
+
+**CONSIDERATION (operand distribution and interconnect)**: Replicating a Wallace tree 128× implies 128 sets of wide operand buses to/from the register file. The interconnect / operand-routing network cost scales with the MUL operand width and the number of cores. **PROPOSAL**: include operand-routing overhead in the area estimate, not just the MUL/DIV datapath itself.
+
+## Performance Considerations
+
+**PROPOSAL**: **MUL throughput of 1 per cycle is a target for a high-performance XH-1 core**, but is not architecturally non-negotiable. Low-end in-order cores (some Ibex configurations) implement MUL with throughput < 1 per cycle. B1 satisfies the high-performance target with a 1-stage pipelined multiplier; B1' extends to 2 per cycle for wide-issue. If the 1-cycle MUL cannot be closed at the target process, the throughput target remains 1 per cycle but the latency becomes 2 cycles (B1-fallback-A).
+
+**PROPOSAL**: **DIV throughput of 1 per ~33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).
+
+**ASSUMPTION**: XH-1 target workloads include a mix consistent with Embench / SPECint-class profiles, where MUL/DIV instructions are a small fraction of dynamic instruction count. **INSUFFICIENT EVIDENCE** on the actual XH-1 target workload mix and on the specific dynamic-instruction share of MUL/DIV. The prior revision's "<2% MUL/DIV" and "<0.5% DIV/REM" claims are removed as unsourced.
+
+**OPEN QUESTION**: Does XH-1 target HPC or cryptography workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3, A4, A2a, or B10. **NOTE**: ML workloads are dominated by floating-point multiplies on the FPU, not by integer MUL/DIV; integer MUL/DIV is relevant to ML only for quantization, address arithmetic, and integer embeddings.
+
+## Area Considerations
+
+**PROPOSAL**: Budget the MUL/DIV unit at a small single-digit percentage of single-core area for the B1 design, pending synthesis. The exact percentage is **INSUFFICIENT EVIDENCE**.
+
+**OPEN QUESTION**: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.
+
+**ASSUMPTION**: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) and A4 (high-radix SRT) are larger, with A4 typically the largest. **INSUFFICIENT EVIDENCE** on the XH-1-specific gate-count budget.
+
+## Power and Energy Considerations
+
+**FACT**: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.
+
+**PROPOSAL**: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.
+
+**PROPOSAL**: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.
+
+**OPEN QUESTION**: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design.
+
+**INSUFFICIENT EVIDENCE**: Specific per-MUL or per-DIV energy numbers for the XH-1 process are not established. The prior revision's "single-digit pJ in 7 nm" claim is removed as unsourced; per-MUL energy in advanced processes is implementation-dependent and varies by an order of magnitude or more depending on architecture and clock frequency.
+
+## Implementation Considerations
+
+**PROPOSAL**: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget accommodates the entire critical path from operand register → compressor tree → CPA → output register, with the pipeline register at the CPA output. **INSUFFICIENT EVIDENCE** on whether a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the XH-1 target clock period; the specific tree depth and CPA depth are implementation-dependent and not asserted as fixed numbers here. The prior revision's "Tree depth 6–7; final CPA ~6 gates deep" is removed as unsourced and implementation-specific.
+
+**MUL pipeline register placement** (clarified):
+- **Primary (1-stage)**: register at CPA output. The compressor tree and the 128-bit CPA are both in cycle 1.
+- **Fallback A (2-stage)**: register at compressor-tree output. The compressor tree is in cycle 1, the 128-bit CPA is in cycle 2.
+- The placement determines the critical path per cycle: in the primary, the per-cycle critical path is tree + CPA; in fallback A, the per-cycle critical path is max(tree, CPA). Fallback A is the natural way to close timing if tree + CPA exceeds the target clock period in a single cycle.
+
+**PROPOSAL**: For MULHSU, the standard implementation generates a 64×64 partial-product array with the unsigned operand's partial products zero in the upper half and the signed operand's final partial-product row sign-extended (or added in inverted-and-carry form) into the reduction tree. The 128-bit-wide signed multiplier datapath is an alternative but doubles the multiplier width and is rarely used.
+
+**PROPOSAL**: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 32 cycles for quotient bits + 1 cycle for finalization = ~33 cycles total. The remainder is the "running remainder" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.
+
+**PROPOSAL**: B5 (skip-on-zero): add a front-end detector on the DIV operands that forwards the result directly for divisor = ±1 or dividend = 0, bypassing the iterative loop. The fast path must handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1) by returning quotient = dividend, remainder = 0, consistent with the M-extension rule. Trivial area; reduces effective DIV latency for common cases.
+
+**PROPOSAL**: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework. Note that WIDTH=32 does not by itself support the MULW instruction semantics in RV64 (which performs a 32×32→64 multiply and sign-extends the 32-bit result); the B3 32×32→64 datapath implements MULW by taking the lower 32 bits and sign-extending to 64.
+
+## Verification Considerations
+
+**FACT**: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions). For DIV/REM, the corner cases include the division-by-zero and signed-overflow rules defined in the ISA spec.
+
+**PROPOSAL**: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:
+- **Reference MUL**: SystemVerilog `bit [127:0]` (or DPI-C to a software bigint). The reference produces the full 128-bit product; the checker compares the appropriate bits of the 128-bit result against the architectural result:
+  - MUL, MULH, MULHU, MULHSU: lower 64 or upper 64 bits of the 128-bit product, with sign-handling per the ISA spec.
+  - MULW: lower 32 bits of the 64-bit product (where the 64-bit product is computed on a 32×32 signed multiplication, with the 32-bit result sign-extended to 64 bits and written to `rd`). The reference is a 32×32 signed multiply that produces a 32-bit result, which is then sign-extended to 64 bits and compared against the architectural `rd` value. The 128-bit reference path is used for MUL/MULH/MULHU/MULHSU, not for MULW.
+- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec, including the division-by-zero and signed-overflow rules for both quotient-producing and remainder-producing instructions.
+- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1), plus randomized large operands.
+- **Regression list size**: The prior revision's "64 hand-crafted corner cases" is removed as a specific number; the regression list should be sized to cover the documented corner cases and is grown as bugs are found. **INSUFFICIENT EVIDENCE** for a canonical count.
+
+**PROPOSAL**: At the 128-core replication level, **per-core functional verification** of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level (via a SystemVerilog generate block). This covers functional equivalence at the unit level. **However**, the verification of the generate block itself, and the interaction between per-core clock-gating / power-state and MUL/DIV state (e.g., does a clock-gated MUL lose its pipeline state correctly across gating? does a power-gated divider leave the iteration counter in a valid state for resumption, or is the DIV flushed and re-issued as in option (a) of the 128-core power-gating proposal?), must be verified explicitly. **Per-core physical / timing verification is not bypassed**: timing, DFT, and physical-design closure are verified at the integration level on a representative core and assumed replicated, with explicit per-die variation analysis as required by the XH-1 physical-design flow.
+
+**PROPOSAL**: If the XH-1 verification flow includes formal property checking, the DIV correctness property ("quotient × divisor + remainder == dividend" within the RISC-V M extension's special cases) is a clean formal target and should be specified. **INSUFFICIENT EVIDENCE** on whether formal property checking is in scope.
+
+## Software Considerations
+
+**PROPOSAL**: Document the MUL/DIV latencies (1 cycle MUL, ~33 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.
+
+**OPEN QUESTION**: Does the XH-1 ABI / linker convention include a software-emulated division routine for code that cannot tolerate the ~33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one. The compiler can also apply divide-by-constant transformations (B6) to reduce effective hardware DIV frequency.
+
+**PROPOSAL**: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.
+
+**PROPOSAL**: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.
+
+## Recommendation
+
+**RECOMMENDATION**: Adopt **B1** — a hybrid MUL unit (target 1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Add **B5** (skip-on-zero, with the signed-overflow corner case handled) at the DIV front end. Add **B3** as the MULW implementation and the 32-bit-extended-operand fast path. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM. For wide-issue cores, scale to **B1'** (two MUL pipelines sharing one DIV).
+
+Rationale:
+1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed for high-performance targets).
+2. Keeps per-core area small, manageable at 128× replication.
+3. Avoids the verification burden of B8 (shared CSA) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).
+4. **B3 inclusion is required for MULW**, not optional: the same 32×32→64 datapath that accelerates 64-bit MUL on 32-bit-extended operands also implements MULW directly. Deferring B3 means deferring the natural MULW implementation.
+5. B5 is a near-free improvement to the common case, with the signed-overflow corner case handled correctly.
+6. The MUL/DIV design inherits the radix-4 iterative divider pattern from Rocket and Ibex; the MUL side departs from both references (1-stage pipelined vs. Rocket's multi-stage or Ibex's short-pipeline / combinational), which is an aggressive target that must be validated by synthesis.
+
+**Fallback plan** (if the 1-cycle MUL cannot be closed at the target process / clock):
+- **Primary fallback**: B1-fallback-A — 2-cycle pipelined MUL with the pipeline register at the compressor-tree output. Latency 2 cycles, throughput 1 per cycle, modest area overhead. B1 architecture preserved.
+- **Secondary fallback**: B1-fallback-B — multi-cycle iterative MUL (Booth-encoded). Cycle count implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number. Lower area, lower throughput, higher latency. DIV remains radix-4 iterative.
+- **Tertiary fallback**: Lower the target clock frequency at the system level.
+
+This recommendation is **conditional on**:
+- The XH-1 target process supporting either a 1-cycle 64×64→128 MUL critical path (primary) or a 2-cycle pipelined MUL critical path (fallback A) at the target clock. Both must be validated by synthesis at the target corner; **INSUFFICIENT EVIDENCE** without target process specification.
+- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT), a pipelined iterative divider (A2a or B10), or a shared MUL/DIV organization (B8, B9).
+- The 128-core replication budget tolerating the cumulative MUL/DIV area; this requires a known single-core area budget, which is **INSUFFICIENT EVIDENCE**.
+- A clear DPM policy for handling in-flight MUL/DIV state across power gating.
+
+If any of these conditions fails, re-open the design against the named fallback.
+
+## Confidence
+
+**Medium-High** for B1 as the baseline architectural pattern. **Low** for specific area, power, and energy numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are **INSUFFICIENT EVIDENCE**). The corrected version removes specific unsourced quantitative claims and demotes several prior FACTs to ASSUMPTION or INSUFFICIENT EVIDENCE.
+
+## Open Questions
+
+1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design and determines whether 1-cycle MUL is feasible.
+2. What is the XH-1 target workload mix? HPC, cryptography, or general-purpose? (ML is not primarily an integer MUL/DIV workload.)
+3. Is the XH-1 core in-order, out-of-order, or hybrid?
+4. Does XH-1 implement RV64B (bit-manipulation) extensions, including Zbc (CLMUL / CLMULH / CLMULR)? The B extension does not naturally share the Wallace-tree multiplier datapath; any sharing is at the operand-mux and writeback layers, not the compressor tree.
+5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?
+6. Does XH-1 use a per-core DPM scheme, and how does it handle in-flight MUL/DIV state across power gating (retention, flush-and-re-issue, or block-power-gate-until-completion)?
+7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM (or RV64IMB)?
+8. Is there a software-emulated division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV? Will the compiler apply divide-by-constant transformations (B6)?
+9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's "quotient × divisor + remainder == dividend" property?
+10. For wide-issue cores, is B1' (two MUL pipelines + one shared DIV) the target, or is single-MUL B1 sufficient?
+11. What is the XH-1 interconnect / operand-routing cost of replicating a wide MUL operand bus 128 times? Should this overhead be included in the MUL/DIV unit's area budget?
+12. What is the XH-1 reliability target? Does the MUL/DIV pipeline require ECC or parity protection against soft errors?
+13. What is the XH-1 DFT architecture for the 128× replicated MUL/DIV scan chains?
+
+## Sources
+
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. Canonical ISA reference; defines the M-extension corner-case rules for DIV/REM/DIVU/REMU/DIVW/REMW/DIVUW/REMUW and MULW.
+- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA*, Chapter 16 (B Extension, including Zbc). Canonical ISA reference for CLMUL / CLMULH / CLMULR.
+- Asanović et al., "The Rocket Chip Generator," EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. Reference for Rocket's MUL/DIV organization; configuration-dependent.
+- Celio, Patterson, Asanović, "BOOM v2: a superscalar out-of-order processor," 2017. Reference for BOOM's MUL/DIV design.
+- Ibex documentation, lowRISC. Reference for the in-order baseline.
+- Chen et al., "XiangShan: An Open-Source High-Performance RISC-V Core," 2022. Reference for high-performance RISC-V MUL/DIV design.
+- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. Reference for shift-subtract, SRT, and Newton-Raphson divide algorithms.
+- Flynn, Oberman, *Advanced Computer Arithmetic Design*. Reference for high-radix divider design.
+- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. Reference for Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process.
+
+**INSUFFICIENT EVIDENCE**: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, energy, and timing are **INSUFFICIENT EVIDENCE** pending RTL implementation and target-process specification. Cortex-A77 per-instruction latencies are not publicly published by Arm and are **INSUFFICIENT EVIDENCE** from primary sources. The internal radix of the Intel Haswell integer divider is widely reported as high-radix shift-subtract rather than Newton-Raphson, but the specific radix (16 vs. 32) is **INSUFFICIENT EVIDENCE** from primary sources; Newton-Raphson is reported to be used in Haswell's floating-point unit. The cycle count for a Booth-encoded iterative 64×64 multiplier is implementation-dependent and **INSUFFICIENT EVIDENCE** for a specific number.