Re: [Discuss-gnuradio] [GSoC] Co-Processors Update #7

[Tom Tsou]

On Fri, Jul 25, 2014 at 1:02 AM, Alfredo Muniz <address@hidden> 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