Notes about NOUR register emulation

Simulation of the NOUR Register Set
-----------------------------------

    These notes build upon the RF Link simulation notes posted to the NOUR
mailing list during June of 2003 (See message index #17, subject "Some notes
about RF emulation").  This document attempts to begin describing using the
low level operations described in that email to simulate the register set
described by Jamil Khatib in the document "NOUR: The Bluetooth Baseband
Controller IP Core" (http://www.handasarabia.org/document.php?id=83).

    The goal of this simulation block is to provide validation of the register
set described in the NOUR document.  The register set must be proven sufficient
to implement the Bluetooth functions as detailed in section 1.1 of the NOUR
document.  A secondary goal is to provide a base set of registers which an
emulated microcontroller can interact with in order to simulate a full NOUR
module.

    From the point of view of "the registers" themselves, there are really
only two inputs.  The first is the radio.  Bits coming in from the outside can
cause update of the register state if we're reading, and use of the RF slots
can cause update if we're writing data.  The other source of input is the
 microcontroller accessing these registers.  This is how the emulator should be
structured.  There is no real asynchronous operation within this block of
emulation.  It takes action either based upon the tick of time from the RF
layer, or action from the microcontroller.  Apart from the initial startup
process, this block should be completely passive.  It never initiates an action
on its own.

    In terms of interaction between implementation units the interfaces should
be relatively simple.  The messages passed to/from the RF link daemon have 
already been partially defined.  Access by the microcontroller into the 
registers should be able to follow a simple function call interface except 
for the cases in which the baseband can signal interrupts for the controller.
Even though the register emulation itself never generates async events, events
from the RF layer might need to be passed up to the microcontroller without
having the controller initiate the request.  In this case something like a
callback needs to be provided from within the microcontroller side of the
emulation.  This can actually be implemented by the controller side as a poll
of interrupt status within the baseband, but it must be an action scheduled at
least once every radio clock TICK.


- Startup

    The emulator must set the clock registers (CLKN and CLK) and the local
address registers (LOC_BD_ADDR0, LOC_BD_ADDR1, and LOC_ADDR) before
connecting to the RF Link emulation daemon.  Once the registers are initialized
the clock registers should be updated in step with the TICK messages from the
RF Link layer of the emulator.  The emulator must track and count the RF TICKs
so that the CLK ticks can be incremented every 625 TICK messages, and so that
the CLK1 bit of the interrupt source register can be set appropriately.

    Once the system has connected to the RF daemon it can choose to enter
other states based upon the setting of the state control field in the BB_CTRL
register.  Note that much of the significant interaction done in these
stages of setup is still triggered by a read from the radio.  Even if the
device is in Page or Inquiry mode, the emulated registers care little about
the write stages of these processes.  They change state upon receipt of a 
packet in response to the write operations.


- Hop selection

    I had some questions here based upon the division of responsibility between
what is driven by the microcontroller and what is provided automatically within
the dedicated functional blocks.  I'm assuming tuning of the radio to a
specific channel at each slot is provided by a dedicated functional block 
based upon the mode of the module and the addresses and clock values 
configured.  But I'm a little hazy on what the process would be for the
different operations.  Say the device is acting as a master within a piconet,
and wants to accept a connection from a new slave.  Is everything about 
setting up the connection except for assigning a new member address taken care
of without the involvement of the microcontroller?


- Input data path

    Once attached to an RF link daemon, received bits start getting shifted
into the simulated Access Code correlator.  Configuration of the correlator
needs to be done based upon the mode of the module (and therefor what access
codes it should respond to).  But once configured for the proper mode this
block operates relatively independently.

    If a match is found in the access code, received bits must start getting
shifted into the data path for construction of a packet to pass up to higher
levels (see Figure 3 from the NOUR document).  Once a full packet has been 
received the condition is signaled by setting Bit 1 of the Int_Src register.


- Output data path

    This should consist of just shifting one bit at a time out of the output 
stream.  There's a lot in those functional blocks though.