mirror of
https://github.com/allexanderbergmns/xh1-research.git
synced 2026-08-26 20:27:02 +00:00
31 lines
2.3 KiB
Markdown
31 lines
2.3 KiB
Markdown
The document is technically sound and well-structured for a research proposal for a high-core-count RISC-V system.
|
|
|
|
### Technical Review
|
|
|
|
**1. Memory Model & RISC-V Compliance**
|
|
The document correctly identifies the nuances of the RISC-V Weak Memory Ordering (RVWMO) model. Specifically, the distinction between a local `FENCE` and the requirement for a "global drain" is a critical point in RISC-V. The document correctly notes that `FENCE` only requires local guarantees to be met, and that global ordering is typically handled via `aq`/`rl` bits on AMO instructions or by the software composing multiple fences. This demonstrates a high level of adherence to the RISC-V specification.
|
|
|
|
**2. Scalability and Architecture**
|
|
For a 128-core system, the choice of a **Directory-based MESI protocol** combined with a **2D Mesh NoC** is the industry standard.
|
|
- **Directory:** Using a "coarse-vector" directory (16 pointers per entry) is an effective way to manage the directory size/overhead trade-off.
|
|
- **Interconnect:** A 2D mesh with virtual channels is necessary to prevent head-of-line blocking and provide the necessary bandwidth for 128 cores.
|
|
- **Cache Hierarchy:** The move to a write-back L1 with directory-tracked L2/L3 is standard for this scale.
|
|
|
|
**3. Verification Strategy**
|
|
The inclusion of **litmus tests** and **formal verification** (specifically mentioning `riscv-formal`) is essential for a 128-core system. The state space for memory consistency in a multi-core system is massive; formal verification of the coherence protocol is the only way to ensure correctness in the face of complex corner cases.
|
|
|
|
**4. Unresolved Design Questions**
|
|
The "Unresolved" section shows a mature understanding of the current RISC-V ecosystem:
|
|
- **Zalasr:** Correctly identifies that it is not yet ratified and should not be a dependency.
|
|
- **Ztso:** Correctly identifies the lack of a standard "opt-in" and the need for a design-time decision.
|
|
- **FENCE.TSO:** Correctly identifies that the spec allows for it to be implemented as a hint.
|
|
|
|
**5. Minor Observations**
|
|
- **Fence Overhead:** The document notes that global fences are more expensive on larger machines. This is a valid concern due to the increased diameter of the 2D mesh and the size of the directory.
|
|
{
|
|
"verdict": "PASS",
|
|
"confidence": "HIGH",
|
|
"issues": [],
|
|
"required_fixes": []
|
|
}
|