[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Queries regarding FPGA

From: Clark Pope
Subject: Re: [Discuss-gnuradio] Queries regarding FPGA
Date: Mon, 27 Feb 2006 10:41:10 -0500

----Original Message Follows----
From: Eric Blossom <address@hidden>
To: Clark Pope <address@hidden>
CC: address@hidden, address@hidden
Subject: Re: [Discuss-gnuradio] Queries regarding FPGA
Date: Sun, 26 Feb 2006 17:23:55 -0800

On Sun, Feb 26, 2006 at 11:16:17AM -0500, Clark Pope wrote:
> You'll want to strip out the extra receiver. The default fpga is 2 rx and 1
> tx. You probably don't need the second RX for your application. You also
> may not need the halfband filter on your receiver.
> In the past I've stripped down to a single RX and got utilization down to
> about 30%. You'll probably be at 40% with one RX and one TX.

The current code is (mostly) conditionally configured for number of Rx
and Tx channels.  You can select 0, 1, 2 or 4 Rx, but right now, the
Tx is either 0 or 2.  It's easy to fix.  I'd welcome a patch (the Tx
should be conditionalized in the same style as the Rx).

Take a look at usrp/fpga/toplevel/usrp_std/usrp_std.v, usrp_std.vh
and usrp_std_config_*.vh

> As far as control logic. I've been planning something similar (open 802.11 > mac) and I was thinking I could write a linux device driver to do a lot of
> the time critical stuff (agc, CA, etc.). Seems like one can poll some
> status lines from the FPGA frequently enough to do a lot of things.

FYI, It's not clear that going to a driver is going to make too much
difference.  It might, but I'd start with the user mode code.
Measure twice, cut once ;)

There is some fairly straight-forward work that can be done to reduce
the latency of the user mode code, and that's probably a good first
step.  This would also including enabling real-time scheduling for the
signal processing threads (SCHED_FIFO), reducing the amount of user
space buffering for the USRP (no need to mess with the generic
buffering in GNU Radio, it's not the problem), and transfering smaller
chunks of data across the user/kernel boundary (that that won't help


Yes, I will probably monkey around from within user space originally, but I should have mentioned that my end goal is to have the USRP appear as an 802.11 network node to the OS so that it integrates with ethereal and other network tools just like any wi-fi card would. So I'm stuck with developing a custom device driver (probably adapted from wlan-ng) anyway.


Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]