Re: [Discuss-gnuradio] Complex Short/INT16 type

[Nick Foster]

Sean, with all the talk about optimization for ARM, the first thing I
would do is start to integrate Volk with existing floating-point
blocks. Stock GCC is very, very bad at vectorizing for the NEON SIMD
unit -- even when hardware floating point is used in GCC, most float
instructions end up allocated to the VFP rather than the NEON unit.
You might find an easy 2x-3x improvement just by doing the heavy
lifting in Volk rather than in C++. All of the Orc functions in Volk
will work for NEON. There's no FIR filter in Orc right now (need to
get accumulators working properly in Orc), but Philip Balister already
wrote NEON FIR filter cores for the _fff and _ccf FIR filters.

This isn't to say that short complex wouldn't be a useful addition to
GR. Just that it's likely going to be more work than making use of the
existing floating-point hardware the E100 already has.

This is work that needs to be done anyway to make ARM platforms as
useful as possible, and we (Josh, Phil, and I) are happy to help you
optimize your application for E100 if you give us details on how your
application works. We're putting together a "motivating example" using
Volk to show users how to Volkify their own blocks.

--n

On Tue, Nov 8, 2011 at 9:13 AM, Josh Blum <address@hidden> wrote:
>
>
> On 11/07/2011 02:15 PM, Nowlan, Sean wrote:
>> Hi all -
>>
>> I'm getting limited by the slow ARM processor in the E100 and I want
>> to modify parts of gr-digital and gnuradio-core to support complex
>> short/INT16 types in the modulation schemes. I suspect that it won't
>> be as trivial as defining "typedef std::complex<short> gr_complexs;"
>> in gnuradio-core/src/lib/runtime/gr_complex.h and doing a
> find-and-replace in the relevant source files. There are probably
>
> It may be that simple for some blocks. Like the symbol table in BPSK.
>
>> issues with dynamic range that I'll have to deal with in addition to
>> having to implement filters using fixed-point math.
>>
>
> Often blocks will need to have scale factors. Fortunatly, with a FIR
> filter, you get a free scale factor in the "filter taps"
>
>> Questions:
>>
>> 1)      Do you think I'd save anything by doing all the modulation &
>> filtering in complex float32 and then converting at the very end?
>
> Its good to make the conversion part of an operation that does something
> useful rather than doing it for the sake of converting. Like a filter
> that takes in floats and spits out shorts.
>
>> This will reduce the bandwidth requirement to the FPGA by two, but
>> I'm afraid the float math is the true limitation.
>>
>
> The format going into the FPGA is always integer. If you pass floats
> into the UHD, they are copy-converted from host buffer to memory mapped
> buffers.
>
>> 2)      Why is there a gr_complex_to_interleaved_short block but not
>> a gr_complex_to_complex_short block? Would it be better if I rolled
>> my own or just hooked up a gr_complex_to_interleaved_short block and
>> then a deinterleave block? Or alternatively, split the complex float
>> vector into two streams and feed them to a USRP sink block using
>> COMPLEX.INT16?
>>
> The interleaved short block is a strange hold-over from ancient times. I
> would ignore it. I think a block such as "gr_complex_to_complex_short"
> is a good idea.
>
>> 3)      What specific parts of the modulation examples or
>> gnuradio-core do you think I need to change to support complex short
>> ints?
>>
>
> Probably some new sc16 filter blocks for the matched filters. I have
> mentioned the importance of volk before.
>
> The constellation stuff relies on this new constellation library in
> gr-digital. Perhaps Ben can lean in here and offer some advice on how to
> modify this for alternative data types.
>
> The recovery stuff in the BPSK is using Tom's new gri-control-loop to
> simplify writing things like FLLs, PLLs. Thats a place too look, see how
> the timing recovery blocks make use of it.
>
> -Josh
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>