Bug in ARM assembler optimezed OpenMAX implementation?

I believed i've found a bug in the assembler optimized version of the
OpenMAX implementation, can anyone here confirm this bug?


First, i begin with the software version i'm using!

* Arm Assembler optimized openmax (OX001-BU-00010-r2p0-00rel0)
Filename: ARM_OpenMax_OX001-BU-0010-r2p0-00rel0.tgz
md5sum: 2eb4fb315e5935bcfa5cf9ed28e63954

* ARM C implementation of openmax (OX000-BU-00010-r1p0-00bet0)
Filename: arm-download-98665.tgz
md5sum c093bd73e6e48c13952855a63ec5baab


* Compiler Toolchains
RVDS: RVDS v 4.0

$ arm-eabi-gcc --version
arm-eabi-gcc (GCC) 4.4.0
Copyright © 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



* Report
The function omxSP_FIR_Direct_S16 provides different results when
comparing the C implementation and the Assembler optimized version
when TAP length is over 9 TAPS!
Also, TAP length of 4, 8, 12, 16 results in segmention fault on my
target (Android telephone HTC Magic)

** Specifics

*** TAP length = 13
OMX_S16 FIR_TESTVECTOR[100] = {
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,
  10000,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0
};

const OMX_S16 Coeff[13]={16384, 8192,4096,2048,1024,512,256,128,64,32,16,16,0};
int Coefflen=13;

delayline is zeroed
delaylinIndex 0

result = omxSP_FIR_Direct_S16(FIR_TESTVECTOR, Destination, len, Coeff,
Coefflen,  delayline, delaylineIndex); 


Provides the result:
**** CORRECT C implementation  (performed on PC)
...
Destination[18]==0
Destination[19]==0
Destination[20]==5000
Destination[21]==2500
Destination[22]==1250
Destination[23]==625
Destination[24]==313
Destination[25]==156
Destination[26]==78
Destination[27]==39
Destination[28]==20
Destination[29]==10
Destination[30]==5
Destination[31]==5
Destination[32]==0
...

**** FAILED!! Assembler implementation (performed on target, ARM1176)
Destination[18]==0
Destination[19]==0
Destination[20]==-2
Destination[21]==-6641
Destination[22]==-9926
Destination[23]==-2435
Destination[24]==-7426
Destination[25]==-2436
Destination[26]==-4177
Destination[27]==-2418
Destination[28]==-7426
Destination[29]==-2319
Destination[30]==0
Destination[31]==-2435
Destination[32]==0



*** TAP length = 9
OMX_S16 FIR_TESTVECTOR[100] = {
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,
  10000,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0,
  0,0,0,0,0,0,0,0,0,0
};

const OMX_S16 Coeff[13]={16384, 8192,4096,2048,1024,512,256,128,64,32,16,16,0};
int Coefflen=9;

delayline is zeroed
delaylinIndex 0

result = omxSP_FIR_Direct_S16(FIR_TESTVECTOR, Destination, len, Coeff,
Coefflen,  delayline, delaylineIndex); 


Provides the result:
**** CORRECT C implementation  (performed on PC)
...
Destination[18]==0
Destination[19]==0
Destination[20]==5000
Destination[21]==2500
Destination[22]==1250
Destination[23]==625
Destination[24]==313
Destination[25]==156
Destination[26]==78
Destination[27]==39
Destination[28]==20
Destination[29]==0
Destination[30]==0
Destination[31]==0
Destination[32]==0
...

**** CORRECT Assembler implementation (performed on target, ARM1176)
Destination[18]==0
Destination[19]==0
Destination[20]==5000
Destination[21]==2500
Destination[22]==1250
Destination[23]==625
Destination[24]==313
Destination[25]==156
Destination[26]==78
Destination[27]==39
Destination[28]==20
Destination[29]==0
Destination[30]==0
Destination[31]==0
Destination[32]==0

Do anyone here have possibility to confirm this bug??


/Bo Svangård,
System Designer, EmbeddedArt AB, Swden
Telephon +46-736 631 628

Hello,
I am using OX002-BU-0010-r2p0-00rel0 for SP function and I have not tried to do comparison with C version of it.
Have you used omxSP_FFTFwd_CToC_SC32_Sfs and omxSP_FFTInv_CToC_SC32_Sfs  SP functions ?

no

I want to use float values as input of this functions ?
ok

Do you have any idea about that?

no

Thanks,
rach