简介面向ZYNQ课设与FPGA综合实践的双项目实战包涵盖从基础实验到人机交互的不同难度适合数字系统设计、嵌入式系统课程设计或毕业设计参考。内含两个完整可运行项目FFT频谱分析系统覆盖Vivado IP核构建、信号采集到实时频域显示的完整链路并附设计文档、仿真与运行截图打地鼠交互游戏采用PL端逻辑控制核心、PS端Linux或裸机程序交互的架构工程目录清晰附带实验报告与硬件运行实拍图两个项目均提供可直接打开的Vivado工程文件。包内共83个文件以vhd硬件源码22个、do仿真脚本14个、sh辅助脚本7个及doc文档、png截图为主整体仅11.28MB结构紧凑、分类明确。已有16人学习下载所有内容均经过真实开发环境验证可直接对照搭建省去从零调试与整理资料的弯路也适合考前突击作为课程设计的完整方案参考。 第一次把FFT频谱分析跑在ZYNQ上、看到屏上真的出现一条随输入频率移动的谱线时我心里那块石头才算彻底落地。ZYNQ这个平台ARM和FPGA待在同一个片子里能用PL做高速数据通路、用PS跑交互逻辑听起来很美但真要把FFT这种经典信号处理从IP核配置一路推到屏幕显示中间全是教材不会告诉你的坑。这次我把两个方向完全不同的项目——FFT频谱分析、打地鼠交互游戏——整理成了一组双项目实战包工程基于Vivado构建完整Block Design、约束文件、应用源码、实测截图都归档好了。前者练的是AXI数据通路和IP核调度后者练的是PS/PL协同和状态机设计正好把ZYNQ开发里最核心的两条主线一次打通。这篇文章就把这两个项目背后的设计思路、关键实现和调试心得摊开讲一遍适合正在学ZYNQ、准备从仿真走向板卡的朋友参考。1. 为什么是这两个项目FFT与打地鼠背后的ZYNQ学习主线1.1 FFT频谱分析练的是数据通路不是算法本身很多人一听到FFT第一反应是去查DFT公式、研究蝶形运算。真到了ZYNQ上你会发现Xilinx早就把FFT IP核封装好了你根本不需要手写蝶形运算真正卡住你的是数据怎么送进去、结果怎么接出来、显示怎么刷新。FFT IP核的输入输出都是AXI4-Stream接口这一套握手信号tvalid、tready、tlast、tuser才是整个项目真正的难点。数据流式进入、流式输出中间还牵扯DMA搬运、BRAM缓存、时钟域匹配。做完这个项目你对AXI总线的理解会有一个质的提升这种底子后面做图像采集、高速通信全用得上。1.2 打地鼠交互游戏练的是PS/PL分工逻辑设计反而简单打地鼠这个游戏功能拆开看非常简单随机位置冒出一只地鼠玩家按键敲中得分加一没敲中地鼠消失。但越简单的功能越能暴露系统设计的问题。一开始我把游戏逻辑全放在PS端定时器、随机数、碰撞检测、分数刷新全让ARM去跑结果按键扫描和显示刷新互相干扰地鼠消失计时也有明显抖动。后来把地鼠状态机、命中判定、计时这些实时性要求高的逻辑挪到PL端PS只保留启停控制和分数显示整个系统立刻清爽了。这个设计过程教会我的不是怎么写状态机而是怎么判断一段功能该放PL还是PS——这是ZYNQ开发里最核心的架构决策能力。1.3 两个项目组合成一条递进学习路线实战包按先FFT、后打地鼠的顺序组织不是随手排的。FFT项目逼你把AXI DMA、VDMA、FFT IP核之间那条数据链路跑通这些底层能力放到打地鼠项目里就变成PS通过AXI GPIO读写PL寄存器的小事。反过来如果一上来就做打地鼠你可能花大量时间在调按键消抖和显示时序上反而错过了对总线的理解。两个项目做完PL端的数据流和PS端的交互控制都有了实操经验ZYNQ最典型的两种开发范式——数据密集型、控制密集型的——正好都覆盖到了。2. Vivado工程速览从PS配置到PL逻辑的完整骨架2.1 两个工程的硬件架构与IP选型差异虽然是同一个Zynq-7000平台两个工程的Block Design差别非常大我把关键IP列个表方便对照功能模块FFT频谱分析工程打地鼠交互游戏工程处理器系统Zynq PSDDR、UART、SDZynq PSDDR、UART、GPIO数据通路AXI DMA FFT IP VDMAAXI GPIO 控制PL寄存器显示输出VGA/HDMIVDMA驱动TFT/LCDSPI或并口随机数产生无输入为固定采样数据/ADCPL端LFSR伪随机发生器中断机制DMA传输完成中断定时器中断 按键中断FFT工程的核心在数据搬移PS端通过AXI DMA把时域采样数据送进FFT IP核变换结果再经VDMA送到显示端。打地鼠工程完全没有大数据流真正重要的是PS与PL之间的小规模寄存器交互——AXI GPIO在这里比自定义AXI外设更省事减少一块是一块没必要为了显得高级给简单功能包一层复杂接口。2.2 时钟、复位与约束的常见坑两个工程共用同一个PS配置的思路但PL侧时钟必须单独考虑。FFT IP核和VDMA对时钟频率比较敏感实测在100MHz下跑4096点FFT没问题打地鼠的状态机逻辑跑得很慢给个25MHz都绰绰有余。这里有个典型的错误Vivado的自动连接有时会默认把某个AXI端口接到FCLK_CLK0上如果这个时钟和IP核实际需要的时钟不一致仿真能过综合布线也不报错上板就随机性卡死。所以每次配完Block Design建议先打开Clock Wizard看看输出频率是否和预期一致再继续往下走。约束文件同样容易出事。很多新手Block Design画完了直接Generate Bitstream然后收到DRC报错。原因很直白没写XDC约束管脚位置和时钟周期都没声明Vivado不知道信号该往芯片哪个引脚走。FFT工程至少要约束好DDR、UART、显示接口的管脚打地鼠工程则要约束按键、LED、LCD接口。约束文件的完整写法在实战包里有模板直接对着改即可。2.3 工程目录结构参考这套实战包每个项目都按统一目录组织方便复现vivado_prj/Vivado工程文件、Block Design导出、综合实现结果src/hdl/自定义Verilog/VHDL源码如LFSR、状态机、按键消抖src/vitis/PS端C工程包含BSP配置和应用代码constrs/XDC约束文件docs/实测截图、接线说明、操作流程我强烈建议你拿到工程后先打开vivado_prj里的Block Design看一下整体结构再对照docs里的截图理解数据流最后才去动源码。一上来就翻代码很容易被细节淹没。3. FFT频谱分析项目从AXI数据通路到频谱显示的完整链路3.1 FFT IP核参数配置最容易被忽略的两个选项Xilinx FFT IP核配置界面里参数很多但真正影响板级效果的就那么几个变换长度Transform Length我用的4096点。点数越大频率分辨率f_s/N越高但输出帧率越低。1024点在示波器类应用里刷新快适合观察信号动态变化4096点更适合需要精细分辨两个相邻频率的场景。如果你拿不定主意先用1024点把链路跑通再切4096点。IP核在Vivado里要重新生成但工程整体不动。缩放策略Scaling Schedule / Block Floating Point这是最容易忽略的选项。FFT内部每级蝶形运算都可能溢出IP核提供无缩放、逐级缩放、块浮点三种方式。我实测下来块浮点是最省心的它自动根据整帧数据的最大值决定缩放因子精度也够用。如果你图省事选了无缩放输入信号幅度稍微大一点输出直接饱和频谱图会出现很多假峰而且这种问题看代码根本看不出来只能靠实测发现。输出顺序建议选Natural Order这样FFT结果刚好按频率从低到高排列省得在PS端再reverse一次。3.2 时域数据送到频域结果的完整搬运流程FFT工程的完整数据链路是这样的PS端准备时域采样数据可以来自ADC也可以是由DDS IP核生成的测试信号通过AXI DMA以流模式写入FFT IP核的s_axis接口FFT IP核完成变换后结果从m_axis接口输出经VDMA送到显示控制器最终显示在VGA/HDMI屏幕上。监听DMA的完成中断PS就能知道一帧FFT数据已经处理完。这条链路里最容易断的点在握手信号。FFT IP核的输入接口必须看到tvalid和tready同时拉高才开始接收数据而tlast用来标识一帧的最后一笔数据。如果DMA没有正确配置突发长度tlast永远不来FFT IP核就一直等在那里后续数据全部堆积表现出来就是输出端半天没有数据、屏幕花屏或者不动。遇到这种情况不要怀疑IP核坏了先用ILA抓一下s_axis接口的tvalid和tready基本十有八九是这里的问题。3.3 频谱显示的横轴标定与纵轴量程处理把FFT输出直接拿来显示是不行的这里还要做两道转换。横轴方向第k个输出点对应的频率是k*f_s/N如果不做这个换算屏幕上的谱线位置和实际频率对不上你会觉得频率怎么偏了。纵轴方向FFT输出的幅度范围很大直接当像素值会看到一条填满屏幕的直线必须做对数压缩或者开方处理。我在PL端用移位加查找表的方式近似实现dB转换没用浮点运算资源开销小很多。这个思路和纯软件上做FFT完全不同软件里一个log10函数随便调FPGA里就要想怎么用简化算法逼近。3.4 实测截图解读不平整的频谱说明什么问题实战包里的实测截图中有一张显示的是单一正弦波输入时的频谱旁边还有一些较小的旁瓣。我当初调试时看到这根谱线旁边多出这么多小峰第一反应是电路噪声折腾了半天滤波电路最后才发现是时域数据的截断问题——采集的数据长度和FFT点数不一致相当于把正弦波掐头去尾在边界处产生跳变反映在频域上就是频谱泄漏。解决办法是给输入数据加窗Hamming窗或Hanning窗或者在数据采集时保证整周期采样。这个经验很值得记下来因为它说明了一个道理ZYNQ上做FFT很多问题不是出在数字逻辑上而是信号处理的边界条件没处理好。你在自己的实测里如果也看到杂散峰先别急着怀疑硬件检查一下采样是否整周期、FFT点数是否整除采样率。4. 打地鼠交互游戏PS与PL协同的典型状态机实践4.1 游戏逻辑放PL还是PS这是个架构决策打地鼠游戏的功能拆解之后其实很清晰随机产生位置、地鼠出现、命中判定、得分统计、倒计时。我的第一版把全部逻辑放PSARM在循环里既要等按键又要更新LCD还要管倒计时结果就是操作有延迟感地鼠出现的时间也不稳定玩家体验很差。第二版把地鼠状态机、命中判定和出现计时全部移到PL端用Verilog实现PS只负责在游戏开始/结束时读写几个寄存器并把PL上报的命中次数显示到屏幕上。这样分工之后PL保证毫秒级响应PS的负担也大幅下降。这个取舍背后是一条通用的ZYNQ设计原则实时性要求高的逻辑下沉PL控制类逻辑留在PS不要把所有功能都往ARM里塞。4.2 LFSR伪随机数与游戏状态机的Verilog实现随机地鼠位置用线性反馈移位寄存器LFSR实现比在PS里调rand()更符合PL端的实现习惯而且完全不占用总线。LFSR本质上就是一个带反馈的移位寄存器只要初始值不为0就能持续输出伪随机序列。地鼠状态机的核心代码结构类似这样localparam IDLE 3d0, MOLE_UP 3d1, HIT 3d2, EXPIRED 3d3; always (posedge clk or negedge rst_n) begin if (!rst_n) state IDLE; else begin case (state) IDLE: if (timer_done) state MOLE_UP; MOLE_UP: begin if (hit_flag) state HIT; else if (timer_done) state EXPIRED; end HIT: state IDLE; EXPIRED: state IDLE; default: state IDLE; endcase end end从IDLE进入MOLE_UP时通过LFSR给出地鼠位置同时启动一个计数器计数值决定地鼠停留多久。命中检测要把按键按下时刻和地鼠有效窗口对齐如果玩家在状态机还没进入MOLE_UP时就提前按下按键应该判定无效否则游戏就变成比手速而不是比反应了。4.3 按键消抖和显示联动的实测问题按键是典型的机械结构按下瞬间电平会抖动几十毫秒如果不做消抖一次按键可能被判定成多次命中分数会出现明显虚高。我在PL端用20ms左右的计数窗做消抖检测到按键电平变化后启动计数器计数器期间忽略所有电平翻转计数结束后再确认一次电平状态。消抖逻辑写好后从按键到命中再到屏幕分数更新整个过程大概几十毫秒实测没有出现丢帧或者误判。显示刷新这块有个小提醒打地鼠游戏的画面刷新不需要太高帧率60Hz已经非常流畅。不要一上来就想着上高清显示和复杂图形先把格子、地鼠、分数这三样基础元素跑通再考虑加动画效果。我在迭代过程中发现很多人卡住的地方不是画图而是PL端状态机跑着跑着和PS端显示循环不同步分数显示滞后一拍。后来在PS的中断服务函数里只做从PL寄存器读取最新分数并缓存这一个动作显示刷新由主循环负责两个节奏分开问题就消失了。4.4 难度调节与可玩性的工程实现打地鼠的好玩程度取决于节奏控制。地鼠停留时间太长玩家扫屏就是毫无压力太短又容易让人烦躁。我在PL端用两个计数器参数控制难度一个是地鼠出现间隔一个是地鼠停留时间。PS端通过AXI GPIO把难度等级写到PL寄存器里PL根据寄存器值选择不同的计数值。实际调试时我试了从200ms到1.5s的停留时间最后发现在800ms左右手感最适中——既让人有时间反应又不会闲得无聊。这种参数调优看着不起眼但恰恰是游戏类项目能否从能跑变成好玩的关键实战包里的默认参数就是这个区间。5. 烧写、调试与实录从Vivado工程到板卡的必经之路5.1 比特流生成DRC报错根因往往不在DRC生成比特流时最常见的报错是Vivado 12-1345提示DRC errorBitgen没有运行。很多人这时候会去翻DRC报告但真正的根因通常是两类一是约束文件里时钟或管脚声明的名字和设计里的端口名对不上二是某个IP核没有正确分配到所需的引脚或时钟资源。我在两个工程里都遇到过类似的情况最后都是在XDC里补充了完整的管脚位置约束和时钟频率约束之后解决的。建立约束的习惯越早越好——新建工程时就把约束文件加到工程里每次改完Block Design后检查一遍XDCDRC错误会少很多。另外建议布线和生成比特流前先跑一遍综合单独看有没有Critical Warning。很多DRC错误其实在综合阶段就有苗头只是被当成warning忽略了。5.2 ILA在线调试别到最后才想起来加ILAIntegrated Logic Analyzer是FPGA调试的利器。我见过太多人工程都快结束了上板发现信号不对才手忙脚乱地加ILA。正确的做法是在Block Design阶段就把需要观测的关键信号标记出来——FFT工程的tvalid、tready、tlast、tuser、FFT输出帧序号打地鼠工程的状态机当前状态、地鼠位置寄存器——这些信号在CIPS里勾选Mark Debug综合后就自动接入ILA无需手工修改HDL。设置触发条件时FFT工程我习惯用s_axis_tvalid上升沿作为触发采样深度256到512就够看完整一次握手过程。看AXI握手最好的方式是同时观察tvalid和tready如果tvalid拉高很久但tready一直低说明下游还没准备好是典型的反压问题。5.3 三种运行方式选哪种ZYNQ程序有三种常见运行方式各有适用场景JTAG下载调试开发阶段首选Vivado里下载比特流后在Vitis里直接运行工程缺点是掉电即失。可以在Vitis的Debug配置里勾选Reset entire system确保PS和PL同步复位。QSPI Flash固化适合只需要PL逻辑或PS程序较短的应用。在Vitis里生成BOOT.BIN包含FSBL比特流应用ELF烧进Flash上电自动运行。实测QSPI启动速度快但更新程序要重新擦写Flash迭代不太方便。SD卡启动实战包推荐的方式。把BOOT.BIN和image.ub或单独的应用ELF放到SD卡FAT32分区Zynq的BootROM会自动从SD卡加载。更新程序只需要换卡里的文件开发效率高很多。生成BOOT.BIN时有个经验如果选了包含FSBL的启动镜像务必确认FSBL工程和当前Vivado硬件导出的hdf文件匹配否则启动时会卡在FSBL阶段串口终端没有任何输出看起来像板子没上电一样。5.4 Vivado版本稳定性和工程管理的几个心得热搜里常看到Vivado安装失败、启动闪退、WinPcap报错这类问题。我个人建议跑Zynq-7000这类老平台优先选Vivado 2019.2或2020.1这两个版本对Zynq-7000支持很稳定资料也多没必要追新版本。安装时路径不要带中文和空格WinPcap那个弹窗是安装Vivado硬件服务器组件时才必须的如果只做嵌入式开发不跑仿真绕过去就行。工程管理方面我吃过亏某次在FFT工程上加了一个小功能没保存原工程直接改结果综合布线后时序崩了想回退又找不到原始版本只能重画Block Design。从那以后我每条功能分支都单独复制一份工程目录并在XDC里用注释记录改动日期。这个习惯看起来笨但在调试阶段真的能救命。双项目实战包里我也保留了多个版本的归档方便对照不同配置之间的差异。最后再分享一个调试习惯每次修改完PL逻辑重新生成比特流后先在JTAG下把所有功能测一遍确认没有回归问题再决定要不要固化。实测下来很多问题都是改了一处小逻辑结果另一个模块的时序受影响这种连锁反应只有每次都完整回归测试才能及早发现。这个习惯我在做FFT和打地鼠两个项目时都坚持下来了也是这套实战包能保持工程稳定、截图干净的原因所在。本文还有配套的精品资源点击获取