Reuse of LDPC Code Base Matrices - 1.1 English

It is possible to reuse a single base matrix to support different code rates and codeword sizes in the following ways:

1. Change the sub-matrix size to support different codeword sizes at the same rate. For each code, specify a different PSIZE, N, and K (as defined in REG0 to REG2), while keeping the offset parameters in the shared code definition tables (that is, SC_OFF, LA_OFF and QC_OFF in REG3) the same.
2. Reuse only a portion of the base matrix to support different codeword sizes and rates, but with the same K. If the base matrix takes the form shown in the following figure (more specifically, the column of the rightmost non-zero sub-matrix increases monotonically with layer), it is possible to reduce the number of columns in the base matrix by reducing the number of layers, NLAYERS, and N in the code definition while keeping the offset parameters in the shared code definition tables (that is, SC_OFF, LA_OFF and QC_OFF) the same. The rate increases as the number of parity bits and codeword size is reduced.

Figure 1. Changing Number of Columns in Base Matrix by Adjusting NLAYERS

For method 1, if PSIZE ≤ 64, then packing is performed (unless the NO_PACKING field is set in the code definition register). In this case, the QC_TABLE entries are different. As such, for support of all PSIZE, at least three sets of QC_TABLEs are required (that is, one for PSIZE ≤ 32, one for 32 < PSIZE ≤ 64, and one for PSIZE > 64). Furthermore, a method to reduce the rotation to be less than PSIZE is required, although this might be done from the largest value using a suitable reduction operation, for example, modulo(ROTATION, PSIZE).

If this operation results in differences between the rotation values for the two codes, then a separate set of entries is required in the QC_TABLE. For example, if the PSIZE for two codes was 33 and 64, and the rotation value was 48, then, because 48 is greater than 33, there would need to be a reduced value specified for PSIZE = 33 and, as a consequence, the QC_TABLE entries for each code would need to be defined separately. If all the rotation values were less than 33, then only one set of entries would need to be defined in the QC_TABLE for both codes.

For method 2, the stall parameters (in LA_TABLE) might change with the number of layers. Analysis of the changes can be performed by passing the code with different numbers of layers through the core API to generate the instruction tables. The amount of variation depends upon the code, but it is likely that the number of variants can be significantly reduced to less than one LA_TABLE per codeword size. It might also be possible to further reduce the number of tables by setting the stall values to be the maximum of those generated by the API. That is, it is safe to use a STALL value larger than that provided by the API, although this might have implications on throughput.

With either method, it is necessary to provide code parameters (that is, REG0-3) for each code variant. There are 128 register sets available to support this. The shared code parameters SC_TABLE, LA_TABLE, QC_TABLE can be apportioned as necessary between unique codes, and combined in an arbitrary fashion by the code parameters for a particular code definition. If these are to be rewritten, then it might be appropriate to sub-divide the tables into a number of equal size partitions to allow each partition to be written independently.

Methods 1 and 2 can be combined to obtain greater flexibility.