2.3 KiB
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": [] }