★ FEATURED ARTICLE 做信号处理这块凡是跟频域打过交道的朋友应该都绕不开 FFT 和 IFFT 这对“孪生兄弟”。很多项目里明明只集成了 FFT 模块却突然发现需求里还需要做逆变换这时候要是能想办法用现成的 FFT 模块把 IFFT 也算了那真是省了不少事。我最早碰到这个需求是在做某套通信系统的时候算法那边丢过来一个频域均衡的方案接收端要先做 FFT 进频域处理再把结果 IFFT 回时域。当时工程里用的是某常用 FPGA 平台自带的 FFT IP 核正变换一路畅通到了反变换这里我下意识以为要换个 IP或者自己用 CORDIC 搭一个后来翻了手册才发现现成 FFT 模块本身就支持通过配置信号直接做 IFFT只是很多人没用过这个功能。顺着这个思路我把“利用 FFT 模块求 IFFT”这件事完整梳理了一遍也踩过几个不算深但足够烦人的坑今天一次性写清楚希望能给要走这条路的兄弟省点时间。1. 先搞清楚为什么 FFT 模块能算 IFFT1.1 从数学定义看 FFT 与 IFFT 的关系首先得明确一个基本概念FFT 和 IFFT 在数学上并不是两个毫无关联的算法离散傅里叶变换和它的逆变换之间有非常清晰的代数关系。DFT 正变换的公式是X(k) Σ x(n) · e^(-j2πkn/N)IDFT 的公式是x(n) (1/N) · Σ X(k) · e^(j2πkn/N)对比这两个式子可以发现的第一个规律是如果只看求和部分IDFT 等于把正变换公式里的指数符号取反其他结构完全一样。也就是说只要在进入 FFT 模块之前对输入数据做一个特殊的预处理让 FFT 核计算出来的结果正好等于 IFFT 的结果这个方案就成立。更直白一点讲FFT 模块本身是一个“计算离散傅里叶变换”的硬件加速器它内部虽然有蝶形运算单元、旋转因子查找表这些固定结构但通过改变输入数据的符号和排列方式就能让它的输出对应到 IDFT 的数学定义。1.2 两条实现路线直接配置信号 vs 共轭法实际工程里有两套用 FFT 模块求 IFFT 的做法。第一套是依赖芯片厂商提供的 FFT IP 核自带功能。大部分主流 FPGA 的 FFT IP 核都会提供一个配置端口比如某些 IP 里叫fwd_inv有些叫mode把这个信号拉高一拍或者配置成指定值IP 核内部就会自动切换计算模式用同一套蝶形运算单元去执行反变换而且输出还会自动乘上 1/N 这个归一化系数。这种方式最省事完全不需要自己动手改数据唯一的要求是 IP 核配置时要开放这个动态配置接口不能把模式固定死成 FFT。第二套是纯数学技巧也就是常说的“共轭法”。核心公式不复杂IFFT 的结果可以表示为x(n) (1/N) · conj( FFT( conj( X(k) ) ) )拆开来讲就是三步先把频域数据取共轭送进 FFT 模块做一次正变换再把输出取共轭最后每个点除以 N。这个方法的好处是哪怕你手里的 FFT 模块根本没有任何可配置模式或者说你用的是一段纯软核代码、第三方闭源 IP也能靠着最基础的 FFT 正变换功能把 IFFT 算出来。两条路线各有适用场景。第一条路线适合 FPGA 工程里直接用厂商 IP 的情况零额外开销第二条路线适合那些 FFT 模块被封装得很死、只留了输入输出接口的项目或者你在软件上写 C 代码 / Python 仿真时想快速验证算法。如果是软件代码共轭法几乎就是标准答案因为 FFT 和 IFFT 共用一个函数代码量能省一半。2. 硬件平台实操用可配置 FFT IP 核实现 IFFT2.1 工程环境与模块选型我在实际项目里用的平台是某主流 FPGA 厂家提供的开发环境芯片型号是某款中端系列的器件资源不算特别富裕所以功耗、逻辑资源都得精打细算。工程里例化的 FFT IP 核选择了 1024 点的可配置变换长度数据位宽选了 16bit因为当时的信号经过 ADC 采集后量化成了 16bit 定点数直接喂给 FFT 模块不用做额外位数转换。配置界面里有一个比较容易被忽略的选项就是“Transform Length”可以设置成可动态配置下拉框里通常有“Fixed”和“Programmable”两种。如果只是用固定 1024 点选 Fixed 就行但如果希望同一个模块既能做 256 点又能做 1024 点就必须选 Programmable同时 IP 核会多出一个配置端口用于动态修改点数。我这次因为需求明确是固定 1024 点就选了 Fixed省了几个配置引脚。另一个关键选项是“Architecture Choice”常见的有 Pipelined Streaming、Radix-2 Burst I/O 等。既然要在一个连续数据流里做实时处理必须在时域数据一路进来的同时把频域结果一路吐出去那就直接选 Pipelined Streaming。虽然它消耗的 DSP、BRAM 资源比其他结构多不少但换来了最高的数据吞吐率不会阻塞后级模块处理。2.2 fwd_inv 切换信号的使用细节IP 核例化完成之后正常会看到一组和模式控制相关的接口最常见的是fwd_inv或者mode。以fwd_inv为例这个信号在高电平时表示执行 FFT低电平时表示执行 IFFT。需要特别强调的是它和普通的配置信号不同不是随便拉高拉低就立刻生效而是在数据流的帧边界处才会被采样。我第一次用的时候犯了个错以为这个信号和s_axis_config_tvalid一样可以随时配置。结果在数据流传输中途把fwd_inv从高拉低发现接下来的输出并不是预期结果反而把当前帧数据算了半截正变换半截反变换。查了手册才知道IP 核内部是在检测到一帧数据开始传输的瞬间也就是s_axis_data_tvalid拉高并且s_axis_data_tready也处于高电平的那个时钟沿去锁存fwd_inv的电平状态之后的整帧数据都按这个状态处理。正确做法是若要切换模式必须在上一帧数据传输完成之后、下一帧数据开始之前提前把fwd_inv设置好。在实际工程里我的做法是把模式切换和帧同步信号绑定上游模块发来一个“开始新帧”的脉冲我就用这个脉冲去同步更新fwd_inv保证配置永远不会迟到。2.3 缩放因子配置与定点数溢出风险定点 FFT 最让人头疼的问题之一就是动态范围。1024 点的 FFT如果输入信号是满幅度的正弦波中间蝶形运算的结果会远超单点的幅度如果不做处理很容易溢出。常见的 FFT IP 核会在内部提供缩放配置比如有三种模式缩放因子由用户静态配置、由模块自动计算、或者完全关闭缩放。我在第一次设计时图省事选了“无缩放”结果在仿真里一切正常一到板级测试输入信号刚接近满幅时就出现明显的频谱毛刺通过调试抓数据发现中间级蝶形运算的结果发生了溢出虽然 IP 核内部对溢出做了饱和处理但饱和带来的非线性畸变已经影响到频谱精度。后来改成“自动缩放”模式IP 核会在每一级蝶形运算后自动右移一位保证数据不溢出。但引入自动缩放之后又出现了一个新问题输出结果的幅度被压缩了原本应该是单位幅度的正弦波频谱实际算出来只有满幅度的几分之一后级做阈值判断时要重新标定。如果项目对精度要求高我建议不要用自动缩放而是自己根据输入信号的统计特性算好缩放因子。具体做法是预先在仿真里灌入最大幅度的输入波形观察 FFT 各中间级输出的最大绝对值如果某一级最大绝对值接近位宽上限就右移一位然后记录总共右移了多少位在最后的输出端再根据这个偏移量做左移补偿。这个做法虽然多花一点时间但能换来完全可预测的动态范围和精度。在这个方案里如果做 IFFT还要额外注意一点IFFT 模内本身还有 1/N 的归一化系数有些 IP 会在反变换模式下自动把 1/N 乘进去但有些需要你手动处理。我碰到的情况是IP 在 FFT 模式下不会对输出做任何除法而在 IFFT 模式下会根据配置决定要不要除以 N。这就意味着同一套后端处理逻辑要对两种模式分别设置不同的增益补偿值如果没注意到这个差异正变换和反变换的绝对幅度会差 1024 倍光靠肉眼去判断波形很容易误以为出了 bug。3. 纯逻辑实现路径用 FFT 正变换模块推算 IFFT3.1 共轭法的完整流程拆解如果你的环境里确实拿不到带模式切换的 FFT 模块或者你只是在做纯 C 模型验证那就该用共轭法了。前面给过公式这里把流程拆到每一步并且解释每一步到底在做什么。假设我们有一段频域数据 X(k)k 从 0 到 N-1需要把它转换回时域序列 x(n)。共轭法流程如下第一步对 X(k) 的每一个元素取共轭也就是把虚部的符号翻转。在硬件里复数通常用两个并行总线表示一个实部一个虚部取共轭只需要把虚部总线接入取反逻辑即可。第二步把共轭后的结果送入 FFT 模块按正变换模式执行一次快速傅里叶变换。这一步得到的结果如果按数学推导正好是 N 倍的 x(n) 的共轭。第三步对 FFT 输出结果再取一次共轭。取了之后得到的就是 N 倍的 x(n)。第四步也是很多初学者会忘的一步把所有输出点除以 N。这个除法在软件里很简单但在硬件里你要么用一个除法器要么用移位近似处理前提是 N 是 2 的幂。值得说明的是如果 FFT 模块在正变换模式下已经内置了除以 N 的功能这种情况用在声学分析软件里比较多因为工程上经常希望 FFT 输出直接是幅度谱那第四步的分母取值要相应修改你得清楚你的工具到底在输出端做了什么不能被模块默认行为“代劳”之后又重复除一次。3.2 硬件逻辑里的共轭实现细节在 FPGA 上实现共轭法比想象中要省资源因为核心操作只有一个虚部取反。复数数据流如果采用实部和虚部交替传输的话共轭操作需要在总线侧做一个字节级选通转换把虚部对应的字节段送进取反器实部对应的字节段直通。但这里有一个很隐蔽的问题就是数据有符号数还是无符号数。FFT IP 核的输入输出通常约定为有符号定点数两补码格式。取共轭时对负数虚部取反要特别小心比如虚部值是16h8000这在两补码里代表 -32768取反之后会溢出变成 32768但 16bit 有符号数的最大值是 32767所以这里会发生回绕。实际处理时最好把数据位宽放宽一位再做取反或者做饱和处理否则共轭法算出来的结果在边界点可能出现一个异常的跳动点。除此之外时序上也要注意共轭操作的位置。如果 FFT 模块要求输入数据是连续流那么取共轭必须放在 FFT 之前并且要保证取共轭逻辑不引入额外的反压。如果共轭处理导致数据延迟一拍而 FFT 模块的 tready 信号并没有等待这一拍就有可能出现数据错位。稳妥的做法是在共轭处理模块内部也做一套简单的握手逻辑把 tready 信号向前级传递。3.3 软件仿真段用 Python 验证共轭法在写 RTL 之前我习惯先用 Python 快速验证一遍算法这样能对“共轭法是否适用于这个场景”有个直观判断。简单写一段验证代码import numpy as np N 8 x np.array([1, 2, 3, 4, 4, 3, 2, 1], dtypecomplex) # 正变换 X np.fft.fft(x) # 共轭法求 IFFT y np.conj(np.fft.fft(np.conj(X))) # 对比 x_recon y / N print(np.max(np.abs(x_recon - x)))这段代码跑完理论上误差在浮点精度范围内接近 0。把 N 改成 1024用随机复数序列测试结果也一致。有了这个仿真保证再往 RTL 上搬心里就有底了起码数学逻辑不会错。如果遇到 FFT 库函数内部自带归一化的情况比如某些库函数执行np.fft.ifft时会自动除以 N但当你用np.fft.fft去算共轭法时并没有自动归一化因此要在最后手动除 N。这一点跟硬件里遇到的情况是一样的所以无论在软件还是硬件里我都建议先写一个小型测试向量别怕麻烦确认模块的输出约定之后再大规模接入系统。4. 工程实战中的关键问题与调试记录4.1 帧对齐与 tlast 信号引起的“频谱漂移”把 FFT 模块接入到真实数据流中最常出现的问题不是算法本身而是帧边界没对齐。记得第一次做板级调试时FFT 输出数据的第一个点总不是直流分量频谱图里所有的谱线位置都偏移了一个点。排查了很久最后定位到问题是输入端的tlast信号没有在最合适的位置拉高。FFT IP 核通常要求在一帧数据的最后一个有效数据上拉高tlast表示这帧结束了。如果tlast早了一拍或者晚了一拍IP 核内部会认为帧长不对有些实现会把数据当成一帧错位的序列来处理。解决方法是把上游数据源和 FFT 模块之间的 AXI 握手逻辑仔细核对尤其注意tvalid与tlast的配合关系。如果数据是连续不间隔的还得注意在帧与帧之间插入一个空闲周期让 FFT 模块有时间输出最后一级蝶形运算的结果否则下一帧的数据就会覆盖上一帧还没输出完的数据。因为这个问题我在工程里加了一个简单的帧封装状态机专门负责把上游来的块数据封装成符合 FFT 输入要求的 AXI-S 流。封装状态机内部维护一个计数器当计数到 N-1 时拉高tlast同时至少暂停一拍再开始下一帧。这样处理之后频谱漂移问题彻底消失。4.2 共轭法路径的相位翻转坑用共轭法做 IFFT 时有一个容易被忽略的点如果输入数据本身就是共轭对称序列也就是说实部是偶对称、虚部是奇对称那么共轭法得到的结果会退化出一个相位翻转。我在做某种单边带信号恢复时碰到过这个问题当时输出的时间序列跟预期正好是共轭关系后来往回查发现就是共轭法路径在边界条件上处理错了。具体来讲标准的共轭法公式要求对整帧数据统一处理但有时在代码里为了方便只对有效子载波做了共轭直流和边缘载波没有处理导致整体结果多了一个共轭操作。这个问题在纯数学仿真里很难被发现因为仿真时你用的是完整数组但到了硬件数据被分成了一个个 Block RAM 存储的帧很容易出现“处理了大部分点漏了几个特殊点”的情况。解决方法是写一个自检模块在测试模式下向 FFT 模块灌入一个已知的频域序列比如单位冲激然后观察 IFFT 输出是否符合预期。如果输出相位一致、幅度一致再切换成随机序列做全量比对确保特殊点都处理到位。这个自检模块虽然消耗一点逻辑资源但能大幅缩短板级调试时间。4.3 定点精度与溢出的进一步处理前面提过缩放因子的问题但定点精度对 IFFT 的影响比 FFT 更敏感。因为 IFFT 本质上是一个求和过程如果某一级的舍入误差被累计到下一级最终输出可能在最低几位不断跳动反映在波形上就是一种轻微的“噪声地板”。我在做高精度音频处理时遇到过这个情况输出信噪比比预期的低了很多。排查到最后发现问题出在 FFT 模块内部的旋转因子查找表上IP 默认把旋转因子量化到了 16bit但当数据位宽是 18bit 时旋转因子的量化误差就变成了主要噪声源。后来把 IP 配置里的相位因子位宽调高到 20bit噪声立刻降到了可接受范围。如果你用的是固定的 FFT IP没有开放旋转因子位宽配置那就只能从外部做补偿了。一种可行的替代办法是把输入信号做一些预处理比如幅度整体衰减让中间级蝶形运算的动态范围余量更大从而降低量化误差的相对比例。虽然这治标不治本但很多场景下够用。4.4 常见问题与排查速查表根据我自己的踩坑经历把和“利用 FFT 模块求 IFFT”相关的问题整理成了一张速查表方便大家遇到问题的时候快速对照。现象可能原因排查思路与解决办法IFFT 输出幅度远小于预期FFT 模块在 IFFT 模式下没有乘以 1/N或后端增益补偿不对确认 IP 的归一化配置必要时在输出端手动补偿输出波形相位翻转共轭法处理时漏了特殊点或 fwd_inv 切换时机错误用单位冲激做自检检查全频点共轭是否完整频谱图整体偏移一个点帧对齐错误tlast 位置不对核对 AXI-S 帧封装在帧边界插入空闲周期动态范围小出现削波缩放因子配置不合理或者 IP 内部溢出改为手动缩放预先仿真确定各级移位量低信噪比输出噪声偏大旋转因子位宽不足或数据位宽不足增大 IP 的相位因子位宽调整输入幅度让动态范围留余量数据流中第一帧正常后续异常fwd_inv 切换信号没有在帧边界同步用帧同步脉冲配合模式切换避免中途切换这张表其实也印证了一件事真正让“FFT 模块求 IFFT”变得好用的是对数据格式、时序约定和数值精度的掌控而不只是选择哪条实现路线。5. 两条路线的对比与选型建议为了更直观地帮大家做决策我把两种方案放在一起对比一下。对比项动态配置 IFFT 模式共轭法硬件改动量小只需拉一个模式信号中需要额外加取反逻辑数学清晰度高内部自动处理归一化中等需要自己维护 1/N资源开销最低增加虚部取反逻辑以及可能的除法器对 IP 的要求必须支持动态模式切换任意 FFT 模块均可适合场景FPGA 工程实时流处理软件实现、被封装死的 IP踩坑概率中等主要集中在切换时序偏中高容易漏特殊点如果项目里用的是常见 FPGA 平台我的建议是优先选用 IP 核自带的动态配置功能这是最省力也最可靠的路线。反变换和正变换在 IP 内部共用蝶形运算单元只是旋转因子和归一化有所区别效果上不会有任何折扣。但如果你的 FFT 模块是外包团队写的或者用了很老的软核代码那共轭法几乎是唯一解。它不依赖任何 FFT 模块的特殊功能只要数学上正确结果就一定正确。只要注意取共轭的数值边界别在溢出点上翻车就行。我还遇到过一种场景是系统的 FFT 模块同时被多个子模块复用有的子模块需要正变换有的需要反变换。这时候如果每个子模块都单独例化一个 IP资源浪费很严重。比较好的方案是只例化一个支持动态模式切换的 FFT 模块用仲裁逻辑把多个子模块的请求分时调度给它。虽然增加了控制复杂度但资源利用率大幅提升。这个思路在资源紧张的工程里还是挺实用的。最后再分享一个我在实际调试中摸索出来的小技巧。无论是用哪种方案都不要直接在真实数据流上调试 IFFT而是先在模块输入端灌入一个时间上很短的脉冲信号比如在采样点 0 处放一个 1其余点放 0。对脉冲做 FFT 得到的是全频段的常数频谱再做 IFFT 应该能还原成脉冲。如果这个过程输出完全正确说明模块配置、时序、归一化都没有问题如果这一步就出错那一定是在基础配置上出了问题趁早排查比在复杂信号上翻车要快得多。这套自检思路我一直沿用到现在几乎每接入一个新的 FFT 模块都会先跑一遍。
阅读完成 · 觉得有帮助？
