
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787681983-KgLFHxwzEcip8jzl0Cbd","object":"chat.completion","created":1787681983,"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":"# Multiply-Divide Unit\n\n## Status\n\nEngineering research document, pre-synthesis. All quantitative values below are explicitly labeled as unvalidated estimates, heuristics, or INSUFFICIENT EVIDENCE where no source can be cited. No measurement against a target technology library, layout, or workload has been performed for XH-1. The primary recommendation is conditional on synthesis data that does not yet exist in the XH-1 repository.\n\n## Abstract\n\nThe multiply-divide (MUL/DIV) unit implements the integer multiplication and division instructions defined by the M extension of the RISC-V ISA on the RV64I base (commonly written RV64IM, since the M extension is implied when one says RV64I + M). In XH-1, the MUL/DIV unit sits on the execution path of each of the 128 cores, and its latency, throughput, area, and energy directly influence per-core performance and the die-level power and thermal envelope. This document surveys existing MUL/DIV architectures (iterative, array, Radix-4/8 Booth, array-of-serial, non-restoring, and SRT division), compares their trade-offs across per-core and cluster-shared organizations, and proposes a design direction suitable for a 128-core RISC-V processor where replication, area, and energy are first-class constraints. No design point in this document has been validated against a target process, frequency, or workload.\n\n## Research Question\n\nWhat MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:\n\n- Per-core area must be small enough to replicate the unit 128 times on one die, or alternatively the unit must be shared across a small cluster of cores with acceptable latency and contention. The per-core area budget is currently UNKNOWN; the EX-stage latency budget is TBD by `pipeline.md`.\n- The unit is on a non-critical path for most general-purpose code but is on the critical path for scientific, cryptographic, hash, and DSP workloads.\n- IEEE 754 floating-point support is out of scope for this document; only integer MUL/DIV is considered. F/D extension implications are listed as an open question.\n- Verification must scale to 128 cores; deterministic, fully combinational MUL and bounded-iteration DIV designs simplify verification. A divider with data-dependent early-exit is a verification complication that is noted but not resolved here.\n\n## Background\n\n### Required Instructions (RV64I + M)\n\nThe M extension defines the following on RV64 (per the RISC-V Unprivileged ISA, Document Version 20191213, Chapter 7, \"M Extension\"):\n\n- MUL: 64×64 → lower 64 bits of the product.\n- MULH: 64×64 signed×signed → upper 64 bits of the product.\n- MULHSU: 64×64 signed (rs1) × unsigned (rs2) → upper 64 bits.\n- MULHU: 64×64 unsigned×unsigned → upper 64 bits.\n- DIV, DIVU, REM, REMU: 64-bit signed/unsigned divide and remainder.\n- MULW: 32×32 → lower 32 bits, sign-extended to 64.\n- DIVW, REMW: 32×32 signed divide and remainder, sign-extended to 64.\n- DIVUW, REMUW: 32×32 unsigned divide and remainder, sign-extended to 64.\n\nThe header of the previous revision referred to \"RV64IM (and optionally M-extension),\" which is incoherent because M is part of RV64IM by definition. The scope of this document is the M extension on RV64I.\n\n### Latency and Throughput Ranges (Background Only)\n\nPublished open-source RISC-V cores report approximate latency ranges. These are background reference values from named cores; they are not measurements of XH-1. The values attributed to specific cores below are taken from source-file inspection of public repositories, not from synthesis or PPA reports.\n\n| Operation        | Reported latency range (cycles) | Reported throughput      | Source basis                                                          |\n|------------------|---------------------------------|--------------------------|-----------------------------------------------------------------------|\n| MUL (lower 64)   | 1–3                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`; Ariane `mult.sv`                           |\n| MULH (upper 64)  | 3–5                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`                                             |\n| DIV/REM (64-bit) | 8–64                            | 1 per N cycles           | Rocket: 35–39 cycle radix-4 iterative; Ariane: 33–35 cycle NR-ish; BOOM: configurable |\n| MULW/DIVW family | similar to 64-bit variants      | similar                  | Same                                                                  |\n\nThe exact latency in any given core depends on the EX-stage timing budget, the process corner, and the divider radix. INSUFFICIENT EVIDENCE exists in the XH-1 repository to pin XH-1 to a specific cycle count.\n\n### Division Algorithms (Background)\n\n- Restoring division: simple, one bit per iteration, simple control, slow.\n- Non-restoring division: a class of bit-serial dividers that avoid the explicit restore step. Includes the iterative subtract-and-shift form (one bit/cycle) and array (combinational) forms. SRT is a redundant-digit extension of the non-restoring family. The term \"non-restoring\" in this document refers to the iterative subtract-and-shift form unless otherwise noted.\n- SRT division (radix-2, radix-4, radix-16): a redundant-digit non-restoring division; quotient-digit selection allows more than one bit per iteration. Higher radix reduces iteration count at the cost of more complex selection logic and a larger redundant residual representation.\n- Newton–Raphson reciprocal multiplication: pre-computes an approximation of the reciprocal via iteration, then multiplies. Variable latency, convergence-dependent.\n- Goldschmidt division: similar trade-off to Newton–Raphson.\n\n### Multiplication Algorithms (Background)\n\n- Shift-and-add multiplier: simple, slow, one bit per cycle.\n- Array (Braun / Baugh–Wooley) multiplier: combinational, O(n²) partial products and full-adders, deterministic single-cycle latency, large area.\n- Wallace / Dadda tree multiplier: O(n log n) partial-product reduction using 3:2 and 4:2 compressors; faster critical path, less regular layout. The choice between Wallace and Dadda is largely a layout / regularity preference; INSUFFICIENT EVIDENCE to prefer one over the other without synthesis.\n- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count compared to a naive array by recoding one operand as overlapping signed digits.\n- Compressor-tree implementations (3:2 counters, 4:2 compressors, Ling / Han–Carlson adders) trade area for shorter critical paths.\n\n### Partial-Product Counts for Radix-4 and Radix-8 Booth (Worked)\n\nFor a 64-bit signed operand encoded in radix-4 (overlapping 2-bit windows), the number of signed-digit rows is ⌈64/2⌉ = 32, plus one sign-correction row for negative-operand handling, for a total of 33 partial-product rows. The 33rd row is not a free addend; it exists to correct the sign-extension terms produced when the Booth recoding expands a negative operand. Verification authors should treat this row as a separate partial product with its own correctness argument.\n\nFor a 64-bit signed operand encoded in radix-8 (overlapping 3-bit windows), the number of signed-digit rows is ⌈64/3⌉ = 22, plus one sign-correction row, for a total of 23 partial-product rows. The previous revision's \"11 partial products\" figure for a 64-bit radix-8 encoder is incorrect and is corrected here; 11 is approximately correct for a 32-bit radix-8 encoding (⌈32/3⌉ = 11 digits, no separate sign row in some formulations) but not for 64-bit.\n\n## Existing Approaches (Per-Core, Unless Noted)\n\nThe following architectures are well-known and serve as comparison baselines. All area-multiplier numbers in this section are unvalidated estimates; no synthesis has been performed.\n\n### A1. Iterative Shift-and-Add Multiplier + Restoring Divider\n\n- Multiplier: 64 cycles, 1 bit/cycle.\n- Divider: 64 cycles (restoring) or ~64 cycles (non-restoring). A 64-bit radix-2 non-restoring divider takes 64 iterations on a 64-bit operand; the 32-cycle figure in the previous revision is unjustified for a 64-bit radix-2 design and is corrected to 64 here.\n- Area: very small. Used as the 1× baseline in the comparison table.\n\n### A2. Booth-Radix-4 Multiplier + Iterative Non-Restoring Divider\n\n- Multiplier: 33 partial products reduced through a 4:2 tree. Two pipeline stages; 2-cycle latency, 1/cycle throughput.\n- Divider: 64-cycle non-restoring, 1/64 throughput.\n- Area: estimated ~3–4× of A1; INSUFFICIENT EVIDENCE without a technology file.\n\n### A3. Pipelined Radix-4/8 Booth Multiplier + Radix-4 SRT Divider (Non-Pipelined SRT)\n\n- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.\n- Divider: radix-4 SRT, ~16 cycle latency when not pipelined, 1/16 throughput. The previous revision oscillated between \"pipelined internally\" and \"typically not deeply pipelined\"; this entry adopts the non-pipelined SRT-4 view for direct comparison with B4. A pipelined SRT-4 with 1/cycle throughput is a separate design point (B4-pipe).\n- Area: estimated ~5–7× of A1; INSUFFICIENT EVIDENCE without a technology file.\n\n### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider\n\n- Multiplier: 64×64 → 128 in a single cycle, large area.\n- Divider: 4–8 cycle latency via radix-16 selection.\n- Area: estimated ~10–15× of A1; INSUFFICIENT EVIDENCE without a technology file.\n\n### A5. Shared / Clustered MUL/DIV Unit\n\n- A single MUL/DIV unit serves N cores, accessed via a small FIFO or blocking interface.\n- Saves replicated area; increases latency under contention.\n- A natural fit for 128-core designs only if inter-core divide/mul traffic is low or bursty.\n\nThis alternative was not analyzed in depth in the previous revision; it is included here as a candidate organization (see B7).\n\n## Alternative Designs (Per-Core, Unless Noted)\n\n### B1. 2-Stage Pipelined Radix-4 Booth Multiplier + 64-Cycle Non-Restoring Divider\n\n- Radix-4 Booth encoding of two 64-bit operands produces 33 partial products (32 signed-digit rows plus one sign-correction row). Partial-product reduction through a 4:2 compressor tree, followed by a final carry-propagate add split across two pipeline stages.\n- Latency 2 cycles, throughput 1/cycle.\n- Divider: 64-cycle radix-2 non-restoring iterative divider with explicit worst-case latency. The previous revision named 32 cycles; the corrected value is 64 iterations for a 64-bit operand, with the option of a 1-cycle \"skip when both operands are zero\" guard but no other early-exit that would change the worst case. Any data-dependent early-exit (e.g., trailing-zero detection on the dividend) is recorded as a TBD microarchitectural feature and not assumed in the worst-case latency budget.\n- Area: estimated ~3–5× of A1; INSUFFICIENT EVIDENCE without a technology file.\n\n### B2. 3-Stage Pipelined Radix-8 Booth Multiplier + 64-Cycle Non-Restoring Divider\n\n- 23 partial products for a 64-bit operand (22 signed-digit rows plus one sign-correction row). The previous revision's \"11 partial products\" figure is corrected here.\n- Latency 3 cycles, throughput 1/cycle.\n- Smaller critical path than B1 at the cost of higher area and more complex Booth-3 encoding.\n\n### B3. Iterative Multiplier with Multi-Cycle Variable Latency\n\n- A single 64×64 multiplier reused across MUL/MULH/MULHSU/MULHU by selecting output bits.\n- Latency 4–5 cycles, 1/cycle throughput.\n- Smaller area than B1; longer issue-to-use distance complicates scheduling.\n\n### B4. Pipelined Radix-4 SRT Divider (Standalone, Two Variants)\n\n- B4 (non-pipelined): 16-cycle latency, 1/16 throughput, non-pipelined.\n- B4-pipe (pipelined): 16-cycle latency, 1/cycle throughput, deeply pipelined.\n- The previous revision was internally inconsistent between text and table; the two variants are recorded here as separate design points.\n- Divider-only area: estimated ~3–4× the B1 non-restoring divider. When added to a B1 multiplier, total unit area is estimated ~6–8× of A1 for B4-pipe. The \"3–4× divider\" and \"6–8× total to A2\" numbers in the previous revision refer to different baselines and are reconciled in the Comparison table.\n- Larger area than B1's divider; more verification complexity (quotient-digit selection must be proven correct for all residuals).\n\n### B5. Newton–Raphson Divider with Hardware Reciprocal Iteration (64-bit)\n\n- For 64-bit dividend/divisor: a 32-bit reciprocal approximation is refined via Newton–Raphson iteration (typically 2 iterations to reach 64-bit accuracy), then multiplied by the dividend, with a correction step. Total latency is approximately 6–10 cycles for 64-bit operands, of which the multiplies are 1 cycle each (assuming a B1-class multiplier is available) and the reciprocal iterations are 1–2 cycles each. The 4–6 cycle figure in the previous revision applies to 32-bit operands and is corrected here for the 64-bit case.\n- Lowest divide latency for many operand classes, but variable and dependent on operand class (convergence count is worst-case bounded but typical-case data-dependent).\n- Complex verification: requires convergence proof or guarded iteration count plus a fallback path.\n\n### B6. Combinational Array Divider (Non-Restoring 2D Cell Array)\n\n- Single-cycle 64-bit divide via a 2D array of controlled add/subtract cells, sometimes called a \"combinational non-restoring divider\" or just \"array divider.\" The term is not standardized; this document uses \"combinational non-restoring array divider\" to disambiguate.\n- Estimated very large area (order-of-magnitude larger than a 64-bit combinational multiplier, but INSUFFICIENT EVIDENCE for an exact ratio). The previous revision's \"~50×\" figure was an unsupported round number and is not retained.\n- Likely unacceptable for 128-core replication.\n\n### B7. Cluster-Shared MUL/DIV Unit (8 Cores per Unit, 16 Units Total)\n\n- A single radix-4 Booth multiplier + radix-4 SRT divider (B1 + B4-pipe) shared by 8 cores via a small FIFO.\n- 16 instances on the die instead of 128.\n- Per-cluster area budget can absorb a faster divider than per-core replication allows.\n- Latency and contention penalty under simultaneous divide requests. Contention behavior depends on the issue model (blocking, non-blocking with FIFO, full reservation station); the choice is TBD.\n\n## Comparison\n\nThe following table lists estimated per-unit characteristics. All numbers are unvalidated estimates pending synthesis. Relative area is normalized to A1 (1×); the actual ratios depend on the technology library, target frequency, and choice of final adder. For B7 the per-cluster area is given; the per-core effective area is per-cluster area divided by 8.\n\n| Design                                          | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area (per unit)         | Per-core effective area | Verification Complexity |\n|-------------------------------------------------|-------------|----------------|-------------|----------------|----------------------------------|-------------------------|-------------------------|\n| A1. Shift-add + restoring                       | 64          | 1/64           | 64          | 1/64           | 1×                               | 1×                      | Low                     |\n| A2. Booth-r4 + NR div                           | 2           | 1/1            | 64          | 1/64           | ~3–4× (unvalidated)              | ~3–4×                   | Low–Medium              |\n| A3. Pipelined r4/r8 + SRT-4 (non-pipe)          | 2–3         | 1/1            | 16          | 1/16           | ~5–7× (unvalidated)              | ~5–7×                   | Medium                  |\n| A4. Combinational + SRT-16                      | 1           | 1/1            | 4–8         | 1/4–1/8        | ~10–15× (unvalidated)            | ~10–15×                 | High                    |\n| B1. 2-stage r4 + NR-64 (no early-exit)          | 2           | 1/1            | 64 worst    | 1/64           | ~3–5× (unvalidated)              | ~3–5×                   | Low–Medium              |\n| B2. 3-stage r8 + NR-64                          | 3           | 1/1            | 64 worst    | 1/64           | ~4–6× (unvalidated)              | ~4–6×                   | Medium                  |\n| B4. SRT-4 (non-pipelined), divider only         | n/a         | n/a            | 16          | 1/16           | adds ~3–4× to A2 divider (unval.) | n/a (divider)           | Medium                  |\n| B4-pipe. SRT-4 (pipelined, 1/cycle), divider only| n/a        | n/a            | 16          | 1/1            | adds ~6–8× to A2 total (unval.)  | n/a (divider)           | Medium–High             |\n| B5. Newton–Raphson (64-bit)                     | 1           | 1/1            | 6–10        | 1/6–1/10       | ~6–8× (unvalidated)              | ~6–8×                   | High                    |\n| B6. Combinational non-restoring array divider   | 1           | 1/1            | 1           | 1/1            | very large (unvalidated)         | very large              | Medium                  |\n| B7. Cluster-shared (per 8 cores) B1 + B4-pipe   | 2           | 1/1            | 16          | 1/1 (when free)| per-cluster ~8–12× A1 (unval.)   | ~1–1.5× A1 per core     | Medium–High             |\n\nThe previous revision compared only per-core designs and omitted the per-core effective area column for B7. The per-core effective area for B7 is approximately per-cluster area divided by 8, which makes the cluster organization attractive only if the per-core MUL/DIV unit would otherwise exceed the per-core area budget by a factor of 5–8× or more. The trade-off (per-core area savings vs. inter-core contention latency) is not quantified in this document.\n\n## Proposal (Resolved, Conditional on Synthesis)\n\nPROPOSAL (PRIMARY, CONDITIONAL): Adopt B1 (2-stage pipelined Radix-4 Booth multiplier, 33 partial products, 4:2 compressor tree, 2-cycle latency, 1/cycle throughput) paired with a 64-cycle radix-2 non-restoring iterative divider with explicit worst-case latency. The 32-cycle figure in the previous revision is corrected to 64.\n\nCONDITIONAL UPGRADE: If workload analysis (TBD) or synthesis results show that 64-cycle divide latency is a bottleneck, upgrade the divider to B4-pipe (pipelined radix-4 SRT, 16-cycle latency, 1/cycle throughput). The trigger condition is empirical and is not assumed to hold by default.\n\nORGANIZATIONAL FALLBACK: If per-core area constraints prove tighter than current unvalidated estimates, evaluate B7 (cluster-shared organization, 16 instances serving 8 cores each, FIFO interface) with a per-cluster B1 + B4-pipe datapath. The trigger condition is a per-core area budget exceeded by B1's estimated footprint.\n\nThis resolves the prior contradiction between the abstract PROPOSAL (which named a pipelined SRT-4) and the final Recommendation (which named a 32-cycle non-restoring divider). The remaining sections are aligned to B1 + 64-cycle non-restoring divider as the primary proposal, with B4-pipe as a conditional upgrade and B7 as a separate organizational fallback. The proposal is conditional on synthesis data and on a per-core area budget that has not yet been established.\n\n## Advantages\n\n- 2-cycle pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest per-core area, suitable for replicated 128-core operation.\n- 64-cycle non-restoring iterative divider has explicit worst-case latency that does not depend on operand values, simplifying pipeline scheduling, forwarding, and verification.\n- Radix-4 Booth and radix-2 non-restoring division are well-understood and have reference implementations in Rocket, BOOM, and Ariane (specific measurements: INSUFFICIENT EVIDENCE in the XH-1 repository; see Sources).\n\n## Disadvantages\n\n- 64-cycle divide is slow for workloads dominated by large-integer arithmetic (RSA, big-integer math, certain cryptographic primitives). The conditional B4-pipe upgrade addresses this at additional area cost.\n- A non-restoring iterative divider has the lowest per-core area but penalizes every divide by up to 64 cycles, which can be felt in hash-table probing, parser/lexer dispatch, and some interpreter dispatch loops.\n- Booth encoding complicates verification of signed/unsigned correctness for MULH / MULHSU / MULHU; the verification plan must cover all four sign combinations explicitly.\n- The design's performance on divide-heavy workloads depends on the in-order / out-of-order issue model, which is TBD.\n\n## XH-1 Considerations\n\n- ASSUMPTION: XH-1 is a 128-core design with a short pipeline (TBD by `pipeline.md`). The MUL/DIV unit must fit in a small per-core area budget and the EX-stage latency budget.\n- ASSUMPTION: The design targets a balance of general-purpose and HPC-adjacent workloads; therefore a moderately fast (but not the fastest) divider is acceptable as the default, with an explicit upgrade path.\n- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.\n- The W-variants (MULW, DIVW, DIVUW, REMW, REMUW) reuse the lower 32 bits of the 64-bit datapath with sign-extension at the output, not a separate 32-bit datapath.\n\n### Instruction Coverage\n\n- MUL/MULH/MULHSU/MULHU: supported.\n- DIV/DIVU/REM/REMU: supported, with RISC-V-spec corner cases handled explicitly.\n- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.\n\n### Edge Cases (RISC-V Spec, Document Version 20191213, Chapter 7)\n\nThe following are the architecturally specified results. The previous revision contained an error in the DIVU-by-zero description; the corrected behavior, stated consistently using two's-complement bit patterns, is:\n\n- DIV by zero: quotient = 2^XLEN − 1 (all bits set, which is the two's-complement representation of −1); remainder = dividend (x).\n- DIVU by zero: quotient = 2^XLEN − 1 (all bits set, which is also the two's-complement representation of −1 for an XLEN-bit signed interpretation, but is the unsigned all-ones value); remainder = dividend (x).\n- REM by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (two's-complement −1).\n- REMU by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (unsigned all-ones).\n- Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0.\n- REM sign rule: the sign of the remainder follows the sign of the dividend. This is a frequent bug source and must be covered explicitly in verification; the previous revision did not call it out.\n\nNote on terminology: \"quotient = −1\" and \"quotient = 2^XLEN − 1\" describe the same bit pattern in two's complement. This document uses the unsigned 2^XLEN − 1 form throughout to avoid ambiguity about sign interpretation. The unit must produce these results without raising an exception.\n\n## 128-Core Scalability\n\n- Per-core area: a small 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree, a 2-stage pipelined final adder, and a 64-cycle non-restoring divider is expected to be a small fraction of a typical RV core area, but the exact fraction is INSUFFICIENT EVIDENCE because no baseline core area has been established for XH-1.\n- Floorplanning: a regular MUL/DIV layout that mirrors across all 128 cores is preferred to avoid routing asymmetry that would break clock distribution and thermal symmetry.\n- Voltage / frequency: a moderately pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.\n- Contention: per-core replication means there is no inter-core contention for the MUL/DIV unit. The only contention is intra-core (e.g., two dependent divides in flight in an out-of-order pipeline). The cluster-shared B7 organization reintroduces inter-core contention; this is the central trade-off.\n- Test / DFT: 128 instances of the MUL/DIV unit (or 16 instances in B7) must be tested. A scan-friendly, fully synchronous design with no asynchronous reset paths inside the iterative divider is preferable. DFT strategy is addressed in a dedicated section below.\n\n## Performance Considerations\n\n- For general-purpose code, MUL/DIV is rarely the bottleneck; a 2-cycle MUL latency matches typical issue-to-use distances.\n- For cryptography, the relevant metric depends on the algorithm. Karatsuba multiplication and certain Montgomery multiplication formulations (e.g., CIOS, FIOS) use full 64×64→128 multiplies and select either the lower or upper half depending on the step; MULH throughput is therefore relevant to some Montgomery and Karatsuba sequences, not only to software-emulated 128-bit integers. The previous revision's claim that MULH is irrelevant to Montgomery/Karatsuba is oversimplified and is corrected here to a softer form: MULH matters for software-emulated 128-bit integers and for some Montgomery / Karatsuba formulations; the precise relevance is algorithm-dependent. A specific algorithm study is out of scope for this document.\n- For hash tables and interpreters, DIV latency matters more than throughput; a 64-cycle divider is acceptable but not ideal.\n- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.\n- A 64-cycle divide in a deeply pipelined in-order core can be tolerated if the divider is non-blocking and the result is forwarded late; the claim that \"in-order cannot tolerate a 64-cycle divider\" is too strong and is not made here.\n\n## Area Considerations\n\n- ASSUMPTION (unvalidated, heuristic): A 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree and 2-stage pipelined final adder is on the order of 0.02–0.10 mm² in a typical 7nm process, depending on target frequency, Vdd, and FF corner. No source is cited; INSUFFICIENT EVIDENCE to refine this without a technology file. The 10× range is not a die-budget input and must be replaced with synthesis data.\n- ASSUMPTION (unvalidated, heuristic): A 64-cycle non-restoring iterative divider is on the order of 0.01–0.05 mm² in the same envelope.\n- PROPOSAL (unvalidated): Total MUL/DIV area target: <0.15 mm² per core. 128× replication: ~20 mm². These numbers are order-of-magnitude estimates and must be replaced with synthesis data before being used for die budgeting. The previous revision provided a similar target without a baseline; the same caveat applies.\n- The choice between a Wallace and a Dadda tree implemented with 4:2 compressors is largely a layout / regularity preference; INSUFFICIENT EVIDENCE to prefer one over the other without synthesis. The claim that the 4:2 compressor tree is \"more area-efficient than a Wallace tree\" is removed.\n- Sign-extension and zero-extension muxes for MULW are negligible area.\n\n## Power and Energy Considerations\n\n- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.\n- The iterative divider has lower average switching power than a fully combinational divider, but its long residency increases leakage energy per operation.\n- Power gating: at 128 cores, a per-core power-gate for the MUL/DIV unit is worth considering if idle periods dominate. The wake-up latency and IR-drop impact on the power grid are not yet analyzed; INSUFFICIENT EVIDENCE without a full-die power analysis.\n- Energy per multiply is heuristic: energy tends to scale with the number of switching nodes in the critical reduction tree. This is a rule of thumb, not a measured result; INSUFFICIENT EVIDENCE for a specific quantitative claim.\n- Energy per divide is dominated by the 64-cycle residency; data-dependent early-exit (if implemented) reduces energy for typical operands but the worst-case energy remains.\n\n## Implementation Considerations\n\n- Synchronous, single-clock-domain design inside the unit.\n- No asynchronous resets inside the iterative divider; synchronous reset only at the start of an operation.\n- Final carry-propagate adder: Kogge–Stone, Han–Carlson, and Brent–Kung are all viable. The choice depends on the EX-stage timing budget and the area target; Kogge–Stone / Han–Carlson are faster but larger, Brent–Kung is smaller but slower. The previous revision named a default without justification; this document records the choice as a trade-off driven by the EX-stage timing budget, to be decided after synthesis.\n- Divider quotient and remainder registers are 64 bits each, with an extra bit for the iterative sign.\n- The microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.\n- Output muxing for MUL / MULH / MULHSU / MULHU / MULW is a small mux tree, not a separate datapath.\n- Booth encoding produces 33 partial products for radix-4 of a 64-bit operand (32 signed-digit rows plus one sign-correction row). The sign-correction row is required for negative-operand correctness; verification must cover it explicitly.\n\n## Verification Considerations\n\n- Formal verification of the multiplier compressor tree and final adder is feasible with bounded model checkers and is recommended.\n- Directed tests for division edge cases: ÷0 (signed and unsigned, both quotient and remainder), INT64_MIN / −1, dividend = divisor, dividend = 0, divisor = 1, all-ones, alternating bits, dividend = −1, divisor = 2.\n- Explicit coverage of the REM sign-of-dividend rule.\n- Coverage of all 4 MUL variants (MUL, MULH, MULHSU, MULHU) and the W-variants.\n- Randomized differential testing against a software reference (a GCC-compiled test harness running on Spike or QEMU, or a Python / C++ golden model) is recommended.\n- 128-core DFT: see the dedicated section below.\n\n### DFT Strategy (128 Replicated Units)\n\n- Single-clock-domain, synchronous-reset-only design is required for scan insertion.\n- Each MUL/DIV instance is scan-stitched independently; long scan chains between the iterative divider and surrounding logic are avoided to prevent hold-time issues.\n- Scan compression: per-core compression reduces the number of top-level scan pins; the compression architecture is TBD by the DFT plan.\n- BIST: optional per-core BIST for the MUL/DIV unit is feasible given its small size and regular structure; this would reduce ATPG complexity at the cost of additional area for the BIST controller.\n- ATPG implications: the iterative divider is the only sequential element of consequence in the MUL/DIV block; full-scan coverage is straightforward if no asynchronous paths are introduced.\n\n## Software Implications\n\n- Compilers emit MUL freely; no software changes are required.\n- Division by a constant is often transformed by the compiler into a magic-number multiply; the choice of MUL/DIV design therefore disproportionately affects runtime divide performance for code with frequent constant divides.\n- For languages with software-emulated 128-bit integers (`__int128` in C/C++), the compiler emits MULH / MULHU sequences; MULH latency and throughput are the relevant metrics here. This is the primary case where MULH is the key metric.\n- Crypto libraries (libsodium, OpenSSL, mbedTLS) use Karatsuba and Montgomery multiplication formulations whose reliance on MULH vs. MUL is algorithm-dependent; MULH throughput is relevant to some of these formulations and not to others. The previous revision's strong claim that MULH is irrelevant to Karatsuba / Montgomery is corrected to a softer, algorithm-dependent statement.\n- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a 64-cycle divider increases interpreter dispatch latency for that pattern.\n\n## Recommendation\n\nRECOMMENDATION (CONDITIONAL ON SYNTHESIS): Subject to validation against a target technology library, target frequency, and a per-core area budget, adopt B1 (2-stage pipelined Radix-4 Booth multiplier, 33 partial products, 4:2 compressor tree, 2-cycle latency, 1/cycle throughput) paired with a 64-cycle radix-2 non-restoring iterative divider with explicit worst-case latency and no data-dependent early-exit in the base configuration.\n\nRationale:\n\n- Best balance of area, energy, and performance for 128-core replication under current unvalidated estimates, pending synthesis.\n- Deterministic, fully synchronous design simplifies verification and DFT.\n- 1/cycle MUL throughput meets general-purpose and crypto lower-half-multiply needs.\n- 64-cycle worst-case DIV latency is acceptable for general-purpose workloads; an upgrade path to B4-pipe (16-cycle pipelined SRT-4) is reserved for the case where profiling evidence supports it.\n\nThe recommendation is conditional because all area, energy, and latency numbers in this document are unvalidated estimates; the specific B1 + 64-cycle non-restoring choice depends on a per-core area budget that has not yet been established. If synthesis shows that B1 exceeds the per-core area budget, B7 (cluster-shared organization) is the next design point to evaluate before reducing the per-core divider latency.\n\nRECOMMENDATION (CONDITIONAL UPGRADE): If early workload analysis (TBD) or profiling evidence shows that divide latency is a bottleneck, upgrade the divider to B4-pipe (pipelined radix-4 SRT, 16-cycle latency, 1/cycle throughput) at an estimated additional ~3–4× divider area on top of B1's divider (unvalidated). Do not adopt a Newton–Raphson divider unless profiling evidence strongly supports it, due to verification complexity and variable latency.\n\nRECOMMENDATION: Do not adopt a fully combinational non-restoring array divider or a fully combinational multiplier for the replicated 128-core design. The area cost is not justified by the latency benefit at the per-core replication factor.\n\nRECOMMENDATION (FALLBACK): If per-core area constraints prove tighter than estimated, evaluate B7 (cluster-shared organization, 16 instances serving 8 cores each, FIFO interface) with a per-cluster B1 + B4-pipe datapath before reducing the per-core divider latency further. This trades inter-core contention for per-core area and is the right knob to pull when the per-core area budget is the binding constraint.\n\n## Confidence\n\n- Direction of recommendation: MEDIUM. The general design class is well-established; the specific B1 + 64-cycle non-restoring choice depends on a per-core area budget and process node that have not yet been validated.\n- Quantitative area, latency, power, and energy numbers: LOW. No measurements exist in the XH-1 repository; all such numbers in this document are explicitly labeled as unvalidated estimates or INSUFFICIENT EVIDENCE.\n- Verification strategy approach: MEDIUM. The recommended approach (formal on the multiplier, directed + randomized for the divider, explicit REM sign rule) is standard practice. Whether the XH-1 implementation passes the verification plan is not yet known.\n- Spec-level edge-case correctness (i.e., that the RISC-V spec defines the behavior as documented here): MEDIUM. The RISC-V Unprivileged ISA, Document Version 20191213, Chapter 7 is cited as the source; whether the XH-1 implementation matches the spec is not yet verified and is the subject of the verification plan, not a research claim.\n\n## Open Questions\n\n- What is the EX-stage latency budget? (Depends on `pipeline.md`.)\n- What is the target frequency and process node? Determines whether 2-cycle MUL is feasible, and which final-adder architecture is appropriate.\n- Is the design in-order or out-of-order? Out-of-order execution can hide divide latency; in-order can also tolerate a 64-cycle divider if the divider is non-blocking and the result is forwarded late, but the scheduling cost depends on the specific pipeline depth and issue model.\n- Will the MUL/DIV unit share an issue port with the ALU, or have a dedicated issue port? The recommendation assumes the MUL/DIV unit has access to the issue port, but whether the port is shared or dedicated is TBD. If the port is shared with the ALU, the per-cycle issue bandwidth of the MUL/DIV unit must be reconciled with the ALU's, and the throughput numbers in the comparison table must be reinterpreted as \"throughput when the issue port is available.\" A shared port may force B1 throughput below 1/cycle on divide-heavy code.\n- Is there a future F / D extension? If so, the integer MUL/DIV unit may also need to feed FP-to-int conversions or FP reciprocal iterations; this is not yet analyzed.\n- What is the expected workload mix? General-purpose vs. HPC vs. embedded vs. server?\n- Should the MUL/DIV unit be power-gated when idle? At 128 cores, idle probability may be high; wake-up latency and IR-drop impact are TBD.\n- Should the divider support a \"fast-path\" for division by a small constant (e.g., a compiler-inserted reciprocal-multiply hint) as a microarchitectural feature? This is recorded as a TBD feature and is not assumed in the base configuration.\n- Is the B7 cluster-shared organization a realistic fallback, or is per-core replication a hard requirement?\n- What scan-compression architecture will be used for 128 replicated units?\n\n## Sources\n\n- RISC-V Unprivileged ISA, Document Version 20191213, Chapter 7, \"M Extension.\" Defines MUL, MULH, MULHSU, MULHU, DIV, DIVU, REM, REMU, and the W-variants, including the corner-case behavior for division by zero and signed overflow. The \"−1\" and \"2^XLEN − 1\" quotient values for ÷0 are the same bit pattern in two's complement and are documented in this revision of the spec.\n- Rocket Chip, file `src/main/scala/rocket/MulDiv.scala`, public repository. Background reference for typical MUL/DIV organization and reported latency ranges. Specific commit, measured numbers, and PPA data: INSUFFICIENT EVIDENCE in the XH-1 repository to cite.\n- BOOM (SmallBoomConfig and MediumBoomConfig), public repository. Background reference only.\n- Ariane, file `core/multiplier.sv` and related, public repository. Background reference only.\n- Hennessy and Patterson, \"Computer Architecture: A Quantitative Approach.\" General MUL/DIV trade-off discussion. Specific chapter / edition: INSUFFICIENT EVIDENCE in the XH-1 repository to cite.\n- Parhami, \"Computer Arithmetic: Algorithms and Hardware Designs.\" Standard reference for multiplier and divider algorithms including Booth, Wallace / Dadda, SRT, and Newton–Raphson. Specific chapter / edition: INSUFFICIENT EVIDENCE in the XH-1 repository to cite.\n- No quantitative claim in this document is derived from a measurement of XH-1 silicon, layout, or synthesis. All such numbers are explicitly labeled as unvalidated estimates, heuristics, or INSUFFICIENT EVIDENCE.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":11467,"completion_tokens":8968,"total_tokens":20435,"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}}}