Patent Application
20150244397
The present disclosure relates to the field of digital communications and, more particularly, to efficient FEC decoder scheduling and receiver pipeline flow control in digital communication systems.
Communication systems such as G.hn (ITU-T standard G.9960/G.9961) rely on low density parity check (LDPC) codes for forward error correction (FEC). These codes have recently become popular in several advanced communication systems because they can lead to a throughput that approaches the channel capacity of a channel while still allowing for efficient decoding. The decoding methods used for these codes are usually based on iterative techniques that converge on the correct codeword after some number of iterations when the channel noise is not too high. Since it is generally not possible to know when the noise level has exceeded the capability of the code to correct the errors, it is not easy to determine if a particular LDPC decoding iteration would converge and find the correct codeword. Ideally a decoder in a receiver of a communication system is allowed to run decoder iterations until the codeword is successfully recovered or it is determined that convergence is unlikely. However, that is not practical for high data-rate communications since the upper limit on the decoding time is unknown. Therefore, decoders are typically designed with sufficient throughput to run a fixed number of iterations for each codeword. If it takes the decoder longer than this upper limit to converge to a correct codeword, the decoder aborts the operation and the codeword is uncorrected. If the decoder converges in fewer number of iterations than the maximum number of iterations, the decoder moves on to the next codeword, but there is no way to take advantage of the time savings. Therefore, it is desirable to have a technique that provides the maximum amount of time to the decoder for decoding each codeword, based on the time budget available in the receiver at any given instant.
The receiver time budget for G.hn as well as other communication systems depends on several factors. Generally, a receiver is designed with a throughput that matches or exceeds the requirements of the relevant standard. In the case of G.hn the throughput target is 1 Gbps for a 100-Mhz baseband power-line device. Since the receiver pipeline dataflow is complex, each component of the pipeline needs to exceed this throughput requirement so that the overall pipeline can meet the requirement. Another consideration for the pipeline is the inter-frame gap (IFG) which defines the minimum amount of time between transmissions on the medium. In a half-duplex system such as G.hn, the size of the IFG determines how quickly the receiver pipeline must complete the processing of a frame before preparing to transmit the next frame. Since the LDPC decoder is the last part of the G.hn pipeline, the IFG affects the amount of time the LDPC decoder can spend working on the final codewords of a frame. The location of the LDPC decoder in the pipeline also means that it can slow down the entire pipeline if it consumes too much time. A receiver pipeline would usually include a time domain first-in-first-out (FIFO) module that can absorb some extra pipeline delay caused by the LDPC decoder or other receiver processes. The size of this FIFO module also affects the time budget of the receiver pipeline in general and the LDPC decoder in particular.
Various embodiments pertaining to efficient FEC decoder scheduling and receiver pipeline flow control are described herein. Embodiments of the techniques, processes, algorithms, devices, apparatuses and systems described herein, and any variations thereof, may be implemented in the form of software, firmware, hardware or any combination thereof.
According to one aspect, a method may include: receiving, by a communication device, a frame; and processing the frame by the communication device. The processing may include dynamically adjusting allocation of time for decoding each codeword in the frame by a decoder of the communication device.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may include: calculating an average amount of time that can be allowed by the decoder in decoding each codeword, a minimum amount of time that must be allowed by the decoder in decoding each codeword, and a maximum amount of time that cannot be exceeded by the decoder in decoding each codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: tracking, during processing of the frame, a number of codewords processed by the decoder, and a target number of codewords that would be processed if the average codeword processing time were maintained.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: determining whether the number of codewords processed by the decoder is above the target number of codewords.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the number of codewords processed by the decoder is above the target number of codewords, determining whether an amount of time used by the decoder in decoding a current codeword equals a maximum amount of time that cannot be exceeded by the decoder in decoding each codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the amount of time used by the decoder in decoding a current codeword has reached the maximum amount of time: abandoning the current codeword; and processing a next codeword in the frame.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the amount of time used by the decoder in decoding the current codeword has not reached the maximum amount of time and enough time remains to run a decoder iteration, enabling the decoder to perform a next iteration on the current codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the number of codewords processed by the decoder is not above the target number of codewords, determining whether there is sufficient extra time to allow for one or more additional iterations by the decoder for the current codeword.
In one embodiment, the determining whether there is sufficient extra time may include: tracking an amount of extra time to allow for one or more additional iterations by the decoder for each codeword based at least in part on a number of clocks per iteration for decoding a codeword of a given size and a clock counter used in tracking the slack.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that there is sufficient extra time to allow for one or more additional iterations by the decoder for the first codeword, determining whether the time used by the decoder in decoding the current codeword equals the maximum amount of time that cannot be exceeded by the decoder in decoding each codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the time used by the decoder in decoding the current codeword has reached the maximum amount of time, abandoning the current codeword and processing a next codeword in the frame.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the amount of time used by the decoder in decoding a current codeword has not reached the maximum allowed time, enabling the decoder to perform a next iteration on the current codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that there is not sufficient extra time to allow for one or more additional iterations by the decoder for the current codeword, determining whether a minimum amount of time has been consumed by the decoder in decoding the current codeword.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the minimum amount of time has been consumed by the decoder in decoding the current codeword, abandoning the current codeword and processing a next codeword in the frame.
In one embodiment, the dynamically adjusting allocation of time for decoding each codeword in the frame may further include: in response to determining that the minimum amount of time has not been consumed by the decoder in decoding the first codeword, enabling the decoder to perform a next iteration on the first codeword.
In one embodiment, the decoder may include a low density parity check (LDPC) decoder.
In one embodiment, a decoder time may be tracked based on iterations of the LDPC decoder.
In one embodiment, the average, minimum, and maximum times may be recalculated at some points during processing of the frame.
According to another aspect, a device may include: a memory unit configured to store data, a set of instructions, or a combination thereof; a communication unit configured to receive a frame; and a processing unit coupled to the memory unit and the communication unit. The processing unit may be configured to process the frame by dynamically adjusting allocation of time for decoding each codeword in the frame.
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the processing unit may be configured to perform operations including: calculating an average amount of time that can be allowed by the processing unit in decoding each codeword, a minimum amount of time that must be allowed by the processing unit in decoding each codeword, and a maximum amount of time that cannot be exceeded by the processing unit in decoding each codeword; tracking, during processing of the frame, a number of codewords processed by the processing unit and a target number of codewords that would be processed if the average codeword processing time were maintained; and determining whether the number of codewords processed by the processing unit is above the target number of codewords.
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the processing unit may be further configured to perform operations including: in response to determining that the number of codewords processed by the decoder is above the target number of codewords, determining whether an amount of time used by the processing unit in decoding a current codeword equals a maximum amount of time that cannot be exceeded by the processing unit in decoding each codeword; in response to determining that the amount of time used by the processing unit in decoding a current codeword has reached the maximum amount of time: abandoning the current codeword; and processing a next codeword in the frame; in response to determining that the amount of time used by the decoder in decoding the current codeword has not reached the maximum amount of time and enough time remains to run a decoder iteration, enabling the processing unit to perform a next iteration on the current codeword.
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the processing unit may be further configured to perform operations including: in response to determining that the number of codewords processed by the processing unit is not above the target number of codewords, determining whether there is sufficient extra time to allow for one or more additional iterations by the processing unit for the current codeword; tracking an amount of extra time to allow for one or more additional iterations by the processing unit for each codeword based at least in part on a number of clocks per iteration for decoding a codeword of a given size and a clock counter used in tracking the extra time; in response to determining that there is sufficient extra time to allow for one or more additional iterations by the processing unit for the current codeword, determining whether the time used by the processing unit in decoding the current codeword equals the maximum amount of time that cannot be exceeded by the processing unit in decoding each codeword; in response to determining that the time used by the processing unit in decoding the current codeword has reached the maximum amount of time: abandoning the current codeword; and processing a next codeword in the frame; in response to determining that the time used by the processing unit in decoding the current codeword has not reached the maximum amount of time, performing a next iteration on the current codeword; in response to determining that there is not sufficient extra time to allow for one or more additional iterations by the processing unit for the current codeword, determining whether a minimum number of iterations has been performed by the processing unit in decoding the first codeword; in response to determining that the minimum amount of time has been consumed by the processing unit in decoding the current codeword: abandoning the current codeword; and processing a next codeword in the frame; and in response to determining that the minimum amount of time has not been consumed by the processing unit in decoding the current codeword, performing a next iteration on the current codeword.
This summary is provided to introduce the inventive concept pertaining to efficient FEC decoder scheduling and receiver pipeline flow control in digital communication systems. A select number of embodiments, including preferred embodiments, of the inventive concept are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of the present disclosure. The drawings illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the present disclosure.
The inventive concept presented herein takes into account in real-time all of the factors described above with respect to the issues to be addressed to produce a maximum number of iterations allowed for each codeword in the decoder. Therefore, each codeword gets the maximum amount of processing time and has a greater chance of convergence, leading to overall improvement in the throughput as well as reduction in the number of uncorrected codewords that need to be retransmitted.
The basic strategy of the inventive concept is to calculate the target number of iterations that can be allowed, on average, for each codeword in a frame and then ensure that this target is met, for the duration of the frame. The target is tracked and compared to the actual progress in order to allow additional time to be allocated to codewords when the LDPC decoder progress is faster than average. In this manner each codeword is allocated the maximum amount of time and the pipeline timing constraints are not exceeded. Those of ordinary skill in the art would appreciate that, although examples and embodiments presented herein are specific to G.hn, the inventive concept is applicable to any communication system that uses LDPC or similar error correcting codes which take variable time for decoding depending on the noise conditions on the channel.
Referring to
In the receive direction, samples enter from the analog front end (AFE) block at the rate of one sample per sample clock and are processed in the time domain by the time domain processing block. The FIFO block collects samples and kicks off the fast Fourier transform (FFT) block whenever an entire orthogonal frequency division multiplexing (OFDM) symbol's worth of samples are available for processing. The time domain samples of the OFDM symbol are then processed in the FFT block and transferred to the frequency domain processing block. Similar to the FFT block, the frequency domain processing block processes data on OFDM symbol boundaries. After the frequency domain processing, the data is segregated (using the operation known as de-framing) along the codeword boundaries into FEC codewords for processing in the error correction block (i.e., LDPC decoder). The three distinct processing granularities along the receive path (namely: sample, symbol, and codeword) make pipeline dataflow scheduling complex. This is further complicated by the fact that the relative time required for each process varies depending on the parameters chosen for the frame (e.g., bit loading, codeword size, FEC rate, etc). With the exception of the error correction, all processes in the receive path usually take a constant amount of time for a particular frame with a given set of framing parameters. However, the time taken by the LDPC decoder is variable and depends on the noise conditions on the channel. The focus of the inventive concept is to carefully control the variable processing time of the LDPC decoder to ensure efficient receiver operation in spite of the complex dataflow requirements.
For a half-duplex system such as G.hn, one of the considerations for allocating time to the LDPC decoder is the maximum time allowed between receiving a frame and transmitting a new frame, known as the inter-frame gap (IFG). The IFG affects the decoder time budget when an immediate response (either as an acknowledgement or a new transmission) is required after a frame is received.
Referring to
The example illustrated in
(TFFT+TFD+TLDPC+TCPU+TIFFT)<(IFGMIN+TPREAMBLE) (1)
In Equation 1 all the time values are constant for a given set of framing parameters with the exception of TLDPC (available time for processing by the LDPC decoder) and TCPU (available time for processing by the CPU). Therefore, when the goal is to increase TCPU (available time for processing by the CPU) or decrease IFGMIN (minimum required time for IFG), thereby improving the throughput by reducing the wasted time on the transmission medium, the goal may be accomplished by reducing TLDPC. The time budget established by the inventive concept allows an upper limit to be placed on TLDPC while still providing maximum processing time for each codeword in the LDPC decoder.
An example algorithm of efficient FEC decoder scheduling and receive pipeline flow control in accordance with the present disclosure is described herein.
The example algorithm may be explained by way of equations expressed in terms of parameters and variables. Definitions of certain parameters used in the algorithm, calculated for each received frame, are as follows:
Definitions of certain working variables used in the algorithm, calculated for each received frame, are as follows:
It is noteworthy that, although the definitions and algorithm description are defined in terms of system clocks, any time measuring mechanism with sufficient resolution would suffice.
For G.hn most of the parameters for a frame that is being received are unknown until the header has been decoded. Therefore, the example algorithm described herein is applied to the payload of the frame, after the header has been successfully decoded.
After the header has been decoded, the following basic parameters for the frame may be determined:
Using these parameters the CLCW parameter may be calculated as follows (Equation 2):
CL
CW=(CLSYM*CWSIZE)/SYMSIZE (2)
This calculation is simplified for illustrative purposes. The last OFDM symbol could contain a partial codeword that does not need to be processed. In very low throughput cases the difference could be significant. However, in those cases the LDPC decoder has more time to work on each codeword and the difference may not need to be considered.
As long as the LDPC decoder runtime per codeword is less than or equal to CLCW, the decoder would not slow down the receiver pipeline. However, for the purpose of maximizing decoding efficiency it is advantageous to sometimes allow the decoder to exceed this average (CLCW). The amount of additional time the decoder is allowed to consume, referred to as the slack herein, is largely determined by two factors, namely: (1) the amount of additional space in the receive FIFO, and (2) the required IFG. For a frame that does not require a quick response the available FIFO space would determine the slack and the IFG would not be a consideration. However, if a quick response is required (such as G.hn acknowledgement) then it is possible that the FIFO cannot be allowed to fill up without potentially exceeding the IFG. Since the slack represents time, it can be specified in terms of number of clocks as follows (Equation 3):
CL
Slack=min(available RX FIFO space in system clocks,IFG time budget) (3)
Equation 3 is merely a guideline as the actual calculation may need to consider other factors related to the receiver pipeline dataflow or system timing. For hardware efficiency the slack can also be specified in terms of the number of decoder iterations, as long as each iteration requires a fixed number of clocks, as follows (Equation 4):
I
Slack=floor(CLSlack/CLI) (4)
The algorithm requires two additional tuning parameters, namely: IMIN and IMAX. The minimum number of iterations allowed per codeword would normally be set to a maximum number of iterations that can be run without exceeding CLCW, as follows (Equation 5):
I
MIN=floor(CLCW/CLI) (5)
Since the IMIN calculation could drop too much precision in some cases, an initial slack could be assigned to compensate using the CLINIT parameter. For example, this parameter could be set to the total precision loss due to rounding: CLINIT=(CLCW mod CLI)*(total number of OFDM symbols in the frame), provided that CLINIT<=CLSlack. The IMIN parameter could also be set lower than the above calculation to allow the decoder to catch up after falling behind. In that case the algorithm would perform better on the initial codewords if it were initialized with more slack assigned in CLINIT. Although the IMIN parameter specifies the minimum number of iterations to run, the LDPC decoder could decide to abandon the codeword before IMIN iterations if the LDPC decoder determines that the codeword is unlikely to converge based on some other criteria. The LDPC decoder could also successfully decode the codeword in fewer iterations.
The other tuning parameter, IMAX, defines the upper limit on the number of iterations that can be run on any codeword. This limit prevents the decoder from wasting too much time on a codeword that is unlikely to converge. IMAX may be determined based on simulations or tests of the decoder using a particular channel and set of system parameters.
The example algorithm may also be explained by way of flowcharts, as shown in
At 302, the algorithm initializes parameters and/or variables. For example, the algorithm may initialize the working variables as follows: CNTAVE=CLCW, CNTSlack=CLINIT, CWAVE=0 and CWCUR=0.
At 304, the algorithm starts average and current counters. For example, the algorithm may start the codeword counter CWCUR as well as the clock counters CNTAVE and CNTSlack.
At 306, the algorithm increments codeword count. For example, the current codeword counter CWCUR is incremented.
At 308, the algorithm determines whether the receiving of a frame by the transceiver 100 has been completed. If the receiving of the frame has been completed, the process 300 stops; otherwise, the process 300 proceeds to 310.
At 310, the algorithm determines whether parameter update is necessary. If it is determined that the update of one or more parameters is necessary, the process 300 proceeds to 320, at which point any new parameter update is applied, and then proceeds to 312. If it is determined that no parameter update is necessary, the process 300 directly proceeds from 310 to 312.
At 312, the algorithm determines whether the particular codeword currently being processed is the last codeword. If it is determined that the particular codeword is the last codeword, then the process 300 proceeds to 322 to freeze the average counter, e.g., by freezing the counter CWAVE, and then proceeds to 314. If it is determined that no parameter update is necessary, the process 300 directly proceeds from 312 to 314.
At 314, the algorithm runs an LDPC iteration.
At 316, the algorithm performs codeword selection. For example, the algorithm performs process 400, as shown in
At 318, the algorithm determines whether the processing of the current codeword is completed (e.g., the codeword was successfully decoded or it was abandoned). If it is determined that the processing of the codeword is completed, the process 300 proceeds to 306; otherwise, the process 300 proceeds to 312.
At 402, the algorithm determines whether the decoding of a given codeword is complete. If it is determined that the decoding of the codeword is complete, the process 400 proceeds to 416, at which point the process 400 starts processing the next codeword in the frame; otherwise, the process 400 proceeds to 404.
At 404, the algorithm determines whether the current count of processed codewords is greater than the number of codewords that should have been processed. If it is determined that the current count of processed codewords, e.g., CWCUR, is greater than the number of codewords that should have been processed, e.g., CWAVE, the process 400 proceeds to 412; otherwise, the process 400 proceeds to 406.
At 406, the algorithm determines whether there is sufficient slack for an iteration, e.g., whether it is true that CNTSlack is greater than or equal to CLI. If it is determined that there is sufficient slack for an iteration, the process 400 proceeds to 412; otherwise, the process 400 proceeds to 408.
At 408, the algorithm determines whether a minimum number of iterations have been completed, e.g., ICUR>=IMIN. If the determination is positive, the process 400 proceeds to 414; otherwise, the process 400 proceeds to 410. Alternatively, the LDPC decoder or another algorithm may decide to abandon the codeword before IMIN iterations are carried out. In such case the process 400 also proceeds to 414.
At 410, the algorithm selects the next iteration of the same codeword to be ran next.
At 412, the algorithm determines whether a maximum number of iterations have been reached, e.g., ICUR=IMAX. If the determination is negative, the process 400 proceeds to 410; otherwise, the process 400 proceeds to 414.
At 414, the algorithm abandons the codeword. For example, if the codeword fails to converge after the maximum number of iterations have been completed, the algorithm determines that there is an uncorrectable error and stops trying to decode the codeword.
At 416, the algorithm selects the first iteration of the next codeword in the received frame to be processed next.
At 502, the algorithm advances clock counter.
At 504, the algorithm determines whether timeout has been reached. If it is determined that timeout, e.g., CLCW, has been reached, the process 500 proceeds to 514; otherwise, the process 500 proceeds to 506.
At 506, the algorithm determines whether the current count of processed codewords is greater than the number of codewords that should have been processed. If it is determined that the current count of processed codewords, e.g., CWCUR, is greater than the number of codewords that should have been processed, e.g., CWAVE, the process 500 proceeds to 518; otherwise, the process 500 proceeds to 508.
At 508, the algorithm determines whether the current count of processed codewords is equal to the number of codewords that should have been processed. If it is determined that the current count of processed codewords, e.g., CWCUR, is equal to the number of codewords that should have been processed, e.g., CWAVE, the process 500 ends; otherwise, the process 500 proceeds to 510.
At 510, the algorithm determines whether the clock counter for slack is at the minimum, e.g., CNTSlack=0. If it is determined that the clock counter for slack is at the minimum, the process 500 ends; otherwise, the process 500 proceeds to 512.
At 512, the algorithm decrements the clock counter for slack, e.g., CNTSlack=CNTSlack−1.
At 514, the algorithm increments target codeword count. For example, the algorithm increments CWAVE.
At 516, the algorithm resets the clock counter.
At 518, the algorithm determines whether the slack is at the maximum. For example, the algorithm determines whether CNTSlack is equal to CLSlack. If it is determined that the slack is at the maximum, the process 500 ends; otherwise, the process 500 proceeds to 520.
At 520, the algorithm increments the clock counter for slack, e.g., CNTSlack=CNTSlack+1.
An example pseudo code that executes the above-described algorithm is described below. At the beginning of the first payload symbol (after ACE if present) the above parameters (CLCW, IMIN, IMAX, CLI, ISlack, CLSlack and CLINIT) are calculated. Then, the working variables are initialized as follows:
The following example pseudo code describes an operation of the algorithm for calculations.
When the last codeword of a frame is started in the LDPC decoder, the algorithm may set the value of certain variables as follows:
The calculations shown in the pseudo code above are performed on the last codeword which would be given the remaining slack or IMAX iterations, whichever is less.
As an additional optimization, the last codewords of a frame may be allowed to run for an extended time when the LDPC decoder runtime is limited by the size of the RX FIFO instead of the IFG. A separate iteration parameter is defined for this case: ILAST. After the last OFDM symbol is received in the time domain (e.g., the RX FIFO is no longer collecting new samples), all remaining codewords may be allowed to run for ILAST iterations, regardless of the slack.
When an impulse noise event occurs, it may be possible to determine that one or more codewords are unlikely to be correctable. For example, the masked or unused subcarriers could be used to detect impulse noise events by determining the total amount of error that is received in the known data for all masked tones. Likewise, the error in the data carrying tones could be accumulated to infer if an impulse noise event had likely occurred. Using this information the LDPC input could be indicated as erased and likely uncorrectable. If a codeword is indicated as erased the algorithm could take that into account and avoid wasting time on trying to process the codeword. It is likely that such codewords would not be able to be decoded and would require retransmission. To compensate, the algorithm could recalculate the CLCW and other parameters based on fewer codewords needing to be decoded.
In the preceding discussion the algorithm is discussed using a system clock to measure the passage of time. However, any timing reference could be used as long as it has sufficient accuracy. As an example, the G.hn network timing reference (NTR) could be used. The NTR measures the passage of time based on a network-wide timing reference. This method allows the algorithm to work independently of the speed of the system clock and automatically adjust for network timing. It is noteworthy that the NTR is one possible alternative timing reference, among others. The algorithm attempts to compensate for both the RX FIFO and IFG requirements in one set of parameters. Although this would be effective in many cases, in other cases it would be more optimal to allow the parameters to be reset to new values when some codewords remain to be processed. On a long frame, this method would allow the algorithm to use one set of parameters initially for avoiding RX FIFO overflow and then another set at the end to ensure IFG or to provide additional time when IFG is not a concern. The second set of parameters could be precalculated and programmed to be applied after a certain number of codewords have been processed.
Example enhancements 1 and 2 discuss times when it may be beneficial to recalculate the algorithm parameters, in particular the target processing rate, CLCW, maximum slack, CLSlack, and the iteration limits, IMIN and IMAX. Other events could trigger a parameter update and the parameters could be updated for every codeword if necessary. However, since parameter calculations can be more complex than the algorithm for tracking progress, it is expected that parameter updates would not occur often. The algorithm would perform well with no parameter updates in most cases.
Example process 600 includes one or more operations, actions, or functions as illustrated by one or more of blocks 602 and 604. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Process 600 may be implemented in one or more scenarios as depicted in one or more of
At 602, the communication device may receive a frame.
At 604, the communication device may process the frame by dynamically adjusting allocation of time for decoding each codeword in the frame by a decoder of the communication device.
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the communication device may calculate a target number of iterations that cannot be exceeded by the decoder in decoding each codeword. For example, the communication device may calculate the following: an average amount of time that can be allowed by the decoder in decoding each codeword, a minimum amount of time that must be allowed by the decoder in decoding each codeword, and a maximum amount of time that cannot be exceeded by the decoder in decoding each codeword
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the communication device may track a number of iterations by the decoder in decoding a first codeword in the frame. For example, the communication device may track, during processing of the frame, a number of codewords processed by the decoder as well as a target number of codewords that would be processed if the average codeword processing time were maintained.
In one embodiment, in dynamically adjusting allocation of time for decoding each codeword in the frame, the communication device may determine whether the number of codewords processed by the decoder is above the target number of codewords.
In one embodiment, in response to determining that the number of codewords processed by the decoder is above the target number of codewords, the communication device may determine whether an amount of time used by the decoder in decoding a current codeword equals a maximum amount of time that cannot be exceeded by the decoder in decoding each codeword.
In one embodiment, in response to determining that the amount of time used by the decoder in decoding a current codeword has reached the maximum amount of time, the communication device may abandon the current codeword and process a next codeword in the frame.
In one embodiment, in response to determining that the amount of time used by the decoder in decoding the current codeword has not reached the maximum amount of time and enough time remains to run a decoder iteration, the communication device may enable the decoder to perform a next iteration on the current codeword.
In one embodiment, in response to determining that the number of codewords processed by the decoder is not above the target number of codewords, the communication device may determine whether there is sufficient extra time to allow for one or more additional iterations by the decoder for the current codeword.
In one embodiment, in determining whether there is sufficient extra time, the communication device may track an amount of extra time to allow for one or more additional iterations by the decoder for each codeword based at least in part on a number of clocks per iteration for decoding a codeword of a given size and a clock counter used in tracking the slack.
In one embodiment, in response to determining that there is sufficient extra time to allow for one or more additional iterations by the decoder for the first codeword, the communication device may determine whether the time used by the decoder in decoding the current codeword equals the maximum amount of time that cannot be exceeded by the decoder in decoding each codeword.
In one embodiment, in response to determining that the time used by the decoder in decoding the current codeword has reached the maximum amount of time, the communication device may abandon the current codeword and process a next codeword in the frame.
In one embodiment, in response to determining that the amount of time used by the decoder in decoding a current codeword has not reached the maximum allowed time, the communication device may enable the decoder to perform a next iteration on the current codeword.
In one embodiment, in response to determining that there is not sufficient extra time to allow for one or more additional iterations by the decoder for the current codeword, the communication device may determine whether a minimum amount of time has been consumed by the decoder in decoding the current codeword.
In one embodiment, in response to determining that the minimum amount of time has been consumed by the decoder in decoding the current codeword, the communication device may abandon the current codeword and process a next codeword in the frame.
In one embodiment, in response to determining that the minimum amount of time has not been consumed by the decoder in decoding the first codeword, the communication device may enable the decoder to perform a next iteration on the first codeword.
In one embodiment, the decoder comprises a LDPC decoder.
In one embodiment, a decoder time is tracked based on iterations of the LDPC decoder.
In one embodiment, the average, minimum, and maximum times are recalculated at some points during processing of the frame.
As shown in
The above-described techniques pertain to efficient FEC decoder scheduling and receiver pipeline flow control. Although the techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing such techniques. Those skilled in the art may make derivations and/or modifications of any of the disclosed embodiments or any variations thereof, and such derivations and modifications are still within the scope of the present disclosure.
In the above description of example implementations, for purposes of explanation, specific numbers, materials configurations, and other details are set forth in order to better explain the invention, as claimed. However, it would be apparent to one skilled in the art that the claimed invention may be practiced using different details than the example ones described herein. In other instances, well-known features are omitted or simplified to clarify the description of the example implementations.
The inventor intends the described embodiments to be primarily examples. The inventor does not intend these embodiments to limit the scope of the appended claims. Rather, the inventor has contemplated that the claimed invention might also be embodied and implemented in other ways, in conjunction with other present or future technologies.
Moreover, the word “example” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word example is intended to present concepts and techniques in a concrete fashion. The term “techniques,” for instance, may refer to one or more devices, apparatuses, systems, methods, articles of manufacture, and/or computer-readable instructions as indicated by the context described herein.
As used in the present disclosure, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more,” unless specified otherwise or clear from context to be directed to a singular form.
