Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit

[Eric Blossom]

On Fri, Dec 08, 2006 at 08:19:09AM -0500, Philip Balister wrote:
> >
> >Remember that the GPIF is currently set up to DMA 256 16-bit values.
> >Perhaps that part needs changing.  The magic value is probably buried
> >in the WaveData table in usrp_gpif.c
> 
> I looked over the GPIF stuff with the Cypress tool I do not see any
> reference to transfer size in there. I am thinking the transfer size
> is set in the FPGA?

Nope.  The GPIF is in charge of the transfer.  I'm assuming that what
you are seeing is that the FX2 is bursting a 256 word transfer, given
how you have programmed everything.  BTW, I'm not kidding about this
being nearly impossible without a logic analyzer.

What's currently really happening on the GPIF bus?  (Bring out the
relevant GPIF pins to the daughterboard debug headers.)

Looking at page 10-16 (10.3.2.2.2 Decision Point States) of the FX2
Technical Reference Manual (and dusting off my memory), the waveform
decision point is controlled by the "Transaction Count Expired"
signal.  Page 10-24, "LOGIC FUNCTION Register", TERMA and/or TERMB
will be coded as RDY5 (or Transaction-Count Expiration, if
GPIFREADYCFG.5 = 1 (which it is))

See page 10-41, 10.4.3.1 "Transaction Counter".

To use the Transaction Counter for FIFO "x" load GPIFTCB3:0 with the
desired number of transactions.  When a FIFO-READ or -WRITE waveform
is triggered on that FIFO, the GPIF will transfer the specified number
of bytes (or words, if WORDWIDE=1).

See ### HERE ### below (from usrp/firmware/src/usrp2/usrp_main.c):

Are you setting these to 32 instead of 256?  If not, that's probably
the root of the problem.


      // Next see if there are any "OUT" packets waiting for our attention,
      // and if so, if there's room in the FPGA's FIFO for them.

      if (g_tx_enable && !(EP24FIFOFLGS & 0x02)){  // USB end point fifo is not 
empty...

        if (fpga_has_room_for_packet ()){          // ... and FPGA has room for 
packet

          GPIFTCB1 = 0x01;      SYNCDELAY;        #######  HERE #######
          GPIFTCB0 = 0x00;      SYNCDELAY;        #######  HERE #######

          setup_flowstate_write ();

          SYNCDELAY;
          GPIFTRIG = bmGPIF_EP2_START | bmGPIF_WRITE;   // start the xfer
          SYNCDELAY;

          while (!(GPIFTRIG & bmGPIF_IDLE)){
            // wait for the transaction to complete
          }
        }
      }

      // See if there are any requests for "IN" packets, and if so
      // whether the FPGA's got any packets for us.

      if (g_rx_enable && !(EP6CS & bmEPFULL)){  // USB end point fifo is not 
full...

        if (fpga_has_packet_avail ()){          // ... and FPGA has packet 
available

          GPIFTCB1 = 0x01;      SYNCDELAY;       ####### HERE #######
          GPIFTCB0 = 0x00;      SYNCDELAY;       ####### HERE #######

          setup_flowstate_read ();

          SYNCDELAY;
          GPIFTRIG = bmGPIF_EP6_START | bmGPIF_READ;    // start the xfer
          SYNCDELAY;

          while (!(GPIFTRIG & bmGPIF_IDLE)){
            // wait for the transaction to complete
          }

          SYNCDELAY;
          INPKTEND = 6; // tell USB we filled buffer (6 is our endpoint num)
        }
      }


> >Another thing you could try is to set up the GPIF in a non-flowstate
> >mode.  You'd need to use the Cypress tool to do this (or Larry
> >Doolittle's perl (?) code.  Running in full speed, you don't need to
> >be able to burst data at 96MB/sec between the FX2 and FPGA.
> >
> 
> Do you have any idea what sort of changes to the 8051/FPGA code are
> involved? The machines I am using this with do not need high data
> rates (in fact more decimation in the FPGA would be helpful).

Not really.  This is one of those RTFM, and watch with the logic
analyzer games.

> >Philip, do you have access to a logic analyzer?
> >It would extremely helpful for determining what's really happening
> >between the FX2 and FPGA.
> >
> 
> Agreed. Unfortunately, we are a communication group, not a digital
> hardware group. So we do not have a logic analyzer. Of course, these
> days, it is hard to tell the difference between a comm group and a
> digital hardware group.

Unless you get lucky and the modification above labeled "HERE" works,
you're _really_ going to want access to a logic analyzer.  Otherwise
you can't tell what's going on.  There must be somebody in one of the
engineering buildings who's got one you can borrow for a couple of
days.  It doesn't have to be blazingly fast or have a tremendous
number of channels.  32 channels will be more than enough.  You could
get by with 16 if you had to.

Good luck!

Eric