Embedded clocks

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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


Re: Embedded clocks
Quoted text here. Click to load it

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


Re: Embedded clocks
Quoted text here. Click to load it

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


Re: Embedded clocks
Quoted text here. Click to load it

Which means what, exactly ? fs ?

   Idealy the decoder would not have a clock, but rather the data
Quoted text here. Click to load it

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


Re: Embedded clocks

Quoted text here. Click to load it

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

Re: Embedded clocks
Quoted text here. Click to load it

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.


Re: Embedded clocks

Quoted text here. Click to load it

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

Re: Embedded clocks
Quoted text here. Click to load it

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.


Re: Embedded clocks

Quoted text here. Click to load it

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

Re: Embedded clocks
Quoted text here. Click to load it

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




Re: Embedded clocks
On 11 Aug 2006 14:16:19 -0700, rickman


Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded clocks
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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.


Re: Embedded clocks

Quoted text here. Click to load it

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

Re: Embedded clocks

Quoted text here. Click to load it

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

Re: Embedded clocks
On 12 Aug 2006 04:12:43 -0700, rickman

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

[...]

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded clocks

Quoted text here. Click to load it

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


Re: Embedded clocks
<snip>
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Re: Embedded clocks
Quoted text here. Click to load it

But if I have an oscillator, I have a clock available.  That is my
point.  RS-232 has very loose requirements for a clock.  An RC may not
be good enough, but it doesn't take much.

Quoted text here. Click to load it

Way too complex.  I am looking at a very small package and I may be
limited to 64 logic cells.  In fact I don't know that I can make this
work in such a small part.  The problem is that one end of the link has
to be built into a cable housing where the signals are fanned out
again.  I don't need a lot of IO, but I expect it will take more than
64 logic cells.


Quoted text here. Click to load it

I don't see one wire as being any simpler than a UART.  One wire is
just bit async rather than byte async.  You still need a timer to time
the bits.

Quoted text here. Click to load it

Yeah, I have thought about I2C, but it would have to run at High Speed
to work properly due to the addressing overhead.  SPI would work too,
but would use all four pins leaving us no spares.  A UART interface
could use two wires, one for transmit and one for receive.  The word
size can be application specific with dedicated bits for discrete
signals.  Most importantly, I think it will be the smallest in a CPLD.


Re: Embedded clocks

Quoted text here. Click to load it

I, and maybe Jim, assumed that you have a more powerful master and multiple
slaves, which you scan. Then it is easier and cheaper to use just some SMD
resistor and capacitor than an oscillator, which is reliable with the one
wire bus, if you provide one exact clock from a master.

Quoted text here. Click to load it

How fast do you need to communicate? Maybe you can do all with a CPLD, but
with the HCS08 you have a tested 100 kbps I2C bus integrated (and up to 1
mbps with reduced bus loading) and it is easier to program a
microcontroller than a FPGA (I've programmed it in an other project with a
C compiler).

http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S08GB60.pdf

The 32 kbyte Flash single unit price is $8.81, which is more than twice as
expensive as the 64 macro cell CPLD XC9572XL-10VQG64C, but you don't need
any more external components, if you need A/D converters and the precision
of the internal oscillator is good enough for your application.

But after taking a look at the CPLDs from Xilinx, maybe this is a good
idea, too. I didn't know that they have integrated Flash, so you need only
some external RC component for the clock. Is a CPLD big enough for a CPU
core? This would be the ideal combination: high-speed tasks implemented in
VHDL and complex tasks implemented with an integrated CPU.

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

Re: Embedded clocks

Quoted text here. Click to load it

anything better than RC, has starting time issues, so usually runs
all the time, and that has power penalties.

Quoted text here. Click to load it

build them both, and count the macrocells :)

UARTs need (commonly) /16 resettable counter on RX, and a /16 non
resetable counter on TX, plus the byte buffers in both directions.

So that's at least 8 macrocells running higher than the bit-rate,
plus appx 4 more do do the framing, vs 3-4 for PWM bus.

PWM Osc is gated-monostable type at 4x bit rate - so power is lower.
A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect

Simulating all this is not that easy, on today's tools, which are
designed for a master-clock approach.


Quoted text here. Click to load it

CPLDs have no problems with speed, but the host speed may be a stumbling
block. Philips talked about 3.4MHz i2c, but nothing seems to have hit
the streets. I see they now have a FM+ spec, which is high drive i2c,
at 1MBd, also well within CPLD's reach.

i2c Address info can be compile-time-coded into CPLDs, to save pins
and macrocell resource.

Quoted text here. Click to load it

SPI can work with 3 wires, if that helps.

Quoted text here. Click to load it


How many IO's do you need, on how many addresses ?

Do they need dataDirection register control, and read-back, or
are simpler fixed OUT and IN acceptable ?

64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.

-jg


Site Timeline