Re: Re: CRC -16 component
Ravi Ranjan Kumar <raviranjan_kumar-HTy/[email protected]> Tue, 9 Mar 2004 21:24:01 -0500
| Newsgroups | gmane.org.handasarabia.nour |
|---|---|
| Message-ID | <[email protected]> |
Hi Jamil,
Please find my comments below marked as Ravi>>
It is nice to have a technical discussion with a person who
knows about what my way of thinking is.
Thanks and Regards
-- Ravi Ranjan
> >
> > - 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?
>
>
Ravi>> The clock recovery: It depends upon the radio module
that we are planning to use. If we use a radio module
wich does clock recovry itself (Whcih it should do
according to bluerad standard) than we need not worry,
and the txClk and rxClk will be supplied by the radio
module.
If the radio moule does not do so, then we will need to
recover the rxClk and generate the txClk in a higher
clock frequency domain. And believe me it's not defficult
and there are provisions to use internal clock in the
FPGAs also.
Yes that is 1 MHZ.
> > 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)
>
Ravi >> I was thinking of a txController and a rxController
which gets controlled by the microcontroller. And the
txController and rxController deals with these muxes and
data-path elements and the microcontroller controlls
these controller to get the work done. It makes the
microcontroller code simpler and it can run at lower
frequency because there will be much of realtime
requirments from this microcontroller.
>
> > 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
>
> --------------------------
> NOUR Mailing List
> Handasa Arabia Organization
> http://www.handasarabia.org
> [email protected]
>
> Message number 119
>
>
>
>
________________________________________________
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 121