discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Queries regarding FPGA


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Queries regarding FPGA
Date: Sun, 26 Feb 2006 17:23:55 -0800
User-agent: Mutt/1.5.9i

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
throughput!).

Eric




reply via email to

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