problem about utilizing TCP2 on C6455

Hi Cho,

I think you are not really setting the SNR to be 50 in that parameter. 

The parameter configBase.snr          = 50;   /* 0 = disable SNR threshold checking */ is suggesting that there is some sort of stopping criteria for the testbench. Can you try changing the configBase.snr = 0 and re-run the program?

Also, your 2nd point is interesting. It should not behave in such a fashion. Can you also try changing the extrinsic scaling factors to 32 instead of 0 and re-run it?

for (i = 0; i < 16; i++) configBase.extrScaling [i] = 32;

Regards,

Arun

Thanks for your reply

I really do set SNR = 50 but there is no difference between 2 cases.(whether SNR = 50 or SNR = 0)

I also test the extrScaling value. TCP2 could not recover the error at all when the value = 32 as your suggestion.

But the lower extrScaling value reports  the lower error ratio. It meas when extrScaling = 0, TCP2 recover the error at most.

Is there any other checking point ?

What about the CRC Check? Did you try enabling it to see if there is any improvement? 

Regards,

Arun

Did you mean the CRC on TCP2 ifself?

If yes, it is not available to us due to frame is longer than decoded frame by TCP2.

So i check the bit corruption by comparing bit by bit.

Is there any differences for TCP2's performance base on CRC ?

I think the CRC is just one of criteria whether it goes furthure or stop so it shall not explain this weired behaivor.

Could you check the source  that I coded ?

Hi Cho,

I'm sorry i should have re-phrased my reply. Yes you are correct, CRC is a stopping criteria. Your settings look fine. Can you try running this attached example code and see if this works for TCP2 on C6455/TCI6482?

Regards,

Arun

Hi Arun.
Thank you for your reply.

My test bed is a C6455DSK.
My project is already "TCI6482TCP2VCP2BER" was based.
I attach the code of the project is associated with TCP2.
Please check the problem.

Hello,

I know this thread is inactive much time ago, but I have the same problem posted at the beginning of the thread by post. Sorry for inconvenience.

I have the same configuration of the TCP2, and the best performance is for an only iteration. The greater number of iterations, the greater number of wrong bits in the output.

In the last replay, it is said that the problem happened because of the interleaving of parities before sending to TCP2:

"Also note that interleaved parities must be de-interleaved prior to being sent to TCP2." on page 22, SPRU973

I do not really understand the meaning of that sentence. Maybe does it refer to the organization of systematic and parity in words before sending to TCP2?

Please, considerer the algorithm that I am using to organized systematic and parity data.

My input data (systematic and parity) is stored in a Int8 buffer in (5,3), i.e. SIIII.FFF.

Data in that array are:

X0, A0, A0’, X1, A1, A1’, …

My algorithm tries to convert the data from (5,3) to (4,2), and pack them as expected by the TCP when using rate 1/3 and little endian mode (figure 8, SPRU973):

         Word N + 1                                       Word N

---------------------------------------------------------------------------------

0     A1’     0     A1     X1                 0     A0’     0     A0     X0

The code is the following:

void pack32SoftBits(Int8 *input, Uint32 *output, Uint16 length)
{
  Uint32 i;
  Uint32 k;
  Int8 tmp[3]; // To convert from (5,3) data in input to (4,2) data in output


  for(i = 0; i < (length/3); i++)  //length, total number of 8-bit input soft bits (systematic and parity data)
  {
    for(k = 0; k < 3; k++)
    {

      // Get three input data (X, A, A')

      tmp[k] = input[3*i+k];

      // (5,3) --> (4,2)

      tmp[k] = tmp[k] >> 1;

      if (tmp[k] > 31)
      {
        tmp[k] = 31;
      }
      if (tmp[k] < -32)
      {
        tmp[k] = -32;
      }
    }

    output[i] = 0;

    output[i] |= ((tmp[2] & 0x3F) << 18) | ((tmp[1] & 0x3F) << 6) | (tmp[0] & 0x3F);

  }
}

Later, output pointer is used as source address when programming the EDMA3 transfer of systematic and parity data to TCP2.

Where could be the problem?

Thank you in advance.

David.

I found the solution to the problem. Effectively, the problem was related to the interleaved parities, because I was not de-interleaving them prior to being sent to TCP2.

I found out how to do it and now I get the expected bits in the output.

The algorithm posted above to convert the data from (5,3) to (4,2), and pack them as expected by the TCP when using rate 1/3 and little endian mode is right.

Here it is the algorithm which de-interleaves the interleaved parities.

Data in softBitsVector array: X0 A0 A0' X1 A1 A1' ... and the 12 tail soft bits at the end.

Where,

    X:  systematic

    A:  parity

    A': interleaved parity

Each data in softBitsVector array is a signed char.