USB packet format / inband signaling

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?

  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 ?

What is exactly the daughter board role and its responsibilities ? Is it
only a physical interface for the antenna ?

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 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?

SPI is used to write to the AD9862 register but what is I2C ?

Thanks,
Thibaud

Hi Thibaud,

Here is my response as to how I understand things to work - which
could be completely wrong.

On 2/27/07, Thibaud H. [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).

The FX2 firmware will then be pretty transparent and pass along the
information over the same datapath as the current TX/RX samples.

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.

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.

Again - I am not sure if this is how it is supposed to be, but this is
how I have read it thus far.

  1. 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.

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.

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.

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.

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.

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.

If I have screwed up, I am sorry and please, someone correct me.

Brian

Brian P. wrote:

component stack: http://img168.imageshack.us/img168/415/groveralleb2.png
program the FPGA).
FPGA and send on out through the m-block FIFO that the FX2 will read.

Again - I am not sure if this is how it is supposed to be, but this is
how I have read it thus far.

So the usb packets will be decoded/encoded in the fpga itself. The tx
fifo would store 512 bytes of usb data and then parse it, send the
samples and execute the command right? This could be a first thing to
work on.

For the most part, it’s our link to the outside world. When doing a

little bit ?
a signal. Once that happens, it’s synchronized to the system. It
AD9862. Since the FPGA will be writing to the SPI, the in-band
signaling code should only have to write to the AD9862.

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.

If I have screwed up, I am sorry and please, someone correct me.

Brian

Thanks for this detailed explanation :slight_smile:
Thibaud

On Tue, Feb 27, 2007 at 08:24:48PM -0500, Brian P. wrote:

component stack: http://img168.imageshack.us/img168/415/groveralleb2.png
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” :wink:

Again - I am not sure if this is how it is supposed to be, but this is
how I have read it thus far.

  1. 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs