FPGA实现开源802.11 Wi-Fi基带芯片：从OFDM到DMA完整设计-北京尧图网络

简介这是一套基于软件无线电SDR的开源802.11 Wi-Fi基带芯片FPGA设计整合了Linux驱动、固件与完整协议栈兼容mac80211主要面向具有一定FPGA和无线通信基础的开发者可用于SDR原型验证、协议定制与学术研究。压缩包内共140个文件约8.7MB核心组成包括C语言底层驱动射频控制、DMA传输、收发中断、Shell脚本、Makefile构建文件、设备树dts/dtb配置、Markdown说明文档以及辅助图片目录结构清楚便于按模块查阅与编译。这套资源已有3425人学习。工程实现了802.11a/g/n、20MHz带宽、70MHz至6GHz频率范围支持站点、AP、监控等工作模式并在FPGA中实现了DCFCSMA/CA低MAC层、CSI信道状态信息、实时IQ捕获等功能同时可配置RTS/CTS持续时间、CTS-to-self、SIFS/DIFS、时隙与竞争窗口等通道访问参数。通过这份材料读者能够搭建一套完整的SDR Wi-Fi实验平台深入理解基带处理、MAC调度与Linux无线子系统的协同关系并基于源码开展二次开发和性能优化。1. 为什么要用FPGA重做一块802.11基带芯片把Wi-Fi黑匣子打开的方向和受益人群Wi-Fi大家天天在用但绝大多数人对它的印象就是一个“买来就能连”的黑匣子。真正想把这个黑匣子打开、把IEEE 802.11的基带处理抓在自己手里时常规路径几乎为零现成的网卡芯片不给你任何改动物理层的接口商业基带IP又贵又封闭。这套基于FPGA的开源802.11 Wi-Fi基带芯片设计方案实际上是把SDR软件无线电的思路搬到基带芯片设计里用FPGA实现OFDM收发信机、CSMA接入控制和DMA数据通路再用Linux上的mac80211协议栈做上层的MAC管理。它适合正在做通信方向毕业设计的学生也适合想快速搭一套教学演示或原型验证平台的从业者。方案以Zynq平台加AD9361射频前端为载体既能跑真实抓包又能逐级观察基带信号选它做课题比从空白Verilog开始要顺手得多。2. 需求分析与技术选型从OFDM链路需求到ZynqAD9361组合2.1 基带链路的核心需求OFDM解调、802.11帧处理与可观测性把802.11物理层拆开看接收通路至少包括L-STS的检测与定时同步、去循环前缀、64点FFT、信道估计、星座解映射、解交织和卷积译码发送通路则反过来先做MAC层下来的MPDU加扰再做编码、交织、星座映射、IFFT和加循环前缀。真正动手做时最容易忽略的不是单个算法会不会而是子载波编号和处理顺序的海量对齐工作。比如802.11a的FFT是64点但只有52个子载波被占用-26到-1以及1到26之间的索引映射做得不对OFDM符号就解不齐。下面的Verilog示例是FFT核例化的接口写法是接收链路里最常见的一段// 实例化64点FFT对接AXI-Stream接口 wire [31:0] fft_tdata_in; wire [31:0] fft_tdata_out; wire fft_tvalid_in; wire fft_tvalid_out; wire fft_tready_in; xfft_64 u_xfft_64 ( .aclk(axi_clk), .aresetn(axi_rstn), .s_axis_config_tdata(16h0001), // forward FFT .s_axis_config_tvalid(1b1), .s_axis_data_tdata(fft_tdata_in), .s_axis_data_tvalid(fft_tvalid_in), .s_axis_data_tready(fft_tready_in), .m_axis_data_tdata(fft_tdata_out), .m_axis_data_tvalid(fft_tvalid_out) );这个例化里有几个参数值得注意。config通道用来声明做正变换还是逆变换一般固定为正向即可data通道的tvalid必须和上游的符号边界对齐不能每来一个时钟都拉高。RA调试时如果发现FFT输出和星座图完全对不上大多数情况不是算法问题而是输入数据的位宽截断和tlast边界没处理好。我一般会在工程里保留一组旁路寄存器把FFT的输入输出分别抓一段存到DDR里这样至少能判断“信号到底有没有进到FFT里面”。2.2 为什么选择Zynq加AD9361这套组合而不是ASIC或纯FPGA如果纯用ASIC思路去设计一个802.11基带芯片时间成本和流片成本都过高而且FIRST版无法逐级调试PHY如果纯用FPGA整个MAC层和协议栈也要自己实现工作量从“做一个基带”变成了“做一整套网卡”。Zynq是ARM加FPGA的异构SoCARM侧PS可以跑完整LinuxFPGA侧PL放实时性要求高的硬件逻辑两边的数据通过AXI总线交换。这个架构刚好和802.11的分层模型对齐PHY里对时延敏感的部分放PLMAC管理帧、连接管理、网络协议栈放PS跑Linux。AD9361是低功耗射频收发器支持2.4GHz和5GHz频段带宽可配置直接输出零中频IQ信号省掉了外置的模拟正交混频器、ADC和DAC设计。openwifi这类工程常把它当作默认射频前端因为它和FPGA之间就是一组并行IQ数据线和SPI控制接口数据路径非常短。整套系统从空气到应用的路径变成天线到AD9361、IQ采样、FPGA基带、DMA传DDR、arm上Linux的mac80211驱动、最后到socket应用。这段路径里每一步都能观测正是选这套组合的核心原因。2.3 工具链与代码组织Verilog、HLS和Linux驱动各自负责哪一段基带工程里常有人纠结“到底用Verilog还是HLS”实际上二者不是竞争关系。PHY里有严格时序要求的模块比如OFDM前端、CSMA退避计时器、DMA描述符调度用Verilog/VHDL直接写更可控而一些算法验证型的DSP模块比如滤波器的系数生成、频域均衡、某些加窗逻辑用Vivado HLS从C代码生成IP更省事。HLS生成的东西被我当成“带参数的代码生成器”跑通了就固化下来不再手工改底层寄存器。Linux驱动的角色是桥接mac80211和FPGA。mac80211是内核里的无线子系统它负责生成管理帧、维护连接状态、做调度而实际的PHY发送和接收由FPGA完成。驱动需要有这么几个能力申请和管理DMA通道、把skb挂到硬件描述符上、处理中断、把收到帧从DMA区搬进skb并交给netif_receive_skb。整体分工可以用下面这张表概括环节工具/技术交付物PHY基带逻辑Verilog Xilinx IP核RTL电路、bitstreamDSP原型验证Vivado HLS封装成AXI接口的IP核射频前端控制Linux下AD9361驱动spidev/iio设备节点协议栈接入内核mac80211接口wlan0网络设备这个分工决定了后续章节的展开方式写FPGA逻辑时关注数据时序写驱动时关注描述符和中断调射频时关注校准参数三部分各自黑盒化但互相咬合。3. 总体架构设计四层模块、两条数据流与软硬件边界划分3.1 顶层模块划分射频前端、PHY基带、MAC接口与DMA一个可交付的openwifi工程在FPGA侧至少能划分出五个固定模块AD9361射频接口、接收PHY、发送PHY、CSMA/接入控制、DMA桥接。接收方向的数据路径是AD9361输出IQ数据先进入接收PHY检测到前导码后开始OFDM解调解出MPDU后送到MAC接口做地址过滤和FCS校验然后由DMA引擎搬到DDR内存驱动把这段区域构造成skb交给协议栈。发送方向反过来驱动把skb数据写入DMA描述符FPGA侧DMA拉回硬件发送PHY完成加扰、编码、调制再送回AD9361发出去。CSMA/CA被放在硬件侧实现这个点很多人一开始不理解。CSMA退避的时间粒度是微秒级Linux内核调度根本保证不了这种精度必须由FPGA里的退避计数器直接控制发送时隙。与之配套的还有RTS/CTS、ACK发送、帧间隔这些实时行为也都在硬件里完成。软件侧只负责策略比如决定要不要开启RTS阈值、重传次数上限、速率选择由驱动和mac80211协商后配置到硬件寄存器。3.2 MAC层与PHY层的边界mac80211和FPGA之间的交付物设计边界的时候我习惯先回答一个问题哪一个字节是由Linux生成的哪一个字节是由FPGA加的管理帧比如Probe Request、Association Request、Beacon由mac80211生成完整帧驱动直接把它们塞进发送队列而数据帧的FCS和PLCP头一般由FPGA在发送时补上这样驱动程序少算一段也不会出现驱动和硬件对CRC理解不一致的问题。接收方向FPGA做地址过滤和FCS校验之后把干净的MPDU交到驱动驱动读取802.11头部判断帧类型再分发给mac80211。驱动侧要对接的接口是mac80211的ops结构。一段典型的实现大概长这样static const struct ieee80211_ops openwifi_ops { .start openwifi_start, .stop openwifi_stop, .config openwifi_config, .add_interface openwifi_add_interface, .remove_interface openwifi_remove_interface, .tx openwifi_tx, .configure_filter openwifi_configure_filter, .set_channel openwifi_set_channel, };这里面的tx回调是发送路径的核心它拿到mac80211交下来的skb以后不能直接传输要先查一下硬件描述符队列是否满、是否需要做加密处理、是否需要等待CSMA空闲。如果我们把这一层实现想象成“网卡驱动里常见的ndo_start_xmit”那它多出来的一部分认知就是帧不是立即发而是交给硬件调度什么时候发由FPGA里的退避计时器说了算。3.3 数据通路与寄存器映射DMA环形队列和AXI地址空间FPGA与ARM之间的交互全部通过寄存器映射和DMA描述符完成。描述符里需要有状态位、长度、地址、控制字段形成环形队列后由驱动和硬件轮流读写头尾指针。地址空间要提前划分好避免驱动访问到无关区域还浑然不知。一个典型的映射如下地址段用途0xA000_0000DMA TX描述符区0xA000_2000DMA RX描述符区0xA000_4000MAC控制寄存器0xA000_6000PHY状态寄存器0xA000_8000IQ调试抓取窗口对应的设备树节点要告诉内核这个硬件在哪儿、中断号是什么。设备树里通常这么描述wifi_core: wifia0000000 { compatible openwifi,wifi-core; reg 0x0 0xa0000000 0x0 0x9000; interrupts 0 61 4; /* SPI中断61电平触发 */ dma-names tx, rx; };这里的reg长度不要只覆盖自己用的那一段最好把整个地址块都描述出来方便后续扩展调试窗口。在把驱动跑起来的过程中如果insmod不报错但wlan0不出现优先检查reg里的地址和FPGA侧对外导出的地址是否一致这类问题占驱动初始化失败原因的一大半。4. 关键模块实现OFDM链路、AD9361初始化和DMA驱动的落地代码4.1 OFDM发送与接收链路的实现从子载波映射到FFT例化OFDM链路里最值得展示的子载波映射逻辑在HLS里可以用一段概念代码描述出来。802.11a的64点FFT中真正承载数据的子载波是中间连续的52个边缘的直流和防护频带必须置零否则频谱会泄漏到相邻信道。用HLS写的话这段逻辑长这样#define N_FFT 64 void ofdm_tx_symbol(hls::streamap_uint32 in, hls::streamap_uint32 out) { #pragma HLS INTERFACE axis portin #pragma HLS INTERFACE axis portout #pragma HLS INLINE off ap_uint32 buf[N_FFT]; for (int i 0; i N_FFT; i) { #pragma HLS PIPELINE II1 buf[i] in.read(); } for (int i 0; i N_FFT; i) { #pragma HLS PIPELINE II1 /* * 802.11a中有效子载波位于[-26, -1]以及[1, 26] * 这里做的是标准子载波编号到FFT输入位置的映射。 */ int idx (i 26) ? (i 27) : (i 37); out.write(buf[idx]); } }这段代码的关键不在循环本身而在idx的计算。FFT输入顺序和802.11标准的子载波编号并不一致如果不做重排后面的星座映射全是乱的。HLS编译时通常会给每个循环生成流水线II1表示每一拍处理一个数据但最终能否达到这个性能还要看数组是否会被综合成BRAM导致端口冲突。真遇到II达不到1的情况可以把数组拆成两个bank或者直接在Verilog中手写状态机这是工程里常见的取舍。接收端的FFT输出同样存在符号边界问题。我一般会在FPGA里加一个symbol_sync模块用L-STS自相关的峰值来确定OFDM符号窗口的起点并且把这个起点用寄存器暴露给驱动。这样既能在Linux侧实时读到当前同步状态也能在调试时判断究竟是同步漂移还是后续解调出错。4.2 AD9361射频前端的初始化参考时钟、增益和IQ校准顺序AD9361的寄存器配置项非常多最好不要从头裸写寄存器直接用Linux下的驱动API做初始化概念调用顺序如下struct ad9361_rf_phy *phy ad9361_phy_open(); ad9361_set_frequency(phy, 2437e6); /* 2.4GHz信道6 */ ad9361_set_rx_rf_bandwidth(phy, 20e6); ad9361_set_tx_rf_bandwidth(phy, 20e6); ad9361_set_rx_gain(phy, RX_GAIN_FAST_ATTACK, 10); ad9361_set_tx_attenuation(phy, 20000); /* 0.01dB步进 */ ad9361_set_bb_clock(phy, 40e6); /* 基带采样时钟 */这里的40MHz采样时钟对应20MHz带宽的射频信道IQ两路各20Msps。需要注意的坑是AD9361上电以后必须先做DC Offset和IQ相位的校准再配置信道频率顺序反了会出现星座图整体旋转成椭圆的现象。增益策略也要提前想好。如果用自动增益建议选FAST_ATTACK模式它比手动固定增益更适合抓突发式的Wi-Fi帧如果是纯实验室环境手动增益更稳定便于定位问题。AD9361这套驱动在Linux内核和外部维护仓库里都有完整实现直接复用比自己从头调省太多事。4.3 DMA控制器的实现描述符、中断与缓存一致性DMA是连接FPGA基带和Linux网络栈的关键层次发送路径的驱动代码可以用内核DMA引擎来组织。一个基本的发送函数大约长这样static int openwifi_start_tx(struct sk_buff *skb) { struct dma_chan *chan priv-tx_chan; dma_addr_t addr dma_map_single( priv-dev, skb-data, skb-len, DMA_TO_DEVICE); if (dma_mapping_error(priv-dev, addr)) { dev_err(priv-dev, dma map failed\n); return NETDEV_TX_BUSY; } struct dma_async_tx_descriptor *desc dmaengine_prep_slave_single( chan, addr, skb-len, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT); desc-callback openwifi_tx_done; desc-callback_param skb; dmaengine_submit(desc); dma_async_issue_pending(chan); return NETDEV_TX_OK; }注意dma_map_single和dma_unmap_single必须严格配对。很多工程第一次跑起来短包没问题打流十分钟后开始乱序就是因为发送完成回调里没有释放DMA映射缓存一致性被破坏。另一个容易被忽略的字段是长度必须用skb-len而不是MTU。MTU只是IP层的限制802.11帧加了头部之后长度会超过MTU用错长度会把描述符里的数据截断。接收路径一般用dma_alloc_coherent申请一块固定的环形缓冲区FPGA直接把接收到的帧写到这个地址驱动通过描述符里的状态位判断是否有新数据。这块缓冲区不需要担心cache一致性问题因为coherent映射已经保证了CPU和DMA看到的是同一份数据。4.4 完整编译下载流程从Vivado批处理到Linux模块加载整个工程编译流程最好做成脚本避免某一步漏了导致后面全部重来。命令行大致是这样的# 1. FPGA工程编译board参数指定目标板 vivado -mode batch -source scripts/build_openwifi.tcl -tclargs board_zc706 # 2. 生成设备树确认wifi节点地址与FPGA侧一致 dtc -I dts -O dtb -o wifi.dtb wifi.dts # 3. 编译内核驱动 cd openwifi/driver make KERNELDIR/lib/modules/$(uname -r)/build # 4. 加载驱动并验证设备 insmod openwifi.ko ip link set wlan0 up iw dev wlan0 scan几个步骤的失败现象各不相同。bitstream下载后系统能启动但wlan0不存在基本是驱动和设备树版本不匹配insmod报地址错误大概率是设备树reg和Vivado地址不一致wlan0出现但scan不到AP才轮到射频前端和天线的问题。按这个顺序排查能节省大量时间。5. 避坑排查通信基带FPGA项目里最常翻车的五个环节5.1 AD9361收不到数据时钟和校准顺序问题现象上电后能从AD9361读到IQ数值但wlan0永远收不到任何Beacon。原因FPGA给AD9361的参考时钟分频不成整数比导致基带采样率和802.11符号率对不上前导码检测永远失败。解决先确认板级晶振频率在驱动里打印实际配置的基带采样时钟把采样率固定为20MHz的整数倍再检查初始化流程里是否在配置信道前完成IQ校准。这类问题我一般用频谱仪看AD9361输出端的IQ信号如果看到明显的杂散边带基本都是时钟问题。5.2 DMA长包传输错乱缓存映射和描述符长度写错现象短包完全正常长包一半对一半错错误字节位置每次都不一样。原因DMA描述符里的长度字段写成了MTU或者完成回调里没有释放DMA映射缓存一致性被破坏。解决发送路径使用skb-len作为长度配合dma_map_single后严格在回调里配对dma_unmap_single接收路径用dma_alloc_coherent分配缓冲区避免手动加一致性屏障。跑长包前先用固定长度的循环发包脚本压一遍比如发1000个1500字节帧看统计是否稳定。5.3 时序收敛不过OFDM数据通路里组合逻辑太长现象综合能过布局布线一堆setup violation最后只能降频运行。原因OFDM数据通路在符号级做了大量组合逻辑从子载波重排到星座映射之间没有插入流水寄存器。解决在FFT和星座映射之间、均衡器之后分别加流水寄存器把I/Q两路拆开并行计算综合设置里开启retiming。代码写好之后先把约束写完整再综合时钟周期10ns的话input/output delay按30%余量给别最后时刻再补约束那时候能改的余地很小。5.4 抓包能通但CRC全错OFDM符号边界偏移现象能接入AP但打流几分钟就断抓包文件里出现大量CRC Error。原因帧同步不准确OFDM符号边界偏移了几个采样点解调出的比特序列整体错位CRC必然失败。解决在接收链路保留L-STS自相关峰值记录用FPGA里的符号计数器把FFT窗口起点锁住不让它随噪声漂移。调试时把FFT输入和输出同时抓到ILA窗口里检查符号边界是否有跳变。这个问题在现场答辩中很容易被错误归结为“射频信号不好”。5.5 内核死锁DMA中断和发送路径争用锁现象多线程打流时内核死锁控制台完全卡住只能重启单板。原因DMA完成中断里做了sleep操作或者拿了一把和发送路径相同的spinlock造成锁的持有者在等待另一个中断亮起。解决中断下半部用workqueue或tasklet处理中断里只做描述符回收和状态更新不在原子上下文调用dma_unmap_single共享锁用spin_lock_irqsave初始化确保中断上下文不会和进程上下文互相等待。6. 验收与答辩用抓包和波形证据把设计链路讲清楚6.1 验收指标与测试方法验收不要只停留在“能连上”这一条建议从上到下分三层。第一层是物理层验收确认OFDM调制解调正确星座图能清晰分辨QPSK和16QAM频偏在允许范围内第二层是DMA与驱动验收确认小包长包连续跑一小时无丢帧内存稳定不增长第三层才是协议验收用两个板子互连做Association、抓包、iperf3打流。常用指标可以整理成一张表验收项指标方法OFDM解调星座图清晰无旋转导出IQ数据绘制星座图持续性千字节级报文连续传输无CRC错iperf3 UDP 10分钟MAC接入正常关联并交换管理帧iw命令 tcpdump有效吞吐接近物理速率的一半以上iperf3 TCP测试抗干扰多节点同信道同时发送不碰撞三块板同频广播统计验收的顺序比指标本身更重要。先做回环自测再收发包再上双板联调最后才做多节点。每过一步就等于把问题范围缩小一层现场出问题时能很快定位到具体模块。6.2 演示与答辩技巧一条主链路加一套波形证据答辩时最忌讳只在PPT上放架构图。我习惯现场演示两条东西一条是抓包窗口用tcpdump或者wireshark实时抓到Beacon和Association请求另一条是ILA抓取的基带波形展示某个OFDM符号的FFT输入或星座映射结果。后者最关键它能证明你“真的在做基带设计”而不是拿现成网卡改个名字。提前把这些波形保存成截图现场万一环境干扰抓不到包也有证据兜底。现场出问题不要慌按链路顺序排查先读AD9361寄存器确认射频在线再看IQ原始波形有没有有效信号然后看FFT输出星座图是否收敛接着查DMA描述符状态最后看Linux收包计数。这个顺序本身就是答辩中最好的回答框架。从那以后我每次做通信类FPGA项目都会强制走一遍“寄存器到IQ波形再到抓包”的完整链路再进场这套流程能挡掉大半现场问题希望帮到你。本文还有配套的精品资源点击获取

FPGA实现开源802.11 Wi-Fi基带芯片：从OFDM到DMA完整设计

相关推荐

Elasticsearch召回+Spark重排：搜索与推荐一体化系统实战拆解

恶意代码动态行为分析实战：环境隔离与C2通信识别

open-code-review：基于CLI与LLM Agent的开放代码评审新范式

更多资讯

永磁同步电机无感控制：高频方波注入与滑模观测器接力覆盖全速域

KV Cache太吃显存？Replay机制：重算一小段，释放90%显存并提升并发

重算反而省算力：长上下文下KV Cache与局部重计算的博弈

接口联调必看：拆解动态加密参数jt的二级算法与断点调试

CentOS7 Docker安装配置实操：构筑轻量CI/CD底座

Physical AI 模型低门槛部署指南：从硬件准备到微调训练

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？