setup

research/.xh1/runs/20260825T180900Z/attempts

@@ -0,0 +1,2 @@
+2026-08-25T18:09:56Z	research/03-core-design/mul-div-unit.md	1	research	completed
+2026-08-25T18:10:12Z	research/03-core-design/mul-div-unit.md	1	review	api-failure

research/.xh1/runs/20260825T180900Z/failed

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

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

@@ -0,0 +1,194 @@
+# Multiplier–Divider Unit for the XH-1 Core
+
+## Status
+DRAFT — Engineering research, no silicon data.
+
+## Abstract
+This document investigates the design of an integer multiply/divide (MUL/DIV) unit suitable for one tile of the XH-1 128-core RISC-V processor. It frames the problem space (RV32M/RV64M, latency vs. throughput, area and energy), surveys the canonical microarchitectural options (iterative shift-and-add, array multipliers, Booth/Wallace/Dadda trees, reciprocal/sRT dividers, radix-2/4/8 dividers, and merged MAC-fused units), and maps them against the constraints implied by the other XH-1 core documents (small per-core budget, 128-core replication, expected integration with the pipeline, register file, and load–store unit). The document is written so that downstream choices about pipeline depth, core clock target, and shared vs. private FP/MAC can be made coherently with the MUL/DIV decision.
+
+## Research Question
+What microarchitecture for the integer multiply/divide unit best fits one XH-1 core, given that the core will be replicated 128 times, must support the M extension on RV32 and/or RV64, and must coexist with a pipeline, register file, and load–store unit whose budgets are not yet fixed?
+
+Sub-questions:
+1. Should the unit be fully combinatorial, multi-cycle iterative, or pipelined?
+2. Which radix and which encoding (Booth-2, Booth-3, modified Booth-4) is appropriate for the expected operand width?
+3. Should MUL and DIV share silicon, or be separate datapaths?
+4. How does the choice interact with 128-core replication (area amortization, frequency, yield)?
+5. What are the verification implications of each choice?
+
+## Background
+The RISC-V M extension defines four signed/unsigned multiply variants producing 2X-bit results (MUL, MULH, MULHU, MULHSU), four matching multiply-high variants, and signed/unsigned divide and remainder (DIV, DIVU, REM, REMU). On RV64 there is an additional MULW/DIVW/REM family that operates on 32-bit values and sign-extends.
+
+Key microarchitectural properties that drive the design:
+- Latency-tolerance: in a deep pipeline, multi-cycle iterative units are acceptable as long as the structural hazard is bounded and the scoreboard/issue logic handles in-flight multiplies.
+- Throughput: the M extension opcodes are infrequent in many workloads but dominate in linear-algebra kernels, crypto, and hash functions.
+- Operand width: an RV64 core needs both 64-bit and 32-bit paths. A 64×64→128 multiplier is roughly 4× the area of a 32×32→64 multiplier.
+- Result width: MULH-family instructions require the full 2X-bit result; MUL only requires the low X bits. Most designs share the upper datapath and select the low half.
+
+ASSUMPTION: XH-1 cores implement the M extension. If only the I extension is required, the MUL/DIV unit collapses dramatically. The remainder of this document assumes M is in scope.
+ASSUMPTION: XH-1 is RV64. If RV32 only, all 64-bit-specific considerations below can be relaxed.
+
+## Existing Approaches
+
+### Multipliers
+1. Iterative shift-and-add multiplier
+2. Array (braid) multiplier
+3. Wallace tree multiplier
+4. Dadda tree multiplier
+5. Booth-encoded tree multiplier (radix-4, modified Booth)
+6. Higher-radix Booth (radix-8/16) with 4:2/5:2 compressor trees
+7. Pipelined versions of any of the above, with stage counts from 1 to N
+
+### Dividers
+1. Restoring divider
+2. Non-restoring divider
+3. SRT divider (s radix-2, radix-4, radix-8, radix-16)
+4. Newton–Raphson reciprocal + multiply (software or hardware)
+5. Goldschmidt divider
+6. Digit-recurrence with prescaling (for faster convergence)
+7. Lookup-table (LUT) assisted dividers (small LUT, big LUT)
+
+PROPOSAL: Classify each option along four axes — latency (cycles), throughput (1/n per cycle), area (gate equivalent or µm² estimate), and design complexity (verification effort, corner cases).
+
+## Alternative Designs
+
+### Option A: Pipelined iterative multiplier + iterative non-restoring divider
+- One shared 64-bit datapath, Booth-2 radix-4, latency ≈ 3–4 cycles for MUL, fully pipelined at 1 result/cycle.
+- Divider: non-restoring, ≈ 32–64 cycles for RV64 DIV, variable.
+- Area: smallest among the options; one of the smallest in published small-core implementations.
+- Verification: standard; iterative state machines are well understood.
+
+### Option B: Fully combinational 64×64 array multiplier + SRT-4 divider
+- MUL latency: 1 cycle, but very high area and long critical path.
+- DIV: SRT-4, ≈ 16 cycles typical.
+- Area: largest.
+- Verification: simple timing closure problem, but 128 cores × this area is likely prohibitive.
+
+### Option C: Pipelined Wallace/Booth tree (3-stage) + SRT-4 divider
+- MUL: 3-cycle pipelined, 1 result/cycle sustained.
+- DIV: 16–20 cycles, fully pipelined divider.
+- Area: moderate to large; tree is irregular.
+- Verification: irregular partial-product reduction is harder to verify than array.
+
+### Option D: Fused multiply–accumulate (MAC) with Booth-3 (radix-8) and 4:2 compressors
+- MUL: 3-cycle, also accepts an accumulate operand each cycle.
+- Provides a useful primitive for dot-product kernels and soft-fp libraries.
+- Divider: separate iterative non-restoring path.
+- Area: similar to C, but the accumulator latch and bypass network add cost.
+
+### Option E: Truncated 32×32→64 only, with MULHW/DIVW synthesized in microcode
+- Illegal in general: software synthesis of MULH is too slow to be acceptable.
+- Listed for completeness and to discard.
+
+## Comparison
+
+| Option | MUL latency | MUL throughput | DIV latency (RV64) | Area (relative) | Design complexity |
+|--------|-------------|----------------|---------------------|------------------|--------------------|
+| A — Iterative Booth + NR div | 3–4 cyc | 1/cyc pipelined | 32–64 cyc | 0.6–0.8× | Low |
+| B — Array + SRT-4 | 1 cyc | 1/cyc | 16 cyc | 2.5–3.0× | Medium (timing) |
+| C — Wallace/Booth + SRT-4 | 3 cyc | 1/cyc | 16–20 cyc | 1.0–1.2× | High (tree) |
+| D — MAC (Booth-3, 4:2) + NR div | 3 cyc | 1/cyc (with acc) | 32–64 cyc | 1.1–1.3× | High |
+| E — Truncated, microcoded | n/a | n/a | n/a | smallest | n/a (incomplete) |
+
+Numbers above are ORDER-OF-MAGNITUDE ESTIMATES based on published small-core implementations; INSUFFICIENT EVIDENCE exists to claim a specific gate count or µm² without synthesis at a known target node.
+
+## Advantages
+- Option A: smallest area per core → most 128-core replication headroom; trivially fits any pipeline depth; well-understood verification.
+- Option B: best single-cycle latency; useful for OoO cores with tight issue windows.
+- Option C: good balance of latency and area; widely used in commercial OoO cores.
+- Option D: enables efficient dot-product and SIMD-style software; helps a soft FP stack.
+
+## Disadvantages
+- Option A: lower peak MUL throughput than pipelined trees; multi-cycle DIV may stall the issue queue on back-to-back DIVs.
+- Option B: area is prohibitive at 128 cores; long critical path forces a slow core clock or deep pipelining (defeating the latency benefit).
+- Option C: Wallace/Dadda partial-product reduction has irregular carry-save structures that are harder to formally verify and harder to fix in ECO.
+- Option D: accumulator adds bypass and forwarding complexity into the pipeline and register-file writeback path; benefits only workloads that can be rewritten to use the MAC.
+- Option E: not viable for an M-extension-compliant core.
+
+## XH-1 Considerations
+ASSUMPTION: XH-1 is a tiled, replicated design where per-core area is a first-class constraint because the whole 128-core array must fit in the package, power, and yield envelope. A small per-core MUL/DIV is therefore a high-value design point.
+
+PROPOSAL: Treat MUL/DIV as one of the "shared-tile resource" candidates. Specifically:
+- If 128 cores × 1 MUL/DIV per core exceeds the area budget, fall back to a per-cluster shared unit (e.g., 1 MUL/DIV per 4 or 8 cores) behind a dedicated interconnect port.
+- The crossbar/coherence documents in the repository should be checked before committing to a per-core vs. shared decision.
+- A shared unit complicates the scoreboard: the issue queue must track remote MUL/DIV latency, which can be 4–8× the per-core MUL latency.
+
+## 128-Core Scalability
+- Per-core area: Option A scales best; Option B is the worst case.
+- Frequency: Option A and Option C both close timing at typical small-core targets; Option B is the only option likely to force a slower core clock.
+- Yield: small per-core datapath → higher core yield, fewer fatal defects per die.
+- Coherence traffic: a long-latency MUL/DIV keeps the core stalled but does not generate coherence traffic; an off-core MUL/DIV (shared) does, because the issuing core may continue past the result and the unit must return through the interconnect.
+- Verification: per-core unit × 128 = 128 instances × one verification suite. This is a strong argument for the simplest microarchitecture that meets the latency target.
+
+## Performance Considerations
+- For most non-numeric workloads, MUL/DIV throughput does not bound IPC; latency does not either, because the operand is rarely on the critical path. A 3–4 cycle MUL and a 32–64 cycle DIV is acceptable.
+- For numeric, crypto, and hash kernels, MUL throughput is critical; the pipelined-tree options (C, D) win by roughly 2–3× peak throughput.
+- DIV is rarely on the hot path; a 32–64 cycle iterative divider is almost always sufficient.
+
+RECOMMENDATION (conditional): If XH-1 targets general-purpose + occasional numeric, prefer Option A. If XH-1 targets numeric/CV/crypto explicitly, prefer Option C.
+
+## Area Considerations
+- A 64×64→128 array multiplier at a modern node is roughly the size of the register file's writeback port plus the ALU; this is the dominant per-core cost in Option B.
+- A pipelined 3-stage tree (Option C) shrinks the per-stage critical path at the cost of three sets of partial-product reduction and accumulation latches.
+- An iterative multiplier (Option A) is dominated by a single 33–64-bit adder and a shift register, and is the smallest.
+- PROPOSAL: Capture the per-option area in the implementation document once the target node is fixed. Until then, treat the "relative" column in the comparison table as the working estimate.
+
+## Power and Energy Considerations
+- Combinational array multipliers (Option B) toggle the entire partial-product array every cycle; energy per MUL is highest.
+- Pipelined tree multipliers (Option C) distribute the switching across pipeline registers, lowering per-cycle peak power but with similar energy per operation.
+- Iterative shift-and-add (Option A) is the lowest per-operation energy because the active datapath per cycle is small (one adder stage).
+- 128-core replication: peak power is the product of per-core dynamic power and number of active cores. Option A keeps per-core power lowest, which is the most important axis for a 128-core envelope.
+
+## Implementation Considerations
+- Sign handling: MULHSU requires signed×unsigned with full sign extension. The most common bug source in MUL/DIV is signed/unsigned mode selection; design the control path so that mode bits are sourced from the decoder, never from a sticky register.
+- Zero-detection: DIV by zero must complete in bounded time and write a defined result. The IEEE / RISC-V rule is that DIV/REM by zero return −1 / the dividend. The unit must NOT trap on divide-by-zero; that is a software choice.
+- Overflow: for DIV, the only overflow case is INT_MIN / −1. RISC-V mandates that this returns INT_MIN. The divider must detect this explicitly; iterative non-restoring dividers do, but SRT designs must be checked.
+- Latency variability: DIV latency is data-dependent in non-restoring designs (it is fixed in SRT). If the pipeline assumes a fixed MUL/DIV latency, prefer an SRT divider or a constant-iteration iterative divider.
+- Reset and scan: a 128-core replication multiplies the scan chain length. PROPOSAL: gate scan on the MUL/DIV unit to limit shift power, at the cost of reduced fault coverage. This is a verification trade-off.
+
+## Verification Considerations
+- The MUL/DIV unit has the highest ratio of corner cases to lines of RTL of any execution unit. Famous verification pitfalls:
+  - Signed multiplication: 0 × INT_MIN, INT_MIN × INT_MIN.
+  - MULH overflow into the high half with sign extension.
+  - MULHSU sign/unsigned mixing.
+  - DIV by zero, REM by zero.
+  - DIV overflow (INT_MIN / −1, INT_MIN % −1).
+  - All 16 combinations of signed/unsigned × 4 ops × 2 widths on RV64.
+- PROPOSAL: Maintain a directed-test corpus at the unit level that exhausts the (sign × op × corner-operand) matrix, and a constrained-random suite at the core level.
+- ASSUMPTION: XH-1 follows the riscv-formal convention of writing the MUL/DIV shadow model in a functional language. If so, the shadow model is the most expensive deliverable in the verification flow and is the strongest argument for picking the simplest microarchitecture.
+
+## Software Considerations
+- The compiler's latency model for MUL/DIV must match the hardware's; otherwise the scheduler will insert unnecessary stalls or miss scheduling opportunities. If Option A is chosen, the compiler should treat MUL as a 3–4 cycle latency op and DIV as a 32–64 cycle latency op.
+- If MUL/DIV is moved off-core (shared), the toolchain needs an intrinsic or scheduling model that reflects the round-trip latency through the interconnect. This is non-trivial; most toolchains do not model non-uniform functional unit latency across cores.
+- The Linux kernel's alternatives patching and the C library's soft-float paths sometimes use MUL/DIV in hot paths; verify that the chosen unit's latency is acceptable for the kernel configurations that the project intends to boot.
+
+## Recommendation
+PROPOSAL: For XH-1's first-pass implementation, adopt **Option A** (iterative Booth-2 multiplier pipelined to 1 result/cycle, non-restoring divider at 1 bit/cycle) for the following reasons:
+1. Per-core area is minimized, which is the dominant axis in a 128-core replication.
+2. The verification footprint is the smallest among the viable options.
+3. The latency/throughput profile is acceptable for the majority of non-numeric workloads.
+4. The microarchitecture is the easiest to ECO and to port across nodes.
+
+PROPOSAL: If benchmarks (TBD) show that MUL/DIV throughput is on the critical path, migrate to **Option C** (pipelined 3-stage Booth/Wallace tree + SRT-4 divider) as a follow-on revision. Reserve **Option B** (fully combinational) for a hypothetical single-core "XH-1 Big" variant where replication is not the binding constraint.
+
+ASSUMPTION: This recommendation is contingent on the pipeline depth, target clock, and per-core area budget not being fixed by other documents in the repository. If, for example, the pipeline document commits to a 5+ GHz target, Option A may not close timing and Option C becomes the floor rather than the upgrade.
+
+## Confidence
+- Low-to-medium on the relative area numbers; they are order-of-magnitude estimates from published small-core work, not XH-1 synthesis.
+- High on the qualitative trade-offs (area, verification complexity, replication cost).
+- Low on the latency numbers, which depend on the target node and the adder architecture that is not yet specified in `alu.md` or `datapath.md`.
+
+## Open Questions
+- What is the target node and the target core clock? This gates the latency-vs-area decision.
+- Is XH-1 RV32 or RV64? If RV32, the 32×32→64 multiplier is dramatically smaller.
+- Is the M extension mandatory for the first tape-out, or can it be gated behind a config bit?
+- Is there a plan for a shared per-cluster MAC/vector unit that subsumes the MUL/DIV? If so, the per-core MUL/DIV may be reduced to a minimal subset.
+- What is the pipeline depth (see `pipeline.md`, currently SOON)? This determines whether a 1-cycle, 3-cycle, or N-cycle MUL fits cleanly into the execute stage.
+- What is the issue model — in-order (single-issue, dual-issue, etc.)? The structural hazard model for MUL/DIV depends on it.
+- Does the project plan to use `riscv-formal` for verification, or a UVM/constrained-random flow? The two flows have different optimal unit-level architectures.
+- What are the integer workload targets — server, embedded, HPC, ML inference? Each implies a different MUL/DIV throughput requirement.
+
+## Sources
+- The RISC-V "Unprivileged ISA" specification, M-extension chapter — INSUFFICIENT EVIDENCE to cite a specific revision without checking the repository. The relevant normative requirements are: MUL/MULH/MULHU/MULHSU produce full 2X-bit results, DIV/DIVU/REM/REMU round toward zero, DIV/REM by zero write back defined results, and INT_MIN / −1 is defined.
+- Canonical microarchitecture textbooks (Hennessy & Patterson; Parhami; Ercegovac & Lang) — referenced only at the level of well-known technique names (Booth, Wallace, Dadda, SRT, non-restoring division). No specific page or claim is attributed.
+- INSUFFICIENT EVIDENCE: any XH-1-specific synthesis, layout, or benchmark data. The comparison table is built from public-domain technique properties and must be re-validated with synthesis at the target node before tape-out.

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

@@ -0,0 +1,194 @@
+# Multiplier–Divider Unit for the XH-1 Core
+
+## Status
+DRAFT — Engineering research, no silicon data.
+
+## Abstract
+This document investigates the design of an integer multiply/divide (MUL/DIV) unit suitable for one tile of the XH-1 128-core RISC-V processor. It frames the problem space (RV32M/RV64M, latency vs. throughput, area and energy), surveys the canonical microarchitectural options (iterative shift-and-add, array multipliers, Booth/Wallace/Dadda trees, reciprocal/sRT dividers, radix-2/4/8 dividers, and merged MAC-fused units), and maps them against the constraints implied by the other XH-1 core documents (small per-core budget, 128-core replication, expected integration with the pipeline, register file, and load–store unit). The document is written so that downstream choices about pipeline depth, core clock target, and shared vs. private FP/MAC can be made coherently with the MUL/DIV decision.
+
+## Research Question
+What microarchitecture for the integer multiply/divide unit best fits one XH-1 core, given that the core will be replicated 128 times, must support the M extension on RV32 and/or RV64, and must coexist with a pipeline, register file, and load–store unit whose budgets are not yet fixed?
+
+Sub-questions:
+1. Should the unit be fully combinatorial, multi-cycle iterative, or pipelined?
+2. Which radix and which encoding (Booth-2, Booth-3, modified Booth-4) is appropriate for the expected operand width?
+3. Should MUL and DIV share silicon, or be separate datapaths?
+4. How does the choice interact with 128-core replication (area amortization, frequency, yield)?
+5. What are the verification implications of each choice?
+
+## Background
+The RISC-V M extension defines four signed/unsigned multiply variants producing 2X-bit results (MUL, MULH, MULHU, MULHSU), four matching multiply-high variants, and signed/unsigned divide and remainder (DIV, DIVU, REM, REMU). On RV64 there is an additional MULW/DIVW/REM family that operates on 32-bit values and sign-extends.
+
+Key microarchitectural properties that drive the design:
+- Latency-tolerance: in a deep pipeline, multi-cycle iterative units are acceptable as long as the structural hazard is bounded and the scoreboard/issue logic handles in-flight multiplies.
+- Throughput: the M extension opcodes are infrequent in many workloads but dominate in linear-algebra kernels, crypto, and hash functions.
+- Operand width: an RV64 core needs both 64-bit and 32-bit paths. A 64×64→128 multiplier is roughly 4× the area of a 32×32→64 multiplier.
+- Result width: MULH-family instructions require the full 2X-bit result; MUL only requires the low X bits. Most designs share the upper datapath and select the low half.
+
+ASSUMPTION: XH-1 cores implement the M extension. If only the I extension is required, the MUL/DIV unit collapses dramatically. The remainder of this document assumes M is in scope.
+ASSUMPTION: XH-1 is RV64. If RV32 only, all 64-bit-specific considerations below can be relaxed.
+
+## Existing Approaches
+
+### Multipliers
+1. Iterative shift-and-add multiplier
+2. Array (braid) multiplier
+3. Wallace tree multiplier
+4. Dadda tree multiplier
+5. Booth-encoded tree multiplier (radix-4, modified Booth)
+6. Higher-radix Booth (radix-8/16) with 4:2/5:2 compressor trees
+7. Pipelined versions of any of the above, with stage counts from 1 to N
+
+### Dividers
+1. Restoring divider
+2. Non-restoring divider
+3. SRT divider (s radix-2, radix-4, radix-8, radix-16)
+4. Newton–Raphson reciprocal + multiply (software or hardware)
+5. Goldschmidt divider
+6. Digit-recurrence with prescaling (for faster convergence)
+7. Lookup-table (LUT) assisted dividers (small LUT, big LUT)
+
+PROPOSAL: Classify each option along four axes — latency (cycles), throughput (1/n per cycle), area (gate equivalent or µm² estimate), and design complexity (verification effort, corner cases).
+
+## Alternative Designs
+
+### Option A: Pipelined iterative multiplier + iterative non-restoring divider
+- One shared 64-bit datapath, Booth-2 radix-4, latency ≈ 3–4 cycles for MUL, fully pipelined at 1 result/cycle.
+- Divider: non-restoring, ≈ 32–64 cycles for RV64 DIV, variable.
+- Area: smallest among the options; one of the smallest in published small-core implementations.
+- Verification: standard; iterative state machines are well understood.
+
+### Option B: Fully combinational 64×64 array multiplier + SRT-4 divider
+- MUL latency: 1 cycle, but very high area and long critical path.
+- DIV: SRT-4, ≈ 16 cycles typical.
+- Area: largest.
+- Verification: simple timing closure problem, but 128 cores × this area is likely prohibitive.
+
+### Option C: Pipelined Wallace/Booth tree (3-stage) + SRT-4 divider
+- MUL: 3-cycle pipelined, 1 result/cycle sustained.
+- DIV: 16–20 cycles, fully pipelined divider.
+- Area: moderate to large; tree is irregular.
+- Verification: irregular partial-product reduction is harder to verify than array.
+
+### Option D: Fused multiply–accumulate (MAC) with Booth-3 (radix-8) and 4:2 compressors
+- MUL: 3-cycle, also accepts an accumulate operand each cycle.
+- Provides a useful primitive for dot-product kernels and soft-fp libraries.
+- Divider: separate iterative non-restoring path.
+- Area: similar to C, but the accumulator latch and bypass network add cost.
+
+### Option E: Truncated 32×32→64 only, with MULHW/DIVW synthesized in microcode
+- Illegal in general: software synthesis of MULH is too slow to be acceptable.
+- Listed for completeness and to discard.
+
+## Comparison
+
+| Option | MUL latency | MUL throughput | DIV latency (RV64) | Area (relative) | Design complexity |
+|--------|-------------|----------------|---------------------|------------------|--------------------|
+| A — Iterative Booth + NR div | 3–4 cyc | 1/cyc pipelined | 32–64 cyc | 0.6–0.8× | Low |
+| B — Array + SRT-4 | 1 cyc | 1/cyc | 16 cyc | 2.5–3.0× | Medium (timing) |
+| C — Wallace/Booth + SRT-4 | 3 cyc | 1/cyc | 16–20 cyc | 1.0–1.2× | High (tree) |
+| D — MAC (Booth-3, 4:2) + NR div | 3 cyc | 1/cyc (with acc) | 32–64 cyc | 1.1–1.3× | High |
+| E — Truncated, microcoded | n/a | n/a | n/a | smallest | n/a (incomplete) |
+
+Numbers above are ORDER-OF-MAGNITUDE ESTIMATES based on published small-core implementations; INSUFFICIENT EVIDENCE exists to claim a specific gate count or µm² without synthesis at a known target node.
+
+## Advantages
+- Option A: smallest area per core → most 128-core replication headroom; trivially fits any pipeline depth; well-understood verification.
+- Option B: best single-cycle latency; useful for OoO cores with tight issue windows.
+- Option C: good balance of latency and area; widely used in commercial OoO cores.
+- Option D: enables efficient dot-product and SIMD-style software; helps a soft FP stack.
+
+## Disadvantages
+- Option A: lower peak MUL throughput than pipelined trees; multi-cycle DIV may stall the issue queue on back-to-back DIVs.
+- Option B: area is prohibitive at 128 cores; long critical path forces a slow core clock or deep pipelining (defeating the latency benefit).
+- Option C: Wallace/Dadda partial-product reduction has irregular carry-save structures that are harder to formally verify and harder to fix in ECO.
+- Option D: accumulator adds bypass and forwarding complexity into the pipeline and register-file writeback path; benefits only workloads that can be rewritten to use the MAC.
+- Option E: not viable for an M-extension-compliant core.
+
+## XH-1 Considerations
+ASSUMPTION: XH-1 is a tiled, replicated design where per-core area is a first-class constraint because the whole 128-core array must fit in the package, power, and yield envelope. A small per-core MUL/DIV is therefore a high-value design point.
+
+PROPOSAL: Treat MUL/DIV as one of the "shared-tile resource" candidates. Specifically:
+- If 128 cores × 1 MUL/DIV per core exceeds the area budget, fall back to a per-cluster shared unit (e.g., 1 MUL/DIV per 4 or 8 cores) behind a dedicated interconnect port.
+- The crossbar/coherence documents in the repository should be checked before committing to a per-core vs. shared decision.
+- A shared unit complicates the scoreboard: the issue queue must track remote MUL/DIV latency, which can be 4–8× the per-core MUL latency.
+
+## 128-Core Scalability
+- Per-core area: Option A scales best; Option B is the worst case.
+- Frequency: Option A and Option C both close timing at typical small-core targets; Option B is the only option likely to force a slower core clock.
+- Yield: small per-core datapath → higher core yield, fewer fatal defects per die.
+- Coherence traffic: a long-latency MUL/DIV keeps the core stalled but does not generate coherence traffic; an off-core MUL/DIV (shared) does, because the issuing core may continue past the result and the unit must return through the interconnect.
+- Verification: per-core unit × 128 = 128 instances × one verification suite. This is a strong argument for the simplest microarchitecture that meets the latency target.
+
+## Performance Considerations
+- For most non-numeric workloads, MUL/DIV throughput does not bound IPC; latency does not either, because the operand is rarely on the critical path. A 3–4 cycle MUL and a 32–64 cycle DIV is acceptable.
+- For numeric, crypto, and hash kernels, MUL throughput is critical; the pipelined-tree options (C, D) win by roughly 2–3× peak throughput.
+- DIV is rarely on the hot path; a 32–64 cycle iterative divider is almost always sufficient.
+
+RECOMMENDATION (conditional): If XH-1 targets general-purpose + occasional numeric, prefer Option A. If XH-1 targets numeric/CV/crypto explicitly, prefer Option C.
+
+## Area Considerations
+- A 64×64→128 array multiplier at a modern node is roughly the size of the register file's writeback port plus the ALU; this is the dominant per-core cost in Option B.
+- A pipelined 3-stage tree (Option C) shrinks the per-stage critical path at the cost of three sets of partial-product reduction and accumulation latches.
+- An iterative multiplier (Option A) is dominated by a single 33–64-bit adder and a shift register, and is the smallest.
+- PROPOSAL: Capture the per-option area in the implementation document once the target node is fixed. Until then, treat the "relative" column in the comparison table as the working estimate.
+
+## Power and Energy Considerations
+- Combinational array multipliers (Option B) toggle the entire partial-product array every cycle; energy per MUL is highest.
+- Pipelined tree multipliers (Option C) distribute the switching across pipeline registers, lowering per-cycle peak power but with similar energy per operation.
+- Iterative shift-and-add (Option A) is the lowest per-operation energy because the active datapath per cycle is small (one adder stage).
+- 128-core replication: peak power is the product of per-core dynamic power and number of active cores. Option A keeps per-core power lowest, which is the most important axis for a 128-core envelope.
+
+## Implementation Considerations
+- Sign handling: MULHSU requires signed×unsigned with full sign extension. The most common bug source in MUL/DIV is signed/unsigned mode selection; design the control path so that mode bits are sourced from the decoder, never from a sticky register.
+- Zero-detection: DIV by zero must complete in bounded time and write a defined result. The IEEE / RISC-V rule is that DIV/REM by zero return −1 / the dividend. The unit must NOT trap on divide-by-zero; that is a software choice.
+- Overflow: for DIV, the only overflow case is INT_MIN / −1. RISC-V mandates that this returns INT_MIN. The divider must detect this explicitly; iterative non-restoring dividers do, but SRT designs must be checked.
+- Latency variability: DIV latency is data-dependent in non-restoring designs (it is fixed in SRT). If the pipeline assumes a fixed MUL/DIV latency, prefer an SRT divider or a constant-iteration iterative divider.
+- Reset and scan: a 128-core replication multiplies the scan chain length. PROPOSAL: gate scan on the MUL/DIV unit to limit shift power, at the cost of reduced fault coverage. This is a verification trade-off.
+
+## Verification Considerations
+- The MUL/DIV unit has the highest ratio of corner cases to lines of RTL of any execution unit. Famous verification pitfalls:
+  - Signed multiplication: 0 × INT_MIN, INT_MIN × INT_MIN.
+  - MULH overflow into the high half with sign extension.
+  - MULHSU sign/unsigned mixing.
+  - DIV by zero, REM by zero.
+  - DIV overflow (INT_MIN / −1, INT_MIN % −1).
+  - All 16 combinations of signed/unsigned × 4 ops × 2 widths on RV64.
+- PROPOSAL: Maintain a directed-test corpus at the unit level that exhausts the (sign × op × corner-operand) matrix, and a constrained-random suite at the core level.
+- ASSUMPTION: XH-1 follows the riscv-formal convention of writing the MUL/DIV shadow model in a functional language. If so, the shadow model is the most expensive deliverable in the verification flow and is the strongest argument for picking the simplest microarchitecture.
+
+## Software Considerations
+- The compiler's latency model for MUL/DIV must match the hardware's; otherwise the scheduler will insert unnecessary stalls or miss scheduling opportunities. If Option A is chosen, the compiler should treat MUL as a 3–4 cycle latency op and DIV as a 32–64 cycle latency op.
+- If MUL/DIV is moved off-core (shared), the toolchain needs an intrinsic or scheduling model that reflects the round-trip latency through the interconnect. This is non-trivial; most toolchains do not model non-uniform functional unit latency across cores.
+- The Linux kernel's alternatives patching and the C library's soft-float paths sometimes use MUL/DIV in hot paths; verify that the chosen unit's latency is acceptable for the kernel configurations that the project intends to boot.
+
+## Recommendation
+PROPOSAL: For XH-1's first-pass implementation, adopt **Option A** (iterative Booth-2 multiplier pipelined to 1 result/cycle, non-restoring divider at 1 bit/cycle) for the following reasons:
+1. Per-core area is minimized, which is the dominant axis in a 128-core replication.
+2. The verification footprint is the smallest among the viable options.
+3. The latency/throughput profile is acceptable for the majority of non-numeric workloads.
+4. The microarchitecture is the easiest to ECO and to port across nodes.
+
+PROPOSAL: If benchmarks (TBD) show that MUL/DIV throughput is on the critical path, migrate to **Option C** (pipelined 3-stage Booth/Wallace tree + SRT-4 divider) as a follow-on revision. Reserve **Option B** (fully combinational) for a hypothetical single-core "XH-1 Big" variant where replication is not the binding constraint.
+
+ASSUMPTION: This recommendation is contingent on the pipeline depth, target clock, and per-core area budget not being fixed by other documents in the repository. If, for example, the pipeline document commits to a 5+ GHz target, Option A may not close timing and Option C becomes the floor rather than the upgrade.
+
+## Confidence
+- Low-to-medium on the relative area numbers; they are order-of-magnitude estimates from published small-core work, not XH-1 synthesis.
+- High on the qualitative trade-offs (area, verification complexity, replication cost).
+- Low on the latency numbers, which depend on the target node and the adder architecture that is not yet specified in `alu.md` or `datapath.md`.
+
+## Open Questions
+- What is the target node and the target core clock? This gates the latency-vs-area decision.
+- Is XH-1 RV32 or RV64? If RV32, the 32×32→64 multiplier is dramatically smaller.
+- Is the M extension mandatory for the first tape-out, or can it be gated behind a config bit?
+- Is there a plan for a shared per-cluster MAC/vector unit that subsumes the MUL/DIV? If so, the per-core MUL/DIV may be reduced to a minimal subset.
+- What is the pipeline depth (see `pipeline.md`, currently SOON)? This determines whether a 1-cycle, 3-cycle, or N-cycle MUL fits cleanly into the execute stage.
+- What is the issue model — in-order (single-issue, dual-issue, etc.)? The structural hazard model for MUL/DIV depends on it.
+- Does the project plan to use `riscv-formal` for verification, or a UVM/constrained-random flow? The two flows have different optimal unit-level architectures.
+- What are the integer workload targets — server, embedded, HPC, ML inference? Each implies a different MUL/DIV throughput requirement.
+
+## Sources
+- The RISC-V "Unprivileged ISA" specification, M-extension chapter — INSUFFICIENT EVIDENCE to cite a specific revision without checking the repository. The relevant normative requirements are: MUL/MULH/MULHU/MULHSU produce full 2X-bit results, DIV/DIVU/REM/REMU round toward zero, DIV/REM by zero write back defined results, and INT_MIN / −1 is defined.
+- Canonical microarchitecture textbooks (Hennessy & Patterson; Parhami; Ercegovac & Lang) — referenced only at the level of well-known technique names (Booth, Wallace, Dadda, SRT, non-restoring division). No specific page or claim is attributed.
+- INSUFFICIENT EVIDENCE: any XH-1-specific synthesis, layout, or benchmark data. The comparison table is built from public-domain technique properties and must be re-validated with synthesis at the target node before tape-out.