OMAP-L138跑LINUX时DSP做FFT运算速度慢的问题

Jiangfeng Xiao

Prodigy 80 points

Other Parts Discussed in Thread: SPRC265

使用omapl138的arm核跑linux，dsp通过upp接口接收fpga上传的AD采样数据，然后对其做fft运算，但运算速度很慢。

论坛里也有个类似问题的 www.deyisupport.com/.../22241.aspx

给的意见是：

#1. 请问是否采用的TI的DSP库？如果是，请根据这个网页计算一下理论值：http://www.ti.com/lsds/ti/dsp/c6000_dsp/c674x/benchmarks.page

#2. 数据Bufer放在片上还是DDR？或者ShareRAM，如果不是片上L2-RAM，是否正确使能Cache.

#3. 做为测试，可以停掉ARM，只跑DSP以验证运算速度。

#4. 最好是用profile来统计cycle数，而不是绝对时间。

#5. PLL是否正确倍频，运行在什么频率？

我这边的情况是：

1、使用的是TI的DSP库，网址www.ti.com/.../sprc265，调用的是时间抽取基2的DSPF_sp_cfftr2_dit()函数

2、数据Buffer放在片上IRAM，

#pragma DATA_SECTION(“数据Buffer”, ".xbuf");

CMD文件对xbuf定义

.xbuf:   {} > IRAM

4、统计cycle数代码如下

    unsigned int cycles, t_i, t_extra, t_delta;
    t_i = CLK_gethtime();
    t_extra = CLK_gethtime() - t_i;
    t_i = CLK_gethtime();//获取当前时钟
    DSPF_sp_cfftr2_dit((float * )x, (float * )tw, N);
    //调用fft函数       
    bit_rev((float * )x,N);//旋转基运算
    t_delta = CLK_gethtime() - t_i - t_extra;
    cycle = t_delta;

然后得出结论是DSP completed processing in 9216266 cycles.需要900万个周期。
3、作为测试，当我把arm停掉时，只跑dsp，代码是完全一样的，统计cycle方法也是一样的，但是单独跑dsp时只需要30万个周期就能算完FFT。

请问下，像这种情况，是否ARM和DSP抢占DDR所致？有没有好的办法可以解决这个问题？
另外，PLL是否正确倍频如何查看？因为PLL是arm初始化的，而arm跑linux系统的话不知道从哪个内核源码有PLL频率信息，或者可以通过别的方式获知？
谢谢~

10 年多前

0 Gary Wu 10 年多前

TI__Genius 10941 points

ARM侧跑Linux时，请问使用的是UBL+u-boot+kernel的方式？

还是使用AISgen工具配置参数，使用u-boot+kernel方式？

想说的是前者可以在UBL代码中找到PLL的配置，后者是在AISgen工具中设置的。

如果只是使用DSP，可以使用仿真器，然后通过GEL文件进行初始化，其中就有PLL的初始化代码

0 Jiangfeng Xiao 10 年多前回复 Gary Wu

Prodigy 80 points

非常感谢您的答复。

当ARM侧跑Linux时，我使用的是UBL+U-boot+kernel的方式。

这两天一直在看UBL的源码、编译、ais格式转换，等，因为之前使用的是现成的ubl-nand.bin镜像，所以得仔细阅读下源码才能确定其PLL是如何配置的。

PLL是配置如下的，具体代码如下：

    // CPU(s) at 300 MHz
    status |= DEVICE_PLL0Init(0, 24, 0, 1, 0, 11, 5);
      // Timings for DDR2 at 150 MHz
      status |= DEVICE_ExternalMemInit(0x00000047, 0x08934832, 0x204929C9, 0x0C12C722, 0x00000406, 0x00000000);

从配置方式上看UBL和裸跑DSP时的GEL文件对PLL初始化是一样一样的。

处理器

处理器论坛

OMAP-L138跑LINUX时DSP做FFT运算速度慢的问题