• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 644 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCP2 on 6482

Brad Clarkson
Intellectual 350 points

I'm using the TCP2 on a 6482 (little endian) to decode 3GPP data...  and it is decoding the blocks fine... 

But I have 2 questions that may or may not be related...

1)  I have to swap the of the output hard decisions around to get the correct buffer.  I'm using TCP2_OUT_ORDER_31_0.  Here's my code that swaps the bytes around:

    for (int i = 0; i < (NumInfoBits + 4) / BITS_IN_BYTE; i += 4)
    {
        Uint8 tmp0 = turboHD[i];
        Uint8 tmp1 = turboHD[i+1];
        Uint8 tmp2 = turboHD[i+2];
        Uint8 tmp3 = turboHD[i+3];
        turboHD[i]   = tmp3;
        turboHD[i+1] = tmp2;
        turboHD[i+2] = tmp1;
        turboHD[i+3] = tmp0;
    }

If I switch to TCP2_OUT_ORDER_0_31, then the data is in the correct bytes, but I'd have to swap bits 0 & 7, 1 & 6, etc.

Am I doing something wrong...  causing the bits to need swapping around?

2) I'd like to use the TCP2's CRC stop criteria, but I can't get it to ever stop early (even though the CRC is good).

/* TCP2 configuration defines */
#define TCP2_INTERLEAVER_LOAD_FLAG  TRUE    /* To load the interleaver RAM */
#define TCP2_MAX_ITERATIONS          8      /* Maximum iterations of the TCP2 */
#define TCP2_MIN_ITERATIONS          2      /* minimum iterations of the TCP2 */
#define TCP2_OUT_PARAM_READ_FLAG    TRUE    /* Output parameters read flag */
#define TCP2_PROLOG_SIZE            12      /* prolog size */
#define TCP2_PROLOG_REDUCTION       TRUE    /* prolog reduction enabled */
#define TCP2_MAX_STAR_ENABLE        TRUE    /* Maximum star enable */
#define TCP2_EXTR_SCALE             0       /* set this if MAX STAR is FALSE */

    /* setup the TCP2 base params */
    tcp2BaseInit->inputSign    = TCP2_INPUT_SIGN_POSITIVE;
    tcp2BaseInit->intFlag      = TCP2_INTERLEAVER_LOAD_FLAG;
    tcp2BaseInit->maxIter      = TCP2_MAX_ITERATIONS;
    tcp2BaseInit->maxStarEn    = TCP2_MAX_STAR_ENABLE;
    tcp2BaseInit->standard     = TCP2_STANDARD_3GPP;
    tcp2BaseInit->crcLen       = 24;   /* CRC */
    tcp2BaseInit->crcPoly      = 0x00864CFB; /* CRC poly */
    tcp2BaseInit->minIter      = TCP2_MIN_ITERATIONS;
    tcp2BaseInit->numCrcPass   = 1; /* default value */
    tcp2BaseInit->outParmFlag  = TCP2_OUT_PARAM_READ_FLAG;
    tcp2BaseInit->outputOrder  = TCP2_OUT_ORDER_31_0;
    tcp2BaseInit->prologRedEn  = TCP2_PROLOG_REDUCTION;
    tcp2BaseInit->prologSize   = TCP2_PROLOG_SIZE;
    tcp2BaseInit->rate         = TCP2_RATE_1_3;
    tcp2BaseInit->map          = 0;
    tcp2BaseInit->snr          = 0; /* disable SNR threshold checking */

Maybe the CRC-stop problem is related to me having to swap the output bits around?

 thanks,

Brad

 

 

  • 0
    TI__Guru* 84110 points

    Brad,

    Although I am not the TCP2 expert that you need, I may be able to give you some advice on the byte swapping code.

    You can use intrinsics to do this, specifically _packhl2 and _swap4. For example,

        for (i = 0; i < (NumInfoBits + 4) / BITS_IN_BYTE; i += 4)
        {
            Uint32 tmp = _amem4(&turboHD[i]);
            tmp = _swap4( _packhl2( tmp, tmp ) );
            _amem4(&turboHD[i]) = tmp;
        }

    I am not sure why you add 4 to NumInfoBits. Since the loop is always executed 4 bytes at a time (your version and the swap4 version), I would have expected +31 here to make sure you get to the last full word.

    If you know anything about NumInfoBits, mainly if it will result in an even number of words, then you can add #pragma UNROLL(2) in front of the for-loop to get even better optimization.

    Regards,
    RandyP

  • 0
    TI__Mastermind 23525 points

    Brad,

    Comments from a colleague here at TI:

    1. The TCP2 stores output hard decisions packed in 32-bit words.  As long as they are always accessed as 32-bit words (i.e. using 32-bit data types), then they will always appear in the desired order (bit_31 down to bit_0).  If they are accessed as individual bytes, then the endian mode of the system will affect the apparent byte ordering of the data within each 32-bit word.  The byte ordering within each 32-bit word will be opposite for little-endian and big-endian modes.  So, depending on the endian mode of the system and how the next module in the processing chain accesses and uses the TCP2 output data, the bytes may need to be swapped.

     

    2. The TCP2 CRC stopping criteria was originally designed for 3GPP2.  It does not support the CRC check defined for WCDMA (transport blocks) or LTE (transport/codeblocks).  The TCP2 CRC calculation is initialized with all 1’s, so it will not work for LTE.  And it does not bit-reverse the CRC, so it will not work for WCDMA.

     

    Regards,

    Travis

     

  • 0 in reply to tscheck
    Intellectual 350 points

    Thanks alot for the information!  I'll update my unpack routine and quit trying to make the CRC work for LTE!

    thanks,

    Brad

  • 0 in reply to Brad Clarkson
    Intellectual 480 points

    Brad,

    In your post you said "the CRC is good".  Do you mean you have seen the crc_pass field in TCPSTAT register set to TRUE? 

    I'm also having problems with the CRC aspect of the TCP.  However, I'm not trying to get early termination based on CRC, I just want to know if the CRC passed.  Your question not only flushed out the initialisation to all ones (a big thank you!), it also suggests that you have had at least some success with CRCPOLY = 0x00864CFB.  This surprised me as SPRU973 Table 12 suggests that the polynomial should be in the form 'shift right to drop the LSB', whereas 0x00864CFB looks like 'drop the MSB' format, i.e. I would have expected 0x0C3267D for the 24 bits CRC.  Hence my opening question.

    Travis / Randy,

    Can either of you add anything?

    Regards,    Tim

  • 0 in reply to Tim Jackson
    Intellectual 350 points

    Tim,

    > Do you mean you have seen the crc_pass field in TCPSTAT register set to TRUE? 

    No...  by saying "the CRC is good", I meant that I checked the TCP output buffer... and it had a valid transport block with a valid CRC.

    I never had any success with the TCP automatically checking the CRC... since the TCP does not support the way LTE does CRCs.  I just checked the CRC myself after the TCP finished.

    Sorry I'm not more help...

    Brad

  • 0 in reply to Brad Clarkson
    TI__Mastermind 23525 points

    I'll have a few other folks take a look...

     

    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 480 points

    I have now tried the 24 bit polynomial from SPRU973 and still get CRC_PASS=0.  I've tried all ones and all zeroes initial register states in my CRC generator.  The data decodes error free, including the 24 bits carrying the CRC.

    Is there some example code which exercises the CRC check functionality?

    Regards,    Tim