100 Mbit manchester coded signal in FPGA

Antti Lukats wrote:
> gosh the 7404 and 7414 are totally different chips (in the context of making 
> oscillators).
> it wasnt much of an engineer who tried crystal osc with 7414.
> 7414 is good for making RC oscillator with 1 R and 1C (7404 is not)
> 
> http://focus.ti.com/lit/ds/symlink/sn74lvc1404.pdf

and also the very similar
http://www.standardics.philips.com/products/aup/pdf/74aup1z04.pdf

> and CPLD osc about the same as from above should work.

problem is, cpld osc is not 'about the same', as these devices use 
unbuffered inverters for the Xtal osc, and Schmitt post buffers.
- no presently available CPLD's offer unbuffered inverters, they
have loop gains even higher than buffered cmos gates which tyically
chain 3 inverters.

> sure it has to tested to work properly on the correct freq and not harmonics

still leaves edge effects, which are not ideal on a clock source :)

-jg

Antti wrote:
> Michael Dreschmann schrieb:
>
> > Hi all,
> >
> > we are trying to implement a 100 MBit communication link witch uses
> > manchester coding. The signal is generated by a CPLD (xc2c64a) and we
> > hope we can receive it with an FPGA (Virtex4 for example).
> > Because the CPLD design will work at 2.5V and should use minimal power
> > (sensor node) my question is if it is possible to use a crystal with a
> > NOT-gate in the CPLD for generating the oszillator frequency instead
> > of an external oszillator.
> > The second question concerns the reception of the datastream within
> > the FPGA. My thought was to use a digital pll as mentioned here
> > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html
> > to generate a sample clock for the incomming bitstream.
> > With the help of a DCM module I would generate two 300 MHz clocks, one
> > shifted by 180 degree. Then I should be able to sample the incomming
> > stream with 600 MHz and I hope this is enough to stay phase locked
> > with the datastream. But I haven't done such a fast communication
> > before, so I've no idea if this will work. Any comments from you would
> > be nice.
> >
> > Thanks,
> >  Michael
>
> you can look at the USB DPLL get the sub phy from opencores as example
> it uses 4x clock to deliver mid-bit clock enable to latch the data.
> something
> similar should work for manchester as well.
>
> cpld oscillator shure work, but you still need a resistor across not
> gate in-out
> it want oscillate otherwise. I have spent some time trying to get an
> crystal
> to swing on FPGA pins without external resistor but have not yet
> succeeded.

I am not familiar with USB data recovery designs, but I have worked
with Manchester encoding before.  A 4x clock is on the hairy edge for
data recovery.  The way Manchester encoding works, you start the bit in
the opposite state and transition to the correct state in the middle of
the bit.  You can also see a transision at the start of a bit if it
matches the previous bit.  To sample the data you have only one half a
bit time.  You have to have a lockout period to prevent a false edge
detection on the edge between bit cells.

Since you have a one clock cycle uncertainty in the timing of the
detection, you have trouble timing the length of the lockout period for
detecting the edge in the next middle of bit cell.  At 4x any timing
error will result in eventual slips in timing.  You need assure that
you clock just a bit faster than 4x to never have the edge detector
locked out when in the center of a bit cell.

The logic of a Manchester encoder or decoder is simple.  But you have
to be careful to sample fast enough to make it work.  A 4x clock will
not work reliably.  A 4.1x clock will.

Just a slight correction: The theoretically lowest clock recovery
sample frequency is 3 times the bit frequency (not 4 times).
You simply start a digital differentiator on any level transition, and
make that differentiator ignore level transitions for the two following
periods, in order to not trigger again. That recovers the clock, and
the rest is trivial.
Since there is a 1/3 bit time uncertainty, this scheme works
theoretically (best-case) with at least three clocks per bit cell.
Obviously, a practical implementation should add some guardband, but 4x
should be reliable if the frequencies are stable and there is not too
much jitter in the system. Of course, 6 or 8 times is even more robust.
Peter Alfke., Xilinx
================
rickman wrote:
> Antti wrote:
> > Michael Dreschmann schrieb:
> >
> > > Hi all,
> > >
> > > we are trying to implement a 100 MBit communication link witch uses
> > > manchester coding. The signal is generated by a CPLD (xc2c64a) and we
> > > hope we can receive it with an FPGA (Virtex4 for example).
> > > Because the CPLD design will work at 2.5V and should use minimal power
> > > (sensor node) my question is if it is possible to use a crystal with a
> > > NOT-gate in the CPLD for generating the oszillator frequency instead
> > > of an external oszillator.
> > > The second question concerns the reception of the datastream within
> > > the FPGA. My thought was to use a digital pll as mentioned here
> > > http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/dpll.html
> > > to generate a sample clock for the incomming bitstream.
> > > With the help of a DCM module I would generate two 300 MHz clocks, one
> > > shifted by 180 degree. Then I should be able to sample the incomming
> > > stream with 600 MHz and I hope this is enough to stay phase locked
> > > with the datastream. But I haven't done such a fast communication
> > > before, so I've no idea if this will work. Any comments from you would
> > > be nice.
> > >
> > > Thanks,
> > >  Michael
> >
> > you can look at the USB DPLL get the sub phy from opencores as example
> > it uses 4x clock to deliver mid-bit clock enable to latch the data.
> > something
> > similar should work for manchester as well.
> >
> > cpld oscillator shure work, but you still need a resistor across not
> > gate in-out
> > it want oscillate otherwise. I have spent some time trying to get an
> > crystal
> > to swing on FPGA pins without external resistor but have not yet
> > succeeded.
>
> I am not familiar with USB data recovery designs, but I have worked
> with Manchester encoding before.  A 4x clock is on the hairy edge for
> data recovery.  The way Manchester encoding works, you start the bit in
> the opposite state and transition to the correct state in the middle of
> the bit.  You can also see a transision at the start of a bit if it
> matches the previous bit.  To sample the data you have only one half a
> bit time.  You have to have a lockout period to prevent a false edge
> detection on the edge between bit cells.
>
> Since you have a one clock cycle uncertainty in the timing of the
> detection, you have trouble timing the length of the lockout period for
> detecting the edge in the next middle of bit cell.  At 4x any timing
> error will result in eventual slips in timing.  You need assure that
> you clock just a bit faster than 4x to never have the edge detector
> locked out when in the center of a bit cell.
>
> The logic of a Manchester encoder or decoder is simple.  But you have
> to be careful to sample fast enough to make it work.  A 4x clock will
> not work reliably.  A 4.1x clock will.

Peter Alfke wrote:
> Just a slight correction: The theoretically lowest clock recovery
> sample frequency is 3 times the bit frequency (not 4 times).
> You simply start a digital differentiator on any level transition, and
> make that differentiator ignore level transitions for the two following
> periods, in order to not trigger again. That recovers the clock, and
> the rest is trivial.
> Since there is a 1/3 bit time uncertainty, this scheme works
> theoretically (best-case) with at least three clocks per bit cell.
> Obviously, a practical implementation should add some guardband, but 4x
> should be reliable if the frequencies are stable and there is not too
> much jitter in the system. Of course, 6 or 8 times is even more robust.

I don't agree.  By ignoring the signal for 2 clock edges, you are
actually delaying by up to 3 clock edges.  You may have just missed
catching the transition on edge 1, then you wait until edge 2 and 3.
So the jitter in the measurement will put you (worst case) right at the
next transition on your input signal and you may just miss that.  If
all clocks were perfect and there was no worry about transition timing
on the edges, etc, then yes, I would agree you could do it with 3
clocks.  But in the real world with imperfect clocks and signals you
can miss an edge when the timing is boarderline.

The same issue prevents you from working properly with 4 clocks because
by waiting 2 clock edges you can improperly "see" the transition
between cells and by waiting 3 clock edges you can miss a valid
transition just as above.  With 5 clock cycles to a data bit, you will
be able to wait 3 clock edges and will always be assured of ignoring
the interbit transition and "seeing" the mid-bit transition.  3/5 of a
bit to 4/5 of a bit delay is always in the first half of the next bit
to within 10% of the bit period or 1/2 a clock cycle. Not many systems
will have that much jitter or timing distortion.

As to how much jitter is tolerable, I think this comes down to your
metastability figures.  I don't recall the exact number, but I believe
it is the neighborhood of low 10's of ps.  I have never worked with a
system where the clock was that accurate or stable and the signals were
reproduced that accurately.  Heck, just a couple of extra pF on a
signal line can skew the edges enough to add 100 ps of jitter and screw
up a 3x or 4x clocked decoder.

I guess you could go to a fractional ratio between the clock and the
data.  At 3.5x waiting 2 edges will give you 2 to 3 clocks delay which
is 0.25 of a clock beyond the inter-bit transition to be ignored and
0.5 clock cycles before the next mid-bit transition.  It is just the
cases that are trying to be integer multiples of the bit rate that are
problematic until you get to 5x.  There really is no reason to run at
integer multiples since you can never match the frequency exactly.  So
even 4.1x will give you enough margin unless the skew and jitter is
pretty bad which can happen depending on the transmission medium.

rickman wrote:
> I don't agree.  By ignoring the signal for 2 clock edges, you are
> actually delaying by up to 3 clock edges.  You may have just missed
> catching the transition on edge 1, then you wait until edge 2 and 3.
> So the jitter in the measurement will put you (worst case) right at the
> next transition on your input signal and you may just miss that.  If
> all clocks were perfect and there was no worry about transition timing
> on the edges, etc, then yes, I would agree you could do it with 3
> clocks.  But in the real world with imperfect clocks and signals you
> can miss an edge when the timing is [borderline].

<snip>
While the specific approach about a digital differentiator and looking 
at specific samples relative to an input stream ignored by a few cycles 
may be confusing, if you don't wait to acquire the signals but analyze 
what you got, the concept flows.
_____

If you can find a sampling such that you can guarantee at least one 
unambiguous sample in any half bit period - including jitter - then you 
can recover the data.  The worst case for the 3x clock is when one clock 
samples midpoint of one half-bit section of the data leasing the front 
and back edges of the next half bit perilously close the the edges.

(view in fixed space font:)
               __ _____       __
               __/     \_____/__
Sample Points  ^   ^   ^   ^

Depending on the jitter it might not work but the sample points are 1/12 
of a full bit period from the data transition.  If one of the sample 
points is on the hairy edge, the value *will* stabilize through standard 
handling of asynchronous signals.

The minimum sampling frequency for guaranteed operation is determined by 
the minimum pulse width (less than half a bit period) degraded by the 
jitter of the edges (both leading and trailing) as well as jitter in the 
sampling clock.  The DCMs may produce a large amount of (calculated) 
jitter that would be included in any DCM-based sampling clock analysis. 
  But for a 100 MB/s data rate, the 5 ns period won't be degraded *that* 
much.  While 300 MHz should work flawlessly, even a 250 MHz sampling 
clock might work if the duty cycle is well controlled.  5 ns half 
period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns 
apart should hit the meat of the half period.  Fractional multipliers 
are just such a bother.

Metastability windows are now sub-picosecond so all that needs to be 
worried about is standard synchronization for those one in a million 
events that happen once every 5 seconds at 2x 100 MB/s.

Sample everything, let the logic figure it out.

The clock is extracted from the data rather than the data extracted from 
the clock.

There's even a Xilinx app note that describes how to extract data from 
wide busses above 600 MB/s without rocket I/O.  There's no 1.5x clock 
available at those rates!

John_H wrote:
> rickman wrote:
> > I don't agree.  By ignoring the signal for 2 clock edges, you are
> > actually delaying by up to 3 clock edges.  You may have just missed
> > catching the transition on edge 1, then you wait until edge 2 and 3.
> > So the jitter in the measurement will put you (worst case) right at the
> > next transition on your input signal and you may just miss that.  If
> > all clocks were perfect and there was no worry about transition timing
> > on the edges, etc, then yes, I would agree you could do it with 3
> > clocks.  But in the real world with imperfect clocks and signals you
> > can miss an edge when the timing is [borderline].
>
> <snip>
> While the specific approach about a digital differentiator and looking
> at specific samples relative to an input stream ignored by a few cycles
> may be confusing, if you don't wait to acquire the signals but analyze
> what you got, the concept flows.
> _____
>
> If you can find a sampling such that you can guarantee at least one
> unambiguous sample in any half bit period - including jitter - then you
> can recover the data.  The worst case for the 3x clock is when one clock
> samples midpoint of one half-bit section of the data leasing the front
> and back edges of the next half bit perilously close the the edges.
>
> (view in fixed space font:)
>                __ _____       __
>                __/     \_____/__
> Sample Points  ^   ^   ^   ^

I don't agree that this is the worst case.  The worst case is when the
transition of the signal is at the same time as the clock edge.  The
signal can be sampled either in the leading or the trailing state.  So
the edge might be sampled right at the edge or 1/3 of the way into the
bit time (2/3 of the first half of the bit).  Your decoder has to
sample either 0, 1 or 2 clocks after the edge is detected.  It then has
to wait a defined number of clocks before it recognizes another edge.
This is to prevent the detection of the edges that can occur between
bit times.  If you select 1 clock for the lock out, the worst case is
when you detect the mid-bit edge as soon as it happens.  Then the lock
out is too short.  If you wait 2 clocks after detecting the mid-bit
edge the worst case is when the edge is just missed by a clock and is
not detected until the next clock.  Then waiting 2 more clocks puts you
at the middle of the next bit and the slightest amount of jitter will
cause you to miss the mid-bit edge.

So any amout of jitter will cause failures with a 3x clock.  You can
use a 3.1x clock and will have less margin (0.06 clock periods) at the
one extreme and 0.1 clock period margin at the other.  But a 3x clock
is not workable.


> Depending on the jitter it might not work but the sample points are 1/12
> of a full bit period from the data transition.  If one of the sample
> points is on the hairy edge, the value *will* stabilize through standard
> handling of asynchronous signals.

The problem is not that the signal becomes metastable, the problem is
when *both* the edge detection and the next edge detection are close to
metastable.  Then you can miss an edge because of even microscopic
amounts of jitter.

> The minimum sampling frequency for guaranteed operation is determined by
> the minimum pulse width (less than half a bit period) degraded by the
> jitter of the edges (both leading and trailing) as well as jitter in the
> sampling clock.  The DCMs may produce a large amount of (calculated)
> jitter that would be included in any DCM-based sampling clock analysis.
>   But for a 100 MB/s data rate, the 5 ns period won't be degraded *that*
> much.  While 300 MHz should work flawlessly, even a 250 MHz sampling
> clock might work if the duty cycle is well controlled.  5 ns half
> period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns
> apart should hit the meat of the half period.  Fractional multipliers
> are just such a bother.

Your statements are not supported by the facts.


> Metastability windows are now sub-picosecond so all that needs to be
> worried about is standard synchronization for those one in a million
> events that happen once every 5 seconds at 2x 100 MB/s.

I agree that the metastability windows are small.  But metastability
has nothing to do with this analysis.  I brought it up to show that the
difference between an edge being detected in this clock cycle and the
next is a very small amount of time and much smaller than the jitter in
a typical clocked system.


> Sample everything, let the logic figure it out.

Don't they use that logic in the Rangers?


> The clock is extracted from the data rather than the data extracted from
> the clock.
>
> There's even a Xilinx app note that describes how to extract data from
> wide busses above 600 MB/s without rocket I/O.  There's no 1.5x clock
> available at those rates!

Please tell how they do it!

Here are two example bit streams that I collected from my white board.
Please decode them for me and explain the algorithm you used.  Each one
is clocked at 3x the bit rate...

0001101110010000
0000101111010000

An algorithm should be able to correctly decode these streams.

"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1155322803.697990.219990@i42g2000cwa.googlegroups.com...
> John_H wrote:
>> If you can find a sampling such that you can guarantee at least one
>> unambiguous sample in any half bit period - including jitter - then you
>> can recover the data.  The worst case for the 3x clock is when one clock
>> samples midpoint of one half-bit section of the data leasing the front
>> and back edges of the next half bit perilously close the the edges.
>>
>> (view in fixed space font:)
>>                __ _____       __
>>                __/     \_____/__
>> Sample Points  ^   ^   ^   ^
>
> I don't agree that this is the worst case.  The worst case is when the
> transition of the signal is at the same time as the clock edge.  The
> signal can be sampled either in the leading or the trailing state.  So
> the edge might be sampled right at the edge or 1/3 of the way into the
> bit time (2/3 of the first half of the bit).  Your decoder has to
> sample either 0, 1 or 2 clocks after the edge is detected.  It then has
> to wait a defined number of clocks before it recognizes another edge.
> This is to prevent the detection of the edges that can occur between
> bit times.  If you select 1 clock for the lock out, the worst case is
> when you detect the mid-bit edge as soon as it happens.  Then the lock
> out is too short.  If you wait 2 clocks after detecting the mid-bit
> edge the worst case is when the edge is just missed by a clock and is
> not detected until the next clock.  Then waiting 2 more clocks puts you
> at the middle of the next bit and the slightest amount of jitter will
> cause you to miss the mid-bit edge.

Detection of edges that can occur between bit times was not understood (by 
me) as a necessary condition for manchester decoding.  If this is the case, 
the situation is more difficult.  If the requirement did not include glitch 
filtering (as should be the case for 100 Mbit/s chanchester encoding) then 
sampling at the edge would leave the samples on either side fully 1/3 into 
the half bit period; only the edge sample would be ambiguous and would 
either widen the previous half bit or the next one in the new timing domain.

Jitter is not an issue.  Glitches are an issue.  If the logic levels are 
well behaved, my suggestions should hold.  If the logic levels are not well 
behaved, it appears that finding and holding on to error-free manchester 
decoded data is an elusive task.

> So any amout of jitter will cause failures with a 3x clock.  You can
> use a 3.1x clock and will have less margin (0.06 clock periods) at the
> one extreme and 0.1 clock period margin at the other.  But a 3x clock
> is not workable.
>
>
>> Depending on the jitter it might not work but the sample points are 1/12
>> of a full bit period from the data transition.  If one of the sample
>> points is on the hairy edge, the value *will* stabilize through standard
>> handling of asynchronous signals.
>
> The problem is not that the signal becomes metastable, the problem is
> when *both* the edge detection and the next edge detection are close to
> metastable.  Then you can miss an edge because of even microscopic
> amounts of jitter.

If you aren't dealing with edge detection but sample the signals and let any 
metastability settle out first.  Edge detection is done on this data.  The 
constraint is that the smallest half period degraded by both the transmit 
jitter and the receive clock jitter MUST be less than the sampling period, 
adjusting for the sub-picosecond metastability window (which is less than 
any jitter consideration).

>> The minimum sampling frequency for guaranteed operation is determined by
>> the minimum pulse width (less than half a bit period) degraded by the
>> jitter of the edges (both leading and trailing) as well as jitter in the
>> sampling clock.  The DCMs may produce a large amount of (calculated)
>> jitter that would be included in any DCM-based sampling clock analysis.
>>   But for a 100 MB/s data rate, the 5 ns period won't be degraded *that*
>> much.  While 300 MHz should work flawlessly, even a 250 MHz sampling
>> clock might work if the duty cycle is well controlled.  5 ns half
>> period, 750 ps pk-to-pk jitter, at least one of the sample points 4 ns
>> apart should hit the meat of the half period.  Fractional multipliers
>> are just such a bother.
>
> Your statements are not supported by the facts.

If there are glitches sampled in either half, you are correct that my 
statements are not supported by facts.  If the signal is well behaved though 
degraded by jitter and duty cycle I stand by my understanding of sampling 
theory to suggest that I am correct.  As long as you can get one unambiguous 
sample of the half period, you can extract the original data stream. 
Understanding when two samples are both the same half period versus two half 
periods from adjoining bits is where a tracking NCO or similar clock 
extraction is needed.  If there is no NCO, just the immediate neighborhood 
of a few samples, then no - unambiguous decoding is not possible at 2.5x 
rates.

>> Metastability windows are now sub-picosecond so all that needs to be
>> worried about is standard synchronization for those one in a million
>> events that happen once every 5 seconds at 2x 100 MB/s.
>
> I agree that the metastability windows are small.  But metastability
> has nothing to do with this analysis.  I brought it up to show that the
> difference between an edge being detected in this clock cycle and the
> next is a very small amount of time and much smaller than the jitter in
> a typical clocked system.

The difference of being on one side of the metastability window or the other 
is having one more sample in one half the bit period or the other.  The edge 
detection is just moved by one sample, not ignored entirely.

>> Sample everything, let the logic figure it out.
>
> Don't they use that logic in the Rangers?
>
>
>> The clock is extracted from the data rather than the data extracted from
>> the clock.
>>
>> There's even a Xilinx app note that describes how to extract data from
>> wide busses above 600 MB/s without rocket I/O.  There's no 1.5x clock
>> available at those rates!
>
> Please tell how they do it!

http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf

> Here are two example bit streams that I collected from my white board.
> Please decode them for me and explain the algorithm you used.  Each one
> is clocked at 3x the bit rate...
>
> 0001101110010000
> 0000101111010000
>
> An algorithm should be able to correctly decode these streams.

With this small sequence of bits, unambiguous decoding is still available

  0001101110010000
10  01  01  10  10   01
 1   0    0     1    1    0

 0000101111010000
10   01 01  10  10  01
 1    0   0   1    1    0

The half bit perios are always identified by a 101 or a 010.  The half bit 
periods from two adjecent bits are always identified by 111 or 000.  On 
average, the bit rate is two half-bit pairs every three clocks.

Q.E.D. yet? 

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:Iu5Dg.7581$Oh1.4082@news01.roc.ny...

>  0001101110010000
> 10  01  01  10  10   01
> 1   0    0     1    1    0
>
> 0000101111010000
> 10   01 01  10  10  01
> 1    0   0   1    1    0

I may have inverted my single-bit results.  It looks like manchester has the 
logic level in the second half of the bit, not the first like I thought.  I 
checked wikipedia.org and saw my inversion, otherwise the idea still holds.

Without knowing the clock rate, Manchester encoding has pulses that are 
either 1/2 bit period or 1 whole bit period.  You should get two tight 
ranges of count values that correspond to these intervals.  In the 3x clock 
case, those two ranges overlap.  It's knowing when the half bit periods are 
definitely half or whole bit periods that the alignment can be determined 
and the frequency extracted without ambiguity. 

John_H wrote:
> "John_H" <newsgroup@johnhandwork.com> wrote in message
> news:Iu5Dg.7581$Oh1.4082@news01.roc.ny...
>
> >  0001101110010000
> > 10  01  01  10  10   01
> > 1   0    0     1    1    0
> >
> > 0000101111010000
> > 10   01 01  10  10  01
> > 1    0   0   1    1    0
>
> I may have inverted my single-bit results.  It looks like manchester has the
> logic level in the second half of the bit, not the first like I thought.  I
> checked wikipedia.org and saw my inversion, otherwise the idea still holds.
>
> Without knowing the clock rate, Manchester encoding has pulses that are
> either 1/2 bit period or 1 whole bit period.  You should get two tight
> ranges of count values that correspond to these intervals.  In the 3x clock
> case, those two ranges overlap.  It's knowing when the half bit periods are
> definitely half or whole bit periods that the alignment can be determined
> and the frequency extracted without ambiguity.

Ok, that is what you are not getting.  Time sampling does not produce
an even distribution of pulses in the time sampled domain with a 3x
clock.  The above sequences both need to be decoded to the same
sequence, 1001.  The first sequence assumes "ideal" sampling with no
timing abiguities.  The second sequence is what you might get if the
sampling is done right on the important edges and a small amount of
jitter messes up your data.

000_1101110010000
     ^  First bit = 1
00011_01110010000
        ^  edge between bits, ignore
000110_1110010000
          ^  Second bit = 1
000110111_0010000
               ^  Third bit = 0
00011011100_10000
                   ^  edge between bits, ignore
000110111001_0000
                     ^  Fourth bit = 0

If you don't understand how this was decoded, you need to go back to
Wikipedia.

The second sequence has two places where the signal capture was on the
wrong side of the edge because of jitter.  So it now is not possible to
decode and recover the correct data.  The same thing can happen with a
4x clock.  But as the clock gets faster than 4x there are no more
multiples where you can't find a correct delay for ignoring the
inter-bit edge.

You may not notice but I did decode exactly what you show BUT I included the 
preceeding and following bits as well.  The inversion is the issue.  Some 
references suggest the bit value is in the first half, some the second. 
This is pointed out later in the wikipedia article.  I used the first half 
of the bit period for the data but you can see my bit half pairs are 
correct.

Of COURSE the sampling doesn't produce an evenly PACED distribution of 
pulses, it produces counts of 2 to 4 for the two half bits from adjecent 
values and counts from 1-2 for the isolated half bits.  It happens that 
these overlap as I described.  If you only have an all-zero or all-one 
pattern then no, you cannot ambiguously extract the data.  Once you get any 
other data, the alignment is guaranteed.

You mentioned the sequences need to be decoded to 1001 yet you decoded 1100. 
At the 2x transmit output, the encoded sequence would be either 10100101 or 
01011010 depending on your polarity.  Is that what you were attempting to 
show?  Or was it 1100?

Your "go back to Wikipedia" comment was uncalled for.  If you don't 
understand what I'm trying to describe or vice-versa, it's a problem with 
the communication medium (to include the inaccuracies of English) and not 
that I'm brain challenged.

Embedded clocks are used all over.  Successfully.  But you don't see it. 
Are you right?


"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1155329590.259386.229690@h48g2000cwc.googlegroups.com...
> John_H wrote:
>> "John_H" <newsgroup@johnhandwork.com> wrote in message
>> news:Iu5Dg.7581$Oh1.4082@news01.roc.ny...
>>
>> >  0001101110010000
>> > 10  01  01  10  10   01
>> > 1   0    0     1    1    0
>> >
>> > 0000101111010000
>> > 10   01 01  10  10  01
>> > 1    0   0   1    1    0
>>
>> I may have inverted my single-bit results.  It looks like manchester has 
>> the
>> logic level in the second half of the bit, not the first like I thought. 
>> I
>> checked wikipedia.org and saw my inversion, otherwise the idea still 
>> holds.
>>
>> Without knowing the clock rate, Manchester encoding has pulses that are
>> either 1/2 bit period or 1 whole bit period.  You should get two tight
>> ranges of count values that correspond to these intervals.  In the 3x 
>> clock
>> case, those two ranges overlap.  It's knowing when the half bit periods 
>> are
>> definitely half or whole bit periods that the alignment can be determined
>> and the frequency extracted without ambiguity.
>
> Ok, that is what you are not getting.  Time sampling does not produce
> an even distribution of pulses in the time sampled domain with a 3x
> clock.  The above sequences both need to be decoded to the same
> sequence, 1001.  The first sequence assumes "ideal" sampling with no
> timing abiguities.  The second sequence is what you might get if the
> sampling is done right on the important edges and a small amount of
> jitter messes up your data.
>
> 000_1101110010000
>     ^  First bit = 1
> 00011_01110010000
>        ^  edge between bits, ignore
> 000110_1110010000
>          ^  Second bit = 1
> 000110111_0010000
>               ^  Third bit = 0
> 00011011100_10000
>                   ^  edge between bits, ignore
> 000110111001_0000
>                     ^  Fourth bit = 0
>
> If you don't understand how this was decoded, you need to go back to
> Wikipedia.
>
> The second sequence has two places where the signal capture was on the
> wrong side of the edge because of jitter.  So it now is not possible to
> decode and recover the correct data.  The same thing can happen with a
> 4x clock.  But as the clock gets faster than 4x there are no more
> multiples where you can't find a correct delay for ignoring the
> inter-bit edge.
>