[GSoC] Co-Processors Update #7

GNU Radio
1

Hello all,

Logistical:

  • When is the next coproc call???
  • Mentor Philip is on vacation for a few weeks :frowning:

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

Crunch time is upon us!

2

Hi Alfredo,

On Thu, Jul 24, 2014 at 1:57 PM, Alfredo M. [email protected]
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

3

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. [email protected] 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. [email protected] 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. [email protected] 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. [email protected] 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!

4

Hey Alfredo,

cool stuff with the Turbo Code :slight_smile:

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
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:

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. [email protected]:

5

On Thu, Jul 24, 2014 at 11:47 PM, Jan Krämer [email protected]
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!

6

On Fri, Jul 25, 2014 at 1:02 AM, Alfredo M. [email protected]
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