DS634 Datasheet, PDF (8/20 Pages) –

IEEE 802.16e CTC Decoder v4.0
The decoder can accept a new code block only when the output signal rdyforblk (rdyforblk(1) is High
for the 480, 960, 1440, 1920, and 2400 blocks and rdyforblk(0) is High for the remaining blocks). There-
fore, before sending a new code block to the decoder, the user must check that the rdyforblk
signal is High before proceeding. If the user pulses the start_in signal High when the rdyforblk signal
is Low, the operation of the core is corrupted and must be reset before correct operation can resume.
Upon reset, the rdyforblk signal goes High.
If the code block is not one of the last five blocks of the H-ARQ mode, then the decoder can process P
code blocks, while a second P code block is being written. Therefore, the rdyforblk(0) signal remains
High after the first P start_in pulses. If the first P code blocks are still being processed, the rdyforblk(0)
Dsignal goes Low upon seeing the second P start_in pulses.
If the code block is one of the last five blocks of the H-ARQ mode, then the decoder can process one
code block while a second code block is being written. Therefore, rdyforblk(1) signal remains High
i_{after the first start_in pulse. If the first block is still being processed, the rdyforblk(1) signal goes Low}
s_{upon seeing the second start_in pulse.}
It is assumed that data from the code block continues to arrive even though the rdyforblk signal is Low.
c_{Thus, the rdyforblk signal truly is a “ready for block” indicator and not a “ready for data” indicator.}
The start_in pulse must go High for only one clock and only once per code block.
o _{After the decoder finishes writing the first code block to the output buffer, the rdyforblk signal goes}
High and remains High until another start_in pulse arrives (assuming the second code block is still
n _{being processed). This sequence of events repeats for each subsequent input block.}
t ^Latency
i The latency of the decoder is a function of the block size, the number of iterations, the number of SISO
n processors, and the clock frequency. It is also dependent upon the current state of the decoder. In par-
ticular, the time it takes to decode a given code block can be large if the decoder is still iterating on the
previous code block. In other words, part of the latency for the new code block is attributed to waiting
u _{for the decoder to finish iterating on the previous code block.}
In some cases, the decoder finishes iterating on the previous code block before the new code block is
e _{completely written to the input buffer. In these cases, the input buffer is the bottleneck, and the decod-}
ing latency for a given block is the same as the first block latency.
d _{The latency of the IEEE 802.16e CTC decoder core is defined as the number of clocks from the time the}
last sample of the first code block is received to the time the first sample of the first code block is coming
out of the decoder. Latency in terms of number of clocks is given by Equation 1.
IP _{L = 2Ni[2N′ + C] + 25}
Equation 1
where N_i is the number of iterations, N' is the data block size in pairs (N) divided by the number of
SISOs (Ns), when N is equal to 480, 960, 1440, 1920, or 2400 pairs; otherwise N' is the block size in pairs
(N), and C is a constant that is equal to 21 when early termination is disabled; otherwise, C is equal to
25.
8
www.xilinx.com
DS634 December 2, 2009
Product Specification