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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
