**Review of research/05-memory/atomics.md**

The document provides a clear and structured discussion of atomic operations in the context of a 128‑core RISC‑V processor. It correctly identifies the key scalability challenges, reviews several implementation approaches, and outlines reasonable proposals for the XH‑1 design. The overall technical intent is sound, and the document is appropriate for its research stage.

However, a few issues must be addressed before acceptance, and several minor points deserve attention.

**1. Factual / Specification Error (must fix)**
- In Section 5.3, the claim that AMO payload sizes could be 128 bits “if the Zicbom/Zve extensions are considered” is incorrect. Zicbom is a cache‑block‑management extension, and Zve is the vector extension; neither introduces 128‑bit atomic memory operations. The standard `Zaamo` extension defines only 8‑, 16‑, 32‑, and 64‑bit AMOs. The erroneous reference to Zicbom/Zve creates a misunderstanding of the ISA and should be removed.

**2. Unsupported Performance Claims**
- The document estimates that L1‑based AMO ping‑ponging could reduce throughput to “below 2 M ops/sec” and that in an LR/SC loop the probability of success for a given hart “approaches 1/128.” These are rough, unsupported estimates presented without simulation data, analytical modeling, or references. While they are illustrative, they are stated as if they are quantitative conclusions. They should either be removed or explicitly labelled as speculative order‑of‑magnitude guesses.

**3. Reservation Invalidation on `xret`**
- Section 5.4 states that the reservation register “must be cleared … upon executing an `xret`.” The RISC‑V specification requires clearing on a context switch, interrupt, or exception, but does not explicitly require clearing on `xret`. In practice the reservation is already lost because the trap entry cleared it; the statement is therefore slightly misleading. It is not a serious error, but it would be better to clarify that the reservation is **already** invalidated by the time `xret` executes.

**4. Missing Discussion of Power/Area Implications**
- The review criteria include power and area considerations. The document does not address the power or area cost of the proposed AMO execution location (home‑node vs. L1), the hardware‑assisted backoff, or the additional PMU counters. For a complete research document, a brief mention of these trade‑offs would be expected.

**5. Lack of Supporting Citations**
- The document contains no references to the RISC‑V specification, existing literature on atomics scaling, or prior work on directory‑based AMO execution. While not mandatory for an internal research note, the absence of any citations weakens the evidence base for the proposals.

**Verdict**

Despite these points, the document is technically credible for its research stage. The necessary fix is minor and straightforward. The verdict is **PASS** with the required correction of the Zicbom/Zve error.

```json
{
  "verdict": "PASS",
  "confidence": "HIGH",
  "issues": [
    "The claim that the probability of a successful sc for a given hart approaches 1/128 is an unsupported approximation.",
    "The estimate that L1‑based AMO throughput could drop below 2 M ops/sec is unsupported by any analysis or data.",
    "The statement that the reservation must be cleared upon executing xret is slightly inaccurate; it is already cleared by the interrupting trap. The phrasing should be clarified.",
    "The document does not discuss power or area implications of the proposed AMO execution strategies.",
    "No citations are provided to support the claimed scalability limits or to reference the RISC‑V specification."
  ],
  "required_fixes": [
    "Remove the incorrect reference to Zicbom/Zve in Section 5.3. The standard Zaamo extension supports only up to 64‑bit AMO payloads; there is no 128‑bit AMO in Zicbom or Zve. Correct the sentence to state that the interconnect must support payloads up to 64 bits (or 8/16/32/64 bits) for AMO instructions."
  ]
}
```
