1. 技术分享的内容定位：为什么小组要持续跟踪RV动态
2026年已经过半。RISC-V小组在6到8月这段时间里，把最近三个月的技术动态重新梳理了一遍。这个季度有几个明显的信号：指令集扩展提案进入密集落地期，高性能核的微架构设计话题从学术圈扩散到工程圈，软件生态的成熟度也比去年同期上了一个台阶。整理成一次小组分享，既是为了让团队内部对齐认知，也是想给周边关注RISC-V的开发者一份可参考的季度观察。
这次分享的材料主要围绕三条线展开：指令集层的变化、CPU微架构设计上的新做法、以及软件工具链和落地场景的进展。不是面面俱到的新闻汇总，而是挑那些真正会影响你我做设计的点来讲。比如哪个扩展草案该提前关注，哪个微架构设计思路开始在社区里成为共识，哪个工具链缺口正在被填上。这些东西才是大家真正想听的干货。
参与这次分享的同事背景比较杂，有做CPU核的，有做验证的，也有做编译器工具链和应用层的。这就要求分享内容不能太偏某一个方向，得找到一个所有人都有感知的切入点。我们最后决定以“指令集演进如何向上影响软件、向下约束硬件”作为主线，把三个月的内容串联起来。事实证明这个角度效果不错，讨论环节明显比以往热闹。
如果你也在做RISC-V相关的开发，或者正准备入坑，这份梳理应该能帮你省下不少搜集信息的时间。下面按模块展开讲，每个部分我都会把背景、关键动态、以及对我们实际工作的影响一起说清楚。
2. 指令集层的演进：扩展提案从纸面走向落地
2.1 基础指令集冻结之后，扩展指令集成为主战场
RISC-V基础指令集早几年就已经冻结，这意味着G、C、M、A、F、D这些常用扩展的组合在很长一段时间内不会再有破坏性更改。基础ISA的稳定对工具链和操作系统是好事，编译器不用频繁适配，内核也不用跟着改。但这也意味着，整个生态的目光都转向了各类标准扩展的推进节奏上。
2026年年中这个时间点，最值得关注的几个扩展方向集中在向量处理、中断控制和内存模型这几个领域。向量扩展RVV已经有不少芯片在实装，但v1.0正式版本之后还有很多细节在打磨，比如不同向量长度下的性能表现、寄存器分组带来的上下文切换开销优化等。这些不是规范层面的问题，而是实现在具体芯片上之后才会暴露出来的工程问题。
中断控制器相关的扩展（比如CLIC）也在从草案走向实现。和之前的标准中断控制器相比，CLIC在低延迟中断处理上做了不少改进，这对实时性要求高的场景意义很大。我们组里做MCU的同事对这个进展尤其敏感，用他们的话说，CLIC如果能在更多芯片上得到硬件支持，有些场景下可以省掉一层软件模拟的中断派发逻辑。
2.2 RISC-V指令集扩展的模拟实现与验证
分享时大家讨论最热烈的一个话题是：面对还在草案阶段的扩展，怎么提前做实现评估和验证准备。做芯片设计的人都有经验，等工作组把规范彻底定稿了再动手，周期上往往来不及。所以我们内部习惯用模拟器加上快速原型平台来提前探路。
具体做法是，在QEMU或自研的指令集模拟器里先实现草案版本的扩展（例如向量扩展），跑一套针对性测试用例，评估指令编码和寄存器使用方式对代码密度、中断延迟、数据通路设计的影响。这样我们可以在草案阶段就把疑问反馈给工作组，同时也能提前评估未来要改动多少验证环境。
这套流程用下来，最大的收获不是实现了多少条新指令，而是逼着团队把规范和落地之间的差距提前看清楚。刚接触RISC-V设计的开发者，可能不太理解规范层面的一个细微选项会给硬件实现带来多大差别。举个简单的例子：向量扩展中配置向量长度的指令如果允许部分写入，硬件上就要额外考虑写屏蔽逻辑，这对数据通路面积是有影响的。这些细节不在模拟器里跑一遍，光读规范是感觉不到的。
2.3 指令集演进对CPU设计的具体影响
从CPU设计的角度看，指令集层的动态不是高高在上的规范文档，而是直接影响微架构权衡的约束条件。比如LSU（Load Store Unit）设计时，需要提前了解后续向量扩展访问内存的模式，是否支持非对齐访问，以及是否会引入更复杂的内存一致性需求。这些都对访存流水线的排队策略、跨时钟域处理方案有影响。
拿这次分享中提到的内存模型相关讨论来说，RISC-V在内存一致性上走的是比较开放的路子，允许不同实现选择不同的模型强度。这对高性能核的设计者是好事，灵活性更大；但对做验证的人来说是额外负担，因为形式化验证的复杂度会上升。我们在分享里专门用一个案例说明了这个问题：同样的并发程序，在不同的内存模型下会产生不同的执行结果，验证环境的抽象层级就得跟着调整。
指令集演进带来的另一个变化是自定义指令的空间。RISC-V的预留编码空间多，这对特定领域加速很有吸引力。但我们分享时也提醒大家，自定义指令不是随便定的，一旦加入，工具链、调试器、反汇编器都要同步适配，这个成本经常被低估。所以除非应用场景固定、收益明显，否则建议优先考虑标准扩展。
3. CPU微架构设计的新风向：从学术研究到工程落地
3.1 高性能核的关键技术路径
6到8月这段时间，RISC-V高性能核的讨论热度持续走高。几年前大家还在争论RISC-V能不能做高性能，现在的焦点已经切换到具体用什么微架构技术来提升性能。乱序执行、多发射、大窗口、高级分支预测这些经典CPU设计技术，开始被系统地迁移到RISC-V核上。
和x86以及ARM核相比，RISC-V高性能核起步晚，但后发优势很明显：没有历史包袱，可以按照现在能拿到的最先进工艺去设计。近期比较受关注的方向包括用定制化的访存流水线降低缓存缺失代价，以及通过更细粒度的电源门控来改善能效比。这些做法在商用核里已经比较成熟，但在开源RISC-V核里大规模的实现案例还不多，所以有团队公布相关经验时，参考价值很高。
分享时我特意强调了超标量设计中的取指宽度和译码复杂度问题。RISC-V的指令编码格式规整，译码逻辑相对简单，但变长指令（标准压缩指令）的存在还是给取指和译码阶段增加了一些麻烦。比如前端抓取16位和32位混合指令流时，指令边界对齐的预判逻辑要做额外的处理，处理不好会直接影响有效取指带宽。这些工程量上的差距，反过来也说明RISC-V非常适合教学和科研——因为踩坑的过程本身就是学习的过程。
3.2 缓存一致性、内存模型与多核互连
多核设计是高性能RISC-V处理器绕不开的环节。动态梳理里专门讨论了缓存一致性和互联总线的话题。和单核设计不同，多核环境下每个核看到的同一份内存，需要保证一致性协议不出错，同时还要尽量降低同步开销。ACE总线风格的一致性接口依然是常见的做法，但很多团队开始考虑在特定场景下用简化的自研协议来降低实现复杂度。
这里有个现实的问题：完整的一致性协议非常复杂，验证工作量巨大。所以不少团队会先做非缓存一致性的多核（也就是软件自己保证数据同步），等方案跑通了再逐步引入硬件一致性。这种小步快跑的做法对资源有限的团队很实用，我们在分享中也提到了这样规划的优势与风险。
另外，这类多核设计的验证，目前主要还是依赖随机测试加上定向测试的组合策略。不过随着RISC-V开源生态里形式化验证工具链的成熟，越来越多团队开始对关键协议模块做形式化验证，这能在早期发现一些随机测试很难命中的边界情况。
3.3 开源RISV-V核与商业核的同频共振
开源RISC-V核项目在这段时间里也有不少更新，比如广泛使用的Rocket、BOOM，以及更偏嵌入式场景的Ibex，还有一些新的面向AI加速的核在做公开的微架构说明。开源核的意义不只是给开发者一个免费可用的CPU，更重要的是它成了微架构研究和教学的公共平台。
分享中我们对比了开源核与商业核的定位差异：开源核通常更强调可读性、可配置性和可验证性，代码结构要照顾社区维护的便捷性，而商业核更强调PPA（性能、功耗、面积）的极致优化，代码风格不一定适合阅读和学习。但这几年有个好趋势，一些商业公司开始把自己的部分微架构设计经验通过开源项目释放出来，这对整个生态的工程成熟度是好事。
如果读者是学生或者刚开始接触CPU设计的开发者，我强烈建议把一两个开源核的RTL代码完整读一遍，配合文档和仿真环境，亲手跑一遍指令，比单纯看架构书收获大得多。做CPU设计不是背概念，是要对着代码看数据流和控制逻辑是怎么样协作的。
4. 软件工具链与生态成熟度：离“开箱即用”还有多远
4.1 工具链的进步和尚未解决的痛点
RISC-V要走向大规模商用，软件生态是不能回避的硬骨头。这次三季度动态梳理，软件工具链的变化占了相当大比重。GCC对RISC-V的支持已经比较成熟，LLVM也在快速追赶，两边在向量化、代码密度优化上的差距正在缩小。调试工具方面，OpenOCD和各类IDE对RISC-V的支持也明显比前两年更顺滑。
但大家实际用下来，还是有不少痛点。比如不同厂商的调试探针和调试协议实现存在兼容性差异，同一个调试脚本在这个板子上能跑，换个调试器就出问题。这类的兼容性问题往往是规范之外的定义模糊导致的，跟芯片设计阶段就做错了的情况还不一样，处理起来更麻烦。所以在芯片规划阶段，提前考虑软件工具的适配成本，不是可有可无的事。
编译器和工具链的目标不是为了“能编译”，而是为了“生成高质量的代码”。RISC-V的指令集相比ARM和x86少了很多隐含的寄存器状态，编译器生成代码的模式比较清晰，这对编译器开发者反而是一件比较省心的事。但支持向量扩展的自动向量化还在不断改进，能跑到什么程度，很大程度上取决于具体硬件实现提供的向量寄存器数量、宽度，以及是否支持 gather/scatter 等高级内存访问模式。
4.2 OS与虚拟化：嵌入式到服务器场景的跨越
操作系统支持方面，Linux对RISC-V的支持已经是主流状态了，内核里针对RISC-V的补丁和应用说明文档都在稳步增加。实时操作系统（RTOS）在RISC-V上的移植也比前几年轻松不少，各种RTOS官方或者社区都已经有了可用的移植。更重要的是，虚拟化方向上，软硬件协同的进展非常快——硬件辅助虚拟化扩展落地之后，RISC-V在服务器和云计算这种需要高隔离性、多租户部署的场景，才真正具备了资格证。
我们小组里有做虚拟化方向的同事，他专门提了一个观点：RISC-V的虚拟化支持虽然还在推进中，但好在设计清楚、不绕弯，按规范来实现的话，软件适配成本比预期低。这对做云计算基础设施的团队来说是个积极信号。但这也意味着，虚拟化涉及的中断虚拟化、内存管理单元虚拟化、设备直通等，未来会是软件社区重点发力的方向。
4.3 验证方法学与硬件仿真加速的参考实践
软件生态不只是应用软件，也包括验证工具链。RISC-V的验证是个大话题，很多团队都在摸索一体化的验证方案。这次分享中我们重点讨论了基于UVM的验证环境、仿真加速和FPGA原型验证这三件事怎么配合。
UVM是目前最主流的SoC验证方法学，RISC-V核的验证也大量采用这种方式。但CPU验证有个特点：需要跑大量指令序列，纯事件驱动的仿真速度太慢。所以常见做法是搭建指令级仿真器和RTL仿真对比的框架，跑回归测试时直接用指令级模拟器来生成预期结果，再用RTL仿真来比对。这个框架的关键在于“可追溯性”：RTL在执行任何一条指令时，要能准确回溯到指令级模拟器的状态，否则比对结果没有意义。我们用这套方式已经发现了不少数据库一致性问题，效率上比纯手写测试向量高很多。
FPGA原型验证则是另一个层级的问题。CPU设计频率高的时候，事件驱动仿真一秒钟只能跑几百条指令，完整启动一个操作系统内核可能要跑几亿甚至几十亿条指令，这在纯仿真环境下是不可想象的。所以高集成度的核在流片之前，基本都会走一遍FPGA原型验证，借助板卡上的DDR、PCIe等接口，直接在真实环境下跑起来，测试软件兼容性和启动流程。虽然FPGA上的频率比最终芯片低不少，但对于软件团队来说，能提前拿到硬件行为的参考，价值远大于频率损失。
5. 应用驱动下的RISC-V落地场景：端侧AI与边缘计算
5.1 向量扩展让RISC-V在AI推理领域获得新机会
AI加速是当前RISC-V生态最热门的应用方向之一，端侧AI推理更是绕不开的场景。RVV向量扩展之所以备受关注，就是因为很多AI推理算子本质上是批量的小数据运算，用向量指令来处理，效果比纯标量执行提升显著。尤其是int8量化模型、混合精度推理这类场景，RVV的并行度可以很好地发挥出来。
不少芯片公司在这个季度发布了面向端侧AI的RISC-V处理器方案，核心亮点基本都集中在支持RVV v1.0、针对特定神经网络算子做了指令级优化，以及集成了轻量级的NPU协作单元。我们内部总结的时候说，这已经不是“RISC-V能不能做AI”的阶段，而是“针对特定AI模型，RISC-V核的方案怎么做才能把能效打上去”的优化阶段。
从实际落地的角度，如果读者想在FPGA上跑一个RISC-V核并做AI推理实验，可以参考的思路是：选一个支持RVV的核，例如使用支持向量扩展配置的开源核，跑通Linux后，再移植推理框架，配合自写的汇编优化算子做性能对比。整个流程下来大概一两周，可以让团队很快建立起对向量性能和工具链成熟度的直观感知。
5.2 工控、汽车与高可靠场景的信号
工控和汽车是RISC-V另外一个非常现实的增长点。这些场景对指令集生态有一个共同要求：确定性和可验证性。RISC-V因为规范清晰、无历史包袱，在一些人看来比传统架构更适合做功能安全相关的设计。这季度就有一些和汽车功能安全相关的设计流程公开分享，讨论了故障注入测试、诊断覆盖率以及和底层硬件的接口。
对我们小组来说，工控和汽车场景的信号还不是马上要转化为内部项目的方向，但它提示了我们一个重点：芯片设计里“验证工具链的完善程度”往往决定了这个架构能不能进入高可靠领域。如果一个指令集生态连配套的故障注入工具、覆盖率分析工具都缺，那就算架构本身再安全，也没有办法向客户证明可靠性。RISC-V在这方面已经在补齐，但国际认证和工具成熟度还需要时间。
5.3 开发者生态与社区运营的几个体会
最后想聊聊开发者生态。RISC-V的社区活力和过去几年比，明显上了一个台阶。各大邮件列表、GitHub仓库、技术会议的互动频率都很高。尤其在国内，越来越多公司和高校在开源自己设计的核、验证环境和软件栈钙迁移经验。这对生态的良性循环帮助很大。
我们自己组里在参与社区时，有几个体会可以分享：第一，读规范的时候尽量直接看官方文档，不要只看二手博客，手边常备一份最新版的指令集手册会省很多事；第二，遇到问题优先去邮件列表或官方论坛搜索，很多疑问社区里都已经有人讨论过；第三，开源项目提PR之前，先看看维护者的提交风格和态度，尽量按照维护者习惯的格式提交，否则很容易石沉大海。
6. 常见问题与踩坑记录：我们小组在跟踪RV动态时的实操经验
6.1 阅读新扩展草案时，如何快速抓住重点
RISC-V扩展的草案文档动辄上百页，直接硬读效率很低。我们小组摸索出来的方法是：先看指令编码表，再读行为伪代码，最后才是文字说明。编码表能快速告诉你指令格式和操作数数量，行为伪代码能让你理解指令执行的逻辑，看懂了这两个部分，再去翻阅文字细节就有针对性了。
另外，草案里经常会用“V1.0 draft”之类的状态标识，阅读时要先确认版本。有些草案的早期版本和正式版存在破坏性差异，按过期版本做设计评估会导致返工。
6.2 评估一个开源RV核，应该从哪几个维度入手
分享会上大家问得最多的问题之一，就是开源RISC-V核怎么选。我的建议是不要只看GitHub星标数，要从这几个维度去评估：支持的指令集扩展是否和你的需求匹配（比如是否支持向量扩展），验证环境的完整度（有没有现成的UVM testbench、覆盖率报告），文档质量（有没有清晰的集成指南），以及社区维护活跃度（最近半年是否有实质性的代码提交）。
实际踩过的坑是：有些项目代码质量不错，但完全没有验证环境，集成之后出了问题很难定位是核的问题还是自己SoC集成的问题；另一些项目维护不频繁，适配新工具链需要自己改不少地方。团队如果没有专门的验证人手，选核时优先考虑验证配套完善的项目。
6.3 工具链版本与规范版本不匹配的排查思路
RISC-V生态另外一个常见坑是工具链版本和规范版本错位。比如某个扩展在你的核上已经实现了，但编译器版本太旧，生成的代码没有用上新指令；或者反过来，工具链默认产生了目标核不支持的指令，导致程序跑到一半就挂了。
排查这种问题的思路是：先用编译器的目标CPU选项看是否支持对应扩展；再用objdump把生成的目标文件反汇编出来，确认有没有不认识的指令；最后对照核支持的扩展列表做匹配。整个过程不复杂，但如果没有这个意识，出了问题很容易绕很久。我们这次分享还专门整理了一张排查步骤清单，方便组里新人参考。
6.4 在仿真环境里启动Linux常见失败原因小结
针对在RISC-V仿真环境里启动Linux这个经典操作，我们整理了最近的几个失败案例：第一类是内核镜像编译时架构配置错误，导致启动早期就跳到了非法指令；第二类是设备树里内存描述和仿真平台实际内存大小不一致，内核启动到内存初始化阶段就卡住；第三类是外设中断控制器配置不正确，导致内核在初始化中断的时候挂起。
这些问题的共性在于，它们都不是内核代码本身的问题，而是内核镜象、设备树、仿真平台三者之间的配置没有对齐。建议新手在搭建Linux环境时，先验证最简单的“裸机Hello World”工程，确认RTL环境没问题后再启动内核，否则问题叠加起来很难排查。
7. 后续关注方向与实操建议
7.1 下季度值得关注的指令集与微架构话题
展望下一阶段的技术动态，有几个话题我认为值得提前关注：向量扩展在编译器和算子库中的生态推动是否如预期那样顺利；面向服务器场景的虚拟化支持会不会有更多实现细节公开；以及低功耗RISC-V设计在可穿戴设备上的落地案例会不会增多。这几个方向分别对应着指令集、CPU设计、应用落地三个层面，对不同类型的团队都有参考价值。
再有就是之前反复提到的验证方法学演进。围绕RISC-V的随机指令生成、处理器核验证参考模型、覆盖率驱动的验证技术，近几年值得期待。CPU验证是所有CPU设计的成本中心，一旦这些方法学成熟起来，对小团队是极大的利好。
7.2 团队内部持续技术跟踪的小建议
在分享末尾，我们讨论了一个很实际的问题：怎么让小组内部持续跟踪技术动态，而不是每个季度临时抱佛脚。最后形成的建议是1-2个人轮流盯社区更新，每周整理一份短消息到内部频道；每月做一次15分钟的简要分享，每季度做一次综合分享。长期下来，团队对生态变化的感知会比大多数同行跟得紧，做技术选型时也更有底气。
如果有人想复刻我们这样的分享机制，还有一点小提醒：一定要把动态和技术影响分析结合起来，不要只做信息播报员。单纯说“某个规范更新了”，价值不大；把它翻译成“这个更新对我们正在设计的模块有什么影响、建议怎么调整计划”，团队成员才有兴趣继续听。
就我个人的经验而言，做这类技术跟踪分享最难的不是信息获取，而是坚持。网上关于RISC-V的各种动态每天都有，如果不梳理，很容易让人觉得信息量巨大却无从下手。但只要坚持每个季度系统性整理一次，半年之后，你对整个生态的感知深度会明显超过只看新闻标题的阶段。
