这阵子集中做了一块国产RFSOCFPGA双芯架构的宽带高速信号处理板从方案评估、器件选型到回板调试、跑通数据链路整套流程走下来踩了不少坑也积累了一些值得记录的经验。做这类板卡的人应该都有同感单看RFSOC的集成度确实高但真到宽带多通道实时处理的场景单颗芯片的资源和IO往往撑不住所以就有了“RFSOC负责射频采样与前端处理、FPGA负责数据调度与复杂算法”这种双芯分工的架构。这篇文章我会把整个设计和实现过程按实战顺序拆开讲内容包括为什么非要双芯组合、两颗芯片之间怎么分活、数据接口怎么选型、带宽怎么估算、时钟和电源这些“硬骨头”怎么啃以及调试阶段最容易翻车的地方。内容面向硬件工程师、FPGA逻辑工程师、嵌入式软件工程师也适合正在评估类似方案的项目负责人参考。如果你正准备设计一块类似的高速信号处理板或者已经在调JESD204B/高速串行接口的路上这篇应该能帮你少走不少弯路。1. 为什么非要用“国产RFSOCFPGA”双芯组合先算清楚这笔账1.1 单颗RFSOC的瓶颈出现在哪里说到宽带高速信号处理第一反应往往是“用一颗RFSOC全搞定”。RFSOC的好处大家都知道射频直采直发内部集成了高速ADC/DAC、可编程逻辑PL和ARM处理器PSBOM面积小、链路短、开发周期相对集成方案要短得多。但实际做系统方案时我越来越多地发现单芯方案在一些场景下并不好使。举一个实际算账的例子。假设系统要求是4通道、单通道500MHz带宽的中频直采接收ADC采样率定在1.2GSPS、16bit精度。光接收链路原始数据率就是4乘1.2G乘16bit等于76.8Gbps也就是9.6GB/s。即便在RFSOC内部先做数字下变频DDC把有效带宽压到500MHzIQ各16bit输出那也还有4乘500M乘2乘16bit即64Gbps的吞吐。这部分数据如果要实时做FFT、测向算法、脉冲参数测量或者要落盘存储单靠RFSOC内部的DSP和查找表资源往往会非常紧张。更麻烦的是资源冲突。RFSOC的PL资源要同时承担射频数据搬移、DDC/DUC逻辑、PS接口的AXI互联、DDR控制、中断管理等杂活再塞入复杂的基带算法和协议处理布局布线很容易时序收敛不了。调一个不是瓶颈的模块会连累整条射频链路。所以这块板子的定位想清楚之后我很快就决定了双芯架构RFSOC聚焦射频采集和预处理外挂一颗资源更充裕的FPGA做数据调度、算法加速和对外高速接口。两颗芯片各干各擅长的事开发和调试也能并行推进。1.2 双芯之间的分工逻辑谁做射频谁做处理双芯架构听起来简单但脏活累活怎么分其实需要很细的考虑。我在这块板子上最终的分工是这样的RFSOC负责射频相关的所有工作多通道ADC采样、DAC发射内置DDC/DUC和抽取/内插滤波增益控制以及和射频前端低噪声放大器、衰减器、滤波器的SPI配置。这部分如果放到外部FPGA里做等于要用FPGA的GTH/GTY高速收发器直接接收JESD204B数据流开发复杂度和风险会大幅增加没必要。外部FPGA承担的则是更“业务化”的处理多通道数据的汇聚与分发、大点数FFT/信道化、脉冲检测与参数测量、数据压缩与格式化、对外PCIe/SRIO/光纤接口以及和上位机之间的命令控制链路。这里有一个容易被忽略的好处RFSOC内部的中频处理是相对通用的射频链路定型之后基本不会大改而业务算法在项目过程中会频繁调整。把业务算法放到外部FPGA改版时只需要动这一颗FPGA的逻辑和固件射频模块可以保持稳定。这个解耦在项目交付阶段给我省了非常多的事。1.3 国产器件的选型考虑不要只看资源表既然标题里定了“国产RFSOC”那就得说说选型时容易踩的坑。很多人在国产器件选型时只看逻辑资源、DSP数量和ADC/DAC采样率这几个数字好看就定了。但实际工程里更关键的反而是这几项第一是高速串行收发器的速率和误码表现。RFSOC和FPGA之间如果走1x/4x SerDes线速率可能到10Gbps以上这时收发器在高温下的抖动和误码率直接决定系统能不能稳定跑。选型时建议重点对比收发器在什么线速率下有完整的误码率测试报告。第二是PS端ARM的外设完整度和软件生态。RFSOC的ARM要跑Linux以太网、串口、SD/eMMC、DDR控制器这些能不能稳定工作启动镜像怎么固化工具链是否顺手都决定了软件开发周期。第三是工具链成熟度。国产FPGA的IDE这些年进步明显但插件的稳定性、综合编译速度、在线逻辑分析仪等Debug工具的易用度和国外一线厂商的差距仍然存在。这不是说不能用而是要提前安排测试板或者参考板把关键流程跑一遍别等原理图都画完才发现某个IP核没有对应版本。选型阶段我列过一个简单的评估表把RFSOC和FPGA的关键指标、功耗、封装、工具链成熟度、供货周期逐项打分最后定下来的组合是射频前级用带4路3GSPS级别ADC/DAC的国产RFSOC外部处理端用一颗逻辑资源中等偏上、带8路以上10Gbps收发器的国产FPGA。整个过程中最花时间的不是对比性能参数而是把两份参考设计和评估板的功耗数据拿来核对电源预算。2. 双芯架构的数据通路接口选型、带宽估算与帧格式设计2.1 端到端带宽需求估算从采样率开始推设计双芯系统第一步永远是算清楚端到端带宽。很多板子做出来跑不通或者跑到一半频繁丢数根子在方案阶段没有把每一级接口的水位算准。我习惯的做法是画一条数据流水线从天线口的模拟信号开始一级一级标出数据率。拿我这块板子的接收链路举例第一级是ADC采样。ADC工作在1.2GSPS、16bit4通道的原始数据率是76.8Gbps。这一级主要在RFSOC内部处理不涉及芯片间传输但要注意芯片内部PL到数据通路之间是否有足够的位宽缓冲避免采样数据在内部堵塞。第二级是DDC下变频。通过数字混频和抽取滤波把有效带宽从采样率降下来。假设抽取因子设为2输出IQ各16bit那么4通道最终的数据率就是4乘600M乘2乘16bit等于76.8Gbps。注意DDC做完之后数据率不一定比原始数据率低因为IQ双路本身会带来数据量翻倍。第三级才是关键RFSOC的PL把DDC后的数据传给外部FPGA。这里传输方式如果选择4路10Gbps的SerDes理论带宽为4乘10Gbps减去协议开销实际可用带宽大约在34到36Gbps左右。如果你的需求是76.8Gbps那显然不够用。这台板子的办法是把DDC后的数据经内部进一步做信道化或抽取降速同时只把有效信号带宽内的数据发送出去。也就是说链路预算的计算要追溯到“最终要输出给后端的有效数据率”而不是笼统地拿采样率乘位数。表格式的估算能让人看得更直观链路节点数据率传输介质说明ADC原始采样76.8GbpsRFSOC内部4ch x 1.2GSPS x 16bitDDC后IQ76.8GbpsRFSOC内部4ch x 600MSPS x 2 x 16bit二次抽取后19.2GbpsRFSOC-外部FPGA只送有效带宽外部FPGA-DDR120Gbps理论DDR4接口实际考虑刷新与效率FPGA-上位机25.6GbpsPCIe3.0 x8 / 光纤压缩后数据这个表做完之后接口方案的取舍就清晰了RFSOC到外部FPGA之间并不需要盲目追求最高速率真正该做的是在RFSOC内部把数据尽量压缩降低后续所有环节的压力。2.2 RFSOC与FPGA之间的高速接口选型两颗芯片之间的接口是我在这类项目里花时间最多的地方没有之一。常见的选项有并行LVDS、JESD204B、Aurora 8B/10B、SRIO、PCIe。并行LVDS是早期中频数字化板卡常用的方案优点是协议简单、延迟低、不需要高速收发器缺点是引脚消耗极大几十对差分线布起来非常痛苦而且千兆级别的同步时钟在PCB上对等长要求很苛刻。对于RFSOC到外部FPGA这种几十Gbps的吞吐需求并行LVDS基本可以排除。JESD204B是ADC/DAC和FPGA/ASIC之间最主流的接口标准但通常是FPGA作为接收端去接ADC芯片RFSOC和FPGA之间用JESD204B更多是把RFSOC模拟出来的数据在内部打包成JESD204B帧格式发给外部FPGA。这样做的好处是链路有完整的数据对齐和误码监控机制SYSREF同步可以严格保证多通道间的确定性延迟。缺点是配置参数多Lane数、帧格式、K字符、多帧对齐这些概念新手很容易晕。Aurora协议则是Xilinx生态里很常用的轻量串行协议如果我们用国产FPGA也有对应的高速串行接口方案。它比JESD204B更容易上手灵活度高线速率和通道数可以自定义。缺点是协议开销相对高一点8B/10B编码会有20%的带宽损失对于10Gbps的物理链路实际有效带宽也就8Gbps。SRIO和PCIe则更偏系统级互连如果两颗芯片之间除了纯数据搬运还需要做地址映射、消息传递那么它们是更合适的选择。我在实际项目中最终用的是JESD204B方案原因有两个一是链路本身内置了确定性延迟机制多通道之间的一致性对齐有保障这在测向、波束形成场景里是硬指标二是JESD204B的误码检测比较完善能通过Lane的误码计数快速定位物理链路问题。代价是要花时间把JESD204B的子类、多帧长度、SYSREF时序这些参数彻底搞懂。2.3 帧格式与流量控制避免乒乓缓冲失效的细节芯片间传输一旦上了高速串行链路就不能像寄存器那样敲一个值就完事数据必须以帧为单位组织。帧格式设计看起来是个纯软件/逻辑问题但设计不好直接导致后续处理单元解析困难、丢帧、缓存溢出。我这块板子的帧格式参考了常见的做法。帧头使用固定字节数比如4字节同步字然后是通道号、数据属性、时间戳之后是有效负载数据帧尾附带CRC32校验。时间戳非常重要尤其是多片同步或者长时间采集的场景没有时间戳后面做数据关联和波形对齐会难到怀疑人生。流量控制是另一个容易被忽视的点。两颗芯片之间如果只靠“发完就完”接收端缓存溢出几乎是必然。所以必须设计背压机制。在JESD204B这类协议里标准本身并不提供传输层的反压机制数据是按速率持续流动的。我这边把处理链路设计成外部FPGA内部的接收缓冲接近半满时通过一个低延迟的GPIO或者带内标志通知RFSOC侧暂停发送或者让发送端降低有效数据速率。这个背压不一定要断流可以是通过动态调整抽取因子或丢弃非关键通道数据来实现。3. 硬件实现中的“坑位”时钟、电源与PCB布局3.1 时钟设计采样时钟的相位噪声直接决定系统底噪高速信号处理板的时钟设计在很多项目里是被低估的。我见过不少板子逻辑都能跑通但射频指标一直上不去最后排查来排查去问题出在采样时钟的相位噪声。采样时钟并不是一个“能出时钟就行”的信号它本质上参与ADC的量化过程相噪差ADC的无杂散动态范围和信噪比会明显恶化。具体到双芯架构RFSOC和外部FPGA还需要考虑时钟同步的问题。我的做法是做一个时钟树用一块低相噪的PLL芯片产生系统参考时钟再分配出几路一路给RFSOC采样时钟一路作为JESD204B的SYSREF同步信号一路提供给外部FPGA的参考时钟。所有时钟最好同源这样两颗芯片之间的采样相位关系才是确定的。PCB布线时SYSREF要和采样时钟做等长匹配。很多第一次做JESD204B的人会在概念里认为SYSREF只是一个“参考信号”走线长短无所谓结果多芯片同步时对齐一直不稳定折腾很久才发现是SYSREF相对采样时钟的时序裕量不够。3.2 电源树设计数字噪声是如何混进射频通路的双芯高速板卡的电源设计难点在于“同时伺候好数字和模拟”。RFSOC内部的RF采样电路对电源噪声极其敏感而旁边的FPGA又是功耗大户开关电源的纹波和开关噪声很容易通过平面耦合到射频区域。我的电源树是按“分区供电”的思路做的。数字大电流部分FPGA核心、SerDes收发器、DDR使用高效率的DC-DC模拟部分RFSOC的ADC/DAC供电、时钟芯片则使用低噪声LDO。DC-DC的开关频率尽量避开RFSOC采样频率及其整数倍不然开关纹波会以混叠分量的形式出现在ADC输出频谱里那个杂散很难滤除。还需要注意的是磁珠和滤波电容的位置。磁珠用来隔离DC-DC和模拟LDO的输出但磁珠本身在特定频段会有阻抗峰值选型时要看阻抗特性曲线而不是只看直流电阻。电源平面切割也要谨慎确保模拟地和数字地只有一个明确的单点连接参考避免让回流电流绕着板子跑一圈。3.3 PCB叠层、阻抗与布局给高速链路留好退路双芯高速板的PCB设计我个人的建议是最少8层常规做到10到12层会更舒服。层叠安排上表层走高速串行差分线内层要有完整的参考地平面关键信号层之间不能随便跨越分割。阻抗控制方面10Gbps级别的JESD204B差分线要按100欧姆差分阻抗设计单端高速信号按50欧姆。需要注意的是国产板材的介电常数和损耗因子与常规FR4有差异做阻抗计算时要用厂家提供的实际参数不要照抄网上模板。布局上的一个经验是RFSOC的射频输入输出尽量靠近板边连接器模拟前端区域要和其他数字区域隔开必要时用屏蔽罩或者地孔墙做隔离。FPGA放置在RFSOC的另一侧两颗芯片之间的SerDes走线尽量短、少打孔换层。如果顶层实在走不通必须换层时要保证成对信号线同层换层且换层位置附近有足够的地孔伴随。另外强烈建议在高速链路上预留测试点至少把时钟信号和一组差分数据引到测试焊盘上。调试的时候如果没有这些测试点只能拿示波器探头在细间距的BGA扇出上硬碰非常痛苦。4. 调试与验证从串口打印到第一条稳定波形4.1 上电时序和启动的优先级双芯板卡回板后第一件事不是写逻辑而是检查上电时序。RFSOC、FPGA、DDR、时钟芯片各有各的上电顺序要求电源轨电压异常导致芯片损坏的例子并不罕见。我调试时会先做一次完整的电源测试用可编程电源限流上电逐路测量电源轨的电压和上电顺序确认没有短路然后再进入启动流程。启动的顺序应该是时钟芯片供电并锁定 - PS端ARM启动通过串口打印信息确认运行 - 加载PL比特流 - 通过内部寄存器访问确认两颗芯片之间的SerDes链路训练成功 - 最后才是数据通路的跑数验证。很多团队一上来就加载完整逻辑结果一片黑不知道是时钟没锁、DDR初始化失败还是SerDes没对齐。把启动流程拆成多个可观测的里程碑每个阶段都有对应的串口打印或状态寄存器可以查调试效率会高很多。4.2 从串口打印到第一条波形一条亲测有效的调试路径这块板子的调通路径我按下面的顺序走基本是顺畅的确认PS端Linux启动正常串口能敲命令DDR读写测试通过。这一步能排除RFSOC的ARM最小系统问题。加载一份只包含内部回环的最小比特流在RFSOC内部把ADC采样数据直接回环到DAC用频谱仪看输出信号是否正常。这一步验证的是射频前端、ADC、DAC本身的工作状态。开启JESD204B链路在外部FPGA里写一个接收帧检测模块统计SYSREF同步状态、帧同步状态、链路误码率。链路指标达标后再进行下一步。建立整条数据通路用信号源产生单音信号从上位机抓取FFT结果确认频率和幅度都正确。测试中我发现一个比较隐蔽的问题链路偶尔会出现周期性误码单独跑回环却一切正常。最后定位到是SYSREF信号的重复触发时序和JESD204B的本地多帧时钟边界没有完全对齐导致每隔一段时间出现一次帧对齐丢失。解决办法是在配置链路时把SYSREF的触发窗口拉长并且保证SYSREF到达后留有足够的建立保持时间。这类问题用误码计数是最容易发现的所以调试代码里一定要有在线误码统计别等到上位机看到错误数据才往回追。4.3 实测吞吐率、误码率与整机老化数据通路跑通之后还要做两个维度的验证一个是极限吞吐率一个是长稳老化。极限吞吐率测试我是这样做的在外部FPGA内部生成伪随机数据灌入JESD204B上行链路另一侧接收并实时比对数据统计误码率。好的高速串行链路应该在10Gbps线速率下单Lane误码率低于10的负15次方级别如果明显高于这个水平就要检查眼图、时钟抖动和电源噪声。长稳老化同样重要。我遇到过在实验室常温下一切正常但连续跑24小时后开始偶发丢数的情况。原因是部分高速信号路径在温度升高后抖动增大达到了接受端的时序余量边缘。解决思路是优化接收端均衡参数或者在PCB上给主要芯片增加散热片。这块板子在高低温箱里的表现也验证了不少设计余量比如某些DDR控制器参数必须在低温下重新训练这类问题只能在温循测试中暴露。因此如果项目周期允许一定要留出足够的老化测试时间窗口别把高低温测试压缩到最后一周。5. 工程化细节国产器件项目里很容易被低估的工作量5.1 开发工具链、IP核与文档的匹配国产RFSOC和FPGA各自的工具链都在快速迭代但版本之间的兼容性仍然是个大问题。不同版本的IDE里IP核参数接口可能变化加密IP的授权方式也可能不同。我在这块板子上就遇到过RFSOC侧用某个版本的编译工具链生成的比特流在固件镜像打包时才发现启动文件格式不匹配被迫升级了工具链版本结果个别IP核又要重新配置。所以一定要尽早固定工具链版本同一项目组统一环境。原理图、管脚约束、时钟约束、上电时序这些文件要有严格的版本管理最好用Git。管脚分配是一件非常繁琐的工作尤其是双芯片设计管脚交叉核对稍有疏忽就可能造成PCB报废。建议在原理图设计阶段就写好管脚分配表并编写脚本自动核对FPGA约束文件和原理图网表是否一致。5.2 国产器件的参考设计与支持渠道做国产器件项目参考设计的价值怎么强调都不为过。拿到评估板或参考设计后第一件事不是直接抄而是理解每一颗芯片的电源连接、时钟路径、复位逻辑。很多国产芯片的数据手册在细节上写得不够细致参考设计反而是最可靠的信息来源。另外厂商FAE的支持渠道要提前建立好。JESD204B链路调不通、寄存器配置与数据手册不一致这类问题在国产器件上出现的概率相对更高。我建议在项目启动时就拉一个和器件原厂、代理商的沟通群遇到问题第一时间同步log和寄存器截图很多疑难杂症靠原厂FAE的经验能很快定位。5.3 监控、保护与可测试性设计给板子留好后路最后说一个很多人项目中期才后悔的点板卡的可测试性和保护机制设计。双芯板卡价值不低烧一块板子不只是经济损失还直接影响项目进度。所以一定要在硬件设计里加入以下机制每路主要电源轨都有电流和电压监控至少关键模拟电源要有过流保护预留JTAG链把RFSOC和FPGA的调试接口串联起来方便现场升级和调试预留温度传感器放在RFSOC和FPGA附近Linux里读温度并做降频或报警高速接口上尽量选择带ESD保护的方案板卡在实验室被静电打坏的事件并不罕见。监控信息可以在PS端Linux里通过I2C读取也可以在外部FPGA里做一个状态寄存器组方便上位机通过PCIe或网口查询整板健康状态。这些设计在调试阶段能帮你快速判断问题是供电、时钟还是逻辑问题在现场交付阶段更能大幅降低维护成本。这块双芯板卡从方案预研到样板调通前后花了大概一个季度。最大的体会是RFSOC和FPGA的双芯架构不是简单的“两颗芯片放在一块板上”而是要在射频指标、处理资源、带宽余量、可维护性之间做全局平衡。如果只把目光聚焦在某一颗芯片上后面一定会被另一侧的瓶颈拖住。希望这篇总结能对正在做同类板卡的朋友有所帮助。