Re: Re: CRC -16 component

Hi Jamil,
Please find my comments on the changes suggested by you in your
mail marked as "Ravi>>". Please mail me for any clarification on
this.
Thanks and Regards
-- Ravi Ranjan Kumar




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


---- On Wed, 03 Mar 2004, Jamil Khatib ([email protected])
wrote:

 
 Dear all,
 I would like to thank you for all what you have done in this
project. It was
 interesting to see that some work are going on.
 
 I would like to make some explanations to the NOUR design
specifications document and some comments about your
interpretation of the design.
 
 - 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).

           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.

 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 == "0"; it holds the value
> >                     of txRxDataIn.
> >                     If the drain == "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,
> >
> >	Mohamed 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