We should move this to the usrp-users list since this has no gnuradio
content. I’ve added it to the cc list.
On 05/04/2011 02:01 AM, Alexander C. wrote:
On 04/22/2011 07:05 PM, Almohanad F. wrote:
IRQ, or user-space processing?
is if it can push>=12MSPS, i.e. if it’s throughput is 24e6 words/sec
I don’t remember of the top of my head. On a loopback test, I see about
2 MSPS, which means 2 MSPS go into the PFGA and 2 come back. There is a
test program that lets you set a decimation and the looks for drops for
testing one way transfers. 90% of my work has revolved around
correctness to this point.
The Read and Write cycle times are 17 clocks at the moment (L3 Clock
rate is 166 Mhz). So that is 102 nS per sample if everything else is
perfect. See arch/arm/mach-omap2/board-overo.c for the gpmc config.
(This setup move to u-boot at some point)
any number of samples - does it reside at some higher levels?
The driver does have a concept of 2048 buffers. This could easily go to
4K buffers since the ring buffer is allocated via get_free_page. It
could be bigger if you allocated contiguous pages so you had larger than
4K physical blocks of memory. The majority of the complexity of the
driver is creating buffers usable by the DMA system that can be mapped
into user space and dealing with cache management.
- There is a delay getting interrupts after the fpga signals data ready via
GPIO. This is not huge, but for high rates it hurts. I’m not certain where
the delay is (gpio interupt controller, or kernel interrupt handler).
Could we transfer in bigger packets to reduce GPIO overhead?
Yes. This will reduce the percentage of time you are waiting on the
plan to use TMS320C6A8167, and then move towards C66x.
Even though the PFGA is tightly coupled to the OMAP, anything you can do
in the FPGA will help I know it is hard to do processing in the FPGA
than a processor, but the FPGA is really good at the high rate stuff.
- If I was smart about the DSP (I’m not), having the DSP take the data from
the FPGA and reduce the rate should help also.
Do you mean C64x DSP in Gumstix? I’m not sure I get this.
Yes. Basically, instead of having the ARM control the interface to the
FPGA, have the DSP (in the OMAP) do it. Then pass processed data to the