# Multiply/Divide Unit Design for the XH-1 Processor

## Status

**Stub document — research in progress.** No architectural decisions have been finalized. The XH-1 repository contains no prior decisions on the multiply/divide (MUL/DIV) unit. All content below is a structured engineering analysis of design options, framed as proposals and open questions.

## Abstract

This document investigates the design of the integer multiply and divide unit (MUL/DIV) for the XH-1, a custom 128-core RISC-V processor. The MUL/DIV unit is a latency-critical but throughput-amortizable functional unit. Its design has outsized impact on the pipeline depth, area per core, and verification effort, all of which compound across 128 replicated cores. We survey the principal implementation strategies (iterative shift-and-add, radix-4/8 Booth, array multipliers, Goldschmidt/Newton-Raphson dividers, and iterative reciprocal-multiplication) and analyze their trade-offs with respect to latency, throughput, area, power, and verification complexity. The document is intentionally non-prescriptive: the XH-1 has not yet established a baseline for core microarchitecture (in-order vs. out-of-order, pipeline depth), so recommendations are conditional on those upstream decisions.

## Research Question

> What is the appropriate microarchitecture for the integer MUL/DIV unit in the XH-1 core, given that the unit will be replicated 128 times, must support the RV64M extension, and must satisfy XH-1's target latency, area, and power budget — the latter two of which are not yet defined?

Specifically:

- How should the unit be pipelined relative to the rest of the core?
- Should it share silicon with adjacent datapath structures (ALU, register file read/write ports) or remain isolated?
- How should division throughput be traded against area and verification cost?
- What is the impact of the choice on multi-core contention for shared execution resources, if any?

## Background

The RISC-V "M" standard extension defines four signed/unsigned variants of multiply and two signed/unsigned variants of divide plus remainder:

- `MUL` (lower 64 bits of signed × signed)
- `MULH`, `MULHU`, `MULHSU` (upper 64 bits, various sign combinations)
- `DIV`, `DIVU` (signed/unsigned quotient)
- `REM`, `REMU` (signed/unsigned remainder)

Critical properties of this ISA slice that drive microarchitecture:

- **Wide-operand upper-multiply (UMUL):** Producing the upper 64 bits of a 64×64→128-bit product is approximately twice the area of the lower-64-bit result, since it cannot reuse a 64×64→64 multiplier without additional logic.
- **Division latencies:** A non-trivial iterative divider for 64-bit operands requires 32 to 64 reduction steps, dominating pipeline depth if fully combinational.
- **Signed semantics:** MULHSU and DIVU/REMU require careful sign-handling that complicates early-exit logic.
- **Throughput vs. latency decoupling:** RISC-V MUL/DIV results are written to the integer register file, so latency can be hidden by OoO scheduling — but in an in-order core, latency is directly exposed to the front-end.

The XH-1 is a 128-core machine. Decisions in the MUL/DIV unit replicate 128×, so per-core area and verification effort dominate. There is no public XH-1 microarchitecture document in the repository that would constrain the MUL/DIV design (e.g., pipeline depth, issue width, in-order/OoO).

**INSUFFICIENT EVIDENCE:** Pipeline depth, issue width, in-order vs. OoO status, target frequency, and target process node for XH-1 are all unknown.

## Existing Approaches

The following approaches are well-established in the literature and commercial designs. No specific citation is invented here; references to canonical techniques are sufficient.

### 1. Shift-and-Add Multiplier (Iterative)

- **Mechanism:** A 64-bit multiplier is implemented as a 64-cycle state machine, one partial-product bit per cycle, with a 129-bit accumulator.
- **Latency:** 64 cycles (signed) or 32 cycles (sign-preconditioned) before result available.
- **Throughput:** 1 multiply per ~64 cycles.
- **Area:** Very small. Roughly one 64-bit adder + one shifter + one 129-bit accumulator register.
- **Power:** Low. Minimal clocked area.
- **Verification:** Low complexity. Straightforward to model and exhaustively test small operand widths.
- **Use case:** Embedded in-order cores (e.g., RV32I designs where MUL/DIV are infrequent and latency-tolerant). Generally unsuitable for high-performance 64-bit cores.

### 2. Radix-4 Booth-Encoded Multiplier (Array or Iterative)

- **Mechanism:** Booth recoding reduces partial products to ceil(n/2). A radix-4 scheme halves the iteration count. Implemented either as a combinational Wallace/Dadda tree, or iteratively over ceil(64/2) = 32 cycles.
- **Latency:** 32 cycles iterative, ~8–16 cycles pipelined (depending on adder tree depth).
- **Throughput:** 1 multiply per 32 cycles iterative, 1/cycle fully pipelined.
- **Area:** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA.
- **Power:** Moderate to high. The Wallace tree toggles aggressively.
- **Verification:** Moderate. Corner cases around operand sign and the `MULHSU` path require careful directed tests.
- **Use case:** Mid- and high-performance cores; the default choice for most modern desktop-class RV64 cores.

### 3. Radix-8 or Radix-16 Booth Multiplier

- **Mechanism:** Higher-radix Booth recoding (radix-8, radix-16) further reduces partial products by 3× or 4× at the cost of harder partial-product generation (3× or 5× multiples).
- **Latency:** Fewer pipeline stages for the same throughput target, or higher throughput for the same area.
- **Throughput:** 1/cycle or better.
- **Area:** Larger partial-product generator; smaller adder tree. Net area roughly comparable to radix-4.
- **Power:** Mixed. Fewer adder levels, but more complex PP generation.
- **Verification:** Higher. Radix-8+ PPGs have more corner cases.
- **Use case:** High-frequency designs where the critical path is in the adder tree, not the PPG.

### 4. Iterative Subtractive Divider (Non-Restoring / Restoring)

- **Mechanism:** Standard shift-subtract over 32 to 64 cycles. Produces quotient (and optionally remainder) one bit per cycle.
- **Latency:** 32 to 64 cycles.
- **Throughput:** 1 divide per 32–64 cycles.
- **Area:** Small. A 64- or 65-bit ALU with quotient/remainder registers.
- **Power:** Low.
- **Verification:** Moderate. The signed-dividend/divisor path and the division-by-zero convention (RISC-V returns -1) require explicit verification.
- **Use case:** In-order cores with low expected DIV frequency.

### 5. Radix-4/8 SRT Divider

- **Mechanism:** Higher-radix SRT produces 2 or more quotient bits per iteration by selecting one of several shifted multiples of the divisor.
- **Latency:** 16 to 32 cycles.
- **Throughput:** One divide per 16–32 cycles.
- **Area:** Substantially larger than subtractive. Requires a redundant quotient representation (carry-save) and a quotient-digit selection table.
- **Power:** Higher.
- **Verification:** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction is a known source of silicon bugs in commercial designs.
- **Use case:** High-frequency OoO cores needing higher DIV throughput.

### 6. Goldschmidt / Newton-Raphson Divider (Reciprocal Multiplication)

- **Mechanism:** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Effectively performs division using a fast multiplier.
- **Latency:** A few iterations of multiply-add. Amortized low latency if the multiplier is fast.
- **Throughput:** Bounded by the multiplier.
- **Area:** Reuses the multiplier. Adds a small amount of control logic and lookup-table ROM for the initial estimate.
- **Power:** Low marginal cost on top of the multiplier.
- **Verification:** High. The accuracy of the final iteration relative to the rounding-mode requirements (RISC-V round-toward-zero) is a common bug source.
- **Use case:** Designs that already have a fast pipelined multiplier and want a small, fast divider.

### 7. Shared MUL/DIV Iterative Unit (Multiplexed)

- **Mechanism:** A single iterative datapath (shift-add) handles both MUL and DIV by reconfiguring its datapath between operations.
- **Latency:** Same as iterative, but the unit cannot serve MUL and DIV concurrently.
- **Throughput:** MUL and DIV contend for the same unit.
- **Area:** Smallest. The most area-efficient option.
- **Power:** Lowest.
- **Verification:** Low to moderate. Single datapath, but dual-purpose microcode/sequencer.
- **Use case:** Cost-sensitive cores.

## Alternative Designs

Beyond the standard taxonomy, several non-obvious variants are worth considering:

### A. Pipelined Multiplier + Sequential Divider (Split Unit)

A fully pipelined radix-4 multiplier (e.g., 4-cycle latency) is paired with an independent 32-cycle sequential divider. The two units have separate reservation/issue logic.

- **Rationale:** MUL is far more frequent than DIV in most workloads. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches the workload asymmetry.
- **Cost:** Two reservation-station or issue-queue entries (relevant if the core is OoO); two small register files for intermediate state.

### B. Variable-Latency Divider (Speculative / Early-Quit)

Produce a 32-bit approximate quotient, sign-extend, and perform a single correction step. In many real programs the divisor has small magnitude, and the early-quit path saves cycles.

- **Risk:** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core.

### C. Radix-2 SRT with Carry-Save Quotient + Software Fixup

A radix-2 SRT with a 1-bit-per-cycle selection function and a carry-save quotient register. Faster than naive subtractive, simpler than radix-4 SRT.

- **Cost:** The quotient-to-2's-complement conversion is on the critical path or requires a final fixup step.

### D. Pipelined 2-bit-per-cycle "Naïve" Divider

Iterate two shift-subtract steps per cycle. Doubles divider throughput without an SRT selection table. Latency roughly halved vs. radix-1.

- **Cost:** Two 64-bit adders and a longer critical path. Area is moderate.

### E. Iterative Multiplier (Pipelined) + Lookup-Table Reciprocal + Multiply

A small reciprocal ROM (e.g., 12-bit seed) followed by a Newton-Raphson refinement step using the iterative multiplier. Yields a divider latency of a few multiplier iterations (e.g., 4–8 cycles).

- **Cost:** The Newton iteration must converge to enough bits of reciprocal precision to guarantee correct rounding toward zero for all 64-bit inputs. This typically requires a final exact-fixup step (one or two multiplies plus a comparison), and the precision / error analysis is non-trivial.

## Comparison

| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort | Notes |
|---|---|---|---|---|---|---|
| Shift-add MUL / subtractive DIV (iterative, shared) | 32–64 | ~1/32–1/64 | 0.3–0.5× | 0.3–0.5× | Low | Area-optimal, latency-poor |
| Radix-4 MUL + subtractive DIV | 32 (MUL) / 32–64 (DIV) | 1/32–1/64 | 0.7–1.0× | 0.7–1.0× | Moderate | Balanced, common in mid-range RV64 |
| Radix-4 MUL (pipelined) + SRT DIV | 4–8 (MUL) / 16–32 (DIV) | 1/cycle (MUL) | 1.0–1.4× | 1.0–1.5× | High | Desktop-class; verification-heavy |
| Radix-8 MUL (pipelined) + Newton-Raphson DIV | 2–4 (MUL) / 4–8 (DIV) | ≥1/cycle | 1.2–1.6× | 1.2–1.8× | High | High-performance, requires careful rounding-fixup |
| Pipelined radix-4 MUL + iterative DIV (split) | 4–8 (MUL) / 32–64 (DIV) | 1/cycle (MUL) | 0.9–1.2× | 0.9–1.2× | Moderate | Workload-asymmetric; RECOMMENDATION-CANDIDATE |
| 2-bit-per-cycle naïve DIV | 16–32 | 1/16–1/32 | 0.9–1.1× | 0.9–1.1× | Moderate | Compromise; no SRT selection table |

**Numbers are illustrative engineering estimates, not benchmark data.** The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1.

## Advantages

The leading candidates each have a distinct strength profile:

- **Iterative shared unit:** Smallest per-core area and lowest power, multiplying directly into 128-core replication savings.
- **Pipelined radix-4 MUL + iterative DIV (split):** Best workload asymmetry match; MUL throughput is high (common case), DIV cost is contained.
- **Pipelined radix-4 MUL + SRT DIV:** Highest predictable throughput on both operations; minimal front-end exposure.
- **Newton-Raphson DIV on top of fast MUL:** Reuses the multiplier's silicon; area-efficient if the multiplier is already large.

## Disadvantages

- **Iterative shared unit:** Latency directly stalls the pipeline in an in-order core. DIV latencies of 30–60 cycles are unacceptable for tight feedback loops.
- **Pipelined radix-4 MUL + iterative DIV:** DIV latency is still long. The dual-unit bookkeeping (two reservation stations, two issue paths) adds microarchitectural complexity.
- **Pipelined radix-4 MUL + SRT DIV:** Highest area and verification cost. SRT selection-table corner cases are a known source of post-silicon bugs. The verification cost is multiplied 128× in replication effort.
- **Newton-Raphson DIV:** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean spec for the correction step.

## XH-1 Considerations

**PROPOSAL (pending XH-1 baseline):** The XH-1 has not yet established a microarchitecture baseline. Several XH-1-specific factors bear on the MUL/DIV choice:

1. **128-core replication amplifies per-core area and verification cost.** A 1.5× area MUL/DIV unit is 1.5× across all 128 cores, not just one. The die-area cost is severe.
2. **Per-core issue width and in-order/OoO status are not established.** A wide-issue OoO core tolerates long-latency iterative dividers via scheduling; a narrow in-order core does not.
3. **128 cores imply a tile- or mesh-style interconnect.** Long-latency MUL/DIV operations that block a single core are local to that core; the rest of the machine is unaffected. This *favors* simpler per-core MUL/DIV implementations.
4. **Verification cost is replicated.** High-effort designs (SRT, Newton-Raphson fixup) need 128× the formal and random-verification runs.

**OPEN QUESTION:** What is the target workload mix for XH-1? Cryptographic, scientific, server, or general-purpose? Each has very different MUL/DIV demands.

## 128-Core Scalability

The MUL/DIV unit is per-core and not shared across cores (in the absence of a globally-shared execution unit, which is unusual for a 128-core design). Scalability considerations:

- **No coherence problem.** MUL/DIV operates on register values; the result is written to the integer register file, which is private to each core.
- **No cross-core contention.** Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior.
- **Verification parallelism.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once, but its integration with the core's pipeline must be verified 128×, unless formal methods prove equivalence.
- **Area-budget pressure.** If the per-core area budget is tight, the MUL/DIV unit competes with the L1 cache, branch predictor, and ROB for die area. Iterative implementations (subtractive DIV, iterative MUL) are most competitive in this regime.
- **Power-grid and clock distribution.** A replicated fast pipelined multiplier across 128 cores is a substantial clock-tree and switching load. Power delivery and clock skew must be analyzed for the replicated load.

**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128.

## Performance Considerations

MUL/DIV performance interacts with the rest of the core in two ways:

1. **Latency exposure.** In an in-order core, MUL latency stalls the front-end. In an OoO core, MUL latency is amortized as long as other independent instructions exist.
2. **Throughput-bound on dependent chains.** Tight loops of dependent MUL/DIV operations (e.g., big-integer arithmetic, hash functions, matrix multiplies) are throughput-bound, not latency-bound. For these, pipelined MUL at 1/cycle is essential.

**INSUFFICIENT EVIDENCE:** Without a target workload, no quantitative performance claim can be made.

## Area Considerations

Indicative relative area estimates (engineering estimates, not benchmark data):

| Unit | Relative Area (per core) |
|---|---|
| Iterative MUL + iterative DIV (shared) | ~0.3–0.5× of "full" unit |
| Radix-4 pipelined MUL + iterative DIV (split) | ~0.7–0.9× |
| Radix-4 pipelined MUL + radix-4 SRT DIV | ~1.0–1.2× |
| Radix-8 pipelined MUL + Newton-Raphson DIV | ~1.2–1.5× |

**Per 128 cores, a "full" 1.0× unit is 128 unit-areas.** A 0.3× unit is 38 unit-areas — a significant die-area delta. The XH-1 per-core area budget must be defined before this can be quantified.

## Power and Energy Considerations

Power and energy per operation, ranked from most to least efficient:

- **Iterative:** Low per-cycle power, but high per-operation energy × time product (many cycles × dynamic power).
- **Pipelined MUL + iterative DIV:** Low per-op MUL energy, high per-op DIV energy.
- **Pipelined MUL + SRT DIV:** High per-cycle power, but low per-op energy.
- **Pipelined MUL + Newton-Raphson DIV:** Per-op energy is a small multiple of MUL energy; competitive.

**PROPOSAL:** Energy-per-operation, not energy-per-cycle, is the more relevant metric for a workload-bound design. A pipelined radix-4 MUL with an iterative DIV is a reasonable energy-vs-area compromise.

## Implementation Considerations

- **Wallace/Dadda tree synthesis risk.** Compressor trees are notoriously hard to place-and-route at high frequency on modern nodes. A poorly placed adder tree can cost 100+ ps of unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon.
- **PPG and Booth recoder verification.** Radix-4 PPGs are easy to verify by simulation; radix-8+ PPGs require more corner cases.
- **SRT selection table correctness.** Selection tables must be proven correct for all operand values. This typically requires exhaustive enumeration for reduced operand widths and extensive directed testing for full width.
- **RISC-V division-by-zero convention.** `-1` for `DIV`/`DIVU`, `dividend` for `REM`/`REMU`. Must be implemented explicitly; the design must not return a trap.
- **Pipeline interlocks.** If MUL is pipelined, the in-order scoreboard or the OoO wakeup logic must handle in-flight MULs; this is a per-instruction-record cost.
- **Physical design replication.** A 128-core replicated design benefits from a small, regular MUL/DIV unit. Highly irregular SRT selection logic and complex PPGs resist clean replication.

## Verification Considerations

Verification cost is the dominant non-silicon cost in modern CPU design. The MUL/DIV unit is a known hot-spot for bugs:

- **Radix-2/4 shift-add and subtractive:** Lowest. Exhaustive simulation at reduced widths is tractable.
- **Radix-4 Booth + iterative DIV:** Moderate. Corner cases around `MULHSU` and signed division overflow.
- **SRT:** High. SRT selection-table bugs are famous in industry (e.g., the Pentium FDIV bug, though that was a different radix); verification typically requires formal proofs of the selection function.
- **Newton-Raphson:** High. Rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the final fixup step.
- **Replication factor:** A bug in the MUL/DIV unit is potentially a bug in all 128 cores. Bugs that manifest only at certain operand combinations are particularly dangerous.

**RECOMMENDATION:** Verification cost should be a first-class input to the MUL/DIV design decision. A simpler, more easily verified design is preferable to a faster, harder-to-verify one, unless the performance delta is necessary for the XH-1 target workload.

## Software Considerations

- **Compiler expectations.** GCC and LLVM default to MUL/DIV idioms for multiplication by constants when the multiplier is not auto-converted. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences.
- **Library code.** libgcc, compiler-rt, and the C library contain hand-written multiplication and division routines (e.g., for `__divti3`, `__udivti3`). These may use the MUL/DIV instructions in tight loops, exposing the unit's throughput directly.
- **System software.** Hash functions, AES-GCM polynomial multiplication, modular exponentiation in cryptography, and big-integer arithmetic in language runtimes are all MUL-throughput sensitive.
- **128-core interaction.** The system stack (kernel, hypervisor) will run on some subset of the 128 cores. There is no asymmetric design implication: every core is equal.

**INSUFFICIENT EVIDENCE:** XH-1's target software ecosystem is unknown. Bare-metal, Linux, or richer OS support each imply different MUL/DIV usage profiles.

## Recommendation

**No final recommendation is made at this time.** The MUL/DIV design is contingent on three decisions that are not yet established in the XH-1 repository:

1. The core microarchitecture (in-order vs. OoO, issue width, pipeline depth).
2. The per-core area and power budget.
3. The target workload mix and software ecosystem.

**Conditional recommendations** (to be revisited once the above are known):

- **If XH-1 targets an in-order core with tight area budget:** A single shared iterative shift-add MUL and subtractive DIV unit is the smallest, easiest-to-verify choice. MUL/DIV latency will be high, but the area × 128 replication argument is decisive.
- **If XH-1 targets a wide-issue OoO core with relaxed area budget:** A pipelined radix-4 Booth multiplier (4–8 stage pipeline) paired with a radix-4 SRT or 2-bit-per-cycle naïve divider is the natural choice. MUL throughput at 1/cycle; DIV throughput at 1/16 to 1/32 cycle.
- **If the per-core area budget is moderate and the workload is balanced:** A pipelined radix-4 MUL with an iterative 32-cycle subtractive DIV (the "split" approach) is a strong compromise.

**Cross-cutting recommendation:** Defer any design that depends on a non-trivial final correction step (SRT error correction, Newton-Raphson rounding fixup) until those algorithms have been formally specified and proven correct on reduced widths.

## Confidence

| Topic | Confidence |
|---|---|
| Taxonomy of MUL/DIV approaches | High (canonical, well-known) |
| Relative area and power rankings | Medium (qualitative, no synthesis data) |
| Per-cycle latency numbers | Medium (typical, but node- and target-frequency-dependent) |
| Suitability for XH-1 specifically | **Low** (XH-1 microarchitecture not yet established) |
| Specific recommendation | **Insufficient evidence** to commit |

## Open Questions

1. Is the XH-1 core in-order or out-of-order? Issue width? Pipeline depth? Target frequency?
2. What is the per-core area budget, in absolute terms or as a fraction of die area?
3. What is the target workload mix (cryptographic, HPC, server, general-purpose, embedded)?
4. Will XH-1 implement the "B" (bitmanip) extension, which adds many pseudo-multiplication operations? If so, the MUL/DIV unit may be partially reused.
5. Is the 128-core fabric a true SMP (Linux runs on all 128 cores), or is it a heterogeneous mix (e.g., application cores + management cores)? This affects MUL/DIV uniformity requirements.
6. What is the target process node? Node geometry strongly affects the area and timing trade-offs of Booth vs. array multipliers.
7. Will the MUL/DIV unit be hardened as a macro and replicated 128 times, or will it be synthesized per-core? Hardening is favored for area/power; synthesis-per-core favors design flexibility.
8. Is there an asymmetric verification budget for the MUL/DIV unit, or is verification cost unconstrained?
9. Does XH-1 need a 64×64→128-bit MUL for the upper-multiply operations to be single-cycle, or is multi-cycle acceptable?
10. What is the expected frequency of `DIV`/`REM` instructions in the target workload? Server workloads may have many fewer than scientific workloads.

## Sources

- **INSUFFICIENT EVIDENCE.** No XH-1-internal sources exist for this topic. The repository document `research/03-core-design/mul-div-unit.md` is itself a stub ("SOON"), and all sibling documents in `research/03-core-design/` are stubs. No prior architectural decisions are recorded.
- No external citations, papers, benchmarks, or measurements have been invented for this document. All comparative claims are framed as engineering estimates or as canonical background knowledge in the field of computer arithmetic.
