[Top][All Lists]

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

Re: [Discuss-gnuradio] USRP packet parsing

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Wed, 21 Mar 2007 16:04:16 -0400

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.

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.


reply via email to

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