1. 从一块250M采样率的ADC板卡说起这个项目到底在做什么第一次拿到这个需求的时候我盯着250M采样率、14BIT、双通道这几个参数看了很久。做过数据采集的人都知道这三个数字凑在一起意味着什么——它已经脱离了普通单片机内置ADC那种玩具级的范畴进入了高速数据采集系统的领域。250M采样率意味着每秒要产生2.5亿个采样点14BIT精度意味着每个点用两个字节来存双通道意味着这个数字还要翻倍。简单算一下250M × 2字节 × 2通道 1GB/s的原始数据吞吐量。这个量级的数据靠STM32那种几十兆主频的MCU去直接读取基本是不现实的。所以这个项目的本质是一个典型的高速ADDA模数转换与数模转换数据采集与传输系统。它的核心链路是这样的模拟信号进入高速ADC芯片ADC在250M采样时钟的驱动下把模拟波形数字化FPGA或者专用的高速接口芯片负责把高速并行数据缓存、打包然后通过某种高速总线比如PCIe、千兆/万兆以太网、USB3.0等传输到上位机。上位机拿到数据之后要做三件事把波形画出来给人看、根据设定的条件做触发判断、对采集到的信号做频谱分析并计算信噪比等指标。这里面每一个环节都有坑。ADC的采样时钟怎么给、数据怎么对齐、传输带宽够不够、上位机怎么保证不丢数据、触发逻辑放在FPGA里还是上位机里、频谱计算用FFT还是别的算法、信噪比怎么算才准确——这些问题我在实际做项目的过程中都踩过一遍。这篇文章就把整个项目的设计思路、关键参数的计算过程、实操中的注意事项以及上位机软件的实现要点完整地梳理一遍。适合读这篇文章的人应该是对数据采集系统有一定了解但还没完整做过高速采集项目的工程师或者正在做类似项目、卡在某个环节上的人。如果你连ADC是什么都还不清楚建议先补一下基础因为下面的内容会涉及不少硬件和信号处理层面的细节。2. 250M采样率14BIT双通道ADC的硬件链路设计2.1 为什么这个采样率下不能再用MCU直接读ADC很多人做ADC采集的第一反应是找一款带高速ADC接口的单片机比如STM32H7系列有DCMI或者SPI接口理论上也能接外部ADC。但250M采样率这个量级MCU的方案直接出局。原因很简单MCU的GPIO翻转速度、总线读取速度、中断响应时间都跟不上250MHz的数据速率。我们来算一笔账。假设ADC输出的是14BIT并行数据加上一个数据时钟DCO和一个帧同步信号至少需要16根信号线。250MHz的频率下每根线的建立时间和保持时间可能只有几百皮秒。MCU的GPIO在这种频率下根本无法稳定采样更别说还要把数据读进内存再通过串口或者USB发出去。所以这个项目里FPGA几乎是唯一的选择。FPGA可以做到用LVDS或者LVCMOS接口直接接收ADC的高速并行数据在片内用FIFO做跨时钟域处理然后通过高速收发器GTP/GTX/GTH或者外挂的PCIe硬核把数据送到上位机。我实际用过的方案是Xilinx的Artix-7或者Kintex-7系列FPGA配合ADI或者TI的高速ADC。ADC的选型上ADI的AD968014BIT双通道、最高1G采样率或者TI的ADS54J6016BIT双通道、最高1G采样率都是常见的选择。如果只需要250M采样率可以选低一档的型号成本会低不少。2.2 采样时钟的质量直接决定信噪比高速ADC对采样时钟的抖动Jitter极其敏感。14BIT的ADC理论信噪比上限是SNR 6.02N 1.76 6.02×14 1.76 ≈ 86dB。但这个86dB是在理想时钟条件下才能达到的。如果采样时钟的抖动太大信噪比会急剧下降。具体怎么算采样时钟抖动引入的信噪比恶化可以用这个公式估算SNR_jitter -20log(2π × f_in × t_jitter)其中f_in是输入信号频率t_jitter是时钟的RMS抖动。假设输入信号是100MHz时钟抖动是100fs飞秒那么SNR_jitter -20log(2π × 100e6 × 100e-15) ≈ -20log(0.0628) ≈ 24dB。这个数字看起来还行但如果时钟抖动变成1psSNR_jitter就降到约4dB整个系统的信噪比就被时钟抖动完全主导了。所以在这个项目里采样时钟必须用专用的低抖动时钟芯片比如TI的LMK04828或者ADI的HMC7044。这些芯片可以输出多路同步时钟抖动可以做到100fs以下。同时时钟的PCB走线要做阻抗匹配尽量短远离数字噪声源。我在实际调试中遇到过因为时钟走线经过了一个开关电源附近导致信噪比直接掉了10dB的情况后来把时钟线改到另一层远离电源平面问题才解决。2.3 数据接口与FPGA的对接细节ADC和FPGA之间的数据接口常见的有LVDS低压差分信号和JESD204B高速串行接口。250M采样率、14BIT、双通道的情况下如果走LVDS并行接口数据速率是250M × 14BIT × 2通道 7Gbps需要分成多对差分线来传输。如果走JESD204B可以用更少的线数但协议更复杂需要额外的SYSREF和同步信号。我个人的经验是如果FPGA的IO资源够用LVDS并行接口更直观调试起来也更容易。JESD204B虽然线少但一旦链路建立不起来排查起来非常痛苦需要抓眼图、调均衡参数。对于250M采样率这个量级LVDS方案完全够用。在FPGA内部接收到的数据要先做位对齐和字对齐。因为ADC输出的数据是随路时钟DCO同步的FPGA需要用IDELAY或者ISERDES来调整采样点确保每个bit都能正确采到。这个过程通常需要写一个训练状态机发送特定的测试码型比如PRBS然后扫描延迟值找到误码率最低的那个点。这个步骤在调试初期非常关键如果位对齐没做好后面所有的数据都是错的。3. 数据从FPGA到上位机传输方案的选择与取舍3.1 几种高速传输方案的对比数据从FPGA到上位机常见的方案有PCIe、以太网、USB3.0这几种。每种方案都有自己的适用场景选错了会在后期调试中付出很大代价。传输方案理论带宽实际可用带宽开发难度适用场景PCIe Gen2 x420Gbps约12Gbps高板卡插在工控机内要求高带宽低延迟千兆以太网1Gbps约800Mbps中传输距离远带宽要求不高万兆以太网10Gbps约7Gbps高需要远距离高带宽USB3.05Gbps约3Gbps中便携设备即插即用对于250M采样率、14BIT、双通道的系统原始数据率是7Gbps。如果要做连续采集千兆以太网肯定不够USB3.0也勉强。PCIe Gen2 x4或者万兆以太网是比较现实的选择。但如果系统只需要做短时采集比如每次采集1ms的数据然后停下来分析那么数据量就是7Gbps × 1ms 7Mbit千兆以太网也能在几十毫秒内传完。我在实际项目中用的是PCIe Gen2 x2的方案实际带宽能跑到约6Gbps对于短时采集完全够用。PCIe的好处是延迟低、驱动成熟Xilinx和Altera都有现成的DMA IP核可以用。缺点是板卡必须插在机箱里不够灵活。3.2 FPGA内部的FIFO与DMA设计不管用哪种传输方案FPGA内部都需要一个高速FIFO来缓冲数据。因为ADC的数据是连续不断的而传输接口的带宽可能不够或者上位机可能暂时忙不过来。FIFO的作用就是平滑数据流防止溢出。FIFO的深度需要根据最坏情况来算。假设传输接口的带宽是6GbpsADC的数据率是7Gbps那么FIFO的写入速度比读出速度快1Gbps。如果一次采集持续1ms那么FIFO里会积累1Gbps × 1ms 1Mbit的数据。所以FIFO至少要有1Mbit的深度才能保证不溢出。实际设计中我会留2倍余量用2Mbit的FIFO。DMA的设计也很关键。PCIe的DMA通常用描述符Descriptor来管理每个描述符指向一块内存区域。FPGA把数据写满一块区域后更新描述符然后触发中断通知驱动。驱动再把数据拷贝到用户空间。这个过程中描述符的数量和大小会影响传输效率。描述符太小中断太频繁CPU开销大描述符太大延迟高内存占用多。我一般用4KB到64KB之间的描述符大小具体看系统需求。3.3 上位机接收数据时的丢包问题上位机接收高速数据时最容易出的问题就是丢包。丢包的原因可能有很多驱动缓冲区太小、中断处理太慢、内存拷贝次数太多、用户态程序调度不及时等等。我在调试的时候就遇到过一个问题采集1ms的数据上位机收到的数据总是少那么几个点。后来用逻辑分析仪抓PCIe的TLP包发现FPGA确实把数据都发出去了问题出在驱动层。驱动的中断处理函数里做了一次内存拷贝这个拷贝是在中断上下文里做的耗时太长导致后续的中断被延迟处理DMA缓冲区溢出。解决办法是把中断处理分成两部分上半部只做最简单的标记下半部用工作队列或者tasklet来做实际的数据拷贝。这样中断响应就快了不会丢数据。另外用DMA做内存到内存的拷贝而不是用CPU来拷贝也能大大降低CPU开销。4. 上位机软件的核心功能实现4.1 波形显示怎么画才能不卡上位机要显示采集到的波形250M采样率下即使只显示1ms的数据也有25万个点。如果用普通的绘图库比如C#的Chart控件或者Qt的QCustomPlot直接画25万个点界面会卡到无法操作。解决办法有几个。第一是降采样显示在数据量远大于屏幕像素数的时候不需要把每个点都画出来。可以用峰值检测或者均值降采样的方法把25万个点压缩到屏幕宽度的点数比如1920个点。峰值检测的做法是把数据分成1920个区间每个区间取最大值和最小值然后画两条线。这样既能保留波形的包络特征又能大幅减少绘图点数。第二是用OpenGL或者DirectX来加速绘图。普通的GDI绘图在大量数据下性能很差而GPU绘图可以轻松处理百万级的点。Qt的QOpenGLWidget或者C#的SharpGL都是不错的选择。第三是分段加载不要一次性把所有数据都加载到内存里而是分页加载。用户拖动滚动条的时候再加载对应区域的数据。这样内存占用小响应也快。我实际用的方案是降采样加OpenGL。降采样在FPGA里做一部分比如先做4倍降采样上位机再做剩下的。这样传输的数据量也小了一举两得。4.2 触发功能的实现逻辑触发是数据采集系统里非常核心的功能。它的作用是当信号满足某个条件时系统自动开始采集或者标记采集位置。常见的触发类型有边沿触发、电平触发、脉宽触发、窗口触发等。在这个项目里触发可以在FPGA里做也可以在上位机里做。FPGA里做触发的好处是响应快、延迟低可以在信号出现的瞬间就锁存数据。上位机做触发的好处是灵活可以随时改触发条件不用重新烧写FPGA。我一般会两者结合FPGA里做一个简单的边沿触发用来捕获瞬态信号上位机里做复杂的触发判断用来做后处理分析。FPGA的触发逻辑用Verilog写起来很简单就是一个比较器加一个状态机。比如上升沿触发当信号从低于阈值变成高于阈值时输出一个触发脉冲锁存当前FIFO里的数据。上位机的触发逻辑用软件实现可以做得更复杂。比如当信号超过阈值并且持续超过10个采样点才触发这种逻辑在FPGA里实现起来就比较麻烦但在上位机里就是几行代码的事。4.3 频谱计算与信噪比FFT的正确用法频谱计算的核心是FFT快速傅里叶变换。250M采样率下采集1024个点做FFT频率分辨率是250M/1024 ≈ 244kHz。如果采集更多的点比如65536个点分辨率就提高到3.8kHz。分辨率越高频谱越精细但计算量也越大。做FFT的时候有几个坑要注意。第一是加窗如果信号不是整数个周期直接做FFT会有频谱泄漏。加汉宁窗或者布莱克曼窗可以减小泄漏但会降低频率分辨率。我一般用汉宁窗在泄漏和分辨率之间取个平衡。第二是平均单次FFT的结果噪声很大通常要做多次FFT然后取平均。平均的方式有线性平均和指数平均。线性平均适合稳定的信号指数平均适合变化的信号。第三是信噪比的计算信噪比的定义是信号功率与噪声功率之比。在频谱上信号功率是信号峰值的功率噪声功率是除去信号峰值之外所有频点的功率之和。但要注意噪声功率要扣除直流分量和谐波分量否则算出来的信噪比会偏低。我实际用的计算方法是先做FFT找到信号峰值然后把峰值附近几个频点比如±3个频点之外的功率全部累加作为噪声功率最后用信号功率除以噪声功率取10log10得到dB值。这个方法在大多数情况下都能得到合理的信噪比。5. 调试过程中踩过的坑与排查思路5.1 数据错位从眼图到IDELAY的排查链路项目刚调通的时候采集到的波形总是有毛刺有时候还会出现周期性的错误码。一开始怀疑是ADC的问题换了一块板子还是一样。后来用示波器抓ADC的输出数据线发现数据眼图的质量还可以但FPGA采到的数据就是不对。排查的思路是这样的首先确认ADC的输出码型是否正确。让ADC输出一个已知的测试码型比如斜坡信号然后在FPGA里抓数据看是否和预期一致。如果不一致说明位对齐有问题。然后用FPGA的IDELAY原语扫描延迟值从0到31每个延迟值下采集一批数据统计误码率。误码率最低的那个延迟值就是最佳采样点。这个过程说起来简单但实际操作中要注意每次改变延迟值后要等链路稳定了再采数据。因为IDELAY的改变会导致短暂的链路不稳定如果立刻采数据会采到错误的值。我一般会等1ms再采。另外温度变化也会影响最佳延迟值。夏天调试好的参数冬天可能就不行了。所以IDELAY的训练不能只做一次最好在系统启动时自动做一次训练或者定期做训练。5.2 上位机丢数据从驱动到应用层的逐层排查上位机丢数据是高速采集系统里最常见的问题。排查的时候要一层一层来先看FPGA有没有把数据发出去再看驱动有没有收到再看应用层有没有读到。怎么看FPGA有没有发出去可以在FPGA里加一个计数器统计发送的数据包数量然后通过一个低速接口比如UART读出来。如果FPGA发的包数和预期一致说明FPGA没问题。怎么看驱动有没有收到可以在驱动里加打印统计收到的数据包数量。如果驱动的包数比FPGA少说明驱动层丢了。这时候要检查DMA缓冲区的大小、中断处理的时机、有没有其他中断抢占等等。怎么看应用层有没有读到可以在应用层加计数器统计读到的数据量。如果应用层的包数比驱动少说明应用层丢了。这时候要检查应用层的缓冲区大小、读取频率、有没有被其他线程阻塞等等。我遇到过一次丢数据的问题排查到最后发现是应用层的缓冲区太小。应用层每次从驱动读1MB的数据但驱动的缓冲区是4MB应用层读得不够快驱动的缓冲区就溢出了。后来把应用层的读取频率提高或者把驱动的缓冲区改小问题就解决了。5.3 信噪比不达标从电源噪声到接地环路信噪比不达标是另一个常见问题。理论信噪比是86dB但实际测出来只有70dB差了16dB。这16dB去哪里了首先怀疑电源噪声。ADC的电源如果纹波太大会直接调制到输出信号上。用示波器测ADC的电源引脚如果纹波超过几毫伏就要加滤波电容或者换LDO。我一般会在ADC的电源引脚旁边放多个不同容值的电容比如100nF、1uF、10uF覆盖不同频率的噪声。其次怀疑接地环路。如果ADC和FPGA的地平面不干净数字噪声会通过地平面耦合到模拟部分。解决办法是用单点接地把模拟地和数字地在ADC下面用一个点连接起来而不是到处都连。另外ADC的模拟输入要走差分线并且要远离数字信号线。最后怀疑时钟抖动。前面说过时钟抖动会直接恶化信噪比。如果电源和接地都排查过了信噪比还是不行就要考虑换一个抖动更低的时钟源或者优化时钟的PCB走线。6. 一些实操心得与参数配置建议6.1 ADC配置寄存器的常见陷阱高速ADC通常通过SPI接口来配置内部寄存器。配置的时候有几个坑要注意。第一是上电顺序有些ADC要求先给模拟电源再给数字电源最后给时钟。如果顺序错了ADC可能不工作或者工作不正常。具体顺序要看数据手册不能想当然。第二是寄存器的默认值很多ADC的寄存器有默认值但这些默认值不一定适合你的应用。比如有些ADC默认是低功耗模式采样率上不去。配置的时候要仔细看数据手册把该改的寄存器都改对。第三是配置的时序SPI的时钟频率不能太高一般不超过10MHz。配置完成后要等一段时间让ADC稳定再开始采集。我一般会等10ms。6.2 FPGA时序约束的写法FPGA的时序约束是保证数据正确传输的关键。对于ADC接口需要约束输入时钟的频率、输入数据的建立时间和保持时间。对于PCIe接口需要约束参考时钟和收发器的时序。写时序约束的时候最重要的是时钟定义。比如ADC的DCO时钟是250MHz就要在XDC文件里定义create_clock。然后定义input delay和output delay告诉工具数据相对于时钟的到达时间。如果这些约束写错了工具可能会报时序违例或者更糟糕的是不报违例但实际工作不稳定。我一般会用时序报告来检查约束是否合理。如果某个路径的slack是负的说明时序不满足需要优化逻辑或者调整约束。如果slack太大比如超过2ns说明约束可能太松了实际工作中可能有问题。6.3 上位机软件的线程模型上位机软件要同时做很多事情接收数据、显示波形、计算频谱、响应用户操作。如果都用单线程界面会卡死。所以要用多线程。我一般用三线程模型一个线程负责接收数据一个线程负责数据处理FFT、触发判断一个线程负责界面刷新。接收线程优先级最高保证数据不丢处理线程优先级中等界面线程优先级最低因为界面卡一点用户还能忍数据丢了就麻烦了。线程之间的数据传递用环形缓冲区Ring Buffer。接收线程往缓冲区里写处理线程从缓冲区里读。环形缓冲区的好处是读写可以并行不需要加锁用原子操作来管理读写指针。这样效率高延迟低。6.4 关于触发位置的设置技巧触发位置决定了触发点在采集缓冲区中的位置。如果触发位置设为0%触发点就在缓冲区的开头只能看到触发之后的信号。如果设为50%触发点在中间可以看到触发前后各一半的信号。如果设为100%触发点在末尾只能看到触发之前的信号。实际使用中**触发位置设为10%到25%**比较合适。这样既能看到触发前的信号用于分析触发原因又能看到触发后的大部分信号用于分析信号特征。如果触发位置设得太靠后触发后的信号就看不到了。另外触发位置和FIFO的深度也有关系。如果FIFO深度不够触发位置设得太靠前触发前的数据可能已经被覆盖了。所以FIFO深度要足够大至少要能存下触发位置之前的所有数据。7. 这个项目还能怎么扩展这套ADDA采集系统的框架其实可以复用到很多场景。比如把ADC换成更高采样率的型号就可以做射频采样把传输接口从PCIe换成万兆以太网就可以做远程采集把上位机的频谱计算换成更复杂的调制识别算法就可以做信号分析仪。我自己在这个项目的基础上后来加了一个数据记录功能把采集到的原始数据存成二进制文件然后用Python做离线分析。Python的numpy和scipy库做FFT和滤波非常方便比在上位机里用C写快多了。如果你也要做类似的项目建议把数据存储和分析分开采集归采集分析归分析这样系统更灵活。还有一个扩展方向是多板同步。如果一块板卡不够用可以用多块板卡同时采集然后用一个共同的时钟和触发信号来同步。这样就能做多通道的相参采集用于阵列信号处理等应用。多板同步的关键是时钟和触发的分配要用专门的时钟分配芯片保证各路时钟的相位一致。最后说一个我在实际项目中总结的小经验调试高速采集系统一定要有好的测试设备。一台高带宽的示波器至少1GHz带宽、一个低抖动的信号发生器、一个频谱分析仪这三样东西能帮你省下大量排查时间。如果没有这些设备很多问题只能靠猜效率会低很多。 
长河君 · 2026/10/29 1:05:19 · 阅读 1.2k 250M采样率14BIT双通道高速ADC采集系统设计与实现
1. 从一块250M采样率的ADC板卡说起这个项目到底在做什么第一次拿到这个需求的时候我盯着250M采样率、14BIT、双通道这几个参数看了很久。做过数据采集的人都知道这三个数字凑在一起意味着什么——它已经脱离了普通单片机内置ADC那种玩具级的范畴进入了高速数据采集系统的领域。250M采样率意味着每秒要产生2.5亿个采样点14BIT精度意味着每个点用两个字节来存双通道意味着这个数字还要翻倍。简单算一下250M × 2字节 × 2通道 1GB/s的原始数据吞吐量。这个量级的数据靠STM32那种几十兆主频的MCU去直接读取基本是不现实的。所以这个项目的本质是一个典型的高速ADDA模数转换与数模转换数据采集与传输系统。它的核心链路是这样的模拟信号进入高速ADC芯片ADC在250M采样时钟的驱动下把模拟波形数字化FPGA或者专用的高速接口芯片负责把高速并行数据缓存、打包然后通过某种高速总线比如PCIe、千兆/万兆以太网、USB3.0等传输到上位机。上位机拿到数据之后要做三件事把波形画出来给人看、根据设定的条件做触发判断、对采集到的信号做频谱分析并计算信噪比等指标。这里面每一个环节都有坑。ADC的采样时钟怎么给、数据怎么对齐、传输带宽够不够、上位机怎么保证不丢数据、触发逻辑放在FPGA里还是上位机里、频谱计算用FFT还是别的算法、信噪比怎么算才准确——这些问题我在实际做项目的过程中都踩过一遍。这篇文章就把整个项目的设计思路、关键参数的计算过程、实操中的注意事项以及上位机软件的实现要点完整地梳理一遍。适合读这篇文章的人应该是对数据采集系统有一定了解但还没完整做过高速采集项目的工程师或者正在做类似项目、卡在某个环节上的人。如果你连ADC是什么都还不清楚建议先补一下基础因为下面的内容会涉及不少硬件和信号处理层面的细节。2. 250M采样率14BIT双通道ADC的硬件链路设计2.1 为什么这个采样率下不能再用MCU直接读ADC很多人做ADC采集的第一反应是找一款带高速ADC接口的单片机比如STM32H7系列有DCMI或者SPI接口理论上也能接外部ADC。但250M采样率这个量级MCU的方案直接出局。原因很简单MCU的GPIO翻转速度、总线读取速度、中断响应时间都跟不上250MHz的数据速率。我们来算一笔账。假设ADC输出的是14BIT并行数据加上一个数据时钟DCO和一个帧同步信号至少需要16根信号线。250MHz的频率下每根线的建立时间和保持时间可能只有几百皮秒。MCU的GPIO在这种频率下根本无法稳定采样更别说还要把数据读进内存再通过串口或者USB发出去。所以这个项目里FPGA几乎是唯一的选择。FPGA可以做到用LVDS或者LVCMOS接口直接接收ADC的高速并行数据在片内用FIFO做跨时钟域处理然后通过高速收发器GTP/GTX/GTH或者外挂的PCIe硬核把数据送到上位机。我实际用过的方案是Xilinx的Artix-7或者Kintex-7系列FPGA配合ADI或者TI的高速ADC。ADC的选型上ADI的AD968014BIT双通道、最高1G采样率或者TI的ADS54J6016BIT双通道、最高1G采样率都是常见的选择。如果只需要250M采样率可以选低一档的型号成本会低不少。2.2 采样时钟的质量直接决定信噪比高速ADC对采样时钟的抖动Jitter极其敏感。14BIT的ADC理论信噪比上限是SNR 6.02N 1.76 6.02×14 1.76 ≈ 86dB。但这个86dB是在理想时钟条件下才能达到的。如果采样时钟的抖动太大信噪比会急剧下降。具体怎么算采样时钟抖动引入的信噪比恶化可以用这个公式估算SNR_jitter -20log(2π × f_in × t_jitter)其中f_in是输入信号频率t_jitter是时钟的RMS抖动。假设输入信号是100MHz时钟抖动是100fs飞秒那么SNR_jitter -20log(2π × 100e6 × 100e-15) ≈ -20log(0.0628) ≈ 24dB。这个数字看起来还行但如果时钟抖动变成1psSNR_jitter就降到约4dB整个系统的信噪比就被时钟抖动完全主导了。所以在这个项目里采样时钟必须用专用的低抖动时钟芯片比如TI的LMK04828或者ADI的HMC7044。这些芯片可以输出多路同步时钟抖动可以做到100fs以下。同时时钟的PCB走线要做阻抗匹配尽量短远离数字噪声源。我在实际调试中遇到过因为时钟走线经过了一个开关电源附近导致信噪比直接掉了10dB的情况后来把时钟线改到另一层远离电源平面问题才解决。2.3 数据接口与FPGA的对接细节ADC和FPGA之间的数据接口常见的有LVDS低压差分信号和JESD204B高速串行接口。250M采样率、14BIT、双通道的情况下如果走LVDS并行接口数据速率是250M × 14BIT × 2通道 7Gbps需要分成多对差分线来传输。如果走JESD204B可以用更少的线数但协议更复杂需要额外的SYSREF和同步信号。我个人的经验是如果FPGA的IO资源够用LVDS并行接口更直观调试起来也更容易。JESD204B虽然线少但一旦链路建立不起来排查起来非常痛苦需要抓眼图、调均衡参数。对于250M采样率这个量级LVDS方案完全够用。在FPGA内部接收到的数据要先做位对齐和字对齐。因为ADC输出的数据是随路时钟DCO同步的FPGA需要用IDELAY或者ISERDES来调整采样点确保每个bit都能正确采到。这个过程通常需要写一个训练状态机发送特定的测试码型比如PRBS然后扫描延迟值找到误码率最低的那个点。这个步骤在调试初期非常关键如果位对齐没做好后面所有的数据都是错的。3. 数据从FPGA到上位机传输方案的选择与取舍3.1 几种高速传输方案的对比数据从FPGA到上位机常见的方案有PCIe、以太网、USB3.0这几种。每种方案都有自己的适用场景选错了会在后期调试中付出很大代价。传输方案理论带宽实际可用带宽开发难度适用场景PCIe Gen2 x420Gbps约12Gbps高板卡插在工控机内要求高带宽低延迟千兆以太网1Gbps约800Mbps中传输距离远带宽要求不高万兆以太网10Gbps约7Gbps高需要远距离高带宽USB3.05Gbps约3Gbps中便携设备即插即用对于250M采样率、14BIT、双通道的系统原始数据率是7Gbps。如果要做连续采集千兆以太网肯定不够USB3.0也勉强。PCIe Gen2 x4或者万兆以太网是比较现实的选择。但如果系统只需要做短时采集比如每次采集1ms的数据然后停下来分析那么数据量就是7Gbps × 1ms 7Mbit千兆以太网也能在几十毫秒内传完。我在实际项目中用的是PCIe Gen2 x2的方案实际带宽能跑到约6Gbps对于短时采集完全够用。PCIe的好处是延迟低、驱动成熟Xilinx和Altera都有现成的DMA IP核可以用。缺点是板卡必须插在机箱里不够灵活。3.2 FPGA内部的FIFO与DMA设计不管用哪种传输方案FPGA内部都需要一个高速FIFO来缓冲数据。因为ADC的数据是连续不断的而传输接口的带宽可能不够或者上位机可能暂时忙不过来。FIFO的作用就是平滑数据流防止溢出。FIFO的深度需要根据最坏情况来算。假设传输接口的带宽是6GbpsADC的数据率是7Gbps那么FIFO的写入速度比读出速度快1Gbps。如果一次采集持续1ms那么FIFO里会积累1Gbps × 1ms 1Mbit的数据。所以FIFO至少要有1Mbit的深度才能保证不溢出。实际设计中我会留2倍余量用2Mbit的FIFO。DMA的设计也很关键。PCIe的DMA通常用描述符Descriptor来管理每个描述符指向一块内存区域。FPGA把数据写满一块区域后更新描述符然后触发中断通知驱动。驱动再把数据拷贝到用户空间。这个过程中描述符的数量和大小会影响传输效率。描述符太小中断太频繁CPU开销大描述符太大延迟高内存占用多。我一般用4KB到64KB之间的描述符大小具体看系统需求。3.3 上位机接收数据时的丢包问题上位机接收高速数据时最容易出的问题就是丢包。丢包的原因可能有很多驱动缓冲区太小、中断处理太慢、内存拷贝次数太多、用户态程序调度不及时等等。我在调试的时候就遇到过一个问题采集1ms的数据上位机收到的数据总是少那么几个点。后来用逻辑分析仪抓PCIe的TLP包发现FPGA确实把数据都发出去了问题出在驱动层。驱动的中断处理函数里做了一次内存拷贝这个拷贝是在中断上下文里做的耗时太长导致后续的中断被延迟处理DMA缓冲区溢出。解决办法是把中断处理分成两部分上半部只做最简单的标记下半部用工作队列或者tasklet来做实际的数据拷贝。这样中断响应就快了不会丢数据。另外用DMA做内存到内存的拷贝而不是用CPU来拷贝也能大大降低CPU开销。4. 上位机软件的核心功能实现4.1 波形显示怎么画才能不卡上位机要显示采集到的波形250M采样率下即使只显示1ms的数据也有25万个点。如果用普通的绘图库比如C#的Chart控件或者Qt的QCustomPlot直接画25万个点界面会卡到无法操作。解决办法有几个。第一是降采样显示在数据量远大于屏幕像素数的时候不需要把每个点都画出来。可以用峰值检测或者均值降采样的方法把25万个点压缩到屏幕宽度的点数比如1920个点。峰值检测的做法是把数据分成1920个区间每个区间取最大值和最小值然后画两条线。这样既能保留波形的包络特征又能大幅减少绘图点数。第二是用OpenGL或者DirectX来加速绘图。普通的GDI绘图在大量数据下性能很差而GPU绘图可以轻松处理百万级的点。Qt的QOpenGLWidget或者C#的SharpGL都是不错的选择。第三是分段加载不要一次性把所有数据都加载到内存里而是分页加载。用户拖动滚动条的时候再加载对应区域的数据。这样内存占用小响应也快。我实际用的方案是降采样加OpenGL。降采样在FPGA里做一部分比如先做4倍降采样上位机再做剩下的。这样传输的数据量也小了一举两得。4.2 触发功能的实现逻辑触发是数据采集系统里非常核心的功能。它的作用是当信号满足某个条件时系统自动开始采集或者标记采集位置。常见的触发类型有边沿触发、电平触发、脉宽触发、窗口触发等。在这个项目里触发可以在FPGA里做也可以在上位机里做。FPGA里做触发的好处是响应快、延迟低可以在信号出现的瞬间就锁存数据。上位机做触发的好处是灵活可以随时改触发条件不用重新烧写FPGA。我一般会两者结合FPGA里做一个简单的边沿触发用来捕获瞬态信号上位机里做复杂的触发判断用来做后处理分析。FPGA的触发逻辑用Verilog写起来很简单就是一个比较器加一个状态机。比如上升沿触发当信号从低于阈值变成高于阈值时输出一个触发脉冲锁存当前FIFO里的数据。上位机的触发逻辑用软件实现可以做得更复杂。比如当信号超过阈值并且持续超过10个采样点才触发这种逻辑在FPGA里实现起来就比较麻烦但在上位机里就是几行代码的事。4.3 频谱计算与信噪比FFT的正确用法频谱计算的核心是FFT快速傅里叶变换。250M采样率下采集1024个点做FFT频率分辨率是250M/1024 ≈ 244kHz。如果采集更多的点比如65536个点分辨率就提高到3.8kHz。分辨率越高频谱越精细但计算量也越大。做FFT的时候有几个坑要注意。第一是加窗如果信号不是整数个周期直接做FFT会有频谱泄漏。加汉宁窗或者布莱克曼窗可以减小泄漏但会降低频率分辨率。我一般用汉宁窗在泄漏和分辨率之间取个平衡。第二是平均单次FFT的结果噪声很大通常要做多次FFT然后取平均。平均的方式有线性平均和指数平均。线性平均适合稳定的信号指数平均适合变化的信号。第三是信噪比的计算信噪比的定义是信号功率与噪声功率之比。在频谱上信号功率是信号峰值的功率噪声功率是除去信号峰值之外所有频点的功率之和。但要注意噪声功率要扣除直流分量和谐波分量否则算出来的信噪比会偏低。我实际用的计算方法是先做FFT找到信号峰值然后把峰值附近几个频点比如±3个频点之外的功率全部累加作为噪声功率最后用信号功率除以噪声功率取10log10得到dB值。这个方法在大多数情况下都能得到合理的信噪比。5. 调试过程中踩过的坑与排查思路5.1 数据错位从眼图到IDELAY的排查链路项目刚调通的时候采集到的波形总是有毛刺有时候还会出现周期性的错误码。一开始怀疑是ADC的问题换了一块板子还是一样。后来用示波器抓ADC的输出数据线发现数据眼图的质量还可以但FPGA采到的数据就是不对。排查的思路是这样的首先确认ADC的输出码型是否正确。让ADC输出一个已知的测试码型比如斜坡信号然后在FPGA里抓数据看是否和预期一致。如果不一致说明位对齐有问题。然后用FPGA的IDELAY原语扫描延迟值从0到31每个延迟值下采集一批数据统计误码率。误码率最低的那个延迟值就是最佳采样点。这个过程说起来简单但实际操作中要注意每次改变延迟值后要等链路稳定了再采数据。因为IDELAY的改变会导致短暂的链路不稳定如果立刻采数据会采到错误的值。我一般会等1ms再采。另外温度变化也会影响最佳延迟值。夏天调试好的参数冬天可能就不行了。所以IDELAY的训练不能只做一次最好在系统启动时自动做一次训练或者定期做训练。5.2 上位机丢数据从驱动到应用层的逐层排查上位机丢数据是高速采集系统里最常见的问题。排查的时候要一层一层来先看FPGA有没有把数据发出去再看驱动有没有收到再看应用层有没有读到。怎么看FPGA有没有发出去可以在FPGA里加一个计数器统计发送的数据包数量然后通过一个低速接口比如UART读出来。如果FPGA发的包数和预期一致说明FPGA没问题。怎么看驱动有没有收到可以在驱动里加打印统计收到的数据包数量。如果驱动的包数比FPGA少说明驱动层丢了。这时候要检查DMA缓冲区的大小、中断处理的时机、有没有其他中断抢占等等。怎么看应用层有没有读到可以在应用层加计数器统计读到的数据量。如果应用层的包数比驱动少说明应用层丢了。这时候要检查应用层的缓冲区大小、读取频率、有没有被其他线程阻塞等等。我遇到过一次丢数据的问题排查到最后发现是应用层的缓冲区太小。应用层每次从驱动读1MB的数据但驱动的缓冲区是4MB应用层读得不够快驱动的缓冲区就溢出了。后来把应用层的读取频率提高或者把驱动的缓冲区改小问题就解决了。5.3 信噪比不达标从电源噪声到接地环路信噪比不达标是另一个常见问题。理论信噪比是86dB但实际测出来只有70dB差了16dB。这16dB去哪里了首先怀疑电源噪声。ADC的电源如果纹波太大会直接调制到输出信号上。用示波器测ADC的电源引脚如果纹波超过几毫伏就要加滤波电容或者换LDO。我一般会在ADC的电源引脚旁边放多个不同容值的电容比如100nF、1uF、10uF覆盖不同频率的噪声。其次怀疑接地环路。如果ADC和FPGA的地平面不干净数字噪声会通过地平面耦合到模拟部分。解决办法是用单点接地把模拟地和数字地在ADC下面用一个点连接起来而不是到处都连。另外ADC的模拟输入要走差分线并且要远离数字信号线。最后怀疑时钟抖动。前面说过时钟抖动会直接恶化信噪比。如果电源和接地都排查过了信噪比还是不行就要考虑换一个抖动更低的时钟源或者优化时钟的PCB走线。6. 一些实操心得与参数配置建议6.1 ADC配置寄存器的常见陷阱高速ADC通常通过SPI接口来配置内部寄存器。配置的时候有几个坑要注意。第一是上电顺序有些ADC要求先给模拟电源再给数字电源最后给时钟。如果顺序错了ADC可能不工作或者工作不正常。具体顺序要看数据手册不能想当然。第二是寄存器的默认值很多ADC的寄存器有默认值但这些默认值不一定适合你的应用。比如有些ADC默认是低功耗模式采样率上不去。配置的时候要仔细看数据手册把该改的寄存器都改对。第三是配置的时序SPI的时钟频率不能太高一般不超过10MHz。配置完成后要等一段时间让ADC稳定再开始采集。我一般会等10ms。6.2 FPGA时序约束的写法FPGA的时序约束是保证数据正确传输的关键。对于ADC接口需要约束输入时钟的频率、输入数据的建立时间和保持时间。对于PCIe接口需要约束参考时钟和收发器的时序。写时序约束的时候最重要的是时钟定义。比如ADC的DCO时钟是250MHz就要在XDC文件里定义create_clock。然后定义input delay和output delay告诉工具数据相对于时钟的到达时间。如果这些约束写错了工具可能会报时序违例或者更糟糕的是不报违例但实际工作不稳定。我一般会用时序报告来检查约束是否合理。如果某个路径的slack是负的说明时序不满足需要优化逻辑或者调整约束。如果slack太大比如超过2ns说明约束可能太松了实际工作中可能有问题。6.3 上位机软件的线程模型上位机软件要同时做很多事情接收数据、显示波形、计算频谱、响应用户操作。如果都用单线程界面会卡死。所以要用多线程。我一般用三线程模型一个线程负责接收数据一个线程负责数据处理FFT、触发判断一个线程负责界面刷新。接收线程优先级最高保证数据不丢处理线程优先级中等界面线程优先级最低因为界面卡一点用户还能忍数据丢了就麻烦了。线程之间的数据传递用环形缓冲区Ring Buffer。接收线程往缓冲区里写处理线程从缓冲区里读。环形缓冲区的好处是读写可以并行不需要加锁用原子操作来管理读写指针。这样效率高延迟低。6.4 关于触发位置的设置技巧触发位置决定了触发点在采集缓冲区中的位置。如果触发位置设为0%触发点就在缓冲区的开头只能看到触发之后的信号。如果设为50%触发点在中间可以看到触发前后各一半的信号。如果设为100%触发点在末尾只能看到触发之前的信号。实际使用中**触发位置设为10%到25%**比较合适。这样既能看到触发前的信号用于分析触发原因又能看到触发后的大部分信号用于分析信号特征。如果触发位置设得太靠后触发后的信号就看不到了。另外触发位置和FIFO的深度也有关系。如果FIFO深度不够触发位置设得太靠前触发前的数据可能已经被覆盖了。所以FIFO深度要足够大至少要能存下触发位置之前的所有数据。7. 这个项目还能怎么扩展这套ADDA采集系统的框架其实可以复用到很多场景。比如把ADC换成更高采样率的型号就可以做射频采样把传输接口从PCIe换成万兆以太网就可以做远程采集把上位机的频谱计算换成更复杂的调制识别算法就可以做信号分析仪。我自己在这个项目的基础上后来加了一个数据记录功能把采集到的原始数据存成二进制文件然后用Python做离线分析。Python的numpy和scipy库做FFT和滤波非常方便比在上位机里用C写快多了。如果你也要做类似的项目建议把数据存储和分析分开采集归采集分析归分析这样系统更灵活。还有一个扩展方向是多板同步。如果一块板卡不够用可以用多块板卡同时采集然后用一个共同的时钟和触发信号来同步。这样就能做多通道的相参采集用于阵列信号处理等应用。多板同步的关键是时钟和触发的分配要用专门的时钟分配芯片保证各路时钟的相位一致。最后说一个我在实际项目中总结的小经验调试高速采集系统一定要有好的测试设备。一台高带宽的示波器至少1GHz带宽、一个低抖动的信号发生器、一个频谱分析仪这三样东西能帮你省下大量排查时间。如果没有这些设备很多问题只能靠猜效率会低很多。