# 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. Quantitative comparisons are presented only as qualitative relative magnitudes, never as benchmark figures.

## 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 dividers, Newton-Raphson dividers, subtractive dividers, and SRT dividers) 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 any 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, FP multiplier) 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 *not* twice the area of a lower-only 64×64→64 multiplier when the multiplier is implemented as a single full-width partial-product / carry-save tree. The 64×64→128 result is generated by the same array; the carry-save adder tree is slightly deeper and wider, and a final carry-propagate adder is needed to collapse the upper half. Standard practice in open RISC-V cores (e.g., Rocket, BOOM, XiangShan) is to share one partial-product array between `MUL`, `MULH*`, and the FP multiplier, with operand- and result-muxing. The "upper-only" mode is therefore a small incremental cost over the lower-only mode, not a doubling.
- **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` is conventionally implemented by sign- or zero-extending the signed operand to a full-width signed/unsigned operand and reusing the unsigned 64×64→128 array; the verification burden is therefore small once the unsigned array is correct. By contrast, signed division has two non-trivial edge cases: division by zero (RISC-V returns `-1` for `DIV`/`DIVU`, and the dividend for `REM`/`REMU`) and the signed overflow case `INT64_MIN / -1`, where the mathematical quotient is `INT64_MIN` itself. Hardware that does not detect this case explicitly will return the wrong result.
- **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 unless explicit forwarding is provided.

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. References: standard computer-arithmetic texts (e.g., Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*) cover these techniques in canonical form. No XH-1-internal prior art exists.

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

- **Mechanism:** A 64-bit multiplier is implemented as a state machine that processes one partial-product bit per cycle against a 128-bit accumulator (or a 129-bit accumulator with a sign-preconditioned variant). Signed operands are typically sign-extended, not handled by halving the iteration count.
- **Latency:** Approximately 64 cycles for a 64-bit operand, plus a small constant for sign/result correction.
- **Throughput:** One multiply per ~64 cycles.
- **Area:** Very small. Roughly one wide adder + one shifter + one accumulator register.
- **Power:** Low. Minimal clocked area per cycle.
- **Verification:** Low complexity. Straightforward to model and exhaustively test at small operand widths.
- **Use case:** Embedded in-order cores 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). Over a 64-bit operand, the standard radix-4 Booth encoding produces 32 partial-product rows, and an *iterative* radix-4 multiplier performs the additions in roughly 16 cycles (two operand bits consumed per iteration against a running accumulator). Implemented as a single combinational Wallace/Dadda tree, the same 32 partial-product rows are summed in one cycle, with the tree depth determining the achievable clock period.
- **Latency:** ~16 cycles iterative, or one combinational tree of ~8–16 levels of CSA + a final CPA, optionally broken into pipeline registers.
- **Throughput:** One multiply per 16 cycles iterative; 1/cycle if the array is fully pipelined.
- **Area:** Moderate. Recoder + partial-product array + carry-save adder tree + final CPA.
- **Power:** Moderate to high. The Wallace/Dadda tree toggles aggressively, and clock-tree load on a replicated array is non-trivial.
- **Verification:** Moderate. The corner cases that matter are the signed overflow cases (not the `MULHSU` path, which is essentially free given a correct unsigned array).
- **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 further reduces partial-product rows (radix-8 reduces by 3×, radix-16 by 4× relative to radix-2). The cost is in the partial-product generator (PPG): radix-8 requires 3× multiples; radix-16 requires 3×, 5×, 7× multiples (or a 3×/5× combination plus a higher-order term) and is therefore considerably more complex than radix-4.
- **Latency:** The fully pipelined radix-4 array can already achieve 1/cycle throughput; higher radices reduce the *depth* of the adder tree (fewer partial-product rows to sum) and therefore either shorten the critical path or allow fewer pipeline stages. The throughput is not increased beyond 1/cycle unless the array is duplicated.
- **Throughput:** 1/cycle for a single pipelined array; not inherently higher than radix-4.
- **Area:** Larger PPG; smaller (shallower) adder tree. Net area is roughly comparable to radix-4.
- **Power:** Mixed. Fewer adder levels, but more complex PPG.
- **Verification:** Higher. Radix-8+ PPGs have more corner cases and the recoding is harder to prove correct.
- **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 the operand width. Produces quotient (and optionally remainder) one bit per cycle.
- **Latency:** Roughly 64 cycles for a 64-bit operand (plus a small constant for sign correction).
- **Throughput:** One divide per ~64 cycles.
- **Area:** Small. A 64- or 65-bit ALU with quotient/remainder registers.
- **Power:** Low.
- **Verification:** Moderate. The division-by-zero convention, the `INT64_MIN / -1` overflow case, and the `REM`/`REMU` dividend-return case must all be implemented and tested explicitly. The signed-dividend path is the principal source of bugs.
- **Use case:** In-order cores with low expected DIV frequency.

### 5. Radix-4 SRT Divider

- **Mechanism:** Higher-radix SRT produces 2 (radix-4) or more quotient digits per iteration by selecting one of several shifted multiples of the divisor from a selection table indexed by a truncated partial remainder.
- **Latency:** ~16 to 32 cycles for a 64-bit operand.
- **Throughput:** One divide per 16–32 cycles.
- **Area:** Substantially larger than subtractive. Requires a redundant (carry-save) quotient representation, a quotient-digit selection table, and partial-quotient error-correction logic.
- **Power:** Higher.
- **Verification:** High. SRT selection tables have notoriously tricky corner cases, and partial-quotient error correction has been the source of silicon bugs in commercial designs (the classic example is the Pentium FDIV bug, which was a radix-4 SRT selection-table defect — the same general technique, not a fundamentally different radix). Verification typically requires formal proofs of the selection function over reduced operand widths plus extensive directed testing.
- **Use case:** High-frequency OoO cores needing higher DIV throughput.

### 6. Goldschmidt Divider (Reciprocal Multiplication)

- **Mechanism:** Iteratively refine an initial reciprocal estimate, then multiply by the dividend. Each iteration multiplies both the partial remainder and the partial quotient by a correction factor derived from a short reciprocal estimate. Distinct from Newton-Raphson (see §7).
- **Latency:** A few multiply iterations. 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 final iteration must converge to enough bits of precision to guarantee correct rounding toward zero for all 64-bit inputs, which typically requires a final exact-fixup step. The accuracy analysis is non-trivial and historically a bug source.
- **Use case:** Designs that already have a fast pipelined multiplier and want a small, fast divider.

### 7. Newton-Raphson Divider (Reciprocal Multiplication)

- **Mechanism:** Iteratively refine an initial estimate of the divisor's reciprocal using a Newton-Raphson step, then multiply the dividend by the refined reciprocal. Each iteration squares the error, so convergence is quadratic. Distinct from Goldschmidt, which uses a multiplicative correction on both the partial remainder and the partial quotient simultaneously; the two algorithms have different error dynamics and different fixup requirements.
- **Latency:** A few iterations of multiply-add. Typically fewer iterations than Goldschmidt to reach a given precision, but each iteration is a full multiply.
- **Throughput:** Bounded by the multiplier.
- **Area:** Reuses the multiplier. Adds lookup-table ROM for the initial estimate and modest control logic.
- **Power:** Low marginal cost on top of the multiplier.
- **Verification:** High. The final-step rounding-toward-zero correctness across all 64-bit input pairs requires a careful proof of the fixup step.
- **Use case:** Designs with a fast pipelined multiplier that want a low-latency divider.

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

- **Mechanism:** A single iterative datapath handles both MUL and DIV by reconfiguring its datapath between operations.
- **Latency:** Same as the underlying iterative unit; 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 sequential subtractive divider. The two units have separate reservation/issue logic.

- **Rationale:** Under many server, desktop, and general-purpose workloads, MUL is more frequent than DIV, but the ratio is workload-dependent and should not be assumed a priori. Giving MUL a fast pipelined datapath and DIV a slow sequential one matches a plausible 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 partial-width approximate quotient, sign-extend, and perform a single correction step on the remaining bits. The early-quit path saves cycles when the divisor has small magnitude.

- **Risk:** Variable latency complicates the scoreboard / wakeup logic in an OoO core, or stalls the pipeline in an in-order core. This can be partially mitigated by a fixed maximum latency with early completion, at the cost of additional control logic.

### C. Radix-2 SRT with Carry-Save Quotient + Software/Hardware 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. Roughly halves divider latency relative to radix-1 subtractive without requiring an SRT selection table.

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

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

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.

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

### F. Shared Multi-Cycle Divider Across Cores (Divider Co-Processor)

A small number of high-throughput dividers (e.g., 4 or 8) placed at fixed points in the fabric and dispatched to by cores via a memory-mapped or message interface. The dividers are not private to any core.

- **Rationale:** Avoids replicating the divider 128×. Trades single-core latency (now includes a fabric round-trip) for amortized area.
- **Cost:** NOC traffic, dispatch latency, contention at the divider, and software-visible ABI changes (or a transparent-but-slow trap path).
- **Status:** Unusual but not unprecedented in accelerator-rich many-core designs.

### G. FP / Integer Multiplier Sharing

Share the integer multiplier's partial-product array and adder tree with the FP pipeline. Standard in Rocket, BOOM, and most SiFive cores.

- **Rationale:** Avoids replicating a wide datapath. The FP pipeline also benefits from a fast multiplier.
- **Cost:** Cross-unit scheduling and bypassing complexity. The integer and FP pipelines may have different latency targets.

### H. Latency-Tolerant In-Order MUL/DIV

Even a multi-cycle iterative MUL/DIV may be tolerable in an in-order core if the result-bus supports forwarding directly from the MUL/DIV output to dependent consumers, bypassing the register file writeback-read path.

- **Cost:** Forwarding path length and bypass-network complexity scale with MUL/DIV latency.

### I. Interaction with the "B" (Bitmanip) Extension

The RISC-V Bitmanip extension introduces MUL/DIV-adjacent operations (e.g., `CLZ`, `CTZ`, `MIN`, `MAX`, bit-extract/deposit, and several pseudo-multiplication idioms such as `RORI` and `SH*ADD`). If the B extension is in scope, the MUL/DIV unit may either be reused for some of these (e.g., via the ALU) or augmented with dedicated bitmanip datapath. The decision is interdependent with the MUL/DIV choice and is flagged as an open question below.

## Comparison

The following table presents *qualitative* relative magnitudes only. No node, frequency, or synthesis data is available for XH-1, so quantitative ratios are not asserted.

| Approach | Latency (cycles) | Throughput (ops/cycle) | Relative Area | Relative Power | Verification Effort |
|---|---|---|---|---|---|
| Shift-add MUL / subtractive DIV (iterative, shared) | ~64 | ~1/64 | Smallest | Smallest | Low |
| Iterative radix-4 MUL + subtractive DIV | ~16 (MUL) / ~64 (DIV) | ~1/16 (MUL) | Small to moderate | Small to moderate | Low to moderate |
| Radix-4 array MUL (pipelined) + subtractive DIV (split) | ~4–8 (MUL) / ~64 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
| Radix-4 array MUL (pipelined) + radix-4 SRT DIV | ~4–8 (MUL) / ~16–32 (DIV) | 1/cycle (MUL) | Large | Large | High |
| Radix-8 array MUL (pipelined) + Newton-Raphson or Goldschmidt DIV | ~3–6 (MUL) / ~4–8 (DIV) | 1/cycle (MUL) | Largest | Largest | High |
| 2-bit-per-cycle naïve DIV (paired with radix-4 MUL) | ~4–8 (MUL) / ~32 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |
| Pipelined radix-4 MUL + iterative DIV (split) | ~4–8 (MUL) / ~64 (DIV) | 1/cycle (MUL) | Moderate | Moderate | Moderate |

The relative magnitudes are illustrative and intended only to convey ordering. The actual ratios depend on the target process node, synthesis library, and clock target, none of which are known for XH-1.

**INSUFFICIENT EVIDENCE:** Quantitative area, power, and energy comparisons cannot be made without a target node, frequency, and synthesis flow.

## 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. Easiest to verify.
- **Pipelined radix-4 MUL + iterative DIV (split):** Best workload-asymmetry match if MUL is in fact more frequent than DIV in the target workload; 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 if the core is in-order.
- **Newton-Raphson or Goldschmidt 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. Long DIV latencies are problematic for tight feedback loops unless forwarding is provided.
- **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 Pentium FDIV bug being a radix-4 SRT defect). The verification cost is multiplied 128× in replication effort.
- **Newton-Raphson / Goldschmidt DIV:** Rounding-toward-zero correction is subtle; commercial implementations have shipped with latent bugs in this path. Not recommended without a clean, formally-specified 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 larger MUL/DIV unit pays the same area cost 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, unless explicit forwarding is provided.
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, unless a shared divider alternative (§F) is adopted.
4. **Verification cost is replicated.** High-effort designs (SRT, Newton-Raphson fixup) need 128× the formal and random-verification runs.
5. **Physical-design regularity matters under replication.** A small, regular MUL/DIV unit is easier to harden and replicate 128× than a complex, irregular SRT unit.

**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 by default. 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** in the default per-core configuration. Unlike shared caches or interconnects, the MUL/DIV unit does not introduce hot-spot behavior. A shared-divider alternative (§F) changes this analysis.
- **Verification parallelism.** A 128-core machine can be partitioned for verification; the MUL/DIV unit is verified once at the unit level, but its integration with the core's pipeline must be verified 128×, unless formal methods prove equivalence across replications.
- **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 (IR drop), clock skew across the replicated load, and dynamic power density must be analyzed for the replicated load.
- **Scan and BIST.** A 128× replicated unit implies 128× the scan-chain length (if scan is per-core) or a partitioned BIST architecture. The choice affects DFT area and test time.
- **Fault tolerance.** A defect in the MUL/DIV unit is potentially a defect in all 128 cores. This argues for either a hardened, characterized macro or built-in redundancy / sparing, depending on yield targets.
- **Timing variation.** Across-die process variation affects 128 replicated units independently. A design that is timing-marginal at one corner may fail at another. Iterative designs are less sensitive to per-unit timing variation than deep-pipelined arrays.

**PROPOSAL:** Favor an implementation whose area × power product is small, since both costs multiply by 128. Prefer regular, hardenable structures over irregular ones that resist replication.

## 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 unless explicit forwarding is provided. 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

Relative area ordering, qualitative only (no synthesis data available):

- Iterative MUL + iterative DIV (shared): smallest.
- Iterative radix-4 MUL + subtractive DIV: small to moderate.
- Pipelined radix-4 MUL + iterative DIV (split): moderate.
- Pipelined radix-4 MUL + radix-4 SRT DIV: large.
- Pipelined radix-8 MUL + Newton-Raphson / Goldschmidt DIV: largest.

The XH-1 per-core area budget must be defined before any of the above can be quantified in absolute terms.

**INSUFFICIENT EVIDENCE:** Absolute area figures require a process node and a synthesis flow.

## Power and Energy Considerations

Relative energy-per-operation ordering, qualitative only:

- **Iterative:** Low per-cycle power, but high per-operation energy × time product (many cycles).
- **Pipelined MUL + iterative DIV:** Low per-op MUL energy, high per-op DIV energy.
- **Pipelined MUL + SRT DIV:** High per-cycle power, lower per-op energy than iterative.
- **Pipelined MUL + Newton-Raphson / Goldschmidt 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, contingent on the workload.

**INSUFFICIENT EVIDENCE:** Quantitative power and energy figures require a process node, a clock target, and a workload trace.

## Implementation Considerations

- **Wallace/Dadda tree synthesis risk.** Compressor trees are notoriously hard to place-and-route at high frequency on modern nodes. Poor placement can introduce unexpected delay. This favors iterative or low-radix designs for first-pass XH-1 silicon. (No specific delay figure is asserted; the qualitative risk is well-known in the literature.)
- **PPG and Booth recoder verification.** Radix-4 PPGs are well-understood and tractable to verify; 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 and overflow conventions.** `-1` for `DIV`/`DIVU` on divide-by-zero; the dividend for `REM`/`REMU` on divide-by-zero; `INT64_MIN` for `INT64_MIN / -1` on signed overflow. These must be implemented explicitly; the design must not raise 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 and are a physical-design risk under 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. The hard cases are the signed division edge cases (division-by-zero, `INT64_MIN / -1`), not the `MULHSU` path. The unsigned 64×64→128 array, once verified, covers `MUL`, `MULHU`, and `MULH` (with sign handling); `MULHSU` is a sign-extension of the signed operand to a full-width signed/unsigned form and is essentially free given a correct unsigned array.
- **SRT:** High. SRT selection-table bugs are famous in industry (e.g., the Pentium FDIV bug was a radix-4 SRT selection-table defect). Verification typically requires formal proofs of the selection function over reduced widths and extensive directed testing.
- **Newton-Raphson / Goldschmidt:** 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.

**Preliminary verification strategy** (to be refined once the design choice is made):

- **Unit-level:** Exhaustive simulation at reduced operand widths (e.g., 8, 12, 16 bits) for the core datapath. Formal equivalence checking between the RTL and a reference model written in a high-level specification language (e.g., Bluespec, Scala, or a C reference). For SRT or Newton-Raphson, formal proof of the selection function or the convergence step.
- **Directed corner-case suite:** Explicit tests for division-by-zero, signed overflow (`INT64_MIN / -1`), the `REM`/`REMU` dividend-return case, `MULHSU` against a cross-checked reference, and the `MUL`-then-truncate boundary.
- **Random / constrained-random:** At full width, comparing against a software reference. Coverage targets on the Booth recoder, PPG, and selection table.
- **Integration:** Per-core pipeline integration verified 128× unless formal equivalence is established across replications.
- **Post-silicon:** Microarchitectural validation suite, focused on MUL/DIV-intensive kernels (big-integer arithmetic, hashes, polynomial multiplications).

**PROPOSAL:** 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 behavior.** GCC and LLVM routinely use shift-and-add sequences for multiplication by small constants, and they may either emit `MUL` instructions or inline expansions depending on the cost model. The cost of a long-latency MUL or DIV may push the compiler toward suboptimal code sequences, but the magnitude of this effect is workload- and compiler-version-dependent and should not be assumed.
- **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 in the default per-core configuration.

**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; whether this is acceptable depends on whether explicit forwarding is provided.
- **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 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 / Goldschmidt 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, power, and energy rankings | Low to medium (qualitative ordering only; no synthesis data) |
| Per-cycle latency numbers | Low to 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 or augmented.
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 and replication regularity; 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.
11. Will the MUL/DIV unit be shared with the FP pipeline (as in Rocket / BOOM), or kept private to the integer pipeline?
12. Will XH-1 adopt a shared multi-cycle divider across cores (Alternative F), or is a strictly per-core MUL/DIV unit required?

## Sources

- Canonical computer-arithmetic references: Parhami, *Computer Arithmetic*; Ercegovac and Lang, *Digital Arithmetic*; Hennessy and Patterson, *Computer Architecture*. These cover the techniques surveyed above in standard form.
- Open RISC-V core implementations (Rocket, BOOM, XiangShan, SiFive) provide reference designs for radix-4 array multipliers, iterative and SRT dividers, and FP/integer multiplier sharing. These are cited as implementation exemplars, not as XH-1 references.
- **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 qualitative engineering estimates or as canonical background knowledge in the field of computer arithmetic.
