Re: [bluetooth] Internal buffer

[Jamil Khatib <jamilkhatib75@yahoo.com>]

OK we agree to have two FIFOs one for Tx and one for
Rx.
Each FIFO is of the maximum frame size.
If single packet payload to be stored in teh buffer we
need about 345Bytes for each channel. This buffer can
be implemented using two ESB (memory blocks) of Altera
FPGAs using dual port memory core. This is not much
memory resource of such FPGA (only 16% ESB resources
of smallest Altera APEX fpga)
I think the size is suiatable for Xilinx FPGAs also.


We need to make sure that new packet is ready in the
system when we receive ACK on the previouse packet.
this means that the we should store to packets always
or let teh backend interface (CPU) operate at high
clock rate compared to the Tx or Rx clock (this needs
to be checked carefully)

I suggest also to put hte buffer at teh RF side (i.e.
to buffer TX packet after performing all header
operatins and Rx before)

We should store the packet length in order to decide
if it is going to take more than time slot


Regards,
Jamil

> [Ling] In the bluetooth spec, there is an reference
> implementation for the
> Rx/Tx buffer. It allocate two buffers for both Rx
> and Tx end. Of course, it
> is a very simplified method without thinking of cost
> reduction. This depends
> on how to we split Link Controller implementation,
> partially in software or
> totally in hardware. Link Contoller(LC) is
> reponsible for physical link
> layer error free transmission. Actually I prefer to
> implement LC in hardware
> totally, otherwise, the highly coupled interrupt and
> timing requirements
> will make the interface with upper layer a mess. LMP
> can be do in a simple
> RISC. Of course the RISC also handles bigger buffer
> management and HCI. Once
> the packet is handled from upper layer to Link
> Controller, the Link
> Controller will be fully responsible for packet
> transmittion, even for
> multi-slot packet, it will be clean the upper layer
> only transmit to LC once
> in the packet boundry since it won't have concept on
> slot or
> re-transmission.  I support to build two buffers for
> each Rx/Tx end. It is
> clean and can separate the layers well. Otherwise,
> the FIFO can be saved,
> more RAM will be needed in upper layer, more over,
> more interaction will
> occur between HCI and LMP and LC. Of course, all of
> above is based on
> assumption that LC will be done in hardware logic
> fully. If anyone prefer a
> more software oriented approach, the thinking might
> be different.
> 
> > as a result do we need to have a single buffer to
> stre
> > a single ACL packet? or to have two buffers one to
> > store multiple packets and teh other to be used at
> the
> > output and retransmission purposses?
> 
> [Ling] The buffer handling will be very serious in
> Connection state, and it
> is highly related to link efficiency.
> 
> > One extra thing do we need this buffer to combine
> > packets that spans more than single time slot or
> just
> > senddirectly each packet fragment to thehigher
> layers?
> 
> [Ling] If we want to hide the re-transmission thing
> from upper layer, we
> need to handle the mult-slot packet wholely before
> we hand over to upper
> layer. I prefer a bigger mult-slot FIFO for a clean
> design between layers.
> At least, in the beginning stage. We can live the
> room for later tweaking
> targeting for low cost...
> 
> Regards,
> -Ling
> 
> --
> To unsubscribe from bluetooth mailing list please
> visit http://www.opencores.org/mailinglists.shtml


__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml