mirror of
https://github.com/allexanderbergmns/xh1-research.git
synced 2026-08-26 23:07:01 +00:00
285 lines
19 KiB
Markdown
285 lines
19 KiB
Markdown
# 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.
|