decode and recover message from rs codeword according to ccsds standard

since r2021b

libraries:
wireless hdl toolbox / error detection and correction

description

the ccsds rs decoder block decodes and recovers a message from a reed-solomon (rs) codeword according to the consultative committee for space data systems (ccsds) standard [1]. the block accepts codeword data and a samplecontrol bus and outputs a decoded message data, a samplecontrol bus, control signals that indicate whether the decoded data is corrupted and whether the block is ready to accept data, and an optional signal to provide the number of corrected errors. the block provides an architecture suitable for hdl code generation and hardware deployment.

because the latency of the block varies, the block provides the output port nextframe that indicates when the block is ready to accept new input codeword data. for more details about the latency of the block, see the algorithm section.

the block also supports shortened message lengths. you can use this block in a ccsds receiver for satellite communication.

examples

ports

input

data — input codeword data
integer in the range from 0 to 255

input codeword data, specified as an integer in the range from 0 to 255. this integer represents a symbol.

the block accepts a maximum value of 255 x i and a minimum value of (255 – k 1) x i for the number of input codeword symbols per frame. k is the message length specified by the message length (k) parameter. i is the interleaving depth specified by the interleaving depth (i) parameter. the number of input codeword symbols must be an integral multiple of i.

the block supports back-to-back input frames for:

full-length codes when you set message length (k) to 223 and interleaving depth (i) to 3, 4, 5, or 8
full-length codes when you set message length (k) to 239 and interleaving depth (i) to 1, 2, 3, 4, 5, or 8

the block does not support back-to-back input frames for:

shortened codes for any of the message length (k) and interleaving depth (i) values
full-length codes when you set message length (k) to 223 and interleaving depth (i) to 1 or 2

double and single data types are allowed for simulation, but not for hdl code generation. for hdl code generation, specify this value in fixdt(0,8,0) or uint8 format.

data types: double | single | uint8 | fixdt(0,8,0)

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 frame
end — indicates the end of the input frame
valid — indicates that the data on the input data port is valid

for more details, see .

data types: bus

output

data — decoded message data
integer in the range from 0 to 255

decoded message data, returned as an integer in the range from 0 to 255. the output data type is the same as the input data type.

the block outputs n – (255 – k) x i number of decoded message symbols for n number of input codeword symbols. k is the message length specified by the message length (k) parameter and i is the interleaving depth specified by the interleaving depth (i) parameter.

data types: double | single | uint8 | fixdt(0,8,0)

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 frame
end — indicates the end of the output frame
valid — indicates that the data on the output data port is valid

for more details, see .

data types: bus

err — indication of corruption in output data
boolean scalar

indication of corruption in the output data, returned as a boolean scalar.

when this value is 1, the output contains errors. when this value is 0, the output contains zero errors.

if the number of symbol errors in the input codeword data is greater than (255 - k) x i / 2, the block outputs data without correcting the errors and sets the err port to 1 to indicate that errors that cannot be corrected exist in the input codeword data. k is the message length specified by message length (k) parameter.

data types: boolean

nextframe — block ready indicator
boolean scalar

block ready indicator, returned as a boolean scalar.

the block sets this signal to 1 (true) when the block is ready to accept the start of the next frame. if the block receives an input ctrl.start signal while nextframe is 0 (false), the block discards the frame in progress and begins processing the new data.

data types: boolean

numcorrerr — number of corrected errors
nonnegative scalar

number of corrected errors, returned as a nonnegative scalar.

the maximum number of errors that the block can correct is equal to (255 – k) x i / 2. if the number of errors in the input codeword data is greater than (255 – k) x i / 2, the block outputs data without correcting the errors and sets the numcorrerr port to 0 to indicate that none of those errors can be corrected.

the block sets the numcorrerr port to 0 when the err port is 1.

dependencies

to enable this port, select the output number of corrected symbol errors parameter.

data types: uint8

parameters

message length (k) — length of message
`223` (default) | `239`

select the message length.

interleaving depth (i) — depth of interleaving
`1` (default) | `2` | `3` | `4` | `5` | `8`

select the interleaving depth.

output number of corrected symbol errors — number of corrected symbol errors
`off` (default) | `on`

select this parameter to enable the numcorrerr output port. this port outputs the number of corrected errors.

algorithms

this block diagram shows the high-level overview of the ccsds rs decoder block and its operation when you set the interleaving depth (i) parameter to 4. this operation is a parallel implementation and contains logic that is equivalent to four independent rs decoders because the specified interleaving depth is 4.

the d2c block converts the input dual basis codeword symbols to conventional basis codeword symbols and sends them for decoding. simultaneously, the d2c block sends the conventional basis codeword symbols to the ram block. the ram block stores these symbols for correction. the switch (s1) interleaves the conventional basis symbols and sends them to the respective rs decoding logic blocks. each rs decoding logic block calculates syndrome values, determines the error location polynomial using the berlekamp-massey algorithm, and finds error locations and magnitudes using chien search [4] and forney [5] algorithms, respectively. for information about the berlekamp-massey algorithm, see .

the error magnitudes from these rs decoding logic blocks are xored with their respective input codeword symbols that are stored in the ram block by using the switch (s2) and the calculated error locations to obtain the corrected message symbols. the c2d block converts the corrected conventional basis symbols back to dual basis symbols.

ccsds rs decoder block architecture diagram

latency

the latency between valid input data and the corresponding valid output data depends on the interleaving depth and the time the block takes to calculate error locator polynomials and find error locations and magnitudes. the time for which the nextframe output port value remains 0 depends on the processing time of the block. the processing time of the block is equal to the sum of the time the block takes to compute error locating polynomials (elptime) and find error locations and error magnitudes (convtime). this equation represents the processing time.

$\begin{array}{l} p r o c e s s i n g_t i m e = e l p t i m e c o n v t i m e \\ = 4 \times t t (2 \times t 1) d \end{array}$

t is the number of errors an rs code can correct and is equal to (255 – k)/2. k is the message length specified by the message length (k) parameter and d is the number of pipeline delays, which is fixed to 10 for this block.

the latency of the block is 2^{ceil
(log₂(processing_time
256))} 255 x i 1. i is interleaving depth specified by the interleaving depth (i) parameter.

this figure shows a sample output and latency of the ccsds rs decoder block when you set the message length (k) and interleaving depth (i) parameter values to 223 and 4, respectively. in this case, the processing time is less than the 255 x interleaving depth (i), so the block provides support for continuous input frames. the latency of the block is 2045 clock cycles.

performance

the performance of the synthesized hdl code varies with the target and synthesis options. it also varies based on the message length and interleaving depth.

this table shows the resource and performance data synthesis results when you specify the input in fixdt(0,8,0) format and set the message length (k) and interleaving depth (i) parameter values to 223 and 4, respectively. the generated hdl is targeted to the xilinx^® zynq^®- 7000 zc706 evaluation board. the design achieves a clock frequency of 132 mhz.

resource	number used
luts	16056
registers	12397
dsps	0
block rams	17

references

[1] tm synchronization and channel coding. recommendation for space data system standards. ccsds 131.0-b-3. blue book. issue 3. washington, d.c.: ccsds, september 2017.

[2] tm synchronization and channel coding. summary of concept and rationale ccsds 130.1-g-3. green book. issue 3, june 2020.

[3] stephen b. wicker. error control systems for digital communication and storage. prentice hall 1995.

[4] chien, r. “cyclic decoding procedures for bose- chaudhuri-hocquenghem codes.” ieee transactions on information theory 10, no. 4 (october 1964): 357–63. .

[5] forney, g. “on decoding bch codes.” ieee transactions on information theory 11, no. 4 (october 1965): 549–57. .

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 verilog and vhdl code for fpga and asic designs using hdl coder™.

hdl coder™ provides additional configuration options that affect hdl implementation and synthesized logic.

hdl architecture

this block has one default hdl architecture.

hdl block properties

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 `0`. for more details, see (hdl coder).
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 `0`. for more details, see (hdl coder).
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 `0`. for more details, see (hdl coder).

restrictions

you cannot generate hdl for this block inside a (hdl coder).

version history

introduced in r2021b

decode and recover message from rs codeword according to ccsds standard -凯发k8网页登录

description

examples