这两年做FPGA和嵌入式SoC的团队几乎都绕不开“国产化替代”这四个字。很多项目原本跑在Xilinx ZYNQ上好好的突然接到通知——关键元器件要换国产方案逻辑代码要平移驱动要重编Linux系统要重新移植。之前我参与过一个图像处理相关的边缘计算项目原本是基于ZYNQ-7020开发的客户要求全国产化之后全组人花了不少时间调研最后锁定了复旦微的FMQL45T900。这次迁移折腾了差不多两个月中间踩了不少坑也总结出一套从Xilinx ZYNQ迁移到复旦微FMQL45T900的完整流程。这篇文章不打算写成那种泛泛而谈的“国产化趋势分析”我就直接从工程实操的角度把芯片选型对比、PS侧ARM环境搭建、PL侧逻辑迁移、交叉编译链配置、联合调试这些关键环节全部分享出来。项目刚做的时候全网搜不到一篇完整的迁移攻略现在做完回头整理希望能给后面做类似方案的工程师省点时间。1. 为什么最终选了FMQL45T900这颗芯片到底什么水平先说选型。当时我们手里有两条路线一是用高云或者紫光同创的纯FPGA再把ARM部分换成外挂的国产应用处理器二是直接选复旦微的FMQL系列SoCARM和FPGA做在同一颗芯片里。对比了一圈之后选了后者。1.1 FMQL45T900与ZYNQ-7020/7045的资源换算FMQL45T900是复旦微 FMQL45 系列里的一款SoC内部集成了四核ARM Cortex-A9PS端和一片规模相当于Kinte-x-7级别的可编程逻辑PL端。从资源量上看它跟Xilinx ZYNQ-7045比较接近比7020要宽裕不少。具体参数差异我整理了一张表对比项Xilinx ZYNQ-7020Xilinx ZYNQ-7045复旦微FMQL45T900PS端CPU双核ARM Cortex-A9双核ARM Cortex-A9四核ARM Cortex-A9逻辑单元约85K350K约350K级别DSP Slice约220个900个900个级别BRAM约4.9Mb19.2Mb19.2Mb级别高速串行收发器无部分封装有有GTX级别有支持PCIe、SRIO等操作系统支持Linux/RTOSLinux/RTOSLinux/RTOS这里有个很重要的点FMQL45T900的PS端是四核A9而ZYNQ-7020是双核A9。这意味着如果你原来是基于ZYNQ-7020开发的项目迁移到FMQL45T900之后PS端的CPU算力是有明显冗余的——多出来的两个核可以分担图像算法、网络协议栈或者数据库这类负载。但如果原来是ZYNQ-7045上的项目那差不多是平级迁移资源上不会有惊喜也不会有明显落差。1.2 迁移前先算清楚这几笔账选型不能只看资源表还得看几笔实际的账。我当时做了一个粗略评估第一笔账是引脚兼容性。FMQL45T900的封装和引脚定义跟ZYNQ-7045不完全一致所以PCB几乎没办法直接“换上芯片就完事”。如果你的项目里PL端引出了大量自定义IO改板是逃不掉的。我们当时是重新画了一版PCB把电源、DDR、配置FLASH、以太网接口全部按复旦微的参考设计重做。第二笔账是开发工具链。Xilinx那套Vivado用惯了之后切到复旦微的Procise工具链会有一段明显的适应期。后面我会专门讲工具链的问题。简单说Procise用得熟练之后日常开发效率能接受但别指望它跟Vivado一样顺手。第三笔账是IP核生态。ZYNQ下很多现成的Xilinx IP核MIG、FIFO Generator、Clocking Wizard等等在复旦微平台上是没有对应“同名替换”的。迁移工作里PL端逻辑本身往往不难真正费时间是这些基础IP的重新生成、验证和适配。第四笔账是操作系统BSP。复旦微官方提供Linux BSP但基于的内核版本和文件系统跟Xilinx那套有差别。你需要重新编译内核、重新生成设备树、重新移植驱动。如果原来的应用层代码依赖某些内核接口或设备节点名也需要逐一核对。把这四笔账算完之后我们当时的结论是FMQL45T900适合那种PL端逻辑量比较大、PS端要跑Linux做业务、并且需要一定算力的项目。如果你的项目只是简单用几万LUT做做逻辑控制选它有点浪费不如选国产纯FPGA或者更低成本的平台。2. 整体架构迁移思路ARM端的核、总线与启动流程怎么对应选型定了之后第一件事不是急着移植代码而是把原来ZYNQ方案里的“系统架构图”拿出来重新画一版FMQL45T900的。这两颗芯片在整体架构上高度相似都是ARM处理器系统通过AXI总线连接可编程逻辑外设也都在片上集成了但细节上差异不少。2.1 双核变四核Linux启动和应用层有哪些坑原来ZYNQ-7020是双核A9跑的是标准ARM LinuxSMP模式大部分时候Linux只会在两个核上做任务调度。FMQL45T900是四核A9Linux内核起来之后默认也是SMP模式四个核都会被调度。理论上应用层代码是透明的不用改。但实际跑起来有几个坑值得提醒第一个坑是内核配置。复旦微的BSP默认内核配置跟Xilinx的不完全一样尤其在CPU frequency scaling、电源管理、DMA一致性这些选项上。我们第一次直接拿原来的内核配置去编译结果启动到一半卡在calibrating delay loop后来对比官方BSP配置发现是Timer和GIC相关配置项没打开。所以强烈建议不要拿ZYNQ的内核配置硬套用复旦微BSP的defconfig作为基础再裁剪。第二个坑是多核负载均衡。原来双核A9的时候如果某个线程绑核绑在CPU1上迁移到四核之后这个绑核关系本身不会错但CPU编号可能变了。最好在应用层通过sched_setaffinity或cgroup重新设计绑核策略。我们当时有一个图像采集线程原来绑在CPU1上跟DMA中断做亲和性迁移后直接绑了CPU1结果没注意中断被分配到CPU2上去了性能掉了不少。后来统一改成绑核中断亲和性一起配。第三个坑是启动时间。四核A9的内核引导比双核要慢一点另外复旦微的U-Boot默认启动流程多了一些自检步骤。如果你的项目对上电到应用程序跑起来的时间有严格要求比如小于5秒那需要花时间优化U-Boot环境和内核启动参数。2.2 设备树和外设驱动的适配是重头戏从ZYNQ迁移到FMQL45T900内核驱动的适配工作里设备树是最大的一块。Xilinx那套设备树里很多外设节点地址和中断号跟复旦微是不同的。比如ZYNQ的UART0地址是0xE0000000中断号是27FMQL45T900的UART0地址我印象中不是同一个段中断号也变了。这种差异如果不仔细对芯片手册很容易出现“内核打印没有串口输出”这种看起来像系统完全没启动的诡异现象。我们迁移时踩过一个典型坑GEM以太网控制器。原来ZYNQ下网络节点叫ethernete000b000驱动用的macb驱动。复旦微的以太网控制器也是兼容macb驱动的但寄存器基地址和中断号不同而且DMA描述符的对齐要求在某些配置下有差异。我们当时直接把原设备树里的reg和interrupts改过去结果网络吞吐只有百兆水平查了半天才发现是DMA burst length配置项在设备树里没改还是Xilinx默认的8字节复旦微这颗需要按16字节设置才能跑满千兆。设备树适配建议分三步走先从复旦微官方BSP的默认设备树模板开始确认芯片的外设基地址映射关系。把原ZYNQ设备树里的自定义节点比如PL端寄存器映射的axislave节点、DMA节点、中断控制器级联节点平移过来核对地址和中断号。编译后用u-boot的fdt命令实际打印设备树逐一确认节点被内核正确识别。2.3 启动流程差异从BootROM到U-Boot再到内核FMQL45T900的启动流程跟ZYNQ基本理念一致都是从BootROM开始加载FSBLFirst Stage Boot Loader再跳转到U-Boot最后引导Linux内核。但具体操作上有区别ZYNQ用的是Boot.bin包含FSBLbitstreamU-Boot通过SD卡或QSPI加载。FMQL45T900也类似不过复旦微的FSBL生成和烧录工具链跟Xilinx SDK不一样是放在Procise里的。我们第一次试图用Vivado SDK的方式生成BOOT.bin折腾了几天发现根本不对后来老老实实按复旦微的《FSBL生成指南》走完一遍才算正常引导。另外FMQL45T900支持多种启动介质包括QSPI Flash、SD卡、JTAG甚至支持加密启动。对于量产项目建议直接把启动镜像做到QSPI Flash里SD卡只留作调试和升级。安全启动那块复旦微支持AES和RSA认证具体在FSBL阶段做校验如果项目有安全合规要求这部分值得提前了解。3. PL端逻辑迁移Xilinx IP换到国产IP哪些坑必须绕开PL端的逻辑迁移是整篇里最需要耐心的一步。如果原来的ZYNQ工程里用了大量Xilinx官方IP尤其是有安全相关功能或者高速接口的那么迁移工作量会直线上升。3.1 时钟、复位和全局缓冲资源处理Xilinx工程里最常见的几个基础IPClocking WizardPLL/MMCM时钟生成、Processor System Reset复位同步、FIFO Generator、Block Memory Generator。这些在复旦微平台上都不是“直接替换文件”的关系。以时钟IP为例ZYNQ下我习惯用Clocking Wizard生成200MHz、100MHz、75MHz等多路时钟每路都经过BUFG全局时钟网络。在FMQL45T900上时钟管理单元是复旦微自己的PLL硬核Procise里有对应的时钟IP但配置界面和使用方式不太一样。你需要在Procise里重新例化时钟IP按照原来的频率分配方案逐路生成然后手动检查每路时钟的相位、抖动参数是否满足后端设计需求。这里有一个实际案例我们原设计里用200MHz时钟驱动DDR控制器和图像采集逻辑用75MHz驱动以太网MAC的AXI接口。迁移时按照原频率在复旦微PLL IP里配置发现75MHz那路输出偏了200ppm左右。虽然200ppm对大多数逻辑不影响但图像采集那边有个行同步计数器经常偶尔错一帧排查了一天最后定位到是75MHz时钟源引入的微小频偏在跨时钟域FIFO里偶尔产生溢位。解决办法是换用另一路输出微调分频系数让频率精确到小数点后四位问题才消失。复位信号方面复旦微平台建议不要直接用Xilinx的Processor System Reset IP而是在逻辑里自己写一个复位同步释放模块。原因是复旦微的IP里对异步复位同步释放的支持参差不齐如果各个模块复位风格不统一后端时序收敛的时候很容易冒出一堆复位恢复时间违例。我们当时统一改成了“全局异步复位模块内同步释放”的风格后端的时序报告干净了很多。3.2 存储类接口IP的替换MIG、BRAM、FIFODDR控制器是PL端迁移里最敏感的部分之一。ZYNQ-7020时代很多设计是把DDR挂在PS端的DDR控制器上PL端通过AXI HP口访问DDR。FMQL45T900的PS端也有DDR控制器理论上PL端通过AXI接口也能访问DDR内存。但如果你原来的设计是PL端用MIG软核单独控制一片DDR颗粒那么在复旦微平台上可能需要用Procise里的DDR控制器IP来重新生成。我们当时没有用MIG用的是PS端的DDR控制器PL端通过AXI DMA访问DDR所以这块避开了最大的坑。但BRAM和FIFO这两个IP绕不开。Xilinx的Block Memory Generator生成的BRAM初始化文件.coe或.mif在复旦微的IP里不一定直接识别。解决方法是保留原始的初始化数据文件在Procise的BRAM IP配置里重新加载一遍并且注意确认字节顺序和地址映射。FIFO IP的替换需要注意异步FIFO的读写时钟域和almost full/empty标志位时序。Xilinx的FIFO Generator里有一个“first word fall through”模式很多图像处理设计依赖它做低延迟数据通路。复旦微的FIFO IP也支持这种模式但配置项名称可能不一样我们当时找了好一会儿才找到对应选项。如果你原来的设计里用了FWFT模式迁移后务必用仿真把读时序抓一遍再上板。3.3 高速接口LVDS接收、MIPI、QSPI的适配心得热搜词里有很多人搜FPGA实现MIPI、FPGA的LVDS接收这几个都是平时项目里的硬骨头。FMQL45T900的PL端在LVDS和MIPI D-PHY这类接口上的支持跟Xilinx K7系列比较接近但IP和约束处理有差异。先说LVDS接收。如果你原来的设计里是用Xilinx的SelectIO IP来做LVDS差分信号接入那么在复旦微平台上需要重新例化IO资源。一个常见的做法是直接在代码里实例化IBUFDS/OBUFDS原语。复旦微的原语命名跟Xilinx不同但功能对应代码改动量不大。比较麻烦的是IO约束Xilinx里用set_property -name IO_STANDARD LVDS_25复旦微的约束语法不同需要参考Procise的约束手册逐一改。MIPI这块我们项目里用PL端做了一个MIPI CSI-2的接收接口原来是基于Xilinx的MIPI CSI-2 IP来实现的迁移时这个IP在复旦微的生态里没有对应物。最后我们只能把MIPI的物理层用差分IO原语加延时单元自己搭协议层的解包逻辑用Verilog重写。这个过程工作量不小但能换来对MIPI底层机制更清晰的理解。如果你也要做类似事情我建议先把MIPI D-PHY的LP/HS状态机和字节对齐逻辑调通再往上加协议层不要一上来就想着用现成IP。QSPI Flash接口的适配相对简单。FMQL45T900支持通过QSPI加载启动镜像PL端也可以再接一片QSPI Flash做数据存储。Xilinx的Quad-SPI IP可以替换成复旦微的QSPI控制器IP代码层面主要注意指令码和地址模式的配置。我们当时遇到的问题是Flash型号兼容性原来用的某款国产Flash在ZYNQ下工作正常换到FMQL45T900后读ID正常但写操作偶尔失败。后来换了一颗复旦微验证列表里的Flash型号问题解决。这个经验说明存储芯片选型一定要查目标平台官方验证过的兼容列表别只看容量和封装。4. 交叉编译与嵌入式Linux软件栈Qt5.5.1 ARM工程是怎么跑起来的PL端迁移得差不多之后PS端的软件环境就要开始搭建了。这块很多从ZYNQ迁移过来的团队容易低估。Xilinx的PetaLinux虽然也有学习成本但至少资料多、社区大。到复旦微这边很多资料藏在官方文档和FAE手里需要慢慢摸索。4.1 交叉编译工具链的选择arm-linux-gnueabihf还是ARM Compiler先明确一个概念FPGA的PL端开发和ARM端的交叉编译是两套不同的工具链。PL端用ProciseARM端用GCC交叉编译器。如果你在FMQL45T900的PS端跑Linux那么标准做法是使用arm-linux-gnueabihf- 前缀的GCC交叉编译器从复旦微BSP里获取或从Linaro工具链自行构建。很多人搜ARM Compiler那是Keil MDK环境下开发裸机MCU用的跟FMQL45T900这种跑Linux的SoC不是一回事。FMQL45T900的PS端虽然也能跑裸机程序但我们不建议——Linux下能用线程、DMA和文件系统开发效率高得多。真要跑裸机也建议用复旦微的HDF和配套的交叉编译工具链别混用Keil那套。4.2 Linux内核、文件系统和设备树的构建顺序我们迁移Linux软件栈的顺序是这样的获取复旦微BSP的Linux源码包确认内核版本。用官方defconfig生成基础配置启动内核确保串口、网口、SD卡或QSPI可用。在基础系统上逐步加入我们所需要的外设驱动和自定义驱动。用Buildroot或Yocto构建根文件系统这里注意根文件系统架构选择必须是armhf。把Qt5.5.1或你项目里的Qt版本交叉编译到目标平台的工具链上。Qt这块多说一句。我们项目里用的是Qt5.5.1因为原有ZYNQ上就是5.5.1迁移时不想引入Qt版本变化带来的UI兼容问题。交叉编译Qt时最容易踩的坑是qmake的配置。如果你直接用主机的Qt交叉编译环境编译出的二进制到板子上跑会报“symbol lookup error”因为依赖的库路径和版本不对。建议使用Buildroot提供的qt5包或者手动交叉编译时用-marcharmv7-a -mfpuneon -mfloat-abihard这些参数确保FPU指令集匹配A9核心。还有一个细节如果你的Qt应用依赖EGL/GLES做硬件加速渲染那需要确认FMQL45T900的GPU如果SoC内置是否支持相应的驱动。我们项目里Qt界面只做数据显示和交互纯软件渲染就够用了但如果你的UI很复杂涉及大量动画和视频叠加那最好先跟复旦微确认GPU驱动情况避免后期性能不达标。4.3 驱动开发时的DMA和中断注意事项自己在Linux下写PL端外设驱动时重点是DMA和中断。FMQL45T900的PS端集成有DMA控制器也可以使用PL端逻辑里自带的AXI DMA IP。我们在迁移时用的是PL端例化一个AXI DMA IP将采集数据搬到DDR然后通过中断通知ARM端处理。这个方案在ZYNQ下很成熟迁移到FMQL45T900之后主要改动是设备树里的DMA节点和中断号以及驱动里对DMA一致性的处理。踩过的坑是DMA缓冲区的cache一致性。ZYNQ时代习惯了用dma_alloc_coherent分配一致内存迁移后继续沿用但发现大块内存分配的时间偏长影响采集线程的实时性。后来改成了dma_map_single配合流式映射的方式只用dma_alloc_coherent分配描述符数据缓冲区改用普通kmalloc加map/unmap实时性提升明显。这就是一个典型的“同样API在不同平台上性能差异”的问题建议实测后再优化。中断方面需要注意GIC的SPI中断号分配差异。ZYNQ的PL端中断一般从61号开始具体看器件FMQL45T900的SPI中断号范围可能不同。在看设备树和irq number映射时务必跟芯片手册核对。我们当时有一路中断号写错了现象是中断驱动里request_irq不报错但中断永远不触发排查了很久才发现是中断号错位。5. 联合调试与性能验证实测数据就是最好的验收报告整个系统迁移后最让人心安的不是代码全部跑通而是性能数据达到甚至超过原来的ZYNQ方案。这里分享几组我们实测的数据和一个典型的调试链路。5.1 DDR带宽、DMA吞吐和中断延迟实测先说DDR带宽。我们原ZYNQ-7020平台上通过AXI HP口做DMA搬运实测DDR读带宽大约在2400MB/s左右写带宽在1800MB/s左右受FPGA逻辑时钟和AXI位宽限制。迁移到FMQL45T900后同等条件下实测读带宽接近3100MB/s写带宽2300MB/s整体有约三成提升。这个提升一方面来自四核A9的PS端DDR控制器时序优化另一方面也跟PL端逻辑微调有关——我们在迁移时把AXI数据位宽从64位扩到了128位。再看DMA吞吐。我们用了PL端AXI DMA IP做图像采集采集分辨率是1080p30帧每帧数据量约1920x1080x3字节大概6MB。原来ZYNQ方案下DMA搬运一帧大约要2.1ms迁移后是1.6ms左右也就是帧间隔33ms里DMA占用不到5%留给CPU做图像处理和AI推理的空间很宽裕。中断延迟这块我们用一个简单的GPIO中断测量从FPGA拉高GPIO到ARM端中断处理函数入口的延时ZYNQ平台实测约12微秒FMQL45T900平台上约10微秒基本持平。这个数据对大多数应用来说都够用。5.2 典型调试场景从“寄存器读不到”到“DMA搬运链跑通”调试过程中印象最深的一个问题是PL端寄存器读不到数据。上电之后ARM端通过AXI总线访问PL端寄存器读回来全是0xFFFFFFFF或者0xDEADBEEF总线错误返回。这个现象在ZYNQ上不常见因为ZYNQ的AXI互联相对透明。FMQL45T900平台上第一反应是检查PL端逻辑有没有正确加载也就是FSBL阶段有没有把bitstream配置进去。排查链路先用JTAG读PL端状态寄存器确认bitstream已经加载然后在Linux下用devmem直接读地址发现还是0xFFFFFFFF接着检查设备树里PL端寄存器的地址范围对应到AXI地址映射。结果发现设备树里写的地址是0x80000000但我在Procise里给PL端逻辑分配的AXI从接口基地址是0x40000000两者不一致。ARM访问0x80000000时地址译码根本路由不到PL端自然读不到数据。这个问题排查了一整天本质原因就是Procise的地址映射配置和Linux设备树地址没对齐。解决方法是把Procise里的AXI从接口地址统一改成设备树里声明的0x80000000重新生成bitstream再改设备树的范围范围重启后寄存器读写恢复正常。这个案例想说明的是迁移到新平台后很多“玄学问题”归根结底是地址映射、中断号、设备树这几个基础环节没对齐按链路逐一排查反而比东试西试更快。5.3 启动时间、功耗和稳定性的横向对比我们项目对启动时间有一定要求实测数据如下FSBL加载bitstreamZYNQ约0.5秒FMQL45T900约0.7秒bitstream较大。U-Boot启动两者差不多约0.4秒。Linux内核启动到Shell可交互ZYNQ约2.1秒FMQL45T900约2.5秒四核更多自检。应用自启动到主界面显示ZYNQ约1.2秒FMQL45T900约1.5秒。总体从上电到应用就绪FMQL45T900比原ZYNQ慢约0.8秒左右但全流程在7秒以内可以接受。功耗方面我们项目里FMQL45T900的PS端四核全开PL端逻辑规模约60%使用率整板功耗约11W比原来ZYNQ-7020方案的8.5W高出2.5W左右。如果你做的是电池供电的设备这2.5W很关键建议提前在结构散热和电源设计上留好余量。稳定性方面连续跑48小时压力测试温度稳定在78℃左右加了散热片风扇没有出现DMA挂死、DDR bit翻转或网络断连的异常。6. 国产化替代不是“换个芯片重编一遍”而是一次重新设计最后说点个人体会。刚开始接到这个迁移任务的时候我心里是有点打鼓的。Xilinx的生态是几十年积累下来的Vivado、PetaLinux、大量社区资料、成熟的IP这些优势不是一朝一夕能追上的。复旦微FMQL45T900这套平台文档不够完善中文资料分散FAE响应速度也是时快时慢很多问题只能靠自己对芯片手册慢慢啃。但做完整个项目之后我的看法有了变化。FMQL45T900本身的设计成熟度在我实际用过的国产FPGA/SoC平台里算是第一梯队的。四核A9跑Linux很稳PL端逻辑资源充足高速接口能力也不差。真正的难点不是芯片本身而是整个生态的“惯性”——大把习惯了Xilinx工具的工程师需要时间去适应Procise的约束写法、IP配置方式和调试流程。有几个小建议给后面的人别指望一天两天完成迁移按一个月周期来排期时间表里一定要留出“IP替换踩坑”和“驱动适配”两块冗余。跟复旦微的FAE建立直接联系很多技术问题在官方资料里没写清楚但FAE心里有数。遇到诡异问题时按“地址映射→中断号→设备树→时钟复位→后端约束”的顺序排查绝大多数问题都能归到这五类里。如果项目允许用FPGA逻辑里多留一些调试寄存器ARM端通过AXI总线实时读取状态联调效率会高很多。这次迁移前后花了大概两个月虽然过程曲折但最终交付的FMQL45T900方案在性能上比起原ZYNQ方案没有缩水部分指标反而更高。国产FPGA/SoC的选择已经不是一个“能不能用”的问题而是“怎么用好、怎么把坑提前踩完”的问题。希望这篇实战记录能帮同行们少走一些弯路。