Re: [Discuss-gnuradio] Queries regarding FPGA

[amit malani]

i am sorry for asking it again, but few of my questions got lost with the flow of discussion.

how control signaling is done?..whats the protocol for it?

actually when i say these lines.
        src = usrp.source_c (0, decim)
        src.set_rx_freq (0, IF_freq)
        src.set_pga(0,20)
how actually it gets translated and conveyed to the master_control(?) module on FPGA to do the needful. am I not he right path?

please let me know,
thanks in advance

amit

On 2/27/06, Thomas Schmid <address@hidden > wrote:

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
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio