Re: [Discuss-gnuradio] USRP packet parsing

[Thibaud Hottelier]

Brian Padalino wrote:
> On 3/22/07, Thibaud Hottelier <address@hidden> wrote:
> > Yes, I forgot that the packet are ordered by timestamps, which solved
> > the fragmentation issues. However I cannot find an Altera RAM
> > megafunction that provides more that two independent ports. This is not
> > enough and will prevent the FPGA from processing packets (that have the
>
> You cannot have more than 2 ports on their RAM.  It is wired up as a
> dual-port RAM at most.  Use a FIFO for each channel as they are
> independent from each other anyway.  Moreover, if you get it working
> for 1 channel, instantiating the rest of the chain for 2, 3, N
> channels is as easy as a for loop.

I can copy the sample to a fifo, but I still have 3 processes that want 
to use the RAM a the same time: One to progressively store the packets 
coming from the usb bus, one to copy the samples into the corresponding 
channel fifo and one to copy the subcommands to be executed now. So, if 
I am not mistaken I will have to find a way to synchronize the two last 
processes, right?

> > I think sending one packet per transmit window in the most common.
> > However I remember having read somewhere on the wiki what the maximum
> > transmit is but I cannot find it again.
>
> I am not really thinking about the rates, but more the mechanism as to
> how it will be compared.  What will the state machine look like?  What
> is the length of 1 tick?  How will it operate to make sure it can send
> everything properly?  If a FIFO gets half empty, how quickly can we
> get more samples to send out of modulated data?

I can write and read from the fifo at the same time, so one process 
would be in charge of filling the channel fifo. Two states: either wait 
for the timestamps to match the time, or proceed a copy of the samples 
from the ram to the fifo. The problem is if there are more than one 
channels, then this process can be busy filling in channel 1 fifo while 
channel 2 fifo is empty. I don't know how to solve that.

For instance the packets for one channel can stack up in ram until it's 
full, preventing any other channel to receive data.

> Things like that.
>
> Brian