Using gnu-radio for project

GNU Radio
1

Dear Friends,

For a school project, I am looking to speed up a software radio.
I downloaded and built gnu-radio and dial-tone works.

Ideally, I’d like to start with a functioning GSM (others?) radio
which runs in software and speed up the computationally intensive
components (which gnu radio might be using the fpga for)

I would really appreciate if someone could help me in trying to figure
out if/how gnu-radio is a good fit and/or point to other open source
projects.

Thanks,
-Bains

PS. I have no background in dsp/signal-processing but have good
programming background and my day job is writing compilers.

2

On Sat, Sep 27, 2008 at 03:37:34PM -0700, Inderaj B. wrote:

Dear Friends,

For a school project, I am looking to speed up a software radio.
I downloaded and built gnu-radio and dial-tone works.

Ideally, I’d like to start with a functioning GSM (others?) radio
which runs in software and speed up the computationally intensive
components (which gnu radio might be using the fpga for)

Good. Are you thinking about using various SIMD instruction sets, or
something else?

PS. I have no background in dsp/signal-processing but have good
programming background and my day job is writing compilers.

Eric

3

Thanks Eric,
Yes I want to use SIMD. Since I want to spend most time improving
performance, it would be nice if I can start off from something
functioning
or put together something quickly.
How much effort would it be to get a GSM (other?) all software system
together (except A/D I guess). Maybe I could use pre-generated streams
on
both ends in software.

Thanks
Inderaj

4

On Tue, Sep 30, 2008 at 1:48 PM, Eric B. [email protected] wrote:

Inderaj

This is great. What we’ve been thinking about is building a library
of SIMD accelerated primitives, along the lines of Intel’s Integrated
Performance Primitives. The crucial differences would be: free
software (GPLv3); support for SSE, SSE2, SSE3, Altivec and Cell SPE
instruction sets.

Do you mind adding NEON to this list? NEON is a SIMD unit on ARM
Cortex-A8 processors. Information on NEON instructions is at
Documentation – Arm Developer.
Sorry it si the superseded link, I’m too lazy to find the current one
:slight_smile:

the IPP docs, peforming a s/ipp/gpp/g.

http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346499.pdf

http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346532_userguide_win_ia32.pdf

Two possible starting points are:

liboil http://liboil.sourceforge.net (currently x86, x86-64 and PPC)

liboil is used by a number of desktop programs, spending time on this
would be a win for me :slight_smile:

Philip

5

On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj B. wrote:

Thanks Eric,
Yes I want to use SIMD. Since I want to spend most time improving
performance, it would be nice if I can start off from something functioning
or put together something quickly.
How much effort would it be to get a GSM (other?) all software system
together (except A/D I guess). Maybe I could use pre-generated streams on
both ends in software.

Thanks
Inderaj

This is great. What we’ve been thinking about is building a library
of SIMD accelerated primitives, along the lines of Intel’s Integrated
Performance Primitives. The crucial differences would be: free
software (GPLv3); support for SSE, SSE2, SSE3, Altivec and Cell SPE
instruction sets.

Our working title for this is the “Generic Performance Primtives” (GPP).

One unresolved issue is what code to start with. We need a framework
that provides for reference implementations, QA, testing all argument
alignments, correctness, performance, etc; runtime dispatch based on
the equivalent of cpuid; can be built as both shared and static
libraries (need static on the SPE).

The basic idea (for the user visible routines) would be to start with
the well thought out API described in Volume 1 (Signal Processing) of
the IPP docs, peforming a s/ipp/gpp/g.

http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346499.pdf

http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346532_userguide_win_ia32.pdf

Two possible starting points are:

liboil http://liboil.sourceforge.net (currently x86, x86-64
and PPC)
Framewave http://framewave.sourceforge.net (x86 and x86-64 only)

(Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE
C/C++ intrinsics. http://sseplus.sourceforge.net
Mostly it appears that they provide emulations for instructions that
are missing at a particular level. E.g., your code could target SSE3,
and they’d emulate the missing addsub instruction in terms of SSE.)

For starters, it would be great if you could look at these two options
(and any others that you come across) and let us know how you think
these would work out as starting points, given the requirements above.

If this seems like more than you want to bite off, I can provide a
list of high-priority functions and you could start implementing the
reference version and any of the SSE*, Altivec or SPE versions that
grab your attention. We’re big on complex arithmetic :slight_smile:

Please let me know how this sounds and if you’ve got any comments or
questions.

Thanks!
Eric

6

On Tue, Sep 30, 2008 at 02:03:14PM -0400, Philip B. wrote:

:slight_smile:
NEON’s fine by me, as long as you’re doing the work :slight_smile:

the IPP docs, peforming a s/ipp/gpp/g.
liboil is used by a number of desktop programs, spending time on this
would be a win for me :slight_smile:

The issues I see with it is that there’s currently no support for
complex- in the framework, and that the intel function naming
convention doesn’t map well (at all?) into the liboil framework.

Eric

7

On Tue, Sep 30, 2008 at 2:43 PM, Eric B. [email protected] wrote:

Sorry it si the superseded link, I’m too lazy to find the current one
:slight_smile:

NEON’s fine by me, as long as you’re doing the work :slight_smile:

I just want to make sure the work has somewhere to go.

The basic idea (for the user visible routines) would be to start with
liboil http://liboil.sourceforge.net (currently x86, x86-64 and PPC)

liboil is used by a number of desktop programs, spending time on this
would be a win for me :slight_smile:

The issues I see with it is that there’s currently no support for
complex- in the framework, and that the intel function naming
convention doesn’t map well (at all?) into the liboil framework.

Well, who said it was an Intel dominated world?

Philip

8

I agree with this because of the Beagle board and the efficacy of OMAP
processors for embedded SDR apps. With TI finally giving us free
development tools for noncommercial activities (not exactly GPL v3) the
6000
DSP part on the OMAP and the Neon are both sources of considerable MIPS
at
very low power.

We should think about how to officially support libraries based on open
source we develop but for which there are NO free tools for some of the
more
interesting parts coming out way including Cell, OMAP, Tilera Tile64,
and
more. We are doing this now for USRP2. It is time to make a simple
policy
statement that open source, but binary support is accepted and
encouraged
given these conditions: A), B), …

Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Trample the slow … Hurdle the dead”

9

On Tue, Sep 30, 2008 at 02:50:50PM -0400, Philip B. wrote:

Documentation – Arm Developer.
Sorry it si the superseded link, I’m too lazy to find the current one
:slight_smile:

NEON’s fine by me, as long as you’re doing the work :slight_smile:

I just want to make sure the work has somewhere to go.

Yep, me too.

liboil is used by a number of desktop programs, spending time on this
would be a win for me :slight_smile:

The issues I see with it is that there’s currently no support for
complex- in the framework, and that the intel function naming
convention doesn’t map well (at all?) into the liboil framework.

Well, who said it was an Intel dominated world?

Nobody. However, they have provided over 1000 pages of detailed
documentation on their API. Since a big part of any effort is
figuring out what the API should be, I’d prefer to use theirs (and
their documentation) than to reinvent the wheel.

Eric

10

Do you mind adding NEON to this list? NEON is a SIMD unit on ARM
Cortex-A8 processors. Information on NEON instructions is at
Documentation – Arm Developer
j.html.
Sorry it si the superseded link, I’m too lazy to find the current one
:slight_smile:

This assembler language manual gives pretty good details (except
actual instruction encodings):

Documentation – Arm Developer

I also tried looking at NEON for the ARM-9, but got:

Documentation – Arm Developer

"Cortex-A9 NEON Media Processing Engine Technical Reference Manual
Revision: r0p0

This is a placeholder for a restricted document that is not
available from this site. Please contact ARM for more information."

John

11

Philip B. wrote:

Bottom line: companies are still “funny” about doucmentation for high
end products, but attitudes are changing very slowly.

Philip

Hello,

Sometimes it seems the chip makers are really in the documentation
business.

I was interested in the Marvell 88F5182 SoC as it was used in a NAS I
have. Marvell did not have any information on the website and wanted a
NDA signed. Then one day I noticed datasheet and user manual for it on
the web site. It uses an ARM v5TE architecture.

73 Eric

12

It is actually an ARMv7a.

This a LATER chip than the ARM11, much less the ARM9. The NEON is a
powerful 128 bit wide SIMD processor capable of doing floating point
arithmetic.

Bob

This is definitely going to make a VERY nice low power SDR board.
Another
we should consider is the OMAP-L137 which has
ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Trample the slow … Hurdle the dead”

13

On Tue, Sep 30, 2008 at 9:24 PM, John G. [email protected] wrote:

Documentation – Arm Developer

I also tried looking at NEON for the ARM-9, but got:

Documentation – Arm Developer

"Cortex-A9 NEON Media Processing Engine Technical Reference Manual
Revision: r0p0

The Cortex-A9 is not the same as an arm9. The Beagle uses a Cortex-A8
which is an armv7 architecture processor. Confusing? Yes. An arm9
processor uses an armv5 instruction set. (From memory)

The arm7 technical reference is not public, but if you ask nicely you
can get a copy. Needing it to implement NEON based filters for GNU
Radio was a good reason.

Bottom line: companies are still “funny” about doucmentation for high
end products, but attitudes are changing very slowly.

Philip