Re: Proposal for register validation technique

Hi,
I am so sorry for teh delay.
You have a good idea. I think we can use it also to verify our design by
combining it with System Verilog.

Once you start the design you may find some missing reigsters or bits.
Do you think that once it is done we can connect it to BlueZ stack?

Can you please give us a small document on how you are planing to do
everything?

Regards,
Jamil Khatib

On 6/16/2003, "Mike Rowehl" <[email protected]> wrote:

>Hello all,
>    We've started speaking about validating the specification of the
register
>set for the NOUR project.  Right now no one has stepped forward who has
>previous experience with bluetooth firmware, so I'm proposing a technique
for
>simulating the radio in software and helping us to get started working on
the
>algorithms and organization for firmware based on this register set.
>    The BlueZ project for Linux (http://bluez.sf.net) provides something
called
>hciemu that can be used for testing.  hciemu effectively creates "virtual"
hci
>interfaces.  These interfaces communicate with each other by passing around
>messages at the granularity of HCI events.  It allows a way to experiment
with
>and test the upper layers of their stack without having physical devices
>present.  My proposal is to extend this existing work to create a NOURemu
>device that can be used with BlueZ.
>    The NOURemu device would accept HCI events from the upper layers of
BlueZ
>and run the request through our firmware.  Two or more NOURemu devices
could
>then communicate with each other by exchanging data at the level of
register
>updates.  I haven't yet worked out any of the specifics such as how to
>represent information exchanged between the two devices, or if the radio
link
>should be simulated or emulated, or if the 'firmware' in the emulated
device
>should run through a CPU simulator for the microprocessor we choose to use
in
>the design.  If there is interest in this idea those are points I think we
can
>work through in the implementation.
>    Significant points I think support organizing like this:
>
>- It gives us a method for immediately starting to move forward with work,
we
>  already have the specification of the register set and access to the
existing
>  work in BlueZ.
>- It allows us to start development of the algorithms needed for the
firmware
>  in a very 'friendly' environment.
>- We can incrementally implement the emulation layer.  We start out with
hciemu
>  devices and start working in subsets of the registers controlling
functions
>  we're interested in testing.  The hci transport is used for the stuff we
>  don't have implemented yet, and we can test subsections while still having
a
>  fully functional emulation environment.
>- By involving a working implementation for the upper layers of the
protocol
>  stack we hopefully can avoid oversights in the host side of the
integration.
>
>At present this is the best idea I've come up with to help Jamil get
validation
>for the excellent work he's done on the specification so far.  I would be
happy
>to take the lead in starting the device emulation project if we think that
it
>would provide a good technique for advancing.
>
>Comments?  Concerns?  Criticism?  Let me know.
>                                                  Mike
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: nour-unsubscribe-bZJqt4gKw0dwc45b+y0WwMLKnirKmNT7@public.gmane.org
>For additional commands, e-mail: [email protected]
>Handasa Arabia, http://www.handasarabia.org

---------------------------------------------------------------------
To unsubscribe, e-mail: nour-unsubscribe-bZJqt4gKw0dwc45b+y0WwMLKnirKmNT7@public.gmane.org
For additional commands, e-mail: [email protected]
Handasa Arabia, http://www.handasarabia.org