AnsweredAssumed Answered

Same code produces different results in VDK and standard VisualDSP projects?

Question asked by Jaco on Jul 5, 2010
Latest reply on Jul 20, 2010 by CraigG



I have implemented an overlap save convolution algorithm and I use exactly the same code in a standard SHARC VisualDSP project and a VDK project. However, the results generated by these two projects differ in a strange way. I have been struggling to find the cause, but no success. Here are the details:


The input signal comes from a file "inp32k.dat". This file contains 32768 samples. The overlap save algorithm reads and writes the data in blocks of 1024 samples at a time while applying a 1024 tap filter to it using the standard overlap save method. Just to keep things simple I've made the filter all ones, so in effect it is just a moving average filter. The code writes the result into a file called "out32k.dat". I've attached the two projects in zip files


I've targeted the code for the ADSP21479 DSP and run the code in the simulator. I have a test drive licence and am running VisualDSP++ 5.0 with update 8 on Windows 7.


Now here is the strange part. When I run the standard VisualDSP project that I've attached it produces the correct results as verified by a Matlab simulation. When I run the VDK project on the same data it produces different results. I've attached a screen capture of the difference of the two output signals:




As you can see it is mostly zero, but with a strange block of non-zero values at about sample number 25000. In the VDK project I have only one thread called MainThread which is also designated as the boot thread. This thread's Run() function runs exactly the same code as that of the main function of the standard project. At first I thought it might be stack problems, but I've tried with different thread stack sizes up to 16384. I also verified with the VDK history window that the stack size used by this thread is only 167. The other interesting phenomenon is that the results are different when I try different stack sizes. Is this maybe caused by using file I/O in VDK?


Finally, the real project that I'm working on is a Gardner non-uniformly partitioned real-time convolver. This method requires threading. However, after not being able to produce the correct results I've been able to narrow it down to the contrived example that I'm reporting here.