Problem with data reception from FPGA - GPIF buffer sizes?

Having issues with the site, hardware, source code, or any other issues?
Post Reply
ifrasch
Posts: 11
Joined: Mon Apr 11, 2016 12:41 pm

Problem with data reception from FPGA - GPIF buffer sizes?

Post by ifrasch »

I've got a custom FPGA image where I don't continuously receive samples (by design); instead my design generates exactly 11125 output samples in each iteration - meaning the in_valid signal on the fifo_writer block is asserted for 11125 cycles. On the host side I've configured libbladeRF's synchronous interface for the minimum buffer size of 1024 samples. Since 11125 is not a multiple of 1024, in the FPGA I sent extra dummy samples (by asserting in_valid) so that I would fill the last buffer (11*1024 = 11264 samples sent, total).

The problem is this isn't working. When I receive samples at the host with bladerf_sync_rx(), I only receive the first 10240 samples before it times out. The last buffer of 1024 samples doesn't make it to the host. I've looked at it with SignalTap and I'm pretty sure my design is sending exactly 11*1024 output samples to the FIFO.

So I must be missing something here regarding the FPGA GPIF/DMA interface. Is there a different buffer size I need to fill in the FPGA? Which buffer size should I be trying to fill in the FPGA, so that all my samples are guaranteed to make it from the RX FIFO to the host?
bglod
Posts: 201
Joined: Thu Jun 18, 2015 6:10 pm

Re: Problem with data reception from FPGA - GPIF buffer size

Post by bglod »

This kind of sounds like an "off by one" problem somewhere. If you TX another 1024 "zeroes", does it work?

In your SignalTap, did the rx_sample_fifo have the missing 1024 samples in it at the time of the timeout, or do those samples simply never show up? If they don't show up, it could be a TX issue. Are you using metadata? Is the metadata correct?

There's a lot going on in the fx3_gpif.vhd state machines, could be something in there. Pay particular attention to the FIFO used signals and what causes the FIFOs to be read/written. There are some thresholds that may not be triggering the appropriate action. I suggest following the TX/RX paths in fx3_gpif and then SignalTapping the relevant FSM state signals and anything that leads to a state transition. You can enable conditional storage and use a smaller sample depth in SignalTap if you find that you're monitoring too many signals and run out of block RAM.

If that doesn't really tell you anything, you can also take a look at the NIOS. Some signals are accessible via SignalTap, but the Eclipse debugger will be more useful. Instructions are here.
Electrical Engineer
Nuand, LLC.
ifrasch
Posts: 11
Joined: Mon Apr 11, 2016 12:41 pm

Re: Problem with data reception from FPGA - GPIF buffer size

Post by ifrasch »

Thanks for the suggestions bglod. You're probably right about it being an off-by-one problem. But instead of continuing to debug this, I decided to change my design so that I continuously receive samples.

After one iteration of the detector, it immediately moves on to the next iteration inside the FPGA instead of sending a specific number of samples to the host and then waiting for the host to tell it to move to the next iteration. This way I don't have to pad with extra samples :) . Works fine now!
bglod
Posts: 201
Joined: Thu Jun 18, 2015 6:10 pm

Re: Problem with data reception from FPGA - GPIF buffer size

Post by bglod »

Sweet!
Electrical Engineer
Nuand, LLC.
Vzz
Posts: 1
Joined: Tue Mar 20, 2018 2:11 am

Re: Problem with data reception from FPGA - GPIF buffer sizes?

Post by Vzz »

Hi.

I have a similar problem to what ifrasch had. In my implementation I'm trying to send exactly 1024 samples each iteration from the FPGA.

What I've noticed is that the fifo-used limits for a transaction to begin dosn't add up with 1024 samples as seen here.
https://github.com/Nuand/bladeRF/blob/0 ... #L171-L181

If my understanding is correct then a transaction begins when the fifo contains more than 512 words. That means the first transaction begins at 513 words and you'll end up with the rest of the samples not being transferred.

Unfortunately my JTAG is having some issues so I havn't yet been able to debug this in any detail with signal tap. But some initial testing seem to confirm this behaviour.

Am I missing something?

Regards, Victor
Post Reply