Re: [Discuss-gnuradio] USRP packet parsing

[Thibaud Hottelier]

Brian Padalino wrote:
> On 3/21/07, Thibaud Hottelier <address@hidden> wrote:
> > 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 ?
>
> You really shouldn't need the padding in there since the length of the
> packet is within the packet itself.  The FPGA can use that information
> to process the packet.


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 
same timestamps but use different channels) concurrently.

>
> I suppose we really need to figure out how the timer is going to work
> with the scheduling of the entire system.  Do we really need a 1/64e6
> resolution of commands?  How are we going to control the epoch for
> TDMA systems?  I would think those sort of implementations would
> really drive how this connects up to that system.

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.

> Brian