# MUL/DIV Unit ## Status DRAFT — initial research document. No architectural decision has been made for XH-1. ## Abstract This document investigates the design of the multiplication and division unit (MUL/DIV) for a single core inside the XH-1 128-core RISC-V processor. It surveys existing approaches for integer multiplication and division, identifies alternative implementations, and analyzes trade-offs in performance, area, power, latency, verification complexity, and scalability across 128 cores. The document focuses on the base integer extensions (RV64I/M) and explicitly defers floating-point and vector multiply/accumulate topics, which belong to separate units. ## Research Question What is the most appropriate microarchitectural implementation of the MUL/DIV unit for a single XH-1 core, given that 128 identical cores will be instantiated on die, and given that the MUL/DIV unit must implement at minimum RV64M (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU)? Sub-questions: - Should multiplication be iterative (shift-and-add) or fully combinational (array/Wallace/Booth)? - Should division use a restoring, non-restoring, SRT, or Newton–Raphson scheme? - Should the unit be pipelined, multi-cycle, or variable-latency? - How does the MUL/DIV unit interact with the surrounding pipeline (depth, bypass, in-order vs out-of-order issue)? - How does the unit scale when replicated 128 times on die? - Should fused MAC operations (MUL + ADD) or fused multiply-add be considered? ## Background The RISC-V "M" extension specifies eight integer multiply/divide instructions (MUL, MULH, MULHSU, MULHU, DIV, DIVU, REM, REMU) on 64-bit values producing either 64-bit or 128-bit results. Division is defined to round toward zero and is required to complete even for overflow cases (e.g., `INT64_MIN / -1`), as specified in the RISC-V Unprivileged ISA. Key properties of the workload that influence the design: - **Result width asymmetry.** MUL produces a 128-bit result, but only the low 64 bits are written to `rd` for `MUL`. MULH-family instructions write the high 64 bits. The datapath therefore needs at least a 64×64→128 multiplier followed by a selector. - **Sign handling.** Three signed/unsigned combinations (signed×signed, signed×unsigned, unsigned×unsigned) must be supported. Sign correction is required for MULH/MULHSU. - **Division latency and throughput.** RISC-V does not require division to retire in a single cycle, but the ISA mandates deterministic behavior for overflow. - **Rarity in many workloads.** Empirical studies (e.g., Hennessy & Patterson, *Computer Architecture: A Quantitative Approach*) report that integer divide and remainder instructions are uncommon (typically <1% of dynamic instructions), while multiplies are more frequent in HPC and crypto workloads. For XH-1, the unit sits on the execution path of every core. With 128 cores, area and per-core energy dominate; raw single-thread latency of division matters less than aggregate throughput, die-area cost, and ease of verification. ## Existing Approaches ### Multiplication 1. **Iterative shift-and-add multiplier** - One 64-bit adder reused across 64 cycles. - Smallest area, lowest energy per multiplication, but very long latency. 2. **Array multiplier (combinational)** - 64×64 array of full adders producing a 128-bit result. - Single-cycle result, large area, high fan-out, and a long critical path. - Historically too slow for one cycle at high clock frequencies. 3. **Wallace / Dadda tree** - Tree of carry-save adders reducing partial products to two 128-bit vectors, then a final carry-propagate adder. - Logarithmic depth; commonly used in high-performance cores. - Larger area than array, but shorter critical path. 4. **Booth-encoded Wallace / Dadda** - Radix-4 or higher Booth recoding reduces the number of partial products by ~2×. - Common in modern cores (e.g., reported in implementations of ARM and x86 multipliers). 5. **Pipelined iterative multiplier** - Splits the 64-cycle iterative multiplier into pipeline stages (commonly 2–4 stages). - Used in many in-order RISC-V cores (e.g., the Rocket Chip generator's `MulDiv`). 6. **Dedicated single-cycle fused multiply-add (FMA) for integers** - Rare for integer-only M-extensions; usually belongs to the F/D extensions. ### Division 1. **Restoring division** - Classical shift-subtract. One bit per cycle, 64 cycles for 64-bit operands. - Simple, easy to verify. 2. **Non-restoring division** - Similar latency, but allows a single add/subtract per bit without explicit restore. - Used in many textbook implementations. 3. **SRT division** - Radix-4 or higher; produces 2+ bits per cycle using a small redundant quotient-digit table. - Significantly faster (16–32 cycles for 64-bit) at higher area cost. - Common in high-performance OoO cores (e.g., POWER, Itanium, recent x86). 4. **Newton–Raphson reciprocal + multiply** - Iteratively refines an approximation of 1/d, then multiplies. - Very high throughput once the reciprocal is available. - Worst-case latency is higher than SRT; best for repeated divisions by the same divisor. - Rare in integer pipelines due to initial latency. 5. **Goldschmidt division** - Similar to Newton–Raphson; iteratively scales numerator and denominator toward 1. - Same usage profile as Newton–Raphson. 6. **Lookup-table based constant dividers** - For known small constant divisors, the compiler/runtime can replace DIV with a multiply-by-reciprocal. - Microarchitectural implication: the DIV unit need not be heavily optimized if software frequently replaces division by constants. ## Alternative Designs For the XH-1 MUL/DIV unit, four credible microarchitectural templates are considered. ### Design A: Shared iterative multi-cycle unit (Rocket-style) - One 64-bit datapath reused for both MUL and DIV. - MUL: 1 cycle/partial product (radix-2 Booth optional). - DIV: 1 bit/cycle, restoring or non-restoring. - MUL latency: ~33–35 cycles (radix-2 Booth) or ~64 cycles (plain shift-add). - DIV latency: ~64 cycles. - Throughput: 1 MUL or DIV per ~32 cycles (shared); MUL and DIV cannot execute concurrently. - Plausible canonical reference: the `MulDiv` module in the BOOM/Rocket Chip generator (UC Berkeley). ### Design B: Pipelined iterative multiplier + iterative divider - Multiplier: 2–4 stage pipelined radix-2/radix-4 iterative unit. - Divider: separate 64-bit iterative datapath (non-restoring or SRT-radix-2). - MUL throughput: 1 per cycle once pipeline is full. - DIV throughput: 1 per ~32 cycles. - Independent issue of MUL and DIV is possible. ### Design C: Pipelined Wallace/Booth multiplier + SRT-radix-4 divider - Multiplier: 3-stage pipelined radix-4 Booth → Wallace tree → CPA. Produces full 128-bit result. - Divider: radix-4 SRT producing 2 bits/cycle; ~17 cycles for 64-bit DIV. - DIV/REM can be produced simultaneously since quotient digits are known. - Area: significantly larger than Designs A and B. - Latency: MUL ~3–4 cycles, DIV ~17–20 cycles. - Used in many modern superscalar cores. ### Design F: Fused integer MAC / FMA - Add an integer fused multiply-add returning low 64 bits (a*b)+c in one operation. - This is non-standard for RV64M and would require custom opcodes or being staged behind a regular MUL+ADD sequence. - Documented here for completeness, not recommended without strong workload evidence. ## Comparison | Property | A: Iterative shared | B: Pipelined iterative MUL + iterative DIV | C: Wallace/Booth MUL + SRT-4 DIV | |---|---|---|---| | MUL latency | ~33–64 cycles | 3–5 cycles | 3–4 cycles | | MUL throughput | 1 / 32 cycles | 1 / cycle | 1 / cycle | | DIV latency | ~64 cycles | ~32 cycles | ~16–20 cycles | | DIV throughput | 1 / 64 cycles | 1 / 32 cycles | 1 / 16 cycles | | 64×64→128 datapath | Yes (shared) | Yes (MUL only) | Yes (Wallace) | | MUL+DIV concurrency | No (shared) | Yes (separate datapaths) | Yes (separate datapaths) | | Estimated relative area | 1.0× | ~1.5–2.0× | ~3.0–5.0× | | Estimated critical path | Short | Short | Longest (CPA final stage) | | Verification complexity | Low | Medium | High | | Fits "small in-order" model | Excellent | Good | Marginal | ASSUMPTION: Area estimates above are rough order-of-magnitude relative numbers based on typical RISC-V implementations and the cited textbooks. They have not been measured for XH-1. ## Advantages ### Design A (iterative shared) - Smallest area per core, which directly reduces die cost across 128 cores. - Lowest per-core dynamic energy for the rare case of an actual MUL/DIV. - Easiest to verify formally (small state space, one datapath). - Matches the "many small cores" scaling philosophy. - Canonical reference: Rocket Chip `MulDiv`. ### Design B (pipelined iterative MUL + iterative DIV) - MUL throughput is high enough to support HPC and crypto workloads where 64-bit multiplies are common. - DIV remains simple. - Area increase over A is bounded. - Two independent datapaths simplify scheduling in the issue stage. ### Design C (Wallace/Booth + SRT-4) - Best raw latency and throughput for both operations. - Suitable for single-core-bound workloads or for cores that need to hide memory latency behind fast arithmetic. - DIV+REM can be produced together with little extra hardware. ## Disadvantages ### Design A - DIV latency of 64 cycles is long; if the surrounding pipeline is short (e.g., 5–7 stages), the unit will dominate total execution time for any divide. - Back-to-back MULs serialize. - Under HPC or cryptography kernels, MUL throughput becomes a bottleneck. ### Design B - More area than A. - Pipelined MUL increases register pressure in the issue queue and requires more bypass paths in the surrounding execution stage. - DIV still slow. ### Design C - Largest area per core, replicated 128 times. - Highest per-core power. - Wallace tree and SRT have long critical paths that may limit clock frequency for the whole core. - Verification complexity is significantly higher: partial-product reduction, Booth recoding, SRT quotient-digit selection tables, and divider corner cases (e.g., `INT64_MIN / -1`) all need separate coverage. - Wall-clock design and verification cost may delay the whole project. ## XH-1 Considerations PROPOSAL: For XH-1, an in-order core with 128 instances on die, the dominant design constraint is **per-core area, energy, and verification cost**, not single-thread peak performance. The MUL/DIV unit should therefore favor small, simple, well-trodden implementations. Specific implications for XH-1: - The 128-core factor means the MUL/DIV unit's area is multiplied by 128. Even a 2× area difference per core translates to a substantial absolute area delta. - The energy of 128 MUL/DIV datapaths, even at low utilization, contributes to total socket power. - A long-latency MUL/DIV unit is acceptable if the surrounding pipeline is deep enough or if it can be overlapped with other in-flight instructions in the same core. - Single-cycle MUL would impose a critical path on the whole core; for a 128-core design, sustained high clock frequency across all cores is critical to total throughput. ## 128-Core Scalability Scalability dimensions to consider: - **Wiring and layout.** A 128-core die has a complex interconnect. A small MUL/DIV unit is easier to place and route within each core tile. Designs with large irregular adder trees (Wallace/SRT) complicate physical design at high core counts. - **Verification replication.** Bugs in the MUL/DIV unit, if present, propagate to 128 cores. A simpler, formally verifiable design (Design A) is safer for replication. - **Yield.** Smaller per-core area improves yield and binning flexibility; large per-core area reduces the number of cores that fit on a reticle at the target process node. - **Power delivery.** 128 simultaneous MUL/DIV operations are unlikely, but worst-case power events (e.g., SIMD-style vector MUL workloads scaled down to integer MUL) must be within the socket's power-delivery budget. - **Frequency scaling.** A 128-core chip with modest per-core frequency but high aggregate throughput may benefit from a short critical path. A Wallace multiplier's critical path can limit fmax for the whole core. ## Performance Considerations - MUL/DIV instructions are infrequent in general-purpose workloads (often <1% dynamic instructions) but can dominate kernels in cryptography (AES, ChaCha20, RSA), big-integer arithmetic (GMP-style libraries), and some HPC kernels. - If XH-1 is intended for general-purpose server or desktop use, the MUL/DIV unit will rarely be on the critical path of a thread. - If XH-1 targets HPC or cryptography, the MUL throughput becomes important. In this case, B or C should be reconsidered. - Software can use compiler transformations to replace DIV by constants with multiply-by-reciprocal, reducing pressure on the DIV unit. ## Implementation Considerations - **Sign handling.** The unit must correctly handle `MULH`, `MULHSU`, and `MULHU` as well as overflow cases of DIV (notably `INT64_MIN / -1`, which must produce `INT64_MIN` per RISC-V spec). - **REM vs DIV.** Producing REM in parallel with DIV using the same datapath is standard in restoring/non-restoring designs; the unit should support issuing DIVU/REMU pairs in one operation. - **Pipeline interface.** The unit must integrate with the core's issue, wakeup, and writeback stages. If in-order, the issue stage must stall in-order cores on multi-cycle MUL/DIV. If OoO, completion must wait for the unit's completion signal. - **Bypassing.** Forwarding paths from the MUL/DIV pipeline registers to dependent instructions must be designed carefully to avoid structural hazards. - **Early termination.** For DIV, the unit can terminate early when the remainder is zero, saving cycles. Implementation cost is low. ## Verification Considerations - **Corner cases.** RV64M has well-defined corner cases: `INT64_MIN / -1`, division by zero, overflow in REM, sign interactions in MULH-family. - **Directed + constrained-random.** A combination of directed tests for ISA corner cases and constrained-random for the rest is standard practice (e.g., as in the RISC-V architectural test framework, riscv-tests). - **Formal verification.** A small iterative multiplier/divider (Design A) is amenable to formal proofs of correctness for a few-bit case and inductive scaling. A Wallace + SRT unit (Design C) is significantly harder to formally verify due to selector-table complexity. - **Cross-core equivalence.** With 128 identical cores, regression in one core implies regression in all 128. A well-verified single-core design simplifies the chip-level verification effort. - **Testbench reuse.** The RISC-V community maintains architectural compliance tests that should be run against the MUL/DIV unit regardless of the chosen design. ## Recommendation PROPOSAL: Adopt a **Design B–leaning approach**: a small, simple, well-understood MUL/DIV unit similar in spirit to Rocket Chip's `MulDiv`, with the following characteristics: - A **radix-4 Booth-encoded iterative multiplier** (or radix-2 if radix-4 proves too complex for the area budget) producing 64 bits of result per ~16 cycles, sharing partial datapath with the divider if needed. - A **non-restoring (or radix-2 SRT) divider** completing in ~32 cycles. - MUL and DIV on the same datapath with **shared state** but capable of being interleaved at issue time. - Optional microarchitectural relaxation: a separate tiny **fast-MUL path for 32×32→64 results** (the low half of MUL where both operands are sign- or zero-extended from 32 bits) to accelerate common cases. This adds minimal area. This recommendation is provisional and is the lightest-weight option that still keeps MUL throughput reasonable. It avoids the critical-path cost of Design C and the throughput limit of Design A, while remaining well within the verification budget of a 128-core project. RECOMMENDATION: If workload analysis (not yet performed) shows MUL-heavy HPC/cryptography use, escalate to a pipelined radix-4 Booth multiplier with a 2–3 cycle latency, keeping the iterative divider. If workload analysis shows almost no MUL/DIV usage, drop to a plain Design A. ## Confidence - **Low–Medium** for any specific microarchitectural recommendation. The document is at an early stage; the recommendation will be revised after: 1. Workload analysis (target use cases of XH-1). 2. Synthesis of representative MUL/DIV units in the target technology. 3. Frequency, area, and power target constraints. - **High** that the iterative, shared-datapath approach (Design A or B) is the appropriate starting point for a 128-core, area-constrained, verification-constrained design. ## Open Questions - What is the target frequency of XH-1 cores, and what is the critical-path budget for the MUL/DIV unit? - What process node is targeted, and what is the per-core area budget? - What is the intended workload mix (server, HPC, embedded, ML)? - Is the core in-order or out-of-order? The MUL/DIV interface and latency tolerance depend strongly on this. - Will the F extension (floating-point) be present in the same core, and if so, should integer MUL be reused inside an FMA datapath? - Will the V extension (vector) be present? If so, scalar integer MUL may be lightly used and the scalar MUL/DIV unit can be minimal. - Are fused integer MAC operations required by any target workload? - What level of formal verification is mandated for XH-1? ## Sources Primary and authoritative references used or cited in this document: - RISC-V International, *The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture* — official definition of RV64M (MUL, MULH, MULHSU, MULHU, DIV, DIVU, REM, REMU) and division overflow semantics. - RISC-V International, *Architectural Compatibility Test Suite* (riscv-tests, riscv-arch-test) — official compliance test references. - UC Berkeley Architecture Research, *Rocket Chip Generator* documentation — reference for the small iterative `MulDiv` module. - UC Berkeley Architecture Research, *BOOM Out-of-Order Processor* documentation — reference for SRT-class dividers and pipelined multipliers in BOOM v2/v3. - Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (recent editions) — workload frequency of MUL/DIV, energy/area considerations. - Ercegovac & Lang, *Digital Arithmetic* — comprehensive treatment of shift-add, Booth, Wallace, SRT, and Newton–Raphson dividers. - Parhami, *Computer Arithmetic: Algorithms and Hardware Designs* — additional reference for multiplier and divider architectures. ASSUMPTION: Specific page numbers and edition identifiers for Hennessy & Patterson, Ercegovac & Lang, and Parhami have not been quoted above because the exact editions in the XH-1 research library have not been recorded in this document. They should be cited precisely when this document is finalized. INSUFFICIENT EVIDENCE: No synthesis, layout, or PPA data for the target process node is yet available for any of the four design candidates. The relative area and energy figures are qualitative estimates only.