# 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.
