Embedded clocks

I was posting to the thread on the embedded clock in a Manchester
encoded bit stream and realized that the clock is not truely embedded
in the data stream.  I say this because you still have to know the
clock rate in order for it to work.  The decoder has to lock out the
edge detection for the time between bits to prevent detecting false
bits.  You have to know the data rate in order to time this lock out
period.  Of course the timing is much less critical than a typical
clock, even an RC clock.  But none the less you have to have a clock of
a given frequency.

Are there any methods of transmitting data and clock on a single wire
that do not rely on the decoder having knowlege of the clock rate.
This is not entirely academic.  I have an interface I am working on
where I need to multiplex multiple signals over a single pin.  One is a
serial bus and the others are discrete pins which require very accurate
timing.  Idealy the decoder would not have a clock, but rather the data
would be self clocking.  I would like to use a very low power CPLD that
could be powered by either the signal or at least only require a few mA
of current from an LDO on the battery connection.

Is self clocking on a single pin possible?  I am thinking that the
extra info has to be presented in some manner that requires either a
timing or amplitude measurement.

rickman wrote:
> I was posting to the thread on the embedded clock in a Manchester
> encoded bit stream and realized that the clock is not truely embedded
> in the data stream.  I say this because you still have to know the
> clock rate in order for it to work.  The decoder has to lock out the
> edge detection for the time between bits to prevent detecting false
> bits.  You have to know the data rate in order to time this lock out
> period.  Of course the timing is much less critical than a typical
> clock, even an RC clock.  But none the less you have to have a clock of
> a given frequency.
>
> Are there any methods of transmitting data and clock on a single wire
> that do not rely on the decoder having knowlege of the clock rate.
> This is not entirely academic.  I have an interface I am working on
> where I need to multiplex multiple signals over a single pin.  One is a
> serial bus and the others are discrete pins which require very accurate
> timing.  Idealy the decoder would not have a clock, but rather the data
> would be self clocking.  I would like to use a very low power CPLD that
> could be powered by either the signal or at least only require a few mA
> of current from an LDO on the battery connection.
>
> Is self clocking on a single pin possible?  I am thinking that the
> extra info has to be presented in some manner that requires either a
> timing or amplitude measurement.

You do not have to know (except to within a very broad range) the clock
rate for a manchester encoded (or many other techniques) to lock up to
it.

A Manchester encoded stream is guaranteed a transition every bit, and
two transitions per bit for a logical 1 (some schemes did this for zero
instead).

That means the minimum transition rate on the line is clk/2 [zero bits]
and for (statistically) 50% of the time, clk * 2 [ 1 bits]. Obviously,
that means that *on average*, the transition rate of the line is the
clock rate. This requires the loop filter of the PLL/DLL to be
appropriately set, but within a pretty wide margin.

Self clocking schemes abound, some with inherently wider bandwidths
than others, although the issue is more usually the application than
the technique.

What was the application (clock rate variation in particular)? We may
be able to suggest a suitable technique.

Cheers

PeteS

PeteS wrote:
> rickman wrote:
> > I was posting to the thread on the embedded clock in a Manchester
> > encoded bit stream and realized that the clock is not truely embedded
> > in the data stream.  I say this because you still have to know the
> > clock rate in order for it to work.  The decoder has to lock out the
> > edge detection for the time between bits to prevent detecting false
> > bits.  You have to know the data rate in order to time this lock out
> > period.  Of course the timing is much less critical than a typical
> > clock, even an RC clock.  But none the less you have to have a clock of
> > a given frequency.
> >
> > Are there any methods of transmitting data and clock on a single wire
> > that do not rely on the decoder having knowlege of the clock rate.
> > This is not entirely academic.  I have an interface I am working on
> > where I need to multiplex multiple signals over a single pin.  One is a
> > serial bus and the others are discrete pins which require very accurate
> > timing.  Idealy the decoder would not have a clock, but rather the data
> > would be self clocking.  I would like to use a very low power CPLD that
> > could be powered by either the signal or at least only require a few mA
> > of current from an LDO on the battery connection.
> >
> > Is self clocking on a single pin possible?  I am thinking that the
> > extra info has to be presented in some manner that requires either a
> > timing or amplitude measurement.
>
> You do not have to know (except to within a very broad range) the clock
> rate for a manchester encoded (or many other techniques) to lock up to
> it.
>
> A Manchester encoded stream is guaranteed a transition every bit, and
> two transitions per bit for a logical 1 (some schemes did this for zero
> instead).
>
> That means the minimum transition rate on the line is clk/2 [zero bits]
> and for (statistically) 50% of the time, clk * 2 [ 1 bits]. Obviously,
> that means that *on average*, the transition rate of the line is the
> clock rate. This requires the loop filter of the PLL/DLL to be
> appropriately set, but within a pretty wide margin.
>
> Self clocking schemes abound, some with inherently wider bandwidths
> than others, although the issue is more usually the application than
> the technique.
>
> What was the application (clock rate variation in particular)? We may
> be able to suggest a suitable technique.
>
> Cheers
>
> PeteS

I'll correct my own mistake: (Blame the cold ;)

For 50% of the time in a manchester encoded sheme, the transition rate
is clk/2 and for 50% it's clk.  By setting the loop filter at 3/4 clock
(or even 5/8) we can lock in on the clock quite easily. (Nowadays -
when it was first invented, it was quite a breakthrough and not easy at
all).

Certainly there are schemes that are wider band - 8b/10b encoding comes
to mind for instance.

Cheers

PeteS

rickman wrote:
> I was posting to the thread on the embedded clock in a Manchester
> encoded bit stream and realized that the clock is not truely embedded
> in the data stream.  I say this because you still have to know the
> clock rate in order for it to work.  The decoder has to lock out the
> edge detection for the time between bits to prevent detecting false
> bits.  You have to know the data rate in order to time this lock out
> period.  Of course the timing is much less critical than a typical
> clock, even an RC clock.  But none the less you have to have a clock of
> a given frequency.
> 
> Are there any methods of transmitting data and clock on a single wire
> that do not rely on the decoder having knowlege of the clock rate.
> This is not entirely academic.  I have an interface I am working on
> where I need to multiplex multiple signals over a single pin.  One is a
> serial bus and the others are discrete pins which require very accurate
> timing.

Which means what, exactly ? fs ?

   Idealy the decoder would not have a clock, but rather the data
> would be self clocking.  I would like to use a very low power CPLD that
> could be powered by either the signal or at least only require a few mA
> of current from an LDO on the battery connection.
> 
> Is self clocking on a single pin possible?  I am thinking that the
> extra info has to be presented in some manner that requires either a
> timing or amplitude measurement.

The closest to this would be PWM modulation, widely seen on 1-wire BUS 
designs.
Intel have a SST bus, that has up to 2MBd PWM, but info is sparse.

To demodulate PWM, you need only a dual monostable (or, a Single gated 
RC Osc + small divider ), and that Osc can Auto-start, so can idle in 
very low power states.

Normally two time-slots are used, one monstable at 50% bit time, samples 
the data, and another is set to timeout after no-edges for XX time, 
which does the frame operations.

With a CPLD, you control both, and can send using SPI with a good fifo
( you need to ensure no false frames, due to host pauses )

-jg

rickman wrote:

> Is self clocking on a single pin possible?  I am thinking that the
> extra info has to be presented in some manner that requires either a
> timing or amplitude measurement.

As Jim wrote, the one-wire bus can do this. With this concept you need only
one wire (and ground) to power and communicate with a device:

http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf
http://www.maxim-ic.com/appnotes.cfm/an_pk/126

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss wrote:
> rickman wrote:
>
> > Is self clocking on a single pin possible?  I am thinking that the
> > extra info has to be presented in some manner that requires either a
> > timing or amplitude measurement.
>
> As Jim wrote, the one-wire bus can do this. With this concept you need only
> one wire (and ground) to power and communicate with a device:
>
> http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf
> http://www.maxim-ic.com/appnotes.cfm/an_pk/126

Thanks to everyone for their posts.  Each of the above solutions
require timing of the signal and so will not work without a clock (or
timer) of a specified rate.  The key is "specified".  To decode a
machester stream you need a time interval of about 3/4 of the bit time
in order to blank the edge detector on the edge between bits.  That
interval can be somewhat broad, but must be known to at least better
than 33%.  So I can't read a Manchester stream at 10 Mbps and one at 1
Mbps with the same timer.  Of course I can design a circuit that will
synchronize the clock to a fixed rate bit stream.  But that is a lot
more complex.  I am looking for something that will just plain clock
the data across the interface without a requirement to know the
frequency whether by measuring it, or a priori.

rickman wrote:

> Thanks to everyone for their posts.  Each of the above solutions
> require timing of the signal and so will not work without a clock (or
> timer) of a specified rate.

With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and
1. Should be easy to generate with an op-amp and to detect with another
one. But I think it is easier to use a clock and normal digital signals.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

rickman wrote:
> Frank Buss wrote:
> 
>>rickman wrote:
>>
>>
>>>Is self clocking on a single pin possible?  I am thinking that the
>>>extra info has to be presented in some manner that requires either a
>>>timing or amplitude measurement.
>>
>>As Jim wrote, the one-wire bus can do this. With this concept you need only
>>one wire (and ground) to power and communicate with a device:
>>
>>http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf
>>http://www.maxim-ic.com/appnotes.cfm/an_pk/126
> 
> 
> Thanks to everyone for their posts.  Each of the above solutions
> require timing of the signal and so will not work without a clock (or
> timer) of a specified rate.  The key is "specified".  To decode a
> machester stream you need a time interval of about 3/4 of the bit time
> in order to blank the edge detector on the edge between bits.  That
> interval can be somewhat broad, but must be known to at least better
> than 33%.  So I can't read a Manchester stream at 10 Mbps and one at 1
> Mbps with the same timer.  Of course I can design a circuit that will
> synchronize the clock to a fixed rate bit stream.  But that is a lot
> more complex.  I am looking for something that will just plain clock
> the data across the interface without a requirement to know the
> frequency whether by measuring it, or a priori.

Why do you need such a loose frequency spec ?

ALL schemes will clearly need some time-element.

What you need is to reduce the Clock _tolerance_ and _power_ costs, to
minimal levels.

The one-wire (PWM data) designs change from a classic clock (which draws 
power all the time ) to a more async-based monostable ( so can idle at 
very low powers ). It also drops the clock tolerance to quite slack 
levels, met by the cheapest components.
The overhead, is slightly less bandwidth efficency than other modulation
methods.

With one wire, the master provides the edges, and the slave the data 
(sometimes), and the slave can use very cheap / low power / fast wakeup 
RC oscillator.

one-wire designs are implicitly duplex, and so are better suited than 
manchester to low cost slave nodes.

They also work well with CAN transcievers, as that is a 'OR' BUS

-jg

On 11 Aug 2006 14:16:19 -0700, rickman
 <spamgoeshere4@yahoo.com> wrote:


>Thanks to everyone for their posts.  Each of the above solutions
>require timing of the signal and so will not work without a clock (or
>timer) of a specified rate.  

I'm not sure I understand this.

Give me an oscillogram of a Manchester-coded signal and I can
tell you its clock rate by inspection -  unless the data stream
is all-1s or all-0s, and that's a corner case that we easily
know how to avoid.  I need only one different bit in the
entire oscillogram and I can work out what's going on with
no _a priori_ knowledge of the data rate.  

To achieve this I need only two things: (a) some means to
measure the time between transitions, to a good enough
precision; (b) enough memory to remember what's going
on until I see a bit transition from 0 to 1 or back.  Condition
(a) means, in  digital-land, some kind of oversampling and
so it implies a *minimum* sampling clock rate; but 
measurement of edge-to-edge times imposes no lower
limit on the data rate.

I suspect rickman is looking for a scheme in which the
data line can provide its own clock using some method
other than oversampling.  Pulse-position or pulse-width
modulation does that well enough, as do a whole raft
of PSK techniques, but all of them require some kind
of phase-locked loop or related means to act as a
"flywheel" so that you can detect deviations of the 
line signal from an average clock that's also delivered
by the line.

Once you've introduced a PLL you are, of course, in 
something like analogue territory; and once you're
there, a whole world of modulation techniques opens up.
Amplitude-shift keying sounds about as self-clocking
as it gets; there are ternary codes (positive-going pulse
for 1, negative-going to 0), .......  And in the absence of
any interfering signals these schemes are, trivially,
self-timed.  Of course, as soon as you have other 
signals present on the same line, the obvious way
to sort out one from another is by prior knowledge
of the clock frequency.  Ask the radio guys about 
that - they are probably likely to speak of a "carrier"
rather than "clock", and they may talk about "tuning"
to choose a given signal!
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley wrote:
> On 11 Aug 2006 14:16:19 -0700, rickman
>  <spamgoeshere4@yahoo.com> wrote:
>
>
> >Thanks to everyone for their posts.  Each of the above solutions
> >require timing of the signal and so will not work without a clock (or
> >timer) of a specified rate.
>
> I'm not sure I understand this.
>
> Give me an oscillogram of a Manchester-coded signal and I can
> tell you its clock rate by inspection -  unless the data stream
> is all-1s or all-0s, and that's a corner case that we easily
> know how to avoid.  I need only one different bit in the
> entire oscillogram and I can work out what's going on with
> no _a priori_ knowledge of the data rate.

Actually, that is not correct.  Here are two sequences sampled at 1
MHz.  Please tell me the clock rates.

0101010101010101
0011001100110011

But I acknowledged that you could "measure" the data rate as long as
the bit stream allows for that.


> To achieve this I need only two things: (a) some means to
> measure the time between transitions, to a good enough
> precision; (b) enough memory to remember what's going
> on until I see a bit transition from 0 to 1 or back.  Condition
> (a) means, in  digital-land, some kind of oversampling and
> so it implies a *minimum* sampling clock rate; but
> measurement of edge-to-edge times imposes no lower
> limit on the data rate.
>
> I suspect rickman is looking for a scheme in which the
> data line can provide its own clock using some method
> other than oversampling.  Pulse-position or pulse-width
> modulation does that well enough, as do a whole raft
> of PSK techniques, but all of them require some kind
> of phase-locked loop or related means to act as a
> "flywheel" so that you can detect deviations of the
> line signal from an average clock that's also delivered
> by the line.

Pulse position and pulse with modulation still require a time
measurement which requires me to have a time reference on the receiver.


> Once you've introduced a PLL you are, of course, in
> something like analogue territory; and once you're
> there, a whole world of modulation techniques opens up.
> Amplitude-shift keying sounds about as self-clocking
> as it gets; there are ternary codes (positive-going pulse
> for 1, negative-going to 0), .......  And in the absence of
> any interfering signals these schemes are, trivially,
> self-timed.  Of course, as soon as you have other
> signals present on the same line, the obvious way
> to sort out one from another is by prior knowledge
> of the clock frequency.  Ask the radio guys about
> that - they are probably likely to speak of a "carrier"
> rather than "clock", and they may talk about "tuning"
> to choose a given signal!

If I am going to require a time reference at the receiver the simplest
scheme I know of is just async serial data with a start and a stop bit.
 No point in using Manchester encoding if I am transferring the data
over a wire just a few inches long.