基于KCU105+ADRV9371板卡的ADI IIO Oscilloscope操控参考设计与...

ad9371参考设计，移植 基于kcu105＋adrv9371板卡，通过adi iio oscilloscope软件进行操控和查看 提供移植支持和工程 包含hdl工程、vitis工程、各种文档、文件 提供

最近在折腾ADI的AD9371射频芯片，发现官方给的KCU105+ADRV9371方案确实是个好东西。这玩意儿的参考设计直接拿过来用虽然方便，但真要把整套系统移植到自家板卡上，可没想象中那么简单。今天就唠唠移植过程中那些必须踩的坑。

硬件配置这块，先得确认时钟树是不是匹配。官方给的JESD204B IP核配置参数特别容易翻车，这里贴段关键代码：

// JESD参数配置 parameter L = 4; // lanes数量 parameter F = 4; // 每帧octets数 parameter S = 1; // 每帧采样数 assign device_clk = clkgen_0/clk_out1; // 注意这个312.5MHz时钟

这段配置直接关系到基带和射频的数据对齐，之前手贱把F值改成了2，结果IIO Oscilloscope里波形直接碎成马赛克。建议先用官方给的ILA抓一下JESD接口的eye diagram，眼图睁不开的话基本不用往下走了。

软件栈方面，Vitis工程里有个巨坑藏在device tree里。遇到过最离谱的bug是DMA地址映射没对齐，症状是能识别到AD9371但采集不到数据。这时候得去zynqultrapse0的配置里检查AXI地址分配：

// axi_dmac地址段不能和其他IP冲突 axi_dmac: axi-dmac@80000000 { compatible = "adi,axi-dmac-1.00.a"; reg = <0x80000000 0x1000>; };

当时在这个地址段和AXI SPI控制器撞车，系统直接启动失败。推荐用Vitis的Address Auto Assign功能，但自动分配完一定得手动复查。

调试时推荐用ADI提供的Python脚本配合IIO Oscilloscope，比纯C API直观多了。比如这个扫频脚本：

with iio.Context('ip:192.168.1.100') as ctx: tx = ctx.find_device("cf_ad9371_dds_core") tx.attrs['frequency'].value = '1000000000' # 1GHz载波 rx = ctx.find_device("cf_ad9371_lpc") data = rx.channels[0].capture(1024) plt.plot(np.real(data)) # 实时看时域波形

跑这段脚本时如果报超时，八成是JESD链路没锁住。这时候别急着怀疑代码，先检查板子上的SYNC信号灯是不是绿的。

文档里藏着个金钥匙——adiprojecttree.txt文件。这个树状图把整个工程的文件夹结构理得明明白白，移植时按图索骥比瞎找强。特别是hdl2019r2分支下的约束文件，不同年份的版本引脚分配差异贼大。

最后说个玄学问题：遇到过几次上电后ARM核死活起不来，后来发现是电源时序问题。官方手册里明确要求1V8要先于其他电压上电，实际用示波器抓板卡电源轨才发现有个LDO响应慢了3ms。改完供电电路后世界终于清净了。

整套工程包里有几个宝藏文件：transplantchecklist.md列了23个验证项，从DDR4校准到SPI Flash烧写全齐活了；jupyternotebooks文件夹里的交互式调试指南，比看PDF爽多了。建议移植时开着IIO Scope和Vivado联调，三屏操作更下饭。

要工程源码的直接私，仓库里连SD卡镜像都准备好了，刷进去就能开机跑demo。不过提醒一句，官方tcl脚本生成bitstream至少要跑40分钟，建议备好速溶咖啡。