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.

Regarding the rate-dematch submodule for Bit Rate Coprocessor (BCP) in TI 6670

Hi,

I am wondering if the rate-dematch (RD) submodule for Bit Rate Coprocessor (BCP) in TI 6670 (explained in section 4.8 of the Bit Rate Coprocessor manual for 6670 chip) supports rate-dematching for the DL-PDSCH in LTE? In particular, is it possible to program parameters N_soft, K_MIMO, M_limit, etc (explained in 5.1.4.1.2 of 36.212, Rel. 8) to be used in this submodule?

Thanks in advance,

Dejan

  • Hello, Dejan

    the difference between PUSCH and PDSCH is the soft buffer size for the r-th code block (represented by Ncb bits). Ncb for PUSCH is always equal to the circular buffer size for r-th code block, while ncb for PDSCH could be less than or equal to the circular buffer size. the RD module in BCP can be used for PDSCH only if Ncb for PDSCH is equal to the circular buffer size for the r-th code block. if the parameters UE category, Kmimo and M_limit are chosen such that PDSCH Ncb is equal to the circular buffer size, then the RD module can be used for PDSCH.

    thanks and regards,

    Xiaozhou (Jennifer) Huang

     

  • Thanks very much for the response! That was my understanding as well.

    Dejan

  • Hi Xiaozhou, I'm trying to use BCP RD for PDSCH.


    I would like to use it also when Ncb is less than the circular buffer, can I fill the "missing bits" with 0 and send the request to BCP?


    i.e:

    Virtual Buffer = 800; Ncb = 768

    I could fill with dummy bits the last 32 bits of each CodeBlocks and send the request to BCP RD module using Ncb=800

    Do you see any drawbacks? 

    Thanks

  • hello, Sriva

    the basic idea is right, but not that simple by just adding 32 bits at the end.  The 32 zero bits might not be at the end, could be in the middle . It will depends on the code block size, the number of rate matching output numbers, and the rv index.  At the rate matching side, it starts to read out bit from the circular buffer based on the rv Index, then based on the number of rate matching output, it could read to the end (Ncb), then circular back to the beginning of the circular buffer, then in this case, the 32 zero bits will be in the middle of rate dematch input, not at the end. 

    thanks and regards,

    Xiaozhou (Jennifer) Huang

  • Hi Xiaozhou, I don't get your point.

    In my understanding even in case of Rv=3 the circular buffer should be filled by zero at the end.
    In example, with Rv=3 and virtual buffer = half of code block

    | [p1/p2]''' | sys | [p1/p2]' |

    where:
    [p1/p2]''' are the last intervleaved parity 1 and parity 2 bits (from starting point to the end of code block
    sys are all the systematic bits
    [p1/p2]' are the first intervleaved parity 1 and parity 2 bits

    Some p1/p2 are dropped because the virtual cicular buffer cannot contain all data.

    In this case in order to use the RD I should transform the buffer in this way:

    | [p1/p2]''' | sys | [p1/p2]' | zeroes |


    Am I right?

    Also in this example case the zeroes should be always at the end of the virtual circular buffer...
    Thanks for yout help!
  • hello, Sriva,

    inside the circular buffer, the added zero is always at the end, this is right. but what I am saying it, when you fill in the circular buffer with the input data, the added zero is NOT always at the end of the input data stream.

    Regards,

    Xiaozhou (Jennifer) Huang

  • Thanks for your help, now it's clear.
    Regards