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

[Andre Puschmann]

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.

-Andre