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.

BCP CRC data format in LTE mode

Hello!

I want to ask something about the imput and output data format in the CRC submodule of the BCP in LTE mode.

Why there is a rule of the floowing:

Imput:

 Input byte buffer (packed 8-bits-per-byte).The bit order in each byte is msb first.
 *              When NumInputBits is not multiple of 8, the last (NumInputBits mod 8) bits are in
 *              the msb bits of InputBytes[NumInputBits/8].

Output:

These L bits shall be appended to the input bits by the system in the same way 
 *              as the input bits are packed, i.e. MSB bit first and MSB byte first

Is this an rule of the 3GPP 36.211 or a special rule of the TI hardware?

Thanks in advanced for anybody who can help me on this problem.

Alan

 

  • Nobody? Can anyone help on it?

  • Can anyone help on it?

  • Can anyone help on it?

  • Hi Chen,

    All BCP sub-modules including CRC are internally little-endian (both byte and bit endianness). As mentioned in sections 4.3.1.1 and 4.3.1.2 of the BCP user guide:

    4.3.1.1 Input Data: Input Data is packed into 128-bit words. The first data value to be processed is in the LSB of the first 128-bit word, and continues in packed format.

    4.3.1.2 Output Data: Output data is always packed into 128-bit words, the first value to be transmitted is in the least significant bit(s).

    The BCP supports Data reformatting and endian conversion as defined in section 3.3 (Data Reformatting and Endian conversion). Apart from byte swaps, the BCP also supports bit reversal on 8, 16 and 32 bit boundaries. The Input and output data endianness and format conversion settings can be configured on a per flow basis inside the Traffic Manager using the fields FORMAT_IN, and ENDIAN_IN in the TM_FLOW_ID_TABLE registers.

    Can you please check how these fields are setup in your code? From your description, it appears that the FORMAT_IN (FORMAT_OUT is the same as FORMAT_IN) field is setup for 8-bit reversal.

    Please refer to sections 3.3 and Table 4-3 (TM Register details) for details about endianness and format conversion support.

    Regards
    -Nitin

  • Hi Nitin,

       I am sure that in my code the following seting suit for your description:

        rxCfg.tmFlowCfg.endian_in           =   Bcp_EndianFormat_32;
        rxCfg.tmFlowCfg.endian_out          =   Bcp_EndianFormat_32;
        rxCfg.tmFlowCfg.format_in           =   Bcp_DataFormat_NoChange;
        rxCfg.tmFlowCfg.pkt_type            =   0;      // No special pkt assignments
        rxCfg.tmFlowCfg.dsp_int_sel         =   0;

       rxCfg.tmFlowCfg.format_out          =   Bcp_DataFormat_NoChange;

    And the rule I said above is quoted by the TI employee of China in the deyisurpoort.com. He told me that the input and output data must be followed this rule:

     Input byte buffer (packed 8-bits-per-byte).The bit order in each byte is msb first.
     *              When NumInputBits is not multiple of 8, the last (NumInputBits mod 8) bits are in
     *              the msb bits of InputBytes[NumInputBits/8].

    output data(only the L bits, not the N bits part, N+L is the whole output data of CRC submodule)

    These L bits shall be appended to the input bits by the system in the same way 
     *              as the input bits are packed, i.e. MSB bit first and MSB byte first.

    In my eyes, I think this rule is only for CRC submodule(the N bits input of CRC and the L bits output data ) . My question is why the CRC submodule has such sepcial rules? Is it  needed by the 3GPP in the LTE TS36.212 or just a rule by TI hardware?

    Thank you sincerely for answer me question very much!!!

    Alan

  • Hi Chen,

    I think there is misunderstanding. The in/out format you mentioned is for the software function bcp_crcCodecC64pByte which is provided in the bcp_crc.c in pdk, while the in/out format for BCP CRC is as Nitin said with detailed description in the BCP user guide.

    If u still feel obscure, we can have call for more. Thanks.

    And here great appreciation for Nitin's help.

    Andy

  • Hi Andy,

    This question really bothers me a lot and you really help me a lot in the forum. Firstlly thank you and Nithin greatly in advance.

    The software CRC can do the same results as the hardware CRC so I think the software CRC do the same procedures as the the hardware CRC. And the  bcp_crcCodecC64pByte which is provided in the bcp_crc.c in pdk is for CRC caculation only. The function of bcp_crcCodecC64pByte does not need the input and output data fomat change as described in the 3GPP TS36.212.

    Then I lead the quesiton why the software CRC should do the data fomat changing, which in my mind is equal to why the hardware CRC should do the data format changing. Maybe there is really mislead you that the so called "why the hardware CRC should do the data format changing" here is focus on the equal part to the "the software CRC should do the data fomat changing", not the data format asked before the hardware input and output. I feel deeply sorry on this and I am still confuse about why we should do the data format before bcp_crcCodecC64pByte caculation?

    If Andy still cannot understand my question this time, beg you conntect me on xiechen528@foxmail.com my be there canbe the voice email in Chinese which I can really explain my question.

    Thanks agian deeply!!

    Alan