Re: [Discuss-gnuradio] Queries regarding FPGA
On Wed, Mar 01, 2006 at 11:02:12PM -0500, amit malani wrote:
> 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.
Please take a look at the code in usrp_standard.{h,cc},
usrp_basic.{h,cc}, and usrp_prims.{h,cc}. They all go over the USB as
control messages to endpoint 0. The control messages are parsed in
the FX2 and acted upon. Generally speaking they end up issuing
transactions on the I2C bus or SPI bus.
The FPGA registers, AD9862 regs and daughterboards appear on the SPI bus.
The configuration eeproms and daughterboards appear on the I2C bus.
See the USRP schematics for details.
usrp/firmware/include/usrp_spi_defs.h contains the defs for the SPI bus.
usrp/firmware/include/usrp_i2c_addr.h contains the standard i2c
addresses. Some daughterboards use others that are a function of
which slot the d'board is plugged into.
> 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
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
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 advanceamitOn 2/27/06, Thomas Schmid <[EMAIL PROTECTED] > 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 tohave shorter delays, you use the udelay function and do a busy wait.Or is there something that I am missing?ThomasOn 2/26/06, Eric Blossom < [EMAIL PROTECTED]> 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> Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio>___Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
On Mon, Feb 27, 2006 at 08:28:56AM -0800, Thomas Schmid 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? nanosleep(2) used to have that wanted passive/active sleep, but it isn't the case anymore with Linux 2.6 kernels. Most of the time, with an appropriate design, you just don't need a real time OS. However, if you are in tight feedback business or alike, and haven't found out a another way, Xenomai[1] under a patched Linux is the solution, with hard accuracy in the order of <10us, task run from user-space, with a POSIX skin API. [1] http://xenomai.org > On 2/26/06, Eric Blossom <[EMAIL PROTECTED]> wrote: > > 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!). This step would be very good! If we go the SCHED_FIFO way, it would be neat to be able to enable it on a thread by thread basis. Actually, the Omnithread library has already support for SCHED_FIFO policy for POSIX systems. Since running applications as root is no good, what we're missing here is a wrapping of POSIX libcap in Omnithread/POSIX to gain secheduling priviledges, pretty much the same way JACK is doing it, as explained here[2]. Then, thanks to the realtime-lsm kernel module, regular users of a group can gain access to the SCHED_FIFO policy. The audio guys went before us, the libcap and realtime-lsm package can be found on most moderns distros. The day we leave the SCHED_OTHER safe world, GNU Radio will need to have implemented in its flowgraph scheduler a watchdog to spare at least 1% when choking 100% of the CPU time... [2] http://jackit.sourceforge.net/docs/faq.php#a5 -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
On Mon, Feb 27, 2006 at 10:41:10AM -0500, Clark Pope wrote: > > 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 > > 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. > > -Clark You can do that from user space. Not sure about the wifi specific extensions, but there's already code in user space that has GNU Radio show up as an "ethernet" interface (gr0 under GNU/Linux). We use the tun interface. See gnuradio-examples/python/gmsk2/tunnel_ip_null_mac.py and the README in the same directory. It talks about how to ifconfig the gr0 interfaces, add routes, etc. See also /usr/src/linux/Documentation/networking/tuntap.txt Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
Original Message Follows From: Eric Blossom <[EMAIL PROTECTED]> To: Clark Pope <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], discuss-gnuradio@gnu.org 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 throughput!). Eric 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. -Clark _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
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 <[EMAIL PROTECTED]> 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Queries regarding FPGA
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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Queries regarding FPGA
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. 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. Original Message Follows From: "amit malani" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Queries regarding FPGA Date: Sat, 25 Feb 2006 23:06:57 -0500 Hello! I am trying to implement a CSMA/CA typish MAC layer protocol. something like RTS-CTS-DATA-ACK type packet exchange. The idea to move some functionality on FPGA. The idea is to maintain two speperate buffers, one for DATA packets and the other for RTS packets. so that over multiple rounds of transmissions, DATA packet is preprocessed and stored on FPGA..yeilding in good deal of time saving. Also implementing some timers on FPGA which would assist in collision avoidance mechanism. I just wanted a sanity check from you guys who have worked on design and use of FPGA. on a course level i could see, from std_usrp project, 57% of the memory bits are utilised so far: there is scope for extra buffer 87% of LEs are also utilised. : So would there be enough space to implement the control logic? (will need to implement inside the master_control module right?). if there is not enough space, can I kick out few modules? Also how control signaling is done?...it must be inline to data path I guess? whats the protocol for it? thanks, amit ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
