Re: What is the status of stack HCI and above?
Mohamed Salem <[email protected]> Tue, 26 Aug 2003 14:18:24 +0300
| Newsgroups | gmane.org.handasarabia.nour |
|---|---|
| Message-ID | <[email protected]> |
--=-Jo8/Re3LGn0stuzBg0zH
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi Shrirang,
Thanks for your interest to work in the stack layers that might be a
part of our development in NOUR.
The attached document compiled by "Mike Rowehl" would help you in
understanding the development organization for the bluetooth overall
system from a perspective that might be close to yours , as I guess you
are more into software development ..
please, review the document and feel free to post your queries ..This
would be so helpful to get you a place for the upcoming development
cycle of the project...
Best Regards,
Mohamed A.Salem
On Mon, 2003-08-25 at 11:12, Shrirang Bhagwat wrote:
> Hi,
>
> I work in bluetooth and would like to contribute something in upper layers
> of the stack... What is the current status of the stack?
--=-Jo8/Re3LGn0stuzBg0zH
Content-Disposition: attachment; filename=emulator_initial_06_18_2003.txt
Content-Type: text/plain; name=emulator_initial_06_18_2003.txt; charset=UTF-8
Content-Transfer-Encoding: 7bit
Basic Design of the NOUR Emulator
---------------------------------
Our initial goal is the validation of the register set used to interface
with the baseband functions. Secondary goals include development of the
algorithms used in the module firmware and use as a debugging platform.
Prior art
---------
The BlueZ project provides hciemu, a virtual HCI style interface used for
testing the upper levels of the BlueZ protocol stack without having to use a
physical device. This project provides much of what we want in terms of
framework, but leaves out many details we want to focus on. For instance, the
hciemu tool assumes that once a slave is connected with a master it can
exchange data with the master. But it ignores the details of the operation
of firmware which would be on the module and behavior such as hop
syncronization or interference necessary for the RF link.
Functional Layering
-------------------
Our goal is to add into the emulation environment much of the detail which
was purposefully avoided in the hciemu tool. Our solution should look
something like the following after we have completed the implementation:
+-------------+ +-------------+
| | | |
| HCI event | | HCI event |
| source/sink | | source/sink |
| (BlueZ) | | (BlueZ) |
| | | |
+-------------+ +-------------+
| |
| |
| |
VHCI VHCI
| |
========================================================
| |
| Everything below the double line is |
| part of the "NOUR Emualtor" |
| |
| |
+--------------------+ +--------------------+
| | | |
| Microprocessor/ | | Microprocessor/ |
| Firmware Emulation | | Firmware Emulation |
| | | |
+--------------------+ +--------------------+
| |
| |
| |
RF Register RF Register
Interface Interface
| |
| |
| +--------------------+ |
| | | |
+-------------| RF Link Emulation |-------------+
| |
+--------------------+
If compared to Figure 2 from the NOUR specification:
VHCI = System Interface
Microprocessor/Firmware = PCM Interface
Clock Management
Buffers
System Controller
Register Interrupts
Data path ?
Hop and Access Code ?
RF Register Interface = RF Interface
I'm not sure if Data Path and Hop and Access Code should be part of the
Microprocessor/Firmware layer, or part of the RF interface emulation. I think
we could make it worth either way, but the two techniques would provide
radically different tradeoffs in terms of difficulty to implement and realism
in the emulated system.
A great majority of the complexity lies in the Microprocessor/Firmware
layer. This is a conscious decision based on our initial goal of wanting to
validate the register interface to the baseband as early as possible. It does
present a possible point of risk however, in that design oversights might be
hidden in the monolithic middle layer. It would be possible to further
subdivide the Microprocessor/Firmware layer based on the existing functional
blocks laid our in the NOUR specification in order to mitigate this risk.
VHCI and BlueZ
--------------
The VHCI interface is provided by BlueZ already (/dev/vhci), and it allows
the hciemu devices to register for receipt of HCI events from the upper layers.
This I think can be reused as is.
Microprocessor and Firmware Emulation
-------------------------------------
This layer I think should be left for last in the development process. It
might involve the use of a custom microprocessor emulator or a tool such as
Verilog to simulate the operation of the microcontroller used in the NOUR
design. I believe we can initially use a simple stub layer here. The initial
implementation will manipulate the RF registers and communicate via the VHCI
interface, but need not attempt to emulate the individual functional blocks.
A system which more closely emulates the decomposition of the system components
would probably take more time to initially develop, but would lead to a more
realistic environment.
There still has to be a considerable amount of logic here even if we don't
emulate a microprocessor. But the complexity should be considerably less if
we concern ourselves with just proxying from HCI to NOUR RF registers.
RF Link Emulation
-----------------
I believe this is the core component necessary to realize our main
objective. The RF Link Emulator exists as a single component with which the
individual NOUR emulator devices communicate. The core of the emulator is an
emulated clock running at bluetooth bit speed. The main data objects
maintained are the bit images for each of the frequency slots on which a
bluetooth radio can operate (79 or 23 depending upon configuration). At each
tick of the radio clock the link emulator collects all the bits being written
on each of the channels. If two or more devices are trying to transmit on the
same channel at the same time, the bit is destroyed (we can emulate
interference if we want at some point, multiple piconets sharing the same area,
etc). Then each bit is written into the buffer of any device listening on a
channel which is currently occupied.
Staging Techniques
------------------
There area a few corners we can cut in order to get a minimal system
working end to end. We can skip on the channel syncronization at first and
just assume piconets are synced to the master. We can provide operations
reading and writing through the radio at the byte level instead of the bit
level and not bother running an asyncronous clock. For example, the master
could write to the radio and then pass off to the addressed slave to let it
have a chance to transmit. In effect using the radio like a token passing
mechanism. Techniques like this certainly don't improve the soundness of the
emulation, but could provide us a way to speed up the version 1 implementation
of the project.
We could also implement the NOUR functions in batches and leave the HCI
emulation in place for the unfulfilled pieces. For instance, the HCI emulation
could be used to take care of inquiry/page processing, but we could switch to
a more detailed emulation mode once a link is formed. This would also allow
us to break the implementation into more managable chunks.
--=-Jo8/Re3LGn0stuzBg0zH
Content-Type: text/plain; charset=us-ascii
--------------------------
NOUR Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
Message number 48
--=-Jo8/Re3LGn0stuzBg0zH--