1. 从问题出发为什么IFFT实时计算会“丢数据”最近在折腾一个宽带数字接收机的FPGA实现核心环节之一就是多相滤波。在Matlab上仿真跑通后信心满满地准备在Vivado里用Xilinx的FFT IP核来实现最后的IFFT变换。想法很简单ADC数据源源不断进来IP核配置成IFFT模式数据灌进去结果流出来齐活。但真干起来才发现现实很骨感。最让我头疼的就是那个看起来人畜无害的s_axis_data_tready信号。我一开始的设想是“直连”ADC数据通过AXI-Stream接口tvalid一拉高就直接怼给FFT IP核的数据输入端口。理论上只要IP核的tready也是高的数据就能被接收。但仿真波形一出来我就傻眼了。在数据开始传输后的头几个时钟周期IP核的tready信号竟然会毫无征兆地拉低那么一下就像下图里画的那样数据流正欢快地跑着突然“门”关了一下几个数据包就被挡在外面了。更要命的是这个现象跟IP核的配置完成与否似乎还没关系它就这么任性。这问题可大可小。在AXI-Stream协议里数据传输成功的黄金法则就是tvalid和tready在同一个时钟上升沿同时为高。tready这一拉低意味着当前时钟周期IP核“拒绝服务”如果发送方我的ADC数据源还在持续发送那这个周期的数据就必然丢失。对于IFFT这种需要完整、连续数据帧的运算来说丢一个点整个一帧32点的计算结果就全错了后续的滤波、解调全都会乱套。这根本不是精度误差而是功能性的错误。我最初怀疑是IP核复位没处理好。是不是配置通道还没就绪数据通道就提前动作了于是我给IP核加上了细致的复位控制逻辑确保配置完成后再开启数据流。然而仿真结果啪啪打脸tready那个调皮的下拉脉冲依然存在。看来这不是一个简单的时序或初始化问题而是Xilinx FFT IP核在流水线实时Pipelined Streaming模式下的一种内部行为特性。它可能在处理帧起始、内部缓冲区切换或某些特定阶段时需要短暂地暂停数据流入。对于这种“非受控”的、由IP核内部状态决定的tready信号我们外部逻辑不能假设它永远为高必须设计一种机制来“适配”它确保数据流在面对短暂背压Backpressure时也能安然无恙。这就是整个优化工程的起点我们得在数据源和FFT IP核之间搭建一个“缓冲池”当IP核说“稍等”的时候数据能有地方暂存等它说“请进”的时候再无缝衔接地送进去。这个“缓冲池”就是FIFO但用什么样的FIFO怎么控制它的读写里面大有学问直接决定了整个流水线的效率和可靠性。2. 核心武器FIFO的选型与“零延迟”读控制既然决定用FIFO做缓冲第一个问题就是用标准同步FIFO还是用First Word Fall ThroughFWFT模式的FIFO这可不是随便选选它直接关系到你整个流水线的延迟和控制的复杂度。我最初试了标准的同步FIFO。它的读操作是这样的你先拉高rd_en信号等到下一个时钟周期数据才会出现在dout端口上。这就引入了一个固定的、1个时钟周期的读延迟。在我们的场景里当FFT IP核的tready信号突然变高表示“我现在可以吃了”的时候如果我们用标准FIFO流程是这样的检测到tready1- 拉高FIFO的rd_en- 等待一个周期 - 数据出现在dout- 再将数据赋予tdata并拉高tvalid给IP核。且不说这多出来的一个周期延迟对实时性的影响最关键的是IP核的tready可能只高一个周期等你折腾完这一个周期的延迟IP核的tready可能又低了导致你虽然读了FIFO但数据并没成功送进IP核而FIFO里的数据已经被消耗掉了这就造成了实质的数据丢失。这方案显然不行。所以FWFT FIFO就成了不二之选。FWFT模式也叫“预取”模式它的精髓在于当FIFO非空时第一个被写入的数据会立即出现在输出端口dout上而不需要等待rd_en信号。rd_en信号的作用变成了“确认消费”当rd_en拉高时它相当于确认了当前输出端口上的数据已经被取走FIFO内部指针更新下一个数据如果存在会立即被推到输出端口。这意味着从数据可用的角度看读延迟是0。这对解决我们的同步问题简直是雪中送炭。因为数据时刻准备在输出端口当IP核的tready信号变高的那个瞬间我们不需要任何等待可以立刻将FIFO输出端口的数据和tvalid信号一起送给IP核。只要tready和tvalid在那个时钟沿同时为高传输就成功了。紧接着我们在同一个周期拉高rd_en告诉FIFO“刚才端口上那个数据我送走了请更新下一个。” 这样整个响应链路没有任何多余的周期延迟完美匹配了IP核tready信号可能短暂有效的特性。光有FWFT FIFO还不够读控制逻辑的设计是另一个关键。这里必须使用组合逻辑来生成rd_en信号。为什么因为我们要实现“零延迟”响应。看下面这段代码这就是核心assign w_fifo_rd_en s_axis_data_tready !w_fifo_empty; assign s_axis_data_tvalid w_fifo_rd_en; // 或者直接 s_axis_data_tready !w_fifo_empty第一行FIFO的读使能w_fifo_rd_en直接等于IP核的tready信号和FIFO非空信号的逻辑与。这是一个纯组合逻辑只要条件满足rd_en在同一时钟周期内立刻变高。第二行送给IP核的tvalid信号可以直接用w_fifo_rd_en来驱动或者也用同样的组合逻辑产生。这保证了tvalid和tready的严格同步——它们是在完全相同的逻辑条件下在同一时刻产生的。当IP核准备好 (tready1) 且FIFO里有数据 (empty0) 时tvalid和rd_en同时为高。在同一个时钟上升沿三件事原子性地发生1) IP核采样到有效数据2) FIFO知道数据被取走更新内部状态3) 下一个数据如果有被预取到输出端口。如果这里用了时序逻辑比如把tready和!empty打一拍再产生rd_en那就又引入了延迟很可能就抓不住IP核那个短暂的准备窗口了。所以记住这个原则在需要与外部握手信号严格同步的快速路径上组合逻辑往往是更好的选择。3. 实战配置从Vivado IP核到仿真验证理论说清楚了我们来看看在Vivado里具体怎么操作。首先FFT IP核的配置是基础。在IP Catalog里找到“Fast Fourier Transform”双击打开配置界面。核心参数配置转换长度Transform Length 根据你的需求来比如我做的这个多相滤波是32通道所以设为32。这个点数也决定了后续数据帧的边界。架构选择Architecture Selection 这里就是实现流水线的关键一定要选择“Pipelined Streaming I/O”。这个架构允许输入数据连续流动输出结果也连续产生中间是流水线处理的吞吐量可以做到每时钟周期一个样本非常适合我们的实时流处理场景。千万别选成“Radix-2 Burst I/O”之类的那种是整帧进、整帧出延迟大无法处理连续流。数据格式Data Format 根据你的ADC数据是定点数还是浮点数来选择。我用的ADC是12位输出所以选择定点数Fixed Point。相位因子宽度Phase Factor Width 这个和精度有关一般可以设置得和输入数据位宽相同或略大比如12到18位。精度越高消耗资源越多。IFFT设置 在“Implementation”标签页下有个“Run Time Configuration”选项。这里不要勾选“Forward Transform”正变换我们的目标就是IFFT。更常见的做法是在设计里通过IP核的配置通道s_axis_config_tdata来动态控制是FFT还是IFFT。配置通道的数据最低位为0是FFT为1是IFFT。为了固定为IFFT模式我们可以像示例代码里那样在初始化时就将s_axis_config_tdata赋值为1并拉高s_axis_config_tvalid直到握手成功。配置好IP核后就是搭建我们的缓冲层。在Block Design里添加一个FIFO Generator IP核。FIFO Generator关键设置接口类型 选择“Native”这是Xilinx FPGA内部常用的FIFO接口。读写位宽和深度 位宽匹配你的输入数据例如12位。深度需要仔细考量太浅容易在IP核背压时间长时溢出太深浪费资源。一个实用的方法是深度设为FFT点数的2-4倍比如32点IFFT用64或128深度的FIFO提供足够的弹性缓冲。最重要的选项 在“FIFO Implementation”选项中找到“Read Mode”务必选择“First Word Fall Through”。这就是我们之前讨论的FWFT模式。握手信号 确保使能full和empty信号我们的控制逻辑需要它们。连接好模块后就是编写我们之前提到的那个核心的组合逻辑控制代码。把ADC数据源连接到FIFO的din写使能wr_en接ADC的valid信号。FIFO的dout连接到FFT IP核的s_axis_data_tdata。然后用组合逻辑把IP核的s_axis_data_tready和FIFO的empty信号“与”起来分别驱动FIFO的rd_en和IP核的s_axis_data_tvalid。上板测试前仿真验证必不可少。在仿真中你可以清晰地看到当ADC数据持续写入FIFO时full信号一直为低。当FFT IP核的tready出现下拉脉冲时FIFO的wr_en可能还在继续因为数据源不停但rd_en会跟着tready变低暂停读取。此时如果FIFO非空数据会停留在dout端口如果FIFO是空的tvalid也会变低。一旦tready恢复为高且FIFO非空rd_en和tvalid立刻同时变高数据在同一个时钟沿被IP核成功采样。FIFO的输出端口随即更新为下一个数据。 整个过程中没有任何数据丢失实现了真正的“弹性缓冲”和“无缝同步”。4. 结果分析与那些容易踩的“坑”流水线调通后我们来验证IFFT的计算结果。我向系统连续发送了多帧数据其中第一帧是简单的递增序列1,2,3,...,32。在Vivado的仿真窗口里抓取m_axis_data_tdata信号它包含了实部和虚部。需要特别注意IP核输出的数据顺序和格式。通常输出数据是交织的比如[虚部高位虚部低位实部高位实部低位]具体顺序要看IP核文档。在我的设置里低位部分是实部高位部分是虚部。把仿真得到的定点数导出转换成有符号十进制数。这时候第一个坑来了Xilinx FFT/IFFT IP核的输出默认是没有除以点数N的也就是说IP核完成的是 N * IFFT(x) 的运算。因此为了得到正确的IFFT结果你必须将输出数据右移 log2(N) 位对于32点就是右移5位相当于除以32。在硬件里除法器开销大所以通常用定点数移位来实现。但这里第二个坑接踵而至有符号数的移位。在Verilog里直接用运算符进行右移对于有符号数signed类型是算术移位保持符号位对于无符号数是逻辑移位补0。你必须确保你的数据被声明为signed类型或者使用算术右移运算符否则符号位会被错误处理导致结果完全不对。我的做法是在代码里这样处理wire signed [17:0] raw_re m_axis_data_tdata[17:0]; wire signed [17:0] raw_im m_axis_data_tdata[41:24]; wire signed [17:0] result_re raw_re 5; // 算术右移5位等价除以32 wire signed [17:0] result_im raw_im 5;处理完移位后我将得到的结果与Matlab计算的ifft(1:32)结果乘以32后的值进行对比。如果我们的流水线同步和计算都没问题两者应该基本一致允许极小的定点量化误差。然而第三个坑在我尝试让设计更健壮时出现了复位信号的处理。我最初为了让系统有确定的初始状态为FFT IP核添加了复位信号aresetn。仿真发现每次复位释放后第一次IFFT运算结果的虚部竟然和Matlab结果的虚部是相反数实部是对的唯独虚部符号反了。反复检查数据格式、移位操作、甚至怀疑Matlab的ifft函数默认归一化方式都没问题。最后将FFT IP核的复位引脚aresetn断开或者始终保持为高不复位这个问题就消失了。我查了一些论坛和文档推测这可能是Xilinx FFT IP核在特定版本或配置下复位序列与内部相位因子初始化存在的一个小bug或者未明确说明的行为。在实时流水线模式下如果不需要在运行中动态复位IP核最稳妥的办法就是不要使用这个复位信号而是通过控制数据流的启停来实现重置。如果确实需要全局复位可能需要更复杂的配置序列重新初始化IP核这超出了本文的范畴但值得大家注意。最后来看一下优化前后的对比。没有流水线缓冲时数据流完全受制于IP核内部不稳定的tready丢失率可能高达百分之几对于高精度信号处理是完全不可接受的。加入FWFT FIFO和组合逻辑控制后数据丢失率降为0实现了无损传输。在资源消耗上增加了一个小型FIFO通常只消耗几百个LUT和几个Block RAM相对于FFT IP核本身消耗的DSP和BRAM资源来说开销几乎可以忽略。在时序上组合逻辑路径tready-rd_en/tvalid非常短不会成为系统时序瓶颈反而因为解决了同步问题使得整个系统可以在更高的主频下稳定运行。这套方法不仅适用于IFFT任何需要处理AXI-Stream背压、实现生产者与消费者速度匹配的场合都可以借鉴这个“FWFT FIFO 组合逻辑握手”的黄金组合。