Questions about hop selection

NOUR Hop Selection Block
------------------------

    These are some notes concerning the operation of the NOUR hop selection
functional block.  This description is being done in order to aid the 
implementation of an emulation tool to be used while developing NOUR.
Information here relies heavily upon the information in the Bluetooth V1.1
Spec, in particular section 10 of the Baseband Specification.  It also relies
heavily on the information in the document "NOUR: The Bluetooth Baseband
Controller IP Core" (http://www.handasarabia.org/document.php?id=83).

    I have some questions about the operation of the NOUR system with respect
to the division of tasks between the microcontroller and the dedicated
functional blocks.  I'm hoping that I will be able to describe particularly
where those questions lie, and either fix my understanding or address any
shortcomings in the interface there might be.  I'm probably just not
understanding something :-)


Connection States
-----------------

    The state diagram (figure 10.4 on page 95 of the Bluetooth Spec v1.1)
lists the major states a system can be in.  What I'm going to try to do is
describe navigation through those states using operations on the registers
given in the NOUR specification.

Standby -
    No problem, we can skip this.

Page Scan -
    Entry into this state is obvious enough, the controller sets state '100'
    in bits 0-2 of register BB_CTRL.  My question here regards how movement
    through the 'slave response' and into the 'connection' state are done.  I
    can envision both schemes where the microcontroller is involved and where
    it is not involved.  Based on what I see in the NOUR spec I believe the
    goal was to not involve the uC in the transaction at all.  If the
    correlator matches against the device access code the page response is
    sent automatically and the module enters a transparent 'slave response'
    substate.  I'm assuming that the registers TIME_PreConn and TIME_Newconn
    are used to manage these substates.  But what I'm not sure about is the
    role of these registers.  Are they meant to be threshold values set by the
    uC and never directly used?  Or are they active timers which the uC uses
    to track state?  If they're meant to be used by the uC we need a way for
    the uC to be notified of entry into the slave response substate.  We
    probably also want a bit in the interrupt source register for these
    timers, so that the uC can set and forget, rather than polling timeouts.

    If the FHS packet is received within timeout, the module is moved from the
    'slave response' state into the 'connection' state.  I believe
    notification of this event is signalled using the 'Page request' bit of
    the Int_Src register.  However, what are the settings for bits 0-2 in
    BB_CTRL and bits 0-2 in Conn_CTRL?  Should we have a setting for connected
    mode in the BB_CTRL register?  Or an 'unconnected' setting in the
    Conn_CTRL register?  Because what happens if we don't get a POLL packet
    within the timeout?  We want to go back to Page Scan mode, but as far as
    these registers are concerned we're already in scan mode.  Do we just
    transfer through Standby explicitly?

Page -
    My questions and comments for this mode very closely parallel the Page
    Scan mode, with the addition that I think we need to put the device class
    in a register if the FHS packet is to be composed outside the uC.  There
    seem to be a number of references to DIAC in the registers, maybe I just
    missed the field used to set the class a device pages as.  It can't be
    FAR_BD_ADDR0, can it?  That's the address being paged for.

Inquiry Scan -
    This would be pretty easy to handle completely within the dedicated blocks
    except for the RANDom holdoff time in the inquiry response messages.
    Frankly, I think that part of the spec seems a bit weak.  But who am I to
    criticize? :-)  If we aren't involving the uC in the inquiry response
    substates I think we need an explicit technique to manage that holdoff
    time.  Or was the plan to just ignore the state transitions there and
    sleep for 0 to 1023 slots while staying in the inquiry scan mode?

Inquiry - 
    I think the plan here is to pass out the address in FAR_BD_ADDR0 and
    FAR_BD_ADDR1 and the clock in INQ_ECLK.  Now, I know it should be pretty
    easy for the controller to pick up these registers could change due to a
    new packet.  But still... there's no way to acknowledge that the
    information has been handled.  Once the Inquiry Request bit is set in
    Int_Src, there should be a way to signal to the base that the controller
    has picked up the inquiry information.

Connection -
    I haven't read through all the details here yet, so I don't have any
    comments yet.  I think I might have some questions about the use of the
    timers for the different substates like park and sniff.  But before we get
    too deep into that I want to take a look at the other states first.  I
    might get my questions answered in going through them.


The Controller
--------------

    Mostly I've assumed that the operations involved in moving through the
states are taken care of without much involvement by the controller.  If we
are going to involve the controller in some of them, I think we need to add
some additional states to the register set and perhaps a few interrupt
sources.  I'm assuming that putting all the control of the hop selector within
the dedicated functional blocks we probably derive a lot of benefit with
respect to having the maximum amount of time to tune to the next hop and
conserving power.  But in order to make sure that we keep the system well
ordered we should probably make some specific rules about which transmissions
make it up to the controller as data and which are handled entirely outside
the intervention of the uC.  Say, any packet not part of an active connection
should be processed entirely according to dedicated register functions.  That
way we have good guidelines along which to tune our functional division.