Re: Feedback on Control architecture

Ravi Ranjan Kumar <raviranjan_kumar-HTy/[email protected]> Wed, 17 Mar 2004 11:59:19 -0500
Newsgroups gmane.org.handasarabia.nour
Message-ID <[email protected]>
Hi Mohamed,
Please find my comments embedded in you mail below.
Thanks and Regards
-- Ravi Ranjan Kumar



---- On 14 Mar 2004 15:36:35, Mohamed Salem
([email protected]) wrote:

> Good document Ravi, My understanding and queries are below
(correct any
> wrong inference please)
> 
> **TxController and RXcontroller are hardware modules that
controls the
> data-path components and its corresponding multiplexers in the
TX and RX
> respectively.
> Each module would be designed as a sequencer or data-flow
manager among
> the data-path elements.
> For instance: in TX, The TXcontroller will decide when to
initialize
> and/or enable the CRC16 component to start processing on the
pay-load
> (plain user-data) coming from the TX buffer; then it informs
that CRC16
> at the end of the user-data by asserting the "Drain" signal
HIGH , and
> also maintain it for 16 cycles which are needed to append the
CRC16
> value from the LFSR to the pay-load.
> and so on for each module according to each processing scheme.
> 

Ravi>> You are very much correct.

> **The micro-controller will have a firm-ware (c-code) which
should be
> simple (due to moving much of the control actions to the HW
> controllers),and the Ucontroller should be like a manager of
the HW
> controllers actions. (I need an example for this scenario from
your
> side) to point out for instance how the Ucontroller manage the
actions
> of forinstance the TXcontroller along the processing among the
data-path
> components.
> 

Ravi>> You are very much correct. The Ucontroller will be acting
as a manager of the h/w, and will be taking care of the states
of the Baseband Inquiry/Page/scan. It will also manage the
piconet. It should also be able to manage the header buffer.
Takes care of the timing on air (The 625/312.5 slot timings). It
also instructs the radio controller to switch to next frequence.

> ** Timerblock module: I need to know the function of it. Is it
only
> sending interrupts to the Ucontroller.? and what are these
interrupts. ?

Ravi>> This block will keep track of all the Bluetooth timing,
IE CLKE, CLKN and timing on air ie the slot timings. It should
also have 2-3 general purpose timier, so that Ucontroller can
use it any time. At the terminal count of the timers, it
interrupts the Ucontroller depending on the confguration by
Ucontroller.
> this is vague for me.
> 
> **Headerbuffer:
> This buffer stores the header of the data to be transmitted as
I
> understand. (the header on which the CRC8 HEC has to be
evaluated)isn't
> it ?
> I need to know why it is interacting with Ucontroller.?

Ravi>> As of now iam thinking that the Ucontroller will prepare
the header and put it the headerbuffer, but there can be other
better way of doing it. Suggestions are invited.

> ** CS register
> IS it the current status register.

Ravi>> It is control and status register.

>In other words a register that holds
> the BT system states .. If yes , please list what states that
we would
> be working with. 

Ravi>> The states are clearly mentioned in the Bluetooth Spec.

> It is reasonable that CS_Reg informs the Ucontroller of the
Current
> state and then the Ucontroller has a scenario to be executed
represeted
> in control actions for the data-path controllers and etc.. 
> 
> Radio-Interface block: 
> 
> what does it inform the Ucontroller with and what is it
getting in
> return from its side. And is this dependant on the RF that we
will
> use.(we need to be independent somehow to work with all RFs
available).
> 

Ravi>> The Ucontroller will be programming the radio for the
next Hop frequency. And allmost all RF modules have their own
booting sequence, which will taken care by Ucontroller.
   There is no interface defined between the Baseband and RF by
the bluetooth, so every RF follow thein own way of communicating
with Baseband some follow JTAG, u-wire, i2c or bluerad. So the
radio interface will be very much dependent on what RF we are
targetting our chip to.

> An explanation of the involved interactions of the control
architecture

Ravi >> I will work on this.

> would be very helpful for all of us...
>  
> I am looking forward to having your feedback and comments.
> 
> Ps: We are all learning here and this is the main objective;
Hence Could
> u please all contribute with your understanding, feedback,
> queries...etc..The most of joy happens when many of us working
as one
> hand to reach the same goal.......Think of it seriously all
here and Let
> Us realize NOUR chip.we are ahead of starting off a real
development
> phase of a very state-of-the-art project ...Waiting for YOU
ALL>
> 
> Best Regards,
> 	Mohamed A.Salem
>  
> 
> 
> On Thu, 2004-03-11 at 03:33, Ravi Ranjan Kumar wrote:
> > Hi,
> > Yesterday i worked on a small document, which describes the
way
> > i am thinking about the h/w architecture of NOUR. Please
find
> > the document attached with the mail in pdf format.
> >   Comments please!!
> > Thanks and Regards
> > -- Ravi Ranjan Kumar
> > 
> > ________________________________________________
> > Get your own "800" number
> > Voicemail, fax, email, and a lot more
> > http://www.ureach.com/reg/tag
> > 
> >
______________________________________________________________________
> > 
> > --------------------------
> > NOUR Mailing List
> > Handasa Arabia Organization
> > http://www.handasarabia.org
> > [email protected]
> > 
> > Message number 122
> 
> 
> --------------------------
> NOUR Mailing List
> Handasa Arabia Organization
> http://www.handasarabia.org
> [email protected]
> 
> Message number 123
> 
> 
> 


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

--------------------------
NOUR Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
[email protected]

Message number 129