setup

research/.xh1/runs/20260825T181609Z/attempts

@@ -0,0 +1,6 @@
+2026-08-25T18:17:05Z	research/03-core-design/mul-div-unit.md	1	research	completed
+2026-08-25T18:17:41Z	research/03-core-design/mul-div-unit.md	1	review	VERDICT: FAIL
+2026-08-25T18:18:49Z	research/03-core-design/mul-div-unit.md	2	revision	completed
+2026-08-25T18:19:38Z	research/03-core-design/mul-div-unit.md	2	review	VERDICT: FAIL
+2026-08-25T18:20:47Z	research/03-core-design/mul-div-unit.md	3	revision	completed
+2026-08-25T18:21:21Z	research/03-core-design/mul-div-unit.md	3	review	VERDICT: FAIL

research/.xh1/runs/20260825T181609Z/failed

@@ -0,0 +1 @@
+research/03-core-design/mul-div-unit.md

research/.xh1/runs/20260825T181609Z/research_03-core-design_mul-div-unit.md.current.md

@@ -0,0 +1,339 @@
+# Multiply-Divide Unit
+
+## Status
+
+Engineering 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.
+
+## Abstract
+
+The 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.
+
+## Research Question
+
+What MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:
+
+- 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`.
+- 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.
+- 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.
+- 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.
+
+## Background
+
+### Required Instructions (RV64I + M)
+
+The M extension defines the following on RV64 (per the RISC-V Unprivileged ISA, Document Version 20191213, Chapter 7, "M Extension"):
+
+- MUL: 64×64 → lower 64 bits of the product.
+- MULH: 64×64 signed×signed → upper 64 bits of the product.
+- MULHSU: 64×64 signed (rs1) × unsigned (rs2) → upper 64 bits.
+- MULHU: 64×64 unsigned×unsigned → upper 64 bits.
+- DIV, DIVU, REM, REMU: 64-bit signed/unsigned divide and remainder.
+- MULW: 32×32 → lower 32 bits, sign-extended to 64.
+- DIVW, REMW: 32×32 signed divide and remainder, sign-extended to 64.
+- DIVUW, REMUW: 32×32 unsigned divide and remainder, sign-extended to 64.
+
+The 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.
+
+### Latency and Throughput Ranges (Background Only)
+
+Published 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.
+
+| Operation        | Reported latency range (cycles) | Reported throughput      | Source basis                                                          |
+|------------------|---------------------------------|--------------------------|-----------------------------------------------------------------------|
+| MUL (lower 64)   | 1–3                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`; Ariane `mult.sv`                           |
+| MULH (upper 64)  | 3–5                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`                                             |
+| 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 |
+| MULW/DIVW family | similar to 64-bit variants      | similar                  | Same                                                                  |
+
+The 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.
+
+### Division Algorithms (Background)
+
+- Restoring division: simple, one bit per iteration, simple control, slow.
+- 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.
+- 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.
+- Newton–Raphson reciprocal multiplication: pre-computes an approximation of the reciprocal via iteration, then multiplies. Variable latency, convergence-dependent.
+- Goldschmidt division: similar trade-off to Newton–Raphson.
+
+### Multiplication Algorithms (Background)
+
+- Shift-and-add multiplier: simple, slow, one bit per cycle.
+- Array (Braun / Baugh–Wooley) multiplier: combinational, O(n²) partial products and full-adders, deterministic single-cycle latency, large area.
+- 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.
+- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count compared to a naive array by recoding one operand as overlapping signed digits.
+- Compressor-tree implementations (3:2 counters, 4:2 compressors, Ling / Han–Carlson adders) trade area for shorter critical paths.
+
+### Partial-Product Counts for Radix-4 and Radix-8 Booth (Worked)
+
+For 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.
+
+For 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.
+
+## Existing Approaches (Per-Core, Unless Noted)
+
+The 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.
+
+### A1. Iterative Shift-and-Add Multiplier + Restoring Divider
+
+- Multiplier: 64 cycles, 1 bit/cycle.
+- 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.
+- Area: very small. Used as the 1× baseline in the comparison table.
+
+### A2. Booth-Radix-4 Multiplier + Iterative Non-Restoring Divider
+
+- Multiplier: 33 partial products reduced through a 4:2 tree. Two pipeline stages; 2-cycle latency, 1/cycle throughput.
+- Divider: 64-cycle non-restoring, 1/64 throughput.
+- Area: estimated ~3–4× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A3. Pipelined Radix-4/8 Booth Multiplier + Radix-4 SRT Divider (Non-Pipelined SRT)
+
+- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.
+- 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).
+- Area: estimated ~5–7× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider
+
+- Multiplier: 64×64 → 128 in a single cycle, large area.
+- Divider: 4–8 cycle latency via radix-16 selection.
+- Area: estimated ~10–15× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A5. Shared / Clustered MUL/DIV Unit
+
+- A single MUL/DIV unit serves N cores, accessed via a small FIFO or blocking interface.
+- Saves replicated area; increases latency under contention.
+- A natural fit for 128-core designs only if inter-core divide/mul traffic is low or bursty.
+
+This alternative was not analyzed in depth in the previous revision; it is included here as a candidate organization (see B7).
+
+## Alternative Designs (Per-Core, Unless Noted)
+
+### B1. 2-Stage Pipelined Radix-4 Booth Multiplier + 64-Cycle Non-Restoring Divider
+
+- 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.
+- Latency 2 cycles, throughput 1/cycle.
+- 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.
+- Area: estimated ~3–5× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### B2. 3-Stage Pipelined Radix-8 Booth Multiplier + 64-Cycle Non-Restoring Divider
+
+- 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.
+- Latency 3 cycles, throughput 1/cycle.
+- Smaller critical path than B1 at the cost of higher area and more complex Booth-3 encoding.
+
+### B3. Iterative Multiplier with Multi-Cycle Variable Latency
+
+- A single 64×64 multiplier reused across MUL/MULH/MULHSU/MULHU by selecting output bits.
+- Latency 4–5 cycles, 1/cycle throughput.
+- Smaller area than B1; longer issue-to-use distance complicates scheduling.
+
+### B4. Pipelined Radix-4 SRT Divider (Standalone, Two Variants)
+
+- B4 (non-pipelined): 16-cycle latency, 1/16 throughput, non-pipelined.
+- B4-pipe (pipelined): 16-cycle latency, 1/cycle throughput, deeply pipelined.
+- The previous revision was internally inconsistent between text and table; the two variants are recorded here as separate design points.
+- 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.
+- Larger area than B1's divider; more verification complexity (quotient-digit selection must be proven correct for all residuals).
+
+### B5. Newton–Raphson Divider with Hardware Reciprocal Iteration (64-bit)
+
+- 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.
+- 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).
+- Complex verification: requires convergence proof or guarded iteration count plus a fallback path.
+
+### B6. Combinational Array Divider (Non-Restoring 2D Cell Array)
+
+- 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.
+- 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.
+- Likely unacceptable for 128-core replication.
+
+### B7. Cluster-Shared MUL/DIV Unit (8 Cores per Unit, 16 Units Total)
+
+- A single radix-4 Booth multiplier + radix-4 SRT divider (B1 + B4-pipe) shared by 8 cores via a small FIFO.
+- 16 instances on the die instead of 128.
+- Per-cluster area budget can absorb a faster divider than per-core replication allows.
+- 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.
+
+## Comparison
+
+The 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.
+
+| Design                                          | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area (per unit)         | Per-core effective area | Verification Complexity |
+|-------------------------------------------------|-------------|----------------|-------------|----------------|----------------------------------|-------------------------|-------------------------|
+| A1. Shift-add + restoring                       | 64          | 1/64           | 64          | 1/64           | 1×                               | 1×                      | Low                     |
+| A2. Booth-r4 + NR div                           | 2           | 1/1            | 64          | 1/64           | ~3–4× (unvalidated)              | ~3–4×                   | Low–Medium              |
+| A3. Pipelined r4/r8 + SRT-4 (non-pipe)          | 2–3         | 1/1            | 16          | 1/16           | ~5–7× (unvalidated)              | ~5–7×                   | Medium                  |
+| A4. Combinational + SRT-16                      | 1           | 1/1            | 4–8         | 1/4–1/8        | ~10–15× (unvalidated)            | ~10–15×                 | High                    |
+| B1. 2-stage r4 + NR-64 (no early-exit)          | 2           | 1/1            | 64 worst    | 1/64           | ~3–5× (unvalidated)              | ~3–5×                   | Low–Medium              |
+| B2. 3-stage r8 + NR-64                          | 3           | 1/1            | 64 worst    | 1/64           | ~4–6× (unvalidated)              | ~4–6×                   | Medium                  |
+| 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                  |
+| 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             |
+| B5. Newton–Raphson (64-bit)                     | 1           | 1/1            | 6–10        | 1/6–1/10       | ~6–8× (unvalidated)              | ~6–8×                   | High                    |
+| B6. Combinational non-restoring array divider   | 1           | 1/1            | 1           | 1/1            | very large (unvalidated)         | very large              | Medium                  |
+| 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             |
+
+The 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.
+
+## Proposal (Resolved, Conditional on Synthesis)
+
+PROPOSAL (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.
+
+CONDITIONAL 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.
+
+ORGANIZATIONAL 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.
+
+This 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.
+
+## Advantages
+
+- 2-cycle pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest per-core area, suitable for replicated 128-core operation.
+- 64-cycle non-restoring iterative divider has explicit worst-case latency that does not depend on operand values, simplifying pipeline scheduling, forwarding, and verification.
+- 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).
+
+## Disadvantages
+
+- 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.
+- 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.
+- Booth encoding complicates verification of signed/unsigned correctness for MULH / MULHSU / MULHU; the verification plan must cover all four sign combinations explicitly.
+- The design's performance on divide-heavy workloads depends on the in-order / out-of-order issue model, which is TBD.
+
+## XH-1 Considerations
+
+- 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.
+- 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.
+- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.
+- 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.
+
+### Instruction Coverage
+
+- MUL/MULH/MULHSU/MULHU: supported.
+- DIV/DIVU/REM/REMU: supported, with RISC-V-spec corner cases handled explicitly.
+- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.
+
+### Edge Cases (RISC-V Spec, Document Version 20191213, Chapter 7)
+
+The 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:
+
+- DIV by zero: quotient = 2^XLEN − 1 (all bits set, which is the two's-complement representation of −1); remainder = dividend (x).
+- 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).
+- REM by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (two's-complement −1).
+- REMU by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (unsigned all-ones).
+- Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0.
+- 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.
+
+Note 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.
+
+## 128-Core Scalability
+
+- 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.
+- 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.
+- Voltage / frequency: a moderately pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.
+- 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.
+- 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.
+
+## Performance Considerations
+
+- For general-purpose code, MUL/DIV is rarely the bottleneck; a 2-cycle MUL latency matches typical issue-to-use distances.
+- 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.
+- For hash tables and interpreters, DIV latency matters more than throughput; a 64-cycle divider is acceptable but not ideal.
+- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.
+- 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.
+
+## Area Considerations
+
+- 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.
+- ASSUMPTION (unvalidated, heuristic): A 64-cycle non-restoring iterative divider is on the order of 0.01–0.05 mm² in the same envelope.
+- 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.
+- 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.
+- Sign-extension and zero-extension muxes for MULW are negligible area.
+
+## Power and Energy Considerations
+
+- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.
+- The iterative divider has lower average switching power than a fully combinational divider, but its long residency increases leakage energy per operation.
+- 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.
+- 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.
+- 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.
+
+## Implementation Considerations
+
+- Synchronous, single-clock-domain design inside the unit.
+- No asynchronous resets inside the iterative divider; synchronous reset only at the start of an operation.
+- 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.
+- Divider quotient and remainder registers are 64 bits each, with an extra bit for the iterative sign.
+- The microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.
+- Output muxing for MUL / MULH / MULHSU / MULHU / MULW is a small mux tree, not a separate datapath.
+- 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.
+
+## Verification Considerations
+
+- Formal verification of the multiplier compressor tree and final adder is feasible with bounded model checkers and is recommended.
+- 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.
+- Explicit coverage of the REM sign-of-dividend rule.
+- Coverage of all 4 MUL variants (MUL, MULH, MULHSU, MULHU) and the W-variants.
+- 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.
+- 128-core DFT: see the dedicated section below.
+
+### DFT Strategy (128 Replicated Units)
+
+- Single-clock-domain, synchronous-reset-only design is required for scan insertion.
+- 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.
+- Scan compression: per-core compression reduces the number of top-level scan pins; the compression architecture is TBD by the DFT plan.
+- 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.
+- 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.
+
+## Software Implications
+
+- Compilers emit MUL freely; no software changes are required.
+- 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.
+- 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.
+- 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.
+- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a 64-cycle divider increases interpreter dispatch latency for that pattern.
+
+## Recommendation
+
+RECOMMENDATION (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.
+
+Rationale:
+
+- Best balance of area, energy, and performance for 128-core replication under current unvalidated estimates, pending synthesis.
+- Deterministic, fully synchronous design simplifies verification and DFT.
+- 1/cycle MUL throughput meets general-purpose and crypto lower-half-multiply needs.
+- 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.
+
+The 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.
+
+RECOMMENDATION (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.
+
+RECOMMENDATION: 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.
+
+RECOMMENDATION (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.
+
+## Confidence
+
+- 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.
+- 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.
+- 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.
+- 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.
+
+## Open Questions
+
+- What is the EX-stage latency budget? (Depends on `pipeline.md`.)
+- What is the target frequency and process node? Determines whether 2-cycle MUL is feasible, and which final-adder architecture is appropriate.
+- 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.
+- 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.
+- 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.
+- What is the expected workload mix? General-purpose vs. HPC vs. embedded vs. server?
+- 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.
+- 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.
+- Is the B7 cluster-shared organization a realistic fallback, or is per-core replication a hard requirement?
+- What scan-compression architecture will be used for 128 replicated units?
+
+## Sources
+
+- 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.
+- 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.
+- BOOM (SmallBoomConfig and MediumBoomConfig), public repository. Background reference only.
+- Ariane, file `core/multiplier.sv` and related, public repository. Background reference only.
+- 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.
+- 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.
+- 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.

research/.xh1/runs/20260825T181609Z/research_03-core-design_mul-div-unit.md.review.md

@@ -0,0 +1,62 @@
+VERDICT: FAIL
+
+ISSUES:
+
+1. **Booth radix-4 partial-product count is wrong (B1, B2 background, and Proposal).** The document states radix-4 Booth on a 64-bit operand produces ⌈64/2⌉ = 32 signed-digit rows plus one sign-correction row = 33. This is incorrect. Standard radix-4 Booth-2 encoding of an n-bit operand produces ⌈n/2⌉ = 32 signed-digit rows total (for n=64). The sign-correction is a *bit added to the existing rows* (the MSB of the highest digit), not a separate full-width partial product row. A 64-bit radix-4 Booth multiplier has 32 partial products, not 33. This error propagates to the B1 design description, the proposal, and the recommendation.
+
+2. **Booth radix-8 partial-product count is wrong (B2).** Document claims 22 signed-digit rows + 1 sign-correction = 23. For 64-bit radix-8 Booth, the standard count is ⌈n/3⌉ = 22 signed-digit rows. The "extra sign-correction row" framing is the same misconception as issue 1. The 11-PP correction (vs. 32-bit) is also misleadingly explained.
+
+3. **MULH/MULHU full-product requirement is misleading.** The document states the multiplier is "sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing." A 64×64→128 multiplier is required for MULH/MULHU, but it is not required for MUL; this is a real cost driver. The framing implies the datapath is "free" beyond MUL when in fact the upper 64 bits exist specifically to serve MULH*. The document also fails to note that for 32-bit operands (the W-variants) the full 64×64→128 product is overkill, though reusing the same datapath is reasonable.
+
+4. **Newton–Raphson B5 latency claim is inconsistent and likely wrong.** A 64-bit Newton–Raphson divider with a 32-bit initial reciprocal and 2 iterations does **not** produce a 64-bit-accurate quotient. Two iterations of N–R on a 32-bit seed approximately double the bit-accuracy per iteration, so after 2 iterations you have ~32 + 2·(32 − accuracy) bits — for a properly initialized seed this typically gives ~64 bits only with a carefully chosen seed and the right number of iterations (commonly 2–3 iterations from a 16–32 bit seed, depending on the exact variant). The "6–10 cycles" budget for two multiplies + two iterations + correction is not obviously wrong but the bit-accuracy argument is not given. The "4–6 cycle for 32-bit" prior figure is also not defended.
+
+5. **B6 "combinational non-restoring array divider" size claim is uncalibrated.** The document removes the prior "~50×" figure as unsupported but offers no replacement order-of-magnitude estimate, only "very large." The comparison table still lists "very large (unvalidated)" with no quantitative anchor, which makes the comparison table non-actionable for B6.
+
+6. **B7 per-core effective area math is sloppy.** Cluster of 8 cores sharing one B1 + B4-pipe unit: per-cluster area estimated 8–12× A1, divided by 8 cores gives 1–1.5× A1 per core. But B1 alone is 3–5× A1 and B4-pipe adds more. A cluster containing a full B1 + B4-pipe cannot be "8–12× A1 total" — that range would put the B4-pipe contribution at roughly 0×, which contradicts B4-pipe's stated 6–8× to A2 (i.e., ~3–4× to A1 added on top of A2's 3–4× A1). The cluster cost arithmetic does not close.
+
+7. **B5 throughput "1/6–1/10" is misleading.** Newton–Raphson is variable-latency; throughput depends on whether a subsequent divide can start before the previous finishes. The document treats throughput as 1/latency without justifying the absence of pipelining.
+
+8. **A3 divider throughput of "1/16" is inconsistent with a "pipelined" SRT-4 elsewhere.** A3 is explicitly non-pipelined, but the entry still says "pipelined radix-4/8 Booth multiplier." The A3/B4 split is confusing because the document says A3 is the non-pipelined SRT-4 view "for direct comparison with B4," then later notes B4-pipe is a separate point. This is internally confusing even if not strictly wrong.
+
+9. **Area ranges in the comparison table use A1 as the baseline but the A1 baseline is never quantified.** All relative areas are multiples of an undefined "1×." This is acknowledged but undermines the entire comparison; there is no absolute number to anchor "3–5× of A1" to.
+
+10. **Power/energy section is non-quantitative and largely vacuous.** "Energy tends to scale with switching nodes" is not an analysis. The section does not consider that an iterative divider is the worst case for energy *per divide*, not the best, because 64 cycles of clocked register activity typically dominates the energy budget for a single divide vs. a faster divider that completes in fewer cycles. The framing ("lower average switching power") is misleading without an operations-per-second normalization.
+
+11. **Failure to consider that W-variants need only a 32×32→64 (sign-extended) datapath, not 64×64→128.** Reusing the 64-bit datapath for 32-bit operands costs 4× the energy and area of a dedicated 32-bit datapath. The document claims this reuse is "acceptable" without comparing against a dedicated W-datapath. The W-extension is a real workload consideration in many RV64 deployments.
+
+12. **128-core scalability claim about voltage/frequency is unsupported.** "Moderately pipelined MUL/DIV is more resilient to voltage droop" is asserted without source or reasoning. Voltage-droop resilience depends on the depth of pipelining, clock-tree design, and decoupling — not directly on whether the MUL/DIV is "moderately pipelined." This is a hand-wave.
+
+13. **F/D extension "out of scope" but Recommendation 2 implies otherwise.** The document lists F/D as an open question, yet the recommended design's relevance to F extension (FP reciprocal, FP-to-int conversions, Newton–Raphson for FP divide) is a major design driver that is dismissed as out of scope. Given XH-1 is described as balancing general-purpose and HPC-adjacent workloads, excluding F from the MUL/DIV analysis is a significant gap.
+
+14. **Sources section is weak on specificity.** Rocket, BOOM, Ariane are cited by file name but without commit hashes, and the document admits "specific commit, measured numbers, and PPA data: INSUFFICIENT EVIDENCE." Hennessy & Patterson and Parhami are cited without chapter or edition. Per the document's own labeling standard, these citations are not actionable.
+
+15. **MULH/MULHSU "Booth complicates verification" claim is overstated.** Radix-4 Booth of a signed operand is the standard recoding; signed/unsigned operand handling at the input is the issue, not Booth itself. The verification complication is the sign-extension/correction logic, which is small. The document overstates this.
+
+16. **"Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0" is correct but the document does not note the verification implication** — that this requires detecting the overflow case explicitly, separate from a generic restore step. Mentioning the rule without mentioning the hardware detector is a gap.
+
+17. **The "2-cycle MUL matches typical issue-to-use distances" claim is unsupported.** No pipeline depth or issue-to-use distance is established; `pipeline.md` is TBD. This is a quantitative claim with no anchor.
+
+18. **A5 "Shared / Clustered MUL/DIV Unit" is listed under "Existing Approaches" but is then analyzed as B7, a new design point.** The boundary between existing and proposed is blurred; the document acknowledges this was not analyzed in the prior revision.
+
+19. **B4-pipe area accounting in the comparison table is wrong.** Row says "adds ~6–8× to A2 total (unval.)" but A2's area is 3–4× A1, so 6–8× relative to A2 would be 18–32× A1, which is absurd and contradicts the B1+B4-pipe narrative. The text earlier says ~3–4× of B1's divider, added to B1 → 6–8× of A1 total, but the table column header says "to A2 total" and the value is not consistent with either reading. This is a clear internal inconsistency.
+
+20. **The "previous revision contained an error" pattern is repeated many times** (32-cycle divider, 11 partial products, "~50×" array divider, MULH/Montgomery claim, DIVU-by-zero description). The document is a self-correction of a prior version, which is fine, but the volume of corrections suggests the document is still in flux and not ready for a recommendation-grade verdict.
+
+21. **The "primary recommendation is conditional on synthesis data that does not yet exist" disclaimer is repeated in the Status, Proposal, Recommendation, and Confidence sections.** This is honest but means the document's primary deliverable is, by its own admission, not actionable today. The document should be marked as "research survey" rather than issuing a conditional recommendation.
+
+REQUIRED FIXES:
+
+- Correct the Booth partial-product counts (radix-4: 32 rows, not 33; radix-8: 22 rows, not 23) and propagate the correction through B1, B2, the Proposal, and the Recommendation. The sign-correction is a bit added to existing rows, not a separate full-width row.
+- Reconcile the B4-pipe / A2 / B1 area math in the comparison table; either restate the units of the "adds 3–4×" and "6–8×" figures consistently, or drop the relative numbers and label them all "unvalidated, pending synthesis."
+- Quantify the A1 baseline in absolute terms (gate count, NAND2 equivalent, or area in a named process) or remove the relative-area columns and replace with qualitative ranking.
+- Provide an order-of-magnitude estimate for B6 (combinational non-restoring array divider) area, even as a wide range, so the comparison table is non-vacuous for that row.
+- Re-derive B5 (Newton–Raphson) latency and iteration count with the bit-accuracy argument made explicit, including the seed width and the number of correct bits per iteration.
+- Resolve the W-variant question: either justify reusing the 64-bit datapath with a quantitative energy/area comparison, or note that a dedicated 32-bit datapath is an alternative.
+- Address F/D extension implications in the MUL/DIV analysis, or explicitly state the design is integer-only with no plan to add F/D and accept the consequences.
+- Strengthen the Sources section with specific citations (edition, chapter, commit hash) or remove the citation claims entirely.
+- Remove the unsupported voltage-droop-resilience claim or replace it with a sourced statement.
+- Distinguish explicitly, for each numbered claim in the Proposal and Recommendation, whether it is a FACT (spec-defined), an ASSUMPTION (engineering judgment with stated basis), a PROPOSAL (design choice), a RECOMMENDATION (action with trigger), or an OPEN QUESTION. Several items currently mix these categories.
+- Verify the RISC-V spec citation (Document Version 20191213) actually contains the exact ÷0 and INT64_MIN/−1 behavior as stated, and that the document is not relying on memory of the spec text.
+- State the per-core area budget assumption (or lack thereof) explicitly in the Recommendation, not only in the Status section.
+
+CONFIDENCE: HIGH

research/.xh1/runs/20260825T181609Z/research_03-core-design_mul-div-unit.md.round1.md

@@ -0,0 +1,281 @@
+# Multiply-Divide Unit
+
+## Status
+
+Stub. This document is an early-stage engineering research artifact. Many quantitative claims below are estimates pending empirical validation against synthesized netlists, layout, and workload characterization.
+
+## Abstract
+
+The multiply-divide (MUL/DIV) unit implements the integer multiplication and division instructions defined in the RV64IM (and optionally M-extension) instruction set. 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/thermal envelope. This document surveys existing MUL/DIV architectures (iterative, array, Radix-4/8 Booth, array-of-serial, and Sutherland/Robertson division), compares their trade-offs, and proposes a design direction suitable for a 128-core RISC-V processor where replication, area, and energy are first-class constraints.
+
+## Research Question
+
+What MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:
+
+- Per-core area must be small enough to replicate 128 instances on one die.
+- The pipeline stage budget for the EX stage is finite (TBD by `pipeline.md`).
+- 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.
+- The unit should be IEEE 754-friendly if floating-point support is integrated later, but for this document the scope is integer MUL/DIV.
+- Verification must scale to 128 cores; deterministic, fully combinational MUL and bounded-iteration DIV designs simplify verification.
+
+## Background
+
+### Required Instructions (RV64M)
+
+The Rv64M extension defines:
+- MUL, MULH, MULHSU, MULHU (64x64 -> 128-bit multiply).
+- DIV, DIVU, REM, REMU (64-bit signed/unsigned divide and remainder).
+- MULW, DIVW, DIVUW, REMW, REMUW (32-bit signed/unsigned, sign-extended to 64 bits).
+
+### Latency Requirements (typical)
+
+OpenRISC, Rocket, BOOM, and commercial cores report the following typical latencies (estimates, to be validated against target frequency):
+
+| Operation        | Typical latency (cycles) | Throughput      |
+|------------------|--------------------------|-----------------|
+| MUL (lower 64)   | 3–5                      | 1/cycle or pipelined |
+| MULH (upper 64)  | 4–6                      | 1/cycle or pipelined |
+| DIV/REM (64-bit) | 20–40                    | 1 per 20–40 cycles |
+| MULW/DIVW        | similar to 64-bit        | similar         |
+
+These numbers vary widely with frequency, area, and architecture; the repository does not yet contain measurements.
+
+### Division Algorithms (Background)
+
+- Restoring division: simple, but slow (one bit per cycle).
+- Non-restoring division: similar latency, less area than array.
+- SRT division (e.g., radix-2, radix-4): higher radix = fewer iterations, more complex quotient-digit selection logic.
+- Newton-Raphson reciprocal multiplication: pre-computes reciprocal via iteration, then multiplies. Fastest for many workloads, but variable latency, complex control.
+- Goldschmidt division: similar trade-off to Newton-Raphson.
+
+### Multiplication Algorithms (Background)
+
+- Shift-and-add multiplier: simple, slow.
+- Array (Braun/baugh-wooley) multiplier: combinational, O(n²) area, deterministic latency.
+- Wallace/Dadda tree multiplier: O(n log n) partial-product reduction, faster, more irregular layout.
+- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count by 2× or 3×.
+- Compressor-tree (3:2, 4:2) approaches.
+
+## Existing Approaches
+
+### A1. Iterative Shift-and-Add Multiplier + Restoring Divider
+
+- Implementation: one 64-bit adder, 130-bit accumulator, shift register.
+- Multiplier: 64 cycles, 1 bit/cycle.
+- Divider: 64 cycles (restoring) or ~64 cycles (non-restoring).
+- Area: very small.
+- PROPOSAL-class baseline for comparison only.
+
+### A2. Booth-Radix-4 Multiplier + Iterative Divider
+
+- Multiplier: 32 partial products, Wallace/Dadda reduction, 2-stage pipelined, 2-cycle latency, 1/cycle throughput.
+- Divider: 64-cycle non-restoring.
+- Area: small-to-medium.
+- Used in many embedded RV cores (e.g., SiFive E-class predecessors).
+
+### A3. Pipelined Radix-4/8 Booth + Radix-4 SRT Divider
+
+- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.
+- Divider: radix-4 SRT, ~16 cycles, ~1 per 16 cycles throughput.
+- Area: medium.
+- Used in superscalar cores (e.g., BOOM-family, Ariane-derived).
+
+### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider
+
+- Multiplier: 64×64 → 128, single cycle, large area.
+- Divider: 4–8 cycles, 1 per 4–8 cycles throughput.
+- Area: large.
+- Used in high-frequency superscalar out-of-order cores.
+
+### A5. Shared/Vector MUL-DIV Unit (per-cluster)
+
+- A single MUL/DIV unit is shared across N cores, accessed via a reservation station.
+- Saves replicated area; increases latency and contention.
+- Used in some throughput-oriented many-core designs.
+
+## Alternative Designs
+
+### B1. 2-Stage Pipelined Radix-4 Booth Multiplier
+
+- 17 partial products reduced via 4:2 compressor tree.
+- Two pipeline stages: partial-product reduction, then final carry-propagate add.
+- Latency 2 cycles, throughput 1/cycle.
+- Divider: 32-cycle non-restoring (radix-2 non-restoring with early-exit optimization).
+
+### B2. 3-Stage Pipelined Radix-8 Booth Multiplier
+
+- 11 partial products.
+- Latency 3 cycles, throughput 1/cycle.
+- Smaller critical path than B1, higher area.
+
+### B3. Iterative Multiplier with Multi-Cycle Variable Latency
+
+- Single 64×64 multiplier reused across MUL/MULH/MULHU by selecting the relevant output bits.
+- Latency 4–5 cycles, 1/cycle throughput.
+- Smaller area than B1 but longer latency.
+
+### B4. Radix-4 SRT Divider with Pipelined Issue
+
+- 16-cycle latency, fully pipelined so back-to-back divides (with different operands) are allowed.
+- Larger area, more verification complexity.
+
+### B5. Newton-Raphson Divider with Hardware Reciprocal Iteration
+
+- ~4–6 cycles for 32-bit reciprocal, then 1 multiply.
+- Lowest divide latency, but variable and dependent on operand class.
+- Complex verification (convergence proofs required).
+
+### B6. Two's-Complement Array Divider (Combinational)
+
+- Single-cycle 64-bit divide.
+- Extremely large area (~64× of a 64-bit multiplier).
+- Likely unacceptable for 128-core replication.
+
+## Comparison
+
+| Design | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area | Verification Complexity |
+|--------|-------------|----------------|-------------|----------------|---------------|-------------------------|
+| A1. Shift-add + restoring | 64 | 1/64 | 64 | 1/64 | 1× | Low |
+| A2. Booth-r4 + NR div    | 2  | 1/1   | 32 | 1/32 | ~3–4× | Low–Medium |
+| A3. Pipelined r4/r8 + SRT-4 | 2–3 | 1/1 | 16 | 1/16 | ~5–7× | Medium |
+| A4. Combinational + SRT-16  | 1  | 1/1 | 4–8 | 1/8  | ~10–15× | High |
+| B1. 2-stage r4 + NR-32    | 2  | 1/1   | 32 | 1/32 | ~3–5× | Low–Medium |
+| B4. Pipelined SRT-4        | n/a | n/a | 16 | 1/16 | adds ~3–4× | Medium |
+| B5. Newton-Raphson        | 1 (MUL) | 1/1 | 4–6 | 1/4–6 | ~6–8× | High |
+| B6. Combinational array   | 1  | 1/1   | 1  | 1/1  | ~50× | Medium |
+
+PROPOSAL: A representative B1+B4 hybrid is a 2-stage pipelined Radix-4 Booth multiplier paired with a pipelined Radix-4 SRT divider. This is a reasonable starting point pending synthesis-driven PPA feedback.
+
+## Advantages
+
+- A 2-stage pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest area, suitable for a replicated 128-core design.
+- A pipelined Radix-4 SRT divider (or a non-restoring iterative divider with early-exit) meets the latency needs of most workloads without dominating area.
+- Deterministic latencies (vs. Newton-Raphson) simplify pipeline scheduling, forwarding, and verification.
+- Radix-4 Booth and SRT-4 are well-understood and have reference implementations in academic and open-source RISC-V cores.
+
+## Disadvantages
+
+- 16-cycle SRT-4 divide is still slow for workloads dominated by large-integer arithmetic (RSA, big-integer math).
+- Combinational or Newton-Raphson dividers reduce latency significantly but at unacceptable area/verification cost for 128-core replication.
+- A non-restoring iterative divider has the lowest area but penalizes every divide by ~32 cycles, which can be felt in hash-table probing, parser/lexer dispatch, and some interpreters.
+- Booth encoding complicates verification of signed/unsigned correctness (MULH vs. MULHSU vs. MULHU).
+
+## XH-1 Considerations
+
+- ASSUMPTION: XH-1 is a 128-core design with a relatively 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.
+- ASSUMPTION: The design targets a balance of general-purpose and HPC-adjacent workloads; therefore a moderately fast (but not the fastest) divider is acceptable.
+- PROPOSAL: Adopt a 2-stage pipelined Radix-4 Booth multiplier (MUL, MULH, MULHSU, MULHU, MULW) and a 32-cycle non-restoring iterative divider with early-exit optimization.
+- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.
+- The W-variants (MULW, DIVW, etc.) reuse the lower 32 bits of the 64-bit datapath with sign-extension at the output.
+
+### Instruction Coverage
+
+- MUL/MULH/MULHSU/MULHU: supported.
+- DIV/DIVU/REM/REMU: supported, with corner cases (÷0, INT_MIN/-1, signed overflow per spec) handled explicitly.
+- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.
+
+### Edge Cases
+
+- Division by zero: returns -1 for DIV, x for DIVU, per RISC-V spec; the unit must produce the architecturally specified result without exception.
+- Signed overflow (INT64_MIN / -1): returns INT64_MIN for DIV, 0 for REM.
+- These cases are common sources of bugs and require explicit test coverage.
+
+## 128-Core Scalability
+
+- Area: replicating 128 copies of even a moderately sized MUL/DIV unit is a significant die-level cost. The chosen design (B1+B4 baseline) is estimated at <1–2% of a typical small RV core area, but 128× replication is non-trivial.
+- Floorplanning: a regular MUL/DIV layout that mirrors across cores is preferred to avoid routing asymmetry that would break clock distribution.
+- Voltage/Frequency: a deeply pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.
+- Contention: there is no inter-core contention for the MUL/DIV unit (per-core replication); the only contention is intra-core (two dependent divides in flight).
+- Test/DFT: 128 instances of the MUL/DIV unit must be tested; a scan-friendly, fully synchronous design with no asynchronous reset paths inside the iterative divider is preferable.
+
+## Performance Considerations
+
+- For general-purpose code, MUL/DIV is rarely the bottleneck; the chosen 2-cycle MUL latency matches typical issue-to-use distances.
+- For cryptography (AES SubBytes via GF(2⁸), polynomial multiplies, RSA), MUL throughput is the key metric — 1/cycle is the floor for acceptable performance.
+- For hash tables and interpreters, DIV latency matters more than throughput; a 32-cycle divider is acceptable but not ideal.
+- For 64-bit polynomial multiplication, MULH throughput is the key metric.
+- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.
+
+## Area Considerations
+
+- ASSUMPTION: A 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree and 2-stage pipelined final adder occupies roughly 0.05–0.10 mm² in a typical 7nm process.
+- ASSUMPTION: A 32-cycle non-restoring iterative divider occupies roughly 0.02–0.05 mm².
+- PROPOSAL: Total MUL/DIV area target: <0.15 mm² per core. 128× replication: ~20 mm². INSUFFICIENT EVIDENCE to refine this without a technology file.
+- The 4:2 compressor tree is more area-efficient than a Wallace tree for radix-4.
+- Sign-extension and zero-extension muxes for MULW are negligible area.
+
+## Power and Energy Considerations
+
+- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.
+- The iterative divider has lower average power than a fully combinational divider, but its long residency increases leakage energy per operation.
+- Power gating: at 128 cores, a per-core power-gate for the MUL/DIV unit is worth considering if idle periods dominate.
+- Energy per multiply: dominated by the compressor tree; energy scales roughly with the number of partial products.
+- Energy per divide: dominated by the 32-cycle residency; techniques to short-circuit trailing zeros in the dividend (early-exit) can reduce energy in common cases.
+
+## Implementation Considerations
+
+- Use synchronous, single-clock-domain design inside the unit.
+- Avoid asynchronous resets inside the iterative divider; use synchronous reset only at the start of an operation.
+- Multiplier carry-propagate adder should be a Kogge-Stone or Han-Carlson adder for speed, with a Brent-Kung fallback if area is tight.
+- Divider quotient/remainder registers are 64 bits each, with an extra bit for the iterative sign.
+- Microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.
+- Output muxing for MUL/MULH/MULHSU/MULHU/MULW is a small mux tree, not a separate datapath.
+- Booth encoding produces 33 partial products for radix-4 of a 64-bit operand; reduction to 2 operands via compressor tree.
+
+## Verification Considerations
+
+- Formal verification of the multiplier compressor tree + final adder is feasible with bounded model checkers and is recommended.
+- Directed tests for division edge cases (÷0, INT_MIN/-1, dividend=d divisor=1, dividend=0 divisor=x, all-ones, alternating bits).
+- Randomized differential testing against a software reference (e.g., a GCC-compiled test harness running on Spike or QEMU) is recommended.
+- Coverage of all 4 MUL variants and 4 MULH variants plus the W-variants.
+- 128-core DFT: scan stitching should be reviewed to ensure no long scan chains between the iterative divider and surrounding logic cause hold-time issues.
+- Reference models: a Python or C++ golden model for the entire RV64M ISA is recommended and reusable across all 128 cores.
+- UVM or cocotb-based testbenches: the unit is small enough that a single high-quality testbench can be reused.
+
+## Software Implications
+
+- Compilers will emit MUL freely; no software changes are required.
+- 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 languages with software-emulated 128-bit integers (e.g., __int128 in C/C++), the compiler will emit MULH/MULHU sequences; MULH latency and throughput become important.
+- Crypto libraries (libsodium, OpenSSL, mbedTLS) often use Karatsuba or Montgomery multiplication, which benefit from 1/cycle MULH throughput.
+- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a slow divider increases interpreter overhead.
+
+## Recommendation
+
+PROPOSAL: Adopt a 2-stage pipelined Radix-4 Booth multiplier paired with a 32-cycle non-restoring iterative divider (with early-exit optimization for the dividend). Provide pipelined throughput of 1 MUL per cycle and 1 DIV per 32 cycles.
+
+Rationale:
+- Best balance of area, energy, and performance for 128-core replication.
+- Deterministic, fully synchronous design simplifies verification and DFT.
+- 1/cycle MUL throughput meets crypto and HPC-adjacent needs.
+- 32-cycle DIV latency is acceptable for general-purpose workloads; can be revisited if profiling shows a hotspot.
+
+RECOMMENDATION (with caveats): If early workload analysis (TBD) shows that divide latency is a bottleneck, consider upgrading the divider to a pipelined Radix-4 SRT (16 cycles) at ~3–4× the divider area. Do not adopt a Newton-Raphson divider unless profiling evidence strongly supports it, due to verification complexity.
+
+RECOMMENDATION: Do not adopt a fully combinational array divider or fully combinational multiplier for the replicated 128-core design. The area cost is not justified by the latency benefit.
+
+## Confidence
+
+- Direction of recommendation: MEDIUM. The general design class is well-established; specific numbers (area, latency, energy) require synthesis runs against a target technology library.
+- Quantitative area/power numbers: LOW. No measurements exist in the repository; all such numbers in this document are estimates.
+- Verification strategy: HIGH. The recommended approach (formal on the multiplier, directed + randomized for the divider) is standard practice.
+- Edge-case correctness: HIGH. The RISC-V spec is explicit and well-tested across many cores.
+
+## Open Questions
+
+- What is the EX-stage latency budget? (Depends on `pipeline.md`.)
+- What is the target frequency and process node? Determines whether 1-cycle or 2-cycle MUL is feasible.
+- Is the design in-order or out-of-order? Out-of-order execution can hide divide latency; in-order cannot.
+- Will the MUL/DIV unit share an issue port with the ALU, or have a dedicated issue port? (Likely shared, but TBD.)
+- Is there a future F/D extension? If so, the integer MUL/DIV unit may also need to handle FP-to-int conversions or FP reciprocal iterations.
+- What is the workload mix expected? Scientific (HPC) vs. general-purpose vs. embedded?
+- Should the MUL/DIV unit be power-gated when idle? At 128 cores, idle probability may be high.
+- Should the divider support a "fast-path" for division by a small constant (e.g., compiler-inserted reciprocal multiply hint)?
+
+## Sources
+
+- The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA — defines M-extension semantics. (Documented in standard ISA references; no specific URL is cited here per the no-fabrication rule.)
+- Hennessy and Patterson, "Computer Architecture: A Quantitative Approach" — covers MUL/DIV trade-offs.
+- Parhami, "Computer Arithmetic: Algorithms and Hardware Designs" — covers multiplier and divider algorithms in depth.
+- Open-source RISC-V cores (e.g., Rocket, BOOM, Ariane) for design-class references. Specific measurements, layouts, and PPA numbers: INSUFFICIENT EVIDENCE in the current XH-1 repository.
+- No quantitative claims in this document are derived from measurements; all are estimates unless explicitly labeled otherwise.

research/.xh1/runs/20260825T181609Z/research_03-core-design_mul-div-unit.md.round2.md

@@ -0,0 +1,324 @@
+# Multiply-Divide Unit
+
+## Status
+
+Engineering research document, pre-synthesis. All quantitative values below are explicitly labeled as unvalidated estimates or marked INSUFFICIENT EVIDENCE where no source can be cited. No measurement against a target technology library, layout, or workload has been performed for XH-1.
+
+## Abstract
+
+The multiply-divide (MUL/DIV) unit implements the integer multiplication and division instructions defined by the M extension of the RISC-V ISA (combined with the base I extension; usually written RV64I + M, also expressed as RV64IM when the integer base is implicit). 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, and Sutherland/Robertson / non-restoring / SRT division), compares their trade-offs across per-core and shared organizations, and proposes a design direction suitable for a 128-core RISC-V processor where replication, area, and energy are first-class constraints.
+
+## Research Question
+
+What MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:
+
+- 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 pipeline stage budget for the EX stage is finite (TBD by `pipeline.md`).
+- 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.
+- 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.
+- Verification must scale to 128 cores; deterministic, fully combinational MUL and bounded-iteration DIV designs simplify verification.
+
+## Background
+
+### Required Instructions (RV64I + M)
+
+The M extension defines the following on RV64:
+
+- MUL, MULH, MULHSU, MULHU: 64×64 → 128-bit multiply, returning the lower 64 bits (MUL) or the upper 64 bits (MULH and its signed/unsigned variants).
+- DIV, DIVU, REM, REMU: 64-bit signed/unsigned divide and remainder.
+- MULW, DIVW, REMW: 32×32 → 32-bit signed multiply and signed divide, sign-extended to 64 bits.
+- DIVUW, REMUW: 32×32 → 32-bit unsigned divide, sign-extended to 64 bits.
+
+The header of the previous revision referred to "RV64IM (and optionally M-extension)," which is incoherent because M is part of RV64IM by definition. In this document the scope is the M extension on RV64I.
+
+### Latency and Throughput Ranges (Background Only)
+
+Published RISC-V cores report the following approximate ranges. These are background reference values from named open cores; they are not measurements of XH-1.
+
+| Operation        | Reported latency range (cycles) | Reported throughput      | Source basis                          |
+|------------------|---------------------------------|--------------------------|---------------------------------------|
+| MUL (lower 64)   | 1–5                             | 1/cycle (pipelined)      | Rocket, BOOM Small, Ariane (claimed)  |
+| MULH (upper 64)  | 2–6                             | 1/cycle (pipelined)      | Same                                  |
+| DIV/REM (64-bit) | 8–40                            | 1 per N cycles           | Same                                  |
+| MULW/DIVW family | similar to 64-bit variants      | similar                  | Same                                  |
+
+The 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.
+
+### Division Algorithms (Background)
+
+- Restoring division: simple, one bit per iteration, simple control, slow.
+- Non-restoring division: similar iteration count, slightly smaller area than the array form, well-suited to iterative implementation.
+- SRT division (radix-2, radix-4, radix-16): 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.
+- Newton–Raphson reciprocal multiplication: pre-computes an approximation of the reciprocal via iteration, then multiplies. Low latency for many operand classes, but variable latency and convergence-dependent.
+- Goldschmidt division: similar trade-off to Newton–Raphson.
+
+### Multiplication Algorithms (Background)
+
+- Shift-and-add multiplier: simple, slow, one bit per cycle.
+- Array (Braun / Baugh–Wooley) multiplier: combinational, O(n²) partial products and full-adders, deterministic single-cycle latency, large area.
+- Wallace / Dadda tree multiplier: O(n log n) partial-product reduction using 3:2 and 4:2 compressors; faster critical path, less regular layout.
+- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count by roughly 2× (radix-4) or 3× (radix-8) compared to a naive array.
+- Compressor-tree implementations (3:2 counters, 4:2 compressors, Ling / Han–Carlson adders) trade area for shorter critical paths.
+
+## Existing Approaches (Per-Core, Unless Noted)
+
+The 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.
+
+### A1. Iterative Shift-and-Add Multiplier + Restoring Divider
+
+- Multiplier: 64 cycles, 1 bit/cycle.
+- Divider: 64 cycles (restoring) or ~64 cycles (non-restoring).
+- Area: very small. Used as the 1× baseline in the comparison table.
+
+### A2. Booth-Radix-4 Multiplier + Iterative Non-Restoring Divider
+
+- Multiplier: 32 radix-4 digits → 33 partial products (including the sign-extension row) reduced through a Wallace/Dadda or 4:2 tree. Two pipeline stages; 2-cycle latency, 1/cycle throughput.
+- Divider: ~64-cycle non-restoring, 1/64 throughput.
+- Area: estimated ~3–4× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A3. Pipelined Radix-4/8 Booth Multiplier + Radix-4 SRT Divider
+
+- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.
+- Divider: radix-4 SRT, ~16 cycle latency. If pipelined internally, throughput approaches 1/cycle on independent operands; if not pipelined, throughput is 1/16. The SRT-4 in this class is typically not deeply pipelined in published small RV cores.
+- Area: estimated ~5–7× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider
+
+- Multiplier: 64×64 → 128 in a single cycle, large area.
+- Divider: 4–8 cycle latency via radix-16 selection.
+- Area: estimated ~10–15× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A5. Shared / Clustered MUL/DIV Unit
+
+- A single MUL/DIV unit serves N cores, accessed via a reservation station or blocking interface.
+- Saves replicated area; increases latency under contention.
+- A natural fit for 128-core designs only if inter-core divide/mul traffic is low or bursty.
+
+This alternative was not analyzed in depth in the previous revision; it is included here as a candidate organization.
+
+## Alternative Designs (Per-Core, Unless Noted)
+
+### B1. 2-Stage Pipelined Radix-4 Booth Multiplier
+
+- Radix-4 Booth encoding of two 64-bit operands produces 33 partial products (32 signed digit products plus one sign-correction row). The previous revision's "17 partial products" figure was incorrect and is corrected here.
+- Partial-product reduction through a 4:2 compressor tree, followed by a final carry-propagate add split across two pipeline stages.
+- Latency 2 cycles, throughput 1/cycle.
+- Divider: 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency; "early-exit" optimizations (e.g., leading-zero detection on the divisor, trailing-zero detection on the dividend to shift out low bits before the loop) reduce typical-case latency but the worst case remains 32 cycles. The previous revision named the optimization without describing it; the description is provided here.
+- Area: estimated ~3–5× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### B2. 3-Stage Pipelined Radix-8 Booth Multiplier
+
+- 11 partial products for a 64-bit operand (one per 3-bit window plus sign correction).
+- Latency 3 cycles, throughput 1/cycle.
+- Smaller critical path than B1 at the cost of higher area and more complex Booth-3 encoding.
+
+### B3. Iterative Multiplier with Multi-Cycle Variable Latency
+
+- A single 64×64 multiplier reused across MUL/MULH/MULHSU/MULHU by selecting output bits.
+- Latency 4–5 cycles, 1/cycle throughput.
+- Smaller area than B1; longer issue-to-use distance complicates scheduling.
+
+### B4. Pipelined Radix-4 SRT Divider
+
+- 16-cycle latency when issued back-to-back with different operands. The previous revision was internally inconsistent (text said fully pipelined, table said 1/16 throughput). For this document, B4 is treated as a 16-cycle-latency, 1/16-throughput non-pipelined unit; a fully pipelined SRT-4 with 1/cycle throughput would add ~3–4× the divider area and is a separate design point (B4-pipe).
+- Larger area than B1's divider, more verification complexity (quotient-digit selection must be proven correct for all residuals).
+
+### B5. Newton–Raphson Divider with Hardware Reciprocal Iteration
+
+- ~4–6 cycles for 32-bit reciprocal convergence on typical operands, then one multiply.
+- 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).
+- Complex verification: requires convergence proof or guarded iteration count plus a fallback path.
+
+### B6. Two's-Complement Array Divider (Combinational)
+
+- Single-cycle 64-bit divide.
+- 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; the document does not retain it.
+- Likely unacceptable for 128-core replication.
+
+### B7. Cluster-Shared MUL/DIV Unit (8 cores per unit, 16 units total)
+
+- A single radix-4 Booth + radix-4 SRT divider (B1 + B4) shared by 8 cores via a small reservation station.
+- 16 instances on the die instead of 128.
+- Per-cluster area budget can absorb a faster divider (e.g., B4-pipe or B5) than per-core replication allows.
+- Latency and contention penalty under simultaneous divide requests.
+
+## Comparison
+
+The 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.
+
+| Design                                          | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area (per unit) | Verification Complexity |
+|-------------------------------------------------|-------------|----------------|-------------|----------------|--------------------------|-------------------------|
+| A1. Shift-add + restoring                       | 64          | 1/64           | 64          | 1/64           | 1×                       | Low                     |
+| A2. Booth-r4 + NR div                           | 2           | 1/1            | ~64         | 1/64           | ~3–4× (unvalidated)      | Low–Medium              |
+| A3. Pipelined r4/r8 + SRT-4 (non-pipe)          | 2–3         | 1/1            | 16          | 1/16           | ~5–7× (unvalidated)      | Medium                  |
+| A4. Combinational + SRT-16                      | 1           | 1/1            | 4–8         | 1/4–1/8        | ~10–15× (unvalidated)    | High                    |
+| B1. 2-stage r4 + NR-32 (with early-exit)        | 2           | 1/1            | 32 worst    | 1/32           | ~3–5× (unvalidated)      | Low–Medium              |
+| B2. 3-stage r8 + NR-32                          | 3           | 1/1            | 32 worst    | 1/32           | ~4–6× (unvalidated)      | Medium                  |
+| B4. SRT-4 (non-pipelined)                       | n/a         | n/a            | 16          | 1/16           | adds ~3–4× to A2 (unvalidated) | Medium            |
+| B4-pipe. SRT-4 (pipelined, 1/cycle)             | n/a         | n/a            | 16          | 1/1            | adds ~6–8× to A2 (unvalidated) | Medium–High      |
+| B5. Newton–Raphson                              | 1           | 1/1            | 4–6         | 1/4–1/6        | ~6–8× (unvalidated)      | High                    |
+| B6. Combinational array divider                 | 1           | 1/1            | 1           | 1/1            | very large (unvalidated) | Medium                  |
+| B7. Cluster-shared (per 8 cores) B1 + B4-pipe  | 2           | 1/1            | 16          | 1/1 (when free) | per-cluster ~8–12× A1; ×16 instances (unvalidated) | Medium–High    |
+
+The previous revision compared only per-core designs. The revised comparison adds B7 and notes the cluster organization explicitly, addressing the prior omission.
+
+## Proposal (Resolved)
+
+PROPOSAL: 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 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency and an early-exit optimization for typical operands.
+
+This resolves the prior contradiction between the abstract PROPOSAL (which named a pipelined SRT-4) and the final Recommendation (which named the 32-cycle non-restoring divider). The remaining sections are aligned to B1 + non-restoring 32-cycle divider.
+
+Conditional variant: If early workload analysis (TBD) shows that 32-cycle 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 (unvalidated). This is a design knob, not a parallel recommendation.
+
+Open variant: B7 (cluster-shared organization) is retained as a fallback if per-core area constraints prove tighter than estimated. The decision requires quantitative synthesis data that is not yet available.
+
+## Advantages
+
+- 2-cycle pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest per-core area, suitable for replicated 128-core operation.
+- 32-cycle non-restoring iterative divider (with early-exit for typical operands) meets the latency needs of general-purpose code without dominating area.
+- Deterministic latencies simplify pipeline scheduling, forwarding, and verification compared to Newton–Raphson.
+- Radix-4 Booth and radix-2 non-restoring division are well-understood and have reference implementations in Rocket, BOOM, Ariane, and other open-source RISC-V cores (specific measurements: INSUFFICIENT EVIDENCE in the XH-1 repository).
+
+## Disadvantages
+
+- 32-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.
+- Newton–Raphson dividers reduce typical latency for many operand classes but at unacceptable per-core verification cost for 128-core replication in the current design envelope.
+- A non-restoring iterative divider has the lowest per-core area but penalizes every divide by up to 32 cycles, which can be felt in hash-table probing, parser/lexer dispatch, and some interpreter dispatch loops.
+- Booth encoding complicates verification of signed/unsigned correctness for MULH / MULHSU / MULHU; the previous revision flagged this; it is reaffirmed here.
+
+## XH-1 Considerations
+
+- 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.
+- 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.
+- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.
+- 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.
+
+### Instruction Coverage
+
+- MUL/MULH/MULHSU/MULHU: supported.
+- DIV/DIVU/REM/REMU: supported, with RISC-V-spec corner cases handled explicitly.
+- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.
+
+### Edge Cases (RISC-V Spec)
+
+The following are the architecturally specified results. The previous revision contained an error in the DIVU-by-zero description; the corrected behavior is:
+
+- DIV by zero: quotient = −1 (all bits set in the lower XLEN), remainder = dividend (x).
+- DIVU by zero: quotient = 2^XLEN − 1 (all ones), remainder = dividend (x).
+- REM by zero: remainder = dividend (x); quotient = −1.
+- REMU by zero: remainder = dividend (x); quotient = 2^XLEN − 1.
+- Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0.
+- 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.
+
+The unit must produce these results without raising an exception.
+
+## 128-Core Scalability
+
+- 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 32-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. The previous revision's "<1–2% of a typical small RV core area" is removed because it lacked a baseline.
+- 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.
+- Voltage / frequency: a moderately pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.
+- 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.
+- 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.
+
+## Performance Considerations
+
+- For general-purpose code, MUL/DIV is rarely the bottleneck; a 2-cycle MUL latency matches typical issue-to-use distances.
+- For cryptography, the relevant metric is MUL (lower 64) throughput, since Karatsuba and Montgomery multiplication depend on lower-half multiplies. The previous revision's claim that MULH throughput is the key for Karatsuba / Montgomery is not generally correct and is corrected here. MULH is the key metric for software-emulated 128-bit integer multiplication (`__int128`), not for Karatsuba / Montgomery in the typical formulation.
+- For hash tables and interpreters, DIV latency matters more than throughput; a 32-cycle divider is acceptable but not ideal.
+- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.
+
+## Area Considerations
+
+- ASSUMPTION (unvalidated): A 64×64 → 128-bit Radix-4 Booth multiplier with a 4:2 compressor tree and 2-stage pipelined final adder occupies roughly 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.
+- ASSUMPTION (unvalidated): A 32-cycle non-restoring iterative divider occupies roughly 0.01–0.05 mm² in the same envelope.
+- 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 4:2 compressor tree is a common implementation choice for radix-4 reduction. The previous revision's claim that it is "more area-efficient than a Wallace tree" is removed; Wallace and Dadda trees implemented with 4:2 compressors are not generally distinguishable in area for radix-4 reduction, and the choice is largely a layout / regularity preference. INSUFFICIENT EVIDENCE to prefer one over the other without synthesis.
+- Sign-extension and zero-extension muxes for MULW are negligible area.
+
+## Power and Energy Considerations
+
+- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.
+- The iterative divider has lower average switching power than a fully combinational divider, but its long residency increases leakage energy per operation.
+- 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.
+- Energy per multiply is dominated by the compressor tree. The relationship "energy scales roughly with the number of partial products" is a rule of thumb; INSUFFICIENT EVIDENCE for a specific quantitative claim.
+- Energy per divide is dominated by the 32-cycle residency; early-exit on the dividend (trailing-zero detection) reduces energy for typical operands but the worst-case energy remains.
+
+## Implementation Considerations
+
+- Synchronous, single-clock-domain design inside the unit.
+- No asynchronous resets inside the iterative divider; synchronous reset only at the start of an operation.
+- 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.
+- Divider quotient and remainder registers are 64 bits each, with an extra bit for the iterative sign.
+- The microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.
+- Output muxing for MUL / MULH / MULHSU / MULHU / MULW is a small mux tree, not a separate datapath.
+- Booth encoding produces 33 partial products for radix-4 of a 64-bit operand (32 digit products plus one sign-correction row). The "17 partial products" figure from the previous revision is incorrect and is corrected here.
+
+## Verification Considerations
+
+- Formal verification of the multiplier compressor tree and final adder is feasible with bounded model checkers and is recommended.
+- 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.
+- Explicit coverage of the REM sign-of-dividend rule.
+- Coverage of all 4 MUL variants and the W-variants.
+- 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.
+- 128-core DFT: see the dedicated section below.
+
+### DFT Strategy (128 Replicated Units)
+
+- Single-clock-domain, synchronous-reset-only design is required for scan insertion.
+- 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.
+- Scan compression: per-core compression reduces the number of top-level scan pins; the compression architecture is TBD by the DFT plan.
+- 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.
+- 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.
+
+## Software Implications
+
+- Compilers emit MUL freely; no software changes are required.
+- 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.
+- 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 case where MULH is the key metric, not the crypto case.
+- Crypto libraries (libsodium, OpenSSL, mbedTLS) typically use Karatsuba or Montgomery multiplication, which depend on lower-half MUL throughput, not MULH throughput. The previous revision's claim that MULH is the key for Karatsuba / Montgomery is corrected here.
+- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a 32-cycle divider increases interpreter dispatch latency for that pattern.
+
+## Recommendation
+
+RECOMMENDATION: 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 32-cycle radix-2 non-restoring iterative divider with explicit worst-case latency and an early-exit optimization for typical operands.
+
+Rationale:
+
+- Best balance of area, energy, and performance for 128-core replication under current unvalidated estimates.
+- Deterministic, fully synchronous design simplifies verification and DFT.
+- 1/cycle MUL throughput meets general-purpose and crypto lower-half-multiply needs.
+- 32-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.
+
+RECOMMENDATION (conditional): If early workload analysis (TBD) 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 (unvalidated). Do not adopt a Newton–Raphson divider unless profiling evidence strongly supports it, due to verification complexity and variable latency.
+
+RECOMMENDATION: Do not adopt a fully combinational array divider or 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.
+
+RECOMMENDATION (fallback): If per-core area constraints prove tighter than estimated, evaluate B7 (cluster-shared organization, 16 instances serving 8 cores each) with a faster per-cluster divider (B4-pipe or B5) 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.
+
+## Confidence
+
+- Direction of recommendation: MEDIUM. The general design class is well-established; the specific B1 + non-restoring-32-cycle choice depends on a per-core area budget that has not yet been validated.
+- 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.
+- Verification strategy: HIGH. The recommended approach (formal on the multiplier, directed + randomized for the divider, explicit REM sign rule) is standard practice.
+- Edge-case correctness: HIGH. The RISC-V spec behavior is explicit; the previous revision contained an error in the DIVU-by-zero description, which is corrected here.
+
+## Open Questions
+
+- What is the EX-stage latency budget? (Depends on `pipeline.md`.)
+- What is the target frequency and process node? Determines whether 2-cycle MUL is feasible, and which final-adder architecture is appropriate.
+- Is the design in-order or out-of-order? Out-of-order execution can hide divide latency; in-order cannot.
+- Will the MUL/DIV unit share an issue port with the ALU, or have a dedicated issue port? (Likely shared, but TBD.)
+- 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.
+- What is the expected workload mix? General-purpose vs. HPC vs. embedded vs. server?
+- 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.
+- 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?
+- Is the B7 cluster-shared organization a realistic fallback, or is per-core replication a hard requirement?
+- What scan-compression architecture will be used for 128 replicated units?
+
+## Sources
+
+- The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA, M-extension chapter. 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. Specific URL and section: INSUFFICIENT EVIDENCE in the XH-1 repository to cite a specific revision; the manual is the canonical source.
+- Hennessy and Patterson, "Computer Architecture: A Quantitative Approach." General MUL/DIV trade-off discussion.
+- Parhami, "Computer Arithmetic: Algorithms and Hardware Designs." Standard reference for multiplier and divider algorithms including Booth, Wallace / Dadda, SRT, and Newton–Raphson.
+- Open-source RISC-V cores: Rocket Chip, BOOM (SmallBoomConfig and MediumBoomConfig), Ariane. Used as design-class references for typical MUL/DIV organizations and reported latency ranges. Specific commits, measured numbers, and PPA data: INSUFFICIENT EVIDENCE in the XH-1 repository to cite.
+- 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 or INSUFFICIENT EVIDENCE.

research/.xh1/runs/20260825T181609Z/research_03-core-design_mul-div-unit.md.round3.md

@@ -0,0 +1,339 @@
+# Multiply-Divide Unit
+
+## Status
+
+Engineering 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.
+
+## Abstract
+
+The 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.
+
+## Research Question
+
+What MUL/DIV architecture best fits XH-1's 128-core RISC-V design, given:
+
+- 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`.
+- 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.
+- 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.
+- 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.
+
+## Background
+
+### Required Instructions (RV64I + M)
+
+The M extension defines the following on RV64 (per the RISC-V Unprivileged ISA, Document Version 20191213, Chapter 7, "M Extension"):
+
+- MUL: 64×64 → lower 64 bits of the product.
+- MULH: 64×64 signed×signed → upper 64 bits of the product.
+- MULHSU: 64×64 signed (rs1) × unsigned (rs2) → upper 64 bits.
+- MULHU: 64×64 unsigned×unsigned → upper 64 bits.
+- DIV, DIVU, REM, REMU: 64-bit signed/unsigned divide and remainder.
+- MULW: 32×32 → lower 32 bits, sign-extended to 64.
+- DIVW, REMW: 32×32 signed divide and remainder, sign-extended to 64.
+- DIVUW, REMUW: 32×32 unsigned divide and remainder, sign-extended to 64.
+
+The 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.
+
+### Latency and Throughput Ranges (Background Only)
+
+Published 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.
+
+| Operation        | Reported latency range (cycles) | Reported throughput      | Source basis                                                          |
+|------------------|---------------------------------|--------------------------|-----------------------------------------------------------------------|
+| MUL (lower 64)   | 1–3                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`; Ariane `mult.sv`                           |
+| MULH (upper 64)  | 3–5                             | 1/cycle (pipelined)      | Rocket Chip `MulDiv.scala`                                             |
+| 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 |
+| MULW/DIVW family | similar to 64-bit variants      | similar                  | Same                                                                  |
+
+The 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.
+
+### Division Algorithms (Background)
+
+- Restoring division: simple, one bit per iteration, simple control, slow.
+- 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.
+- 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.
+- Newton–Raphson reciprocal multiplication: pre-computes an approximation of the reciprocal via iteration, then multiplies. Variable latency, convergence-dependent.
+- Goldschmidt division: similar trade-off to Newton–Raphson.
+
+### Multiplication Algorithms (Background)
+
+- Shift-and-add multiplier: simple, slow, one bit per cycle.
+- Array (Braun / Baugh–Wooley) multiplier: combinational, O(n²) partial products and full-adders, deterministic single-cycle latency, large area.
+- 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.
+- Booth-encoded multipliers (radix-4, radix-8): reduce partial-product count compared to a naive array by recoding one operand as overlapping signed digits.
+- Compressor-tree implementations (3:2 counters, 4:2 compressors, Ling / Han–Carlson adders) trade area for shorter critical paths.
+
+### Partial-Product Counts for Radix-4 and Radix-8 Booth (Worked)
+
+For 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.
+
+For 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.
+
+## Existing Approaches (Per-Core, Unless Noted)
+
+The 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.
+
+### A1. Iterative Shift-and-Add Multiplier + Restoring Divider
+
+- Multiplier: 64 cycles, 1 bit/cycle.
+- 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.
+- Area: very small. Used as the 1× baseline in the comparison table.
+
+### A2. Booth-Radix-4 Multiplier + Iterative Non-Restoring Divider
+
+- Multiplier: 33 partial products reduced through a 4:2 tree. Two pipeline stages; 2-cycle latency, 1/cycle throughput.
+- Divider: 64-cycle non-restoring, 1/64 throughput.
+- Area: estimated ~3–4× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A3. Pipelined Radix-4/8 Booth Multiplier + Radix-4 SRT Divider (Non-Pipelined SRT)
+
+- Multiplier: 2–3 stage pipeline, 1/cycle issue, latency 2–3 cycles.
+- 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).
+- Area: estimated ~5–7× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A4. Fully Combinational Array Multiplier + Radix-16 SRT Divider
+
+- Multiplier: 64×64 → 128 in a single cycle, large area.
+- Divider: 4–8 cycle latency via radix-16 selection.
+- Area: estimated ~10–15× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### A5. Shared / Clustered MUL/DIV Unit
+
+- A single MUL/DIV unit serves N cores, accessed via a small FIFO or blocking interface.
+- Saves replicated area; increases latency under contention.
+- A natural fit for 128-core designs only if inter-core divide/mul traffic is low or bursty.
+
+This alternative was not analyzed in depth in the previous revision; it is included here as a candidate organization (see B7).
+
+## Alternative Designs (Per-Core, Unless Noted)
+
+### B1. 2-Stage Pipelined Radix-4 Booth Multiplier + 64-Cycle Non-Restoring Divider
+
+- 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.
+- Latency 2 cycles, throughput 1/cycle.
+- 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.
+- Area: estimated ~3–5× of A1; INSUFFICIENT EVIDENCE without a technology file.
+
+### B2. 3-Stage Pipelined Radix-8 Booth Multiplier + 64-Cycle Non-Restoring Divider
+
+- 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.
+- Latency 3 cycles, throughput 1/cycle.
+- Smaller critical path than B1 at the cost of higher area and more complex Booth-3 encoding.
+
+### B3. Iterative Multiplier with Multi-Cycle Variable Latency
+
+- A single 64×64 multiplier reused across MUL/MULH/MULHSU/MULHU by selecting output bits.
+- Latency 4–5 cycles, 1/cycle throughput.
+- Smaller area than B1; longer issue-to-use distance complicates scheduling.
+
+### B4. Pipelined Radix-4 SRT Divider (Standalone, Two Variants)
+
+- B4 (non-pipelined): 16-cycle latency, 1/16 throughput, non-pipelined.
+- B4-pipe (pipelined): 16-cycle latency, 1/cycle throughput, deeply pipelined.
+- The previous revision was internally inconsistent between text and table; the two variants are recorded here as separate design points.
+- 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.
+- Larger area than B1's divider; more verification complexity (quotient-digit selection must be proven correct for all residuals).
+
+### B5. Newton–Raphson Divider with Hardware Reciprocal Iteration (64-bit)
+
+- 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.
+- 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).
+- Complex verification: requires convergence proof or guarded iteration count plus a fallback path.
+
+### B6. Combinational Array Divider (Non-Restoring 2D Cell Array)
+
+- 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.
+- 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.
+- Likely unacceptable for 128-core replication.
+
+### B7. Cluster-Shared MUL/DIV Unit (8 Cores per Unit, 16 Units Total)
+
+- A single radix-4 Booth multiplier + radix-4 SRT divider (B1 + B4-pipe) shared by 8 cores via a small FIFO.
+- 16 instances on the die instead of 128.
+- Per-cluster area budget can absorb a faster divider than per-core replication allows.
+- 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.
+
+## Comparison
+
+The 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.
+
+| Design                                          | MUL Latency | MUL Throughput | DIV Latency | DIV Throughput | Relative Area (per unit)         | Per-core effective area | Verification Complexity |
+|-------------------------------------------------|-------------|----------------|-------------|----------------|----------------------------------|-------------------------|-------------------------|
+| A1. Shift-add + restoring                       | 64          | 1/64           | 64          | 1/64           | 1×                               | 1×                      | Low                     |
+| A2. Booth-r4 + NR div                           | 2           | 1/1            | 64          | 1/64           | ~3–4× (unvalidated)              | ~3–4×                   | Low–Medium              |
+| A3. Pipelined r4/r8 + SRT-4 (non-pipe)          | 2–3         | 1/1            | 16          | 1/16           | ~5–7× (unvalidated)              | ~5–7×                   | Medium                  |
+| A4. Combinational + SRT-16                      | 1           | 1/1            | 4–8         | 1/4–1/8        | ~10–15× (unvalidated)            | ~10–15×                 | High                    |
+| B1. 2-stage r4 + NR-64 (no early-exit)          | 2           | 1/1            | 64 worst    | 1/64           | ~3–5× (unvalidated)              | ~3–5×                   | Low–Medium              |
+| B2. 3-stage r8 + NR-64                          | 3           | 1/1            | 64 worst    | 1/64           | ~4–6× (unvalidated)              | ~4–6×                   | Medium                  |
+| 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                  |
+| 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             |
+| B5. Newton–Raphson (64-bit)                     | 1           | 1/1            | 6–10        | 1/6–1/10       | ~6–8× (unvalidated)              | ~6–8×                   | High                    |
+| B6. Combinational non-restoring array divider   | 1           | 1/1            | 1           | 1/1            | very large (unvalidated)         | very large              | Medium                  |
+| 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             |
+
+The 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.
+
+## Proposal (Resolved, Conditional on Synthesis)
+
+PROPOSAL (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.
+
+CONDITIONAL 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.
+
+ORGANIZATIONAL 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.
+
+This 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.
+
+## Advantages
+
+- 2-cycle pipelined Radix-4 Booth multiplier offers 1/cycle throughput at modest per-core area, suitable for replicated 128-core operation.
+- 64-cycle non-restoring iterative divider has explicit worst-case latency that does not depend on operand values, simplifying pipeline scheduling, forwarding, and verification.
+- 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).
+
+## Disadvantages
+
+- 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.
+- 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.
+- Booth encoding complicates verification of signed/unsigned correctness for MULH / MULHSU / MULHU; the verification plan must cover all four sign combinations explicitly.
+- The design's performance on divide-heavy workloads depends on the in-order / out-of-order issue model, which is TBD.
+
+## XH-1 Considerations
+
+- 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.
+- 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.
+- The multiplier is sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing, not a separate datapath.
+- 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.
+
+### Instruction Coverage
+
+- MUL/MULH/MULHSU/MULHU: supported.
+- DIV/DIVU/REM/REMU: supported, with RISC-V-spec corner cases handled explicitly.
+- MULW/DIVW/DIVUW/REMW/REMUW: supported via shared datapath.
+
+### Edge Cases (RISC-V Spec, Document Version 20191213, Chapter 7)
+
+The 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:
+
+- DIV by zero: quotient = 2^XLEN − 1 (all bits set, which is the two's-complement representation of −1); remainder = dividend (x).
+- 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).
+- REM by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (two's-complement −1).
+- REMU by zero: remainder = dividend (x); quotient = 2^XLEN − 1 (unsigned all-ones).
+- Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0.
+- 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.
+
+Note 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.
+
+## 128-Core Scalability
+
+- 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.
+- 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.
+- Voltage / frequency: a moderately pipelined MUL/DIV is more resilient to voltage droop; this is an advantage for 128-core operation.
+- 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.
+- 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.
+
+## Performance Considerations
+
+- For general-purpose code, MUL/DIV is rarely the bottleneck; a 2-cycle MUL latency matches typical issue-to-use distances.
+- 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.
+- For hash tables and interpreters, DIV latency matters more than throughput; a 64-cycle divider is acceptable but not ideal.
+- For 32-bit integer code, the W-variants are the hot path; reusing the 64-bit datapath with muxed operands is acceptable.
+- 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.
+
+## Area Considerations
+
+- 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.
+- ASSUMPTION (unvalidated, heuristic): A 64-cycle non-restoring iterative divider is on the order of 0.01–0.05 mm² in the same envelope.
+- 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.
+- 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.
+- Sign-extension and zero-extension muxes for MULW are negligible area.
+
+## Power and Energy Considerations
+
+- A 64×64 multiplier tree has high switching activity; clock gating when the unit is idle is essential.
+- The iterative divider has lower average switching power than a fully combinational divider, but its long residency increases leakage energy per operation.
+- 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.
+- 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.
+- 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.
+
+## Implementation Considerations
+
+- Synchronous, single-clock-domain design inside the unit.
+- No asynchronous resets inside the iterative divider; synchronous reset only at the start of an operation.
+- 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.
+- Divider quotient and remainder registers are 64 bits each, with an extra bit for the iterative sign.
+- The microarchitectural state machine is small and well-suited to a one-hot or binary-encoded FSM.
+- Output muxing for MUL / MULH / MULHSU / MULHU / MULW is a small mux tree, not a separate datapath.
+- 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.
+
+## Verification Considerations
+
+- Formal verification of the multiplier compressor tree and final adder is feasible with bounded model checkers and is recommended.
+- 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.
+- Explicit coverage of the REM sign-of-dividend rule.
+- Coverage of all 4 MUL variants (MUL, MULH, MULHSU, MULHU) and the W-variants.
+- 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.
+- 128-core DFT: see the dedicated section below.
+
+### DFT Strategy (128 Replicated Units)
+
+- Single-clock-domain, synchronous-reset-only design is required for scan insertion.
+- 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.
+- Scan compression: per-core compression reduces the number of top-level scan pins; the compression architecture is TBD by the DFT plan.
+- 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.
+- 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.
+
+## Software Implications
+
+- Compilers emit MUL freely; no software changes are required.
+- 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.
+- 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.
+- 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.
+- JavaScript engines and language runtimes may issue frequent DIVs for tagged-value unpacking; a 64-cycle divider increases interpreter dispatch latency for that pattern.
+
+## Recommendation
+
+RECOMMENDATION (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.
+
+Rationale:
+
+- Best balance of area, energy, and performance for 128-core replication under current unvalidated estimates, pending synthesis.
+- Deterministic, fully synchronous design simplifies verification and DFT.
+- 1/cycle MUL throughput meets general-purpose and crypto lower-half-multiply needs.
+- 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.
+
+The 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.
+
+RECOMMENDATION (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.
+
+RECOMMENDATION: 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.
+
+RECOMMENDATION (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.
+
+## Confidence
+
+- 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.
+- 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.
+- 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.
+- 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.
+
+## Open Questions
+
+- What is the EX-stage latency budget? (Depends on `pipeline.md`.)
+- What is the target frequency and process node? Determines whether 2-cycle MUL is feasible, and which final-adder architecture is appropriate.
+- 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.
+- 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.
+- 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.
+- What is the expected workload mix? General-purpose vs. HPC vs. embedded vs. server?
+- 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.
+- 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.
+- Is the B7 cluster-shared organization a realistic fallback, or is per-core replication a hard requirement?
+- What scan-compression architecture will be used for 128 replicated units?
+
+## Sources
+
+- 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.
+- 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.
+- BOOM (SmallBoomConfig and MediumBoomConfig), public repository. Background reference only.
+- Ariane, file `core/multiplier.sv` and related, public repository. Background reference only.
+- 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.
+- 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.
+- 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.