VERDICT: FAIL

ISSUES:

1. **Booth radix-4 partial-product count is wrong (B1, B2 background, and Proposal).** The document states radix-4 Booth on a 64-bit operand produces ⌈64/2⌉ = 32 signed-digit rows plus one sign-correction row = 33. This is incorrect. Standard radix-4 Booth-2 encoding of an n-bit operand produces ⌈n/2⌉ = 32 signed-digit rows total (for n=64). The sign-correction is a *bit added to the existing rows* (the MSB of the highest digit), not a separate full-width partial product row. A 64-bit radix-4 Booth multiplier has 32 partial products, not 33. This error propagates to the B1 design description, the proposal, and the recommendation.

2. **Booth radix-8 partial-product count is wrong (B2).** Document claims 22 signed-digit rows + 1 sign-correction = 23. For 64-bit radix-8 Booth, the standard count is ⌈n/3⌉ = 22 signed-digit rows. The "extra sign-correction row" framing is the same misconception as issue 1. The 11-PP correction (vs. 32-bit) is also misleadingly explained.

3. **MULH/MULHU full-product requirement is misleading.** The document states the multiplier is "sized to produce the full 128-bit product so that MULH/MULHU selection requires only output muxing." A 64×64→128 multiplier is required for MULH/MULHU, but it is not required for MUL; this is a real cost driver. The framing implies the datapath is "free" beyond MUL when in fact the upper 64 bits exist specifically to serve MULH*. The document also fails to note that for 32-bit operands (the W-variants) the full 64×64→128 product is overkill, though reusing the same datapath is reasonable.

4. **Newton–Raphson B5 latency claim is inconsistent and likely wrong.** A 64-bit Newton–Raphson divider with a 32-bit initial reciprocal and 2 iterations does **not** produce a 64-bit-accurate quotient. Two iterations of N–R on a 32-bit seed approximately double the bit-accuracy per iteration, so after 2 iterations you have ~32 + 2·(32 − accuracy) bits — for a properly initialized seed this typically gives ~64 bits only with a carefully chosen seed and the right number of iterations (commonly 2–3 iterations from a 16–32 bit seed, depending on the exact variant). The "6–10 cycles" budget for two multiplies + two iterations + correction is not obviously wrong but the bit-accuracy argument is not given. The "4–6 cycle for 32-bit" prior figure is also not defended.

5. **B6 "combinational non-restoring array divider" size claim is uncalibrated.** The document removes the prior "~50×" figure as unsupported but offers no replacement order-of-magnitude estimate, only "very large." The comparison table still lists "very large (unvalidated)" with no quantitative anchor, which makes the comparison table non-actionable for B6.

6. **B7 per-core effective area math is sloppy.** Cluster of 8 cores sharing one B1 + B4-pipe unit: per-cluster area estimated 8–12× A1, divided by 8 cores gives 1–1.5× A1 per core. But B1 alone is 3–5× A1 and B4-pipe adds more. A cluster containing a full B1 + B4-pipe cannot be "8–12× A1 total" — that range would put the B4-pipe contribution at roughly 0×, which contradicts B4-pipe's stated 6–8× to A2 (i.e., ~3–4× to A1 added on top of A2's 3–4× A1). The cluster cost arithmetic does not close.

7. **B5 throughput "1/6–1/10" is misleading.** Newton–Raphson is variable-latency; throughput depends on whether a subsequent divide can start before the previous finishes. The document treats throughput as 1/latency without justifying the absence of pipelining.

8. **A3 divider throughput of "1/16" is inconsistent with a "pipelined" SRT-4 elsewhere.** A3 is explicitly non-pipelined, but the entry still says "pipelined radix-4/8 Booth multiplier." The A3/B4 split is confusing because the document says A3 is the non-pipelined SRT-4 view "for direct comparison with B4," then later notes B4-pipe is a separate point. This is internally confusing even if not strictly wrong.

9. **Area ranges in the comparison table use A1 as the baseline but the A1 baseline is never quantified.** All relative areas are multiples of an undefined "1×." This is acknowledged but undermines the entire comparison; there is no absolute number to anchor "3–5× of A1" to.

10. **Power/energy section is non-quantitative and largely vacuous.** "Energy tends to scale with switching nodes" is not an analysis. The section does not consider that an iterative divider is the worst case for energy *per divide*, not the best, because 64 cycles of clocked register activity typically dominates the energy budget for a single divide vs. a faster divider that completes in fewer cycles. The framing ("lower average switching power") is misleading without an operations-per-second normalization.

11. **Failure to consider that W-variants need only a 32×32→64 (sign-extended) datapath, not 64×64→128.** Reusing the 64-bit datapath for 32-bit operands costs 4× the energy and area of a dedicated 32-bit datapath. The document claims this reuse is "acceptable" without comparing against a dedicated W-datapath. The W-extension is a real workload consideration in many RV64 deployments.

12. **128-core scalability claim about voltage/frequency is unsupported.** "Moderately pipelined MUL/DIV is more resilient to voltage droop" is asserted without source or reasoning. Voltage-droop resilience depends on the depth of pipelining, clock-tree design, and decoupling — not directly on whether the MUL/DIV is "moderately pipelined." This is a hand-wave.

13. **F/D extension "out of scope" but Recommendation 2 implies otherwise.** The document lists F/D as an open question, yet the recommended design's relevance to F extension (FP reciprocal, FP-to-int conversions, Newton–Raphson for FP divide) is a major design driver that is dismissed as out of scope. Given XH-1 is described as balancing general-purpose and HPC-adjacent workloads, excluding F from the MUL/DIV analysis is a significant gap.

14. **Sources section is weak on specificity.** Rocket, BOOM, Ariane are cited by file name but without commit hashes, and the document admits "specific commit, measured numbers, and PPA data: INSUFFICIENT EVIDENCE." Hennessy & Patterson and Parhami are cited without chapter or edition. Per the document's own labeling standard, these citations are not actionable.

15. **MULH/MULHSU "Booth complicates verification" claim is overstated.** Radix-4 Booth of a signed operand is the standard recoding; signed/unsigned operand handling at the input is the issue, not Booth itself. The verification complication is the sign-extension/correction logic, which is small. The document overstates this.

16. **"Signed overflow (DIV of INT64_MIN by −1): quotient = INT64_MIN, remainder = 0" is correct but the document does not note the verification implication** — that this requires detecting the overflow case explicitly, separate from a generic restore step. Mentioning the rule without mentioning the hardware detector is a gap.

17. **The "2-cycle MUL matches typical issue-to-use distances" claim is unsupported.** No pipeline depth or issue-to-use distance is established; `pipeline.md` is TBD. This is a quantitative claim with no anchor.

18. **A5 "Shared / Clustered MUL/DIV Unit" is listed under "Existing Approaches" but is then analyzed as B7, a new design point.** The boundary between existing and proposed is blurred; the document acknowledges this was not analyzed in the prior revision.

19. **B4-pipe area accounting in the comparison table is wrong.** Row says "adds ~6–8× to A2 total (unval.)" but A2's area is 3–4× A1, so 6–8× relative to A2 would be 18–32× A1, which is absurd and contradicts the B1+B4-pipe narrative. The text earlier says ~3–4× of B1's divider, added to B1 → 6–8× of A1 total, but the table column header says "to A2 total" and the value is not consistent with either reading. This is a clear internal inconsistency.

20. **The "previous revision contained an error" pattern is repeated many times** (32-cycle divider, 11 partial products, "~50×" array divider, MULH/Montgomery claim, DIVU-by-zero description). The document is a self-correction of a prior version, which is fine, but the volume of corrections suggests the document is still in flux and not ready for a recommendation-grade verdict.

21. **The "primary recommendation is conditional on synthesis data that does not yet exist" disclaimer is repeated in the Status, Proposal, Recommendation, and Confidence sections.** This is honest but means the document's primary deliverable is, by its own admission, not actionable today. The document should be marked as "research survey" rather than issuing a conditional recommendation.

REQUIRED FIXES:

- Correct the Booth partial-product counts (radix-4: 32 rows, not 33; radix-8: 22 rows, not 23) and propagate the correction through B1, B2, the Proposal, and the Recommendation. The sign-correction is a bit added to existing rows, not a separate full-width row.
- Reconcile the B4-pipe / A2 / B1 area math in the comparison table; either restate the units of the "adds 3–4×" and "6–8×" figures consistently, or drop the relative numbers and label them all "unvalidated, pending synthesis."
- Quantify the A1 baseline in absolute terms (gate count, NAND2 equivalent, or area in a named process) or remove the relative-area columns and replace with qualitative ranking.
- Provide an order-of-magnitude estimate for B6 (combinational non-restoring array divider) area, even as a wide range, so the comparison table is non-vacuous for that row.
- Re-derive B5 (Newton–Raphson) latency and iteration count with the bit-accuracy argument made explicit, including the seed width and the number of correct bits per iteration.
- Resolve the W-variant question: either justify reusing the 64-bit datapath with a quantitative energy/area comparison, or note that a dedicated 32-bit datapath is an alternative.
- Address F/D extension implications in the MUL/DIV analysis, or explicitly state the design is integer-only with no plan to add F/D and accept the consequences.
- Strengthen the Sources section with specific citations (edition, chapter, commit hash) or remove the citation claims entirely.
- Remove the unsupported voltage-droop-resilience claim or replace it with a sourced statement.
- Distinguish explicitly, for each numbered claim in the Proposal and Recommendation, whether it is a FACT (spec-defined), an ASSUMPTION (engineering judgment with stated basis), a PROPOSAL (design choice), a RECOMMENDATION (action with trigger), or an OPEN QUESTION. Several items currently mix these categories.
- Verify the RISC-V spec citation (Document Version 20191213) actually contains the exact ÷0 and INT64_MIN/−1 behavior as stated, and that the document is not relying on memory of the spec text.
- State the per-core area budget assumption (or lack thereof) explicitly in the Recommendation, not only in the Status section.

CONFIDENCE: HIGH
