C6678 DSP上的FFT工程模板：软件蝶形与FFTC硬件加速双路径实战

简介：面向TI TMS320C66x核处理器开发者，资源提供了在C6678上实现的FFT源代码工程，包含C++与汇编源文件、头文件、链接命令、编译配置文件及生成的可执行映射，可直接导入CCS查看SP单精度小端ELF示例的完整框架。资源共31个文件，大小141KB，主要类型包括cpp、asm、h、cmd、map、xml等，既能查看FFT算法的主流程，也能观察底层汇编与内存布局，适合有一定DSP基础并希望深入多核并行优化的工程师。已有368人学习下载。通过学习工程内fft_example_sp与myfft的实现，可理解基2FFT的位反转、蝶形运算、复数操作，以及C6678多核与向量化下的加速思路；同时工程中.opt、.pp、makefile等配置也有助于熟悉CCS编译流程，为实际项目中的性能调优提供参照。

1. 别把C6678的FFT只当成一个函数库：这份源码包解决的是“算得快”

某图像处理Demo做到一半，4096点复数FFT在单核上转一圈要吃掉大几十万个周期，帧率直接掉到没法看。换到C6678之后，事情变得有意思了：这颗8核DSP上同时存在两条完全不同的FFT实现路径——一条是纯软件蝶形运算，另一条是片上FFTC硬件加速器配合EDMA3搬数。源码包把两条路径都写全了，还带多核任务分发和旋转因子表生成工具。对于要在Keystone架构上做信号处理、雷达测距、频谱分析的开发者来说，这份代码的价值不在于“能算FFT”，而在于把“怎么把一个4096点的FFT安排到8个核和1个专用加速器上”这件事拆成了可以照着抄的工程模板。适合两类人：一类是想快速跑通C6678 ffT工程的新手，另一类是想压榨多核性能做二次开发的熟手。

2. 平台与目录：8核C66x + FFTC外设，源码包里都有什么

2.1 C6678的硬件家底：为什么FFT在这颗DSP上有特殊打法

C6678内部有8个C66x内核，每个核主频可到1.25GHz，各自带32KB的L1P、32KB的L1D和512KB的L2 SRAM，片内还有4MB共享的MSMC SRAM，外部再接DDR3。对于FFT这种访存密集型计算，最关键的一点是：一次4096点复数FFT，输入输出加旋转因子表，总数据量几十KB级别，完全可以塞进单个核的L2里，避免DDR的延迟抖动。

片上还集成了一个FFTC协处理器，专门做FFT运算，支持从16点到8192点的复数FFT，采用基4 DIF结构，内部自带位反序输出。换句话说，这颗DSP给开发者指了两条路：要么用通用内核跑软件蝶形，要么把数据喂给FFTC让它算完再搬回来。源码包里两条路都实现了，还负责把EDMA3、缓存一致性、核间通信这些脏活都串起来。

2.2 源码包目录结构：从CCS工程到链接命令文件

整个源码包按CCS工程的标准布局组织，解开之后是这样一个结构：

c6678_fft/ ├── include/ │ ├── fft.h // 软件FFT接口声明，位反序与蝶形运算 │ ├── twiddle.h // 旋转因子表结构体定义 │ ├── edma3.h // EDMA3通道参数封装 │ └── fftc_drv.h // FFTC硬件加速器寄存器配置接口 ├── src/ │ ├── main.c // 多核入口，核0做初始化与任务分发 │ ├── fft_radix2.c // 基2蝶形运算，支持任意2的幂 │ ├── fftc_drv.c // FFTC配置、启动、状态查询 │ ├── edma3_drv.c // EDMA3通道配置与触发 │ └── ipc_utils.c // 核间中断与共享标志操作 ├── tools/ │ └── gen_twiddle.c // 在PC上生成旋转因子表，输出为C数组 ├── c6678_fft.cmd // 链接命令文件，内存段划分 ├── c6678_fft.projectspec // CCS工程描述文件 └── README.md // 编译步骤与性能数据说明

main.c是入口，但里面没有堆业务代码，它只做三件事：根据当前核号区分主从核，核0完成全局初始化和任务分发，从核等待共享内存里的任务标志。fft_radix2.c是纯软件路径的核心，适合小点数、任意修改点数的应用。fftc_drv.c则是硬件加速路径，寄存器配置走的是CSL（Chip Support Library）风格接口，edma3_drv.c负责把输入数据从DDR或MSMC搬到L2，再把FFTC算完的数据搬回去。

2.3 链接命令文件：把数据放到它该在的地方

DSP开发里最容易被忽略的就是内存放置。这份源码的.cmd文件给出了一个可参考的划分方式：

MEMORY { L2_SRAM : origin = 0x00800000, length = 0x00080000 MSMC_SRAM : origin = 0x0C000000, length = 0x00400000 DDR3 : origin = 0x80000000, length = 0x10000000 } SECTIONS { .text > DDR3 .const > MSMC_SRAM .twiddle_table > L2_SRAM .fft_buffers > L2_SRAM .stack > L2_SRAM }

旋转因子表和FFT输入输出缓冲被强制放在L2里，这是有讲究的。L2的访问延迟比DDR低一个量级，且每个核独占自己的L2，多核并行时不会互相抢带宽。.const放进MSMC是因为多核可能都要访问公共常量，MSMC是共享内存，免去了核间数据拷来拷去的开销。我在实际项目里会把大块的原始采样数据放DDR，只把计算热点数据放进L2，这个.cmd文件的思路值得直接抄。

2.4 两条路线怎么选：软件FFT与FFTC的适用边界

源码包给了两条路，但不能闭着眼睛选。我做了一个简单对比，方便快速决策：

一句话结论：如果点数固定、吞吐要求高，走FFTC；如果点数经常变或者要叠加自定义窗函数，走软件FFT。源码包把两套都跑通了，这就意味着你不用从零调寄存器，直接改main里的调度逻辑就能换路。

3. 软件FFT核心拆解：蝶形运算从输入乱序到结果排序

3.1 位反序：输入数据为什么会乱序

基2 DIT算法的特点是：输入序列需要按照位反序重新排列，输出才是自然顺序。这个源码包的fft_radix2.c里先用一个循环完成重排，代码是这样写的：

void bit_reverse(float *real, float *imag, int n) { int i, j, k; float tr, ti; for (i = 1, j = 0; i < n; i++) { // 位反序的核心：把i的二进制位倒过来得到j k = n >> 1; while (k > 0 && j >= k) { j -= k; k >>= 1; } j += k; // 只有i < j时才交换，避免重复换位 if (i < j) { tr = real[i]; real[i] = real[j]; real[j] = tr; ti = imag[i]; imag[i] = imag[j]; imag[j] = ti; } } }

这个位反序算法没有用查表法，而是每步动态计算。它的优点是不占额外空间，缺点是当点数很大时循环开销占比上升。我一般建议：如果点数固定且循环频繁，就把反序索引提前算好存一个数组，运行时直接按索引取值，能省大约一倍的位操作时间。这里的n是FFT总点数，real和imag分别指向实部虚部数组，调用前需要确保两个数组长度至少为n。

3.2 基2蝶形运算的循环结构：三层循环怎么安排

位反序之后就是标准的基2蝶形，代码位于fft_radix2.c的fft_radix2_run函数里：

void fft_radix2_run(float *real, float *imag, const twiddle_t *tw, int n) { int len, i, j, k; float w_re, w_im, u_re, u_im, v_re, v_im; // len是当前蝶形组的跨度，从2开始倍增到n for (len = 2; len <= n; len <<= 1) { // 旋转因子步进长度为总点数除以当前跨度 int step = n / len; // j遍历同一级里的所有蝶形组 for (j = 0; j < len / 2; j++) { // 取预生成的旋转因子 W_N^k，k = j * step w_re = tw[j * step].re; w_im = tw[j * step].im; // i按跨度跳跃，遍历每组内的蝶形 for (i = j; i < n; i += len) { k = i + len / 2; // 蝶形下支先乘旋转因子 v_re = real[k] * w_re - imag[k] * w_im; v_im = real[k] * w_im + imag[k] * w_re; // 上支加下支，下支减上支 u_re = real[i]; u_im = imag[i]; real[i] = u_re + v_re; imag[i] = u_im + v_im; real[k] = u_re - v_re; imag[k] = u_im - v_im; } } } }

这个实现是浮点版本，精度足够大多数测频场景。需要注意的一点：w_im符号取的负号，对应FFT正变换的旋转因子，如果想做IFFT，把w_im取反即可。len从2倍增到n的过程对应log2(n)级运算，每级的蝶形组数和组内蝶形数此消彼长，整体计算量是n*log2(n)量级。

3.3 旋转因子表生成：用查表代替sin/cos实时计算

运行时重复调sin/cos会拖慢速度，源码包单独放了一个tools/gen_twiddle.c，在PC上生成两张表并输出成C数组，编译时直接编进去：

#include <stdio.h> #include <math.h> #define N 4096 int main(void) { int i, half = N / 2; printf("const float tw_re[%d] = {\n", half); for (i = 0; i < half; i++) { if (i % 6 == 0) printf("\n "); printf("%.8ff, ", cos(2.0 * M_PI * i / N)); } printf("\n};\n\n"); printf("const float tw_im[%d] = {\n", half); for (i = 0; i < half; i++) { if (i % 6 == 0) printf("\n "); printf("%.8ff, ", -sin(2.0 * M_PI * i / N)); } printf("\n};\n"); return 0; }

生成出来的表是浮点格式，直接放进L2的.twiddle_table段。这里只生成N/2个点，是因为旋转因子具有对称性和周期性，W_N^(k+N/2) = -W_N^k，实际只需存储前一半就能覆盖所有蝶形运算的取值。想改成IFFT时，只要把tw_im整表取负，或者在使用时对w_im乘-1，不需要重新建表。

3.4 多核任务划分：8个核怎么分一帧数据

纯软件FFT想利用多核，最简单的办法是把一大块连续输入切成多段，每段独立做小点数FFT，最后再合并。源码包采用的是另一种更实用的方案：把N点FFT拆成两个N/2点FFT，分别交给两个核，再利用旋转因子合并。核心调度代码在main.c里：

int core_id = CSL_chipReadReg(CSL_CHIP_DNUM); if (core_id == 0) { // 主核：准备输入数据，置共享标志 for (int c = 1; c < 8; c++) shared_task[c].flag = 1; // 主核也参与一半计算 fft_half(real, imag, half_n, tw_half); // 等待从核完成 while (shared_task[1].done == 0) ; } else { // 从核：暂停等待主核下发任务 while (shared_task[core_id].flag == 0) ; fft_half(real + core_id * half_n, imag + core_id * half_n, half_n, tw_half); // 写完成标志并触发核间中断通知主核 shared_task[core_id].done = 1; IPC_interrupt_send(0); }

shared_task数组放在MSMC共享内存里，flag和done都是volatile类型。这里最容易被忽略的一点：从核不能 busy wait 主核还没写入的flag，因为默认情况下MSMC的可见性需要显式加cache操作，源码包里在写flag之前调用了CACHE_wbL1d，读之前调用了CACHE_invL1d。如果在二次开发里把这些cache操作删了，十有八九会出现从核永远等不到任务的情况。

4. 硬件加速路径：FFTC配置、EDMA3搬数与中断联动

4.1 FFTC初始化：寄存器配置的学问

FFTC走的是完全不同的代码路径。fftc_drv.c里封装了几个关键的配置步骤：设置FFT点数、输入输出格式、旋转因子加载地址。初始化函数的骨架大致长这样：

void fftc_init(fftc_handle_t *h, int fft_size) { CSL_FftcConfigCfg cfg; CSL_FftcParamGetCfg param; // 先清配置结构体，避免残留值影响行为 memset(&cfg, 0, sizeof(cfg)); cfg.fftSize = fft_size; // 16~8192点 cfg.fftDirection = CSL_FFTC_FWD; // 正变换 cfg.twiddleLoadAddr = (Uint32)twiddle_host; // 旋转因子存放地址 // 加载配置到FFTC模块 CSL_fftcConfig(h->regs, &cfg); // 输入输出格式：复数，32位实部+32位虚部 param.inputFormat = CSL_FFTC_INPUT_CCOMPLEX; param.outputFormat = CSL_FFTC_OUTPUT_CCOMPLEX; CSL_fftcParamConfig(h->regs, &param); }

FFTC的旋转因子不是内部固化的，而是由主核在启动前把表搬到FFTC内部的memory里，twiddleLoadAddr就是告诉它在哪取数据。这里的fft_size不是任意值，必须是2的幂档位，且不能超过8192。参数里的inputFormat决定了每次输入的数据组织方式，如果用实数FFT，输入格式可以配置成实部虚部交替存放，输出再做格式转换，能省一半搬运量。

4.2 EDMA3配置：二维传输把数据喂给加速器

FFTC算得再快，数据喂不进去也是白搭。源码包里用EDMA3通道把DDR里的采样数据搬进FFTC的输入FIFO。EDMA3的PaRAM集配置是这样写的：

void edma3_fft_transfer(edma3_handle_t *h, Uint32 srcAddr, Uint32 dstAddr, Uint16 elementCnt, Uint16 frameCnt) { // elementCnt: 每个传输块内的元素个数 // frameCnt: 传输块数量，FFTC输入按帧接收 h->paramSet.srcAddr = srcAddr; h->paramSet.dstAddr = dstAddr; h->paramSet.aCnt = elementCnt; h->paramSet.bCnt = frameCnt; h->paramSet.cCnt = 1; // 配置源为连续地址，目的为固定地址（FIFO模式） h->paramSet.srcBIdx = elementCnt; h->paramSet.dstBIdx = 0; // 目的地址不递增 // 写入触发字，启动通道 CSL_edma3ChannelSetPaRAM(h->chHnd, 0, &h->paramSet); CSL_edma3ChannelTrigger(h->chHnd); }

地址不递增这个细节很关键：FFTC输入FIFO只有一个固定端口，EDMA3每搬完一个frame的数据都要把写地址复位，如果把dstBIdx配成递增，数据会写到奇怪的内存区域去。源地址递增步长是elementCnt，对应二维传输的每一行长度，单位是字节而不是元素个数，所以传复数数据时elementCnt要乘以8。

4.3 中断与完成握手：怎么知道FFT算完了

FFTC启动后是异步的，源码包用轮询状态寄存器来确认完成，没有启用中断：

int fftc_wait_done(fftc_handle_t *h, int timeout) { volatile Uint32 stat; int cnt = 0; // 轮询FFTC状态寄存器，直到输出有效标志置位 do { stat = CSL_fftcGetStatus(h->regs); if (stat & CSL_FFTC_STAT_OUTPUT_VALID) return 0; } while (++cnt < timeout); // 超时说明配置问题，通常是指数或旋转因子表地址错误 return -1; }

状态位CSL_FFTC_STAT_OUTPUT_VALID只是告诉CPU“输出FIFO里有数据了”，不代表整帧算完。更稳妥的做法是同时检查frame complete标志位，源码包里在确认完成之后还会调用一次EDMA3把结果从输出FIFO搬到DDR。这个先看状态位再搬数的顺序不能乱，如果提前搬，搬回来的可能是上一帧的残留数据，这个问题在调试时让我翻过车。

4.4 性能与精度对比：软硬件两条路的实测感知

以4096点复数FFT为例，在1GHz主频下用CCS的Profile功能测，软件版全查表、浮点运算、L2内计算，单核跑完大约十几万周期；硬件FFTC路径把计算交给协处理器，CPU只负责配置EDMA3和等待状态位，实际占用CPU的周期不到软件版的十分之一，主要耗时变成DMA搬数。两者的频谱结果对比，幅值包络一致，但FFTC输出自带归一化因子，幅值需要乘一个固定系数才和软件版对齐，这个系数在源码包的README里写得很清楚。

多核软件版把任务分到8个核后，理论耗时能压到单核的1/6左右（受限于核间合并开销和L2带宽竞争）。FFTC路径如果只做单帧，优势主要体现在CPU被释放出来，可以在等待期间做其他预处理。如果要做连续流水，FFTC配双缓冲EDMA，让DMA和FFTC同时工作，吞吐还能再上一个台阶。

5. 避坑记录：跑通C6678 FFT的五次翻车现场

5.1 结果全零：缓存一致性在背后捅了一刀

现象：从MSMC搬到L2的输入数据，FFT算完输出全是0，但单独用CCS的Memory窗口看L2地址，数据明明是对的。

原因：核0写进MSMC的数据还在L1D缓存里，没有刷回MSMC。从核读取时，L1D又命中了本地缓存的旧行，读到的是脏数据。C6678默认缓存策略是写回，不是写透，跨核共享内存必须显式刷缓存。

解决：写共享数据之后必须调CACHE_wbL1d，读之前调CACHE_invL1d。源码包里在每次IPC标志操作前后都加了缓存刷写，这个操作不能省。

5.2 EDMA3通道不触发：PaRAM配完忘了写触发字

现象：配置完PaRAM集，EDMA3传输没有启动，数据纹丝不动。

原因：PaRAM集写入之后还要通过事件寄存器或者显式写ESR寄存器来触发通道。很多新手只写了PaRAM，漏了触发这一步，导致传输通道永远处于挂起状态。

解决：检查代码里有没有CSL_edma3ChannelTrigger或者对ESR寄存器置位。如果用了事件触发，还要确认事件源的中断标志没有被屏蔽。我一般建议先用显式触发调试通，再接外设事件。

5.3 FFTC输出幅值只有理论值一半

现象：同一个正弦信号，软件FFT的峰值是A，FFTC的峰值是A/2，其他谱线也都按比例缩小。

原因：FFTC内部实现带有缩放逻辑，不同点数档位对应的归一化因子不同。它不是简单除N，而是按蝶形级数逐步缩放的，所以不能用一个固定常数套所有点数。

解决：查对应点数的缩放因子表，在输出后统一乘系数，或者根据信号类型做校准。源码包的README里给了一张常用点数的缩放对照表，二次开发换点数时记得去查。

5.4 从核始终等不到任务：IPC核间中断的目的地写错了

现象：Core0把flag置1，但Core3一直死循环在等待flag。用CCS挂上去看，共享内存里的flag已经是1。

原因：从核的等待循环读的是自己的L1D缓存副本，没有看到MSMC里的最新值。但更隐蔽的原因是某些IPC中断发送函数里，目标核ID参数不是物理核号，而是中断目的寄存器里的映射值，两者在部分配置下不一致。

解决：先确认共享标志变量的缓存操作做全了；再看IPC发送的目的核ID是不是真的对应目标核的物理编号。调试时可以在从核的等待循环里加一个计数器，超过阈值直接报警，比死等要省时间。

5.5 高点数FFT精度飘了：旋转因子表放在了DDR里

现象：256点FFT正常，4096点FFT的噪底明显抬高，输出谱线旁边多出毛刺。

原因：生成旋转因子的浮点精度不够，表里存的是截断后的值，级数一多误差累积。另一个诱因是表被链接到了DDR3段，访问延迟抖动影响了蝶形运算的一致性。

解决：生成表时用double算完再转float存储，保证每一位都舍入正确；链接命令文件把.twiddle_table固定放L2，不要让它飘到DDR里去。从那以后我每次生成旋转因子表都会顺手检查一遍.cmd文件里的段归属。

6. 二次开发：把这份源码改成你自己的FFT流水线

6.1 复用FFTC通道做连续帧处理

源码包默认是一次性算完单帧就停，改成流式处理时，我一般会给EDMA3配置双缓冲：一块buffer在往FFTC搬数据，另一块buffer同时由CPU填充新采样。切换逻辑放在5.4说的完成标志处——确认输出有效后，交换源地址指针再触发下一次搬数。注意交换指针时要先把两个缓冲都刷过cache，否则连续跑几十帧后会偶发错帧。

6.2 加一个窗函数再进蝶形运算

雷达或音频场景通常要加窗抑制频谱泄漏。软件FFT路径改起来很简单，在bit_reverse之前把输入数组逐点和窗函数相乘即可。窗系数表可以用gen_twiddle.c的同类方式预生成，存成const数组链接到L2。FFTC路径则要多一道工序：EDMA3搬数之前先把数据和窗函数乘好，再触发传输。如果嫌CPU耗时，可以再开一个EDMA通道做乘法，但多数场景下逐点乘一次的开销远小于FFT本身，直接让CPU做就够了。

6.3 实数FFT的省时技巧：打包成半点数

面对实数采样序列，一个经典优化是组合成N/2点复数FFT再拆分。代码写在fft_radix2_run外面，核心逻辑是把x[2k]做实部、x[2k+1]做虚部，调用N/2点复数FFT后，通过共轭对称性还原实数序列的频谱。这个技巧能把实数FFT的计算量直接砍掉一半，配合多核分发，实测吞吐收益比盲目优化蝶形内部循环更明显。我每次改完都会做一步验证：输入一段已知频率的正弦，检查峰值位置和幅值是否与理论值一致，再观察噪底有没有异常抬高。

从那以后我每改动一个FFT模块都强制走一遍流程：先查缓存刷写有没有漏，再看旋转因子表有没有放错段，最后用一个已知信号做端到端对比。这套习惯帮我避开了大部分C6678上的老坑，希望帮到你。

本文还有配套的精品资源，点击获取