[Question] Inquiry regarding matrix structure in ldpc_dvb_enc_hs_short_packed.svh vs DVB-S2 Standard

[Comestones]

Dear Author,

I am currently studying the LDPC implementation in your repository and have found it very helpful.

While analyzing the ldpc_dvb_enc_hs_short_packed.svh file, I visualized the parity check matrix generated from the cSHORT_HS_TAB array. I noticed that its structure differs significantly from the matrix generated strictly according to the DVB-S2 standard (using the standard A and B tables).

Specifically, the standard matrix typically shows a dense first column (characteristic of the IRA structure), whereas the matrix in your SV file exhibits a much more uniform distribution of "1"s.

My hypothesis is that a column permutation or reordering algorithm was applied to the standard matrix to optimize it for hardware implementation (e.g., to avoid memory bank conflicts in a layered decoder or to satisfy parallel processing constraints).

Could you please confirm if this is the case? If so, could you kindly share which specific reordering algorithm or logic was used?

I am currently trying to mathematically reconstruct the transformation process to verify the equivalence between the RTL implementation and the theoretical standard. Any insights or references regarding the matrix generation/conversion script would be greatly appreciated.

Thank you for your time and for sharing this excellent open-source work.

Best regards,

comestones

[dshekhalev]

Sorry I saw your message late. You are absolutely right, the data in these tables cannot be taken literally.

To transform DVB codes like QC-LDPC codes it is necessary to transpose (permutate) the parity bits submatrix.

I recommend you read Cedric Marchand "Implementation of an LDPC decoder for the DVB-S2,-T2 and -C2 standards" chapter "The LDPC code in the DVB-S2, -T2 and -C2 standards"->"Matrix construction" & Annex A "DVB-S2 matrices construction". It's better than my retelling it to you.

But the matrices I use are not just check matrices with transposed parity bits. It's optimized by row/column permutations for the control pipeline of a specific decoder implementation, take into account FPGA hardware capabilities and architectural optimizations of the used decoding algorithm.

All this is subordinate to one goal: to ensure the maximum clocking frequency of the decoding core with minimal wait-states and duration of the single decoding iteration.

I suppose that a "numerical hammer" at the triggered FPGA clocking with a wide word and no conflicts/deadlocks will win the layered decoder in terms of data bandwidth, even though it requires ~2 times fewer iterations for same code gain.

For such architecture, you will have to pay with the FPGA resources, but even the base core (with certain modifications not inside this repo) can provide bandwidth up to ~1.5-2.0 Gbps with a good number of iterations >15-20.