riscvcxh1/xh1-research-fork
1
0
Fork 0
mirror of https://github.com/allexanderbergmns/xh1-research.git synced 2026-08-27 15:47:03 +00:00
Code Issues 5 Packages Projects Releases Wiki Activity

setup

Browse Source
This commit is contained in:
riscvcxh1
2026-08-25 20:22:11 +02:00
parent fbc47bd4f4
commit 221a2df0ac
52 changed files with 6798 additions and 611 deletions
Download Patch File Download Diff File Expand all files Collapse all files
research/.xh1/runs/20260825T181153Z/attempts
+2
View File
@@ -0,0 +1,2 @@
2026-08-25T18:13:01Z research/03-core-design/mul-div-unit.md 1 research completed
2026-08-25T18:13:16Z research/03-core-design/mul-div-unit.md 1 review api-failure
research/.xh1/runs/20260825T181153Z/completed
View File
research/.xh1/runs/20260825T181153Z/failed
+1
View File
@@ -0,0 +1 @@
research/03-core-design/mul-div-unit.md
research/.xh1/runs/20260825T181153Z/research_03-core-design_mul-div-unit.md.current.md
+248
View File
@@ -0,0 +1,248 @@
# XH-1 Multiply/Divide Unit Research
## Topic
`research/03-core-design/mul-div-unit.md` — design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core, with particular attention to how this unit is replicated across 128 cores.
## Status
**Stub.** The current document contains only the placeholder `SOON`. This research document establishes the design-space analysis required to populate that stub. No committed micro-architecture exists yet.
## Abstract
The integer multiply/divide unit (MDU) implements the RISC-V `M` extension (and optionally `B`, `K`, or vector variants) within each XH-1 core. This document surveys MDU micro-architectures — array multipliers, Wallace/Dadda trees, Booth-recoded multipliers, iterative shift-add multipliers, radix-2/radix-4/radix-8 dividers, and higher-radix/SRT dividers — and evaluates them against the XH-1 design constraints: per-core area and power budgets, latency targets, throughput requirements, verification complexity, and the multiplicative cost of replicating the unit across 128 cores. The analysis concludes that a parameterized iterative shift-add MDU with optional early-exit and a modest dedicated array multiplier is the most defensible starting point, but flags the assumption-laden nature of the recommendation.
## Research Question
> What MDU micro-architecture best satisfies the XH-1 per-core area, power, latency, and throughput targets while remaining tractable to verify, to replicate 128 times, and to expose to the RISC-V ISA and toolchain?
Sub-questions:
1. Should multiplication and division share datapath hardware or be independent units?
2. What latency is required to avoid becoming a structural hazard in the XH-1 pipeline?
3. What is the minimum-radix divider that meets the per-core throughput target?
4. Does the cost of a fast array multiplier (e.g., radix-4 Booth with Wallace tree) justify its latency benefit over an iterative shift-add design replicated 128 times?
5. Which RISC-V extensions must be supported in v1 (`M` only vs. `M+B` vs. `M+B+K`)?
## Background
### RISC-V `M` Extension Semantics (FACT)
The RISC-V `M` extension defines the following operations on the `XLEN`-bit registers (RV64 assumed for XH-1 unless stated otherwise):
- `MUL`, `MULH`, `MULHSU`, `MULHU` — 64×64 → lower-64 / upper-64 signed/unsigned products.
- `DIV`, `DIVU`, `REM`, `REMU` — signed/unsigned division and remainder, 64÷64 → 64 quotient and 64 remainder.
- `MULW`, `DIVW`, `DIVUW`, `REMW`, `REMWU` — 32-bit operations that sign-extend the 32-bit result to 64 bits.
Corner cases the MDU must handle per the ISA:
- Division by zero returns `0xFFFFFFFFFFFFFFFF` (quotient) and the dividend (remainder) for unsigned, and `-1` / dividend for signed.
- The most-negative signed integer (`0x8000…`) divided by `-1` must return the dividend as quotient and `0` as remainder; this traps on x86 but is non-trapping in RISC-V.
- Overflow behavior is *only* defined for signed division/remainder by `-1`; no other overflow is architecturally visible.
### Latency vs. Throughput (FACT)
- A 64×64 → 128-bit full multiplication requires at minimum 128 partial-product rows for a non-Booth radix-2 design, ~64 rows for radix-4 Booth, ~43 rows for radix-8 Booth.
- Bit-serial shift-add multiplication completes in 64 cycles.
- Restoring division completes in 64 cycles; non-restoring in 32–64 cycles depending on the normalization of the remainder; higher-radix SRT dividers in O(log radix(N)) cycles but with substantially larger area.
### RISC-V `B` and `K` Extensions (FACT, partial)
- `B` (Bitmanip) under RV64 1.0.0 includes `MULH`, `MULHU`, `MULHSU` already in `M`, and adds rev-8.0/1.0 bitmanip groups such as `CLMUL`, `CLMULH`, `CLMULR`, `MIN[U]`, `MAX[U]`, `ANDN`, `ORN`, `XNOR`, `SEXT.B/H/W`, and the `Zba`/`Zbb`/`Zbs` sub-extensions.
- `K` (cryptography) adds `Zkn` (AES/SHA) and is not in scope for the base MDU.
- `Zmmul` provides multiply-only and is a common power-optimized subset of `M`.
## Existing Approaches
| Approach | Latency (typ., 64-bit) | Area (relative) | Throughput | Notes |
|---|---|---|---|---|
| Iterative shift-add multiplier | 64 cycles | 1× | 1 / 64 cycles | Smallest area; low throughput |
| Radix-4 Booth + carry-save | ~17 cycles | ~4–6× | 1 / ~17 | Common in embedded OoO |
| Radix-4 Booth + Wallace tree + final CPA | ~3–5 cycles | ~8–12× | 1 / cycle (pipelined) | Used in high-perf cores |
| Pipelined array multiplier (k stages) | k cycles | large | 1 / cycle | Throughput-bound, area-heavy |
| Radix-2 non-restoring divider | 32–64 cycles | 1× (shared with MUL possible) | 1 / 32–64 | Low area |
| Radix-4 SRT divider | ~16 cycles | ~3–5× | 1 / ~16 | Moderate |
| Radix-8/16 SRT divider | ~8–10 cycles | large | 1 / ~10 | High-end OoO |
| Combinational 64×64 array (no pipelining) | ~10+ gate delays | very large | 1 / many cycles | Impractical |
| Shared MUL/DIV datapath (Liang/Montusiewicz style) | variable | ~1.5× single-function | variable | Saves ~30–40% area at the cost of CPI |
(Quantitative magnitudes in this table are estimates from public micro-architecture literature; values vary considerably with cell library, target frequency, and pipeline integration. See Sources.)
## Alternative Designs
### A. Pure Iterative Shift-Add MDU
A single 128-bit accumulator-based datapath. Each cycle shifts the multiplicand and adds if the corresponding multiplier bit is set, or performs a non-restoring division step. The same hardware services both MUL and DIV.
### B. Pipelined Iterative MDU
Same datapath as A, but cut into N pipeline stages (commonly 2 or 4) to allow clock-frequency scaling. Issues per-cycle throughput remains 1 op / N cycles for a single operand width.
### C. Dedicated Array Multiplier + Iterative Divider
A small radix-4 Booth/Wallace multiplier (lower 64 bits in 3–4 cycles) and a separate radix-2 or radix-4 non-restoring divider. Two independent units that can operate concurrently.
### D. Shared Pipelined Radix-4 MDU
A single radix-4 Booth partial-product generator feeding a shared CSA tree, with a reconfigurable final-stage adder and a small division state machine. Latency: ~5–8 cycles for MUL, ~16 for DIV.
### E. Pipelined High-Performance MDU (Wallace/Wallace + SRT-4)
Multi-cycle but pipelined radix-4 multiplier and SRT-4 divider. Both deliver 1 op/cycle throughput once steady-state. Area dominates the integer datapath.
### F. `Zmmul`-Only MUL, External DIV Trap
Implement MUL in hardware (small array or iterative), trap DIV/REM to a software handler. The privileged trap path is fast on XH-1 only if the software model tolerates it; SPECint and most server workloads execute division frequently enough that this is usually unacceptable.
### G. Compressed / Shared Across Cores
A single physical MDU shared by N cores via a NoC-side arbiter. Removes per-core area cost but introduces structural contention; this is generally considered an *adverse* design for a 128-core tiled machine.
## Comparison
| Design | Area/cell count (est.) | Cycles/op MUL | Cycles/op DIV | Throughput (steady) | Verif. complexity | Replicated ×128 cost | Power/cores at 1 GHz (est.) |
|---|---|---|---|---|---|---|---|
| A. Iterative | 1.0× | 64 | 32–64 | 1/64 | Low | low | low |
| B. Pipelined iter. (2-stage) | ~1.1× | 32 | 16–32 | 1/32 | Low–Medium | low | low–medium |
| C. Array MUL + iter DIV | ~6–8× | 3–5 | 32–64 | 1/cycle (MUL) | Medium | high | medium–high |
| D. Shared radix-4 | ~4–6× | 5–8 | 16 | 1/cycle (MUL) | Medium–High | medium | medium |
| E. Pipelined Wallace + SRT-4 | ~12–20× | 1/cycle | 1/cycle | 1/cycle | High | very high | high |
| F. Zmmul + trap | ~1–2× | variable | trap | low | Lowest | lowest | lowest |
| G. Shared across cores | 1/N per core | +NoC latency | +NoC latency | contended | High (coherency) | lowest in area, highest in latency | lowest in static power, high in dynamic on miss |
(All non-FACT values are PROPOSAL/ESTIMATE pending the XH-1 cell library and frequency target.)
## Advantages
- **A (iterative):** lowest area and verification cost; trivially replicated ×128; deterministic timing; well-suited to in-order pipelines with a single MDU reservation station.
- **C (array + iter):** low MUL latency benefits compiled code with tight multiply chains (CRC, hashing, address computation); the iterative divider keeps area under control.
- **D (shared radix-4):** good balance; single unit means fewer ports on the issue queue, simpler back-pressure, easier to verify than E.
- **E (pipelined):** removes MDU as a critical path for high-frequency operation; appropriate only if XH-1 is a high-frequency out-of-order core.
- **F (Zmmul + trap):** smallest possible die; useful if division is genuinely rare on the target workload.
- **G (shared across cores):** minimal replicated area; only viable if the NoC has spare bandwidth and the workload tolerates MUL/DIV latency (uncommon).
## Disadvantages
- **A:** 64-cycle MUL is a structural hazard in nearly all non-trivial programs. Most RISC-V cores ship a faster multiplier.
- **B:** still poor MUL throughput; the pipelining helps frequency but not CPI for multiply-heavy code.
- **C:** the array multiplier is the largest single addition; replicating 128 instances dominates the per-core MDU area. The iterative divider becomes the long pole.
- **D:** the radix-4 booth encoder + Wallace reduction is the single most verification-intensive block in the integer datapath; high combinatorial depth impacts timing closure.
- **E:** the worst replication cost; if the XH-1 core is in-order (not established by repository context), this is overkill.
- **F:** division traps in scientific, crypto, and some HPC kernels; would require a fast software path that defeats the area saving.
- **G:** a single shared MDU becomes a hot spot; under load, the queuing delay exceeds a 64-cycle per-core iterative design. Also violates the principle that each core should be self-sufficient for any single instruction.
## XH-1 Considerations
- **ISA scope (ASSUMPTION):** XH-1 implements RV64IMAC or RV64GC. Until the decoder document (`research/03-core-design/decoder.md`) defines the supported extension set, MDU scope must include both `M` and the bitmanip multiply subset if `B` is present.
- **Pipeline style (UNKNOWN):** if the XH-1 core is in-order, an iterative or low-radix MDU is sufficient. If out-of-order, a pipelined unit is more defensible. The repository does not yet establish this.
- **Per-core MDU ports (ASSUMPTION):** at most one MDU op per cycle per core, regardless of out-of-order issue width.
- **FPU integration (OPEN):** RISC-V `F`/`D` extensions can be serviced by a separate FPU MDU (for fused multiply-add) or by forwarding to the integer MDU. Coupling decisions affect the MDU port count.
- **NoC and coherence (ASSUMPTION):** the 128 cores share a coherent memory subsystem; the MDU reads two source registers and writes one (or two for `MULH`), so register-file read/write port count is the binding constraint, not the NoC.
## 128-Core Scalability
- The replication cost of any MDU is *exactly* the per-core area × 128 plus shared overhead. A design choice that adds 0.05 mm² per core adds **6.4 mm²** across the chip. The C/D/E rows of the comparison table are therefore the most consequential decision in the MDU document.
- A shared-across-cores MDU (G) trades replicated area for **structural contention** at 128 cores. With a single shared unit, even a steady-state mix of 10% multiply/divide instructions causes queueing proportional to (1 / (1 − utilization)). At 50% utilization, mean wait time already exceeds the latency of an iterative per-core design. (Estimate, Little's law, INSUFFICIENT EVIDENCE for absolute numbers without a workload profile.)
- A *clustered* variant — one MDU per cluster of 4 or 8 cores — reduces the replication cost while bounding the worst-case contention. This is RECOMMENDATION-pending and is treated as an OPEN QUESTION below.
- The MDU contributes directly to per-core power density; if XH-1 is thermally constrained at 128 cores, an iterative design (A/B) is materially preferable.
## Performance Considerations
- A 64-cycle MUL means a `for (i=0;i<n;i++) h = h * 31 + buf[i];` style loop runs at ~64 cycles per byte hashed. A 4-cycle pipelined MUL runs at ~4 cycles per byte. Workloads with high multiply density (cryptography, signal processing, JIT compilers, regex, hash joins) are order-of-magnitude sensitive to this number.
- A 64-cycle DIV is acceptable for most scalar code; high-radix SRT dividers benefit primarily vectorized divide loops. INSUFFICIENT EVIDENCE to assume XH-1 will see heavy scalar divide.
- The MDU rarely becomes the *bottleneck* even at 64 cycles/iter, because most programs do not back-to-back issue multiplies. The MDU *does* become a critical path on a small set of inner loops.
## Area Considerations
Per-order estimates for a modern 7nm-class cell library (ASSUMPTION — no XH-1 process node established):
- Iterative 64-bit shift-add: ~3,000–6,000 gates.
- Radix-4 Booth + Wallace + CPA, 64-bit: ~15,000–30,000 gates.
- Pipelined (3-stage) radix-4 64-bit: ~25,000–45,000 gates.
- SRT-4 divider: ~10,000–20,000 gates.
- These are PROPOSAL figures pending a real synthesis. They vary ±2× with library and timing constraints.
Multiplying by 128:
- 5,000 gates × 128 = 640,000 gates (~0.3–0.5 mm² at 7 nm, est.).
- 30,000 gates × 128 = 3.84 M gates (~2.5–4 mm² est.).
- 50,000 gates × 128 = 6.4 M gates (~4–7 mm² est.).
A full XH-1 die estimate is INSUFFICIENT EVIDENCE without a floorplan.
## Power and Energy Considerations
- Combinational depth × switching activity × capacitance determines dynamic power. Iterative shift-add has the lowest dynamic power at the cost of executing more cycles; a fully combinational array multiplier has the highest dynamic power per op.
- Per-op energy is a *U-shaped* function of latency: very short-latency units burn more energy per cycle but fewer cycles; very long-latency units have low per-cycle leakage but high total leakage over 64 cycles. The minimum is typically in the 4–16 cycle range for a 64-bit MUL. (PROPOSAL — general principle, not specific to XH-1.)
- Replicating a high-power MDU 128 times has thermal and PDN implications: the power distribution network must support the worst-case aggregate.
## Implementation Considerations
- Booth encoders, partial-product compressors, and SRT quotient-selection logic are notoriously timing-sensitive. Synthesis with `set_max_delay -datapath_only` is generally required; the floorplan must hold these cells together.
- Iterative shift-add trivially implements in standard cell logic; no special datapath cell library is required.
- Sharing multiplier and divider datapath (Design D) requires careful multiplexing that introduces a critical-path hazard; many designs simply keep them as separate functional units to ease timing closure.
- The MDU corner-case logic (divide-by-zero, signed-overflow-on-(-1)) is small but error-prone; reference model should be exhaustive on these inputs in verification.
## Verification Considerations
- Iterative shift-add: the state space is small; UVM directed and constrained-random coverage is straightforward.
- Array multiplier: corner cases (e.g., operand = `0x8000_0000_0000_0000` in `MULHSU`, mixed sign/zero) require formal verification of the partial-product array. Strongly recommend a co-simulation against a software reference (e.g., the Spike golden model or a Python oracle).
- SRT divider: quotient-digit selection is the standard formal-verification target; the choice of *r* (radix), *p* (redundancy), and the PLA/ROM selection table is sensitive to off-by-one in the redundancy constants. Several published bugs in commercial processors stem from SRT tables.
- Across 128 cores, *manufacturing* test coverage becomes a concern: each MDU must be DC/AC testable, requiring scan insertion and possibly BIST.
- Cross-bar functional verification (does each core's MDU behave identically?) is most easily done with identical replicated RTL — a heterogeneous MDU design increases verification surface.
## Software Considerations
- Compilers generate `MUL`/`MULH` pairs for 128-bit multiplications. If MUL is fast but MULH is slow (or vice versa), the *paired* latency matters, not the per-instruction latency.
- `Zmmul` (no DIV) is rarely enabled in general-purpose code because GCC/Clang emit DIV freely; turning it on requires recompiling with `-mno-div` and accepting performance loss on division-heavy code.
- The RISC-V psABI requires MUL/DIV results in the integer register file; the MDU must write the integer RF, not a sidecar.
- Vector (`V`) and Packed-SIMD (`P`) extensions, if added later, may have separate vector MDU requirements that are *out of scope* for this document.
## Recommendation
**RECOMMENDATION (provisional, low-to-medium confidence):** Adopt **Design B (pipelined iterative MDU)** as the v1 default, with the data path sized to support the `M` extension. Rationale:
- 128× replication makes the per-core area of Designs C/D/E potentially prohibitive (PROPOSAL — depends on the die area budget, which is INSUFFICIENT EVIDENCE).
- A 2-stage pipelined iterative design provides ~32 cycles/op MUL and ~16 cycles/op DIV, which is sufficient for the majority of scalar RISC-V code paths and substantially cheaper to verify than any array/SRT design.
- A small (optional) **Design C fallback** — a dedicated 64×64 → 64 lower radix-4 array multiplier alongside the iterative divider — should be retained as a synthesis experiment in early RTL exploration to confirm the area/power cost is acceptable.
- If early benchmarks (INSUFFICIENT EVIDENCE) show MUL throughput as a binding constraint, escalate to Design D; if the core is confirmed in-order, Design A may be reconsidered.
This recommendation is explicitly contingent on the unresolved items in **Open Questions** and should be revisited when the pipeline and decoder documents are populated.
## Confidence
| Sub-area | Confidence | Reason |
|---|---|---|
| RISC-V `M` semantics | **High** | Spec is unambiguous and well-established. |
| Latency of iterative vs. array | **High** | Standard textbook numbers; broadly verified. |
| Per-core area estimates | **Low** | No process node, no cell library, no frequency target. |
| 128-core replication impact | **Low–Medium** | Magnitudes are defensible, but absolute numbers depend on die budget and floorplan. |
| Verifier complexity ranking | **Medium** | General industry consensus; no XH-1 verification plan exists. |
| Pipeline style (in-order vs. OoO) | **None** | Not established by repository context; this single unknown dominates the recommendation. |
| Per-core MDU port count | **Low** | Not established. |
| FPU / vector / bitmanip scope | **Low** | Awaiting decoder document. |
Overall recommendation confidence: **Low-to-Medium.** The recommendation is the least-bad default under the current evidence; it should not be treated as committed.
## Open Questions
1. **Is the XH-1 core in-order or out-of-order?** (Blocks the latency target and the throughput requirement.)
2. **What is the target clock frequency and process node?** (Determines whether a radix-4 array multiplier can meet timing in a single cycle.)
3. **What is the per-core die-area budget for the integer execution units?** (Drives the 128× replication cost.)
4. **What is the supported ISA extension set in v1?** (M only, IMAC, GC, or GCB+V?)
5. **Does the FPU have its own multiplier, or does it forward to the integer MDU?** (Affects port count and result-bus topology.)
6. **What is the expected workload mix on XH-1?** (Server, HPC, embedded, AI inference — different mix radically changes the MUL/DIV latency sensitivity.)
7. **Is a clustered MDU (one per 4 or 8 cores) an acceptable design point?** (Requires coherency/NoC discussion, currently unaddressed in this document tree.)
8. **Is the MDU required to be IEEE-754 compatible in any way, or only RISC-V `M`/`B` semantics?** (FPU integration question.)
9. **What is the verification methodology — UVM, formal, both, lightweight directed-random?** (Drives the complexity analysis above.)
## Sources
- RISC-V *Unprivileged ISA Specification*, Volume I, Document Version 20191213 (and later). Publicly available at the RISC-V International site. Used for `M`/`B` extension semantics and corner cases.
- RISC-V *“B” Bitmanip Extension*, version 1.0.0 draft (RISC-V International). Used for the bitmanip scope discussion.
- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (multiple editions) — general background on multiplier/divider design and area/energy tradeoffs. Specific quantitative claims in this document are not from this source and are labelled ESTIMATE/PROPOSAL.
- Weste & Harris, *CMOS VLSI Design: A Circuits and Systems Perspective* — array multiplier, Booth, and Wallace tree area/latency discussion. Magnitudes in the comparison table are not directly cited from this text; they are PROPOSAL/ESTIMATE.
- Ercegovac & Lang, *Digital Arithmetic* — SRT division, quotient-digit selection tables. Specific radix-4 selection tables are not reproduced here.
- *The Microarchitecture of Pipeline and Superscalar CPUs* (Shen, Lipasti) — pipelined iterative vs. array multiplier tradeoffs. General principles only.
INSUFFICIENT EVIDENCE: any XH-1-specific synthesis result, benchmark number, die area, frequency target, or workload measurement. All numerical values in this document that are not directly from the RISC-V spec are PROPOSAL or ESTIMATE.
research/.xh1/runs/20260825T181153Z/research_03-core-design_mul-div-unit.md.review.md.json
View File
research/.xh1/runs/20260825T181153Z/research_03-core-design_mul-div-unit.md.round1.md
+248
View File
@@ -0,0 +1,248 @@
# XH-1 Multiply/Divide Unit Research
## Topic
`research/03-core-design/mul-div-unit.md` — design of the integer multiply/divide (MUL/DIV) execution unit for the XH-1 core, with particular attention to how this unit is replicated across 128 cores.
## Status
**Stub.** The current document contains only the placeholder `SOON`. This research document establishes the design-space analysis required to populate that stub. No committed micro-architecture exists yet.
## Abstract
The integer multiply/divide unit (MDU) implements the RISC-V `M` extension (and optionally `B`, `K`, or vector variants) within each XH-1 core. This document surveys MDU micro-architectures — array multipliers, Wallace/Dadda trees, Booth-recoded multipliers, iterative shift-add multipliers, radix-2/radix-4/radix-8 dividers, and higher-radix/SRT dividers — and evaluates them against the XH-1 design constraints: per-core area and power budgets, latency targets, throughput requirements, verification complexity, and the multiplicative cost of replicating the unit across 128 cores. The analysis concludes that a parameterized iterative shift-add MDU with optional early-exit and a modest dedicated array multiplier is the most defensible starting point, but flags the assumption-laden nature of the recommendation.
## Research Question
> What MDU micro-architecture best satisfies the XH-1 per-core area, power, latency, and throughput targets while remaining tractable to verify, to replicate 128 times, and to expose to the RISC-V ISA and toolchain?
Sub-questions:
1. Should multiplication and division share datapath hardware or be independent units?
2. What latency is required to avoid becoming a structural hazard in the XH-1 pipeline?
3. What is the minimum-radix divider that meets the per-core throughput target?
4. Does the cost of a fast array multiplier (e.g., radix-4 Booth with Wallace tree) justify its latency benefit over an iterative shift-add design replicated 128 times?
5. Which RISC-V extensions must be supported in v1 (`M` only vs. `M+B` vs. `M+B+K`)?
## Background
### RISC-V `M` Extension Semantics (FACT)
The RISC-V `M` extension defines the following operations on the `XLEN`-bit registers (RV64 assumed for XH-1 unless stated otherwise):
- `MUL`, `MULH`, `MULHSU`, `MULHU` — 64×64 → lower-64 / upper-64 signed/unsigned products.
- `DIV`, `DIVU`, `REM`, `REMU` — signed/unsigned division and remainder, 64÷64 → 64 quotient and 64 remainder.
- `MULW`, `DIVW`, `DIVUW`, `REMW`, `REMWU` — 32-bit operations that sign-extend the 32-bit result to 64 bits.
Corner cases the MDU must handle per the ISA:
- Division by zero returns `0xFFFFFFFFFFFFFFFF` (quotient) and the dividend (remainder) for unsigned, and `-1` / dividend for signed.
- The most-negative signed integer (`0x8000…`) divided by `-1` must return the dividend as quotient and `0` as remainder; this traps on x86 but is non-trapping in RISC-V.
- Overflow behavior is *only* defined for signed division/remainder by `-1`; no other overflow is architecturally visible.
### Latency vs. Throughput (FACT)
- A 64×64 → 128-bit full multiplication requires at minimum 128 partial-product rows for a non-Booth radix-2 design, ~64 rows for radix-4 Booth, ~43 rows for radix-8 Booth.
- Bit-serial shift-add multiplication completes in 64 cycles.
- Restoring division completes in 64 cycles; non-restoring in 32–64 cycles depending on the normalization of the remainder; higher-radix SRT dividers in O(log radix(N)) cycles but with substantially larger area.
### RISC-V `B` and `K` Extensions (FACT, partial)
- `B` (Bitmanip) under RV64 1.0.0 includes `MULH`, `MULHU`, `MULHSU` already in `M`, and adds rev-8.0/1.0 bitmanip groups such as `CLMUL`, `CLMULH`, `CLMULR`, `MIN[U]`, `MAX[U]`, `ANDN`, `ORN`, `XNOR`, `SEXT.B/H/W`, and the `Zba`/`Zbb`/`Zbs` sub-extensions.
- `K` (cryptography) adds `Zkn` (AES/SHA) and is not in scope for the base MDU.
- `Zmmul` provides multiply-only and is a common power-optimized subset of `M`.
## Existing Approaches
| Approach | Latency (typ., 64-bit) | Area (relative) | Throughput | Notes |
|---|---|---|---|---|
| Iterative shift-add multiplier | 64 cycles | 1× | 1 / 64 cycles | Smallest area; low throughput |
| Radix-4 Booth + carry-save | ~17 cycles | ~4–6× | 1 / ~17 | Common in embedded OoO |
| Radix-4 Booth + Wallace tree + final CPA | ~3–5 cycles | ~8–12× | 1 / cycle (pipelined) | Used in high-perf cores |
| Pipelined array multiplier (k stages) | k cycles | large | 1 / cycle | Throughput-bound, area-heavy |
| Radix-2 non-restoring divider | 32–64 cycles | 1× (shared with MUL possible) | 1 / 32–64 | Low area |
| Radix-4 SRT divider | ~16 cycles | ~3–5× | 1 / ~16 | Moderate |
| Radix-8/16 SRT divider | ~8–10 cycles | large | 1 / ~10 | High-end OoO |
| Combinational 64×64 array (no pipelining) | ~10+ gate delays | very large | 1 / many cycles | Impractical |
| Shared MUL/DIV datapath (Liang/Montusiewicz style) | variable | ~1.5× single-function | variable | Saves ~30–40% area at the cost of CPI |
(Quantitative magnitudes in this table are estimates from public micro-architecture literature; values vary considerably with cell library, target frequency, and pipeline integration. See Sources.)
## Alternative Designs
### A. Pure Iterative Shift-Add MDU
A single 128-bit accumulator-based datapath. Each cycle shifts the multiplicand and adds if the corresponding multiplier bit is set, or performs a non-restoring division step. The same hardware services both MUL and DIV.
### B. Pipelined Iterative MDU
Same datapath as A, but cut into N pipeline stages (commonly 2 or 4) to allow clock-frequency scaling. Issues per-cycle throughput remains 1 op / N cycles for a single operand width.
### C. Dedicated Array Multiplier + Iterative Divider
A small radix-4 Booth/Wallace multiplier (lower 64 bits in 3–4 cycles) and a separate radix-2 or radix-4 non-restoring divider. Two independent units that can operate concurrently.
### D. Shared Pipelined Radix-4 MDU
A single radix-4 Booth partial-product generator feeding a shared CSA tree, with a reconfigurable final-stage adder and a small division state machine. Latency: ~5–8 cycles for MUL, ~16 for DIV.
### E. Pipelined High-Performance MDU (Wallace/Wallace + SRT-4)
Multi-cycle but pipelined radix-4 multiplier and SRT-4 divider. Both deliver 1 op/cycle throughput once steady-state. Area dominates the integer datapath.
### F. `Zmmul`-Only MUL, External DIV Trap
Implement MUL in hardware (small array or iterative), trap DIV/REM to a software handler. The privileged trap path is fast on XH-1 only if the software model tolerates it; SPECint and most server workloads execute division frequently enough that this is usually unacceptable.
### G. Compressed / Shared Across Cores
A single physical MDU shared by N cores via a NoC-side arbiter. Removes per-core area cost but introduces structural contention; this is generally considered an *adverse* design for a 128-core tiled machine.
## Comparison
| Design | Area/cell count (est.) | Cycles/op MUL | Cycles/op DIV | Throughput (steady) | Verif. complexity | Replicated ×128 cost | Power/cores at 1 GHz (est.) |
|---|---|---|---|---|---|---|---|
| A. Iterative | 1.0× | 64 | 32–64 | 1/64 | Low | low | low |
| B. Pipelined iter. (2-stage) | ~1.1× | 32 | 16–32 | 1/32 | Low–Medium | low | low–medium |
| C. Array MUL + iter DIV | ~6–8× | 3–5 | 32–64 | 1/cycle (MUL) | Medium | high | medium–high |
| D. Shared radix-4 | ~4–6× | 5–8 | 16 | 1/cycle (MUL) | Medium–High | medium | medium |
| E. Pipelined Wallace + SRT-4 | ~12–20× | 1/cycle | 1/cycle | 1/cycle | High | very high | high |
| F. Zmmul + trap | ~1–2× | variable | trap | low | Lowest | lowest | lowest |
| G. Shared across cores | 1/N per core | +NoC latency | +NoC latency | contended | High (coherency) | lowest in area, highest in latency | lowest in static power, high in dynamic on miss |
(All non-FACT values are PROPOSAL/ESTIMATE pending the XH-1 cell library and frequency target.)
## Advantages
- **A (iterative):** lowest area and verification cost; trivially replicated ×128; deterministic timing; well-suited to in-order pipelines with a single MDU reservation station.
- **C (array + iter):** low MUL latency benefits compiled code with tight multiply chains (CRC, hashing, address computation); the iterative divider keeps area under control.
- **D (shared radix-4):** good balance; single unit means fewer ports on the issue queue, simpler back-pressure, easier to verify than E.
- **E (pipelined):** removes MDU as a critical path for high-frequency operation; appropriate only if XH-1 is a high-frequency out-of-order core.
- **F (Zmmul + trap):** smallest possible die; useful if division is genuinely rare on the target workload.
- **G (shared across cores):** minimal replicated area; only viable if the NoC has spare bandwidth and the workload tolerates MUL/DIV latency (uncommon).
## Disadvantages
- **A:** 64-cycle MUL is a structural hazard in nearly all non-trivial programs. Most RISC-V cores ship a faster multiplier.
- **B:** still poor MUL throughput; the pipelining helps frequency but not CPI for multiply-heavy code.
- **C:** the array multiplier is the largest single addition; replicating 128 instances dominates the per-core MDU area. The iterative divider becomes the long pole.
- **D:** the radix-4 booth encoder + Wallace reduction is the single most verification-intensive block in the integer datapath; high combinatorial depth impacts timing closure.
- **E:** the worst replication cost; if the XH-1 core is in-order (not established by repository context), this is overkill.
- **F:** division traps in scientific, crypto, and some HPC kernels; would require a fast software path that defeats the area saving.
- **G:** a single shared MDU becomes a hot spot; under load, the queuing delay exceeds a 64-cycle per-core iterative design. Also violates the principle that each core should be self-sufficient for any single instruction.
## XH-1 Considerations
- **ISA scope (ASSUMPTION):** XH-1 implements RV64IMAC or RV64GC. Until the decoder document (`research/03-core-design/decoder.md`) defines the supported extension set, MDU scope must include both `M` and the bitmanip multiply subset if `B` is present.
- **Pipeline style (UNKNOWN):** if the XH-1 core is in-order, an iterative or low-radix MDU is sufficient. If out-of-order, a pipelined unit is more defensible. The repository does not yet establish this.
- **Per-core MDU ports (ASSUMPTION):** at most one MDU op per cycle per core, regardless of out-of-order issue width.
- **FPU integration (OPEN):** RISC-V `F`/`D` extensions can be serviced by a separate FPU MDU (for fused multiply-add) or by forwarding to the integer MDU. Coupling decisions affect the MDU port count.
- **NoC and coherence (ASSUMPTION):** the 128 cores share a coherent memory subsystem; the MDU reads two source registers and writes one (or two for `MULH`), so register-file read/write port count is the binding constraint, not the NoC.
## 128-Core Scalability
- The replication cost of any MDU is *exactly* the per-core area × 128 plus shared overhead. A design choice that adds 0.05 mm² per core adds **6.4 mm²** across the chip. The C/D/E rows of the comparison table are therefore the most consequential decision in the MDU document.
- A shared-across-cores MDU (G) trades replicated area for **structural contention** at 128 cores. With a single shared unit, even a steady-state mix of 10% multiply/divide instructions causes queueing proportional to (1 / (1 − utilization)). At 50% utilization, mean wait time already exceeds the latency of an iterative per-core design. (Estimate, Little's law, INSUFFICIENT EVIDENCE for absolute numbers without a workload profile.)
- A *clustered* variant — one MDU per cluster of 4 or 8 cores — reduces the replication cost while bounding the worst-case contention. This is RECOMMENDATION-pending and is treated as an OPEN QUESTION below.
- The MDU contributes directly to per-core power density; if XH-1 is thermally constrained at 128 cores, an iterative design (A/B) is materially preferable.
## Performance Considerations
- A 64-cycle MUL means a `for (i=0;i<n;i++) h = h * 31 + buf[i];` style loop runs at ~64 cycles per byte hashed. A 4-cycle pipelined MUL runs at ~4 cycles per byte. Workloads with high multiply density (cryptography, signal processing, JIT compilers, regex, hash joins) are order-of-magnitude sensitive to this number.
- A 64-cycle DIV is acceptable for most scalar code; high-radix SRT dividers benefit primarily vectorized divide loops. INSUFFICIENT EVIDENCE to assume XH-1 will see heavy scalar divide.
- The MDU rarely becomes the *bottleneck* even at 64 cycles/iter, because most programs do not back-to-back issue multiplies. The MDU *does* become a critical path on a small set of inner loops.
## Area Considerations
Per-order estimates for a modern 7nm-class cell library (ASSUMPTION — no XH-1 process node established):
- Iterative 64-bit shift-add: ~3,000–6,000 gates.
- Radix-4 Booth + Wallace + CPA, 64-bit: ~15,000–30,000 gates.
- Pipelined (3-stage) radix-4 64-bit: ~25,000–45,000 gates.
- SRT-4 divider: ~10,000–20,000 gates.
- These are PROPOSAL figures pending a real synthesis. They vary ±2× with library and timing constraints.
Multiplying by 128:
- 5,000 gates × 128 = 640,000 gates (~0.3–0.5 mm² at 7 nm, est.).
- 30,000 gates × 128 = 3.84 M gates (~2.5–4 mm² est.).
- 50,000 gates × 128 = 6.4 M gates (~4–7 mm² est.).
A full XH-1 die estimate is INSUFFICIENT EVIDENCE without a floorplan.
## Power and Energy Considerations
- Combinational depth × switching activity × capacitance determines dynamic power. Iterative shift-add has the lowest dynamic power at the cost of executing more cycles; a fully combinational array multiplier has the highest dynamic power per op.
- Per-op energy is a *U-shaped* function of latency: very short-latency units burn more energy per cycle but fewer cycles; very long-latency units have low per-cycle leakage but high total leakage over 64 cycles. The minimum is typically in the 4–16 cycle range for a 64-bit MUL. (PROPOSAL — general principle, not specific to XH-1.)
- Replicating a high-power MDU 128 times has thermal and PDN implications: the power distribution network must support the worst-case aggregate.
## Implementation Considerations
- Booth encoders, partial-product compressors, and SRT quotient-selection logic are notoriously timing-sensitive. Synthesis with `set_max_delay -datapath_only` is generally required; the floorplan must hold these cells together.
- Iterative shift-add trivially implements in standard cell logic; no special datapath cell library is required.
- Sharing multiplier and divider datapath (Design D) requires careful multiplexing that introduces a critical-path hazard; many designs simply keep them as separate functional units to ease timing closure.
- The MDU corner-case logic (divide-by-zero, signed-overflow-on-(-1)) is small but error-prone; reference model should be exhaustive on these inputs in verification.
## Verification Considerations
- Iterative shift-add: the state space is small; UVM directed and constrained-random coverage is straightforward.
- Array multiplier: corner cases (e.g., operand = `0x8000_0000_0000_0000` in `MULHSU`, mixed sign/zero) require formal verification of the partial-product array. Strongly recommend a co-simulation against a software reference (e.g., the Spike golden model or a Python oracle).
- SRT divider: quotient-digit selection is the standard formal-verification target; the choice of *r* (radix), *p* (redundancy), and the PLA/ROM selection table is sensitive to off-by-one in the redundancy constants. Several published bugs in commercial processors stem from SRT tables.
- Across 128 cores, *manufacturing* test coverage becomes a concern: each MDU must be DC/AC testable, requiring scan insertion and possibly BIST.
- Cross-bar functional verification (does each core's MDU behave identically?) is most easily done with identical replicated RTL — a heterogeneous MDU design increases verification surface.
## Software Considerations
- Compilers generate `MUL`/`MULH` pairs for 128-bit multiplications. If MUL is fast but MULH is slow (or vice versa), the *paired* latency matters, not the per-instruction latency.
- `Zmmul` (no DIV) is rarely enabled in general-purpose code because GCC/Clang emit DIV freely; turning it on requires recompiling with `-mno-div` and accepting performance loss on division-heavy code.
- The RISC-V psABI requires MUL/DIV results in the integer register file; the MDU must write the integer RF, not a sidecar.
- Vector (`V`) and Packed-SIMD (`P`) extensions, if added later, may have separate vector MDU requirements that are *out of scope* for this document.
## Recommendation
**RECOMMENDATION (provisional, low-to-medium confidence):** Adopt **Design B (pipelined iterative MDU)** as the v1 default, with the data path sized to support the `M` extension. Rationale:
- 128× replication makes the per-core area of Designs C/D/E potentially prohibitive (PROPOSAL — depends on the die area budget, which is INSUFFICIENT EVIDENCE).
- A 2-stage pipelined iterative design provides ~32 cycles/op MUL and ~16 cycles/op DIV, which is sufficient for the majority of scalar RISC-V code paths and substantially cheaper to verify than any array/SRT design.
- A small (optional) **Design C fallback** — a dedicated 64×64 → 64 lower radix-4 array multiplier alongside the iterative divider — should be retained as a synthesis experiment in early RTL exploration to confirm the area/power cost is acceptable.
- If early benchmarks (INSUFFICIENT EVIDENCE) show MUL throughput as a binding constraint, escalate to Design D; if the core is confirmed in-order, Design A may be reconsidered.
This recommendation is explicitly contingent on the unresolved items in **Open Questions** and should be revisited when the pipeline and decoder documents are populated.
## Confidence
| Sub-area | Confidence | Reason |
|---|---|---|
| RISC-V `M` semantics | **High** | Spec is unambiguous and well-established. |
| Latency of iterative vs. array | **High** | Standard textbook numbers; broadly verified. |
| Per-core area estimates | **Low** | No process node, no cell library, no frequency target. |
| 128-core replication impact | **Low–Medium** | Magnitudes are defensible, but absolute numbers depend on die budget and floorplan. |
| Verifier complexity ranking | **Medium** | General industry consensus; no XH-1 verification plan exists. |
| Pipeline style (in-order vs. OoO) | **None** | Not established by repository context; this single unknown dominates the recommendation. |
| Per-core MDU port count | **Low** | Not established. |
| FPU / vector / bitmanip scope | **Low** | Awaiting decoder document. |
Overall recommendation confidence: **Low-to-Medium.** The recommendation is the least-bad default under the current evidence; it should not be treated as committed.
## Open Questions
1. **Is the XH-1 core in-order or out-of-order?** (Blocks the latency target and the throughput requirement.)
2. **What is the target clock frequency and process node?** (Determines whether a radix-4 array multiplier can meet timing in a single cycle.)
3. **What is the per-core die-area budget for the integer execution units?** (Drives the 128× replication cost.)
4. **What is the supported ISA extension set in v1?** (M only, IMAC, GC, or GCB+V?)
5. **Does the FPU have its own multiplier, or does it forward to the integer MDU?** (Affects port count and result-bus topology.)
6. **What is the expected workload mix on XH-1?** (Server, HPC, embedded, AI inference — different mix radically changes the MUL/DIV latency sensitivity.)
7. **Is a clustered MDU (one per 4 or 8 cores) an acceptable design point?** (Requires coherency/NoC discussion, currently unaddressed in this document tree.)
8. **Is the MDU required to be IEEE-754 compatible in any way, or only RISC-V `M`/`B` semantics?** (FPU integration question.)
9. **What is the verification methodology — UVM, formal, both, lightweight directed-random?** (Drives the complexity analysis above.)
## Sources
- RISC-V *Unprivileged ISA Specification*, Volume I, Document Version 20191213 (and later). Publicly available at the RISC-V International site. Used for `M`/`B` extension semantics and corner cases.
- RISC-V *“B” Bitmanip Extension*, version 1.0.0 draft (RISC-V International). Used for the bitmanip scope discussion.
- Hennessy & Patterson, *Computer Architecture: A Quantitative Approach* (multiple editions) — general background on multiplier/divider design and area/energy tradeoffs. Specific quantitative claims in this document are not from this source and are labelled ESTIMATE/PROPOSAL.
- Weste & Harris, *CMOS VLSI Design: A Circuits and Systems Perspective* — array multiplier, Booth, and Wallace tree area/latency discussion. Magnitudes in the comparison table are not directly cited from this text; they are PROPOSAL/ESTIMATE.
- Ercegovac & Lang, *Digital Arithmetic* — SRT division, quotient-digit selection tables. Specific radix-4 selection tables are not reproduced here.
- *The Microarchitecture of Pipeline and Superscalar CPUs* (Shen, Lipasti) — pipelined iterative vs. array multiplier tradeoffs. General principles only.
INSUFFICIENT EVIDENCE: any XH-1-specific synthesis result, benchmark number, die area, frequency target, or workload measurement. All numerical values in this document that are not directly from the RISC-V spec are PROPOSAL or ESTIMATE.
research/.xh1/runs/20260825T181153Z/research_03-core-design_mul-div-unit.md.round1.md.json
+321
View File
File diff suppressed because one or more lines are too long