xh1-research-fork/research/.xh1/responses/20260825T180300Z_mul-div-unit.md.json

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787680980-y6wlPzNkplZYwR1xpnVk","object":"chat.completion","created":1787680980,"model":"minimax/minimax-m3:free","provider":"GMICloud","system_fingerprint":null,"service_tier":null,"choices":[{"index":0,"logprobs":null,"finish_reason":"stop","native_finish_reason":"stop","message":{"role":"assistant","content":"# MUL/DIV Unit\n\n## Status\n\nDRAFT — initial research document. No architectural decision has been made for XH-1.\n\n## Abstract\n\nThis 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.\n\n## Research Question\n\nWhat 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)?\n\nSub-questions:\n\n- Should multiplication be iterative (shift-and-add) or fully combinational (array/Wallace/Booth)?\n- Should division use a restoring, non-restoring, SRT, or Newton–Raphson scheme?\n- Should the unit be pipelined, multi-cycle, or variable-latency?\n- How does the MUL/DIV unit interact with the surrounding pipeline (depth, bypass, in-order vs out-of-order issue)?\n- How does the unit scale when replicated 128 times on die?\n- Should fused MAC operations (MUL + ADD) or fused multiply-add be considered?\n\n## Background\n\nThe 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.\n\nKey properties of the workload that influence the design:\n\n- **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.\n- **Sign handling.** Three signed/unsigned combinations (signed×signed, signed×unsigned, unsigned×unsigned) must be supported. Sign correction is required for MULH/MULHSU.\n- **Division latency and throughput.** RISC-V does not require division to retire in a single cycle, but the ISA mandates deterministic behavior for overflow.\n- **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.\n\nFor 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.\n\n## Existing Approaches\n\n### Multiplication\n\n1. **Iterative shift-and-add multiplier**\n   - One 64-bit adder reused across 64 cycles.\n   - Smallest area, lowest energy per multiplication, but very long latency.\n\n2. **Array multiplier (combinational)**\n   - 64×64 array of full adders producing a 128-bit result.\n   - Single-cycle result, large area, high fan-out, and a long critical path.\n   - Historically too slow for one cycle at high clock frequencies.\n\n3. **Wallace / Dadda tree**\n   - Tree of carry-save adders reducing partial products to two 128-bit vectors, then a final carry-propagate adder.\n   - Logarithmic depth; commonly used in high-performance cores.\n   - Larger area than array, but shorter critical path.\n\n4. **Booth-encoded Wallace / Dadda**\n   - Radix-4 or higher Booth recoding reduces the number of partial products by ~2×.\n   - Common in modern cores (e.g., reported in implementations of ARM and x86 multipliers).\n\n5. **Pipelined iterative multiplier**\n   - Splits the 64-cycle iterative multiplier into pipeline stages (commonly 2–4 stages).\n   - Used in many in-order RISC-V cores (e.g., the Rocket Chip generator's `MulDiv`).\n\n6. **Dedicated single-cycle fused multiply-add (FMA) for integers**\n   - Rare for integer-only M-extensions; usually belongs to the F/D extensions.\n\n### Division\n\n1. **Restoring division**\n   - Classical shift-subtract. One bit per cycle, 64 cycles for 64-bit operands.\n   - Simple, easy to verify.\n\n2. **Non-restoring division**\n   - Similar latency, but allows a single add/subtract per bit without explicit restore.\n   - Used in many textbook implementations.\n\n3. **SRT division**\n   - Radix-4 or higher; produces 2+ bits per cycle using a small redundant quotient-digit table.\n   - Significantly faster (16–32 cycles for 64-bit) at higher area cost.\n   - Common in high-performance OoO cores (e.g., POWER, Itanium, recent x86).\n\n4. **Newton–Raphson reciprocal + multiply**\n   - Iteratively refines an approximation of 1/d, then multiplies.\n   - Very high throughput once the reciprocal is available.\n   - Worst-case latency is higher than SRT; best for repeated divisions by the same divisor.\n   - Rare in integer pipelines due to initial latency.\n\n5. **Goldschmidt division**\n   - Similar to Newton–Raphson; iteratively scales numerator and denominator toward 1.\n   - Same usage profile as Newton–Raphson.\n\n6. **Lookup-table based constant dividers**\n   - For known small constant divisors, the compiler/runtime can replace DIV with a multiply-by-reciprocal.\n   - Microarchitectural implication: the DIV unit need not be heavily optimized if software frequently replaces division by constants.\n\n## Alternative Designs\n\nFor the XH-1 MUL/DIV unit, four credible microarchitectural templates are considered.\n\n### Design A: Shared iterative multi-cycle unit (Rocket-style)\n\n- One 64-bit datapath reused for both MUL and DIV.\n- MUL: 1 cycle/partial product (radix-2 Booth optional).\n- DIV: 1 bit/cycle, restoring or non-restoring.\n- MUL latency: ~33–35 cycles (radix-2 Booth) or ~64 cycles (plain shift-add).\n- DIV latency: ~64 cycles.\n- Throughput: 1 MUL or DIV per ~32 cycles (shared); MUL and DIV cannot execute concurrently.\n- Plausible canonical reference: the `MulDiv` module in the BOOM/Rocket Chip generator (UC Berkeley).\n\n### Design B: Pipelined iterative multiplier + iterative divider\n\n- Multiplier: 2–4 stage pipelined radix-2/radix-4 iterative unit.\n- Divider: separate 64-bit iterative datapath (non-restoring or SRT-radix-2).\n- MUL throughput: 1 per cycle once pipeline is full.\n- DIV throughput: 1 per ~32 cycles.\n- Independent issue of MUL and DIV is possible.\n\n### Design C: Pipelined Wallace/Booth multiplier + SRT-radix-4 divider\n\n- Multiplier: 3-stage pipelined radix-4 Booth → Wallace tree → CPA. Produces full 128-bit result.\n- Divider: radix-4 SRT producing 2 bits/cycle; ~17 cycles for 64-bit DIV.\n- DIV/REM can be produced simultaneously since quotient digits are known.\n- Area: significantly larger than Designs A and B.\n- Latency: MUL ~3–4 cycles, DIV ~17–20 cycles.\n- Used in many modern superscalar cores.\n\n### Design F: Fused integer MAC / FMA\n\n- Add an integer fused multiply-add returning low 64 bits (a*b)+c in one operation.\n- This is non-standard for RV64M and would require custom opcodes or being staged behind a regular MUL+ADD sequence.\n- Documented here for completeness, not recommended without strong workload evidence.\n\n## Comparison\n\n| Property | A: Iterative shared | B: Pipelined iterative MUL + iterative DIV | C: Wallace/Booth MUL + SRT-4 DIV |\n|---|---|---|---|\n| MUL latency | ~33–64 cycles | 3–5 cycles | 3–4 cycles |\n| MUL throughput | 1 / 32 cycles | 1 / cycle | 1 / cycle |\n| DIV latency | ~64 cycles | ~32 cycles | ~16–20 cycles |\n| DIV throughput | 1 / 64 cycles | 1 / 32 cycles | 1 / 16 cycles |\n| 64×64→128 datapath | Yes (shared) | Yes (MUL only) | Yes (Wallace) |\n| MUL+DIV concurrency | No (shared) | Yes (separate datapaths) | Yes (separate datapaths) |\n| Estimated relative area | 1.0× | ~1.5–2.0× | ~3.0–5.0× |\n| Estimated critical path | Short | Short | Longest (CPA final stage) |\n| Verification complexity | Low | Medium | High |\n| Fits \"small in-order\" model | Excellent | Good | Marginal |\n\nASSUMPTION: 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.\n\n## Advantages\n\n### Design A (iterative shared)\n\n- Smallest area per core, which directly reduces die cost across 128 cores.\n- Lowest per-core dynamic energy for the rare case of an actual MUL/DIV.\n- Easiest to verify formally (small state space, one datapath).\n- Matches the \"many small cores\" scaling philosophy.\n- Canonical reference: Rocket Chip `MulDiv`.\n\n### Design B (pipelined iterative MUL + iterative DIV)\n\n- MUL throughput is high enough to support HPC and crypto workloads where 64-bit multiplies are common.\n- DIV remains simple.\n- Area increase over A is bounded.\n- Two independent datapaths simplify scheduling in the issue stage.\n\n### Design C (Wallace/Booth + SRT-4)\n\n- Best raw latency and throughput for both operations.\n- Suitable for single-core-bound workloads or for cores that need to hide memory latency behind fast arithmetic.\n- DIV+REM can be produced together with little extra hardware.\n\n## Disadvantages\n\n### Design A\n\n- 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.\n- Back-to-back MULs serialize.\n- Under HPC or cryptography kernels, MUL throughput becomes a bottleneck.\n\n### Design B\n\n- More area than A.\n- Pipelined MUL increases register pressure in the issue queue and requires more bypass paths in the surrounding execution stage.\n- DIV still slow.\n\n### Design C\n\n- Largest area per core, replicated 128 times.\n- Highest per-core power.\n- Wallace tree and SRT have long critical paths that may limit clock frequency for the whole core.\n- 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.\n- Wall-clock design and verification cost may delay the whole project.\n\n## XH-1 Considerations\n\nPROPOSAL: 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.\n\nSpecific implications for XH-1:\n\n- 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.\n- The energy of 128 MUL/DIV datapaths, even at low utilization, contributes to total socket power.\n- 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.\n- 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.\n\n## 128-Core Scalability\n\nScalability dimensions to consider:\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Performance Considerations\n\n- 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.\n- 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.\n- If XH-1 targets HPC or cryptography, the MUL throughput becomes important. In this case, B or C should be reconsidered.\n- Software can use compiler transformations to replace DIV by constants with multiply-by-reciprocal, reducing pressure on the DIV unit.\n\n## Implementation Considerations\n\n- **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).\n- **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.\n- **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.\n- **Bypassing.** Forwarding paths from the MUL/DIV pipeline registers to dependent instructions must be designed carefully to avoid structural hazards.\n- **Early termination.** For DIV, the unit can terminate early when the remainder is zero, saving cycles. Implementation cost is low.\n\n## Verification Considerations\n\n- **Corner cases.** RV64M has well-defined corner cases: `INT64_MIN / -1`, division by zero, overflow in REM, sign interactions in MULH-family.\n- **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).\n- **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.\n- **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.\n- **Testbench reuse.** The RISC-V community maintains architectural compliance tests that should be run against the MUL/DIV unit regardless of the chosen design.\n\n## Recommendation\n\nPROPOSAL: 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:\n\n- 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.\n- A **non-restoring (or radix-2 SRT) divider** completing in ~32 cycles.\n- MUL and DIV on the same datapath with **shared state** but capable of being interleaved at issue time.\n- 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.\n\nThis 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.\n\nRECOMMENDATION: 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.\n\n## Confidence\n\n- **Low–Medium** for any specific microarchitectural recommendation. The document is at an early stage; the recommendation will be revised after:\n  1. Workload analysis (target use cases of XH-1).\n  2. Synthesis of representative MUL/DIV units in the target technology.\n  3. Frequency, area, and power target constraints.\n- **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.\n\n## Open Questions\n\n- What is the target frequency of XH-1 cores, and what is the critical-path budget for the MUL/DIV unit?\n- What process node is targeted, and what is the per-core area budget?\n- What is the intended workload mix (server, HPC, embedded, ML)?\n- Is the core in-order or out-of-order? The MUL/DIV interface and latency tolerance depend strongly on this.\n- Will the F extension (floating-point) be present in the same core, and if so, should integer MUL be reused inside an FMA datapath?\n- 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.\n- Are fused integer MAC operations required by any target workload?\n- What level of formal verification is mandated for XH-1?\n\n## Sources\n\nPrimary and authoritative references used or cited in this document:\n\n- 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.\n- RISC-V International, *Architectural Compatibility Test Suite* (riscv-tests, riscv-arch-test) — official compliance test references.\n- UC Berkeley Architecture Research, *Rocket Chip Generator* documentation — reference for the small iterative `MulDiv` module.\n- UC Berkeley Architecture Research, *BOOM Out-of-Order Processor* documentation — reference for SRT-class dividers and pipelined multipliers in BOOM v2/v3.\n- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (recent editions) — workload frequency of MUL/DIV, energy/area considerations.\n- Ercegovac & Lang, *Digital Arithmetic* — comprehensive treatment of shift-add, Booth, Wallace, SRT, and Newton–Raphson dividers.\n- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs* — additional reference for multiplier and divider architectures.\n\nASSUMPTION: 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.\n\nINSUFFICIENT 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.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":777,"completion_tokens":4495,"total_tokens":5272,"cost":0,"is_byok":false,"prompt_tokens_details":{"cached_tokens":762,"cache_write_tokens":0,"audio_tokens":0,"video_tokens":0},"cost_details":{"upstream_inference_cost":0,"upstream_inference_prompt_cost":0,"upstream_inference_completions_cost":0},"completion_tokens_details":{"reasoning_tokens":0,"image_tokens":0,"audio_tokens":0}}}