4.1. 5G Polar IP Signals
All signals are synchronous to clk.
Encoder
| Signal | Width | Direction | Description |
|---|---|---|---|
| clk | 1 | Input | Clock. |
| rstn | 1 | Input | Active-low synchronous reset. |
| param_req | 1 | Output | Request input parameters. The IP asserts this signal after reset. You should provide input parameters when the IP asserts this signal. The IP does not accept input data until you provide input parameters. |
| param_ready | 1 | Output | Indicates that the IP is ready to accept input parameters. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP takes the valid signal (param_valid) in the next clock cycle. The IP asserts this signal before each code block. The IP asserts this signal when the IP asserts param_req. If the IP asserts this signal but not param_req, you can optionally provide input parameters. If you do not provide input parameters, the IP keeps the previous parameters. |
| param_valid | 1 | Input | Assert when incoming packet parameter signals are valid. Assert this signal for one clock cycle when param_ready is asserted. If asserted for more than one cycle, the IP takes only the parameters at the first cycle. |
| param_len | 3 | Input | 1:N=32 2:N=64 3:N=128 4:N=256 5:N=512 6:N=1024 |
| param_crc | 3 | Input | 0:CRC OFF 1:CRC24a 2:CRC24b 3:CRC24c 4:CRC16 5:CRC11 6:CRC6 7:CRC24c in DCI format |
| param_il | 1 | Input | 0:deinterleaving off 1:deinterleaving on |
| param_fro | 1024 | Input | Indicates frozen bit location. param_fro[i]==1 indicates bit i is a frozen bit. param_fro[1023:N] are ignored when N<1024. |
| param_pc | 28 | Input | Indicates parity check bit location. param_pc[i]==1 indicates the i-th nonfrozen bit is a parity check bit. param_pc[j] is ignored if the number of nonfrozen bits is less than j. k-th nonfrozen bit is never a parity check bit for all k>=28. |
| param_rnti | 16 | Input | Indicates the radio network temporary identifier (RNTI) bits. When you do not select CRC type as CRC24c in DCI format (3’d7), the IP ignores the RNTI. |
| sink_ready | 1 | Output | Indicates that the IP can take an input packet. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP takes the valid signal (sink_valid) in the next clock cycle. When asserted, this signal keeps asserted until the end of the input packet. |
| sink_valid | 1 | Input | Assert when incoming packet data signal is valid. The IP accepts this signal only when the IP asserts sink_ready in the previous clock cycle. When this signal is low, the IP ignores sink_sop, eop, and data. Do not assert this signal at the next clock cycle of a valid EOP, as the IP ignores it. The IP does not accept SOP immediately after EOP. Do not assert this signal at the next clock cycle of param_valid, as the IP ignores it. The IP does not accept SOP immediatley after a new parameter setup. If the IP asserts both param_ready and sink_ready on the previous clock cycle and you assert both param_valid and sink_valid on the current clock cycle, the IP only acepts param_valid and ignores sink_valid. |
| sink_sop | 1 | Input | Indicates the start of an incoming packet. The IP starts to accept incoming packets when you assert this signal. Assert this signal with the first input data. |
| sink_eop | 1 | Input | Indicates the end of an incoming packet. Assert this signal with the last input data. |
| sink_data | 1 | Input | Frame data input. |
| source_valid | 1 | Output | The IP asserts source_valid when dumping an output packet, indicating the outputs are valid. |
| source_data | 1024 | Output | Encoded data output. The IP sends an N-bit codeword at source_data[N-1:0]. |
Figure 16. Encoder timing diagram of packet input after reset Input length =100. Gray shading represents don’t care.
Figure 17. Timing diagram of packet input after a previous packetWith a new set of input parameters for the next packet. This figure applies to both encoders and decoders.
Figure 18. Timing diagram of packet input after a previous packetWithout a new set of input parameters for the next packet. This figure applies to both encoders and decoders.
Figure 19. Encoder timing diagram of packet output
Decoder
| Signal | Width | Direction | Description |
|---|---|---|---|
| Clk | 1 | Input | Clock. |
| rstn | 1 | Input | Active-low synchronous reset. |
| param_req | 1 | Output | Request input parameters. The IP asserts this signal after reset. You should provide input parameters when the IP asserts this signal. The IP does not accept input data until you provide input parameters. |
| param_ready | 1 | Output | The IP can accept input parameters. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP accepts the valid signal (param_valid) in the next clock cycle. The IP asserts this signal before each code block. The IP asserts this signal when it asserts param_req. If the IP asserts this signal but not param_req, you can optionally provide input parameters. If you provide no input parameters, the IP keeps the previous parameters. |
| param_valid | 1 | Input | Assert when incoming packet parameter signals are valid. Assert this signal for one clock cycle when the IP asserts param_ready. If asserted for more than one cycle, the IP accepts only the parameters at the first cycle. |
| param_len | 3 | Input | 1:N=32 2:N=64 3:N=128 4:N=256 5:N=512 6:N=1024 |
| param_crc | 3 | Input | 0:CRC OFF 1:CRC24a 2:CRC24b 3:CRC24c 4:CRC16 5:CRC11 6:CRC6 7:CRC24c in DCI format |
| param_il | 1 | Input | 0:deinterleaving off 1:deinterleaving on |
| param_fro | 1024 | Input | Indicate frozen bit location. param_fro[i]==1 indicates bit i is a frozen bit. param_fro[1023:N] are ignored when N<1024. |
| param_pc | 28 | Input | Indicate parity check bit location. param_pc[i]==1 indicates the i-th nonfrozen bit is a parity check bit. param_pc[j] is ignored if the number of nonfrozen bits is less than j. k-th nonfrozen bit is never a parity check bit for all k>=28. |
| param_rnti | 16 | Input | Indicates the RNTI bits. When you do not select CRC type as CRC24c in DCI format (3’d7), the IP ignores the RNTI. |
| sink_ready | 1 | Output | Indicates that the IP can accept an input packet. The ready latency is 1 clock cycle. If the IP asserts this signal, the IP accepts the valid signal (sink_valid) in the next clock cycle. When asserted, this signal keeps asserted until the end of the input packet. |
| sink_valid | 1 | Input | Assert when incoming packet data signal is valid. The IP accepts this signal only when the IP asserts sink_ready in the previous clock cycle. When this signal is low, the IP ignores sink_sop/eop/data. Do not assert this signal at the next clock cycle of a valid EOP, as the IP ignores it. The IP does not accept SOP immediately after EOP. Do not assert this signal at the next clock cycle of param_valid, as the IP ignores it. The IP does not accept SOP immediatley after a new parameter setup. If the IP asserts both param_ready and sink_ready on the previous clock cycle and you assert both param_valid are sink_valid on the current clock cycle, the IP only acepts param_valid and ignores sink_valid. |
| sink_sop | 1 | Input | Indicates the start of an incoming packet. The IP starts to accept incoming packet when you assert this signal. Assert this signal for one cycle only. |
| sink_eop | 1 | Input | Indicates the end of an incoming packet. Assert this signal with the last input data. Assert this signal for one cycle only. |
| sink_data | 64*LLR_BIT (where LLR_BIT = 6) | Input | Frame data input. Each LLR is LLR_BIT-bit long. You should send 64 LLRs in each cycle. Each packet contains N LLRs of a frame, taking N/64 cycles. Send LLR[63]-LLR[0] in the first cycle; LLR[127]-LLR[64] in the second cycle, etc. When N=32, send LLR[31]-LLR[0] in sink_data[32*LLR_BIT-1:0].
2’s compliment format, but exclude the extreme negative values. LLR ranges from –(2LLR_BIT-1-1) to +(2LLR_BIT-1-1). Saturate the value –2LLR_BIT-1 to –(2LLR_BIT-1-1) before providing to the IP. Refer to Table 12 |
| source_ready | 1 | Input | Assert when you can accept an outgoing packet. The ready latency is 1 clock cycle. When you assert this signal, the IP provides the valid signal (source_valid) in the next clock cycle, if output data is available from the IP. |
| source_valid | 1 | Output | Asserted when dumping an output packet, indicating the outputs are valid. The IP can only assert this signal if it receives source_ready in the previous clock cycle. |
| source_sop | 1 | Output | Indicates the start of an output packet. After decoding finishes and when the downstream is ready, the IP asserts this signal when it provides the first cycle of the output data. |
| source_eop | 1 | Output | Indicates the end of an output packet. The IP asserts this signal when it provides the last cycle of the output data. |
| source_data | 64 | Output | Decoded data output. The IP sends out K output bits, where K = A + L . Where: The IP sends out[63:0] in the same cycle as source_sop. The IP sends out[127:64] in the cycle after. If K does not divide 64, the IP sends out[K-1: K-(K mod 64)] in the same cycle as source_eop, located at source_data[(K mod 64)-1:0]. When K<64, out[K-1:0] are located at source_data[K-1:0]. |
| metric_pass | 1 | Output | Indicates CRC check result. 0: CRC is OFF or CRC check failed 1: CRC check passed. This value is valid from source_sop to source_eop and the IP does not change it during this period |
| Binary | Decimal | Meaning | Binary | Decimal | Meaning |
|---|---|---|---|---|---|
| 011111 | +31 | Strongest 0 | 100001 | -31 | Strongest 1 |
| 000001 | +1 | Weakest 0 | 111111 | -1 | Weakest 1 |
| 000000 | 0 | Unknown | 100000 | -32 | Invalid |
Final hard decision of an LLR is the sign bit (MSB) of the LLR. The hard decision of 0b000000 is 0.
Do not feed -32 as an LLR, instead, saturate it to -31.
Figure 20. Decoder timing diagram of packet input after reset Input length =1,024
Figure 21. Decoder timing diagram of packet output Output length = 600
Refer to Figure 17 for decoder packet input after a previous packet with a new set of input parameters for the next packet.
Refer to Figure 18 for decoder packet input after a previous packet without a new set of input parameters for the next packet.
| Signal | Width | Direction | Description |
|---|---|---|---|
| clk | 1 | input | Clock. |
| rstn | 1 | input | Active-low synchronous reset. |
| param_req | 1 | output | Request input parameters. The IP asserts this signal after reset. Provide input parameters when this signal is asserted. Input data is not ready until you provide input parameters. |
| param_ready | 1 | output | The IP is ready to take input parameters. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP accepts the valid signal (param_valid) in the next clock cycle. The IP asserts this signal before each code block. The IP asserts this signal when param_req is asserted. If the IP asserts this signal but not param_req, you can optionally provide input parameters. If you do not provide input parameters, the IP keeps the previous parameters. |
| param_valid | 1 | input | Assert when incoming packet parameter signals are valid. Assert this signal for one clock cycle when param_ready is asserted. If asserted for more than one cycle, the IP takes only the parameters at the first cycle. |
| param_crc | 3 | input | Select from either 3:CRC24c or 7:CRC24c in DCI format |
| param_rnti | 16 | Input | Indicates RNTI bits. When CRC type is not selected as CRC24c in DCI format (3’d7), the IP ignores RNTI. |
| param_A | 8 | input | Indicates the number of message bits before CRC attachment. Valid range is [12, 140]. |
| param_E | 13 | input | Indicates the number of bits after rate matching. Valid range is [36, 8192]. Set param_E =0 for length 8192, because 8192 overflows to 0 in 13-bit number reprenstations. |
| sink_ready | 1 | output | Indicates that the IP is ready to take an input packet. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP takes the valid signal (sink_valid) in the next clock cycle. When asserted, this signal keeps asserted until the end of the input packet. |
| sink_valid | 1 | input | Assert when incoming packet data signal is valid. This signal is accepted only when sink_ready is asserted in the previous clock cycle. When this signal is low, the IP ignores sink_sop, eop, data. Do not assert this signal at the next clock cycle of a valid EOP, otherwise the IP ignores it. The IP does not accept SOP right after EOP. Do not assert this signal at the next clock cycle of param_valid, otherwise the IP ignores it. The IP does not accept SOP after a new parameter setup. If the IP asserts both param_ready and sink_ready at the previous clock cycle, and you assert both param_valid and sink_valid at the current clock cycle, the IP only accepts param_valid. It ignores sink_valid. |
| sink_sop | 1 | input | Indicates the start of an incoming packet. The system starts to accept incoming packet when you assert this signal. Assert this signal with the first input data. |
| sink_eop | 1 | input | Indicates the end of an incoming packet. Assert this signal with the last input data. |
| sink_data | 1 | input | Frame data input. |
| source_valid | 1 | output | Asserted when dumping an output packet, indicating the outputs are valid. |
| source_data | 1024 | output | Encoded data output. N-bit codeword is sent at source_data[N-1:0]. |
The downlink encoder with bit allocation has the same input and output timing as of the encoder.
| Signal | Width | Direction | Description |
|---|---|---|---|
| clk | 1 | input | Clock.
|
| rstn | 1 | input | Active-low synchronous reset. |
| param_req | 1 | output | Request input parameters. The IP assert this signal after reset. Provide input parameters when yopu assert both this signal and param_ready. The IP is not ready to accept input data until you provide input parameters. |
| param_ready | 1 | output | The IP is ready to take input parameters. Ready latency is 1 clock cycle. If the IP asserts this signal, the IP accepts the valid signal (param_valid) in the next clock cycle. The IP asserts this signal before each code block. If the IP asserts this signal but not param_req, you can optionally provide input parameters. If you do not provide input parameters, the IP keeps the previous parameters. |
| param_valid | 1 | input | Assert when incoming packet parameter signals are valid. Assert this signal for one clock cycle when param_ready is asserted. If asserted for more than one cycle, the IP only accepts the parameters at the first cycle. |
| param_A | 10 | input | Indicates the number of message bits before CRC attachment. Valid range is [12, 1012]. |
| param_E | 13 | input | Indicates the number of bits after rate matching. Valid range is [18, 8192]. Set param_E =0 for length 8192, because 8192 overflows to 0 in 13-bit number reprenstations. |
| sink_ready | 1 | output | Indicates that the IP is ready to accept an input packet. Ready latency is 1 clock cycle. If the IP asserts this signal, it accepts the valid signal (sink_valid) in the next clock cycle. When asserted, this signal keeps asserted until the end of the input packet. |
| sink_valid | 1 | input | Assert when incoming packet data signal is valid. The IP accepts this signal only when sink_ready is asserted in the previous clock cycle. When this signal is low, the IP ignores sink_sop, eop, data. Do not assert this signal at the next clock cycle of a valid EOP, otherwise the IP ignores it. The IP does not accept SOP after EOP. Do not assert this signal at the next clock cycle of param_valid, otherwise the IP ignores it. The IP does not accept SOP after new parameter setup. If the IP asserts both param_ready and sink_ready at the previous clock cycle, and you assert both param_valid are sink_valid at the current clock cycle, the current packet uses the old parameter. The IP applies the new parameter from the next packet. |
| sink_sop | 1 | input | Indicates the start of an incoming packet. The system starts to accept incoming packet when you assert this signal. Assert this signal for one cycle is enough. |
| sink_eop | 1 | input | Indicates the end of an incoming packet. Assert this signal with the last input data. Assert this signal for one cycle is enough.
For DV use only:
|
| sink_data | 64*LLR_BIT | input | Frame data input. Each LLR is LLR_BIT-bit long. You should send 64 LLRs in each cycle. Each packet contains N LLRs of a frame, taking N/64 cycles. Send LLR[63]-LLR[0] in the first cycle; LLR[127]-LLR[64] in the second cycle, etc. When N=32, send LLR[31]-LLR[0] in sink_data[32*LLR_BIT-1:0]. 2’s compliment format, but exclude the extreme negative value. LLR ranges from –(2LLR_BIT-1-1) to +(2LLR_BIT-1-1). Saturate the value –2LLR_BIT-1 to –(2LLR_BIT-1-1) before providing to the IP. |
| source_ready | 1 | input | Asserted by the downstream when it is ready to take an outgoing packet. Ready latency is 1 clock cycle. If you assert this signal, the IP accepts the the valid signal (source_valid), if the IP asserts it in the next clock cycle. |
| source_valid | 1 | output | Asserted when dumping an output packet, indicating the outputs are valid. This signal can only be asserted if source_ready is asserted in the previous clock cycle. |
| source_sop | 1 | output | Indicates the start of an output packet. After decoding finishes and when the downstream is ready, the IP asserts this signal for one cycle, at the first cycle when the output data is dumped. |
| source_eop | 1 | output | Indicate the end of an output packet. The IP asserts this signal at the last cycle when the output data is dumped. |
| source_data | 64 | output | Decoded data output. The IP sends K output bits using ⌈K/64⌉ cycles, where K = A+L The IP sends out[63:0] in the same cycle as source_sop. The IP sends out[127:64] in the cycle after. If K does not divide by 64, the IP sends out[K-1: K-(K mod 64)] in the same cycle as source_eop, located at source_data[(K mod 64)-1:0]. When K<64, out[K-1:0] are located at source_data[K-1:0]. |
| metric_pass | 1 | output | Indicates CRC check result.
This value is valid and the IP hols it still from source_sop to source_eop. |
Figure 22. Decoder with bit allocation timing diagram of packet input after reset
Time t1, the IP deasserts param_ready, and param_req after it receives a param_valid. Then, the bit allocation starts to calculate.
Time t2, sink_ready is asserted, indicating the bit allocation calculation is compete and the decoder can accept a new packet.
Time t3, the IP asserts param_ready again when it receives a valid sink_sop, indicating the bit allocation is available for calculating a new set of parameters. However, do not provide a new parameter, if you want to keep using the existing parameter for a new packet.
Figure 23. Decoder with bit allocation timing diagram of packet input
Time t1, the packet keeps using the old parameter, when you provide a data packet without a parameter.
Time t2, you can provide a new parameter any time after a valid sink_sop (t1). The bit allocation starts calculating the new parameter, while the current packet keeps using the old paramerter. Meanwhile, the IP deasserts param_ready until it accepts this new parameter (t4).
Time t3, the IP asserts sink_ready again when the decoder completes processing the current packet and the bit allocation completes calculating the new parameter. The decoder latency hides the latency of the bit allocation, when the bit allocation completes earlier than the decoder.
Time t4, the IP asserts param_ready again when it receives a valid sink_sop, because it accepts the previously calculated parameter for this new packet and the bit allocation can start to calculate the next parameter. However, do not provide a new parameter, if you want to keep using the old parameter for the new packet.