# \[GSoC\] Co-Processors Update #7 **URL:** \ **Category:** GNU Radio\ **Created:** [July 24, 2014, 7:59pm UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169 "2014-07-24T19:59:10Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [July 24, 2014, 7:59pm UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/1 "2014-07-24T19:59:10Z")
Hello all, Logistical: - When is the next coproc call??? - Mentor Philip is on vacation for a few weeks ☹ Progress: - Bad news is that I’ve given up on the FFTC. The conflict of resources in the resource manager to get the queue manager subsystem running correctly between the ARM and DSP made my head spin too fast as I would need to dissect the dtb, make changes, test, repeat so many times. - Good news is that I have successfully run the turbo decoder on the DSP through loading in a program from the ARM. I fed it some data and it returns the appropriate hard decisions for LTE at 93 Mbits/second with a very simple setup (non segmented so no parallelism). Yay! So we are going to decode LTE turbo codes now as it’s the most painless thing to work with since it doesn’t rely on the queue manager which is a pain to setup with arm+dsp. If anyone knows good resources to read about LTE turbo codes please let me know as I’m fairly new to it and could use some more theory than is provided in TI’s TCP3d reference guide. Also there are 2 LTE carriers in the area that I can hopefully use for testing once I set things up. Need to update wiki. - Time was not wasted however as I can use what I learned on the FFTC playing with the queue manager to send data between the arm and dsp in the shared memory space. Then need to write a program on the arm to get data from gnuradio running on the arm to the dsp. - Need to talk to the TI guys to figure out how to package my work for sharing as TI uses some strange license and we need GPLv3. Don’t want to step on anyone’s toes. - Also for the coproc group (and for the buffer management side of my project) I have started a wiki at my attempts to dissect GNU Radio Runtime. It is incomplete however feedback is much appreciated. [http://gnuradio.org/redmine/projects/gnuradio/wiki/runtime](http://gnuradio.org/redmine/projects/gnuradio/wiki/runtime) Crunch time is upon us! ---
**Author:** ![alfredmart](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a87d85/32.png) [@alfredmart](https://www.ruby-forum.com/u/alfredmart)\ **Post date:** [July 25, 2014, 6:20am UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/2 "2014-07-25T06:20:54Z")
Hi Alfredo, On Thu, Jul 24, 2014 at 1:57 PM, Alfredo M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > - Good news is that I have successfully run the turbo decoder on the DSP > through loading in a program from the ARM. I fed it some data and it returns > the appropriate hard decisions for LTE at 93 Mbits/second with a very simple > setup (non segmented so no parallelism). Yay! So we are going to decode LTE > turbo codes now as it’s the most painless thing to work with since it > doesn’t rely on the queue manager which is a pain to setup with arm+dsp. If > anyone knows good resources to read about LTE turbo codes please let me know > as I’m fairly new to it and could use some more theory than is provided in > TI’s TCP3d reference guide. Also there are 2 LTE carriers in the area that I > can hopefully use for testing once I set things up. Need to update wiki. This is a great result since the turbo decoder is perhaps the most difficult component to achieve high bandwidth using a GPP or DSP. Any thoughts on the next milestone? If you are sticking with LTE decoding, the outer portions of the receiver (OFDM, precoding, etc.) are probably out-of-scope for this project, but do you think it would be possible to attach and manipulate the Bit Rate Coprocessor (BCP)? That would link the upper receiver chain and allow feeding in raw I/Q symbols. Though, the tricky aspect may be that the BCP receive portion is typically setup for the eNodeB side to recover UE uplink signals and not the downlink that you mention. Those are just random thoughts. If you need captures, myself or some of the other LTE folks can probably provide live (or canned) signals at various test points. -TT ---
**Author:** ![alfredmart](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a87d85/32.png) [@alfredmart](https://www.ruby-forum.com/u/alfredmart)\ **Post date:** [July 25, 2014, 7:04am UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/3 "2014-07-25T07:04:38Z")
Thanks for your response Tom. I’ve been told you are the one to talk to about LTE stuff. On Thu, Jul 24, 2014 at 9:19 PM, Tom T. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Any > thoughts on the next milestone? Currently I have everything working on the DSP through a compiled program that I load onto the DSP from the ARM. I would now need to send data between the ARM and the DSP so that we can interface with GNU Radio. I have a couple of options MessageQ, Msgcom, and CMEM. The plan is to simply pass a pointer with all the log-likeihood ratios on the ARM side so that the DSP can process it and then get the pointer to the resulting hard decisions back to the ARM. Once I can test that this works the next step would be to get the data from GNU Radio. On Thu, Jul 24, 2014 at 9:19 PM, Tom T. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > If you are sticking with LTE decoding, the outer portions of the > receiver (OFDM, precoding, etc.) are probably out-of-scope for this > project Yeah I don’t know much about LTE decoding. The TCP3d is capable of operating in three modes: LTE, WiMax, and 3GPP. If one is easier to work with on the DSP side than another please let me know as the TCP3d simply does turbo decoding. It takes in LLRs and outputs the hard decisions though it can also give other things like soft decisions. On Thu, Jul 24, 2014 at 9:19 PM, Tom T. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > do you think it would be possible to attach and > manipulate the Bit Rate Coprocessor (BCP)? The BCP operates through the same means as the FFTC using the QMSS and CPPI. It is definitely possible but I think I’ve spent enough time on it for this summer. I will definitely revisit this issue once I have something more substantial to present for the conference. On Thu, Jul 24, 2014 at 9:19 PM, Tom T. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Those are just random thoughts. If you need captures, myself or some > of the other LTE folks can probably provide live (or canned) signals > at various test points. Thanks. Any resources to understanding the DSP theory would be helpful and your recommendation on whether to pursue LTE, WiMax, or 3GPP. I’m hoping to be at the point where I need to produce live data sometime late next week. Thanks again! ---
**Author:** ![alfredmart](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a87d85/32.png) [@alfredmart](https://www.ruby-forum.com/u/alfredmart)\ **Post date:** [July 25, 2014, 8:49am UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/4 "2014-07-25T08:49:27Z")
Hey Alfredo, cool stuff with the Turbo Code 🙂 If you want to read more on general turbo code principles I suggest Hanzo’s Book on Turbo Codes /EQ [http://www-mobile.ecs.soton.ac.uk/comms/files/fec-book-updtd.pdf](http://www-mobile.ecs.soton.ac.uk/comms/files/fec-book-updtd.pdf) Turbo Codes start at Page 21. I implemented the 8-state RSC code from LTE as single MAP Decoder in my Master’s thesis and I found this pretty helpful: > **[ts\_136212v110100p.pdf](https://www.etsi.org/deliver/etsi_ts/136200_136299/136212/11.01.00_60/ts_136212v110100p.pdf)** > > 669.90 KB Coding starts at page 11. Hope this can help you. See you at GRCON! -Jan 2014-07-25 7:02 GMT+02:00 Alfredo M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![alfredmart](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a87d85/32.png) [@alfredmart](https://www.ruby-forum.com/u/alfredmart)\ **Post date:** [July 25, 2014, 8:59am UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/5 "2014-07-25T08:59:37Z")
On Thu, Jul 24, 2014 at 11:47 PM, Jan Krämer [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hope this can help you. > > See you at GRCON! Thanks Jan! I kept googling lte turbo codes and all I found were research papers so got scared. The book will be helpful. See you at the con! ---
**Author:** ![alfredmart](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a87d85/32.png) [@alfredmart](https://www.ruby-forum.com/u/alfredmart)\ **Post date:** [July 25, 2014, 6:51pm UTC](https://www.ruby-forum.com/t/gsoc-co-processors-update-7/231169/6 "2014-07-25T18:51:00Z")
On Fri, Jul 25, 2014 at 1:02 AM, Alfredo M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Currently I have everything working on the DSP through a compiled program > that I load onto the DSP from the ARM. I would now need to send data between > the ARM and the DSP so that we can interface with GNU Radio. I have a couple > of options MessageQ, Msgcom, and CMEM. The plan is to simply pass a pointer > with all the log-likeihood ratios on the ARM side so that the DSP can > process it and then get the pointer to the resulting hard decisions back to > the ARM. Once I can test that this works the next step would be to get the > data from GNU Radio. Sounds like a great plan. > Yeah I don’t know much about LTE decoding. The TCP3d is capable of operating > in three modes: LTE, WiMax, and 3GPP. If one is easier to work with on the > DSP side than another please let me know as the TCP3d simply does turbo > decoding. It takes in LLRs and outputs the hard decisions though it can also > give other things like soft decisions. LTE and 3GPP (UMTS) will be nearly identical. The main difference is the interleaver, which you aren’t directly interacting with anyways. I say much about WiMax, but, in general, if you already have the decoder working at a decent rate, later algorithm/parameter changes with the TCP itself will likely be more tweaks than anything else. The TCP is fairly well encapsulated. > The BCP operates through the same means as the FFTC using the QMSS and CPPI. > It is definitely possible but I think I’ve spent enough time on it for this > summer. I will definitely revisit this issue once I have something more > substantial to present for the conference. OK. If that’s the case, then the BCP, which is very standard specific, will likely be even more difficult to work with than the FFTC. Probably not a good path to take. > Thanks. Any resources to understanding the DSP theory would be helpful and > your recommendation on whether to pursue LTE, WiMax, or 3GPP. I’m hoping to > be at the point where I need to produce live data sometime late next week. One note about about real-world decoders, such as the TCP, is that they rely heavily on approximation. Turbo decoding theory in literature will carry out calculations in full exponential and log form which doesn’t translate well towards high-performance, fixed-point implementation. The crudest, fastest, and most commonly implemented decoding algorithms will use max-log approximation. All other algorithms will be variations that reduce the approximation error at some expense in decoding complexity. So when you read the papers and textbooks on turbo codes, keep in mind that much of the math will be gone by the time the decoder is implemented in hardware. -TT