1. 系统为什么这样搭FPGA负责采集CH569负责送数先说结论这行当里做高速数据采集方案看着五花八门但归根到底就是在数据从模拟前端进来到PC端看到波形这条链路上做取舍。我之所以把FPGA和CH569拼在一起核心原因只有一句话——CH569把USB3.0的PHY和控制器都集成进了芯片内部且内嵌了一个RISC-V内核这让USB3.0部分变成了一个可用MCU思维操作的外设而不是一个需要复杂驱动和协议栈的黑洞。1.1 数据采集场景对总线的真实需求采集系统到底需要多快的传输速度这不是拍脑袋定的得从信号链源头倒推。我用一个非常常见的场景双通道、12位ADC、采样率50MSPS。每秒产生的数据量单通道数据率 50M × 12bit 600Mbps双通道 1.2Gbps 150MB/s这意味着什么如果只靠单通道USB2.0理论480Mbps实际有效也就40MB/s上下铁定不够连1/3都跑不满。想要把150MB/s的数据流实时甩到PC端USB3.0几乎是消费级接口唯一的选择。CH569这颗芯片的USB3.0是SuperSpeed 5Gbps的物理层理论值虽然被协议开销吃掉一部分但实测批量传输做到350MB/s380MB/s是稳的峰值看过有人跑接近400MB/s。注意这里不是理论带宽是扣除USB协议开销后能实际灌进上位机的有效速率。1.2 为什么是CH569而不是别的组合做USB3.0高速传输市面上还有其他路线FPGA直接接USB3.0 PHY芯片比如TUSB1310、用带USB3.0硬核的FPGA比如部分Intel Agilex或者Xilinx的Versal、或者再挂一颗带USB3.0的高端MCU/MPU。但这些方案有一个共性——贵、难、布板费劲。CH569方案直接把三个东西揉在一颗芯片里RISC-V内核240MHz主频USB3.0设备控制器加PHYSS 5Gbps内置DMA、FIFO、SPI、UART等接口也就是说FPGA只需要通过一组并口我用的16位或32位并行总线把数据灌给CH569CH569内部自己完成打包、DMA搬移、USB协议处理最后从Type-C口出去。工程量瞬间从驱动一个USB3.0 PHY芯片降级成操作一组FIFO读写寄存器。这个选型逻辑本质上是在物理层复杂度和系统灵活性之间找平衡。USB3.0的PHY有大量模拟电路包括时钟恢复、均衡器、LFPS检测、SSC扩频时钟这些自己用分立方案做布线和阻抗控制稍有不慎就枚举失败。CH569把这些全集成进去硬件上你只需要处理USB线的差分对布线JTAG调试口以及3.3V和1.2V电源开发难度直接降了一个量级。2. 硬件架构与设计细节板级工程师的视角硬件设计是整个系统里最容易看着简单但翻车隐蔽的部分。USB3.0的差分线一旦阻抗、长度匹配、参考层处理不好轻则速率上不去重则设备无法枚举。这一章我把整块板子的架构和关键设计约束摊开来讲。2.1 系统硬件框图整块板子的核心链路可以分成四段模拟输入或数字输入根据场景选择可以是高速ADC比如AD9226、ADS42LB69之类也可以是LVDS/CMOS数字信号直接进FPGA。FPGA处理单元完成采集控制、数据预处理滤波、抽取、FFT等、数据打包然后通过并行总线把数据推给CH569。CH569桥接负责将FPGA送过来的并行数据经内部FIFO缓冲DMA搬运到USB3.0设备控制器最终通过Type-C口输出。上位机PC接收USB3.0数据流解析帧格式显示波形/频谱或落盘存储。我当时做的最初版FPGA用的是Intel Cyclone 10 GX后来换成了国产的紫光同创CH569不带PHY那种外置方案直接用的Type-C连接器。2.2 CH569与FPGA之间的总线设计FPGA与CH569的数据通路是整个桥接设计中最关键的部分。CH569对外提供一组并行总线接口你可以在SDK里把它配置成类似FIFO读写模式也可以配成带地址总线的寄存器读写模式。我选的是FIFO模式。好处是FPGA侧逻辑非常干净——只需要关注两个信号方向写请求WR和写数据DATACH569内部有硬件FIFO做缓冲数据不会因为USB总线繁忙而丢失前提是FIFO深度够。引脚分配上要留意的点并行数据总线最好使用FPGA的Bank内连续引脚保证输出延迟一致性。我一开始为了布线方便把数据线拆到了两个Bank结果FPGA I/O的输出Tco不一致在200MHz以上的并口速率下直接导致数据采样错误。后来规规矩矩用了一个Bank的16根IO问题消失。时钟方面CH569的并行总线时钟我用了50MHz起步后期优化到100MHz。以16位位宽计算50MHz×16bit 100MB/s100MHz就是200MB/s足够覆盖大部分采集需求。2.3 电源与地平面处理容易被忽视的翻车点USB3.0的PHY对电源噪声极度敏感尤其是PLL和高速SerDes部分的供电。CH569内部虽然集成了LDO但外部输入电源的纹波如果超标SS信号的眼图就会劣化直接影响链路稳定性。我的做法是3.3V系统电源先用一片低噪声LDO比如LT3042类稳压禁止直接用DC-DC输出靠近模拟/USB部分1.2V核心电压由3.3V经由稳压IC转换并且滤波电容矩阵要靠近芯片电源引脚地平面在CH569下方尽量完整不要在芯片正下方走任何信号线尤其是不要穿过USB差分对下方USB3.0差分对SSTX/-、SSRX/-布线我用了100Ω差分阻抗控制等长控制在5mil内总长度不超过2英寸。这里插一句USB3.0的SS差分对不像USB2.0的D/D-那样可以容忍较长走线5Gbps速率下过长的stub或者过孔阻抗不连续都会导致链路训练失败。如果板子空间允许尽量做在表层减少过孔换层。3. RISC-V核侧CH569的USB3.0固件开发要点CH569最大的反直觉之处在于它虽然是颗MCU但内部USB3.0控制器是有硬件DMA的所以固件层面主要工作并不是逐字节搬运数据而是配置描述符、管理DMA缓冲区和处理端点事件。固件写得合理的话CPU占用率可以做到非常低大部分时间在休眠等待中断。3.1 开发环境与SDK理解CH569用沁恒自家的MounRiver Studio基于Eclipse的IDE或者直接用CMake工具链。芯片是RISC-V内核指令集是基于RV32IMAC的变体支持硬件乘法除法。SDK提供了USB3.0设备相关的库函数包括设备枚举、端点配置、DMA描述符管理等。刚开始用这套SDK时我走了一些弯路SDK里的例程大多是回环测试或按键控制这类真正做数据流传输的参考代码不多。所以如果你直接拿例程改很容易被USB发一次数据就进中断处理一次这种思路带偏导致传输速率上不去。正确做法是使用DMA模式多缓冲乒乓结构让硬件自己搬运数据CPU只在缓冲区满了的时候做指针翻转。3.2 批量传输端点与DMA配置USB3.0的Bulk端点批量传输端点是数据采集类设备的标配因为Bulk传输在USB3.0下带宽可以做到接近2.5Gbps以上相对于USB2.0的Bulk传输只有几十MB/s有质的飞跃而且是可靠传输错了重传不会出现数据损坏。CH569的端点配置代码大致如下以SDK接口为例// 配置端点6为BULK IN用于数据上行 USBFS_Device_EndPoint_Config(EP6, USB_TRANSFER_TYPE_BULK, USB_DIR_IN, 1024);这里有个关键参数端点最大包长。USB3.0的Bulk端点最大包长度是1024字节USB2.0是512字节。理论上每个包越大USB协议开销占比越低吞吐率越高。CH569支持最大包长1024字节正好。DMA描述符配置// 配置DMA描述符将内部FIFO数据搬移到端点的DMA缓冲区 DMA_Descriptor_Init(DMA_CH0, (uint32_t)ep6_buffer, 1024 * 16, DMA_DIR_MEM2MEM);注意我要强调DMA缓冲区的地址对齐非常关键。建议至少按照32字节对齐最好按照64字节对齐。CH569的DMA控制器在搬运数据时如果源地址或目的地址没有对齐会有额外的总线周期开销虽然不至于出错但会影响吞吐率。实测下来16字节对齐和64字节对齐在高速连续搬运时吞吐率差异可以到5%8%。3.3 固件主循环与中断处理固件逻辑可以简化成三段初始化时钟、USB控制器、端点、DMA描述符然后开启USB设备等待主机枚举主循环等待事件标志位处理控制传输设备描述符请求等以及DMA完成中断中断处理当DMA搬完一批数据翻转缓冲区指针重新启动DMA同时把已满的缓冲区标记为可被主机读取需要特别提的是在USB3.0高速传输下中断频率非常高。如果每个数据包都进一次中断CPU会被连续打断到几乎无法做其他事情。我的做法是中断里只做标志位设置和缓冲区切换不做任何数据拷贝数据拷贝全部交给DMA。另外中断服务函数里不要调用任何USB发送API一切留在主循环处理。伪代码示意volatile uint8_t dma_done_flag 0; void DMA_IRQHandler(void) { // 翻转当前使用的缓冲区索引 current_buffer_index ^ 1; // 重新配置DMA指向另一个缓冲区 DMA_Config(current_buffer_index); dma_done_flag 1; } int main(void) { SystemInit(); USB3_Init(); DMA_Init(); while(1) { if (dma_done_flag) { dma_done_flag 0; // 告诉主机当前缓冲区数据有效 USB3_Send_Buffer(current_buffer_index); } } }这里有个坑如果你在DMA中断里直接调用USB_Send会发现偶尔出现数据错乱或者丢包。原因是DMA中断和USB发送逻辑之间有时序竞争——DMA刚完成搬运但USB控制器的内部状态还没完全就绪立刻触发发送可能会把未完全写入的数据发出去。改成主循环判断标志位后这个问题消失。4. FPGA侧逻辑设计与数据流控制CH569再智能也只是一个桥接芯片真正决定数据长什么样的是FPGA里的逻辑。FPGA侧的工作重心是采集控制、数据组织、总线时序产生。这个部分设计得好不好直接决定整个系统能跑多快、数据对不齐、上位机能不能正确解析。4.1 采集侧设计ADC时序与数据对齐如果是接并口ADC时序相对简单ADC在采样时钟的上升沿输出数据FPGA在下一个时钟沿抓取。但要注意的是高速ADC的输出延迟tODOutput Delay并不是固定不变的而是和采样时钟的相位有轻微抖动。为了保证裕量我强烈建议在FPGA内部用IDELAYI/O延时模块或者整数时钟周期延迟链做一个动态校准。以50MHz采样率为例ADC输出数据和采样时钟相位偏差可能从0.5ns到3ns不等直接用系统时钟抓取可能落在数据跳变沿处导致采到错误数据。常见的处理办法是先用一个固定相位偏移比如90°采样然后跑一个简单的训练序列程序自动调整IDELAY值直到数据锁存稳定。如果输入是LVDS接口的高速ADC比如双通道、1GSPS的ADC12DJ3200这类FPGA侧还要做串并转换SerDes这个复杂度和并口ADC完全不同需要用到FPGA内部的ISERDESE2/BUFIO等原语。但CH569那侧接口速率上限摆在那里这种级别的ADC前级不会直接接到CH569总线上中间必须有降速/缓存环节。4.2 跨时钟域处理与异步FIFO采集域和发送域往往是两个时钟域采集域由ADC采样时钟驱动比如50MHz发送域由CH569并行总线时钟驱动比如100MHz两个时钟没有任何相位关系直接传递数据必出亚稳态。所以中间必须加异步FIFO做缓冲这是标准的跨时钟域处理结构。FIFO深度选择是门学问FIFO深度字节 突发传输长度 ×写入速率/读出速率 - 1举个例子FPGA每1ms突发写入16KB数据读出速率是写入速率的2倍那么理论上FIFO只需要16KB就够。但USB3.0在主机侧有时会触发流控主机忙、总线调度导致CH569长时间不拉高读使能。这种情况下FIFO瞬间就会被塞满。所以我建议FIFO深度至少是最大突发数据量的4倍以上。我这里选了32KB用FPGA内部Block RAM组合。异步FIFO设计注意点读写指针要使用格雷码做跨时钟域同步否则多比特指针在跨时钟域时会产生错误空满判断轻则丢数据重则读写出错。如果你用的是带FIFO IP核的FPGAVivado/Xilinx或Quartus/IntelIP核内部已经处理了格雷码但你自定义逻辑时一定要留意这一点。4.3 发给CH569的并行总线时序CH569的并行数据接口时序不是标准AHB或AXI更像一个简化版的同步FIFO写接口。核心信号是写时钟FCLK、写使能FWR、16位/32位数据总线。时序要求关键在于建立保持时间。在100MHz时钟下数据总线的建立时间要求大约是5ns8ns保持时间2ns左右。这个指标对FPGA的IO输出延迟提出了要求。我在Quartus里做了如下约束set_output_delay -clock [get_clocks {fclk}] -max 6.0 [get_ports {data_out[*]}] set_output_delay -clock [get_clocks {fclk}] -min -1.0 [get_ports {data_out[*]}]如果你发现时序违例第一反应不是降频而是检查是不是把IO输出寄存器放在了逻辑单元ALM/CLB里而不是IOBI/O Block里。FPGA综合工具默认的IO寄存器的位置经常不是最优的需要手动添加约束强制综合器将输出寄存器放到IOB中这样可以省掉从LE到IO的走线延迟时序裕量会大幅提升。4.4 数据帧格式设计如何让上位机正确解析数据流如果只是裸数据上位机也能存盘但想做实时显示、波形触发、数据回放等功能就需要在FPGA侧对数据进行帧格式化。我用的帧格式字段长度说明帧头标识2字节固定值0xAA55用于同步检测帧序号4字节自增计数上位机用于检测丢帧通道标识2字节表示数据来自哪个采集通道采样点数4字节本帧有效数据长度有效数据N字节按通道顺序排列的采样数据CRC校验2字节对帧序号通道标识采样点数有效数据做CRC16为什么要加帧序号因为USB虽然可靠传输但主机程序和DMA缓冲机制可能导致乱序或丢帧。上位机检测到帧序号不连续就可以确定丢帧发生从而提示用户调整采样率或者增大缓冲。对于高速采集调试来说这个功能几乎是必备的。一点小提醒帧头选取时尽量选择不易和数据混淆的固定字节模式。0xAA55这种交替模式在随机数据中出现连续4字节匹配的概率非常低基本可以安全使用。如果你想要更高的安全等级可以用0xAA55AA55做4字节帧头代价是每帧多2字节开销。5. 上位机与联调实测USB3.0链路真实表现硬件、固件、FPGA逻辑都就位后重头戏就来了——把整条链路跑起来看它到底能不能达到设计指标。这个环节最能暴露问题因为很多鲁棒性缺陷只有在连续跑大数据量时才显现。5.1 上位机接收方案选型USB3.0上位机通信主流方案有两条路线WinUSB libusb免驱或使用WinUSB驱动跨平台基于批量传输适合数据采集类设备厂商驱动写一个内核驱动性能最好但开发量大、签名麻烦、调试困难对于项目开发选libusb是性价比最高的没有之一。libusb基于WinUSBWindows或libusbK不需要自己写驱动C/C、Python、C#都能调。实测下来libusb在USB3.0批量传输上的性能损失很小不太会造成瓶颈。Python调试原型import usb.core import usb.util # 根据VID/PID找到设备 dev usb.core.find(idVendor0x1234, idProduct0x5678) if dev is None: raise ValueError(Device not found) # 配置端点 dev.set_configuration() endpoint_in 0x86 # 端点6, IN方向 # 持续读取数据 import time start time.time() total_bytes 0 while True: data dev.read(endpoint_in, 16 * 1024, timeout1000) total_bytes len(data) elapsed time.time() - start if elapsed 1: print(fThroughput: {total_bytes / elapsed / 1e6:.2f} MB/s) total_bytes 0 start time.time()跑起来后你会看到实时吞吐率。在CH569FPGA 16位总线100MHz配置下我的实测数据裸数据流无帧格式直接连续灌数据约360MB/s带帧格式每帧头尾加26字节开销约340MB/s加上CRC计算开销约330MB/s这个数字已经超过了绝大多数中高速数据采集的需求比如100MSPS×12bit双通道需要150MB/s有接近2倍余量。5.2 带宽瓶颈分析为什么不是USB3.0的理论5Gbps很多人第一次测出来只有350MB/s就会问USB3.0不是5Gbps约625MB/s吗怎么只剩一半多了几个层面解释USB3.0总线是8b/10b编码的5Gbps实际原始数据吞吐率是4Gbps500MB/sBulk传输在USB3.0下每个突发最大16KB产生一次突发需要发送一个NRDY/ERDY握手存在调度开销PC侧PCIe总线、USB控制器驱动、操作系统调度也会吃一部分性能libusb的读取模式如果每次read是固定16KB用户态和内核态的切换开销会杀掉不少吞吐率实测350MB/s是个非常健康的数据意味着协议层、驱动层、设备固件都工作正常。如果掉到100MB/s以下先别怪芯片大概率是某个环节有阻塞——最常见的就是固件里中断处理太频繁或者FPGA并行总线数据速率太低。5.3 稳定性压测与丢帧检测做完吞吐率测试必须做稳定性测试。我的方法是FPGA侧生成伪随机数据并插入递增帧序号上位机循环读取24小时以上同时校验帧序号连续性和CRC。第一次压测我就抓到了问题运行约40分钟后开始出现CRC错误包但帧序号连续——这说明数据是对的但传输过程中有bit翻转。排查后定位到是USB差分线靠近一个开关电源电磁干扰导致偶发误码。USB协议自带的CRC会检测到这个错误并触发重传所以最后到达PC端的数据不会错但重传会悄悄吃掉带宽。解决办法重新布局将USB差分线远离电感类器件另外在Type-C接口的电源引脚附近加共模电感。改版后连续跑48小时0 CRC错误吞吐率保持不变。如果你发现CRC错误频发且无法通过布局解决可以检查CH569的USB PHY配置寄存器里是否启用了SSC扩频时钟。SSC设计用于降低EMI但在某些板子上会略微恶化接收端眼图关闭SSC可以让高速传输更稳。6. 踩坑记录列举几个浪费我大量时间的真问题这一章相当于项目的隐性附件是我在完整调试链路中遇到的最难啃的几块骨头。如果你也在做类似的项目照着排查能省下不少冤枉时间。6.1 USB3.0设备假成功枚举问题表现为Windows设备管理器里能看到设备但显示为未知USB设备设备描述符请求失败或者有时能识别但传输大量数据时设备掉线。我第一次遇到时以为是驱动问题重装驱动无果换了三台电脑依然复现。后来用逻辑分析仪抓USB数据线才发现CH569在上电后第一次枚举时发出了错误的设备描述符长度——这是固件初始化的时序问题设备描述符缓冲区还没完全填充USB控制器就已经响应了主机的GET_DESCRIPTOR请求。解决办法在USB设备使能之前确保设备描述符数据结构已经在内存中就位并且设置一个全局标志只有初始化完成后才允许USB控制器响应总线事件。CH569的SDK里给了USB3_Dev_Init()这类函数但需要确认它在调用时是否已经将描述符指针指向了正确的内存地址。另外一个非常隐蔽的坑CH569的USB3.0 PHY在上电后需要预热时间PLL锁定时间。如果MCU启动后立刻使能USB设备PHY还没锁定时所有高速信号都会失败。SDK例程里对此有延时处理但如果你裁剪了启动代码一定要保留至少10ms的PHY稳定延时。6.2 DMA缓冲区地址对齐导致的吞吐率卡一半系统刚调通时USB枚举正常、数据传输也正常但速率死活只有180MB/s换了好几台电脑都一样。当时误以为是FPGA总线瓶颈花了两天优化FPGA时序毫无改善。最后静下心翻CH569的数据手册发现DMA连接的内存区域如果地址不是64字节对齐DMA控制器会退化为非突发模式每个总线周期只搬运少量数据严重降低吞吐率。检查代码后确认我在声明DMA缓冲区时使用了普通的全局数组编译器把它放在了一个未对齐的地址上。改成以下写法后速率直接翻倍到360MB/s__attribute__((aligned(64))) uint8_t ep6_buffer[16 * 1024];这件事的教训是跑高速数据传输时先查对齐再查时序。DMA对齐的问题在低速场景完全无感但一上高速立刻就是致命的。6.3 FPGA侧跨时钟域FIFO的空满信号毛刺调试时发现偶发数据错位——不是丢帧而是同一帧内前一段数据出现错位后一段又恢复。用ILA集成逻辑分析仪抓FPGA内部信号发现异步FIFO的Empty信号偶尔会比实际FIFO状态早一个时钟周期拉高。原因分析异步FIFO的读指针同步到写时钟域、写指针同步到读时钟域本来就是拍一拍再判断的所以空满信号天生有一个时钟周期的抖动。这个抖动在大部分场景可以忍受但如果在FIFO为空的瞬间读取数据读出的值就是未定义的可能是旧数据也可能是高阻态。我的处理方案在读取逻辑里加一个空存保护状态机——只在FIFO有效数据量大于一定阈值比如超过16个深度时才允许读出避免在空边界反复跳变。同时将FIFO的读使能信号打两拍后再用滤掉亚稳态。这些改动看起来微小但对数据可靠性的提升立竿见影。6.4 上位机读取线程卡死问题libusb的同步读取接口在设备意外断连时会一直阻塞或者抛异常处理不好程序直接卡死。批量传输还有一个坑如果你设置了超时时间比如1000ms当USB总线繁忙或设备响应慢时read调用会直接超时返回代码里如果不区分超时和数据错误就会把正常的数据流误判为异常。我的处理建议上位机读取用独立的接收线程超时返回时只是记录一次计数而不是退出循环只有在持续多次超时或者收到具体的USB错误码比如LIBUSB_ERROR_NO_DEVICE时才判定设备断连并做重连处理。7. 从这套系统能学到的通用方法论写完这套系统我想多说几句这套架构能复用到其他场景的通用方法论——因为很多人问CH569和FPGA这个组合除了数据采集还能干嘛其实它的可迁移性比想象中广得多。第一个可复用点是**FPGA做前端处理、MCU做协议桥接的分工思想**。FPGA擅长并行、低延迟、确定性的数据搬运和预处理MCU擅长复杂的协议栈和状态管理两者天然互补。这套思想适用于非常多场景高速图像采集FPGA做去马赛克、降噪、格式转换CH569做USB3.0图像传输、软件无线电FPGA做DDC/DUC上下变频CH569做基带数据上传、汽车总线数据记录仪FPGA采集多路CAN/LIN数据CH569通过USB3.0灌给PC上位机做分析。第二个可复用点是调试方法论。整个系统调通后我复盘发现最大的问题往往不是某个单一模块不会写而是各个模块之间的接口缝隙——FPGA和CH569之间的总线时序、CH569和USB主机之间的协议握手、USB主机和上位机之间的驱动交互每一个接缝都可能成为吞噬性能或稳定性的黑洞。所以做这类项目前期画好接口时序图把每一段的时序约定明确写出来比急着写代码重要得多。我自己当时的接口文档改了六版每一版都发现了一些前期没想到的时序边界情况。第三个可复用点是数据帧格式设计。不管传输的是什么类型的数据帧头帧序号通道标识长度CRC这套结构几乎是万能的。我后来做图像数据传输时只把有效数据字段改成了图像行数据上位机解析逻辑稍微调整就能直接工作。先把基础传输管道做扎实再在上层做数据类型的变化是这套系统留给我最大的工程收益。
