RISC-V遇上FPGA：22nm SoC FPGA的架构、开发与实战

高云半导体和晶心科技这则消息，在FPGA圈子里应该算得上一个里程碑事件：RISC-V CPU被完整地嵌入到了22nm SoC FPGA里。放在几年前，这种组合很难想象——一家本土FPGA厂商，一家老牌RISC-V CPU IP公司，把“处理器+可编程逻辑”塞进同一颗22nm芯片。很多做硬件的人看到标题就划走了，觉得又是一条新闻通稿，但实际这事对FPGA工程师、嵌入式软件工程师、甚至刚入门的学生，都值得好好拆一遍。这篇文章我就从常年调板子、写Verilog、也被SoC启动流程折腾过的人的角度，把这则消息讲透：它到底改变了什么，拿到手之后怎么用，以及开发中会遇到哪些坑。

1. 这条新闻到底在说什么：RISC-V CPU被塞进了SoC FPGA

1.1 为什么这件事值得FPGA工程师关注

先说最核心的问题：FPGA里放处理器又不是新鲜事。Xilinx的Zynq、Intel的SoC FPGA，早在十多年前就把ARM核和可编程逻辑封装在同一颗芯片里了。那高云和晶心这次合作，凭什么值得单独聊？

区别最大的一点在于CPU指令集。之前的主流通用SoC FPGA里嵌的基本都是ARM Cortex-A系列，那是商业IP，授权费不低，而且核心微架构是黑盒，用户没法自己改。而RISC-V是开放指令集架构，它的意义不是“省了几块钱授权费”这么简单，而是整个处理器生态从源头开放了——指令集规范公开，CPU核可以替换、可以定制、可以选择不同供应商。

把这层逻辑再往深推一步，晶心科技（Andes Technology）在RISC-V IP领域做了很多年，不是PPT公司，是有大量流片记录和量产客户的。高云则一直在做FPGA，而且这次做到22nm工艺节点。两边一结合，等于给开发者提供了一个新选项：一颗芯片上，既有可编程逻辑，又有一个商用级、可跑Linux的RISC-V CPU子系统。

对FPGA工程师来说，这意味着以后做异构计算平台时，不再只有ARM这一条路了。想研究CPU微架构？想在处理器核里加自定义指令？想做一个完全自主可控的SoC？RISC-V SoC FPGA是个很合适的起点。

1.2 22nm工艺在FPGA上意味着什么

很多人对“22nm”没概念，觉得不就是数字小一点吗。实际上，在FPGA领域，工艺节点直接决定了这颗芯片的天花板。

早期FPGA用90nm、65nm，逻辑容量小、功耗大、跑不了太高频率。后来28nm成为长寿命节点，Xilinx 7系列就是28nm的，到现在还有大量设备在用。22nm相对28nm，在相同功耗下能塞进更多逻辑资源，在相同逻辑规模下功耗更低，同时晶体管尺寸缩小带来更短的布线延迟，逻辑跑高频率更容易。

还有一点容易被忽略：更先进工艺意味着可以集成更多硬核模块。SerDes高速收发器、PCIe硬核、DDR控制器、AD/DA接口——这些硬核在22nm上集成度更高，性能也更好。对用户来说，最直观的收益是：做高速数据采集、无线通信、图像处理这类项目，一颗芯片能干的活更多了。

另外，22nm在今天并不是“激进”的工艺节点，而是成熟、量产稳定、成本可控的选择。用在这个级别的SoC FPGA上，既保证了性能，又不会把价格做到天上去。这对想用FPGA做产品、而不是只做原型验证的团队来说，非常关键。

2. CPU子系统不是一颗孤零零的内核：拆开看SoC FPGA

2.1 子系统里都有什么

新闻标题里有个词很关键：Subsystem，也就是子系统。很多人以为SoC FPGA就是“一颗可编程逻辑里塞了个CPU核”，实际完全不是。CPU之所以能独立跑操作系统，靠的是它背后那一整套基础设施。

一个完整的CPU子系统至少包含这些部分：

• CPU核心：这里是RISC-V核心，可能带浮点单元、SIMD扩展，支持MMU（内存管理单元），这样才能跑Linux。
• Cache：L1指令缓存和数据缓存，通常还有L2缓存，用来缓解CPU和DDR之间速度不匹配的问题。
• 中断控制器：管理来自定时器、外设、FPGA逻辑的中断，是CPU与外设通信的“电话总机”。
• 总线互联：CPU、DMA、DDR控制器、外设IP之间通过总线连在一起，常见的有AXI/AHB/APB。
• 外设集合：UART、SPI、I2C、GPIO、定时器、看门狗、PWM这些基础外设。
• DDR控制器：没有DDR控制器，CPU没法跑大程序，Linux更是无从谈起。
• Boot ROM和启动逻辑：上电后CPU从哪取第一条指令，怎么把固件从Flash搬到DDR，都靠这里控制。

你可以把整个子系统理解成一台“没有外壳的小电脑”，FPGA逻辑则是围绕在这台电脑周围的“可重构硬件加速区”。CPU负责跑逻辑复杂、流程控制强的软件，FPGA负责跑数据量大、并行度高的算法。各干各擅长的。

2.2 CPU与可编程逻辑怎么协同工作

光把CPU和FPGA放在同一颗芯片上是不够的，关键是它们之间怎么通信。SoC FPGA里，CPU子系统和可编程逻辑之间通常用高速总线连接，比如AXI。

实际开发中，这种协同有三种典型模式：

第一种是寄存器读写模式。FPGA里做一个自定义IP，IP内部有一组寄存器。CPU通过总线往这些寄存器写控制字、读状态位，就像操作一个普通外设。这种方式最简单，适合控制类应用，比如让FPGA启动采集、查询采集是否完成。缺点是带宽低，不适合大量数据传输。

第二种是DMA批量搬运模式。FPGA把数据处理完，把结果通过DMA直接写到DDR的指定地址，写完以后给CPU发一个中断。CPU收到中断后直接从DDR读结果。这种方式不占CPU时间，数据传输效率高，是做高速采集、信号处理时的标准方案。

第三种是共享内存的模式。CPU和FPGA都能访问DDR里的同一块内存区域，通过ring buffer或者其他数据结构协作。这套逻辑在软件上更像在写多核通信。

无线通信、软件无线电、视频ISP处理这些场景，基本都是DMA+中断的玩法。CPU处理协议栈、管理流程，FPGA处理滤波器、FFT、编解码、自定义协议，这在性能上比全软件方案高一个量级，比纯FPGA方案更灵活、更容易维护。

3. 哪些场景会先吃螃蟹：从无线通信到边缘智能

3.1 无线通信里的高速数据链路场景

先聊一个热搜词里很多人关心的东西：FPGA在无线通信系统中的作用。其实这正是SoC FPGA最典型的应用方向。

无线通信链路里，FPGA承担着物理层里那些高吞吐量的信号处理任务。比如DDC/DUC（数字下变频/上变频）、CIC滤波器、FIR滤波器、FFT、信道估计、CRC校验，这些算法并行度高，在CPU上跑循环效率低，但在FPGA里就是一条流水线的事。

4G/5G基站里的RRU（射频拉远单元），早期方案是FPGA+DSP，后来是FPGA+ARM，现在用RISC-V SoC FPGA也能搭出一套完整链路：FPGA做数据通路和协议加速，RISC-V核跑控制平面，上位机通过网口或者PCIe下发配置。

这里面有一个绕不开的接口就是JESD204B。高速ADC/DAC现在基本都是JESD204B接口，跑在几Gbps的串行链路上，用来连接FPGA和射频收发芯片。我记得自己第一次调JESD204B的时候，链路一直建立不起来，后来发现不是逻辑问题，是参考时钟的抖动太太，换了一颗低抖动时钟芯片就好了。这类问题在射频系统里层出不穷，而FS方案里，FPGA里要用到带高性能SerDes的器件，如果SoC FPGA集成度不够，还得外挂SerDes芯片，麻烦得多。这次22nm SoC FPGA能把CPU、SerDes、可编程逻辑放一起，对这类应用就是直接受益。

3.2 边缘智能、工业控制与机器视觉

除了无线通信，边缘侧AI推理也是RISC-V SoC FPGA很有发挥空间的场景。

边缘AI有个特点：算法模型更新快，但功耗和成本卡得严。纯ASIC专用芯片灵活性差，纯CPU性能不够，纯FPGA开发效率又低。SoC FPGA的方案就很巧妙：RISC-V核跑AI软件框架，做预处理、后处理和调度；FPGA里部署量化后的CNN加速器，并行计算卷积层；两者通过DMA高速交换数据。

工业控制场景也类似。运动控制卡里，往往需要一个处理器跑插补算法和人机交互，同时需要FPGA产生高速脉冲、读编码器、做IO控制。过去是“ARM主控芯片+FPGA”两颗芯片，外加通信总线。用了SoC FPGA之后，一颗搞定，板子面积缩小，延迟还更低。

机器视觉也吃这套方案。相机采集图像，FPGA做Sensor驱动、图像预处理、ISP，然后送给CPU跑视觉算法。在工业相机、无人机、智能安防这类产品里，一颗SoC FPGA能替代掉“主控+FPGA+外部DDR”的复杂架构。

4. 拿到RISC-V SoC FPGA之后怎么快速上手：开发流程与踩坑记录

4.1 从工具链到第一行代码的完整流程

看到这里，可能有人想问：这东西开发起来是不是很复杂？我按自己的经验说一下，一套RISC-V SoC FPGA方案的开发流程大致分六步。

第一步，安装厂商IDE。高云有自己的FPGA开发环境，叫GOWIN EDA，集成了工程管理、综合、布局布线、仿真、下载等功能。安装完，在工程里新建一个SoC工程，里面会有CPU子系统的图形化配置界面。

第二步，配置CPU子系统。这一步像拼电脑：时钟主频设多少，DDR类型和位宽选多少，哪些外设要打开，中断优先级怎么设。配置界面会生成一个框图，能看到CPU、总线、外设、DDR控制器怎么连的。

第三步，添加FPGA逻辑。在框图的FPGA侧，添加自己的Verilog/SV模块，比如一个数据采集模块、一个算法加速模块。通过系统生成的接口把这些模块接入总线。

第四步，综合布局布线。这一步和普通FPGA流程一样，等Implementation跑完，看资源占用和时序报告。如果时序不收敛，可能需要调整CPU时钟频率或者优化逻辑结构。

第五步，写软件代码。CPU侧的代码用GCC工具链交叉编译，晶心用的是Andes自己的GCC分支。代码逻辑就是普通的嵌入式和Linux开发，操作寄存器、处理中断、跑RTOS或者Linux应用。

第六步，生成BOOT镜像，烧录启动。把FPGA bitstream和CPU固件打包成一个烧录文件，写进QSPI Flash，上电后系统起来，串口打印启动日志。

第一次跑通时，那种“一颗芯片上面同时跑着逻辑和操作系统”的感觉，还是挺奇妙的。

4.2 我第一次跑通RISC-V硬核时踩过的三个坑

流程听上去顺，但实际操作中坑不少。我分享三个最典型的。

第一个坑是启动模式没配对。板子烧完程序后完全没反应，串口什么都不输出。排查半天发现是启动引脚电平设错了，CPU没从QSPI Flash启动，而是试图从别的设备启动。这种问题看不出逻辑错误，只能拿万用表量引脚电平，或者看启动模式寄存器的配置。建议拿到新板子先检查启动配置位，确认上电顺序。

第二个坑是DDR初始化参数不对。RISC-V CPU要跑Linux，DDR是必须的。DDR控制器的时序参数、地址映射、Training流程，一旦配置不对，表现就是系统起来后动不动死机，内存压力一大就崩溃。DRAM型号不同，参数也不同，只能老老实实按DDR手册配置，然后用内存测试程序反复跑。

第三个坑是中断没连好。FPGA里做了一个自定义IP，希望数据准备好后通知CPU。结果CPU永远收不到中断，查了半天，发现给中断控制器发请求的引脚写错了，信号根本没送到中断控制器。这种联调问题最考验人，得一边看FPGA仿真波形，一边在CPU侧打log，两头汇合才能定位。

这三个坑基本是SoC FPGA开发里最常见的拦路虎，提前做好心理准备，能省不少时间。

5. 常见问题速查与排障经验

5.1 RISC-V核到底有没有经过量产验证

很多人看到RISC-V第一个反应是：这东西经过量产吗？靠不靠谱？我直接说结论：不能一概而论，关键看用的是哪个核。

拿开源社区里的Ibex核来说，这是一个面向嵌入式、低功耗场景的RISC-V核，很多研究项目、教学项目都在用，也有企业在一些物联网芯片里集成过。但它定位偏轻量级，不是那种适合跑Linux的应用级核。Andes的RISC-V核则是商业IP，在MCU、AIoT、存储控制、无线连接等领域有大量流片记录。所以“RISC-V有没有量产”这句话，要拆成“哪个核、用在什么工艺、跑什么频率”来回答。

另一个判断维度是看生态配套。量产的芯片需要完整的软件工具链、启动代码、调试器支持。If the vendor提供了完整的SDK、BSP、Linux移植包，说明这个核起码在工程上是可落地的。反过来，只有一个仿真模型、没有配套软件栈的核，那多半还在早期阶段。

我自己选型的经验是：优先选有成熟编译器支持、有第三方调试器适配、能找到量产案例的RISC-V核，而不是只看IPC跑分或者宣传资料。在SoC FPGA方案里，因为FPGA逻辑可以随时改，核选错了还能换，风险比做ASIC低得多。

5.2 高速接口、电源纹波这些“隐形杀手”

SoC FPGA大多要搭配高速ADC/DAC和高速串行收发器用，JESD204B就是绕不开的一个重点。

我在调JESD204B时总结了一条经验：链路建立失败，八成不是逻辑问题，而是时钟和电源问题。JESD204B对参考时钟的抖动要求极高，如果参考时钟质量不好，多通道的同步和确定性延迟就会出问题。有时候逻辑怎么看都对，但时钟源略差一点，链路建立就不稳定。

还有一个高频翻车点是电源纹波。高速数据转换器对电源纹波非常敏感，电源上哪怕有几十毫伏的纹波，都可能直接出现在ADC输出频谱里，表现为杂散抬高、SFDR下降。身边做RF SoC的同事就遇到过：ADC采集出来的信号底噪比预期高很多，最后发现是给模拟供电的DC-DC纹波太大，加了一级LDO之后，频谱立刻干净了。

所以做SoC FPGA + 高速ADC/DAC的设计，一定要重视三件事：参考时钟的质量、电源的设计（尤其是模拟电源和数字电源隔离）、PCB上的阻抗连续。这三样做好，调试时间能减少一半。

5.3 CPU与FPGA联调时的软硬件分界线

最后说一个调SoC FPGA最常见的困境：系统出错时，到底是软件问题还是硬件问题？

我的排查习惯是先划边界。第一步，确认CPU侧的软件基本能跑。最小系统起来，串口能打印日志，内存测试能过，说明CPU子系统和DDR没问题。第二步，确认FPGA逻辑的基本功能。用简单的寄存器读写测试，CPU写一个值，FPGA回读，看数据对不对。如果这一步过不了，大概率是总线地址映射、字节序、接口时序的问题。

第三步才做复杂联调。数据链路出错时，先在FPGA内部抓信号（用逻辑分析仪IP或者在线调试工具），确认FPGA侧输出的数据正确，再去看CPU读到的是什么。两个结果一对，就能知道是数据在DMA传输中丢了，还是CPU软件处理错了。

把问题定位到具体环节之后，剩下的就是耐心把每个子模块的日志打开，逐个击破。我这几轮折腾下来最大的体会是：FPGA和CPU联调，最忌讳“两头一起猜”。把软件、硬件、接口各自的测试做扎实，再复杂的系统也能按步骤解开。

现在再回头看高云和晶心这则消息，它真正的价值不只是多了一款SoC FPGA产品，而是让RISC-V和FPGA这两个生态真正走到了一起。FPGA工程师多了一个可以深入理解的处理器平台，嵌入式工程师多了一个可以自由扩展硬件的实验田。行业里喜欢说“软件定义硬件”，RISC-V SoC FPGA把这句口号往前推了一大步——处理器可以定制，硬件可以重构，软件可以跑Linux，这种全栈开放的平台，在以前确实不多见。接下来就看开发者和生态怎么把它玩起来了。