Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
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? 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). 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. Philip Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
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
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
I've been working on adding USB1.1 (full speed) support to the USRP software/firmware so I can use it with a TI OSK board. I've been going back and forth with Matt on some issues and we are getting out of his area of expertise. Here is summary of progress to date. After modifying the 8051 code I had the following behavior: When I compile the code for the OSK, I see two symbols transmitted, then dead air. Two symbols is 64 bytes (2 symbols x 8 sample/symbol x 4 bytes/sample), then there are 512 - 64 bytes of no signal. It feels like the 64 byte packets are read into a buffer of 512 bytes, where all the un-written bytes are zeros. It feels like somewhere in the USB chain, I send the 64 byte packet, then something reads the 64 bytes and zero pads the packet to 512 bytes. I suspect the FPGA tries to read 512 bytes from the FX2 chip, but that is only because this is the area of the code I least understand :) Matt suggested the following FPGA change, and I also chnaged a similar construct a few lines further on: http://gnuradio.utah.edu/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/tx_buffer.v And look at line 94, you will see the test for end of packet. write_count[8] goes high when we have put 256 elements (512 bytes) into the fifo. You would need to modify this to write_count[5] which will go high when 32 elements (64 bytes) have been put into the fifo. This results in: Well, it looks like data is coming out, but it looks like I get 64 bytes out, then there is a hiccup about 5 microseconds long. I am getting suspicious the OSK doesn't get the data on the USB bus fast enough. I'm still not entirely clear how the FX2 works. I am wondering if there is a way to let the buffers in the FX2 chip fill up more before the FPGA starts pulling data from the FX2. The OSK has a 192 MHz ARM9 processor. i have looked through the 8051 code for packet size dependencies and can't fins any I haven't aready tried to address. Does anyone else have any thoughts? Thanks, Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
Well, it looks like data is coming out, but it looks like I get 64 bytes out, then there is a hiccup about 5 microseconds long. I am getting suspicious the OSK doesn't get the data on the USB bus fast enough. What is the source of the data you're transferring over the bus? If it is coming faster than USB1.1 can handle, of course you'll see hiccups where data is dropped. (The USB2 firmware/fpga sets a flag that the software can read when this happens -- that's what produces those U dribbles on the terminal sometimes.) I think there's a way to select a counter in the FPGA that just transfers an incrementing number in each outgoing USB packet. (Perhaps it's a different FPGA load instead of a settable flag in the main version.) This was used to debug similar issues between the FPGA and the FX2, and between the FX2 and the software library. Alternatively, you can decimate the source down to a very low data rate, so it won't overflow. Get the rate as low as you possibly can, for debugging. (Or, if there's a demodulator in the FPGA, you could e.g. have it tune an FM radio station, demodulate it on-chip, and transfer only the audio over the USB bus, which would be well within its available bandwidth. But I don't think anybody has coded that FPGA transform... yet.) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
On Thu, Dec 07, 2006 at 08:48:54AM -0500, Philip Balister wrote: I've been working on adding USB1.1 (full speed) support to the USRP software/firmware so I can use it with a TI OSK board. I've been going back and forth with Matt on some issues and we are getting out of his area of expertise. Here is summary of progress to date. After modifying the 8051 code I had the following behavior: When I compile the code for the OSK, I see two symbols transmitted, then dead air. Two symbols is 64 bytes (2 symbols x 8 sample/symbol x 4 bytes/sample), then there are 512 - 64 bytes of no signal. It feels like the 64 byte packets are read into a buffer of 512 bytes, where all the un-written bytes are zeros. It feels like somewhere in the USB chain, I send the 64 byte packet, then something reads the 64 bytes and zero pads the packet to 512 bytes. I suspect the FPGA tries to read 512 bytes from the FX2 chip, but that is only because this is the area of the code I least understand :) Unless your FX2 code sets up the transfer size to 64, then this is probably what is happening. That is, the host is sending 64 bytes, but the FX2 is ignoring the real length, and is assuming that it's 512 bytes. Or see below, about the GPIF DMA program still tranfering 256 16-bit values. Matt suggested the following FPGA change, and I also chnaged a similar construct a few lines further on: http://gnuradio.utah.edu/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/tx_buffer.v And look at line 94, you will see the test for end of packet. write_count[8] goes high when we have put 256 elements (512 bytes) into the fifo. You would need to modify this to write_count[5] which will go high when 32 elements (64 bytes) have been put into the fifo. This results in: Well, it looks like data is coming out, but it looks like I get 64 bytes out, then there is a hiccup about 5 microseconds long. I am getting suspicious the OSK doesn't get the data on the USB bus fast enough. I'm still not entirely clear how the FX2 works. I am wondering if there is a way to let the buffers in the FX2 chip fill up more before the FPGA starts pulling data from the FX2. 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 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. Philip, do you have access to a logic analyzer? It would extremely helpful for determining what's really happening between the FX2 and FPGA. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and USB full speed (1.1) transmit
Philip Balister wrote: I've been working on getting the usrp working with a USB full speed interface connected to an OMAP starter kit (OSK) board from TI. I'm not using GNU Radio, but the OSSIE open source SCA. The OSK only has a USB 11 controller that sends 64 byte packets, not the 512 byte packets sent by USB2.0 high speed interfaces. The code I have uses the usrp-0.12 package to communicate with the USRP. This email is mainly of interest to people interested in low level USRP interfacing and the FPGA to FX2 interface. I have a waveform that generates random BPSK that works fine on a PC with is USB high speed interface. The output is raised cosine pulse shaped and I monitor it on a Tektronix signal analyzer. When I run the waveform on a PC with a USB2.0 hidg speed interface I see a good eye diagram. When I compile the code for the OSK, I see two symbols transmitted, then dead air. Two symbols is 64 bytes (2 symbols x 8 sample/symbol x 4 bytes/sample), then there are 512 - 64 bytes of no signal. It feels like the 64 byte packets are read into a buffer of 512 bytes, where all the un-written bytes are zeros. It feels like somewhere in the USB chain, I send the 64 byte packet, then something reads the 64 bytes and zero pads the packet to 512 bytes. I suspect the FPGA tries to read 512 bytes from the FX2 chip, but that is only because this is the area of the code I least understand :) Philip, If you go to http://gnuradio.utah.edu/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/tx_buffer.v And look at line 94, you will see the test for end of packet. write_count[8] goes high when we have put 256 elements (512 bytes) into the fifo. You would need to modify this to write_count[5] which will go high when 32 elements (64 bytes) have been put into the fifo. You probably also need to modify some firmware. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
