[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth] Re: Clock Recovery in BT
Hi,
Iam doing an implementation of the baseband controller of a bluetooth
device in verilog.I was hoping for some advice in this regard from some
one who has worked in this field.I do not understand how to implement
data whitening in verilog.I dont understand the explanation as given in
the specifications.It says the some bits clock have to be stored in the
LFSR.How do we go about that?Advice regarding this is greatly
appreciated.,
Regards,
Puloma
----- Original Message -----
From: Robert Openshaw <robertopenshaw@y... >
To: bluetooth@o...
Date: Wed, 24 Apr 2002 11:21:08 +0100 (BST)
Subject: Re: [bluetooth] Re: Clock Recovery in BT
>
>
> I am not currently coding a correlator block, but I have coded one
> in
> Verilog in the past.
>
> Basically the access code is used to find the start of the packet,
> and
> also to identify which pico net that packet is associated to. (A
> sort
> of address) I strongly recoomend reading over the access code
> section
> of the bluetooth 1.1 spec. You can find an 'introduction' to the
> access
> code and it's function starting on page 48. But I would recommend
> reading the entire section about the bluetooth packet construction.
> You
> can download the spec from http://www.bluetooth.com
>
> You would have to have a talk with Jamil on how he intends to
> architect
> this bluetooth core. On the solution I have worked on in the past
> the
> sync word portion of the access code is calculated in software
> within
> the main controller. But this is an architecture issue. I could
> give
> you a solution that works great! (in verilog) But would not meet
> the
> requirements of this project due to different architectures.
>
> The most basic of correlators is:
> A 64 bit shift register (the access code is 72 bits max, that
> includes
> a pre-amble and a trailer pattern of 4 bits each the remaining 64
> bits
> is called the sync word)
> A 64-bit comparater that cominatorialy compares the 64 bits in your
> shift register with a target 64-bit pattern (basically 64 xor
> gates),
> that COULD be parallel loaded into another 64-bit register from say
> a
> host processor for example.
>
> The output of this comparater is a 64-bit pattern consisting of 1's
> where there was a bit miscompare and a 0 for a bit compare. We then
> need to combinatorially add all the bits together to find otu the
> total
> number of 1's, this gives us an error value. Say 4 int his example.
>
> To provide a bit more flexability you can then compare this error
> value
> with a programmable threshold, which is merely a value written itno
> another register. If the total number of errors is <= our
> threshold
> give a correlate signal, otherwise don't.
>
> If this is done combinatorially you will probably find it can run
> at a
> reasonable speed, I did however create an adder tree that could be
> pipelined if required. That is pretty simple really and wasn't
> necessary as this block, as described above and only if encoded as
> described above, would only need to run at the incomming data
> bit-rate....
>
> Cheers
> Rob
>
> --- Jyoti Wagholikar <jyoti_wagholikar@y... > wrote:
> > Hi Robert,
> > Even I am trying to implement the correlator.
> > I took threshold as 60. I am not sure what is the
> > exact value of the threshold should be. Are you
> > writing a code in C or VHDL/Verilog?
> > Can you please clear my concepts regarding access
> > code/correlator?
> > What I think is:
> > Correlator is required to find the starting of the
> > packet right? How does correlator give signalling on
> > the receiver side?
> > While transmitting the packets the access codes are
> > derived according to different modes like inquiry,
> > device access code, channel access code etc.
> > Is the mode information passed from bolck to block in
> > data path block modules?
> >
> > thanks,
> > -Jyoti
> > --- Robert Openshaw <robertopenshaw@y... > wrote:
> > > Why not seperate out the function of locking onto
> > > the incomming data
> > > stream and looking for an access code match? In my
> > > experience these
> > > are two very very different tasks. Also the preamble
> > > can't be relied on
> > >
> > > to provide the 1010 pattern. I have personally seen
> > > these preambles
> > > missing, and in fact even sometimes some missing
> > > access code, in some
> > > packets on a particular radio chip!
> > >
> > > The first problem you have about the incoming data
> > > stream may be that
> > > it's coming from a totally different clock, even if
> > > it is 1Mhz it does
> > > have
> > > a certain accuracy and our clock also must be within
> > > this accuracy. But
> > >
> > > you can no garuntee the relasionship between them!
> > > Correct? I beleive
> > > the 1Mhz clock accuracy requirement is spec'ed in
> > > the bluetooth 1.1
> > > spec. This accuracy ensures that over the time taken
> > > for 1 maximum
> > > sized bluetooth data packet, that any two 1Mhz
> > > clocks will not drift
> > > far
> > > enough appart as to cause setup/hold violations. But
> > > that is assuming
> > > your clocks are aligned at the start of the packet!
> > >
> > > So somehow you need to prevent this drifting of
> > > clocks resulting in us
> > > either dropping a bit, where our clock is slightly
> > > slower, or gaining
> > > an
> > > extra bit, where our clock is slightly faster.
> > >
> > > So how are you going to lock onto an asynchronouse
> > > data stream?
> > > Perhaps have a small block running much quicker that
> > > 'oversamples' the
> > > incomming data stream? We can then track when the
> > > transitions in the
> > > incomming data stream occurs in relation to our
> > > clock. So we can
> > > predict if we are going to drop or gain a bit. If we
> > > then run our
> > > design at
> > > say 2Mhz with the logic enabled every other cycle
> > > then we are
> > > effectively running at 1Mhz. But now we can recover
> > > this 'dropped bit'
> > > by leaving the enable high for 2 2Mhz cycles, and we
> > > can make up for
> > > this gained, or phantom bit, by leaving the enable
> > > low for an extra
> > > clock
> > > cycle! I feel this can then result in a reasonably
> > > safe tracking of the
> > >
> > > incomming data stream.
> > >
> > > Now the detection of the correct transition in the
> > > incomming data
> > > stream is a different matter. I have seen a 1Mhz
> > > data stream from a
> > > particular manufacturers bluetooth radio chip that
> > > has noise at a
> > > higher
> > > frequency overlaid on the data. Especially near the
> > > beginning of the
> > > packet when it is trying to lock onto the incomming
> > > data stream. I have
> > >
> > > seen a radio chip, from an alternative manufacturer,
> > > that prevents this
> > >
> > > happeneing and has a nice clean 1Mhz signal. So now
> > > we need to filter
> > > out spuriouse transitions. This all gets pretty
> > > messy but I have an
> > > idea
> > > for a solution.
> > >
> > > Now onto the correlator. You are not looking for the
> > > preamble anymore!
> > > Shift the incomming data into a 68 bit shift
> > > register, compare on every
> > >
> > > clock cycle the contets of this shift register with
> > > our access code. As
> > >
> > > soon as they match we have a correlation! If the
> > > correlator is run at
> > > the
> > > incoming data stream speed we can provide a
> > > correlate signal
> > > combinatorially in time for the next clock cycle.
> > >
> > > A quick question. Why are you passing the incoming
> > > data stream
> > > THROUGH the correlator to the FEC? Why not bypass
> > > the correlator, this
> > > will reduce latency (68 clock cycles) on the
> > > incoming data path! If the
> > >
> > > correlator merely monitors the incommind data and
> > > provides a correlate
> > > signal (combinatorially) then the next clock cycle
> > > will be the first
> > > data
> > > bit after the access code! (Most probably the first
> > > bit of the trailer,
> > >
> > > depending on the packet type!) So we could pass the
> > > data straight from
> > > the 're-sync' block mentioned above to the FEC which
> > > merely ignores all
> > >
> > > data until the correlate signal goes high.
> > >
> > > Could this 68 clock cycle latency could be an issue
> > > in us hitting our
> > > next
> > > transmit time slot? It is easliy avoided using the
> > > method mentioned
> > > above! Also the correlator can be run slow, so as to
> > > reduce power
> > > consumtion..... (At the speed of the incomming data
> > > stream!)
> > >
> > > I feel that a programmable threshold is important. I
> > > have seen
> > > successfull corellations with 0 errors, I have also
> > > seen access codes
> > > with 3 errors in it! We really still want to detect
> > > these packets with
> > > say
> > > 3 errors! Say make the threshold programmable from 0
> > > to say 15 errors
> > > (just picking numbers from thin air!) I can see
> > > situations where we
> > > could
> > > have bit errors in the access code! (noisey
> > > enviroment! While popping
> > > pop corn in the microwave????) But we want to reduce
> > > the chances of
> > > correlating on incorrect access codes! Now I know
> > > this is unlikely. The
> > >
> > > access codes are calculated in such a way as to
> > > ensure a high hamming
> > > distance between any two valid access codes! But
> > > It's better to be safe
> > >
> > > than sorry. The software could 'tune' this threshold
> > > accordign tot he
> > > signal quality if an error count is fed abck from
> > > the correlator. This
> > > could
> > > tell the software how many errors are actually
> > > occuring in the access
> > > codes!!!
> > >
> > > Thats about it for my first installment... I could
> > > knock up a spec for
> > > a
> > > correlator explaining the reasoning behind features
> > > if you woudl
> > > like...
> > > Not necessarily as a part of your bluetooth spec,
> > > but merely to try and
> > >
> > > explain my thoughts......
> > >
> > >
> > > Cheers
> >
> === message truncated ===
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml