NR Polar Decoder
Libraries:
Wireless HDL Toolbox /
Error Detection and Correction
Description
The NR Polar Decoder block implements a streaming polar decoder with hardware-friendly control signals. The 5G NR standard uses polar codes for channel coding of the DCI, UCI, and BCH transmit channels.
You must specify the link direction because the coding scheme defined by the 5G NR standard is different for downlink and uplink messages. Downlink messages are encoded with interleaving and use a CRC length of 24 bits. Uplink messages do not use interleaving, and use a CRC length of 6 or 11.
This block implements a CRC-aided successive-cancellation list decoder. This
implementation matches the performance of the nrPolarDecode
(5G Toolbox) function. You can
choose a list length of 2, 4, or 8. Increasing the list length increases the error correction
performance but uses more hardware resources and increases the decoding latency. You can
improve decoding performance for DCI messages by using the optional RNTI
port to specify an expected RNTI value.
This block also performs CRC decoding of the message, equivalent to the nrCRCDecode
(5G Toolbox) function. The block selects the CRC length based on your
specification of the link direction and the K value you provide. The
block detects DCI messages from the values of K and
E, and automatically prepends 1s to the message, equivalent to the
padCRC
input argument of the nrPolarDecode
(5G Toolbox) function.
Because the latency of the polar decoding operation can vary, the block provides an output signal, nextFrame, that indicates when the block is ready to accept new inputs. For more details, see the Latency section of this page.
Examples
Polar Encode and Decode of Streaming Samples
Simulate NR Polar Encode and Decode blocks and compare the hardware-optimized results with results from 5G Toolbox™ functions.
Ports
Input
data — Input sample
scalar
Input sample, specified as a scalar log-likelihood ratio (LLR). The block supports builtin types, and signed fixed-point values with a wordlength of 4 to 16 bits.
The software supports double
and
single
data types for simulation, but not for HDL code generation.
Data Types: fixed point
| int8
| int16
| double
| single
ctrl — Control signals accompanying sample stream
samplecontrol
bus
Control signals accompanying the sample stream, specified as a
samplecontrol
bus. The bus includes the start
,
end
, and valid
control signals, which indicate the
boundaries of the frame and the validity of the samples.
start
— Indicates the start of the input frameend
— Indicates the end of the input framevalid
— Indicates that the data on the input data port is valid
For more details, see Sample Control Bus.
Data Types: bus
K — Length of information block in bits
positive integer
Length of information block in bits, specified as a positive integer. For downlink messages, K must be in the range 36 to 164. For uplink messages, K must be in the range 18 to 25 or 31 to 1023.
Dependencies
To enable this port, set the Configuration source parameter
to Input port
.
Data Types: fixdt(0,10,0)
E — Rate-matched output length in bits
scalar positive integer
Rate-matched output length in bits, specified as a scalar positive integer. Specify a value for E that is greater than K and less than or equal to 8192.
Dependencies
To enable this port, set the Configuration source parameter
to Input port
.
Data Types: fixdt(0,14,0)
RNTI — Target RNTI
16-bit unsigned integer
Target RNTI, specified as a 16-bit unsigned integer. This value increases decoding accuracy for DCI messages. For example, when decoding SIB1 DCI messages, enable this port and set the target RNTI to 65,535. For MIB decoding, you can disable this port or set the target RNTI to 0.
Dependencies
To enable this port, set Link direction to
Downlink
and select the Enable target RNTI
port parameter.
Data Types: uint16
Output
data — Decoded data bit
scalar
Decoded data bit, returned as a scalar. The output message length is
A bits, where A =
K – CRCLen
. For downlink messages,
CRCLen is 24. For uplink messages, CRCLen is
11 or 6, as defined by the 5G NR standard.
Data Types: fixdt(0,1,0)
| Boolean
| double
| single
Complex Number Support: Yes
ctrl — Control signals accompanying sample stream
samplecontrol
bus
Control signals accompanying the sample stream, returned as a samplecontrol
bus. The bus includes the start
, end
, and
valid
control signals, which indicate the boundaries of the frame
and the validity of the samples.
start
— Indicates the start of the output frameend
— Indicates the end of the output framevalid
— Indicates that the data on the output data port is valid
For more details, see Sample Control Bus.
Data Types: bus
err — CRC result
scalar
CRC result, returned as a scalar. If you clear the Full checksum
mismatch parameter, this value is a Boolean. When you select the
Full checksum mismatch parameter, this value is a
ufix24
scalar for downlink messages and a
ufix11
or ufix6
scalar for uplink messages.
If you enable the RNTI port, the block compares the internal CRC checksum against the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.
Data Types: Boolean
| ufix11
| ufix24
nextFrame — Ready for new inputs
scalar
The block sets this signal to 1
when the block is ready to accept the start
of the next frame. If the block receives an input start signal
while nextFrame is 0
, the block discards the
frame in progress and begins processing the new data.
For more information, see Using the nextFrame Output Signal.
Data Types: Boolean
Parameters
Link direction — Direction of 5G NR link
Downlink
(default) | Uplink
Direction of 5G NR link, specified as Downlink
or
Uplink
. When you choose
Downlink
, the block performs deinterleaving, as specified in
the 5G NR standard. When you select Uplink
, the block omits
the deinterleaving logic.
Downlink decoding uses a CRC length of 24 bits. Uplink decoding uses a CRC length of 6 bits (K in the range 18 to 25) or 11 bits (K in the range 31 to 1023).
List length — Number of decoding paths
2
(default) | 4
| 8
This parameter is the maximum number of parallel paths maintained in the decoding
tree. Increasing the list length increases the error correction performance but uses
more hardware resources and increases the decoding latency. When you use list lengths of
4
and 8
, the latency can vary
depending on the SNR of the input signal, and is not constant for given values of
K and E. Use the
nextFrame output signal to determine when the block
is available for a new message.
Configuration source — Source for K and E
Property
(default) | Input port
Select Input port
to enable the K
and E ports. Select Property
to use the
Message length (K) and Rate-matched length
(E) parameters.
Message length (K) — Length of information block in bits
56
(default) | positive integer
For downlink messages, K must be in the range 36 to 164. For uplink messages, K must be in the range 18 to 25 or 31 to 1023.
Dependencies
To enable this parameter, set the Configuration source
parameter to Property
.
Rate-matched length (E) — Rate-matched output length in bits
864
(default) | positive integer
Specify a value for E that is greater than K and less than or equal to 8192.
Dependencies
To enable this parameter, set the Configuration source
parameter to Property
.
Full checksum mismatch — Return checksum from final decoding stage
off
(default) | on
When you clear this parameter, the block returns a Boolean scalar on the err port that indicates whether the CRC was successful. When you select this parameter, the block returns the full CRC checksum on the err port. If your design decodes DCI messages and makes use of the RNTI remainder, select this parameter.
If you enable the RNTI port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.
The nrPolarDecode
(5G Toolbox) function
returns a decoded message that includes the CRC bits. This block returns the decoded
message without the CRC bits, and returns the CRC status separately on the
err port. This behavior is equivalent to calling the nrCRCDecode
(5G Toolbox) function after
using the nrPolarDecode
function. Not recomputing the CRC bits
saves hardware latency and resources.
Enable target RNTI port — Optional port to specify target RNTI value
off
(default) | on
Select this parameter to enable the RNTI input port. Providing a target RNTI value increases decoding accuracy for DCI messages. For example, when decoding SIB1 DCI messages, enable this port and set the target RNTI to 65535. For MIB decoding, you can disable this port or set the target RNTI to 0.
Enabling this port also changes how the block computes the err output port value. If you enable the RNTI port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0.
Dependencies
To enable this parameter, set the Link direction parameter to
Downlink
.
Algorithms
This block implements a CRC-aided successive-cancellation list decoder. It can use a list
length of 2, 4, or 8 as configured by the List length parameter. The
decoder iterates over all LLRs in the tree to reach a decision for a bit and then uses that
decision to decode the next bit. The deinterleaving step is included only when you set the
Link direction parameter to Downlink
.
This diagram shows the architecture of the polar decoder.
The block uses the Configuration stage when the K and
E input port values change. The block computes the locations of the
information bits and passes them to the Decision stage. Because the mapping patterns are
computed as needed, rather than stored in hardware, the block supports all
K and E values within the supported range. The
Configuration stage also computes the interleave pattern when you set the Link
direction parameter to Downlink
.
When you set the Configuration source parameter to
Property
, the K and E
values are constants, so the decoder does not implement the Configuration stage. In this case,
the block includes static lookup tables that contain the precomputed configuration.
To minimize computations for each decode, the Tree Memory stores the probability of each node being a one or a zero. Each iteration updates only the LLRs that have changed. The Core decoding stage uses the LLR update equations from [3].
The Decision stage checks the LLR value against the expected locations of information bits and frozen bits and returns a hard decision to the Tree Memory. If the bit is expected to be frozen, the Decision stage returns a hard decision of zero and updates the probabilities of related paths. The Path Memory reconstructs the most likely paths from the hard decision results and passes the paths and scores to the next stage.
Tree Memory and Path Memory contain up to List length paths. If all frozen bits on a path are zeros (as expected), then the block discards the other parallel paths. This optimization results in variable latency in the decoding operation for list lengths greater than two. For signals with a high noise level, the decoder must increase the number of parallel paths and the cycles for decoding. For low-noise signals, the decoder can use only two parallel paths and reduce the decoding latency.
The Path Selection stage computes the CRC for all paths and then chooses the path that passes the CRC. When you use the RNTI input port, the block compares the internal CRC checksum with the target RNTI value. Otherwise, the block compares the CRC checksum against a value of 0. If all CRCs fail, the block returns the path that has the higher score.
This implementation matches the performance of the 5G Toolbox™ function nrPolarDecode
(5G Toolbox) with the same list
length. Because the block uses fixed-point internal types, any differences are a result of
quantization.
This plot shows the block error rate performance with the three possible list lengths. The input is 6-bit LLR values.
Latency
The table shows example latencies of the NR Polar Decoder block for each N, when decoding for uplink and downlink channels with a list length of two. N is the power-of-two encoded message length determined from the values of K and E.
N | Uplink Latency | Downlink Latency |
---|---|---|
32 | 349 | Not applicable |
64 | 576 | 677 |
128 | 1034 | 1135 |
256 | 1961 | 2062 |
512 | 3896 | 3996 |
1024 | 8202 | Not applicable |
The exact latency varies based on the values of K and E. The latency is longer for frames where the K and E input port values change and the block must compute the new configuration.
Increasing the list length increases the latency. List lengths greater than two do not have a fixed latency for given K and E values. To provide minimal latency, the block traces more than 2 paths only when the frozen bits are not decoded as zeroes. This optimization means that the latency can increase with the SNR of the input signal. For example, for a list length of 4 and N=512, the best case latency is 4108 cycles, and the worst case latency is 4985 cycles.
Because the latency varies, use the output nextFrame control signal to determine when the block is ready for a new input frame.
This waveform shows how the latency varies with the K and E input port values for a list length of two. When the input K and E port values are 132 and 256, the block has a latency of 2272 cycles from the input start signal to the output nextFrame. When the K and E port values change to 54 and 124, the latency changes to 1234 cycles.
This waveform shows how the latency can vary with the noise level of the input signal
when using a list length of 4. The block has K and
E parameter values of 132 and 256 and Link
direction parameter set to Uplink
. The first message
has a latency of 2533 cycles. This message data is generated with low noise and has few bit
errors. In this case, the decoder can collapse to two paths and produce a result in fewer
cycles than when decoding a noisier signal. The second message is generated with a high
noise level, and the decoding latency increases to 3174 cycles. When the input signal has
more bit errors, the decoder must trace more paths to determine the correct bits.
Performance
This table shows the resource and performance data synthesis results of the block when
it is configured with K and E as input ports, the
Link direction parameter set to Downlink
,
and 6-bit input LLRs. The generated HDL is targeted to an AMD®
Zynq®-7000 ZC706 evaluation board. The design achieves a clock frequency of 250
MHz.
Resource | List Length of 2 | List Length of 4 | List Length of 8 |
---|---|---|---|
Slice LUTs | 3048 | 4725 | 9963 |
Slice Registers | 2509 | 3804 | 6471 |
DSP48 | 0 | 0 | 0 |
Block RAM | 4.5 | 5.5 | 6.0 |
The block uses fewer resources when K and E
are specified by parameters. When you set the Link direction parameter
to Uplink
, the block uses more memory to accommodate larger
message sizes.
References
[1] 3GPP TS 38.212. "NR; Physical channels and modulation." 3rd Generation Partnership Project; Technical Specification Group Radio Access Network. URL: https://www.3gpp.org.
[2] Arikan, Erdal. "Channel Polarization: A Method for Constructing Capacity-Achieving Codes for Symmetric Binary-Input Memoryless Channels." IEEE Transactions on Information Theory 55, no. 7 (July 2009): 3051–73. https://doi.org/10.1109/TIT.2009.2021379.
[3] Balatsoukas-Stimming, Alexios, Mani Bastani Parizi, and Andreas Burg. "LLR-Based Successive Cancellation List Decoding of Polar Codes." IEEE Transactions on Signal Processing 63, no. 19 (October 2015): 5165–79. https://doi.org/10.1109/TSP.2015.2439211.
Extended Capabilities
C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.
This block supports C/C++ code generation for Simulink® accelerator and rapid accelerator modes and for DPI component generation.
HDL Code Generation
Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.
HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.
This block has one default HDL architecture.
ConstrainedOutputPipeline | Number of registers to place at
the outputs by moving existing delays within your design. Distributed
pipelining does not redistribute these registers. The default is
|
InputPipeline | Number of input pipeline stages
to insert in the generated code. Distributed pipelining and constrained
output pipelining can move these registers. The default is
|
OutputPipeline | Number of output pipeline stages
to insert in the generated code. Distributed pipelining and constrained
output pipelining can move these registers. The default is
|
You cannot generate HDL for this block inside a Resettable Synchronous Subsystem (HDL Coder).
Version History
Introduced in R2020a
See Also
nrPolarDecode
(5G Toolbox) | NR Polar Encoder
MATLAB Command
You clicked a link that corresponds to this MATLAB command:
Run the command by entering it in the MATLAB Command Window. Web browsers do not support MATLAB commands.
Select a Web Site
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .
You can also select a web site from the following list:
How to Get Best Site Performance
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Americas
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)