USRP packet parsing

GNU Radio
41

I updated the wiki paged and added state machines.
(http://gnuradio.org/trac/wiki/UsrpTxModifications)

Here are the issues still unresolved that I am aware of:

  • Are the overrun/underrun flag per channel or global? From which fifo
    should they be generated?

  • When a packet is outdated I still have to walk though it to empty to
    skip it. This can be resolved by using a RAM block rather than a fifo
    for the N chanX_fifo be will require more coordination between the USB
    block and the data block.

  • Now I am assuming that the samples are 16bits interleaved, how will
    the sample format chosen by the user be reported to the FPGA?

Thibaud

42

On Sat, Mar 24, 2007 at 05:03:00PM -0400, Thibaud H. wrote:

I updated the wiki paged and added state machines.
(http://gnuradio.org/trac/wiki/UsrpTxModifications)

Here are the issues still unresolved that I am aware of:

  • Are the overrun/underrun flag per channel or global? From which fifo
    should they be generated?

From the channel fifos. Each channel has it’s own idea of
under/overrun. We may choose to “or” them together for reporting.

  • When a packet is outdated I still have to walk though it to empty to
    skip it. This can be resolved by using a RAM block rather than a fifo
    for the N chanX_fifo be will require more coordination between the USB
    block and the data block.

You’re basically building a FIFO that includes a “delete N entries”
feature (effectively “add N to the read address counter”). I suggest
that the write end should look identical to a conventional single
clock fifo interface. Same for the read end, only it supports the
additional feature. Check opencores.org, IIRC they have fully
synthesizable FIFOs there. Absent proof to the contrary, I’d trust
Quartus to infer the appropriate M4K ram blocks and configurations for
the channel fifos.

  • Now I am assuming that the samples are 16bits interleaved, how will
    the sample format chosen by the user be reported to the FPGA?

A per-channel format register, like this:

//

// Tx data format control register
//
// 3 2 1
// 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
// ±------------------------------------------------------±------+
// | Reserved (Must be zero) | FMT |
// ±------------------------------------------------------±------+
//
// FMT values:

#define FR_TX_FORMAT 48

define bmFR_TX_FORMAT_16_IQ 0 // 16-bit I, 16-bit Q

//

// Rx data format control register
//
// 3 2 1
// 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
// ±----------------------------------------±±±--------±------+
// | Reserved (Must be zero) |B|Q| WIDTH | SHIFT |
// ±----------------------------------------±±±--------±------+
//
// FMT values:

#define FR_RX_FORMAT 49

define bmFR_RX_FORMAT_SHIFT_MASK (0x0f << 0) // arithmetic right

shift [0, 15]

define bmFR_RX_FORMAT_SHIFT_SHIFT 0

define bmFR_RX_FORMAT_WIDTH_MASK (0x1f << 4) // data width in

bits [1, 16] (not all valid)

define bmFR_RX_FORMAT_WIDTH_SHIFT 4

define bmFR_RX_FORMAT_WANT_Q (0x1 << 9) // deliver both I &

Q, else just I

define bmFR_RX_FORMAT_BYPASS_HB (0x1 << 10) // bypass half-band

filter

// The valid combinations currently are:
//
// B Q WIDTH SHIFT
// 0 1 16 0
// 0 1 8 8

// Possible future values of WIDTH = {4, 2, 1}
// 12 takes a bit more work, since we need to know packet alignment.

The bmFR_RX_FORMAT_BYPASS_HB should be moved to a different
per-channel register. Right now it’s ignored.

Eric

43

On Sat, Mar 24, 2007 at 05:59:06PM -0400, Brian P. wrote:

  • Are the overrun/underrun flag per channel or global? From which fifo
    should they be generated?

Each channel should be responsibile for returning each individual
status back up to the host. With that given, I believe the messages
should be sent up and identified as stating “TX Channel 0” or “RX
Channel 1” is having over or under runs. That would be helpful,
correct?

Yes, but I’m not sure we can spare the USB bandwidth to report them
separately. I agree we should track them separately. I was thinking
about piggybacking the reporting into the header of RX packets.

WRT clarity, perhaps we should refer to these various fifo like this:

tx_usb_fifo
tx_cmd_fifo
tx_chan_fifo_N

rx_usb_fifo
rx_reply_fifo
rx_chan_fifo_N

Eric

44

I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working on the tx_usb_block.

Here is what I think that could become an issue:

  • The data_bus (used to transfer data between blocks) is 32 bits wide
    which might be an overfill.

  • I don’t do know how hard it is to add the “skip” functionality to the
    Altera Fifo.

Is Quartus Web Edition able to run simulation like ModelSim? It looks
like it can but it wants the inputs to be defined in Vector Wave File
whereas I would rather generate them using my own testing blocks. I
would like to start by writing some testing blocks for the tx_usb_block.

Thibaud

45

Brian P. wrote:

A comment with the USB Block - I believe all the processing going into
the USB FIFO is done within the FX2. Moreover, i don’t know why
you’re keeping the byte_count around - it’s coming in with the packet
header.

Are you sure? I thought the FX2 was only buffering the packets, and is
communicating with the fpga through the 16 bits wide usb_data bus.

Byte_count is how many byte from the current packet have been already
received. I need it to skip the padding and to know when the packet is
completely stored in usb_fifo, because packets are processed only when
they are complete (that’s why I also keep track of the number of
complete packet in usb_fifo).

Each channel should be responsibile for returning each individual
status back up to the host. With that given, I believe the messages
should be sent up and identified as stating “TX Channel 0” or “RX
Channel 1” is having over or under runs. That would be helpful,
correct?

Eric, suggested to just OR all the chanX_fifo_{underrun, overrun} and
consider the E and S flags are per channel. I think it’s a good
compromise between complexity and accuracy. What about you?

Being able to skip over an entire packet if the over or underrun
happens, is extremely helpful and should be implemented. We can have
a modified FIFO possibly with a way to “skip” a specific number of
packets? That would be interesting and easily implementable within
your state machines.

Yes, I think that adding the skip functionality to the Altera fifo is
easiest solution.

There is a command that is sent down to the FPGA and can be set in a
mux. The “format” should be passed into the processing FSM and
handled there. It’s a good question - no real idea right now how to
handle this.

Ok, so it won’t modify the state machines, it will just add a switch
statement when the samples are sent to txX_chain.

Good job so far. It’s probably just me, but those FSMs just seem a
little busy and a little confusing. I’ll figure them out soon enough.

Yes, I made them with Dia, that probably not the best tool for that. If
you know any better tool that works on Linux, let me know. I drew the
conditions and actions associated with each transition, is that too
much?

Brian

Thibaud

46

Brian P. wrote:

Looks cool to me.

32-bits should be OK. What problems do you think you may have an issue
with?

None particularly. There is no 32 bits wide bus in the fpga currently,
so I thought that it might use too many connections.

You will probably have to create your own FIFO from the lopsided RAM.
I don’t think there is a way to infer a RAM where side A is a
different size than B. The skip functionality is pretty straight
forward, and you probably just need empty and full flags. That
shouldn’t be difficult.

Ok.

They have a version of ModelSim you can download and use the Altera
blocks all for free. I’d recommend just using that and not going
through the Altera tool. Write a normal testbench and test out that
FIFO.

I’m downloading it :slight_smile: .

If you need me to verify any results or help with any of your coding,
just ask. I have ModelSim along with the Altera tools available to
me.

Thanks. I’m sure I will need your expertise.

Brian

Thibaud

47

On Mon, Mar 26, 2007 at 03:15:22PM -0400, Thibaud H. wrote:

I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working on the tx_usb_block.

OK, sounds good.

Please create yourself a developer branch by copying the
features/inband-usb
branch.

Eric

48

On Mon, Mar 26, 2007 at 03:15:22PM -0400, Thibaud H. wrote:

I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working on the tx_usb_block.

Hi Thibaud,

On the UsrpTxModifications page you show tx_usb_fifo being 16-bits in,
32-bits out. tx_usb_fifo also requires two clocks. This
configuration isn’t supported (see “Cylone Device Handbook”, section
III, Memory)

This arrangement should work fine:

tx_usb_fifo: 16 bits in, 16 bits out, two clocks

tx_chan_fifo_X: 16-bits in, 32 bits out, one clock

tx_cmd_fifo: 16-bits in, 32 bits out, one clock

Eric

49

On 3/26/07, Thibaud H. [email protected] wrote:

I updated the wiki page
(http://gnuradio.org/trac/wiki/UsrpTxModifications) again, added the
command block FSM and renamed the fifos as Eric proposed. If nobody see
any major problem, I can start to implement these modifications by
working on the tx_usb_block.

Looks cool to me.

Here is what I think that could become an issue:

  • The data_bus (used to transfer data between blocks) is 32 bits wide
    which might be an overfill.

32-bits should be OK. What problems do you think you may have an issue
with?

  • I don’t do know how hard it is to add the “skip” functionality to the
    Altera Fifo.

You will probably have to create your own FIFO from the lopsided RAM.
I don’t think there is a way to infer a RAM where side A is a
different size than B. The skip functionality is pretty straight
forward, and you probably just need empty and full flags. That
shouldn’t be difficult.

Is Quartus Web Edition able to run simulation like ModelSim? It looks
like it can but it wants the inputs to be defined in Vector Wave File
whereas I would rather generate them using my own testing blocks. I
would like to start by writing some testing blocks for the tx_usb_block.

They have a version of ModelSim you can download and use the Altera
blocks all for free. I’d recommend just using that and not going
through the Altera tool. Write a normal testbench and test out that
FIFO.

Thibaud

If you need me to verify any results or help with any of your coding,
just ask. I have ModelSim along with the Altera tools available to
me.

Brian