
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787682940-3T2XNZATl1EzhuQC3PRE","object":"chat.completion","created":1787682940,"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\nRevision 2. Initial scoping document. No XH-1 implementation decisions are yet committed. This revision corrects factual errors identified in review, removes unsupported quantitative claims, reconciles internal contradictions, and adds missing alternatives.\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, CLMUL, CLMULH, CLMULR). 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 an XH-1 core given that the design will be replicated 128 times, considering latency, throughput, area, power, energy, 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\n**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The RISC-V M extension for RV64 defines the following instructions:\n\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 bit product, then sign-extended to 64 bits and written to `rd`.\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 to 64 bits and written to `rd`.\n\n**FACT** (per RISC-V ISA spec, Volume I, Chapter 7): The M extension defines the following corner-case behavior:\n\n- Division by zero:\n  - `DIV` / `DIVW`: quotient is `−1` (the architectural definition; the bit pattern is `2^XLEN − 1`, all bits set).\n  - `DIVU` / `DIVUW`: quotient is `2^XLEN − 1` (all bits set, which equals `−1` in two's complement representation).\n  - The signed and unsigned cases produce the same bit pattern at the architectural level; the spec writes `−1` for the signed case and the unsigned maximum for the unsigned case, but these are bit-pattern-identical.\n  - `REM` / `REMW`: remainder equals the dividend.\n  - `REMU` / `REMUW`: remainder equals the dividend.\n- Signed overflow (most-negative integer divided by −1):\n  - `DIV` / `DIVW`: quotient equals the dividend (i.e., the most-negative representable value `2^(XLEN−1)`).\n  - `REM` / `REMW`: remainder equals zero.\n- For unsigned divide (`DIVU` / `REMU` / `DIVUW` / `REMUW`), the only defined special case is division by zero; the dividend / `−1` overflow case does not apply because the operands are unsigned.\n\n**NOTE**: A full 64×64→128-bit multiply requires a true 128-bit result datapath even when only the upper or lower 64 bits are returned.\n\n**NOTE** (MULHSU implementation): MULHSU computes the upper 64 bits of a signed×unsigned 64×64 product. A correct implementation generates a partial-product array for 64×64 bits where the unsigned operand's partial products are zero in the upper half of its bit positions and the signed operand's partial products use signed (sign-extended) rows in the final reduction. Two concrete implementation paths exist:\n\n- (a) Use a signed multiplier datapath: sign-extend the signed operand to 128 bits, zero-extend the unsigned operand to 128 bits, and run a signed 128×128 multiply, then take the upper 64 bits. This is straightforward but doubles the multiplier width and is rarely used.\n- (b) The standard approach: zero-extend the unsigned operand to 64 bits (its bit positions are already non-negative), sign-extend the signed operand only in the final partial-product row, and reduce the 64×64 partial-product array with a final row sign-extension. This requires a modified-Booth or array multiplier with explicit sign handling on the last partial-product row.\n\nA pure unsigned Wallace/Dadda tree without a sign-handling front-end does not implement MULHSU correctly, because the signed operand's most significant partial-product row must be sign-extended (or its inverted-and-carry form added) into the reduction tree.\n\n**NOTE**: 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**NOTE**: MULW is implementable on a 32×32→64-bit datapath: the 32-bit product is sign-extended to 64 bits and written to `rd`. The upper 32 bits of the 64-bit intermediate result are discarded. A 32×32→64-bit fast multiplier (B3 datapath) can therefore implement MULW by taking its lower 32 bits and sign-extending to 64.\n\n**NOTE**: The carry-less multiply instructions CLMUL, CLMULH, and CLMULR are part of the standard Zbc extension (commonly grouped under the umbrella \"B\" extension in some profiling). They are not part of M. They require a different datapath (AND-tree with XOR reduction, no carry propagation) and are not the subject of this document except where they interact with operand muxes / writeback. CLMULR in particular produces a 2·XLEN-bit result with explicit carry-in/carry-out behavior across the two halves; its implementation shares the AND-tree with CLMUL/CLMULH but adds a dedicated reduction stage for the carry path.\n\n### Latency Reference Points\n\n**FACT (Rocket Chip, UC Berkeley generator)**: Rocket Chip is in-order, and the MUL/DIV unit is configuration-dependent across Rocket's `Configs.scala` parameter set. In `RocketCoreConfig` (commonly cited as the default), the multiplier is pipelined with multiple pipeline stages (multi-cycle iterative, new operation accepted per cycle) and the divider is a radix-4 iterative divider. The exact stage counts and latencies are determined by parameters in `Configs.scala` and are not a single canonical value. INSUFFICIENT EVIDENCE for a specific latency number without naming the configuration.\n\n**FACT (BOOM v2/v3, UC Berkeley)**: Out-of-order superscalar. MUL is pipelined (latency configuration-dependent). DIV is variable-latency, non-pipelined.\n\n**FACT (XiangShan, open-source OoO RISC-V)**: MUL is pipelined; DIV is variable-latency, non-pipelined.\n\n**FACT (Ibex, lowRISC)**: In-order. MUL is implemented as a single-cycle or short-pipeline combinational multiplier in some configurations; iterative DIV.\n\n**INSUFFICIENT EVIDENCE**: Arm Cortex-A77 per-instruction MUL/DIV latencies are not publicly published by Arm. No specific numbers are cited from a primary source.\n\n**INSUFFICIENT EVIDENCE**: Intel Haswell integer divider internal radix (radix-16 vs. radix-32) is not established from publicly verifiable primary sources. The design is widely reported to be a high-radix shift-subtract divider rather than a Newton-Raphson divider, but the specific radix is INSUFFICIENT EVIDENCE.\n\n### Divide Algorithms\n\n**FACT**: Four primary classes are considered here:\n\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**: rarely used for general-purpose integer divide due to overhead; exist as alternative approaches.\n\n**FACT**: The 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)\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.\n- **Area (DIV only)**: Smallest divider; typically a few kGE plus control. **INSUFFICIENT EVIDENCE** for a specific gate count.\n- **Power**: Lowest of the divider options when idle; minimal toggle rate per non-dividing cycle.\n- **Used in**: Some low-end in-order cores; some configurations of Rocket Chip with smaller radix.\n\n### A2. Pipelined Iterative Divider\n\n- **Datapath**: Two distinct subclasses must be distinguished:\n  - **(A2a) Pipelined iterative loop**: a single shift-subtract array with pipeline registers inserted at one or more points within the iterative loop, allowing a new operation to enter the loop every cycle after the pipeline is filled. Latency remains 64 cycles; throughput is 1 per cycle after fill.\n  - **(A2b) Fully unrolled divider**: 64 shift-subtract stages with pipeline registers between every stage, giving latency 64 cycles and throughput 1 per cycle from the first cycle. Area is roughly 64× the A1 datapath.\n- **DIV Latency**: 64 cycles.\n- **DIV Throughput**: 1 per cycle (after fill for A2a; from cycle 1 for A2b).\n- **Area**: A2a is ~2–3× A1 (a few extra pipeline registers); A2b is roughly 64× A1 and is rarely used.\n- **Power**: Higher toggle rate than A1; only worthwhile under sustained divide streams.\n- **Used in**: Rare; mostly in high-throughput streaming dividers (DSP). Uncommon in general-purpose cores.\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; the concrete iteration count depends on seed precision and convergence criteria. **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 **only if the multiplier is dedicated to the divider**. If the multiplier is shared with the main MUL datapath, throughput is degraded by contention with MUL issue rate and is workload-dependent. **INSUFFICIENT EVIDENCE** for a single throughput number in the shared case.\n- **Area**: 1 reciprocal seed ROM + 1–2 MUL units (sharing possible 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.\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 per cycle if pipelined; 1 per 16 / 8–10 cycles if iterative.\n- **Area**: large lookup table and complex datapath; PLA is a significant area contributor.\n- **Power**: high; many bits toggle per cycle.\n- **Used in**: high-end x86 integer dividers (radix of the integer divider is **INSUFFICIENT EVIDENCE** from primary sources; widely reported as high-radix shift-subtract rather than Newton-Raphson).\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 (radix-4 iterative divider, custom MUL)\n\n- MUL: 64×64→128 pipelined in 1 stage (target), throughput 1 per cycle. This departs from Rocket Chip's default multi-stage MUL (Rocket's `RocketCoreConfig` issues MUL as a multi-cycle iterative operation); the 1-stage MUL is an aggressive target for XH-1.\n- DIV: radix-4 iterative, ~33 cycles (32 cycles for quotient bits + finalization), blocking on the unit.\n- Single divider per core, 1 MUL pipeline stage.\n\n**NOTE on naming**: B1 inherits the radix-4 iterative divider pattern from Rocket and Ibex, but the MUL organization (1-stage pipelined) is a custom choice that does not match either Rocket's multi-stage MUL or Ibex's short-pipeline / combinational MUL. The \"hybrid\" descriptor refers to combining a pipelined MUL with an iterative DIV; the divider side aligns with reference designs, the MUL side does not.\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**: ASSUMING a MUL:DIV area ratio of approximately 1:1 (i.e., one MUL pipeline and one radix-4 iterative DIV are roughly comparable in area, since a 1-stage 64×64 MUL is a Wallace/Dadda tree plus a 128-bit CPA, and a radix-4 iterative DIV is a ~66-bit adder plus control state), the combined (MUL+DIV) area scales as 1 + 1 = 2× B1 (two MULs plus one shared DIV, where B1 has one MUL and one DIV). The 1.5× figure previously cited assumed MUL is half the area of DIV, which is unsupported. The 1.4× lower bound previously cited is unsupported. The corrected qualitative statement is: **~2× B1**, with the explicit MUL:DIV area ratio assumption stated. **INSUFFICIENT EVIDENCE** for a synthesis-derived number.\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 area over pure MUL; **INSUFFICIENT EVIDENCE** for a specific percentage.\n- Useful for DSP, ML, and HPC; 128-core replication benefits workloads with matrix-style kernels.\n\n### B3. Operand-Width-Detected 32-bit Fast MUL Path (also serves MULW)\n\n- Detect when both operands of a 64-bit MUL are sign- or zero-extended from 32 bits (i.e., bit 31 is replicated through bit 63), and route the multiplication through a 32×32→64 fast multiplier.\n- The same 32×32→64 datapath also implements MULW directly: the 32-bit product (lower 32 bits of the 64-bit result) is sign-extended to 64 bits and written to `rd`. This sharing is essentially free in area terms and means that adopting B3 is the natural way to implement MULW.\n- This is **distinct from MULW as a workaround** for the 32-bit-case: B3 accelerates 64-bit MUL / MULH / MULHSU / MULHU when both operands happen to be 32-bit sign- or zero-extended, a pattern common after `lw` / `lwu` followed by arithmetic. MULW alone does not accelerate this case because MULW is a different instruction with different result semantics.\n- **Position**: B3 is the natural choice for the MULW datapath and adds a 32-bit-extended-operand fast path for 64-bit MUL. The verification cost is the dual datapath (32-bit and 64-bit) and the operand-width classifier. At the 128-core replication level, the area overhead is bounded by the 32-bit datapath size, which is much smaller than the 64-bit datapath; the dominant question is verification cost, not area.\n- **Decision**: B3 is recommended as part of the MULW implementation; deferring B3 means deferring the natural MULW implementation, which is not viable if MULW is in the ISA. The B3-vs-B4 trade-off therefore applies to the 32-bit-extended-operand fast path, not to MULW support.\n\n### B4. Bypassable Output with Operand Width Detection (full 64×64→128 only)\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; MULW must still be implemented separately (e.g., via B3 or a dedicated 32×32→32 path).\n- **Position**: B4 conflicts with the natural MULW-via-B3 sharing above; if MULW is required, B4 is not a complete solution. If MULW is not required, B4 simplifies verification at the cost of a slightly larger MUL datapath for MULW-equivalent work.\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- **Corner cases the fast path must handle correctly** (consistent with the iterative path):\n  - dividend = 0, divisor = anything (including 0): quotient = 0, remainder = 0 (dividend).\n  - divisor = 1: quotient = dividend, remainder = 0.\n  - divisor = −1:\n    - dividend = 2^(XLEN−1) (most-negative): quotient = 2^(XLEN−1) (dividend), remainder = 0 (signed overflow case, the M-extension rule).\n    - all other dividends: quotient = −dividend (two's complement negation), remainder = 0.\n- The fast path must explicitly implement these rules; it is not a simple \"if divisor=±1 then return dividend\" because of the signed-overflow case for divisor = −1.\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 **compile-time** 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. **INSUFFICIENT EVIDENCE** for a quantitative reduction without a specific workload profile.\n\n### B7. Dedicated 32-bit Fast Divider for W-suffixed Instructions\n\n- Implement a separate 32-bit radix-2 or radix-4 iterative divider for DIVW / DIVUW / REMW / REMUW. The 32-bit divider has half the iteration count (32 or 16 cycles vs. 64 or 33 for the 64-bit divider) and roughly a quarter of the datapath area.\n- Useful if profiling shows W-suffixed divides dominate; in most general-purpose workloads they do not.\n- Verification cost: dual divider datapath, similar to B3.\n- **Note**: W-suffixed instructions operate on 32-bit operands; a natural alternative is to share the 64-bit divider datapath with the 32-bit operands on the lower 32 bits, taking 32 or 16 cycles of the 64-bit divider's iteration. B7 is only worth its area if the latency savings matter.\n\n### B8. Combined MUL / DIV with Shared Partial-Product Array (CSA Sharing)\n\n- Reuse the MUL's CSA compressor tree as the final correction multiplier for an SRT or Newton-Raphson divider, sharing the most area-intensive block.\n- Reduces the area penalty of A3 / A4 at the cost of tighter verification coupling between MUL and DIV paths.\n- Real architectural option in some high-performance designs; not considered in the prior revision.\n\n### B9. Combined MUL / DIV with Shared Final Carry-Propagate Adder (CPA Sharing)\n\n- Share only the final 128-bit carry-propagate adder between the MUL datapath and the DIV's correction-multiply step (or the DIV's final-cycle remainder correction). The compressor tree, partial-product generation, and divider iteration state remain separate.\n- Lower area savings than B8 (CSA is shared instead of CPA), but much simpler verification: the shared CPA is a single combinational block, and the MUL vs DIV datapaths feeding it are independent.\n- The MUL pipeline register naturally sits between the compressor-tree output and the CPA, which means the CPA itself can be shared at the output side without disrupting the MUL pipeline structure.\n- **Open question**: whether the MUL pipeline register sits at the compressor-tree output (CPA in cycle 2) or at the CPA output (CPA in cycle 1) determines the CPA's pipeline stage. See Implementation Considerations for the canonical placement decision.\n\n### B10. Partially Unrolled Radix-4 Divider (intermediate between A2a and A2b)\n\n- Unroll the radix-4 iterative divider into a small number of pipeline stages (e.g., 8 or 16 stages) rather than the full 64 (A2b) or the single iterative loop (A2a).\n- Latency 32 or 33 cycles (one stage per two quotient bits for 8 stages, or one stage per quotient bit for 16 stages), throughput 1 per cycle after fill, area roughly 8× or 16× A1.\n- A meaningful intermediate option for the high-DIV-throughput case that the prior revision did not consider.\n- Verification: same as A2a (iterative datapath with pipeline registers); the unrolling does not introduce new corner cases.\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 per 64 cycles | INSUFFICIENT EVIDENCE (combined) | Lowest (DIV only) | Low |\n| A2a (pipelined iter. loop) | not defined in A2a | not defined in A2a | 64 cycles | 1 per cycle (after fill) | INSUFFICIENT EVIDENCE | Med | Med |\n| A2b (fully unrolled) | not defined in A2b | not defined in A2b | 64 cycles | 1 per cycle | INSUFFICIENT EVIDENCE (very large) | High | High |\n| A3 (Newton-Raphson) | 1 cycle | 1 per cycle (dedicated) | N+1 MUL cycles (dedicated); workload-dep. if shared | INSUFFICIENT EVIDENCE (shared) | high | High | High |\n| A4 (Radix-16/64 SRT) | not defined in A4 | not defined in A4 | 8–16 cycles | 1 per cycle if pipelined | high | High | High |\n| B1 (radix-4 DIV, 1-stage MUL) | 1 cycle (target) | 1 per cycle | ~33 cycles | 1 per 33 cycles | baseline | Low–Med | Low–Med |\n| B1' (2× MUL + 1× shared DIV) | 1 cycle | 2 per cycle | ~33 cycles | 1 per 33 cycles (shared) | ~2× B1 (INSUFFICIENT EVIDENCE; assumes MUL:DIV area ≈ 1:1) | Med | Med |\n| B2 (+ MAC) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | +unspecified % over B1 (INSUFFICIENT EVIDENCE) | Med | Med |\n| B3 (32-bit fast MUL; serves MULW) | 1 cycle (32-bit path) | 1 per cycle | ~33 cycles | 1 per 33 cycles | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |\n| B4 (full 64 only; MULW separate) | 1 cycle | 1 per cycle | ~33 cycles | 1 per 33 cycles | same as B1 (MULW path TBD) | Med | Lowest (MUL side); Med (MULW) |\n| B5 (skip-on-zero) | n/a | n/a | reduced in common case | same as base | negligible overhead | n/a | Low |\n| B7 (32-bit fast DIV) | 1 cycle | 1 per cycle | ~16–17 cycles (32-bit) | 1 per 16–17 cycles (32-bit only) | +small (INSUFFICIENT EVIDENCE) | Low | Med (dual mode) |\n| B8 (shared MUL/DIV CSA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | lower than A3/A4 alone (INSUFFICIENT EVIDENCE) | Med–High | Med–High (tight coupling) |\n| B9 (shared MUL/DIV CPA) | 1 cycle | 1 per cycle | A3/A4 latency | A3/A4 throughput | slightly higher than B8 reduction (INSUFFICIENT EVIDENCE) | Med | Low (clean separation) |\n| B10 (partially unrolled radix-4) | not defined in B10 | not defined in B10 | ~32–33 cycles | 1 per cycle (after fill) | ~8–16× A1 (INSUFFICIENT EVIDENCE) | Med | Med |\n\n**ASSUMPTION**: Relative area figures are qualitative orderings based on published reference designs cited in the Sources section. Actual XH-1 synthesis numbers are **INSUFFICIENT EVIDENCE** pending RTL implementation.\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 the divider side; the MUL side departs from both references.\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 per 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; 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### B3 (32-bit fast MUL; serves MULW)\n- Natural implementation of MULW; the 32×32→64 datapath produces the MULW result by sign-extending the lower 32 bits.\n- Accelerates 64-bit MUL on 32-bit-valued operands (a common pattern after `lw`/`lwu` + arithmetic).\n- Area overhead is bounded by the 32-bit datapath size (much smaller than the 64-bit datapath).\n\n### B5 (Skip-on-Zero)\n- Negligible area; reduces effective DIV latency for common cases.\n\n### B7 (32-bit fast DIV)\n- Halves the divider iteration count for the W-suffixed instructions at modest area cost.\n\n### B8 (Shared MUL/DIV CSA)\n- Reduces the area penalty of high-performance dividers by sharing the most area-intensive block.\n\n### B9 (Shared MUL/DIV CPA)\n- Lower verification cost than B8; the shared CPA is a single combinational block and the MUL/DIV datapaths feeding it are independent.\n\n### B10 (Partially Unrolled Radix-4)\n- A meaningful intermediate option for high DIV throughput without the area cost of A2b; same verification profile as A2a.\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 per 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- If multiplier is shared with main MUL datapath, throughput is workload-dependent, not the N+1 figure cited for the dedicated case.\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- **B3 does not subsume MULW for the purpose of \"B3 is redundant\"**: B3 and MULW are two different ways to access 32-bit-multiplication, and B3's value is primarily as the natural MULW implementation and secondarily as the 32-bit-extended-operand fast path.\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- The fast path must explicitly handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1): quotient = dividend, remainder = 0.\n\n### B7\n- Verification: dual divider datapath; same concerns as B3.\n- Area saving is moot if W-suffixed divides are not on the critical path.\n\n### B8\n- Verification: tighter coupling between MUL and DIV paths makes corner-case analysis more difficult.\n\n### B9\n- Area savings are smaller than B8 (CPA shared instead of CSA); the savings are bounded by the CPA size, which is significant but not the dominant block.\n\n### B10\n- Area scales with the unroll factor; 16-stage unroll is ~16× A1, which is meaningful at 128-core replication.\n\n## XH-1 Considerations\n\n**PROPOSAL**: The XH-1 core should adopt **B1 (Hybrid MUL + Iterative DIV)** as the baseline, with the following parameters, pending RTL validation:\n\n- **MUL**: 64×64→128, target 1-cycle pipelined (1 stage of pipeline registers), throughput 1 per cycle. The pipeline register sits at the **CPA output** (after the compressor tree and the 128-bit CPA in cycle 1), so the entire compressor-tree-plus-CPA path is in one cycle. This is the \"1-cycle MUL\" interpretation; the fallback-A interpretation splits the compressor tree and the CPA across two cycles. 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. **INSUFFICIENT EVIDENCE** on whether this fits the XH-1 pipeline depth; depends on the integration context.\n- **B5 (skip-on-zero)**: implement at the front end of the DIV unit; negligible overhead. The fast path must handle the signed-overflow corner case (divisor = −1, dividend = 2^(XLEN−1)) by returning quotient = dividend, remainder = 0.\n- **B3 (32-bit fast MUL, also serves MULW)**: include the 32×32→64 datapath as the MULW implementation path. The same datapath accelerates 64-bit MUL on 32-bit-extended operands. Verification cost: dual datapath, manageable with the B3 corner-case set (operand-width detection, sign-extension patterns).\n- **B7 (32-bit fast DIV)**: Defer; the W-suffixed divide is not assumed to be on the critical path. Revisit if profiling shows otherwise.\n\n**ASSUMPTION**: A 1-cycle MUL latency is achievable in the target process. **INSUFFICIENT EVIDENCE** on the XH-1 target process node and clock period. A full 64×64→128 Wallace/Dadda tree + 128-bit carry-propagate adder in a single cycle is at the edge of feasibility for high-performance designs; typical in-order cores implement MUL as either a multi-cycle iterative multiplier or a multi-stage pipelined multiplier. **PROPOSAL**: Validate via synthesis at the target corner before committing. If the 1-cycle critical path cannot be closed, **fallback options** are:\n  - **B1-fallback-A**: 2-cycle pipelined MUL. The pipeline register sits at the **compressor-tree output** (splitting the compressor tree in cycle 1 from the CPA in cycle 2); latency 2 cycles, throughput 1 per cycle, modest area overhead (one extra pipeline register).\n  - **B1-fallback-B**: Multi-cycle iterative MUL (Booth-encoded). The cycle count for a Booth-encoded iterative multiplier on 64×64 is implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number of cycles. Lower area, lower throughput, higher latency.\n  - **B1-fallback-C**: Retain the 1-stage MUL architecture but lower the target clock frequency (system-level decision, not unit-level).\n\n**MUL/DIV resource sharing and contention (single-issue-lane B1)**: Under B1, the MUL pipeline and the DIV datapath share the integer execution lane's issue slot, register-file read ports, and writeback port. The single execution lane can issue either one MUL per cycle (latency 1) or one DIV (latency ~33) at a time, but not both simultaneously. If a MUL is issued while a DIV is in progress:\n- The MUL occupies the issue slot for 1 cycle; the DIV's iterative state is held in the divider's internal registers and does not require the issue slot during its 33 cycles.\n- Register-file read ports: MUL requires 2 read ports for its 1 cycle; the DIV's operands are read at DIV issue and held in the divider's operand register. No contention after issue.\n- Writeback port: MUL writes back in cycle 2 (1-cycle latency); the DIV writes back on completion. A MUL issued in the same cycle as a DIV completion would contend for the writeback port. In a single-writeback-port lane, the DIV completion must be stalled by 1 cycle to let the MUL writeback, or vice versa. This is a 1-cycle throughput loss in the rare case of simultaneous MUL-and-DIV-completion, and is acceptable at 128-core scale (per-core throughput loss is small; aggregate is bounded by the per-core lane).\n- **For 128-core aggregate throughput**: the per-core limitation is the MUL/DIV issue slot, not the divider's iteration. Aggregate MUL throughput is bounded by 1/cycle/core = 128/cycle die-wide. Aggregate DIV throughput is bounded by 1/33 cycles/core = 128/33 ≈ 3.88 divides/cycle die-wide in the steady state if every core is issuing back-to-back independent divides. This is the steady-state upper bound under B1, not a typical workload figure. With B5 reducing some divides to 1 cycle, the aggregate is workload-dependent and typically lower.\n\n**PROPOSAL**: 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, or 2 in the fallback) and variable-latency DIV (~33).\n\n**PROPOSAL**: 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\n**PROPOSAL**: 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\n**PROPOSAL**: 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. CLMUL / CLMULH / CLMULR (Zbc) require an AND-tree / XOR-reduction datapath that is structurally distinct from both the Wallace-tree multiplier and the iterative divider; they do not share the compressor tree. 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\n**PROPOSAL**: 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\n**PROPOSAL**: The MUL/DIV unit's reservation-station entries, divider iteration state, and pipeline registers must support **state retention or clean-state entry** across power gating. Specifically, when a core is power-gated while a long-latency DIV is in flight, the DIV's mid-iteration state must be handled by one of the following:\n  - (a) **Flush and re-issue**: the in-flight DIV is squashed architecturally (the issue queue entry is marked invalid, the divider's iteration state is discarded), and the DIV is re-fetched and re-issued from the I-cache after the core wakes up. This is architecturally transparent if the re-fetch / re-issue mechanism is present (standard OoO replay path); the architectural state is preserved because the DIV is re-executed from scratch. The cost is re-fetch latency after wakeup. The mechanism is \"not acceptable\" only if the re-fetch path is not implemented (e.g., a simple in-order core without replay).\n  - (b) **Checkpoint to retention**: the divider's iteration state is saved to a retention register or to memory before power-down, and restored on wakeup. Preserves the in-flight DIV but requires retention storage proportional to the divider's state.\n  - (c) **Block power-gating until completion**: power-gating is only allowed when the divider is idle. Simple, but defeats the purpose of DPM if DIV latency is long and frequent.\n- The choice depends on the XH-1 DPM policy and on whether the core is in-order or OoO. **INSUFFICIENT EVIDENCE** on the XH-1 DPM policy; the design must accommodate one of these options without committing to a specific approach here.\n\n**OPEN 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 small single-digit percentage of a high-performance core's area, with iterative DIV adding additional area. The prior revision's \"1–3%\" and \"1 MGE/core total\" baseline are removed here as unsourced. **INSUFFICIENT EVIDENCE** on the XH-1-specific area share without synthesis.\n\n**OPEN 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\n**INSUFFICIENT EVIDENCE**: The XH-1 die-area budget, process node, and clock period are not established in this document.\n\n**PROPOSAL**: 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. **PROPOSAL**: The generate block itself must be included in the verification scope (not assumed trivially correct). At minimum: a lint-clean check, a synthesis-check that the generate block instantiates the correct number of cores, and a per-instance equivalence check on a sample of cores.\n\n**PROPOSAL**: For 128× replicated MUL/DIV pipeline registers, ECC or parity protection should be considered for soft-error mitigation. **INSUFFICIENT EVIDENCE** on the XH-1 reliability target.\n\n**PROPOSAL**: Reset distribution and scan chain architecture for 128× replicated MUL/DIV must be addressed at the integration level. The MUL/DIV unit's scan chains should support parallel or staggered scan-shift across cores to keep test time bounded. **INSUFFICIENT EVIDENCE** on the XH-1 DFT architecture.\n\n**CONSIDERATION (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\n**CONSIDERATION (cross-core aggregate throughput)**: Under B1, each core's blocking DIV delivers at most 1 per 33 cycles per core in the steady state. Across 128 cores, the aggregate is at most ~3.88 divides per cycle in the steady state, which assumes all cores are issuing back-to-back independent divides for the full 33 cycles each. This is an upper bound on aggregate throughput, not a typical workload figure. 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\n**CONSIDERATION (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\n**PROPOSAL**: **MUL throughput of 1 per cycle is a target for a high-performance XH-1 core**, but is not architecturally non-negotiable. Low-end in-order cores (some Ibex configurations) implement MUL with throughput < 1 per cycle. B1 satisfies the high-performance target with a 1-stage pipelined multiplier; B1' extends to 2 per cycle for wide-issue. If the 1-cycle MUL cannot be closed at the target process, the throughput target remains 1 per cycle but the latency becomes 2 cycles (B1-fallback-A).\n\n**PROPOSAL**: **DIV throughput of 1 per ~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\n**ASSUMPTION**: 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\" claims are removed as unsourced.\n\n**OPEN QUESTION**: Does XH-1 target HPC or cryptography workloads where MUL/DIV is a larger share of the instruction mix? If yes, the analysis shifts toward A3, A4, A2a, or B10. **NOTE**: ML workloads are dominated by floating-point multiplies on the FPU, not by integer MUL/DIV; integer MUL/DIV is relevant to ML only for quantization, address arithmetic, and integer embeddings.\n\n## Area Considerations\n\n**PROPOSAL**: 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\n**OPEN 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\n**ASSUMPTION**: 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\n**FACT**: 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\n**PROPOSAL**: 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\n**PROPOSAL**: The MUL pipeline register should be a clock-gated scan flop, not a latch, to simplify DFT.\n\n**OPEN 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.\n\n**INSUFFICIENT 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\n**PROPOSAL**: Implement MUL as a **Wallace/Dadda tree of 4:2 compressors** feeding a final 128-bit carry-propagate adder. The 1-cycle latency budget accommodates the entire critical path from operand register → compressor tree → CPA → output register, with the pipeline register at the CPA output. **INSUFFICIENT EVIDENCE** on whether a Wallace/Dadda tree for 64×64 partial products is achievable in one cycle at the XH-1 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\n**MUL pipeline register placement** (clarified):\n- **Primary (1-stage)**: register at CPA output. The compressor tree and the 128-bit CPA are both in cycle 1.\n- **Fallback A (2-stage)**: register at compressor-tree output. The compressor tree is in cycle 1, the 128-bit CPA is in cycle 2.\n- The placement determines the critical path per cycle: in the primary, the per-cycle critical path is tree + CPA; in fallback A, the per-cycle critical path is max(tree, CPA). Fallback A is the natural way to close timing if tree + CPA exceeds the target clock period in a single cycle.\n\n**PROPOSAL**: For MULHSU, the standard implementation generates a 64×64 partial-product array with the unsigned operand's partial products zero in the upper half and the signed operand's final partial-product row sign-extended (or added in inverted-and-carry form) into the reduction tree. The 128-bit-wide signed multiplier datapath is an alternative but doubles the multiplier width and is rarely used.\n\n**PROPOSAL**: 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\n**PROPOSAL**: 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. The fast path must handle the signed-overflow corner case (dividend = 2^(XLEN−1), divisor = −1) by returning quotient = dividend, remainder = 0, consistent with the M-extension rule. Trivial area; reduces effective DIV latency for common cases.\n\n**PROPOSAL**: 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); the B3 32×32→64 datapath implements MULW by taking the lower 32 bits and sign-extending to 64.\n\n## Verification Considerations\n\n**FACT**: 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\n**PROPOSAL**: 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). The reference produces the full 128-bit product; the checker compares the appropriate bits of the 128-bit result against the architectural result:\n  - MUL, MULH, MULHU, MULHSU: lower 64 or upper 64 bits of the 128-bit product, with sign-handling per the ISA spec.\n  - MULW: lower 32 bits of the 64-bit product (where the 64-bit product is computed on a 32×32 signed multiplication, with the 32-bit result sign-extended to 64 bits and written to `rd`). The reference is a 32×32 signed multiply that produces a 32-bit result, which is then sign-extended to 64 bits and compared against the architectural `rd` value. The 128-bit reference path is used for MUL/MULH/MULHU/MULHSU, not for MULW.\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\n**PROPOSAL**: 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 at the unit level. **However**, the verification of the generate block itself, and the interaction between per-core clock-gating / power-state and MUL/DIV state (e.g., does a clock-gated MUL lose its pipeline state correctly across gating? does a power-gated divider leave the iteration counter in a valid state for resumption, or is the DIV flushed and re-issued as in option (a) of the 128-core power-gating proposal?), must be verified explicitly. **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\n**PROPOSAL**: 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\n**PROPOSAL**: 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\n**OPEN 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\n**PROPOSAL**: 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\n**PROPOSAL**: 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 (target 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, with the signed-overflow corner case handled) at the DIV front end. Add **B3** as the MULW implementation and the 32-bit-extended-operand fast path. 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 for high-performance targets).\n2. Keeps per-core area small, manageable at 128× replication.\n3. Avoids the verification burden of B8 (shared CSA) and the area burden of A3 (Newton-Raphson) and A4 (high-radix SRT).\n4. **B3 inclusion is required for MULW**, not optional: the same 32×32→64 datapath that accelerates 64-bit MUL on 32-bit-extended operands also implements MULW directly. Deferring B3 means deferring the natural MULW implementation.\n5. B5 is a near-free improvement to the common case, with the signed-overflow corner case handled correctly.\n6. The MUL/DIV design inherits the radix-4 iterative divider pattern from Rocket and Ibex; the MUL side departs from both references (1-stage pipelined vs. Rocket's multi-stage or Ibex's short-pipeline / combinational), which is an aggressive target that must be validated by synthesis.\n\n**Fallback plan** (if the 1-cycle MUL cannot be closed at the target process / clock):\n- **Primary fallback**: B1-fallback-A — 2-cycle pipelined MUL with the pipeline register at the compressor-tree output. Latency 2 cycles, throughput 1 per cycle, modest area overhead. B1 architecture preserved.\n- **Secondary fallback**: B1-fallback-B — multi-cycle iterative MUL (Booth-encoded). Cycle count implementation-dependent; **INSUFFICIENT EVIDENCE** for a specific number. Lower area, lower throughput, higher latency. DIV remains radix-4 iterative.\n- **Tertiary fallback**: Lower the target clock frequency at the system level.\n\nThis recommendation is **conditional on**:\n- The XH-1 target process supporting either a 1-cycle 64×64→128 MUL critical path (primary) or a 2-cycle pipelined MUL critical path (fallback A) at the target clock. Both 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), a pipelined iterative divider (A2a or B10), or a shared MUL/DIV organization (B8, B9).\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- A clear DPM policy for handling in-flight MUL/DIV state across power gating.\n\nIf any of these conditions fails, re-open the design against the named fallback.\n\n## Confidence\n\n**Medium-High** for B1 as the baseline architectural pattern. **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 and determines whether 1-cycle MUL is feasible.\n2. What is the XH-1 target workload mix? HPC, cryptography, or general-purpose? (ML is not primarily an integer MUL/DIV workload.)\n3. Is the XH-1 core in-order, out-of-order, or hybrid?\n4. Does XH-1 implement RV64B (bit-manipulation) extensions, including Zbc (CLMUL / CLMULH / CLMULR)? 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, and how does it handle in-flight MUL/DIV state across power gating (retention, flush-and-re-issue, or block-power-gate-until-completion)?\n7. Is the MUL/DIV unit expected to support a future RV MAC extension, or is the project strictly RV64IM (or RV64IMB)?\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?\n12. What is the XH-1 reliability target? Does the MUL/DIV pipeline require ECC or parity protection against soft errors?\n13. What is the XH-1 DFT architecture for the 128× replicated MUL/DIV scan chains?\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- Waterman, Asanović, et al. (eds.), *The RISC-V Instruction Set Manual, Volume I: User-Level ISA*, Chapter 16 (B Extension, including Zbc). Canonical ISA reference for CLMUL / CLMULH / CLMULR.\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\n**INSUFFICIENT 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 internal radix of the Intel Haswell integer divider is widely reported as high-radix shift-subtract rather than Newton-Raphson, but the specific radix (16 vs. 32) is **INSUFFICIENT EVIDENCE** from primary sources; Newton-Raphson is reported to be used in Haswell's floating-point unit. The cycle count for a Booth-encoded iterative 64×64 multiplier is implementation-dependent and **INSUFFICIENT EVIDENCE** for a specific number.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":15078,"completion_tokens":14381,"total_tokens":29459,"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}}}