
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787681513-mkVZlAfmpvyyirk1K6ur","object":"chat.completion","created":1787681513,"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":"# XH-1 Multiply/Divide Unit Research\n\n## Topic\n\n`research/03-core-design/mul-div-unit.md` — design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core, with particular attention to how this unit is replicated across 128 cores.\n\n## Status\n\n**Stub.** The current document contains only the placeholder `SOON`. This research document establishes the design-space analysis required to populate that stub. No committed micro-architecture exists yet.\n\n## Abstract\n\nThe integer multiply/divide unit (MDU) implements the RISC-V `M` extension (and optionally `B`, `K`, or vector variants) within each XH-1 core. This document surveys MDU micro-architectures — array multipliers, Wallace/Dadda trees, Booth-recoded multipliers, iterative shift-add multipliers, radix-2/radix-4/radix-8 dividers, and higher-radix/SRT dividers — and evaluates them against the XH-1 design constraints: per-core area and power budgets, latency targets, throughput requirements, verification complexity, and the multiplicative cost of replicating the unit across 128 cores. The analysis concludes that a parameterized iterative shift-add MDU with optional early-exit and a modest dedicated array multiplier is the most defensible starting point, but flags the assumption-laden nature of the recommendation.\n\n## Research Question\n\n> What MDU micro-architecture best satisfies the XH-1 per-core area, power, latency, and throughput targets while remaining tractable to verify, to replicate 128 times, and to expose to the RISC-V ISA and toolchain?\n\nSub-questions:\n\n1. Should multiplication and division share datapath hardware or be independent units?\n2. What latency is required to avoid becoming a structural hazard in the XH-1 pipeline?\n3. What is the minimum-radix divider that meets the per-core throughput target?\n4. Does the cost of a fast array multiplier (e.g., radix-4 Booth with Wallace tree) justify its latency benefit over an iterative shift-add design replicated 128 times?\n5. Which RISC-V extensions must be supported in v1 (`M` only vs. `M+B` vs. `M+B+K`)?\n\n## Background\n\n### RISC-V `M` Extension Semantics (FACT)\n\nThe RISC-V `M` extension defines the following operations on the `XLEN`-bit registers (RV64 assumed for XH-1 unless stated otherwise):\n\n- `MUL`, `MULH`, `MULHSU`, `MULHU` — 64×64 → lower-64 / upper-64 signed/unsigned products.\n- `DIV`, `DIVU`, `REM`, `REMU` — signed/unsigned division and remainder, 64÷64 → 64 quotient and 64 remainder.\n- `MULW`, `DIVW`, `DIVUW`, `REMW`, `REMWU` — 32-bit operations that sign-extend the 32-bit result to 64 bits.\n\nCorner cases the MDU must handle per the ISA:\n\n- Division by zero returns `0xFFFFFFFFFFFFFFFF` (quotient) and the dividend (remainder) for unsigned, and `-1` / dividend for signed.\n- The most-negative signed integer (`0x8000…`) divided by `-1` must return the dividend as quotient and `0` as remainder; this traps on x86 but is non-trapping in RISC-V.\n- Overflow behavior is *only* defined for signed division/remainder by `-1`; no other overflow is architecturally visible.\n\n### Latency vs. Throughput (FACT)\n\n- A 64×64 → 128-bit full multiplication requires at minimum 128 partial-product rows for a non-Booth radix-2 design, ~64 rows for radix-4 Booth, ~43 rows for radix-8 Booth.\n- Bit-serial shift-add multiplication completes in 64 cycles.\n- Restoring division completes in 64 cycles; non-restoring in 32–64 cycles depending on the normalization of the remainder; higher-radix SRT dividers in O(log radix(N)) cycles but with substantially larger area.\n\n### RISC-V `B` and `K` Extensions (FACT, partial)\n\n- `B` (Bitmanip) under RV64 1.0.0 includes `MULH`, `MULHU`, `MULHSU` already in `M`, and adds rev-8.0/1.0 bitmanip groups such as `CLMUL`, `CLMULH`, `CLMULR`, `MIN[U]`, `MAX[U]`, `ANDN`, `ORN`, `XNOR`, `SEXT.B/H/W`, and the `Zba`/`Zbb`/`Zbs` sub-extensions.\n- `K` (cryptography) adds `Zkn` (AES/SHA) and is not in scope for the base MDU.\n- `Zmmul` provides multiply-only and is a common power-optimized subset of `M`.\n\n## Existing Approaches\n\n| Approach | Latency (typ., 64-bit) | Area (relative) | Throughput | Notes |\n|---|---|---|---|---|\n| Iterative shift-add multiplier | 64 cycles | 1× | 1 / 64 cycles | Smallest area; low throughput |\n| Radix-4 Booth + carry-save | ~17 cycles | ~4–6× | 1 / ~17 | Common in embedded OoO |\n| Radix-4 Booth + Wallace tree + final CPA | ~3–5 cycles | ~8–12× | 1 / cycle (pipelined) | Used in high-perf cores |\n| Pipelined array multiplier (k stages) | k cycles | large | 1 / cycle | Throughput-bound, area-heavy |\n| Radix-2 non-restoring divider | 32–64 cycles | 1× (shared with MUL possible) | 1 / 32–64 | Low area |\n| Radix-4 SRT divider | ~16 cycles | ~3–5× | 1 / ~16 | Moderate |\n| Radix-8/16 SRT divider | ~8–10 cycles | large | 1 / ~10 | High-end OoO |\n| Combinational 64×64 array (no pipelining) | ~10+ gate delays | very large | 1 / many cycles | Impractical |\n| Shared MUL/DIV datapath (Liang/Montusiewicz style) | variable | ~1.5× single-function | variable | Saves ~30–40% area at the cost of CPI |\n\n(Quantitative magnitudes in this table are estimates from public micro-architecture literature; values vary considerably with cell library, target frequency, and pipeline integration. See Sources.)\n\n## Alternative Designs\n\n### A. Pure Iterative Shift-Add MDU\n\nA single 128-bit accumulator-based datapath. Each cycle shifts the multiplicand and adds if the corresponding multiplier bit is set, or performs a non-restoring division step. The same hardware services both MUL and DIV.\n\n### B. Pipelined Iterative MDU\n\nSame datapath as A, but cut into N pipeline stages (commonly 2 or 4) to allow clock-frequency scaling. Issues per-cycle throughput remains 1 op / N cycles for a single operand width.\n\n### C. Dedicated Array Multiplier + Iterative Divider\n\nA small radix-4 Booth/Wallace multiplier (lower 64 bits in 3–4 cycles) and a separate radix-2 or radix-4 non-restoring divider. Two independent units that can operate concurrently.\n\n### D. Shared Pipelined Radix-4 MDU\n\nA single radix-4 Booth partial-product generator feeding a shared CSA tree, with a reconfigurable final-stage adder and a small division state machine. Latency: ~5–8 cycles for MUL, ~16 for DIV.\n\n### E. Pipelined High-Performance MDU (Wallace/Wallace + SRT-4)\n\nMulti-cycle but pipelined radix-4 multiplier and SRT-4 divider. Both deliver 1 op/cycle throughput once steady-state. Area dominates the integer datapath.\n\n### F. `Zmmul`-Only MUL, External DIV Trap\n\nImplement MUL in hardware (small array or iterative), trap DIV/REM to a software handler. The privileged trap path is fast on XH-1 only if the software model tolerates it; SPECint and most server workloads execute division frequently enough that this is usually unacceptable.\n\n### G. Compressed / Shared Across Cores\n\nA single physical MDU shared by N cores via a NoC-side arbiter. Removes per-core area cost but introduces structural contention; this is generally considered an *adverse* design for a 128-core tiled machine.\n\n## Comparison\n\n| Design | Area/cell count (est.) | Cycles/op MUL | Cycles/op DIV | Throughput (steady) | Verif. complexity | Replicated ×128 cost | Power/cores at 1 GHz (est.) |\n|---|---|---|---|---|---|---|---|\n| A. Iterative | 1.0× | 64 | 32–64 | 1/64 | Low | low | low |\n| B. Pipelined iter. (2-stage) | ~1.1× | 32 | 16–32 | 1/32 | Low–Medium | low | low–medium |\n| C. Array MUL + iter DIV | ~6–8× | 3–5 | 32–64 | 1/cycle (MUL) | Medium | high | medium–high |\n| D. Shared radix-4 | ~4–6× | 5–8 | 16 | 1/cycle (MUL) | Medium–High | medium | medium |\n| E. Pipelined Wallace + SRT-4 | ~12–20× | 1/cycle | 1/cycle | 1/cycle | High | very high | high |\n| F. Zmmul + trap | ~1–2× | variable | trap | low | Lowest | lowest | lowest |\n| G. Shared across cores | 1/N per core | +NoC latency | +NoC latency | contended | High (coherency) | lowest in area, highest in latency | lowest in static power, high in dynamic on miss |\n\n(All non-FACT values are PROPOSAL/ESTIMATE pending the XH-1 cell library and frequency target.)\n\n## Advantages\n\n- **A (iterative):** lowest area and verification cost; trivially replicated ×128; deterministic timing; well-suited to in-order pipelines with a single MDU reservation station.\n- **C (array + iter):** low MUL latency benefits compiled code with tight multiply chains (CRC, hashing, address computation); the iterative divider keeps area under control.\n- **D (shared radix-4):** good balance; single unit means fewer ports on the issue queue, simpler back-pressure, easier to verify than E.\n- **E (pipelined):** removes MDU as a critical path for high-frequency operation; appropriate only if XH-1 is a high-frequency out-of-order core.\n- **F (Zmmul + trap):** smallest possible die; useful if division is genuinely rare on the target workload.\n- **G (shared across cores):** minimal replicated area; only viable if the NoC has spare bandwidth and the workload tolerates MUL/DIV latency (uncommon).\n\n## Disadvantages\n\n- **A:** 64-cycle MUL is a structural hazard in nearly all non-trivial programs. Most RISC-V cores ship a faster multiplier.\n- **B:** still poor MUL throughput; the pipelining helps frequency but not CPI for multiply-heavy code.\n- **C:** the array multiplier is the largest single addition; replicating 128 instances dominates the per-core MDU area. The iterative divider becomes the long pole.\n- **D:** the radix-4 booth encoder + Wallace reduction is the single most verification-intensive block in the integer datapath; high combinatorial depth impacts timing closure.\n- **E:** the worst replication cost; if the XH-1 core is in-order (not established by repository context), this is overkill.\n- **F:** division traps in scientific, crypto, and some HPC kernels; would require a fast software path that defeats the area saving.\n- **G:** a single shared MDU becomes a hot spot; under load, the queuing delay exceeds a 64-cycle per-core iterative design. Also violates the principle that each core should be self-sufficient for any single instruction.\n\n## XH-1 Considerations\n\n- **ISA scope (ASSUMPTION):** XH-1 implements RV64IMAC or RV64GC. Until the decoder document (`research/03-core-design/decoder.md`) defines the supported extension set, MDU scope must include both `M` and the bitmanip multiply subset if `B` is present.\n- **Pipeline style (UNKNOWN):** if the XH-1 core is in-order, an iterative or low-radix MDU is sufficient. If out-of-order, a pipelined unit is more defensible. The repository does not yet establish this.\n- **Per-core MDU ports (ASSUMPTION):** at most one MDU op per cycle per core, regardless of out-of-order issue width.\n- **FPU integration (OPEN):** RISC-V `F`/`D` extensions can be serviced by a separate FPU MDU (for fused multiply-add) or by forwarding to the integer MDU. Coupling decisions affect the MDU port count.\n- **NoC and coherence (ASSUMPTION):** the 128 cores share a coherent memory subsystem; the MDU reads two source registers and writes one (or two for `MULH`), so register-file read/write port count is the binding constraint, not the NoC.\n\n## 128-Core Scalability\n\n- The replication cost of any MDU is *exactly* the per-core area × 128 plus shared overhead. A design choice that adds 0.05 mm² per core adds **6.4 mm²** across the chip. The C/D/E rows of the comparison table are therefore the most consequential decision in the MDU document.\n- A shared-across-cores MDU (G) trades replicated area for **structural contention** at 128 cores. With a single shared unit, even a steady-state mix of 10% multiply/divide instructions causes queueing proportional to (1 / (1 − utilization)). At 50% utilization, mean wait time already exceeds the latency of an iterative per-core design. (Estimate, Little's law, INSUFFICIENT EVIDENCE for absolute numbers without a workload profile.)\n- A *clustered* variant — one MDU per cluster of 4 or 8 cores — reduces the replication cost while bounding the worst-case contention. This is RECOMMENDATION-pending and is treated as an OPEN QUESTION below.\n- The MDU contributes directly to per-core power density; if XH-1 is thermally constrained at 128 cores, an iterative design (A/B) is materially preferable.\n\n## Performance Considerations\n\n- A 64-cycle MUL means a `for (i=0;i<n;i++) h = h * 31 + buf[i];` style loop runs at ~64 cycles per byte hashed. A 4-cycle pipelined MUL runs at ~4 cycles per byte. Workloads with high multiply density (cryptography, signal processing, JIT compilers, regex, hash joins) are order-of-magnitude sensitive to this number.\n- A 64-cycle DIV is acceptable for most scalar code; high-radix SRT dividers benefit primarily vectorized divide loops. INSUFFICIENT EVIDENCE to assume XH-1 will see heavy scalar divide.\n- The MDU rarely becomes the *bottleneck* even at 64 cycles/iter, because most programs do not back-to-back issue multiplies. The MDU *does* become a critical path on a small set of inner loops.\n\n## Area Considerations\n\nPer-order estimates for a modern 7nm-class cell library (ASSUMPTION — no XH-1 process node established):\n\n- Iterative 64-bit shift-add: ~3,000–6,000 gates.\n- Radix-4 Booth + Wallace + CPA, 64-bit: ~15,000–30,000 gates.\n- Pipelined (3-stage) radix-4 64-bit: ~25,000–45,000 gates.\n- SRT-4 divider: ~10,000–20,000 gates.\n- These are PROPOSAL figures pending a real synthesis. They vary ±2× with library and timing constraints.\n\nMultiplying by 128:\n\n- 5,000 gates × 128 = 640,000 gates (~0.3–0.5 mm² at 7 nm, est.).\n- 30,000 gates × 128 = 3.84 M gates (~2.5–4 mm² est.).\n- 50,000 gates × 128 = 6.4 M gates (~4–7 mm² est.).\n\nA full XH-1 die estimate is INSUFFICIENT EVIDENCE without a floorplan.\n\n## Power and Energy Considerations\n\n- Combinational depth × switching activity × capacitance determines dynamic power. Iterative shift-add has the lowest dynamic power at the cost of executing more cycles; a fully combinational array multiplier has the highest dynamic power per op.\n- Per-op energy is a *U-shaped* function of latency: very short-latency units burn more energy per cycle but fewer cycles; very long-latency units have low per-cycle leakage but high total leakage over 64 cycles. The minimum is typically in the 4–16 cycle range for a 64-bit MUL. (PROPOSAL — general principle, not specific to XH-1.)\n- Replicating a high-power MDU 128 times has thermal and PDN implications: the power distribution network must support the worst-case aggregate.\n\n## Implementation Considerations\n\n- Booth encoders, partial-product compressors, and SRT quotient-selection logic are notoriously timing-sensitive. Synthesis with `set_max_delay -datapath_only` is generally required; the floorplan must hold these cells together.\n- Iterative shift-add trivially implements in standard cell logic; no special datapath cell library is required.\n- Sharing multiplier and divider datapath (Design D) requires careful multiplexing that introduces a critical-path hazard; many designs simply keep them as separate functional units to ease timing closure.\n- The MDU corner-case logic (divide-by-zero, signed-overflow-on-(-1)) is small but error-prone; reference model should be exhaustive on these inputs in verification.\n\n## Verification Considerations\n\n- Iterative shift-add: the state space is small; UVM directed and constrained-random coverage is straightforward.\n- Array multiplier: corner cases (e.g., operand = `0x8000_0000_0000_0000` in `MULHSU`, mixed sign/zero) require formal verification of the partial-product array. Strongly recommend a co-simulation against a software reference (e.g., the Spike golden model or a Python oracle).\n- SRT divider: quotient-digit selection is the standard formal-verification target; the choice of *r* (radix), *p* (redundancy), and the PLA/ROM selection table is sensitive to off-by-one in the redundancy constants. Several published bugs in commercial processors stem from SRT tables.\n- Across 128 cores, *manufacturing* test coverage becomes a concern: each MDU must be DC/AC testable, requiring scan insertion and possibly BIST.\n- Cross-bar functional verification (does each core's MDU behave identically?) is most easily done with identical replicated RTL — a heterogeneous MDU design increases verification surface.\n\n## Software Considerations\n\n- Compilers generate `MUL`/`MULH` pairs for 128-bit multiplications. If MUL is fast but MULH is slow (or vice versa), the *paired* latency matters, not the per-instruction latency.\n- `Zmmul` (no DIV) is rarely enabled in general-purpose code because GCC/Clang emit DIV freely; turning it on requires recompiling with `-mno-div` and accepting performance loss on division-heavy code.\n- The RISC-V psABI requires MUL/DIV results in the integer register file; the MDU must write the integer RF, not a sidecar.\n- Vector (`V`) and Packed-SIMD (`P`) extensions, if added later, may have separate vector MDU requirements that are *out of scope* for this document.\n\n## Recommendation\n\n**RECOMMENDATION (provisional, low-to-medium confidence):** Adopt **Design B (pipelined iterative MDU)** as the v1 default, with the data path sized to support the `M` extension. Rationale:\n\n- 128× replication makes the per-core area of Designs C/D/E potentially prohibitive (PROPOSAL — depends on the die area budget, which is INSUFFICIENT EVIDENCE).\n- A 2-stage pipelined iterative design provides ~32 cycles/op MUL and ~16 cycles/op DIV, which is sufficient for the majority of scalar RISC-V code paths and substantially cheaper to verify than any array/SRT design.\n- A small (optional) **Design C fallback** — a dedicated 64×64 → 64 lower radix-4 array multiplier alongside the iterative divider — should be retained as a synthesis experiment in early RTL exploration to confirm the area/power cost is acceptable.\n- If early benchmarks (INSUFFICIENT EVIDENCE) show MUL throughput as a binding constraint, escalate to Design D; if the core is confirmed in-order, Design A may be reconsidered.\n\nThis recommendation is explicitly contingent on the unresolved items in **Open Questions** and should be revisited when the pipeline and decoder documents are populated.\n\n## Confidence\n\n| Sub-area | Confidence | Reason |\n|---|---|---|\n| RISC-V `M` semantics | **High** | Spec is unambiguous and well-established. |\n| Latency of iterative vs. array | **High** | Standard textbook numbers; broadly verified. |\n| Per-core area estimates | **Low** | No process node, no cell library, no frequency target. |\n| 128-core replication impact | **Low–Medium** | Magnitudes are defensible, but absolute numbers depend on die budget and floorplan. |\n| Verifier complexity ranking | **Medium** | General industry consensus; no XH-1 verification plan exists. |\n| Pipeline style (in-order vs. OoO) | **None** | Not established by repository context; this single unknown dominates the recommendation. |\n| Per-core MDU port count | **Low** | Not established. |\n| FPU / vector / bitmanip scope | **Low** | Awaiting decoder document. |\n\nOverall recommendation confidence: **Low-to-Medium.** The recommendation is the least-bad default under the current evidence; it should not be treated as committed.\n\n## Open Questions\n\n1. **Is the XH-1 core in-order or out-of-order?** (Blocks the latency target and the throughput requirement.)\n2. **What is the target clock frequency and process node?** (Determines whether a radix-4 array multiplier can meet timing in a single cycle.)\n3. **What is the per-core die-area budget for the integer execution units?** (Drives the 128× replication cost.)\n4. **What is the supported ISA extension set in v1?** (M only, IMAC, GC, or GCB+V?)\n5. **Does the FPU have its own multiplier, or does it forward to the integer MDU?** (Affects port count and result-bus topology.)\n6. **What is the expected workload mix on XH-1?** (Server, HPC, embedded, AI inference — different mix radically changes the MUL/DIV latency sensitivity.)\n7. **Is a clustered MDU (one per 4 or 8 cores) an acceptable design point?** (Requires coherency/NoC discussion, currently unaddressed in this document tree.)\n8. **Is the MDU required to be IEEE-754 compatible in any way, or only RISC-V `M`/`B` semantics?** (FPU integration question.)\n9. **What is the verification methodology — UVM, formal, both, lightweight directed-random?** (Drives the complexity analysis above.)\n\n## Sources\n\n- RISC-V *Unprivileged ISA Specification*, Volume I, Document Version 20191213 (and later). Publicly available at the RISC-V International site. Used for `M`/`B` extension semantics and corner cases.\n- RISC-V *“B” Bitmanip Extension*, version 1.0.0 draft (RISC-V International). Used for the bitmanip scope discussion.\n- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (multiple editions) — general background on multiplier/divider design and area/energy tradeoffs. Specific quantitative claims in this document are not from this source and are labelled ESTIMATE/PROPOSAL.\n- Weste & Harris, *CMOS VLSI Design: A Circuits and Systems Perspective* — array multiplier, Booth, and Wallace tree area/latency discussion. Magnitudes in the comparison table are not directly cited from this text; they are PROPOSAL/ESTIMATE.\n- Ercegovac & Lang, *Digital Arithmetic* — SRT division, quotient-digit selection tables. Specific radix-4 selection tables are not reproduced here.\n- *The Microarchitecture of Pipeline and Superscalar CPUs* (Shen, Lipasti) — pipelined iterative vs. array multiplier tradeoffs. General principles only.\n\nINSUFFICIENT EVIDENCE: any XH-1-specific synthesis result, benchmark number, die area, frequency target, or workload measurement. All numerical values in this document that are not directly from the RISC-V spec are PROPOSAL or ESTIMATE.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":706,"completion_tokens":5439,"total_tokens":6145,"cost":0,"is_byok":false,"prompt_tokens_details":{"cached_tokens":691,"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}}}