OpenCores

Project maintainers

Details

Name: dvb_s2_ldpc_decoder
Created: Nov 7, 2009
Updated: Aug 6, 2018
SVN Updated: Mar 30, 2010
SVN: Browse
Latest version: download (might take a bit to start...)
Statistics: View
Bugs: 2 reported / 0 solved
Star5you like it: star it!

Other project properties

Category:Arithmetic core
Language:Verilog
Development status:Planning
Additional info:
WishBone compliant: No
WishBone version: n/a
License: LGPL

Description

Introduction:
From my thesis: Low-Density Parity Check (LDPC) coding is a form of error coding introduced by Gallager that can achieve performance close to the Shannon limit, exceeding the performance of Turbo codes. The coding scheme was introduced in the early 1960’s, but has gained favor recently due to excellent performance and lack of patent rights. Several recent standards include optional or mandatory LDPC coding methods; among these is the second generation Digital Video Broadcasting standard for satellite applications (DVB-S2). This application is unencumbered by low latency requirements, so the standard employs strong coding over codewords 64,800 bits long. Although the standard was designed for low complexity in hardware, the length of the codewords makes this the most computationally intensive of LDPC codes described in current standards.

Project:
This project should be interesting because the design goals are different from decoders used in other standards. Rather than trying to achieve fairly good error correction over small blocks in a short amount of time, this decoder uses very long codewords and a large number of configurations to achieve very good performance over a wide range of channels.

This project is based on a project I submitted toward fulfillment of my Master's degree in 2008. It originally targeted a 180nm ASIC library provided by the university, but I want to re-implement it for FPGA. There are areas in which I could use some help:

- Verify functional correctness. It does work, in terms of correcting flipped bits, but I wrote the encoder, so it's possible I misunderstood something. An extra set of eyes checking my interpretation of the standard could be useful.
- Testbench improvements. My noise model is just a bunch of files from which I randomly pull samples. I think it would be nicer to call a C function to add noise to the signal. There are a number of other minor improvements I'd like to make to the testbench as well.
- Synthesis to FPGA. The RAM and ROM models I'm using now are suitable to implementation in FPGA, but they're still just behavioral models. I need to switch to real RAM's and ROM's, and build the project in a large FPGA.
- General coding and testing. Checking over the code to find bugs or suggest improvements could be helpful.
- Wishbone I/O? Right now, I load groups of bits into the decoder in parallel (360, 180 or 90 bits at a time, depending on certain parameters of the implementation). It might be better to add a standardized interface, perhaps Wishbone.
- Looking forward. The design permits layered decoding, which is a method to reduce the number of iterations in the decoder while achieving the same performance. Unfortunately, something is going wrong when I change the ROM to layered decoding. It would be useful if someone could investigate this.

Status:
I've lost some fairly important files due to entropy and a re-installation of the OS. In particular, I had C code for creating the ROM file and some C models to verify the Verilog's correctness that have been lost. Unfortunately, I'm not sure what bugs may exist in the current RTL that had actually already been fixed. A quick change to the ROM table allowed me to run a simulation (with ModelSim), and it successfully corrected the errors, but it will take me some time to get the project back into proper shape. To avoid any further loss, I'll check in all the RTL code and an overview document now.