Files
xh1-research-fork/research/.xh1/responses/20260825T180300Z_mul-div-unit.md
2026-08-25 20:22:11 +02:00

285 lines
19 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 NewtonRaphson 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 24 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 (1632 cycles for 64-bit) at higher area cost.
- Common in high-performance OoO cores (e.g., POWER, Itanium, recent x86).
4. **NewtonRaphson 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 NewtonRaphson; iteratively scales numerator and denominator toward 1.
- Same usage profile as NewtonRaphson.
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: ~3335 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: 24 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 ~34 cycles, DIV ~1720 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 | ~3364 cycles | 35 cycles | 34 cycles |
| MUL throughput | 1 / 32 cycles | 1 / cycle | 1 / cycle |
| DIV latency | ~64 cycles | ~32 cycles | ~1620 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.52.0× | ~3.05.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., 57 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 Bleaning 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 23 cycle latency, keeping the iterative divider. If workload analysis shows almost no MUL/DIV usage, drop to a plain Design A.
## Confidence
- **LowMedium** 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 NewtonRaphson 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.