TCP3D Decoder Performance

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com). Please read all the links below my signature.

We will get back to you on the above query shortly. Thank you for your patience.

Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

Reading 3.5.2.1 Max and Min Iteration Parameters, I see the following:

Since the hard decisions are only generated on the non-interleaved half iteration, the
maximum number of iterations executed by the TCP3D for all modes except LTE is
MAX_ITR – 0.5. For LTE, the CRC is calculated from the hard decisions during the
interleaved half iteration. As such, the maximum number of iterations executed by the
TCP3D for LTE is MAX_ITR.

As a result, I suspect the formula at 3.5.5.1 might be incorrect, with the term (2*Niter-1) actually being dependent on the mode:
(2*Niter-notLte) (where notLte is 1 for WiMAX, 0 for LTE).

Could someone confirm this observation?

Hi,

Can you confirm that the CPU clock is at 1.2GHz? I believe the results were updated based on the CPU clock at some point. I have an older graph with me as below:

Regards,

Arun

Arun,

Thanks for getting back to me on this.  So my understanding of this is that the performance for Niter=7.5 is when the formula uses 8:

I agree with your diagram if the clock rate is 500MHz (system clock of 1GHz) (see below), provided I make an adjustment to the formula in 3.5.5.1.  The diagram in the document SPRUGS0 is for 600MHz.

This would just alter the computed throughput by a simple scaling.

Initially I had attempted to recreate the plot using the formula shown in the document and was puzzled that I could only get a match if I used 8.5 as the number of iterations used, but then read further and realised that there were some statements about the difference between LTE and WiMAX modes:

Since the hard decisions are only generated on the non-interleaved half iteration, the
maximum number of iterations executed by the TCP3D for all modes except LTE is
MAX_ITR – 0.5. For LTE, the CRC is calculated from the hard decisions during the
interleaved half iteration. As such, the maximum number of iterations executed by the
TCP3D for LTE is MAX_ITR.

So I get a match with your diagram with 7.5 iterations and 500 MHz using the following function (python) provided I pass notLte=0 (that is to say, using a denominator that does not include the "-1" term, implying that the formula in 3.5.5.1 is incorrect. Alternatively, the formula is good and the diagram is bad (note that my analysis is entirely theoretical and based on the following python snippet:

def throughput(Nmap,Fclock,Niter,Lsw0,K,notLte=0):
 '''
 Throughput according to formula in SPRUGS0, section 3.5.5.1.
 Formula altered to include "notLte" factor, because of
 a) comments in section 3.5.2.1
 b) and in order to match with graph in section 3.5.5.1
 '''
 denom = (2*Niter-notLte)*(1+(2*Nmap*Lsw0)/float(K))
 d = (Nmap * 2 * Fclock)/denom
 return d

Hi,

I agree that there is a correction involved in the case of LTE. To calculate the LTE throughput, you have to put in 8.5 instead of 8 or (remove the -1 from the denominator). As part of your input configuration, you would still pass in 8 as your iterations. 

Regards,

Arun

Arun,

Many thanks for the clarification: I just wanted to be sure I understood the processing throughput computations.

Regards

David