discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USRP packet parsing


From: Thibaud Hottelier
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Wed, 21 Mar 2007 15:24:39 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

So, if I have correctly understood, I would use dual_clock ram component (altsyncram for instance) and only pass the packet address (and maybe its length) to the next block. If the whole packet (including padding) is stored in the RAM then it's easy because all my memory block are the same size, but if I have different packet length then it becomes hairy to deal with because there are RAM fragmentation issues. Is it ok to store the padding to simplify the processing ?

Eric Blossom wrote:
On Wed, Mar 21, 2007 at 12:45:00PM -0400, Thibaud Hottelier wrote:
How do the fpga know is data is interleaved or not ?

I am still worried about the number of fifo that will be used and their size. The FPGA looks pretty full. Is there a way to have a memory separated from the FPGA that I could access through a bus?

Thibaud

I'm not sure you need all those fifos.  It seems that after the first
fifo (which gathers the packet and spans the two clock domains), that
rest of the movements are effectively "change of ownership", with no
need to recopy all the data, perhaps only the identifier of the
particular packet and it's length.

That is, perhaps think about splitting the RAM into max packet sized
blocks (512 bytes), then pass the ownership of the packets around as
needed.  Another way to think about this is to assume that you've got
say 4 packet buffers, numbered 0 through 3.  Then you could have a
very small fifo between blocks that contained lines that contained
only the buffer ID [0,3] and the active length of the buffer.


Brian Padalino wrote:
Something else I noticed was with the channel definition stating that
the IQ data is to be interleaved.  This shouldn't necessarily happen
and there shouldn't be a problem with having the block rams be in a
x32 configuration and each location has an IQ pair associated with it.
This would reduce down any complexity when dealing with
deinterleaving the data coming out, and add to the readability of the
code.

Comments?

Brian

I think we have to assume that people are going to be dealing with all
kinds of data formats, probably mostly I & Q, but definitely with
different number of bits assigned to the I,Q pairs.  We already handle
8 and 16, and there are efforts underway to handle 4, 2 and 1 bit
samples.

It's possible to have dual ported ram with the two ports different
widths.  The interface to the FX2 is over the 16-bit GPIF, so that's
the natural size for one port.  32-bits may make good sense for the
other end.

Eric






reply via email to

[Prev in Thread] Current Thread [Next in Thread]