Memory management

From the above discussion, it is clear that decoding many blocks at the same time requires no small storage area for ASIC or DSP implementation. One should therefore

try to make the most of the memory space available. The decoder needs space to store (I) received samples undergoing decoding, (II) extrinsic information, (III) decoded bits to be forwarded to a higher layer for further processing, and (IV) received samples awaiting decoding. The management of the last category, assuming no buffer overflow, requires only an indicator signal to forward a new block of received samples to the part of the storage area designated for category (I) that was just released due to a stopping decision.

Category (III) is needed because of the stopping time variation across blocks. Its management is straightforward and, besides, it requires much less storage space. As mentioned in Subsection 6.1.2, assigning the extrinsic values for ST-approved bits a constant large value is equivalent to using a (special) binary-valued bit to indicate which partial paths should survive in the APP decoding process. Hence the decoded bits serve the dual purposes of representing the decoder decisions and bookkeeping the survivor paths. The management of categories (I) and (II), however, needs more efforts and careful considerations.

As long as the probability of termination-defying blocks exists, practical latency consideration will force us to set an upper limit D_max on the number of DRs. It can be shown that an unterminated block prevents the decoder from discarding y² associated with those terminated blocks within its span. When the number of blocks that terminate at or around the Dmaxth DR is large so will be the memory required. Hardware constraint thus imposes another threshold Mmax, the maximum affordable (allowable) memory units (MU) where an MU refers to the space for storing categories (I) and (II) associated with a block of data in the decoder. As our sole purpose is to demonstrate the critical role a memory manager plays in the VTT-APP decoder, we assume, for simplicity, that the same number of bits is used to represent the extrinsic information of a bit and the corresponding received sample. An MU is thus assumed to contain KL bits, where a K-bit word is used to store either the extrinsic information or received baseband sample associated with a transmitted bit.

3

Figure 6.6: A joint memory management and IBPTC decoding procedure.

Because of the stopping time variation nature of our decoder, a memory manager has to take into account both thresholds, Dmax and Mmax so as to optimize the perfor-mance. When a block has failed to pass the ST for Dmax times, it will automatically be discarded and the MUs storing the corresponding categories (I) and (II) information are released accordingly. Chances are more than one block that reach the threshold Dmax

simultaneously and it is even more likely that the decoder runs out of MUs before a block reaches the threshold D_max. For both cases, one should then give up decoding one or some of the unterminated blocks. It is both reasonable and intuitively-appearing to terminate the most ancient block, i.e., the one which has failed the ST most often. We refer to these memory shortage induced stopping as forced early stopping.

Fig. 6.6 shows a finite-memory IBPTC decoding procedure for one phase of an ADU. The procedure involves APP decoding, interleaving, deinterleaving, regular and extended stopping decisions, and memory check and release. The last two operations are

collectively called the memory management scheme which is responsible for verifying if there is enough memory during the decoding process and make a proper memory-release decision if there is not enough storage space. As there is no computation involved at all, the complexity is moderate at most.

Denote by MF, Md and MR, the numbers of free (unused) MUs, ADUs, and the required MUs for storing one received block. It follows that MR= x for a rate R = 1/x turbo code. The decoder is initialized with MF = Mmax. An ADU begins a phase by checking if MF > MR (Box 2) where the additional MU is for storing extrinsic information. If M_F does not meet the condition, the memory manager determines which block is to be discarded, makes a forced ESDs, and releases the related storage space (Box 4). Otherwise, the decoder moves the received samples of the new block from where they were saved (in the buffer area) to the corresponding category (I) MUs (Box 3).

Deciding which block is to be given up is simple and clear since our decoding schedule allows only a single most ancient block in its left-most active column at any time. When a forced ESD is made the ADU makes hard decisions on the block to be discarded and releases the related categories (I) and (II) MUs. As the discarded block is always the most ancient block and our decoding schedule is such that all blocks to its left must have been terminated for one reason or another, we are left with the problem of dealing with the related unstopped blocks,the S adjacent blocks to its right for S-IBPTC, if they have not been terminated. At least two alternatives exist for solving this problem. The first solution, which leads to better performance at the cost of higher complexity, is to interleave or de-interleave the extrinsic values for use in decoding the related unstopped blocks, the S blocks to its right for S-IBPTC, without further updates. The second one is to make hard-decisions (stop any further decoding) on all related unstopped blocks, S blocks within its (right) span for S-IBPTC, releasing their category (I) MUs while keeping their category (II) MUs for use in decoding other related blocks.

At beginning of each DR, we ask the decoder whether the scheduled DR is needed (Box 5). Unless the decoder has been notified to by-pass the ensuing DR, we still have to ask if the space for storing the extrinsic information of the coming DR is available.

When such a space is not available (MF = 0) the decoder has to find room for the next DR by discarding the most ancient unterminated block and following the memory release procedure described above (Box 7). The operations in Box 9 include those described in the last paragraph of Subsection 6.1.2. When a regular or extended stopping decision is made, the memory manager releases the corresponding category (II) and parts of category (I) memory (Box 10), memory release procedure 1) and notifies the decoder that further decodings on these blocks are no longer necessary.