Re: Re: CRC -16 component

Hi,
Please find my comments below

>
> - Since bluetooth works on 1MHz we have to process the system
>at faster clock rate specially if we are going to make serial
>processing to reduce the logic size. For that reason there is a
>block that generates pulses at 1 MHz rate while the system is
>going to operate at higher clock rate. We can in this way speed
>up the operations of other parts  that are not dependant on the
>inoput/output stream and use single clock in the system to
>avoide multple clocks.
>
>Ravi>>  My point was to devide the design in three parts.
>           a. Data Path : Which work at the rx/tx clock.
>              In tern saving power (since it is working at
>              lower frequency)and logic (pulse genarator is not
>              required, the logic to take care of the action on
>              pulses is not required).


Jamil>>
Do not you think that multiple clock domains in the system will be very
difficult. What about the clock recovery from the RF chip? is it 1 MHz or
what?


>           b. Controllers: Which controls the data flow and
>              takes intelligent decisions. It will be running
>              at the frequency that is required to support the
>              controller logic.



>           c. The host interface: This perticular block contals
>              the wishbone master, slave, DMA, Buffers and
>              control and status registers. These blocks
>              will run at the frequency which is required to
>              support the data-rate on bluetooth.
>
>If intention of the design is simpler then the approach suggeted
>by you is very much applicable. But if the design needs to be
>efficient in terms of power and gate-counts i my suggestion is
>to go for the design approach taken in the latest CRC bloxk.
>
>
> - in the CRC block (and most Data path blocks) I supply two
>data inputs and do multiplexing inside the block because I do
>not want to make external multiplexors. Besides that this will
>simplify the system controller so it can control only the blocks
>not the muxs.
>
>Ravi>> I was thinking from prespective of debugging the design
>as a system. In this case we need to have more configuerablity
>in terms of bypassing or pssing the data throught the datapth
>elements selectivly. If we have the muxes outside each datapath
>elements, it gives a better control over the controllabilty over
>configueration of each of the data elements.
>

Jamil>> Could you please explain more how the external muxes will help in
debuging. I think teh system controller will have to deal with more blocks
(more complexity in teh microcontroller code)


> I'll try in the coming days to read the documents and send my
>comments.
>
> Best regards,
> Jamil Khatib
>
>> On 3/1/2004, "Mohamed Salem" <[email protected]>
>wrote:
>>
>> >Dear All,
>> >
>> >This presents a detailed description of the CRC-16 component
>> >functionality in the bit-stream processing of the bluetooth
>baseband
>> >datapath.
>> >(This will be added to the HW spec. document on NOUR folder
>on HA site)
>> >-------------------
>> >
>> >Processing description:
>> >------------
>> >-The CRC-16 will process the data of the payload (user-data.)
>in TX and
>> >CRC-16 part in the received packet in RX direction.
>> >
>> >Note: Bluetooth Packet is composed of the following:
>> >{Header, HEC, Payload, CRC-16 Value on USER-data }
>> >
>> >-Some definitions:
>> >
>> >Payload : User-data ; pure data coming from the upper
>bluetooth layers
>> >and stored in the TX-Buffers (at the Transmitter).
>> >TX- Buffers : 32 bits width , read from buffer one bit at a
>time.
>> >The DPRAM technology is suitable to implement the TX/RX
>buffers
>> >according to this context) .. will be revisted later while
>desiging the
>> >buffers.
>> >
>> >-Main Function:
>> >-The function of the CRC-16 is to evaluate the CRC-16 value
>on the
>> >payload(user-data) and append it to payload (TX)
>> >Check for the CRC-16 value correctness in the recieved packet
>and inform
>> >whether it is passed check or failed(RX)
>> >
>> >-The CRC-16 implements the CCITT (X16 + X12 + X5 + 1)
>> >
>> >-The CRC-16 uses a 16 bit LFSR register which has particular
>(Xoring)
>> >for certain Flipflops outputs that are fedback to another FF
>inputs of
>> >the LFSR.Refer to figure 3 in HW specs on the NOUR folder on
>HA site.
>> >
>> >-The  data is flowing to the block in serial fashion each
>clock cycle of
>> >1 MHZ of system clock.
>> >
>> >-The LFSR is initialized to ZEROS (seed-value) of the LFSR
>using an
>> >initialization input signal at the start of the system.
>> >
>> >-The system controller will enable the block for operation
>before the
>> >start of CRC -16 processing using an "enable" input signal.
>> >
>> >-At the end of payload (user-data) the main system controller
>will
>> >inform the CRC-16 by asserting a "drain" input signal high.
>> >
>> >-The drain signal should be asserted "1" for 16 clock
>cycles.When
>> >working on CRC-16 processing the drain signal should be
>(zero) and the
>> >output should be maintained to the value of the input data (
>a 2-1 MUX
>> >is used for that purpose )
>> >
>> >-The 16 clock cycles are enough to "Drain" the LFSR.Hence,
>the CRC value
>> >(16 bits)would be appended to the payload while TX operation.
>> >
>> >-In the RX direction, whenever the CRC part is checked and
>verified the
>> >content of the LFSR should be "Zeros" .Hence, the CRCMATCH
>output signal
>> >should be asserted high , indicating the CRC check
>correctness.
>> >
>> >--- The signal description of the CRC-16 block :
>> >
>> >Input signals:
>> >     txRxClk      : 1 MHz clock.
>> >     sysReset_n   : Active low global reset signal
>> >     txRxDataIn   : A multiplexed (txData: at the time of
>> >                    transmit and rxData: at time of
>reception)
>> >                    data on which the block has to
>> >                    calculate/check CRC-16
>> >     init         : A pulse to initialize the LFSR of the
>CRC-16
>> >                    block ( This signal should be asserted
>for
>> >                    at least a clock period of txRxClk before
>> >                    start of each transaction).
>> >     drain        : This signal gets asserted in the transmit
>> >                    direction only, when the data is over and
>> >                    the calculated CRC-16 has to be appended,
>> >                    it should be high of 16 clocks of txRxClk
>in
>> >                    turn draining all the 16 bits of CRC-16
>> >                    LFSR.
>> >     enableBlock  : It enables the LFSR to calculate/check
>the
>> >                    CRC-16. (I am not sure whether it is
>> >                    required or not, but it's better to have
>it.
>> >                    if it is not required it will be tied to
>> >                    "1".)
>> >
>> > Output signals:
>> >
>> >      txRxDataOut  : If the drain =3D=3D "0"; it holds the value
>> >                     of txRxDataIn.
>> >                     If the drain =3D=3D "1"; it holds CRC-16
>> >                     calculated value.
>> >       crcMatch    : Whenever the value of the LFSR is equal
>to
>> >                     "0", the crcMatch gets asserted. It is
>> >                     receive controller's duty to sample it
>at
>> >                     the end of the packet, to know whether
>> >                     CRC-16 has passed or not.
>> >
>> >Block-Diagram:
>> >will be added to HW spec document on NOUR folder.
>> >
>>
>>----------------------------------------------------------------------
>> >The details of the CRC-16 component will be added to the
>Bit-stream HW
>> >spec. document. version 0.1
>> >--------------------------------
>> >By March 8th , the whole Architecture and explanation of the
>baseband
>> >datapath should be available in details on our spec. document
>which is
>> >going through the review and update process this week.
>> >-----
>> >Waiting for feedback and review ..
>> >
>> >Thanks all for your efforts ..
>> >
>> >Best Regards,
>> >
>> >=09Mohamed A.Salem
>> >
>> >
>> >
>> >
>> >--------------------------
>> >NOUR Mailing List
>> >Handasa Arabia Organization
>> >http://www.handasarabia.org
>> >[email protected]
>> >
>> >Message number 114
>>
>> --------------------------
>> NOUR Mailing List
>> Handasa Arabia Organization
>> http://www.handasarabia.org
>> [email protected]
>>
>> Message number 116
>>
>>
>>
>>
>
>
>--------------------------
>NOUR Mailing List
>Handasa Arabia Organization
>http://www.handasarabia.org
>[email protected]
>
>Message number 117

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

Message number 119