[Top][All Lists]

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

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

From: Andre Puschmann
Subject: Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD
Date: Sun, 04 Mar 2012 16:39:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/04/2012 04:10 PM, George Nychis wrote:
>     I totally like and support your idea and would love to help realizing
>     it. Using the timestamp logic inside UHD as a reference is a great idea
>     that also came to my mind a while ago.
>     There are a few things from the architecture point of view though that
>     need to be discussed. Let's take a CSMA MAC as an example, I guess that
>     goes into the right direction :-) Just having the "if channel free,
>     transmit packet"-logic inside the FPGA wouldn't make much sense in a
>     multi-user environment. What would happen is that if the channel is busy
>     and multiple nodes have packets in their tx queues, they would all end
>     up sending their packets more or less at the same time after the channel
>     gets idle again (assuming all nodes are in sensing range). In a
>     practical system, one would now start to move parts of the CSMA state
>     machine, i.e the random backoff, into the FPGA. Trying to control this
>     via UHD is probably a bad idea as UHD's main business is transportation.
>     I do think we need something like what you have suggested but I am still
>     a bit puzzled about the right way of implementing it.
> Hi Andre,
> Yeppp, the idea is to build part of the MAC in to the FPGA... the part
> that requires low latency operation.  So, after the simple "transmit
> when idle" logic, you put some basic form of back off in to the logic
> also.  
> I have a paper which argues low latency MAC functionality should be
> built in to the FPGA, but controlled from the host, otherwise it's as
> good as worthless implementing it on the host.  If you try to build this
> part of the MAC at the host, the latency of receiving the channel state
> (latency from FPGA -> host), making a decision and performing an action
> (host -> FPGA), completely makes the information stale.  You end up with
> a decision that is something like 1-2ms old, which clearly the state of
> the channel changes at a more finer-grain than that.

Well, I believe it's just a matter of scaling the whole system by the
right factor. Information that is 1ms old can still be valuable if it
still represents the truth.

I just don't want to loose all the flexibility of software by moving the
critical but interesting things to hardware.

But of course, it all depends upon your goals.


reply via email to

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