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