SIG Gap Analyses Template
[SIG Name] Gap Analysis Report: [Topic/Vertical]
Version: 1.0
Date: Jan 22, 2026
Status: [Draft/Under Review/Approved]
Authors/Contributors:
A
B
C
N
1. Executive Summary
Max 2 paragraphs. The "Bottom Line Up Front" for the TSC and Board
Context: Briefly state the market vertical or technical domain (e.g., "AI/ML Edge Inference" or "Android Application Profile").
Problem Statement: Summarize the collective impact of the current deficiencies. Focus on the business/technical result of the gaps (e.g., "Currently, RISC-V cannot support Tier-1 Android deployments due to fragmentation in performance profiles and missing security standards").
Critical Findings & Recommendations:
Finding 1: [Critical Gap] (e.g., Missing vector-optimized BLAS libraries).
Recommendation: [Specific Action] (e.g., Charter a 'Math Libraries' Task Group).
Finding 2: [Critical Gap] (e.g., No standardized IOMMU interface).
Recommendation: [Specific Action] (e.g., Adopt the AIA specification as mandatory).
Finding 3: [Critical Gap] (e.g., Fragmented boot flows).
Recommendation: [Specific Action] (e.g., Align with the 'Server Platform' BBR profile).
2. Scope & Objectives
2.1 In-Scope
Define the specific boundaries. (e.g., "RVA23 Profile," "Linux Kernel 6.x," "GCC 14+")
List specific standards or competitor benchmarks used for comparison (e.g., "ARM BSA/BBR" or "Vulkan 1.3").
2.2 Out-of-Scope
Explicitly state what you are NOT analyzing to prevent scope creep. (e.g., "Proprietary vendor extensions" or "Debug hardware").
3. Landscape Assessment
3.1 Current State (Baseline)
ISA Status: Which existing extensions are relevant? (e.g., V, B, Zc).
Software Ecosystem: What is the current status of upstream support? (e.g., "Support exists in LLVM but is experimental in GCC").
Hardware Availability: Is there silicon available today that meets the baseline?
3.2 Target State (Requirement)
Describe the "Definition of Done."
Example: "To support Tier 1 Android deployment, we require feature parity with ARMv9 in the following subsystems: A, B, and C."
4. Detailed Gap Analysis
This section should be organized by technical layer. Use the tables below for consistency
4.1 ISA & Hardware Gaps
Focus: Missing instructions, architectural behaviors, or CSRs.
Feature / Requirement | Current RISC-V Status | Competitor/Standard Benchmark | Gap Severity* | Recommended Action |
e.g., Cache Management | CBO instructions exist (Zicbom) | ARMv8 PoC/PoU equivalents | CRITICAL | None (Gap Closed) |
e.g., Matrix Math | Vector (V) only | AMX / SME | HIGH | Propose Matrix Extension TG |
4.2 Software & Toolchain Gaps
Focus: Compilers, Libraries, OS Kernel, Runtimes.
Component | Missing Capability | Impact on Developer | Estimated Effort | Owner (SIG/HC) |
OpenBLAS | Optimized GEMM kernels for RVV 1.0 | Low performance in AI workloads | Medium (3-6 mo) | Soft-CPU SIG / PLCT |
AOSP | Emulator support for Hypervisor ext. | Cannot test virtualization | High (6-12 mo) | Android SIG |
4.3 Verification & Compliance Gaps
Focus: ACT (Arch. Compatibility Tests), formal models, or test suites.
Gap 1: [Description]
Gap 2: [Description]
Severity Key:
CRITICAL: Blocker for adoption; no workaround exists.
HIGH: Major performance/functionality loss; complex workaround.
MEDIUM: Minor degradation; acceptable workaround exists.
LOW: Nice to have; future optimization.
5. Risk Assessment
What happens if we do nothing?
Market Risk: (e.g., "Adoption will stall in Automotive cockpit designs due to lack of virtualization standards.")
Fragmentation Risk: (e.g., "Vendors will implement non-standard custom solutions for IOMMU.")
6. Recommendations & Roadmap
6.1 Immediate Actions (0-6 Months)
A
B
N
6.2 Strategic Initiatives (6-18 Months)
A
B
N
6.3 External Liaison Requirements
List organizations we must collaborate with (e.g., ISO, Khronos, UEFI Forum).
