Hi all. My job requires me to implement a turbo decoder in hardware. So far I have read a chapter in Proakis covering turbo codes (and a handful of articles). But I would like to learn more, mainly about implementation issues, decoding algorithms, tradeoffs between algorithm complexity and efficiency. Is there a book I must own? I've done a search and I think the following two books cover this topic well: 1) "Turbo Codes: Desirable and Designable" (2004) by Giulietti, Bougard and Van Der Perre. 2) "Turbo Decoder Architecture for Beyond-4G Applications" (2014) by Wong and Chang. Yet I would totally appreciate any advice about proper literature. Regards, Evgeny.
Books about turbo codes
Started by ●January 14, 2016
Reply by ●January 14, 20162016-01-14
Evgeny Filatov <e.v.filatov@ieee.org> wrote:>My job requires me to implement a turbo decoder in hardware. So far I >have read a chapter in Proakis covering turbo codes (and a handful of >articles). But I would like to learn more, mainly about implementation >issues, decoding algorithms, tradeoffs between algorithm complexity and >efficiency.>Is there a book I must own?>I've done a search and I think the following two books cover this topic >well: >1) "Turbo Codes: Desirable and Designable" (2004) by Giulietti, Bougard >and Van Der Perre. >2) "Turbo Decoder Architecture for Beyond-4G Applications" (2014) by >Wong and Chang.>Yet I would totally appreciate any advice about proper literature.Heegard and Wicker _Turbo Coding_ is good, in the sense that I was able to implement turbo decoders directly from the description of the decoding algorithm in this book. In implementation, there are really two design decisions that are most important: (1) how to represent (in bits) the measures internal to the BCJR algorithm (here, a measure is a value in [0,1] that is the product of many probabilities); and (2) how to implement the interleaving. The rest of it is fairly cookbook. Be wary of descriptions that from the outset discuss using LLR's (log-likely ratios) because these authors are often making an assumption about design decision (1) without having fully explored the design space. Viterbi's paper on the Generalized Viterbi Algorithm (an approximation to the BCJR) is also very clearly written, although you may not be able to use the GVA as it comes with some implementation loss. I should also mention that you will need to know how to derive the MAP probabilities that form the input to the decoder, for each of your subject signal constellations. That topic has been covered in posts to this newsgroup. Good luck Steve
Reply by ●January 14, 20162016-01-14
On 14.01.2016 21:50, Steve Pope wrote:> > Heegard and Wicker _Turbo Coding_ is good, in the sense that I > was able to implement turbo decoders directly from the description > of the decoding algorithm in this book. >Thanks, Steve! The book suggestion is fairly good. "Turbo coding" is clearly written and seems to be adequate for my needs. As is often the case, just because a book is newer does not necessarily make it better. As an example from another field, there are numerous books about GPS, but it's Kaplan's "Understanding GPS" that allowed me to build a working design based on the book alone. Now I will have a good read. :) > In implementation, there are really two design decisions that are > most important: (1) how to represent (in bits) the measures internal > to the BCJR algorithm (here, a measure is a value in [0,1] that is the > product of many probabilities); and (2) how to implement the > interleaving. The rest of it is fairly cookbook. > > Be wary of descriptions that from the outset discuss using LLR's > (log-likely ratios) because these authors are often making an assumption > about design decision (1) without having fully explored the design > space. > > Viterbi's paper on the Generalized Viterbi Algorithm (an approximation > to the BCJR) is also very clearly written, although you may not be > able to use the GVA as it comes with some implementation loss. > > I should also mention that you will need to know how to derive > the MAP probabilities that form the input to the decoder, for > each of your subject signal constellations. That topic has been > covered in posts to this newsgroup. > > Good luck > > Steve > Thanks, that's a good starting point and a lot of information to consider! Best regards, Evgeny.
Reply by ●January 14, 20162016-01-14
On Thu, 14 Jan 2016 21:29:36 +0300, Evgeny Filatov <e.v.filatov@ieee.org> wrote:>Hi all. > >My job requires me to implement a turbo decoder in hardware. So far I >have read a chapter in Proakis covering turbo codes (and a handful of >articles). But I would like to learn more, mainly about implementation >issues, decoding algorithms, tradeoffs between algorithm complexity and >efficiency. > >Is there a book I must own? > >I've done a search and I think the following two books cover this topic >well: >1) "Turbo Codes: Desirable and Designable" (2004) by Giulietti, Bougard >and Van Der Perre. >2) "Turbo Decoder Architecture for Beyond-4G Applications" (2014) by >Wong and Chang. > >Yet I would totally appreciate any advice about proper literature. > >Regards, >Evgeny.Along the lines of what Steve mentioned, if you can figure out how to implement a Viterbi decoder, then a Soft-Output-Viterbi-Algorithm (SOVA) decoder, then a BCJR, then from there it's just hooking things together according to whatever spec and configuration you're trying to match. One of the better TC implementers on the planet is Steven Pietrobon at Small World Communications: http://www.sworld.com.au/ He doesn't show a lot of details on implementation in his documentation (for good reason), but does sometimes show useful hints on practices. Don't get too hung up on the LLR thing. It's not that bad. There are a lot of little tricks that can greatly simplify things that are "sub-optimal" but have very little ultimate affect on performance. Are you building your own BCJR or using an existing one? Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 14, 20162016-01-14
On 15.01.2016 1:05, Eric Jacobsen wrote:> > Along the lines of what Steve mentioned, if you can figure out how to > implement a Viterbi decoder, then a Soft-Output-Viterbi-Algorithm > (SOVA) decoder, then a BCJR, then from there it's just hooking things > together according to whatever spec and configuration you're trying to > match. > > One of the better TC implementers on the planet is Steven Pietrobon at > Small World Communications: http://www.sworld.com.au/ > > He doesn't show a lot of details on implementation in his > documentation (for good reason), but does sometimes show useful hints > on practices. > > Don't get too hung up on the LLR thing. It's not that bad. There > are a lot of little tricks that can greatly simplify things that are > "sub-optimal" but have very little ultimate affect on performance. > > Are you building your own BCJR or using an existing one? > > > Eric Jacobsen > Anchor Hill Communications > http://www.anchorhill.com >Thanks for the hints, Eric. Yes, that would be my own implementation. The major reason is, after I have it up and running, I wish to be able to modify it for the sake of further performance improvements (such as code-aided synchronization) which make turbo-codes really attractive. Best regards, Evgeny.
Reply by ●January 14, 20162016-01-14
Evgeny Filatov <e.v.filatov@ieee.org> wrote:> The major reason is, after I have it up and running, I wish > to be able to modify it for the sake of further performance > improvements (such as code-aided synchronization) which make > turbo-codes really attractive.Are you designing the code as opposed to just the decoder? S.
Reply by ●January 15, 20162016-01-15
On 15.01.2016 1:47, Steve Pope wrote:> Evgeny Filatov <e.v.filatov@ieee.org> wrote: > >> The major reason is, after I have it up and running, I wish >> to be able to modify it for the sake of further performance >> improvements (such as code-aided synchronization) which make >> turbo-codes really attractive. > > Are you designing the code as opposed to just the decoder? > > S. >Exactly. Regards, Evgeny.
Reply by ●January 15, 20162016-01-15
On 15.01.2016 1:47, Steve Pope wrote:> Evgeny Filatov <e.v.filatov@ieee.org> wrote: > >> The major reason is, after I have it up and running, I wish >> to be able to modify it for the sake of further performance >> improvements (such as code-aided synchronization) which make >> turbo-codes really attractive. > > Are you designing the code as opposed to just the decoder? > > S. >I'm not sure "designing" the code is appropriate word, though. I'm pretty much going to stick to whatever options I can find in the literature, but indeed I have a choice there. Regards, Evgeny.
Reply by ●January 15, 20162016-01-15
On Fri, 15 Jan 2016 10:40:30 +0300, Evgeny Filatov <e.v.filatov@ieee.org> wrote:>On 15.01.2016 1:47, Steve Pope wrote: >> Evgeny Filatov <e.v.filatov@ieee.org> wrote: >> >>> The major reason is, after I have it up and running, I wish >>> to be able to modify it for the sake of further performance >>> improvements (such as code-aided synchronization) which make >>> turbo-codes really attractive. >> >> Are you designing the code as opposed to just the decoder? >> >> S. >> > >I'm not sure "designing" the code is appropriate word, though. I'm >pretty much going to stick to whatever options I can find in the >literature, but indeed I have a choice there. >What are your design/performance criteria? Several of the standardized codes are pretty good. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●January 15, 20162016-01-15
On 15.01.2016 19:10, Eric Jacobsen wrote:> What are your design/performance criteria? Several of the > standardized codes are pretty good. > > > Eric Jacobsen > Anchor Hill Communications > http://www.anchorhill.com >Formally it's within 1 dB from the performance achieved by the code (as reported in the literature) I'm trying to implement. Basically I'm comfortable with this project, in the sense I'm not trying to do anything impossible. Regards, Evgeny.
