Embedded clocks

Frank Buss wrote:
> 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.

The problem is lack of pins.  We are looking at a situation where we
don't want to make a connector any larger.  We need to multiplex two
separate bidirectional serial data streams and four discrete signals
over four or less pins.  I was thinking about ways of doing this and
realized that I had to provide a clock in the decoder.  So I either
have to use a pin or I have to add an oscillator to the decoder.  Since
the decoder will be in a cable, I need to keep it minimal.

Actually, decoder is a misnomer since it will have to both send and
receive.  So I don't see any way to get around the need for a timing
reference, either on a pin or by supplying an oscillator.  Most likely
it will be on a pin.  Right now I like the idea of using I2C, but I
will need to perform a detailed analysis of the tradeoffs vs. standard
async with separate clock, I2C, SPI and Manchester encoding.  I see
there are some very small packages for CPLDs, but they don't have much
logic in them.  I don't know if I can design such a transceiver in 64
logic cells.

rickman wrote:

> Is self clocking on a single pin possible?

What about a synchronisation pulse or word at the begin of every 
transmission? The fast clock sources a counter, that has to be active, 
while  synchronisation pulse / word is been received. (In other words: 
The length of the sync pulse / word is measured - the reference time 
interval.) After this you know (with some error) the frequency of the 
incoming data stream.

All you need is a short time stable (long time unstable) oscillator (RC 
oscillator). For every transmission a new sync pulse / word is needed.

This kind of sync pulse / word is used for RFID transmission from 
interrogator to tag.


With a manchester encoded data stream it is furthermore possible to stay 
synchronized. During reception the sync machine may work too and if a 
data symbol is received that has equal length to the reference time 
interval the new measured length of this symbol may be used as new 
(re-synchronized) reference time interval.


The disadvantage: You need a fast clock - fast enough for even your 
highest data rates.

Ralf

rickman wrote:

> 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.

A serial data protocol like RS232 needs exact timing on sender and receiver
side. With the 1-wire protocol you need only one exact clock from the
master, the slave can use inexpensive RC components for timing and clock.

I've just implemented a VHDL program for reading the unique id of the
DS2432, which sits on my Spartan 3E starter kit. Some real-time logic
analyzer data:

http://www.frank-buss.de/tmp/1wire.png

As you can see, the timing precision of the device can varying by nearly a
factor of 2 and it would be still possible to communicate with it.

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

rickman wrote:

> Actually, decoder is a misnomer since it will have to both send and
> receive.  So I don't see any way to get around the need for a timing
> reference, either on a pin or by supplying an oscillator.  Most likely
> it will be on a pin.  Right now I like the idea of using I2C, but I
> will need to perform a detailed analysis of the tradeoffs vs. standard
> async with separate clock, I2C, SPI and Manchester encoding.  I see
> there are some very small packages for CPLDs, but they don't have much
> logic in them.  I don't know if I can design such a transceiver in 64
> logic cells.

Maybe you could use a microcontroller, like the MC9S08 from Freescale,
which I've used in a project: It is inexpensive, has A/D converters
integrated, so you don't need to use extra analog pins for the discrete
signals, I2C is implemented in hardware on the controller and it is about
1cm^2 wide, so it should fit in a cable (no other external components are
required, because it has lots of flash integrated and can generate the
system clock internally, if you don't need crystal precision). Then the
four pins of the cable would be: Vdd, Vcc, I2C data, I2C clock.

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

On 12 Aug 2006 04:12:43 -0700, rickman
 <spamgoeshere4@yahoo.com> wrote:

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

I can't because (a) I don't know whether the data stream is too
fast for me to measure with 1MHz, and (b) assuming there is no
aliasing going on, both streams have no data transitions in them.
I carefully pointed out in my post the need for (a) sufficiently
fast sampling, and (b) a variety of bits in the data stream.

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

And surely, if I can measure it, I can then demodulate it?

[...]

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

I don't really know what you mean by "a time reference".  My point
about measurement is that you can demodulate ANY data rate up to
some upper limit determined by the time resolution of your receiver,
however that may be determined.  (There was an interesting discussion
about the relationship between that limit and the resolution - is the
maximum data rate 1/3 or 1/4 of your clock rate??? - but that doesn't
affect my argument.)  You don't need any prior knowledge of the
data rate whatsoever, except to be sure that it's slower than your
upper limit.

>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.

Do I infer that you're looking for a scheme in which the clock can
be extracted with NO timing components at all in the receiver, i.e.
by combinational decoding of the data line?  If so, I'm pretty sure
it can't be done with any 2-level line discipline; but as soon as you
permit 3-level signalling, I think it's possible.
-- 
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.

Frank Buss wrote:

> http://www.frank-buss.de/tmp/1wire.png

I've added it, with some more explanation, to the Wikipedia page:

http://en.wikipedia.org/wiki/1-Wire

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

On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4@yahoo.com>
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. 

If you *know* it's Manchester coding, and have *no idea* of the clock
rate, the problem can be solved if you can afford to spend some time
framing up. It's harder if you instantly need to decode the first bit.

Basic approach is to measure the times between transitions, compare
several successive transition intervals, and classify them as "long" or
"short" compared to each other. THEN take a mean value, apply blanking
(clock recovery), and start framing up. 

(If you need to retroactively decode the first bit, you'll need to store
and re-visit the first few transition times. This may be easier with the
assistance of an embedded CPU)

There will need to be some constraints on data, otherwise an infinite
sequence of '0's or '1's would take infinitely long to decode. In SP/DIF
or EBU/AES digital audio for example, this comes in the form of an
extra-long transition interval (1.5 bit times) during a preamble, the
trailing edge of which is guaranteed to correctly sync the clock
recovery circuit.


>So I can't read a Manchester stream at 10 Mbps and one at 1
>Mbps with the same timer. 

This approach should allow that - given some quiet time between
different streams, to enable you to recognise a switch in rate.

- Brian

On 12 Aug 2006 04:12:43 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>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

Where are the "different" bits specified by Jonathan in that sequence?
These are both sequences of *identical* bits - all 1's or all 0's (when
stripped of their clock), which Johnathan already covered.

- Brian

Brian Drummond wrote:
> On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4@yahoo.com>
> 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.
>
> If you *know* it's Manchester coding, and have *no idea* of the clock
> rate, the problem can be solved if you can afford to spend some time
> framing up. It's harder if you instantly need to decode the first bit.
>
> Basic approach is to measure the times between transitions, compare
> several successive transition intervals, and classify them as "long" or
> "short" compared to each other. THEN take a mean value, apply blanking
> (clock recovery), and start framing up.
>
> (If you need to retroactively decode the first bit, you'll need to store
> and re-visit the first few transition times. This may be easier with the
> assistance of an embedded CPU)
>
> There will need to be some constraints on data, otherwise an infinite
> sequence of '0's or '1's would take infinitely long to decode. In SP/DIF
> or EBU/AES digital audio for example, this comes in the form of an
> extra-long transition interval (1.5 bit times) during a preamble, the
> trailing edge of which is guaranteed to correctly sync the clock
> recovery circuit.

I am familiar with how to recover Manchester data.  The problem is that
you *do* have to measure the clock rate or know it.

The thread has broken into two discussions. One is about how to recover
Manchester data and the minimum rate clock to use.  The other is about
self clocking data encoding and whether you can decode it without a
time reference.  In reality there is not a practical way to do that.  I
had not given the question much thought when I posed it and I see now
that all the "self clocking" schemes are framed in some rate and the
clock is recovered given a reference.

> >So I can't read a Manchester stream at 10 Mbps and one at 1
> >Mbps with the same timer.
>
> This approach should allow that - given some quiet time between
> different streams, to enable you to recognise a switch in rate.

Yes, you can in essence construct a very wide range PLL to decode a
Manchester signal.  It still uses a time reference and a very complex
one at that.  I was actually looking for a simple way to decode a
combined data and clock signal without having a time reference.  For
most practical purposes this is not doable.

An analog of what I would like to do is the I2C bus.  It is designed to
work at any rate down to 0 Hz.  Of course it uses a clock separate from
data.  It would be nice if that could be done on one digital wire
rather than two.  But I see that this is not practical without going to
multiple voltage levels or adding a reference clock.

rickman wrote:
<snip>
> 
> 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.

This is not quite the simplest.

It imposes clock tolerance requirements, and is half duplex, so the
Transmit has to generate it's own clock.

If you want to ease that, you can do something like the LIN bus, which
gives a auto-baud pre-amble, but that is getting complex for CPLDs.

>  No point in using Manchester encoding if I am transferring the data
> over a wire just a few inches long.

Many TV remote's use manchester, and they do that to allow the use of RC 
clocks, and straight from battery operation.

If you want the simplest scheme, in a CPLD, use one-wire, because that
is duplex, and does not need to generate a TX clock, just a Tx time slot 
( which can be monostable derived ).

If you can get up to 2 wires, then i2c & variants are a widely used 
standard, and it does not take too much CPLD resource.

There is something of a flurry of PowerControl busses being released at 
the moment, some are one wire, and some are 2 wire.
Geberally, they try to be faster, and more low voltage tolerant, than i2c.

-jg