
         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         
{"id":"gen-1787681642-l0WONDu5geIHnWZXFUrN","object":"chat.completion","created":1787681642,"model":"minimax/minimax-m3:free","provider":"GMICloud","system_fingerprint":null,"service_tier":null,"choices":[{"index":0,"logprobs":null,"finish_reason":"stop","native_finish_reason":"stop","message":{"role":"assistant","content":"# XH-1 Multiply/Divide Unit (MDU) Research\n\n## Status\n\nStub document. Repository context for XH-1 does not establish:\n- Pipeline depth of the base integer pipeline\n- Whether cores are in-order or out-of-order\n- Target clock frequency, process node, or PDK\n- ISA extensions ratified (e.g., RV64IM, M-extension always assumed; F/D, V, B, K, H absent without evidence)\n- Performance targets (IPC, target workload mix)\n- Area, power, or energy budgets\n- Memory hierarchy parameters\n\nThis 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.\n\n## Abstract\n\nThe 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.\n\nThis 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.\n\n## Research Question\n\nWhat is the appropriate microarchitecture for the integer multiply/divide unit in each XH-1 core, given:\n1. Unknown core pipeline depth and issue order\n2. 128-core replication constraint\n3. Unknown frequency, area, power, and energy targets\n4. The need to support RV32M/RV64M instructions: MUL, MULH, MULHU, MULHSU, DIV, DIVU, REM, REMU (RV64 also: DIVW, DIVUW, REMW, REMUW, MULW)\n\nSub-questions:\n- What multiplier architecture best balances latency, area, and power at unknown frequency targets?\n- What divider architecture provides acceptable latency without inflating critical path or area?\n- Should the MDU be pipelined, multi-cycle iterative, or a hybrid?\n- How does the MDU interact with the register file, bypass network, and issue/arbitration logic?\n- What is the right way to handle 64-bit × 64-bit → 128-bit (MULH family) and the W-suffixed 32-bit ops in RV64?\n- What division algorithm handles signed division correctly without an extra correction cycle?\n\n## Background\n\n### RISC-V M-Extension Semantics\n\nFACT: 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.\n\nThe M-extension operation summary (RV64 base form):\n- MUL, MULW: low 64/32 bits of product, lower XLEN bits written\n- MULH: signed × signed, upper XLEN bits\n- MULHU: unsigned × unsigned, upper XLEN bits\n- MULHSU: signed × unsigned, upper XLEN bits\n- DIV/DIVU, DIVW/DIVUW: signed/unsigned quotient, round-to-zero semantics\n- REM/REMU, REMW/REMUW: signed/unsigned remainder, sign follows the dividend (not the divisor), defined such that `d = (d / q) * q + (d % q)`\n\n### Why the MDU Matters\n\nASSUMPTION: 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).\n\n### Latency Classes\n\nThe MDU typically has two distinct latency classes:\n- Multiply: low latency (1–4 cycles) for low-half, higher (3–5) for high-half MULH\n- Divide: long latency (4–35+ cycles depending on radix, operands, and whether signed/unsigned)\n\nThis bimodal latency profile is a key design driver: it dictates issue logic complexity, scoreboard behavior, and how the unit is replicated.\n\n## Existing Approaches\n\n### Multipliers\n\n1. **Array multiplier (basic)**\n   - Carry-save array of full adders. Critical path O(n) full-adder delays.\n   - PROPOSAL: low-frequency, area-tolerant baseline.\n   - DISADVANTAGE: poor performance at high frequency; high energy per op.\n\n2. **Wallace tree**\n   - Counter-tree reduction of partial products; final carry-propagate adder (CPA) for the final sum.\n   - ADVANTAGE: logarithmic depth (O(log n)).\n   - DISADVANTAGE: irregular layout, complex routing, harder to verify.\n\n3. **Dadda tree**\n   - Variant of Wallace; reduces the number of longer counters. Slightly fewer gates than Wallace for the same delay in some implementations.\n\n4. **Booth-encoded array / tree multiplier**\n   - Radix-4 (or higher) Booth recoding halves (or quarters) the number of partial products.\n   - For 64-bit operands, radix-4 Booth yields 32 partial products; radix-8 yields ~22.\n   - Reduces tree height, area, and dynamic capacitance at the cost of Booth-encoder logic and signed-correction terms.\n\n5. **Carry-save multiplier with final CPA**\n   - Keeps internal representation in carry-save form; one CPA at the end.\n   - Common in pipelined designs.\n\n6. **Iterative shift-and-add multiplier**\n   - One cycle per bit of operand. Very small area, very long latency.\n   - Inappropriate for any high-performance core; may be acceptable in tiny embedded cores.\n\n7. **Pipelined multiplier**\n   - Multiple pipeline stages; one multiplication initiated per cycle after fill.\n   - Throughput = 1/cycle, but latency grows.\n   - 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.\n\n### Dividers\n\n1. **Subtract-and-shift (radix-2 restoring)**\n   - One bit of quotient per cycle; ~32 or 64 cycles for 32/64-bit division.\n   - Tiny area; very long latency.\n\n2. **Radix-2 non-restoring**\n   - One bit per cycle; constant-time datapath; needs a final correction step for sign and remainder.\n   - Marginally smaller than restoring; same throughput.\n\n3. **SRT radix-4**\n   - Two quotient bits per cycle; ~16/32 cycles for 32/64-bit.\n   - Lookup table of redundant quotient digits; more complex than radix-2.\n   - Common in high-performance cores (e.g., as discussed in Hennessy & Patterson).\n\n4. **SRT radix-8 / radix-16**\n   - 3–4 bits per cycle; ~8–17 cycles for 64-bit.\n   - Larger tables; more area; more difficult to verify.\n   - Used in some superscalar/OoO cores.\n\n5. **Newton–Raphson reciprocal + multiply**\n   - Iteratively refine reciprocal, then one final multiply. Fast (5–8 cycles for 64-bit).\n   - High area (table lookup, multiplier reused for the final multiply). Better for OoO cores that already have a fast multiplier.\n\n6. **Goldschmidt division**\n   - Similar to Newton–Raphson; uses multiplication by precomputed factors. Same trade-off.\n\n7. **Combined multiply/divide (e.g., shared CSA tree)**\n   - Reuse the multiplier hardware as the divider datapath. Common in modern cores; saves area at the cost of tying two units' schedules together.\n\n8. **Pipelined iterative divider**\n   - 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.\n\n### Multiply–Accumulate\n\nASSUMPTION: 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.\n\n## Alternative Designs\n\nFor each XH-1 core, the MDU is a candidate for one of the following microarchitectural envelopes:\n\n### Option A: Iterative Radix-2 Combined MDU\n- Multiplier: 1 cycle per bit (~32 cycles for MUL, 64 for MULH).\n- Divider: 1 bit per cycle, 32/64 cycles.\n- One shared CSA datapath.\n- Very small area; no pipelining.\n- Latency dominates; not viable for a 128-core design where even moderate per-core performance matters.\n\n### Option B: Single-Cycle Radix-4 Booth × Array, Multi-Cycle Iterative Divider\n- Multiplier: 64×64→128 in 1–2 cycles, low half in 1 cycle.\n- Divider: radix-2 non-restoring, 1 bit/cycle, 32/64 cycles.\n- Moderate area; multiplier is the long-path concern; divider is area-cheap.\n- Reasonable for embedded-class frequencies.\n\n### Option C: Pipelined Radix-4/8 Booth Tree, Pipelined Radix-4 SRT Divider\n- Multiplier: 2–4 pipeline stages, 1 multiply per cycle after fill.\n- Divider: pipelined SRT radix-4, 1 division per ~8–10 cycles.\n- Larger area; better throughput; more ports on the register file, more bypass paths.\n- Fits OoO or wide-issue cores.\n\n### Option D: Pipelined Radix-8 Multiplier, Newton–Raphson Divider\n- Multiplier: 2–3 stage radix-8 Booth.\n- Divider: table-init + 2 NR iterations + 1 final multiply.\n- Best division latency; highest area; requires sharing the multiplier between divide and multiply paths.\n\n### Option E: Configurable Radix (low-power mode)\n- Optional: throttle divider radix to save power in low-utilization scenarios.\n- Not standard in commercial cores; adds verification burden.\n\n## Comparison\n\nComparison axes (per core, qualitative; quantitative figures are estimates without a fixed PDK/target):\n\n| Option | Mul latency | Mul throughput | Div latency (64-bit, uns) | Area (rel.) | Power (rel.) | Complexity | Verif. burden |\n|--------|-------------|----------------|----------------------------|-------------|--------------|------------|---------------|\n| A: Radix-2 iterative | ~64 cyc | 1/64 cyc | ~64 cyc | Very low | Very low | Low | Low |\n| B: Radix-4 array + radix-2 div | 1–2 cyc | 1/1–2 cyc | ~64 cyc | Moderate | Moderate | Moderate | Moderate |\n| C: Pipelined Booth + SRT-4 | 2–4 cyc | 1/cyc | ~16 cyc | High | High | High | High |\n| D: Radix-8 + NR divider | 2–3 cyc | 1/cyc | ~5–8 cyc | Highest | Highest | Highest | Highest |\n| E: Configurable | (variable) | (variable) | (variable) | High+ | High+ | Highest | Highest |\n\nPROPOSAL: 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.\n\n## Advantages\n\n- **Option A**: smallest area, easiest to verify, lowest power per core. Good for area-bound 128-core dies.\n- **Option B**: balanced; multiplier is fast enough to be single-issue in most pipelines; divider is the weak link but small.\n- **Option C**: high throughput on both mul and div; aligned with OoO or wide superscalar cores.\n- **Option D**: lowest division latency; NR is a well-understood algorithm.\n\n## Disadvantages\n\n- **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.\n- **Option B**: divider stalls the issue logic for tens of cycles; reservation stations/scoreboards must hold operands; the issue queue depth must absorb this.\n- **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.\n- **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.\n\n## XH-1 Considerations\n\nWithout confirmed XH-1 core order (in-order vs out-of-order), pipeline depth, or frequency target, the following sub-recommendations apply:\n\nASSUMPTION: 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.\n\nIf XH-1 is in-order (per core):\n- 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.\n- Option B (multi-cycle iterative divider) is more realistic than C/D.\n- 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.\n\nIf XH-1 is out-of-order:\n- Division latency can be hidden by speculation if the divisor is known early.\n- Option C or D is more attractive; the cost of the long-latency unit is amortized by IPC.\n- Issue queue must handle the unit's variable latency.\n\nPROPOSAL: 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.\n\n## 128-Core Scalability\n\nEach MDU is replicated 128 times. Scalability concerns:\n\n- **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.\n- **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).\n- **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.\n- **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.\n- **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.\n\nPROPOSAL: 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.\n\n## Performance Considerations\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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).\n\n## Area Considerations\n\nEstimated relative area, normalized to a baseline radix-2 iterative combined MDU (very rough, no PDK):\n\n| Design | Relative area (rough) |\n|--------|------------------------|\n| Radix-2 iterative (A) | 1.0× |\n| Radix-4 array + radix-2 div (B) | ~3–5× |\n| Pipelined radix-4 + SRT-4 (C) | ~6–10× |\n| Radix-8 + NR divider (D) | ~8–12× |\n\nThese are estimates. Actual area depends heavily on:\n- Multiplier radix and Booth encoding depth\n- Whether CSA is retained to the final CPA\n- Divider's choice of redundant representation and on-the-fly quotient conversion\n- Pipeline register count\n- Whether a 64×64→128 result is held in a single 128-bit register or two 64-bit latches\n\nPROPOSAL: 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.\n\n## Power and Energy Considerations\n\n- **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.\n- **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.\n- **NR divider**: The initial reciprocal table lookups can be gated; iteration multiplies are power-hungry but brief.\n- **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.\n\nINSUFFICIENT EVIDENCE to recommend a specific energy target without workload mix and frequency data.\n\n## Implementation Considerations\n\n- **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.\n- **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.\n- **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.\n- **Flush behavior**: On branch mispredict or exception, in-flight MDU operations must be killed. Pipelined iterative units must be safely drainable.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Verification Considerations\n\n- **Mathematical correctness**: Division is a top source of MDU bugs across the industry. Strongly recommend:\n  - 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.\n  - Formal verification of quotient/remainder invariants (`q*d + r == n` and `|r| < |d|` and sign-of-r-follows-n).\n- **Self-consistency**: For every (a, b), the MDU must satisfy `MDU_DIV(a, b) * b + MDU_REM(a, b) == a` (with sign handling).\n- **MULH/MUL consistency**: For signed × signed, `MULHSU(a, b)` and `MULHU(|a|, b)` (with sign correction) must agree.\n- **W-op consistency**: DIVW(a, b) should equal sign-extend32(DIV(sign-extend32(a), sign-extend32(b))). Random differential testing.\n- **Coverage**: Target 100% code and toggle coverage on the MDU; FSM coverage on the divider state machine.\n- **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.\n- **Latency timing**: Verify the latency contract (1/2/N cycles) at the interface level so that downstream issue/retire logic is correct.\n\n## Software Considerations\n\n- **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.\n- **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.\n- **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\".\n- **Builtins**: __builtin_mul_overflow etc. on GCC/Clang map to MUL/branch sequences. Performance of these depends on MDU latency.\n- **OS context switch**: MDU has no architectural state; context switch does not interact with the MDU.\n- **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.\n\n## Recommendation\n\nPROPOSAL: Adopt a design in the **Option B** family for the initial XH-1 MDU:\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nThis recommendation is provisional and is conditional on:\n- Confirmation of the core order (in-order vs out-of-order). For OoO, re-evaluate toward Option C.\n- Confirmation of the target frequency. If a higher frequency is set, the multiplier may need to be pipelined.\n- Confirmation of the area budget. If the budget is tight, fall back toward Option A's divider.\n\n## Confidence\n\n- **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.\n- **Medium confidence**: The relative-area and relative-power tables; they are estimates and depend on the unknown PDK and frequency.\n- **Low confidence**: Any specific cycle-count or area number for XH-1; no XH-1 measurements are available.\n- **Very low confidence**: Recommendations about pipelined vs non-pipelined without knowing core order and frequency.\n\n## Open Questions\n\n1. Is the XH-1 core in-order or out-of-order? (Foundational; drives all MDU trade-offs.)\n2. What is the target pipeline depth and clock frequency? (Drives multiplier pipelining decision.)\n3. Is the XH-1 ISA RV32 or RV64, and which extensions are ratified?\n4. What is the per-core area budget for execution units (ALU + MDU + branch + LSU)?\n5. What is the target workload mix? (Division-heavy workloads change the divider trade-off.)\n6. Is there a custom XH-1 extension that would change the MDU's responsibilities (e.g., a fused MAC)?\n7. Does XH-1 adopt the V-extension? (If yes, the scalar MDU stays as is, but a vector MAC unit is needed separately.)\n8. What is the static-power budget at the target process node? (Affects whether large array multipliers are acceptable.)\n9. Is the MDU expected to be fault-tolerant or SECDED-protected? (Affects pipeline register design.)\n10. 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.)\n\n## Sources\n\nINSUFFICIENT EVIDENCE for XH-1-specific sources; the design space and algorithms referenced here are textbook material:\n\n- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (general sections on multiplier/divider design; editions vary; no specific edition cited here).\n- 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.\n- Standard references on SRT division and Booth recoding are not cited specifically; the algorithms are well-known.\n\nNo 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.","refusal":null,"reasoning":null}}],"usage":{"prompt_tokens":706,"completion_tokens":6519,"total_tokens":7225,"cost":0,"is_byok":false,"prompt_tokens_details":{"cached_tokens":691,"cache_write_tokens":0,"audio_tokens":0,"video_tokens":0},"cost_details":{"upstream_inference_cost":0,"upstream_inference_prompt_cost":0,"upstream_inference_completions_cost":0},"completion_tokens_details":{"reasoning_tokens":0,"image_tokens":0,"audio_tokens":0}}}