
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787682714-tEOJyLgFEDl9Gc6Plr72","object":"chat.completion","created":1787682714,"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\nStub — initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors, removes unsupported quantitative claims, reconciles contradictions, and adds missing alternatives identified in review.\n\n## Abstract\n\nThis document investigates the design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core. The unit must implement the RV64M extension (MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU, MULW, DIVW, DIVUW, REMW, REMUW) and, depending on project scope, the RV64B bit-manipulation extensions (e.g., CLZ, CTZ, BSET, BEXT). The design must be evaluated against the XH-1's 128-core replication factor: a unit that is only a small percentage of a single core's area consumes a large cumulative area across the die when replicated 128 times. The unit's latency impacts critical-path timing, and its throughput affects overall core IPC under integer-heavy workloads (cryptography, hashing, address arithmetic, HPC kernels).\n\n## Research Question\n\nWhat is the optimal MUL/DIV unit organization for a XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, and verification complexity trade-offs across in-order, out-of-order, and hybrid pipeline styles?\n\n## Background\n\n### RISC-V M Extension Semantics (RV64M)\n\nFACT: The RISC-V M extension for RV64 defines the following instructions:\n- MUL, MULH, MULHU, MULHSU: 64×64→128 bit multiply (lower 64 or upper 64 of result, with sign-handling variations).\n- MULW: 32×32→32 (lower 32 of a 32×32→64 multiply, sign-extended result written to xrd).\n- DIV, DIVU: 64÷64 signed/unsigned quotient.\n- REM, REMU: 64÷64 signed/unsigned remainder.\n- DIVW, DIVUW, REMW, REMUW: 32÷32 signed/unsigned quotient/remainder, sign-extended.\n\nFACT (per RISC-V ISA spec): The M extension defines the following corner-case behavior:\n- Division by zero:\n  - `DIV` / `DIVU` / `DIVW` / `DIVUW`: quotient is `-1` (i.e., all bits set).\n  - `REM` / `REMU` / `REMW` / `REMUW`: remainder equals the dividend.\n- Signed overflow (most-negative integer divided by `-1`):\n  - `DIV` / `DIVW`: quotient equals the most-negative representable value.\n  - `REM` / `REMW`: remainder equals zero.\n- For unsigned divide (`DIVU`/`REMU`/`DIVUW`/`REMUW`), overflow cannot occur; only the divide-by-zero rule applies.\n\nThe full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned. The MULHSU (signed × unsigned) variant requires explicit sign-handling of the signed operand before partial-product reduction; a pure unsigned Wallace/Dadda tree requires a front-end sign-extension / Booth-encoding stage.\n\nNOTE: The W-suffixed instructions (MULW, DIVW, DIVUW, REMW, REMUW) are part of the **M extension** in RV64, not the base I extension. The base I extension's W variants are only the simple ALU ops (ADDW, SUBW, SLLW, SRLW, SRAW).\n\n### Latency Reference Points (FACT, from published RISC-V implementations, see Sources)\n\n- Rocket Chip (SiFive, in-order): MUL is unpipelined and configuration-dependent; commonly cited as 3- or 4-cycle unpipelined iterative multiplier. DIV is variable (radix-4 iterative). INSUFFICIENT EVIDENCE for a single canonical latency number without specifying the Rocket Chip configuration (StandardConfig vs MinimalConfig vs other).\n- BOOM v2/v3 (out-of-order): MUL pipelined; latency configuration-dependent. DIV variable.\n- XiangShan (Nanjing, out-of-order): MUL pipelined, DIV variable.\n- Ibex (lowRISC, in-order): MUL single-cycle combinational or short-pipeline; iterative DIV.\n- Arm Cortex-A77: per-instruction latencies are not publicly published by Arm. INSUFFICIENT EVIDENCE; no specific MUL/DIV latency numbers are cited from a primary source.\n\n### Divide Algorithms\n\nFACT: Four primary classes are considered here:\n1. **Digit-recurrence / shift-subtract (radix-2, radix-4, radix-16, radix-64 SRT)**: radix-2 takes 64 cycles worst case; radix-4 takes ~32–33 cycles; radix-16 takes ~16 cycles; radix-64 takes ~8–10 cycles (with significant area/complexity cost). Iterative, small-to-moderate area depending on radix.\n2. **Newton-Raphson reciprocal multiplication**: multiple iterations of a multiply-based refinement to compute the reciprocal, then a final correction multiply to produce the quotient. Latency depends on initial seed precision and convergence criteria.\n3. **Goldschmidt**: similar convergence behavior to Newton-Raphson, with a different iteration structure.\n4. **CORDIC-based and series-expansion dividers**: rotate-mode or series-expansion methods; rarely used for general-purpose integer divide due to overhead, but exist as alternative approaches.\n\nThe RISC-V M extension does not require IEEE-754 compliant division; integer rounding is sufficient, simplifying hardware.\n\n## Existing Approaches\n\n### A1. Iterative Shift-Subtract Divider (Radix-2, single divider only)\n\n- **Datapath**: 128-bit (64 remainder + 64 divisor) shifter/subtractor, radix-2, 64-cycle worst case.\n- **DIV Latency**: 64 cycles.\n- **DIV Throughput**: 1 divide per 64 cycles (not pipelined).\n- **MUL coverage**: A1 defines a divider only; MUL is not part of this organization. Any combined MUL+radix-2-DIV system must be specified separately.\n- **Area (DIV only)**: Smallest divider; typically a few kGE plus control.\n- **Power**: Lowest of the divider options; minimal toggle rate per non-dividing cycle.\n- **Used in**: Some low-end in-order cores; some configurations of Rocket.\n\n### A2. Pipelined Iterative Divider\n\n- **Datapath**: same shift-subtract array as A1 but with pipeline registers at each iteration; latency fixed at 64 cycles, throughput 1/cycle.\n- **DIV Latency**: 64 cycles, fixed.\n- **DIV Throughput**: 1/cycle.\n- **Area**: ~3–5× A1 due to per-stage registers; significant.\n- **Power**: Higher clock-gating complexity; only worthwhile under sustained divide streams.\n\n### A3. Newton-Raphson Divider\n\n- **Datapath**: shared MUL unit(s), initial reciprocal seed ROM, multiplier used in iterative refinement and one final correction multiply.\n- **Latency breakdown**: seed table lookup (1 cycle) + N refinement multiplies (typically 2–3 iterations for 64-bit integer) + 1 final correction multiply. ASSUMPTION: 3 refinement iterations + 1 correction is typical for 64-bit; concrete iteration count depends on the seed precision and the desired final precision. INSUFFICIENT EVIDENCE for a single canonical iteration count without specifying the seed table and refinement schedule.\n- **Throughput**: one divide per N+1 MUL cycles (where N = refinement iterations), assuming the multiplier is dedicated to the divider.\n- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (one of which can be shared with the main MUL datapath, at the cost of contention); large.\n- **Power**: Higher static and dynamic (multiplier active during divide refinement).\n- **Used in**: Some high-performance FPU designs for floating-point; less common for dedicated integer divide because the integer multiplier is large and the fixed iteration count does not beat pipelined shift-subtract on worst-case latency.\n\n### A4. Radix-16 / Radix-64 SRT Divider\n\n- **Datapath**: high-radix recurrence with a quotient-digit lookup table (PLA or ROM), redundant remainder representation. 16 or 64 bits processed per cycle.\n- **DIV Latency**: ~16 cycles (radix-16) or ~8–10 cycles (radix-64) for 64-bit operands.\n- **DIV Throughput**: 1/cycle if pipelined, or 1 per 16 / 8–10 cycles if iterative.\n- **Area**: large lookup table and complex datapath; PLA is a significant area contributor. Practical only in high-performance designs.\n- **Power**: high; many bits toggle per cycle.\n- **Used in**: high-end x86 integer dividers (e.g., Intel Haswell and later use a radix-16 / radix-32 shift-subtract divider for integer divide, not Newton-Raphson; Newton-Raphson in those designs is used in the floating-point unit).\n\n### A5. Approximate / Lookup-Based Dividers (small operand ranges)\n\n- Rarely used for 64-bit; not relevant to XH-1 unless a specific workload (e.g., 32-bit address arithmetic) dominates.\n\n## Alternative Designs\n\n### B1. Hybrid MUL + Sequential-Iterative DIV (Rocket-style)\n\n- MUL: 64×64→128 pipelined in 1–2 stages.\n- DIV: radix-4 iterative, ~33 cycles (radix-4: 2 quotient bits per cycle, 32 cycles for quotient bits + finalization), blocking on the unit.\n- Latency hide: out-of-order core can issue subsequent independent ops; in-order core must stall.\n- Single divider per core, 1–3 MUL pipelined stages.\n\n### B1'. Two MUL Pipelines + Shared Iterative DIV (wide-issue variant)\n\n- Two pipelined MUL datapaths, one shared radix-4 DIV datapath.\n- MUL throughput: 2/cycle (sustained, independent operands).\n- DIV throughput: 1 per ~33 cycles, shared and blocking.\n- Area: ~1.8–2.0× B1 (two MUL pipelines) + same DIV.\n- Useful for 2-issue or wider cores; the recommendation in the original document of \"replicate to 2 MUL pipelines for wide issue\" is a degenerate case of this option.\n\n### B2. Combined MUL/MAC (Multiply-Accumulate) Unit\n\n- 64×64→128 with an additional accumulator register; supports future RV MAC extensions (proposed in some bitmanip drafts).\n- Adds ~10–15% area over pure MUL (ASSUMPTION; INSUFFICIENT EVIDENCE without RTL).\n- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.\n\n### B3. Configurable MUL Width (32-bit fast path)\n\n- Detect when both operands are zero-extended or sign-extended from 32 bits (e.g., results of MULW, DIVW, DIVUW, REMW, REMUW, or explicit 32-bit-zero-extended operands); use a 32×32→64 fast multiplier.\n- Common in commercial cores (Arm, x86).\n- Branch-predictor / decoder pre-classifies operand width.\n- Open question: whether a \"fast-path 32-bit MUL\" justifies the verification cost given the MULW instruction in RV64M already gives 32-bit semantics with a 32-bit result.\n\n### B4. Bypassable Output with Operand Width Detection\n\n- Always implement full 64×64→128; the decoder examines the instruction to forward only the required 64 bits.\n- Verification: a single source of truth (full 128-bit datapath), reducing dual-mode bugs.\n- Disadvantage: no area saving.\n\n### B5. Skip-on-Zero / Divide-Cancellation Optimizations\n\n- Detect zero dividend (quotient is zero, remainder is dividend) and divide-by-one (quotient is dividend, remainder is zero) at the front end and forward the result without entering the iterative loop.\n- Saves latency in the common case for some workloads; trivial area overhead.\n- Composable with any divider organization.\n\n### B6. Software Divide-by-Constant Transformation (cross-cutting)\n\n- Compilers transform division by a runtime constant into a multiply-by-reciprocal sequence. The hardware DIV is then needed only for division by variables.\n- Reduces effective DIV frequency significantly for workloads with constant denominators; affects hardware sizing decisions.\n\n## Comparison\n\n| Design | MUL Latency | MUL Tput | DIV Latency | DIV Tput | Rel. Area (MUL+DIV) | Power (active) | Verification Complexity |\n|--------|-------------|----------|-------------|----------|----------------------|----------------|--------------------------|\n| A1 (radix-2 iter. DIV only) | not defined in A1 | not defined in A1 | 64 cycles | 1/64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |\n| A2 (pipelined iter. DIV) | not defined in A2 | not defined in A2 | 64 cycles | 1/cycle | INSUFFICIENT EVIDENCE (combined) | Med | Med |\n| A3 (Newton-Raphson) | 1-cycle | 1/cycle | depends on iteration count (see A3) | 1/(N+1) cycles | high (see A3) | High | High |\n| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1/cycle if pipelined | high | High | High |\n| B1 (Rocket-style) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | baseline | Low–Med | Low–Med |\n| B1' (2× MUL + 1× shared DIV) | 1–2 cycle | 2/cycle | ~33 cycle | 1/33 cycle (shared) | ~1.8–2.0× B1 | Med | Med |\n| B2 (+ MAC) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | +10–15% over B1 (ASSUMPTION) | Med | Med |\n| B3 (32-bit fast) | <1 cycle (32-bit path) | 1/cycle | ~33 cycle | 1/33 cycle | varies | Low | Med–High (dual mode) |\n| B4 (full only) | 1–2 cycle | 1/cycle | ~33 cycle | 1/33 cycle | same as B1 | Med | Lowest |\n| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |\n\nASSUMPTION: Relative area figures are estimates based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are INSUFFICIENT EVIDENCE pending RTL implementation. Specific quantitative area multipliers (e.g., \"1.4×\", \"2.5×\", \"3.0×\") from the prior revision are removed in favor of qualitative ordering.\n\n## Advantages\n\n### A1 / B1\n- Smallest area; lowest per-core replication cost.\n- Lowest static and dynamic power in the typical case (most cycles no MUL/DIV active).\n- Simpler verification; one mode of operation.\n- Well-understood reference implementation (Rocket, Ibex) for cross-checking.\n\n### A4 (High-Radix SRT)\n- Lowest DIV latency among the iterative-style options; competitive with A3 on a single divide.\n- Pipelined variant gives 1/cycle DIV throughput.\n\n### A3 (Newton-Raphson)\n- Low latency for sequential divides — important for cryptography (RSA, ECC modular reduction) and HPC.\n- Amortizes multiplier cost if MAC (B2) is also desired.\n- Disadvantage: requires multiple refinement iterations; the integer multiplier is large and contention with the main MUL datapath is a concern.\n\n### B2 (MAC)\n- Enables future-proofing for proposed bitmanip and MAC extensions.\n- Helpful for matrix multiplication kernels running across 128 cores.\n\n### B5 (Skip-on-Zero)\n- Negligible area; reduces effective DIV latency for common cases.\n\n## Disadvantages\n\n### A1 / B1\n- Variable DIV latency complicates scheduling in an in-order core; in-order cores stall ~33 cycles per divide.\n- Worst-case latency hits interrupt latency, branch-target computation if the MUL/DIV is on a branch path.\n- Not a fit for sustained divide-bound workloads (e.g., modulo arithmetic in bignum).\n\n### A3\n- Area at 128-core replication is severe; the multiplier is one of the largest blocks in a typical core.\n- Power: a 64×64 multiplier running 1/cycle is one of the highest-power blocks in a typical core.\n- Verification: Newton iteration precision (must converge to within 1 ULP across all operands) is notoriously subtle.\n\n### A4\n- Large lookup table (PLA or ROM); area and power dominated by the table.\n- Verification: complex quotient-digit selection logic.\n- Not commonly used outside high-end commercial designs.\n\n### B3\n- Verification: dual datapath (32-bit and 64-bit) must be exhaustively cross-checked.\n- The classification logic (operand-width detection) is itself a source of corner-case bugs.\n- The MULW instruction in RV64M already provides 32-bit MUL semantics, so a \"fast path\" for non-MULW 32-bit operands must be justified against MULW's existing semantics.\n\n### B2\n- Adds a third writeback port or accumulator path; competes with the FPU/LSU for writeback slots in a multi-issue core.\n\n### B5\n- Only helps the specific cases of zero dividend or divisor ±1; other optimizations (e.g., division by small powers of two) are already handled by the base I extension's shift instructions.\n\n## XH-1 Considerations\n\nPROPOSAL: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:\n- **MUL**: 64×64→128, 1-cycle pipelined (1 stage of pipeline registers), throughput 1/cycle. For 2-issue or wider cores, scale to B1' (two MUL pipelines sharing one DIV).\n- **DIV**: Radix-4 shift-subtract, ~33 cycles worst case (32 cycles for quotient bits + finalization), blocking, non-pipelined. (The prior revision's \"33–35 cycles worst case\" and the \"33–64 cycle\" range are reconciled here: 33 is the radix-4 bound; 64 corresponds to radix-2, which is a different algorithm choice.)\n- **REM**: Reuse the DIV datapath; remainder is a by-product.\n- **Bypass paths**: From MUL output directly to subsequent dependent ALU/branch in the next cycle.\n- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead.\n- **Operand-width detection**: Defer B3 to a future revision; not justified at the 128-core replication level given the added verification cost and the existence of MULW for the 32-bit case.\n\nASSUMPTION: A 1-cycle MUL latency is achievable in the target process. INSUFFICIENT EVIDENCE on the XH-1 target process node and clock period. PROPOSAL: Validate via synthesis at the target corner before committing.\n\nPROPOSAL: The MUL/DIV unit sits on the integer execution lane, sharing the issue queue with ALU and branch. It has its own reservation station (or issue-slot tag) so the issue logic can distinguish short-latency ALU (1 cycle) from long-latency MUL (1) and variable-latency DIV (~33).\n\nPROPOSAL: For the in-order case, the MUL/DIV unit is non-blocking on MUL (1-cycle latency) but blocking on DIV; the in-order front-end stalls on a structural hazard only when a second DIV is issued before the first completes.\n\nPROPOSAL: For an out-of-order XH-1 core, the MUL/DIV unit exposes its variable DIV latency through the wakeup/select logic so that dependent instructions are replayed or re-issued with the correct ready signal.\n\nPROPOSAL: The B-extension unit (if RV64B is implemented) shares **operand muxes, sign-handling logic, and bit-level muxes** with the MUL/DIV unit but does **not** share the Wallace/Dadda compressor tree. Operations like CLZ, CTZ, BSET, BEXT operate on individual bits or small bit-fields and do not naturally map onto a Wallace-tree multiplier datapath. Any apparent sharing is at the operand-fetch and writeback layers, not the core arithmetic.\n\n## 128-Core Scalability\n\nThe 128-core replication factor is the dominant cost driver for the MUL/DIV unit.\n\nPROPOSAL: At 128 cores, every MUL unit must be **power-gateable independently** so that cores not in use (DPM, dark-silicon) can be fully clock- and power-gated, including the MUL/DIV block.\n\nOPEN QUESTION: What is the actual MUL/DIV area share of the XH-1 core? Published RISC-V references suggest a typical MUL unit occupies a few percent of a high-performance core's area, with iterative DIV adding additional area. The prior revision's \"1–3% FACT\" and \"1 MGE/core total\" baseline are removed here as unsourced. INSUFFICIENT EVIDENCE on the XH-1-specific area share without synthesis.\n\nOPEN QUESTION: Is the MUL/DIV area share dominated by the MUL datapath, the DIV datapath, the operand muxing, or the bypass network? Targeted synthesis required.\n\nINSUFFICIENT EVIDENCE: The XH-1 die-area budget, process node, and clock period are not established in this document.\n\nPROPOSAL: The MUL/DIV unit should be **identical across all 128 cores** (no per-core specialization) to simplify verification and physical design. The replication should be a Verilog/SystemVerilog generate block driven by a single template.\n\nCONSIDERATION (clock and timing at 128× replication): If the XH-1 die includes a global clock-distribution network, the MUL/DIV critical path determines the local clock skew tolerance. A pipelined 1-cycle MUL has a short critical path (one 64-bit adder-equivalent) which is favorable; a non-pipelined iterative divider has a 64-bit adder in its loop, which is the cycle-time limiter. The clock-skew analysis should be revisited at the integration level once the XH-1 clock tree is defined.\n\nCONSIDERATION (cross-core aggregate throughput): Under B1, each core's blocking DIV delivers ~1/33 divides per cycle. Across 128 cores, the aggregate is ~3.9 divides per cycle in the best case (all cores dividing simultaneously), which is the upper bound. Real workloads do not exhibit this worst case; the relevant metric is the per-core latency, not aggregate. INSUFFICIENT EVIDENCE on whether the XH-1 DPM or interconnect imposes a global cap on simultaneous divide activity; this is a system-level question outside the MUL/DIV unit's scope.\n\nCONSIDERATION (operand distribution and interconnect): Replicating a Wallace tree 128× implies 128 sets of wide operand buses to/from the register file. The interconnect / operand-routing network cost scales with the MUL operand width and the number of cores. PROPOSAL: include operand-routing overhead in the area estimate, not just the MUL/DIV datapath itself.\n\n## Performance Considerations\n\nPROPOSAL: **MUL throughput of 1/cycle is non-negotiable** for a modern XH-1 core. B1 satisfies this with a single 1-stage pipelined multiplier. B1' extends to 2/cycle for wide-issue.\n\nPROPOSAL: **DIV throughput of 1/~33 cycles (blocking) is acceptable** for most integer workloads. Workloads that require more (e.g., modular arithmetic in cryptography) will suffer; mitigation is left to software (see Software Considerations).\n\nASSUMPTION: XH-1 target workloads include a mix consistent with Embench / SPECint-class profiles, where MUL/DIV instructions are a small fraction of dynamic instruction count. INSUFFICIENT EVIDENCE on the actual XH-1 target workload mix and on the specific dynamic-instruction share of MUL/DIV. The prior revision's \"<2% MUL/DIV\" and \"<0.5% DIV/REM\" FACT claims are removed as unsourced.\n\nOPEN QUESTION: Does XH-1 target HPC or ML workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3/B2 or a pipelined DIV (A2).\n\n## Area Considerations\n\nPROPOSAL: Budget the MUL/DIV unit at a small single-digit percentage of single-core area for the B1 design, pending synthesis. The exact percentage is INSUFFICIENT EVIDENCE.\n\nOPEN QUESTION: Is the XH-1 core area budget (without MUL/DIV) known? The MUL/DIV area share can be re-expressed as a percentage of the entire 128-core die only when this is established.\n\nASSUMPTION: A1-style radix-2 DIV is the smallest practical divider; A3 (Newton) and A4 (high-radix SRT) are larger, with A4 typically the largest. INSUFFICIENT EVIDENCE on the XH-1-specific gate-count budget.\n\n## Power and Energy Considerations\n\nFACT: A 64×64→128 multiplier toggles a large number of bits per cycle when active; its dynamic power is proportional to operand activity factor. Power-gating the multiplier when idle is essential.\n\nPROPOSAL: The MUL/DIV unit should support **fine-grained clock gating** at the operand-mux boundary so that when no MUL/DIV is in flight, the entire unit is clock-gated to 0 toggle rate.\n\nPROPOSAL: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.\n\nOPEN QUESTION: Does the XH-1 power budget allow all 128 MUL/DIV units to be active simultaneously? If not, per-core DPM must enforce that no more than N MUL/DIV units are in active divide at once. This is a system-level power-management question, not a unit-level one, but it constrains the unit's design (e.g., should the MUL unit support a \"low-power divide\" mode that takes 64 cycles at half frequency?).\n\nINSUFFICIENT EVIDENCE: Specific per-MUL or per-DIV energy numbers for the XH-1 process are not established. The prior revision's \"single-digit pJ in 7 nm\" claim is removed as unsourced; per-MUL energy in advanced processes is implementation-dependent and varies by an order of magnitude or more depending on architecture and clock frequency.\n\n## Implementation Considerations\n\nPROPOSAL: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget must accommodate the entire critical path from operand register → compressor tree → CPA → output register. ASSUMPTION: a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the target clock period. The specific tree depth and CPA depth are implementation-dependent and not asserted as fixed numbers here (the prior revision's \"Tree depth 6–7; final CPA ~6 gates deep\" is removed as unsourced and implementation-specific).\n\nPROPOSAL: For MULHSU (signed × unsigned), include a sign-handling stage (e.g., Booth encoding of the signed operand) before the partial-product reduction tree. A pure unsigned Wallace/Dadda tree does not handle the signed × unsigned case without this front-end.\n\nPROPOSAL: Implement DIV as a **radix-4 shift-subtract** with restoring on negative remainder. 32 cycles for quotient bits + 1 cycle for finalization = ~33 cycles total. The remainder is the \"running remainder\" register after the 33rd cycle; the quotient is the shifted-out bits. REM is selected by muxing the appropriate output.\n\nPROPOSAL: B5 (skip-on-zero): add a front-end detector on the DIV operands that forwards the result directly for divisor = ±1 or dividend = 0, bypassing the iterative loop. Trivial area; reduces effective DIV latency for common cases.\n\nPROPOSAL: Parameterize the MUL width with a Verilog `parameter WIDTH=64` so that the same RTL can be synthesized for 32-bit-only cores (test variant, debug, or soft-IP reuse) without manual rework. Note that WIDTH=32 does not by itself support the MULW instruction semantics in RV64 (which performs a 32×32→64 multiply and sign-extends the 32-bit result); an MULW-specific path is required for RV64.\n\n## Verification Considerations\n\nFACT: MUL and DIV are among the most heavily tested instructions in any RISC-V core; their verification is dominated by **corner-case operand pairs** (e.g., 0, 1, -1, 2, -2, 0x7FFF…, 0x8000…, 0xFFFF…, MSB=1 transitions). For DIV/REM, the corner cases include the division-by-zero and signed-overflow rules defined in the ISA spec.\n\nPROPOSAL: Adopt a **directed-random + constrained-random** verification flow using a golden reference model:\n- **Reference MUL**: SystemVerilog `bit [127:0]` (or DPI-C to a software bigint). Compare lower-64 and upper-64 separately. MULW, MULH, MULHU, MULHSU all share the 128-bit reference.\n- **Reference DIV**: Software bigint that produces (quotient, remainder) per the RISC-V M-extension spec including the division-by-zero and signed-overflow rules for both quotient-producing and remainder-producing instructions.\n- **Coverage**: 100% of the corner cases (above), plus cross-product of small operand values (±1, ±2, ±2^32, ±2^63, ±2^64-1), plus randomized large operands.\n- **Regression list size**: The prior revision's \"64 hand-crafted corner cases\" is removed as a specific number; the regression list should be sized to cover the documented corner cases and is grown as bugs are found. INSUFFICIENT EVIDENCE for a canonical count.\n\nPROPOSAL: At the 128-core replication level, **per-core functional verification** of the MUL/DIV unit is unnecessary if the per-core RTL is identical and constrained-random coverage is closed at the template level (via a SystemVerilog generate block). This covers functional equivalence. **Per-core physical / timing verification is not bypassed**: timing, DFT, and physical-design closure are verified at the integration level on a representative core and assumed replicated, with explicit per-die variation analysis as required by the XH-1 physical-design flow.\n\nPROPOSAL: If the XH-1 verification flow includes formal property checking, the DIV correctness property (\"quotient × divisor + remainder == dividend\" within the RISC-V M extension's special cases) is a clean formal target and should be specified. INSUFFICIENT EVIDENCE on whether formal property checking is in scope.\n\n## Software Considerations\n\nPROPOSAL: Document the MUL/DIV latencies (1 cycle MUL, ~33 cycle DIV) in the XH-1 ABI / ISA reference manual so that compiler backends and library authors can schedule around the long-latency DIV.\n\nOPEN QUESTION: Does the XH-1 ABI / linker convention include a software-emulated division routine for code that cannot tolerate the ~33-cycle blocking latency? If yes, the hardware DIV can be a single issue-slot, not a deeply pipelined one. The compiler can also apply divide-by-constant transformations (B6) to reduce effective hardware DIV frequency.\n\nPROPOSAL: The MUL/DIV unit should raise no architectural exception; the RISC-V M extension defines all corner cases architecturally. This simplifies the trap logic.\n\nPROPOSAL: For 128-core use cases, the MUL/DIV unit is the same in every core; the OS scheduler does not need to be aware of its microarchitectural details. Workload distribution across cores is independent of MUL/DIV design.\n\n## Recommendation\n\n**RECOMMENDATION: Adopt B1 — a hybrid MUL unit (1-cycle pipelined, full 64×64→128) combined with a radix-4 iterative, non-pipelined divider (~33 cycles), sharing no logic. Add B5 (skip-on-zero) at the DIV front end. Place the unit on the integer execution lane. Support full per-unit power and clock gating for 128-core DPM. For wide-issue cores, scale to B1' (two MUL pipelines sharing one DIV).**\n\nRationale:\n1. Matches the dominant MUL workload profile (frequent, 1-cycle latency needed).\n2. Keeps per-core area small, manageable at 128× replication.\n3. Avoids the verification burden of B3 (dual datapath) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).\n4. Aligns with proven reference designs (Rocket, Ibex) reducing architectural risk; this is an architectural-pattern alignment, not a claim of identical pipeline structure, since Rocket and BOOM use different organizations.\n5. B5 is a near-free improvement to the common case.\n\nThis recommendation is **conditional on**:\n- The XH-1 target process supporting a 1-cycle 64×64→128 MUL critical path (must be validated by synthesis at the target corner; INSUFFICIENT EVIDENCE without target process specification).\n- XH-1 workload mix not being dominated by sequential DIV/REM (cryptography). If it is, escalate to A4 (radix-16 SRT) or a pipelined iterative divider.\n- The 128-core replication budget tolerating the cumulative MUL/DIV area; this requires a known single-core area budget, which is INSUFFICIENT EVIDENCE.\n\nIf any of these conditions fails, re-open the design.\n\n## Confidence\n\n**Medium-High** for B1 as the baseline choice. **Low** for specific area, power, and energy numbers — those are estimates based on published RISC-V reference designs, not on XH-1 synthesis data. **Low** for any claim about the XH-1 target process, workload mix, or die size (these are INSUFFICIENT EVIDENCE). The corrected version removes specific unsourced quantitative claims and demotes several prior FACTs to ASSUMPTION or INSUFFICIENT EVIDENCE.\n\n## Open Questions\n\n1. What is the XH-1 target process node and clock period? This constrains MUL critical-path design.\n2. What is the XH-1 target workload mix? HPC, ML, cryptography, or general-purpose?\n3. Is the XH-1 core in-order, out-of-order, or hybrid? (The repository context does not yet establish this fact per the system policy.)\n4. Does XH-1 implement RV64B (bit-manipulation) extensions? The B extension does not naturally share the Wallace-tree multiplier datapath; any sharing is at the operand-mux and writeback layers, not the compressor tree.\n5. What is the XH-1 single-core area budget? What is the die-level area budget for the 128-core fabric?\n6. Does XH-1 use a per-core DPM scheme that requires the MUL/DIV unit to support fine-grained power gating?\n7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM?\n8. Is there a software-emulated division in the XH-1 libc / ABI that would tolerate a long-latency hardware DIV? Will the compiler apply divide-by-constant transformations (B6)?\n9. Does the XH-1 verification flow include formal property verification, and will it be applied to the MUL/DIV unit's \"quotient × divisor + remainder == dividend\" property?\n10. For wide-issue cores, is B1' (two MUL pipelines + one shared DIV) the target, or is single-MUL B1 sufficient?\n11. What is the XH-1 interconnect / operand-routing cost of replicating a wide MUL operand bus 128 times? Should this overhead be included in the MUL/DIV unit's area budget?\n\n## Sources\n\n- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213*, Chapter 7 (M Extension). RISC-V International. (Canonical ISA reference; defines the M-extension corner-case rules for DIV/REM/DIVU/REMU/DIVW/REMW/DIVUW/REMUW and MULW.)\n- Asanović et al., \"The Rocket Chip Generator,\" EECS Department, UC Berkeley, Technical Report UCB/EECS-2016-17, 2016. (Reference for Rocket's MUL/DIV organization; configuration-dependent.)\n- Celio, Patterson, Asanović, \"BOOM v2: a superscalar out-of-order processor,\" 2017. (Reference for BOOM's MUL/DIV design.)\n- Ibex documentation, lowRISC. (Reference for the in-order baseline.)\n- Chen et al., \"XiangShan: An Open-Source High-Performance RISC-V Core,\" 2022. (Reference for high-performance RISC-V MUL/DIV design.)\n- Parhami, *Computer Arithmetic: Algorithms and Hardware Designs*, Oxford University Press. (Reference for shift-subtract, SRT, and Newton-Raphson divide algorithms.)\n- Flynn, Oberman, *Advanced Computer Arithmetic Design*. (Reference for high-radix divider design.)\n- Weste, Harris, *CMOS VLSI Design: A Circuits and Systems Perspective*, 4th ed. (Reference for Wallace/Dadda multiplier design and critical-path analysis; does not by itself establish a specific 1-cycle latency in any particular process.)\n\nINSUFFICIENT EVIDENCE: No XH-1-specific RTL, synthesis, or benchmark measurements are available at the time of this document. All quantitative claims about XH-1 area, power, energy, and timing are INSUFFICIENT EVIDENCE pending RTL implementation and target-process specification. Cortex-A77 per-instruction latencies are not publicly published by Arm and are INSUFFICIENT EVIDENCE from primary sources. The Intel Haswell integer divider is a radix-16 (or higher) shift-subtract divider, not a Newton-Raphson divider; Newton-Raphson is used in Haswell's floating-point unit.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":9344,"completion_tokens":8402,"total_tokens":17746,"cost":0,"is_byok":false,"prompt_tokens_details":{"cached_tokens":135,"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}}}