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

Re: [bluetooth] Internal buffer



> Hi all,
> I'd like to continue discussing FIFO size and location
> in hte Baseband controller
>
> As far as I know that the LC should provide error free
> communication to the higher layers. It is responsible
> for retransmitting lost packets (ACL) and higher
> layers should not notice this.
> So LC should store the packets to be transmited in
> internal buffer and the stored frame will be removed
> only when it is asknowledged.
>
[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