[Top][All Lists]

[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: Thu, 22 Mar 2007 11:24:37 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

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.


reply via email to

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