# XH-1 Multiply/Divide Unit (MDU) Research

## Status

Stub document. Repository context for XH-1 does not establish:
- Pipeline depth of the base integer pipeline
- Whether cores are in-order or out-of-order
- Target clock frequency, process node, or PDK
- ISA extensions ratified (e.g., RV64IM, M-extension always assumed; F/D, V, B, K, H absent without evidence)
- Performance targets (IPC, target workload mix)
- Area, power, or energy budgets
- Memory hierarchy parameters

This document therefore proposes structures and trade-offs but cannot validate them against a concrete XH-1 baseline. All quantitative claims are labeled estimates and should be re-derived once baseline parameters are fixed.

## Abstract

The multiply/divide unit (MDU) is responsible for integer multiplication, division, and remainder operations defined in the RISC-V M-extension (and the optional Zmmul/Zihintpause subsets). For a 128-core design, the MDU is a critical area and latency bottleneck: it is one of the most area-intensive execution units in an integer datapath, and its long latency for division operations interacts with the pipeline, the register file read/write ports, and the scoreboard/issue logic. Because the MDU is also replicated 128 times, even modest per-core area or power inefficiency is multiplied across the die.

This document surveys common MDU microarchitectures (iterative subtract-and-shift, SRT radix-4/radix-8, radix-2 non-restoring, array multipliers, Wallace/Dadda trees, Booth-encoded array multipliers, combined multiply-accumulate, and pipelined iterative dividers) and analyzes their suitability for XH-1. The analysis is grounded in widely known textbook and industrial design patterns rather than any specific XH-1 measurement.

## Research Question

What is the appropriate microarchitecture for the integer multiply/divide unit in each XH-1 core, given:
1. Unknown core pipeline depth and issue order
2. 128-core replication constraint
3. Unknown frequency, area, power, and energy targets
4. The need to support RV32M/RV64M instructions: MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU (RV64 also: DIVW, DIVUW, REMW, REMUW, MULW)

Sub-questions:
- What multiplier architecture best balances latency, area, and power at unknown frequency targets?
- What divider architecture provides acceptable latency without inflating critical path or area?
- Should the MDU be pipelined, multi-cycle iterative, or a hybrid?
- How does the MDU interact with the register file, bypass network, and issue/arbitration logic?
- What is the right way to handle 64-bit × 64-bit → 128-bit (MULH family) and the W-suffixed 32-bit ops in RV64?
- What division algorithm handles signed division correctly without an extra correction cycle?

## Background

### RISC-V M-Extension Semantics

FACT: The RISC-V M-extension defines eight base multiplication instructions and eight division/remainder instructions on RV32. On RV64, the W-suffixed variants operate on 32-bit values sign- or zero-extended to 64 bits, and the unsigned W forms (DIVUW, REMUW) must round toward zero. The MULH family returns the upper 64 bits of a 128-bit product.

The M-extension operation summary (RV64 base form):
- MUL, MULW: low 64/32 bits of product, lower XLEN bits written
- MULH: signed × signed, upper XLEN bits
- MULHU: unsigned × unsigned, upper XLEN bits
- MULHSU: signed × unsigned, upper XLEN bits
- DIV/DIVU, DIVW/DIVUW: signed/unsigned quotient, round-to-zero semantics
- REM/REMU, REMW/REMUW: signed/unsigned remainder, sign follows the dividend (not the divisor), defined such that `d = (d / q) * q + (d % q)`

### Why the MDU Matters

ASSUMPTION: Most non-trivial programs perform at least some integer multiplications. Division is rarer but has high latency penalties when it stalls the pipeline. SPEC CPU integer and most server workloads have a small but non-negligible fraction of MUL/DIV (typically a few percent of dynamic instructions, with division being one to two orders of magnitude less frequent than multiplication).

### Latency Classes

The MDU typically has two distinct latency classes:
- Multiply: low latency (1–4 cycles) for low-half, higher (3–5) for high-half MULH
- Divide: long latency (4–35+ cycles depending on radix, operands, and whether signed/unsigned)

This bimodal latency profile is a key design driver: it dictates issue logic complexity, scoreboard behavior, and how the unit is replicated.

## Existing Approaches

### Multipliers

1. **Array multiplier (basic)**
   - Carry-save array of full adders. Critical path O(n) full-adder delays.
   - PROPOSAL: low-frequency, area-tolerant baseline.
   - DISADVANTAGE: poor performance at high frequency; high energy per op.

2. **Wallace tree**
   - Counter-tree reduction of partial products; final carry-propagate adder (CPA) for the final sum.
   - ADVANTAGE: logarithmic depth (O(log n)).
   - DISADVANTAGE: irregular layout, complex routing, harder to verify.

3. **Dadda tree**
   - Variant of Wallace; reduces the number of longer counters. Slightly fewer gates than Wallace for the same delay in some implementations.

4. **Booth-encoded array / tree multiplier**
   - Radix-4 (or higher) Booth recoding halves (or quarters) the number of partial products.
   - For 64-bit operands, radix-4 Booth yields 32 partial products; radix-8 yields ~22.
   - Reduces tree height, area, and dynamic capacitance at the cost of Booth-encoder logic and signed-correction terms.

5. **Carry-save multiplier with final CPA**
   - Keeps internal representation in carry-save form; one CPA at the end.
   - Common in pipelined designs.

6. **Iterative shift-and-add multiplier**
   - One cycle per bit of operand. Very small area, very long latency.
   - Inappropriate for any high-performance core; may be acceptable in tiny embedded cores.

7. **Pipelined multiplier**
   - Multiple pipeline stages; one multiplication initiated per cycle after fill.
   - Throughput = 1/cycle, but latency grows.
   - Interacts with main pipeline depth: should typically be 1–3 cycles for a 64-bit multiplier at typical embedded-class frequencies, or 2–4 cycles for high-frequency designs.

### Dividers

1. **Subtract-and-shift (radix-2 restoring)**
   - One bit of quotient per cycle; ~32 or 64 cycles for 32/64-bit division.
   - Tiny area; very long latency.

2. **Radix-2 non-restoring**
   - One bit per cycle; constant-time datapath; needs a final correction step for sign and remainder.
   - Marginally smaller than restoring; same throughput.

3. **SRT radix-4**
   - Two quotient bits per cycle; ~16/32 cycles for 32/64-bit.
   - Lookup table of redundant quotient digits; more complex than radix-2.
   - Common in high-performance cores (e.g., as discussed in Hennessy & Patterson).

4. **SRT radix-8 / radix-16**
   - 3–4 bits per cycle; ~8–17 cycles for 64-bit.
   - Larger tables; more area; more difficult to verify.
   - Used in some superscalar/OoO cores.

5. **Newton–Raphson reciprocal + multiply**
   - Iteratively refine reciprocal, then one final multiply. Fast (5–8 cycles for 64-bit).
   - High area (table lookup, multiplier reused for the final multiply). Better for OoO cores that already have a fast multiplier.

6. **Goldschmidt division**
   - Similar to Newton–Raphson; uses multiplication by precomputed factors. Same trade-off.

7. **Combined multiply/divide (e.g., shared CSA tree)**
   - Reuse the multiplier hardware as the divider datapath. Common in modern cores; saves area at the cost of tying two units' schedules together.

8. **Pipelined iterative divider**
   - Pipelined SRT or radix-N; divides one operand every cycle after fill. Latency is the depth, throughput is 1/cycle. Best for high-throughput OoO cores.

### Multiply–Accumulate

ASSUMPTION: Some cores fuse MUL+MULH or MUL+ADD into a MAC operation. RISC-V does not define such an instruction in the base ISA, but vendor extensions or a custom XH-1 extension could. Not in scope of base MDU.

## Alternative Designs

For each XH-1 core, the MDU is a candidate for one of the following microarchitectural envelopes:

### Option A: Iterative Radix-2 Combined MDU
- Multiplier: 1 cycle per bit (~32 cycles for MUL, 64 for MULH).
- Divider: 1 bit per cycle, 32/64 cycles.
- One shared CSA datapath.
- Very small area; no pipelining.
- Latency dominates; not viable for a 128-core design where even moderate per-core performance matters.

### Option B: Single-Cycle Radix-4 Booth × Array, Multi-Cycle Iterative Divider
- Multiplier: 64×64→128 in 1–2 cycles, low half in 1 cycle.
- Divider: radix-2 non-restoring, 1 bit/cycle, 32/64 cycles.
- Moderate area; multiplier is the long-path concern; divider is area-cheap.
- Reasonable for embedded-class frequencies.

### Option C: Pipelined Radix-4/8 Booth Tree, Pipelined Radix-4 SRT Divider
- Multiplier: 2–4 pipeline stages, 1 multiply per cycle after fill.
- Divider: pipelined SRT radix-4, 1 division per ~8–10 cycles.
- Larger area; better throughput; more ports on the register file, more bypass paths.
- Fits OoO or wide-issue cores.

### Option D: Pipelined Radix-8 Multiplier, Newton–Raphson Divider
- Multiplier: 2–3 stage radix-8 Booth.
- Divider: table-init + 2 NR iterations + 1 final multiply.
- Best division latency; highest area; requires sharing the multiplier between divide and multiply paths.

### Option E: Configurable Radix (low-power mode)
- Optional: throttle divider radix to save power in low-utilization scenarios.
- Not standard in commercial cores; adds verification burden.

## Comparison

Comparison axes (per core, qualitative; quantitative figures are estimates without a fixed PDK/target):

| Option | Mul latency | Mul throughput | Div latency (64-bit, uns) | Area (rel.) | Power (rel.) | Complexity | Verif. burden |
|--------|-------------|----------------|----------------------------|-------------|--------------|------------|---------------|
| A: Radix-2 iterative | ~64 cyc | 1/64 cyc | ~64 cyc | Very low | Very low | Low | Low |
| B: Radix-4 array + radix-2 div | 1–2 cyc | 1/1–2 cyc | ~64 cyc | Moderate | Moderate | Moderate | Moderate |
| C: Pipelined Booth + SRT-4 | 2–4 cyc | 1/cyc | ~16 cyc | High | High | High | High |
| D: Radix-8 + NR divider | 2–3 cyc | 1/cyc | ~5–8 cyc | Highest | Highest | Highest | Highest |
| E: Configurable | (variable) | (variable) | (variable) | High+ | High+ | Highest | Highest |

PROPOSAL: For an unknown baseline, Option B and Option C are the most defensible starting points. Option A is appropriate only for an explicitly area-constrained embedded profile. Option D is appropriate only if the core is OoO with high issue width and division latency is on the critical performance path.

## Advantages

- **Option A**: smallest area, easiest to verify, lowest power per core. Good for area-bound 128-core dies.
- **Option B**: balanced; multiplier is fast enough to be single-issue in most pipelines; divider is the weak link but small.
- **Option C**: high throughput on both mul and div; aligned with OoO or wide superscalar cores.
- **Option D**: lowest division latency; NR is a well-understood algorithm.

## Disadvantages

- **Option A**: division latency will dominate any long-latency operation count; FMA-heavy or hash-heavy code stalls. For 128 cores replicated, the per-core penalty multiplies.
- **Option B**: divider stalls the issue logic for tens of cycles; reservation stations/scoreboards must hold operands; the issue queue depth must absorb this.
- **Option C**: register file pressure: pipelined iterative divider may want to read 64-bit operands once and write 64-bit result later, but it must also accept new operands. The issue/arbitration logic must prevent structural hazards on the divider.
- **Option D**: NR requires an initial reciprocal table (1–2 KB) per core, replicated 128 times = 128–256 KB total for the table. Significant area at large scale. Must be carefully designed for low static power.

## XH-1 Considerations

Without confirmed XH-1 core order (in-order vs out-of-order), pipeline depth, or frequency target, the following sub-recommendations apply:

ASSUMPTION: XH-1 targets a balanced general-purpose or server-class workload, not a microcontroller class. A 128-core die implies a focus on throughput, not single-thread peak.

If XH-1 is in-order (per core):
- A long-latency divider stalls the pipeline for the entire division. Either the core must have deep OOO machinery at the issue stage, or division latency must be bounded.
- Option B (multi-cycle iterative divider) is more realistic than C/D.
- MULH latency matters: if it is 1–2 cycles, the bypass network from MDU to ALU must include a fast path. If 3+ cycles, a one-cycle bubble is acceptable in a shallow in-order pipeline.

If XH-1 is out-of-order:
- Division latency can be hidden by speculation if the divisor is known early.
- Option C or D is more attractive; the cost of the long-latency unit is amortized by IPC.
- Issue queue must handle the unit's variable latency.

PROPOSAL: Until core order is fixed, design the MDU to be **modular**: a radix-4 Booth multiplier (low half in 1 cycle, full 64×64 in 2 cycles) shared with a radix-2 non-restoring divider, with the divider exposed as a single multi-cycle functional unit. This is consistent with Option B and is incrementally upgradeable to Option C if a pipelined divider is added later.

## 128-Core Scalability

Each MDU is replicated 128 times. Scalability concerns:

- **Area**: The MDU is one of the larger non-frontend units. If the multiplier alone is ~0.05–0.15 mm² and the divider ~0.02–0.05 mm² at a modern node (estimate; depends on process and frequency), 128× MDU area is 9–25 mm² total (estimate). This is significant but not dominant compared to caches/interconnect.
- **Power**: Multipliers and especially SRT dividers are dynamic-power-heavy during computation. With 128 cores potentially issuing MUL/DIV, peak power in the MDU array may be a non-trivial slice of the die's power budget (INSUFFICIENT EVIDENCE for a precise fraction).
- **Clock distribution**: A long combinational path through a tree multiplier is a clock-tree risk. A pipelined multiplier breaks the path but adds register area and clock load.
- **Verification**: 128 identical units are verified in parallel; this is favorable. The MDU verification focus should be on **mathematical correctness** of division (signed, round-to-zero, edge cases) rather than replication.
- **Yield**: A defect in the MDU logic is replicated 128×, so its fault coverage must be very high. Recommend formal verification of the divider's quotient/remainder invariants.

PROPOSAL: Keep the MDU small and well-isolated. Do not let it become the critical path that dictates the global clock period. If the only way to meet timing is to pipeline the multiplier, do so; the cost is one cycle of latency and one extra write port on the integer register file.

## Performance Considerations

- **MUL throughput**: At 1 multiply/cycle per core (pipelined), 128 cores can issue up to 128 multiplies per cycle across the die. Aggregate multiply bandwidth is high; the more pressing concern is per-core latency hiding.
- **MULH throughput**: MULH uses a 64×64→128 multiplier. On RV64, a 128-bit result requires either a wider datapath or two cycle reuse of a 64-bit multiplier. The former doubles MDU area; the latter doubles MULH latency. PROPOSAL: prefer a true 64×64→128 datapath (single cycle) since the alternative doubles register-file read pressure.
- **DIV throughput**: 1 per 16 cycles (SRT-4) or 1 per 64 cycles (radix-2) per core. Across 128 cores, average DIV throughput is high in aggregate but per-thread latency is the user-visible metric.
- **MUL–MULH coupling**: A common implementation is to compute the full 128-bit product once, then take either low or high half. This is a clean reuse strategy.
- **DIV–REM coupling**: In non-restoring or SRT, quotient and remainder come out together. The MDU can expose both at the same latency. RISC-V requires both with consistent semantics.
- **W-suffixed ops in RV64**: Operands are sign- or zero-extended from 32 to 64. The MDU can simply perform 64-bit ops with the upper 32 bits forced to zero/sign-extended. No special hardware is needed if the register file read provides the correct extension (which the standard RF does on RISC-V).

## Area Considerations

Estimated relative area, normalized to a baseline radix-2 iterative combined MDU (very rough, no PDK):

| Design | Relative area (rough) |
|--------|------------------------|
| Radix-2 iterative (A) | 1.0× |
| Radix-4 array + radix-2 div (B) | ~3–5× |
| Pipelined radix-4 + SRT-4 (C) | ~6–10× |
| Radix-8 + NR divider (D) | ~8–12× |

These are estimates. Actual area depends heavily on:
- Multiplier radix and Booth encoding depth
- Whether CSA is retained to the final CPA
- Divider's choice of redundant representation and on-the-fly quotient conversion
- Pipeline register count
- Whether a 64×64→128 result is held in a single 128-bit register or two 64-bit latches

PROPOSAL: For a 128-core design, choose the smallest MDU that meets per-core latency targets. Area scaling is multiplicative across cores; a 10× MDU is 10× cost across the die.

## Power and Energy Considerations

- **Static power**: A large MDU (Option C/D) has more leakage. Across 128 cores, leakage adds up. Clock-gating the MDU when no MUL/DIV is in flight is essentially mandatory; consider also input-gating operand muxes to prevent toggling.
- **Dynamic power**: A pipelined multiplier toggles every cycle when active. A non-pipelined iterative multiplier toggles only during active cycles but for longer. Per-operation energy is generally lower for the non-pipelined option at low utilization.
- **NR divider**: The initial reciprocal table lookups can be gated; iteration multiplies are power-hungry but brief.
- **Energy per op**: For low-utilization workloads, smaller/iterative MDUs are more energy-efficient per operation. For high-utilization workloads, pipelined MDUs amortize the per-op energy.

INSUFFICIENT EVIDENCE to recommend a specific energy target without workload mix and frequency data.

## Implementation Considerations

- **Operand alignment**: The MDU takes two XLEN-bit operands and produces either XLEN or 2*XLEN bits. The result muxes must be carefully timed; the 128-bit result for MULH is on the critical path to the register file write port.
- **Bypass network**: MUL result must be bypassable to dependent operations. MUL→ADD, MUL→MUL, MUL→branch (for select-on-result patterns) all need bypass paths.
- **Scoreboard / wakeup**: In an OoO core, the MDU must signal completion to wake up dependent instructions. Variable latency (mul vs div) requires tagged completion events.
- **Flush behavior**: On branch mispredict or exception, in-flight MDU operations must be killed. Pipelined iterative units must be safely drainable.
- **Special values**: DIV/REM with divisor=0 raises a divide-by-zero exception; the quotient register is written with -1 (signed) or 2^XLEN-1 (unsigned), remainder with the dividend. The MDU must produce these values even on the exception path. The simplest implementation: detect divisor=0, force the result muxes, raise the exception flag.
- **Overflow**: Signed DIV/REM is defined to overflow when the dividend is -2^(XLEN-1) and the divisor is -1; quotient is -2^(XLEN-1), remainder is 0. This is a known corner case.
- **Sign handling for non-restoring/SRT**: The quotient bits come out in a redundant form; the on-the-fly conversion (or final correction) must apply the sign correction. This is a well-known source of bugs.
- **W-suffixed ops**: The result of MULW is the low 32 bits sign-extended to 64. The MDU can compute the full 64-bit product and just route the low 32 bits with sign-extension, or compute a 32×32→64 product. The former is simpler and reuses the 64-bit datapath; recommended.

## Verification Considerations

- **Mathematical correctness**: Division is a top source of MDU bugs across the industry. Strongly recommend:
  - Random testing with a slow software reference (e.g., a software DIV routine) across the full input space, including all corner cases: 0 divisor, -1 divisor, INT_MIN dividend, INT_MIN/INT_MIN, INT_MIN/-1, alternating bit patterns.
  - Formal verification of quotient/remainder invariants (`q*d + r == n` and `|r| < |d|` and sign-of-r-follows-n).
- **Self-consistency**: For every (a, b), the MDU must satisfy `MDU_DIV(a, b) * b + MDU_REM(a, b) == a` (with sign handling).
- **MULH/MUL consistency**: For signed × signed, `MULHSU(a, b)` and `MULHU(|a|, b)` (with sign correction) must agree.
- **W-op consistency**: DIVW(a, b) should equal sign-extend32(DIV(sign-extend32(a), sign-extend32(b))). Random differential testing.
- **Coverage**: Target 100% code and toggle coverage on the MDU; FSM coverage on the divider state machine.
- **Cross-core**: A defect in the MDU RTL hits 128 instances. The verification cost is paid once but the fault-coverage target must be high.
- **Latency timing**: Verify the latency contract (1/2/N cycles) at the interface level so that downstream issue/retire logic is correct.

## Software Considerations

- **Compiler**: GCC/LLVM emit MUL/DIV/REM for the corresponding C operators. Idiomatic C rarely exposes division; the issue is more around hash functions, big-integer arithmetic, and base conversions.
- **Libraries**: libgcc / compiler-rt provide software fallbacks for division if the hardware path is unavailable. The MDU should match the ABI (M-extension) expectations; otherwise the OS or runtime must emulate.
- **Constant division**: A compiler strength-reduction pass converts division by a power of 2 into a shift. For non-power-of-2 constants, some compilers (e.g., GCC) can emit a multiply-by-reciprocal sequence if the hardware division is too slow. This affects what hardware division latency is "good enough".
- **Builtins**: __builtin_mul_overflow etc. on GCC/Clang map to MUL/branch sequences. Performance of these depends on MDU latency.
- **OS context switch**: MDU has no architectural state; context switch does not interact with the MDU.
- **Vector / SIMD**: RISC-V V-extension is out of scope unless XH-1 adopts it. If V is added later, the MDU does not change but vector multiply-accumulate units (independent hardware) will.

## Recommendation

PROPOSAL: Adopt a design in the **Option B** family for the initial XH-1 MDU:
- **Multiplier**: 64×64→128-bit radix-4 Booth-encoded CSA tree, single-cycle low-half result, two-cycle high-half (MULH) result, both written to the register file in 2 cycles total. The CSA tree is followed by a final CPA. 64×64 partial product count is 32 (radix-4), manageable for a single combinational stage at moderate frequency. If the critical path is too long for the target clock, add a single pipeline register between CSA tree and CPA; this becomes Option C-lite.
- **Divider**: Radix-2 non-restoring, 64 cycles for RV64 / 32 cycles for RV32 / 32 cycles for W-ops. Constant-time datapath; quotient and remainder produced in the same iteration. Final sign-correction and round-to-zero applied in the last cycle.
- **Shared datapath**: The CSA tree and partial-product reduction are reused where possible. The divider is otherwise independent of the multiplier to keep verification simple.
- **Latency contract**: MUL/MULW = 1 cycle; MULH family = 2 cycles; DIV/DIVU/REM/REMU and W-suffixed variants = N+1 cycles (where N is operand width) plus a final correction cycle, ≈ 33/65 cycles for RV32/RV64. The scoreboard/issue logic is designed against these numbers.
- **Special-case handling**: DIV/REM by 0 and overflow paths produce architecturally defined result values and raise exceptions. The MDU has a small input-gate to zero-out internal state when the operation completes early on a trap.

This recommendation is provisional and is conditional on:
- Confirmation of the core order (in-order vs out-of-order). For OoO, re-evaluate toward Option C.
- Confirmation of the target frequency. If a higher frequency is set, the multiplier may need to be pipelined.
- Confirmation of the area budget. If the budget is tight, fall back toward Option A's divider.

## Confidence

- **High confidence**: The M-extension semantics, the standard algorithms (radix-2 non-restoring, radix-4 Booth, SRT-4), the corner cases (div by 0, INT_MIN/-1, sign of remainder), the general area/latency trade-off directions.
- **Medium confidence**: The relative-area and relative-power tables; they are estimates and depend on the unknown PDK and frequency.
- **Low confidence**: Any specific cycle-count or area number for XH-1; no XH-1 measurements are available.
- **Very low confidence**: Recommendations about pipelined vs non-pipelined without knowing core order and frequency.

## Open Questions

1. Is the XH-1 core in-order or out-of-order? (Foundational; drives all MDU trade-offs.)
2. What is the target pipeline depth and clock frequency? (Drives multiplier pipelining decision.)
3. Is the XH-1 ISA RV32 or RV64, and which extensions are ratified?
4. What is the per-core area budget for execution units (ALU + MDU + branch + LSU)?
5. What is the target workload mix? (Division-heavy workloads change the divider trade-off.)
6. Is there a custom XH-1 extension that would change the MDU's responsibilities (e.g., a fused MAC)?
7. Does XH-1 adopt the V-extension? (If yes, the scalar MDU stays as is, but a vector MAC unit is needed separately.)
8. What is the static-power budget at the target process node? (Affects whether large array multipliers are acceptable.)
9. Is the MDU expected to be fault-tolerant or SECDED-protected? (Affects pipeline register design.)
10. Does the issue/arbitration logic treat the MDU as a single multi-cycle unit, or as separate mul and div functional units? (Affects which microarchitecture is compatible with the rest of the core.)

## Sources

INSUFFICIENT EVIDENCE for XH-1-specific sources; the design space and algorithms referenced here are textbook material:

- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (general sections on multiplier/divider design; editions vary; no specific edition cited here).
- RISC-V *Unprivileged ISA Specification* (M-extension semantics, division corner cases, W-suffixed ops on RV64). Publicly available at riscv.org; specific version numbers and page references are not cited here.
- Standard references on SRT division and Booth recoding are not cited specifically; the algorithms are well-known.

No XH-1 measurements, no third-party benchmarks, and no external papers are cited because none are available in the repository context. Any quantitative claim in this document is an estimate and should be re-derived when the XH-1 baseline parameters are fixed.
