Re: [bluetooth] Re: Clock Recovery in BT

[Robert Openshaw <robertopenshaw@yahoo.com>]

Probably the best way to verify your C model of the sync word generator
would be to try it with the sample data provided in Appendix IV part 3
of the bluetooth spec. There you will find a number of LAP's and their
associated pre-ambles, sync-words and trailer patters. Try running some
of them access codes, and confirming you get the same result. If you do
then their is a very good change that what you have conforms to the
spec!

I have not written any verilog before that calculates the access code
as this was done in software. My correlator mearly did a combinatorial
compare between a shifting input (the incomming data stream, and the
contects of a 64-bit register (that was written with the required
access code by the host processor).

But I don't see why I couldn't code something like that. I will see how
the work on the proposals go for Jamil.

Cheers
Rob
 --- Jyoti Wagholikar <jyoti_wagholikar@yahoo.com> wrote: > Hi Robert,
>      Thanks for your information. Can you give me the
> solution for synch word? Actually I have written C
> program to calculate the synch word. I am not sure
> whether I have implemented it correctly or not. I'll
> go through it and will check whther my understanding
> is correct or not.
>  I have taken Pseudo random noise sequence that is
> given in the specification. Is it correct? Do I need
> to generate the sequence everytime?
> 
> thanks,
> -Jyoti
> --- Robert Openshaw <robertopenshaw@yahoo.com> wrote:
> > 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@yahoo.com>
> > 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@yahoo.com>
> > 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
> 
=== 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