Re: [Discuss-gnuradio] USRP packet parsing

[Eric Blossom]

On Sat, Mar 24, 2007 at 05:03:00PM -0400, Thibaud Hottelier 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