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: Thomas Schmid
Subject: Re: [Discuss-gnuradio] Queries regarding FPGA
Date: Mon, 27 Feb 2006 08:28:56 -0800

Isn't one of the problems that Linux is not a real time os, i.e.,
exact time scheduling is impossible? As far as I know, linux timers
have an accuracy of 1ms (i.e. 1 jiffie in the kernel). If you want to
have shorter delays, you use the udelay function and do a busy wait.
Or is there something that I am missing?

Thomas

On 2/26/06, Eric Blossom <address@hidden> wrote:
> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>




reply via email to

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