# Multiply-Divide Unit

## Status

Engineering research document, pre-synthesis. All quantitative values below are explicitly labeled as unvalidated estimates or marked INSUFFICIENT EVIDENCE where no source can be cited. No measurement against a target technology library, layout, or workload has been performed for XH-1.

## Abstract

The multiply-divide (MUL/DIV) unit implements the integer multiplication and division instructions defined by the M extension of the RISC-V ISA (combined with the base I extension; usually written RV64I + M, also expressed as RV64IM when the integer base is implicit). In XH-1, the MUL/DIV unit sits on the execution path of each of the 128 cores, and its latency, throughput, area, and energy directly influence per-core performance and the die-level power and thermal envelope. This document surveys existing MUL/DIV architectures (iterative, array, Radix-4/8 Booth, array-of-serial, and Sutherland/Robertson / non-restoring / SRT division), compares their trade-offs across per-core and shared organizations, and proposes a design direction suitable for a 128-core RISC-V processor where replication, area, and energy are first-class constraints.

## Research Question

What MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:

- Per-core area must be small enough to replicate the unit 128 times on one die, or alternatively the unit must be shared across a small cluster of cores with acceptable latency and contention.
- The pipeline stage budget for the EX stage is finite (TBD by `pipeline.md`).
- The unit is on a non-critical path for most general-purpose code but is on the critical path for scientific, cryptographic, hash, and DSP workloads.
- IEEE 754 floating-point support is out of scope for this document; only integer MUL/DIV is considered. F/D extension implications are listed as an open question.
- Verification must scale to 128 cores; deterministic, fully combinational MUL and bounded-iteration DIV designs simplify verification.

## Background

### Required Instructions (RV64I + M)

The M extension defines the following on RV64:

- MUL, MULH, MULHSU, MULHU: 64×64 → 128-bit multiply, returning the lower 64 bits (MUL) or the upper 64 bits (MULH and its signed/unsigned variants).
- DIV, DIVU, REM, REMU: 64-bit signed/unsigned divide and remainder.
- MULW, DIVW, REMW: 32×32 → 32-bit signed multiply and signed divide, sign-extended to 64 bits.
- DIVUW, REMUW: 32×32 → 32-bit unsigned divide, sign-extended to 64 bits.

The header of the previous revision referred to "RV64IM (and optionally M-extension)," which is incoherent because M is part of RV64IM by definition. In this document the scope is the M extension on RV64I.

### Latency and Throughput Ranges (Background Only)

Published RISC-V cores report the following approximate ranges. These are background reference values from named open cores; they are not measurements of XH-1.

| Operation        | Reported latency range (cycles) | Reported throughput      | Source basis                          |
|------------------|---------------------------------|--------------------------|---------------------------------------|
| MUL (lower 64)   | 1–5                             | 1/cycle (pipelined)      | Rocket, BOOM Small, Ariane (claimed)  |
| MULH (upper 64)  | 2–6                             | 1/cycle (pipelined)      | Same                                  |
| DIV/REM (64-bit) | 8–40                            | 1 per N cycles           | Same                                  |
| MULW/DIVW family | similar to 64-bit variants      | similar                  | Same                                  |

The exact latency in any given core depends on the EX-stage timing budget, the process corner, and the divider radix. INSUFFICIENT EVIDENCE exists in the XH-1 repository to pin XH-1 to a specific cycle count.

### Division Algorithms (Background)

- Restoring division: simple, one bit per iteration, simple control, slow.
- Non-restoring division: similar iteration count, slightly smaller area than the array form, well-suited to iterative implementation.
- SRT division (radix-2, radix-4, radix-16): quotient-digit selection allows more than one bit per iteration. Higher radix reduces iteration count at the cost of more complex selection logic and a larger redundant residual representation.
- Newton–Raphson reciprocal multiplication: pre-computes an approximation of the reciprocal via iteration, then multiplies. Low latency for many operand classes, but variable latency and convergence-dependent.
- Goldschmidt division: similar trade-off to Newton–Raphson.

### Multiplication Algorithms (Background)

- Shift-and-add multiplier: simple, slow, one bit per cycle.
- Array (Braun / Baugh–Wooley) multiplier: combinational, O(n²) partial products and full-adders, deterministic single-cycle latency, large area.
- Wallace / Dadda tree multiplier: O(n log n) partial-product reduction using 3:2 and 4:2 compressors; faster critical path, less regular layout.
- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count by roughly 2× (radix-4) or 3× (radix-8) compared to a naive array.
- Compressor-tree implementations (3:2 counters, 4:2 compressors, Ling / Han–Carlson adders) trade area for shorter critical paths.

## Existing Approaches (Per-Core, Unless Noted)

The following architectures are well-known and serve as comparison baselines. All area-multiplier numbers in this section are unvalidated estimates; no synthesis has been performed.

### A1. Iterative Shift-and-Add Multiplier + Restoring Divider

- Multiplier: 64 cycles, 1 bit/cycle.
- Divider: 64 cycles (restoring) or ~64 cycles (non-restoring).
- Area: very small. Used as the 1× baseline in the comparison table.

### A2. Booth-Radix-4 Multiplier + Iterative Non-Restoring Divider

- Multiplier: 32 radix-4 digits → 33 partial products (including the sign-extension row) reduced through a Wallace/Dadda or 4:2 tree. Two pipeline stages; 2-cycle latency, 1/cycle throughput.
- Divider: ~64-cycle non-restoring, 1/64 throughput.
- Area: estimated ~3–4× of A1; INSUFFICIENT EVIDENCE without a technology file.

### A3. Pipelined Radix-4/8 Booth Multiplier + Radix-4 SRT Divider

- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.
- Divider: radix-4 SRT, ~16 cycle latency. If pipelined internally, throughput approaches 1/cycle on independent operands; if not pipelined, throughput is 1/16. The SRT-4 in this class is typically not deeply pipelined in published small RV cores.
- Area: estimated ~5–7× of A1; INSUFFICIENT EVIDENCE without a technology file.

### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider

- Multiplier: 64×64 → 128 in a single cycle, large area.
- Divider: 4–8 cycle latency via radix-16 selection.
- Area: estimated ~10–15× of A1; INSUFFICIENT EVIDENCE without a technology file.

### A5. Shared / Clustered MUL/DIV Unit

- A single MUL/DIV unit serves N cores, accessed via a reservation station or blocking interface.
- Saves replicated area; increases latency under contention.
- A natural fit for 128-core designs only if inter-core divide/mul traffic is low or bursty.

This alternative was not analyzed in depth in the previous revision; it is included here as a candidate organization.

## Alternative Designs (Per-Core, Unless Noted)

### B1. 2-Stage Pipelined Radix-4 Booth Multiplier

- Radix-4 Booth encoding of two 64-bit operands produces 33 partial products (32 signed digit products plus one sign-correction row). The previous revision's "17 partial products" figure was incorrect and is corrected here.
- Partial-product reduction through a 4:2 compressor tree, followed by a final carry-propagate add split across two pipeline stages.
- Latency 2 cycles, throughput 1/cycle.
- Divider: 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency; "early-exit" optimizations (e.g., leading-zero detection on the divisor, trailing-zero detection on the dividend to shift out low bits before the loop) reduce typical-case latency but the worst case remains 32 cycles. The previous revision named the optimization without describing it; the description is provided here.
- Area: estimated ~3–5× of A1; INSUFFICIENT EVIDENCE without a technology file.

### B2. 3-Stage Pipelined Radix-8 Booth Multiplier

- 11 partial products for a 64-bit operand (one per 3-bit window plus sign correction).
- Latency 3 cycles, throughput 1/cycle.
- Smaller critical path than B1 at the cost of higher area and more complex Booth-3 encoding.

### B3. Iterative Multiplier with Multi-Cycle Variable Latency

- A single 64×64 multiplier reused across MUL/MULH/MULHSU/MULHU by selecting output bits.
- Latency 4–5 cycles, 1/cycle throughput.
- Smaller area than B1; longer issue-to-use distance complicates scheduling.

### B4. Pipelined Radix-4 SRT Divider

- 16-cycle latency when issued back-to-back with different operands. The previous revision was internally inconsistent (text said fully pipelined, table said 1/16 throughput). For this document, B4 is treated as a 16-cycle-latency, 1/16-throughput non-pipelined unit; a fully pipelined SRT-4 with 1/cycle throughput would add ~3–4× the divider area and is a separate design point (B4-pipe).
- Larger area than B1's divider, more verification complexity (quotient-digit selection must be proven correct for all residuals).

### B5. Newton–Raphson Divider with Hardware Reciprocal Iteration

- ~4–6 cycles for 32-bit reciprocal convergence on typical operands, then one multiply.
- Lowest divide latency for many operand classes, but variable and dependent on operand class (convergence count is worst-case bounded but typical-case data-dependent).
- Complex verification: requires convergence proof or guarded iteration count plus a fallback path.

### B6. Two's-Complement Array Divider (Combinational)

- Single-cycle 64-bit divide.
- Estimated very large area (order-of-magnitude larger than a 64-bit combinational multiplier, but INSUFFICIENT EVIDENCE for an exact ratio). The previous revision's "~50×" figure was an unsupported round number; the document does not retain it.
- Likely unacceptable for 128-core replication.

### B7. Cluster-Shared MUL/DIV Unit (8 cores per unit, 16 units total)

- A single radix-4 Booth + radix-4 SRT divider (B1 + B4) shared by 8 cores via a small reservation station.
- 16 instances on the die instead of 128.
- Per-cluster area budget can absorb a faster divider (e.g., B4-pipe or B5) than per-core replication allows.
- Latency and contention penalty under simultaneous divide requests.

## Comparison

The following table lists estimated per-unit characteristics. All numbers are unvalidated estimates pending synthesis. Relative area is normalized to A1 (1×); the actual ratios depend on the technology library, target frequency, and choice of final adder.

| Design                                          | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area (per unit) | Verification Complexity |
|-------------------------------------------------|-------------|----------------|-------------|----------------|--------------------------|-------------------------|
| A1. Shift-add + restoring                       | 64          | 1/64           | 64          | 1/64           | 1×                       | Low                     |
| A2. Booth-r4 + NR div                           | 2           | 1/1            | ~64         | 1/64           | ~3–4× (unvalidated)      | Low–Medium              |
| A3. Pipelined r4/r8 + SRT-4 (non-pipe)          | 2–3         | 1/1            | 16          | 1/16           | ~5–7× (unvalidated)      | Medium                  |
| A4. Combinational + SRT-16                      | 1           | 1/1            | 4–8         | 1/4–1/8        | ~10–15× (unvalidated)    | High                    |
| B1. 2-stage r4 + NR-32 (with early-exit)        | 2           | 1/1            | 32 worst    | 1/32           | ~3–5× (unvalidated)      | Low–Medium              |
| B2. 3-stage r8 + NR-32                          | 3           | 1/1            | 32 worst    | 1/32           | ~4–6× (unvalidated)      | Medium                  |
| B4. SRT-4 (non-pipelined)                       | n/a         | n/a            | 16          | 1/16           | adds ~3–4× to A2 (unvalidated) | Medium            |
| B4-pipe. SRT-4 (pipelined, 1/cycle)             | n/a         | n/a            | 16          | 1/1            | adds ~6–8× to A2 (unvalidated) | Medium–High      |
| B5. Newton–Raphson                              | 1           | 1/1            | 4–6         | 1/4–1/6        | ~6–8× (unvalidated)      | High                    |
| B6. Combinational array divider                 | 1           | 1/1            | 1           | 1/1            | very large (unvalidated) | Medium                  |
| B7. Cluster-shared (per 8 cores) B1 + B4-pipe  | 2           | 1/1            | 16          | 1/1 (when free) | per-cluster ~8–12× A1; ×16 instances (unvalidated) | Medium–High    |

The previous revision compared only per-core designs. The revised comparison adds B7 and notes the cluster organization explicitly, addressing the prior omission.

## Proposal (Resolved)

PROPOSAL: Adopt B1 (2-stage pipelined Radix-4 Booth multiplier, 33 partial products, 4:2 compressor tree, 2-cycle latency, 1/cycle throughput) paired with a 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency and an early-exit optimization for typical operands.

This resolves the prior contradiction between the abstract PROPOSAL (which named a pipelined SRT-4) and the final Recommendation (which named the 32-cycle non-restoring divider). The remaining sections are aligned to B1 + non-restoring 32-cycle divider.

Conditional variant: If early workload analysis (TBD) shows that 32-cycle divide latency is a bottleneck, upgrade the divider to B4-pipe (pipelined radix-4 SRT, 16-cycle latency, 1/cycle throughput) at an estimated additional ~3–4× divider area (unvalidated). This is a design knob, not a parallel recommendation.

Open variant: B7 (cluster-shared organization) is retained as a fallback if per-core area constraints prove tighter than estimated. The decision requires quantitative synthesis data that is not yet available.

## Advantages

- 2-cycle pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest per-core area, suitable for replicated 128-core operation.
- 32-cycle non-restoring iterative divider (with early-exit for typical operands) meets the latency needs of general-purpose code without dominating area.
- Deterministic latencies simplify pipeline scheduling, forwarding, and verification compared to Newton–Raphson.
- Radix-4 Booth and radix-2 non-restoring division are well-understood and have reference implementations in Rocket, BOOM, Ariane, and other open-source RISC-V cores (specific measurements: INSUFFICIENT EVIDENCE in the XH-1 repository).

## Disadvantages

- 32-cycle divide is slow for workloads dominated by large-integer arithmetic (RSA, big-integer math, certain cryptographic primitives). The conditional B4-pipe upgrade addresses this at additional area cost.
- Newton–Raphson dividers reduce typical latency for many operand classes but at unacceptable per-core verification cost for 128-core replication in the current design envelope.
- A non-restoring iterative divider has the lowest per-core area but penalizes every divide by up to 32 cycles, which can be felt in hash-table probing, parser/lexer dispatch, and some interpreter dispatch loops.
- Booth encoding complicates verification of signed/unsigned correctness for MULH / MULHSU / MULHU; the previous revision flagged this; it is reaffirmed here.

## XH-1 Considerations

- ASSUMPTION: XH-1 is a 128-core design with a short pipeline (TBD by `pipeline.md`). The MUL/DIV unit must fit in a small per-core area budget and the EX-stage latency budget.
- ASSUMPTION: The design targets a balance of general-purpose and HPC-adjacent workloads; therefore a moderately fast (but not the fastest) divider is acceptable as the default, with an explicit upgrade path.
- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.
- The W-variants (MULW, DIVW, DIVUW, REMW, REMUW) reuse the lower 32 bits of the 64-bit datapath with sign-extension at the output, not a separate 32-bit datapath.

### Instruction Coverage

- MUL/MULH/MULHSU/MULHU: supported.
- DIV/DIVU/REM/REMU: supported, with RISC-V-spec corner cases handled explicitly.
- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.

### Edge Cases (RISC-V Spec)

The following are the architecturally specified results. The previous revision contained an error in the DIVU-by-zero description; the corrected behavior is:

- DIV by zero: quotient = −1 (all bits set in the lower XLEN), remainder = dividend (x).
- DIVU by zero: quotient = 2^XLEN − 1 (all ones), remainder = dividend (x).
- REM by zero: remainder = dividend (x); quotient = −1.
- REMU by zero: remainder = dividend (x); quotient = 2^XLEN − 1.
- Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0.
- REM sign rule: the sign of the remainder follows the sign of the dividend. This is a frequent bug source and must be covered explicitly in verification; the previous revision did not call it out.

The unit must produce these results without raising an exception.

## 128-Core Scalability

- Per-core area: a small 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree, a 2-stage pipelined final adder, and a 32-cycle non-restoring divider is expected to be a small fraction of a typical RV core area, but the exact fraction is INSUFFICIENT EVIDENCE because no baseline core area has been established for XH-1. The previous revision's "<1–2% of a typical small RV core area" is removed because it lacked a baseline.
- Floorplanning: a regular MUL/DIV layout that mirrors across all 128 cores is preferred to avoid routing asymmetry that would break clock distribution and thermal symmetry.
- Voltage / frequency: a moderately pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.
- Contention: per-core replication means there is no inter-core contention for the MUL/DIV unit. The only contention is intra-core (e.g., two dependent divides in flight in an out-of-order pipeline). The cluster-shared B7 organization reintroduces inter-core contention; this is the central trade-off.
- Test / DFT: 128 instances of the MUL/DIV unit (or 16 instances in B7) must be tested. A scan-friendly, fully synchronous design with no asynchronous reset paths inside the iterative divider is preferable. DFT strategy is addressed in a dedicated section below.

## Performance Considerations

- For general-purpose code, MUL/DIV is rarely the bottleneck; a 2-cycle MUL latency matches typical issue-to-use distances.
- For cryptography, the relevant metric is MUL (lower 64) throughput, since Karatsuba and Montgomery multiplication depend on lower-half multiplies. The previous revision's claim that MULH throughput is the key for Karatsuba / Montgomery is not generally correct and is corrected here. MULH is the key metric for software-emulated 128-bit integer multiplication (`__int128`), not for Karatsuba / Montgomery in the typical formulation.
- For hash tables and interpreters, DIV latency matters more than throughput; a 32-cycle divider is acceptable but not ideal.
- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.

## Area Considerations

- ASSUMPTION (unvalidated): A 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree and 2-stage pipelined final adder occupies roughly 0.02–0.10 mm² in a typical 7nm process, depending on target frequency, Vdd, and FF corner. No source is cited; INSUFFICIENT EVIDENCE to refine this without a technology file.
- ASSUMPTION (unvalidated): A 32-cycle non-restoring iterative divider occupies roughly 0.01–0.05 mm² in the same envelope.
- PROPOSAL (unvalidated): Total MUL/DIV area target: <0.15 mm² per core. 128× replication: ~20 mm². These numbers are order-of-magnitude estimates and must be replaced with synthesis data before being used for die budgeting.
- The 4:2 compressor tree is a common implementation choice for radix-4 reduction. The previous revision's claim that it is "more area-efficient than a Wallace tree" is removed; Wallace and Dadda trees implemented with 4:2 compressors are not generally distinguishable in area for radix-4 reduction, and the choice is largely a layout / regularity preference. INSUFFICIENT EVIDENCE to prefer one over the other without synthesis.
- Sign-extension and zero-extension muxes for MULW are negligible area.

## Power and Energy Considerations

- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.
- The iterative divider has lower average switching power than a fully combinational divider, but its long residency increases leakage energy per operation.
- Power gating: at 128 cores, a per-core power-gate for the MUL/DIV unit is worth considering if idle periods dominate. The wake-up latency and IR-drop impact on the power grid are not yet analyzed; INSUFFICIENT EVIDENCE without a full-die power analysis.
- Energy per multiply is dominated by the compressor tree. The relationship "energy scales roughly with the number of partial products" is a rule of thumb; INSUFFICIENT EVIDENCE for a specific quantitative claim.
- Energy per divide is dominated by the 32-cycle residency; early-exit on the dividend (trailing-zero detection) reduces energy for typical operands but the worst-case energy remains.

## Implementation Considerations

- Synchronous, single-clock-domain design inside the unit.
- No asynchronous resets inside the iterative divider; synchronous reset only at the start of an operation.
- Final carry-propagate adder: Kogge–Stone, Han–Carlson, and Brent–Kung are all viable. The choice depends on the EX-stage timing budget and the area target; Kogge–Stone / Han–Carlson are faster but larger, Brent–Kung is smaller but slower. The previous revision named a default without justification; this document records the choice as a trade-off driven by the EX-stage timing budget, to be decided after synthesis.
- Divider quotient and remainder registers are 64 bits each, with an extra bit for the iterative sign.
- The microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.
- Output muxing for MUL / MULH / MULHSU / MULHU / MULW is a small mux tree, not a separate datapath.
- Booth encoding produces 33 partial products for radix-4 of a 64-bit operand (32 digit products plus one sign-correction row). The "17 partial products" figure from the previous revision is incorrect and is corrected here.

## Verification Considerations

- Formal verification of the multiplier compressor tree and final adder is feasible with bounded model checkers and is recommended.
- Directed tests for division edge cases: ÷0 (signed and unsigned, both quotient and remainder), INT64_MIN / −1, dividend = divisor, dividend = 0, divisor = 1, all-ones, alternating bits, dividend = −1, divisor = 2.
- Explicit coverage of the REM sign-of-dividend rule.
- Coverage of all 4 MUL variants and the W-variants.
- Randomized differential testing against a software reference (a GCC-compiled test harness running on Spike or QEMU, or a Python / C++ golden model) is recommended.
- 128-core DFT: see the dedicated section below.

### DFT Strategy (128 Replicated Units)

- Single-clock-domain, synchronous-reset-only design is required for scan insertion.
- Each MUL/DIV instance is scan-stitched independently; long scan chains between the iterative divider and surrounding logic are avoided to prevent hold-time issues.
- Scan compression: per-core compression reduces the number of top-level scan pins; the compression architecture is TBD by the DFT plan.
- BIST: optional per-core BIST for the MUL/DIV unit is feasible given its small size and regular structure; this would reduce ATPG complexity at the cost of additional area for the BIST controller.
- ATPG implications: the iterative divider is the only sequential element of consequence in the MUL/DIV block; full-scan coverage is straightforward if no asynchronous paths are introduced.

## Software Implications

- Compilers emit MUL freely; no software changes are required.
- Division by a constant is often transformed by the compiler into a magic-number multiply; the choice of MUL/DIV design therefore disproportionately affects runtime divide performance for code with frequent constant divides.
- For languages with software-emulated 128-bit integers (`__int128` in C/C++), the compiler emits MULH / MULHU sequences; MULH latency and throughput are the relevant metrics here. This is the case where MULH is the key metric, not the crypto case.
- Crypto libraries (libsodium, OpenSSL, mbedTLS) typically use Karatsuba or Montgomery multiplication, which depend on lower-half MUL throughput, not MULH throughput. The previous revision's claim that MULH is the key for Karatsuba / Montgomery is corrected here.
- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a 32-cycle divider increases interpreter dispatch latency for that pattern.

## Recommendation

RECOMMENDATION: Adopt B1 (2-stage pipelined Radix-4 Booth multiplier, 33 partial products, 4:2 compressor tree, 2-cycle latency, 1/cycle throughput) paired with a 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency and an early-exit optimization for typical operands.

Rationale:

- Best balance of area, energy, and performance for 128-core replication under current unvalidated estimates.
- Deterministic, fully synchronous design simplifies verification and DFT.
- 1/cycle MUL throughput meets general-purpose and crypto lower-half-multiply needs.
- 32-cycle worst-case DIV latency is acceptable for general-purpose workloads; an upgrade path to B4-pipe (16-cycle pipelined SRT-4) is reserved for the case where profiling evidence supports it.

RECOMMENDATION (conditional): If early workload analysis (TBD) shows that divide latency is a bottleneck, upgrade the divider to B4-pipe (pipelined Radix-4 SRT, 16-cycle latency, 1/cycle throughput) at an estimated additional ~3–4× divider area (unvalidated). Do not adopt a Newton–Raphson divider unless profiling evidence strongly supports it, due to verification complexity and variable latency.

RECOMMENDATION: Do not adopt a fully combinational array divider or fully combinational multiplier for the replicated 128-core design. The area cost is not justified by the latency benefit at the per-core replication factor.

RECOMMENDATION (fallback): If per-core area constraints prove tighter than estimated, evaluate B7 (cluster-shared organization, 16 instances serving 8 cores each) with a faster per-cluster divider (B4-pipe or B5) before reducing the per-core divider latency further. This trades inter-core contention for per-core area and is the right knob to pull when the per-core area budget is the binding constraint.

## Confidence

- Direction of recommendation: MEDIUM. The general design class is well-established; the specific B1 + non-restoring-32-cycle choice depends on a per-core area budget that has not yet been validated.
- Quantitative area, latency, power, and energy numbers: LOW. No measurements exist in the XH-1 repository; all such numbers in this document are explicitly labeled as unvalidated estimates or INSUFFICIENT EVIDENCE.
- Verification strategy: HIGH. The recommended approach (formal on the multiplier, directed + randomized for the divider, explicit REM sign rule) is standard practice.
- Edge-case correctness: HIGH. The RISC-V spec behavior is explicit; the previous revision contained an error in the DIVU-by-zero description, which is corrected here.

## Open Questions

- What is the EX-stage latency budget? (Depends on `pipeline.md`.)
- What is the target frequency and process node? Determines whether 2-cycle MUL is feasible, and which final-adder architecture is appropriate.
- Is the design in-order or out-of-order? Out-of-order execution can hide divide latency; in-order cannot.
- Will the MUL/DIV unit share an issue port with the ALU, or have a dedicated issue port? (Likely shared, but TBD.)
- Is there a future F / D extension? If so, the integer MUL/DIV unit may also need to feed FP-to-int conversions or FP reciprocal iterations; this is not yet analyzed.
- What is the expected workload mix? General-purpose vs. HPC vs. embedded vs. server?
- Should the MUL/DIV unit be power-gated when idle? At 128 cores, idle probability may be high; wake-up latency and IR-drop impact are TBD.
- Should the divider support a "fast-path" for division by a small constant (e.g., a compiler-inserted reciprocal-multiply hint) as a microarchitectural feature?
- Is the B7 cluster-shared organization a realistic fallback, or is per-core replication a hard requirement?
- What scan-compression architecture will be used for 128 replicated units?

## Sources

- The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA, M-extension chapter. Defines MUL, MULH, MULHSU, MULHU, DIV, DIVU, REM, REMU, and the W-variants, including the corner-case behavior for division by zero and signed overflow. Specific URL and section: INSUFFICIENT EVIDENCE in the XH-1 repository to cite a specific revision; the manual is the canonical source.
- Hennessy and Patterson, "Computer Architecture: A Quantitative Approach." General MUL/DIV trade-off discussion.
- Parhami, "Computer Arithmetic: Algorithms and Hardware Designs." Standard reference for multiplier and divider algorithms including Booth, Wallace / Dadda, SRT, and Newton–Raphson.
- Open-source RISC-V cores: Rocket Chip, BOOM (SmallBoomConfig and MediumBoomConfig), Ariane. Used as design-class references for typical MUL/DIV organizations and reported latency ranges. Specific commits, measured numbers, and PPA data: INSUFFICIENT EVIDENCE in the XH-1 repository to cite.
- No quantitative claim in this document is derived from a measurement of XH-1 silicon, layout, or synthesis. All such numbers are explicitly labeled as unvalidated estimates or INSUFFICIENT EVIDENCE.
