On Tue, Feb 27, 2007 at 08:24:48PM -0500, Brian Padalino wrote: > Hi Thibaud, > > Here is my response as to how I understand things to work - which > could be completely wrong. > > On 2/27/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote: > >Hi all, > > > >First of all, I would like to make sure that I have understood what is > >going to be modified. I have made a diagram with the whole Gnuradio > >component stack: http://img168.imageshack.us/img168/415/groveralleb2.png > > > >1) The new usb packet will be encoded/decoded in the gnuradio uspr > >driver and in the FX2 firmare right? > > On the host side, the message blocks will queue up the commands and > create the packet structure that will go down to the USRP driver and > be delivered by libusb. > > A specific endpoint within the FX2 will be used to figure out if it's > an m-block packet or something else (like a packet to tell the FX2 to > program the FPGA).
We'll still have 3 endpoints: ep0, the control endpoint, will be used to load firmware into the FX2 and the bitstream into the FPGA. ep2 is the Tx (outbound) endpoint. It supports "bulk" transfers. All Tx data and command packets will be sent to this endpoint. ep6 is the Rx (inbound) endpoint. It supports "bulk" transfers. All Rx data and command replies will come from this endpoint. The FX2 will only examine the ep0 commands. Data on ep2 and ep6 is transparently passed between the FPGA and host via the FX2 GPIF interface. At most minor changes should be required in the FX2 firmware. The transparent forwarding of ep2 and ep6 will work just like it does now. > The FX2 firmware will then be pretty transparent and pass along the > information over the same datapath as the current TX/RX samples. Yes. > Once inside the FPGA, some command parsing happens and the samples are > sent on through to a FIFO where they sit until their timestamp comes > up while the control words go on to some kind of control FSM that will > take care of all those commands based on timestamp. Yes. One thing to be aware of is that there are two clock domains in the FPGA: the master clock (64 MHz) and the USB Clock (48 MHz). The Rx and Tx FIFOs bridge those two clock domains. > The packets going from the USRP to the host will be created within the > FPGA and send on out through the m-block FIFO that the FX2 will read. Yes. The FPGA will build 512 byte packets and queue them for transmission to the FX2 across the GPIF interface. The FX2 will transparently forward them to the host. The host code will then "do the right thing" ;) > Again - I am not sure if this is how it is supposed to be, but this is > how I have read it thus far. > > >2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus > >some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will > >the commands be sent trough the serial bus or through the usb_data bus ? > > I suppose I answered this a bit up above. The SDI/SDO stuff won't be used to communicate between the FX2 and the FPGA. In the current code we use it to read and write FPGA registers. Everything will be sent across the GPIF. The flow control (HAS_SPACE and PKT_AVAIL) and bus interface pins will be used exactly as they currently are. The RX_OVERRUN, TX_UNDERRUN, and FPGA_CLR_STATUS pins will no longer be needed, since that information will be communicated in the bits in the header of the OUT packets. > >What is exactly the daughter board role and its responsibilities ? Is it > >only a physical interface for the antenna ? > > For the most part, it's our link to the outside world. When doing a > frequency hopping scheme or a TDMA scheme, you have to transmit at > extremely specific times, or change frequencies very quickly and > accurately. To do this, you need tight control over the PLL, > synthesizer, mixer, any tuners, etc that will govern how and where > your signal shows up in the spectrum. The role of the daugherboard is > really to make sure the signal gets out as cleanly as possible. Yes. They handle the analog conversion between baseband and RF. > >I also a few question about the format itself: > > > >I don't understand the purpose of the Tag field. Can you explain it a > >little bit ? > > I think this is just a specific identifier for future use. I am not > exactly certain myself. Stay tuned. I think the host is going to want it, but it might turn out to be unnecessary. I was thinking it could be used by the host to determine when an Rx frequency change had occurred without requiring a reply packet. E.g., if the FPGA copied the last seen IN tag into the OUT packets, the host could use a new tag for the command packet that contained the "tune commands". When it saw that new tag in the IN stream, it would know that the "tune" had occurred. This could be "premature optimization..." > >I don't understand how the timestamps will work on OUT packets: How the > >host will know what the value of the 32 bits counter incremented by the > >A/D sample clock ? Is the timestamps the absolute value of the clock or > >a delta? > > Usually a TDMA sequence will do a search first to try to get a lock on > a signal. Once that happens, it's synchronized to the system. It > will probably search for a signal, and once a signal is detected - > reset the free-running counter in the FPGA to be aligned with the > start of the TDMA epoch. I suspect that most of this will happen in the host. The host can detect the slot timing by watching the received data. It will have the timestamp of the received data, and can use that to compute the timestamps needed to hit the TDMA slot for the transmit data. > >SPI is used to write to the AD9862 register but what is I2C ? > > SPI is basically the same thing with a different physical interface. > SPI uses 3 wires where I2C uses 2, if I am not mistaken. > > Currently, the SPI bus is used to write to both the FPGA and the > AD9862. Since the FPGA will be writing to the SPI, the in-band > signaling code should only have to write to the AD9862. And the daugherboards. See usrp/firmware/include/usrp_spi_defs.h > The I2C bus is used to control the daugherboard. I believe the USRP > does not have a connection to the I2C bus right now, and will possibly > require a modification of the board to connect it up. Yes, and it's also used to read the EEPROMs on the motherboard and the daughterboards. > If I have screwed up, I am sorry and please, someone correct me. > > Brian Thanks for answering, and thanks to everyone for their input on these design questions! Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
