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