Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

speex encoder on nios 2

Hi,

I'm trying to port Speex encoder unit on a Nios 2 system. I managed to compile the code and upload it to the device. The only thing is that, using either the floating point or the fixed point operating mode, the result obtained are different from the ones obtained on Debian, using the exact same code(the code is from the user manual, the encode section, without any additions).

The system I'm using has a NIOS2/f processor, and I'm using a Rs232 uart to communicate with a computer so i can collect the data.

Has anyone tried this? If not, do you have any ideas about this problem?

Regards,

Alex

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Dunno - but I'd try to sort out the fixed point/integer version.

    It is much more likely to give matching results and will run a lot faster (less slowly) than the FP version.

    You might have to resort to printing some intermediate values...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Currently I'm working on the fixed point version, but, as I wrote before, the differences exist on this version to. I have some problems following the code-line, because I have little experience in this job-line ( in this moment I can't say for sure that I identified correctly the main encoding function, or if that encoding function is the first function called in the encoding routine , because they are using pointers to functions).

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I forgot to mention that the differences are evolving, to say so. The length for the encoded packet is the same, but the containing data are wrong. In the first packet, only 4/15 Bytes are different, but that number increases.

    After decoding this, I'm obtaining a nice white noise.:(
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Well, you want to find the first divergence - everything beyond that isn't worth looking for.

    Might be something really silly - like failing to get the test data initialised properly, or the stack hitting the heap!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I also thought that the problem is in the memory size(stack overflow) but then I encountered another problem.

    The actual structure of the nios is cpu+pio+jtag+uart+onchip memory (4kB ) used for reset and exception vector + onchip memory (256 kB ) for code and data.

    If I try to modify the size of the second RAM ( +/-) or if I try to use the external RAM I get the "verify failed" error when uploading the code.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I'd try with a single memory block. I'm not sure the linker script (etc) DTRT when there are multiple onchip memory areas.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks, I managed to make it upload on the external RAM ( the problem was that in the generated SOPC system wasn't linked the output clock signal to the RAM, so I connected it manually).

    But overall, the Speex still doesn't work, so I concluded that there is no stack overflow problem :(