Embedded clocks
rickman
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.
PeteS
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
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
Jim Granville
> 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
Frank Buss
> 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, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
rickman
> 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.
Frank Buss
> 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.
Jim Granville
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
Jonathan Bromley
<spamgo...@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...@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.
rickman
> On 11 Aug 2006 14:16:19 -0700, rickman
> <spamgo...@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.
rickman
> 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.
Ralf Hildebrandt
> 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
Frank Buss
> 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
> 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.
Jonathan Bromley
<spamgo...@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.
Frank Buss
> 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
Brian Drummond
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
Brian Drummond
wrote:
>Jonathan Bromley wrote:
>> On 11 Aug 2006 14:16:19 -0700, rickman
>> <spamgo...@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
rickman
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.
Jim Granville
<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
rickman
> 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.
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.
> 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.
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.
> > 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 ).
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.
> 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.
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.
Frank Buss
> 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.
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.
> 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.
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.
Jim Granville
> Jim Granville wrote:
>
>>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.
>
>
> 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.
anything better than RC, has starting time issues, so usually runs
all the time, and that has power penalties.
>
>>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.
>
>
> 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.
>
>
>
>>> 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 ).
>
>
> 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.
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.
>>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.
>
>
> Yeah, I have thought about I2C, but it would have to run at High Speed
> to work properly due to the addressing overhead.
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.
> SPI would work too, but would use all four pins leaving us no spares.
SPI can work with 3 wires, if that helps.
> 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.
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
rickman
> anything better than RC, has starting time issues, so usually runs
> all the time, and that has power penalties.
RC is not even an oscillator without other componets so it really is
not a solution. I can get an oscillator that runs on 1 mA of current,
costs under $0.50 and has plenty of accuracy to do any of the above
protocols. So async serial is ok. One in and one out.
> > 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.
>
> 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.
A PWM bit level signal still has to do all the higher level stuff of
counting the bits in a word etc. So if there is an savings, it would
be very little.
> 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.
>
>
> 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.
The host would be another CPLD. The "host" has to take in two SPI
running near 100 kHz and four discrete signals. I have no info on how
the SPI data is framed. I2C is done in bytes, but my understanding is
that SPI has no defined protocol, it really is a non-standard standard.
I will have to get more info on how the SPI busses are being used
before I can decide if this will even work.
> > SPI would work too, but would use all four pins leaving us no spares.
>
> SPI can work with 3 wires, if that helps.
I could put an address on the SPI bus like I2C does it. I can't recall
at the moment why I felt it would need a fourth pin. I think because
of flagging which of the two SPI ports was running at that moment. But
that can be encoded in the data stream so I guess it could leave a pin
free.
> > 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.
>
> How many IO's do you need, on how many addresses ?
I don't understand. Do you mean the discrete signals?
> Do they need dataDirection register control, and read-back, or
> are simpler fixed OUT and IN acceptable ?
No, just four outputs. They are triggers with timing information, but
I don't know how precise they need to be.
> 64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.
You did not account for the two SPI ports that are being multiplexed.
Without more info on the protocol on the SPI ports, I can't count FFs.
But each one will need a buffer since the link will have to run much
faster than either of the two SPI ports. Also I don't even know if
this will work since SPI is full duplex, IIRC. As you shift out data
read data is coming back, right? Or is it still half duplex with the
read data and write data never happening at the same time? I would not
be able to buffer words and do full duplex. That sounds incompatible
to me.
Jacko
some time limit has to be placed on the stream to get data flow.
a delta sigma stream can be filtered at any fast rate and represent
many levels
the data rate will be limited by various factors.
a virtual grey code could be set up
with no -max to +max
when in the middle two states, either up or down is possible,
one option says clock 0, and one says clock 1
when on the outer two states, then eventually move into one of the
middle states. as you can not loop peak to peak
cheers
Jim Granville
> Jim Granville wrote:
>
>>anything better than RC, has starting time issues, so usually runs
>>all the time, and that has power penalties.
>
>
> RC is not even an oscillator without other componets so it really is
> not a solution. I can get an oscillator that runs on 1 mA of current,
> costs under $0.50 and has plenty of accuracy to do any of the above
> protocols. So async serial is ok. One in and one out.
RC osc would use the CPLD - not sure what 'other components' you mean.
If you are happy with 1mA and 50c, then that's fine.
I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
at a cost of a few cents. ( and appx 50uA at 1MHz )
>
>>>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.
>>
>>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.
>
>
> A PWM bit level signal still has to do all the higher level stuff of
> counting the bits in a word etc. So if there is an savings, it would
> be very little.
Again, it depends on your yardstick. When you are working with 32
Macrocell CPLDs, as I do often, a saving of 8 macrocells can be
very important.
<snip>
>>64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.
>
>
> You did not account for the two SPI ports that are being multiplexed.
> Without more info on the protocol on the SPI ports, I can't count FFs.
I thought this was a multi-slave plus master problem - you seem to be
talking only about the master above - what are the slaves ?
> But each one will need a buffer since the link will have to run much
> faster than either of the two SPI ports. Also I don't even know if
> this will work since SPI is full duplex, IIRC. As you shift out data
> read data is coming back, right? Or is it still half duplex with the
> read data and write data never happening at the same time? I would not
> be able to buffer words and do full duplex. That sounds incompatible
> to me.
SPI works like the simplest 8 bit shift registers, so it is duplex
capable.
Most SPI memories, work in half-duplex - they read the address info,
while floating SerialOUT, and then ignore SerialIN, while
driving serial out (if doing a read).
If you have to slave to two separate SPI streams, that you have little
control over, that could get complex very quickly.
-jg
PeteS
SPI is a spec in search of itself.
There are some variants to it. For a decent overview of the different
types, you could look at the interface specs on this device I use
http://products.zarlink.com/product_profiles/ZL38001.htm
(Look at the microport section).
One of the issues I ran into on the original Motorola implementation
was that the last data bit (lsb) was only valid for half a bit time -
so I had to generate a quadrature clock. (That was in the early 90s).
As you are doing it for yourself, you have no such limitation. SPI can
run at up to 4Mb/s on commercial parts, and I see no reason a CPLD
could not handle that.
Cheers
PeteS
rickman
> rickman wrote:
>
> > Jim Granville wrote:
> >
> >>anything better than RC, has starting time issues, so usually runs
> >>all the time, and that has power penalties.
> >
> >
> > RC is not even an oscillator without other componets so it really is
> > not a solution. I can get an oscillator that runs on 1 mA of current,
> > costs under $0.50 and has plenty of accuracy to do any of the above
> > protocols. So async serial is ok. One in and one out.
>
> RC osc would use the CPLD - not sure what 'other components' you mean.
>
> If you are happy with 1mA and 50c, then that's fine.
>
> I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
> at a cost of a few cents. ( and appx 50uA at 1MHz )
How do you get a CPLD to reliably oscillate with an RC?
> Again, it depends on your yardstick. When you are working with 32
> Macrocell CPLDs, as I do often, a saving of 8 macrocells can be
> very important.
I agree, but I am not sure there is any savings. Both methods have to
do the same work in framing bits and words so I don't see where the
savings would come in. That would require a more detailed analysis or
design. I suppose the one wire protocol might be able to have more
commonality between the rx and tx, but a half duplex uart could likely
do the same thing.
There are other considerations. If I can clearly show that a one-wire
approach would work and fit the part while a uart design would not,
that would be clear evidence. But I am currently working (the emphasis
on *currently*) in a very political environment where being right is no
guarantee of being "right". If a more "trusted" designer decided that
he was uncomfortable with the one-wire approach it would be gone
regardless of the facts.
> <snip>
> >>64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts.
> >
> >
> > You did not account for the two SPI ports that are being multiplexed.
> > Without more info on the protocol on the SPI ports, I can't count FFs.
>
> I thought this was a multi-slave plus master problem - you seem to be
> talking only about the master above - what are the slaves ?
I think I explained what I was building, but it may be scattered over
several different posts. The "thing" I am trying to figure out is in
essense a multiplexer and demultiplexer of several signals. There are
two interfaces that need to be brought out through a cable. The
connector is virtually out of pins and we don't want to make it larger.
Each interface has an SPI port with a CE since it drives multiple
slaves running at lowish rates. The interface also has two discrete
signals which are mostly for timing of control. The SPI port is used
to send setup commands and the discrete signals say "do it now". We
have added four pins to the connector before remembering that the
interface for each was a total of 6 pins and that we actually needed
two ports. Is it unlikely that we can add a total of 12 pins to the
connnector. So we need a mux.
The SPI ports can not be multiplexed together in the simple way since
they have separate masters that are not synchronized. So to multiplex
this will require capturing the data from both ports and muxing it at a
higher speed along with the discrete signals. I am limited by not
knowing the format of the data on the SPI busses.
It just occured to me that I really don't need to know the format of
the data if I just treat the signals as arbitrary data streams. I can
sample them at high enough rates that the timing information is not
significantly distorted and send them across in a very, very simple
scheme. I can sample each one in a round-robin manner at say 1 MHz for
a total clock rate of 10 MHz (10 signals in one direction, 2 in the
other). This interface would need a clock, datain, dataout and frame
sync. That will fill the four pins, but would also be flexible enough
that other discrete signals could be added with a small increase in
frequency.
One BIG advantage to doing it this way is that the latency is no more
than 2 clock cycles or 0.2 uS. I am also very confident that it could
be done in a 32 cell CPLD. The slave would be clocked by the
interface, so it does not need a crystal or other timing device. The
master can be a bit more complex since it is inside the unit, but
likely a ~10 MHz clock can be provided. The only remaining issue is
finding a CPLD that is low power and can be made tolerant of the
external signals. I would hate to have to buffer all 16 signals in the
cable.
> SPI works like the simplest 8 bit shift registers, so it is duplex
> capable.
>
> Most SPI memories, work in half-duplex - they read the address info,
> while floating SerialOUT, and then ignore SerialIN, while
> driving serial out (if doing a read).
>
> If you have to slave to two separate SPI streams, that you have little
> control over, that could get complex very quickly.
Yes, that is the part that has me concerned. But by explaining it to
you, I think I have figured out the best way to approach this. We'll
see if I can get the multiplexer to fit in terms of power and any other
constraints that pop up later.
Thanks for listening and offering your advice.
Brian Davis
>
> 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.
>
(e.g. MachXO) at the far end, you should be able to press the {D|P}LL
into service for clock recovery using a specially constructed waveform.
There was thread last year about sending bidirectional data over a
SATA cable without needing a CDR at the far end where I suggested
a clock phase modulation scheme:
http://groups.google.com/group/comp.arch.fpga/msg/42d1840c981c64e6
- send a clock with fixed rising edges and +/-90 degree
phase modulation of the falling edges
- divide by two to strip the phase modulation -> clean ref. clk
- double then phase shift for a mid-period sample clock
If the {D|P}LL phase detector & ctl logic only uses leading edges,
and doesn't mind the wild duty cycle swings, you could skip the
divide-by-2 and double steps.
I haven't tried that out yet, but I don't see any fundamental problems
with it ( other than wasting BW vs. other modulation schemes. )
Brian
rickman
Thanks for the ideas. I was not aware of the MACHXO parts. They are
suprizingly dense and cheap. Web pricing at Atmel for the 256 LUT part
is around $5 in moderate quantities.
I assume I would need a 2x clock to generate the 90 degree skewing of
the trailing edge or even a 4x clock if I don't want to play tricks
with using opposite phases clocking FFs.
This could work and would only use two pins, one in each direction.
But the device itself would be pushing the boundary of what I would
like to use. The smallest part is 256 LUTs and the smallest package is
a 100 pin Chip Scale BGA at 8x8 mm. There is one universal truth in
FPGAs and CPLDs; if you have a lot of IO, you will have a lot of logic
and if you have a lot of logic you will have a lot of IO. They don't
put large deivces in low pin count packages, ever!
The power consumption of the MACHXO is a bit high. I don't have an
exact number, but the standby current starts at 14 mA. But this is not
out of the ballpark and I will keep the idea in mind since it can use
half the pins of the other approach I have in mind.
Jim Granville
> Jim Granville wrote:
>
>>rickman wrote:
>>
>>
>>>Jim Granville wrote:
>>>
>>>
>>>>anything better than RC, has starting time issues, so usually runs
>>>>all the time, and that has power penalties.
>>>
>>>
>>>RC is not even an oscillator without other componets so it really is
>>>not a solution. I can get an oscillator that runs on 1 mA of current,
>>>costs under $0.50 and has plenty of accuracy to do any of the above
>>>protocols. So async serial is ok. One in and one out.
>>
>>RC osc would use the CPLD - not sure what 'other components' you mean.
>>
>>If you are happy with 1mA and 50c, then that's fine.
>>
>>I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc,
>>at a cost of a few cents. ( and appx 50uA at 1MHz )
>
>
> How do you get a CPLD to reliably oscillate with an RC?
Choose one with Schmitt pin options (also important if you want to try
i2c, where the slow edges will mess with non-schmitt CPLDs ).
That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices.
You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins,
the better the precision, and less it depends on the thresholds.
The numbers I gave are for ATF1502BE.
-jg
Jim Granville
<snip>
> It just occured to me that I really don't need to know the format of
> the data if I just treat the signals as arbitrary data streams. I can
> sample them at high enough rates that the timing information is not
> significantly distorted and send them across in a very, very simple
> scheme. I can sample each one in a round-robin manner at say 1 MHz for
> a total clock rate of 10 MHz (10 signals in one direction, 2 in the
> other). This interface would need a clock, datain, dataout and frame
> sync.
If you use Sync related direction control ( see SPI memories ), you can
share/common the datain/dataout : eg the first 12 clocks are one way,
the last 4 are the other way, in a simple 16 clock frame, with spare room )
-jg
JustJohn
>
> How do you get a CPLD to reliably oscillate with an RC?
>
If you can afford 2 more CPLD pins, Peter described it for an FPGA, but
should work for CPLD:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1
I'm curious:
1) how well does that circuit scale up in frequency,
2) what your frequency needs are?
As described, using 470K resistors, the power for that 3 pin RC
oscillator looks miniscule.
Add a little more gating, you can even shut it off, and re-start time
doesn't look much more than half a clock period.
Jim Granville
> rickman wrote:
>
>>How do you get a CPLD to reliably oscillate with an RC?
>>
>
>
> If you can afford 2 more CPLD pins, Peter described it for an FPGA, but
> should work for CPLD:
>
> http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1
>
> I'm curious:
> 1) how well does that circuit scale up in frequency,
> 2) what your frequency needs are?
>
> As described, using 470K resistors, the power for that 3 pin RC
> oscillator looks miniscule.
RC Osc power is not just resistor power; a significant amount is the
linear-region Icc from the pin buffers that are not square wave driven.
> Add a little more gating, you can even shut it off, and re-start time
> doesn't look much more than half a clock period.
Restart time is instant, but you do need to watch the start(idle) values
as the first half cycle time can differ from the others, as the circuit
changes from rest state, to the ping-pong oscillation cycles.
With 3 terminal Osc's, you should also design the Pinout/PCB, so the
'linear' node is adajcent to the positive acting pin(cap), and not the
negative acting pin. eg a good pinout is : GND RC Cap+ Res-
-jg
rickman
The ATF15xx and Coolrunner II are no gos because of the dual voltages
required. Also the ATF parts only come in the relatively huge TQFP44
packages which are four times larger than the csBGA of the Coolrunner
parts. I can make a schmitt trigger easily enough with a couple of
resistors and an output pin.
How about some details on the RC oscillator? I have not seen a 3 pin
oscillator before.
Jim Granville
> Jim Granville wrote:
>
>>rickman wrote:
>>
>>>How do you get a CPLD to reliably oscillate with an RC?
>>
>>Choose one with Schmitt pin options (also important if you want to try
>>i2c, where the slow edges will mess with non-schmitt CPLDs ).
>>
>>That's Atmel's ATF1502BE (32MC), or CoolrunnerII devices.
>>
>>You can make 1 pin, 2 pin, or 3 pin Oscillators - the more pins,
>>the better the precision, and less it depends on the thresholds.
>>
>>The numbers I gave are for ATF1502BE.
>
>
> The ATF15xx and Coolrunner II are no gos because of the dual voltages
> required.
What we need is a CPLD like the Freescale RS08, or the SiLabs
C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :)
[ ATF1502BE draws 2.3uA, but needs two rails.... ]
> Also the ATF parts only come in the relatively huge TQFP44
> packages which are four times larger than the csBGA of the Coolrunner
> parts.
Yes, I have already mentioned to Atmel that TQFP44 is large in today's
designs....
> I can make a schmitt trigger easily enough with a couple of
> resistors and an output pin.
>
> How about some details on the RC oscillator? I have not seen a 3 pin
> oscillator before.
One Pin : Bidirectional pin, Open Collector, Res Pullup, Swings between
Schmitt VthP and VthN - Tolerance is that of Hyst Band.
Duty cycle is narrow. Hard to gate, as CAP is never 0V.
Can VCO modulate.
Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups,
Swings from GND to VthP, Nominally 50% duty cycle. Gates very well
Can VCO modulate.
Two Pin B : One IP, one OP, Classic HC14 Osc, single Rfb, and Cap,
Swings VthP to VthN, Duty cycle is nominally 50%, Poor VCO modulation.
Three Pin: One IP and 2 OPs. (See 4060, 4541 et al) Positive feedback to
a CAP, negative feedback via resistor, with optional overshoot resistor
from CAP to IP pin. Needs layout to have +ve FB next to RC IP pin.
Has nominal immunity to pin thresholds, and some PSRR, poor VCO modulation.
Gives lowest Icc, as the signal spends least time in high current IP
regions.
Simplest form, is a non-inverter, followed by inverter (order matters).
Can have latches added, to 'de-fur' and can be gated with a little care.
See the other link in this thread
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1
This is a 3 termal RC osc, with a SR latch.
-jg
JustJohn
> JustJohn wrote:
> > As described, using 470K resistors, the power for that 3 pin RC
> > oscillator looks miniscule.
>
> RC Osc power is not just resistor power; a significant amount is the
> linear-region Icc from the pin buffers that are not square wave driven.
>
To be clear, I'll be referring to Peter's circuit (I can't post one
myself, and am too lazy right now to attempt ASCII artwork). Let's call
the top resistor Rc, since it charges the Cap, and call the bottom one
Rs, since it feeds a Sense pin. This simple circuit brings a nice
collection of subtleties with it:..
There are roughly three regions of operation (six, it's a symmetric
circuit, let's look at just after switching C to ground):
A) Immediately after switching , C has pushed Rs to VCC/2 below ground,
and C is charging through both Rc (via the inverted output pin) and and
Rs (via the sense pin protection diode).
B) Some time later, the sense pin protection diode is no longer fwd
biased, and C is charging through Rc only. Rs serves only to connect C
to the sense pin (I'll assume that frequency is low enough that sense
pin capacitance can be ignored).
C) Sense pin reaches linear region, starts causing Icc current draw, in
addition to the charging current Rc.
I hadn't thought much about FPGA input structure before this. I had
generally assumed, unlike logic buffers such as 'ALVC245 and the like,
whose totem-pole inputs can consume enough power near threshold to
destroy themselves, that newer multistandard FPGA inputs were more like
a comparator, and not subject to damage, or even very much increase in
current when near threshold. There are no warnings in the
datasheet...certainly no "Icc current vs. input voltage" chart to
indicate that near threshold operation is of concern..
2) Can anyone say anything about Icc vs. input level for either FPGAs
or, eg. CoolRunnrer PLDs?
> > Add a little more gating, you can even shut it off, and re-start time
> > doesn't look much more than half a clock period.
>
> Restart time is instant, but you do need to watch the start(idle) values
> as the first half cycle time can differ from the others, as the circuit
> changes from rest state, to the ping-pong oscillation cycles.
Of course charging starts immediately, I meant the time from enable to
the 1st threshold crossing at the sense pin. I was wrong in saying
"more" than half a clock period. The first half period should be
shorter than periods that follow, because C only has to charge from
ground to threshold, while in later half periods, C charges from
~VCC/2 below ground to threshold.
Jim Granville
> Jim Granville wrote:
>
>>JustJohn wrote:
>>
>>>As described, using 470K resistors, the power for that 3 pin RC
>>>oscillator looks miniscule.
>>
>>RC Osc power is not just resistor power; a significant amount is the
>>linear-region Icc from the pin buffers that are not square wave driven.
>>
>
> 1) (Jim) Do you have a more precise quantifier than "significant"?
For a good example graph, look at the data of the 74LVC14A, Fig 9 on my
copy.
http://www.standardics.philips.com/products/lvc/pdf/74lvc14a.pdf
Here, you'll see the classic double peaks of a Schmitt transfer.
Non-Schmitts are worse: Similar skirts, but with a single, higher peak.
There can be variations in the peaks, and skirt shapes.
A two terminal Osc will trace the 'butterfly' between the peaks, and so
average 4mA Icc on this device.
A three terminal osc is appx 25-30% of that.
> To be clear, I'll be referring to Peter's circuit (I can't post one
> myself, and am too lazy right now to attempt ASCII artwork). Let's call
> the top resistor Rc, since it charges the Cap, and call the bottom one
> Rs, since it feeds a Sense pin. This simple circuit brings a nice
> collection of subtleties with it:..
>
> There are roughly three regions of operation (six, it's a symmetric
> circuit, let's look at just after switching C to ground):
> A) Immediately after switching , C has pushed Rs to VCC/2 below ground,
> and C is charging through both Rc (via the inverted output pin) and and
> Rs (via the sense pin protection diode).
> B) Some time later, the sense pin protection diode is no longer fwd
> biased, and C is charging through Rc only. Rs serves only to connect C
> to the sense pin (I'll assume that frequency is low enough that sense
> pin capacitance can be ignored).
> C) Sense pin reaches linear region, starts causing Icc current draw, in
> addition to the charging current Rc.
>
> I hadn't thought much about FPGA input structure before this. I had
> generally assumed, unlike logic buffers such as 'ALVC245 and the like,
> whose totem-pole inputs can consume enough power near threshold to
> destroy themselves, that newer multistandard FPGA inputs were more like
> a comparator, and not subject to damage, or even very much increase in
> current when near threshold. There are no warnings in the
> datasheet...certainly no "Icc current vs. input voltage" chart to
> indicate that near threshold operation is of concern..
I'm not sure about damage, but certainly the 4mA linear region of the
LVC14a example, might play havoc with someones uA power budget.
Modern FPGAs are pretty poor low power devices, so you'll likely just
get a shrug from their vendors, but some CPLDs are sub 20uA, and so this
can be important. It _should_ be in the uA CPLD data sheets.
I have to smile at the MAX II low power marketing spin, where they
REMOVE the power, to claim 'low power', and add many discrete components
to do this. Remember Resistor-Transistor Logic ?
>
> 2) Can anyone say anything about Icc vs. input level for either FPGAs
> or, eg. CoolRunnrer PLDs?
It is not hard to measure this, especially once you understand the basic
shape, and the peak(s) you are looking for.
You do need to have a low voltage drop across the current sense.
-jg
Symon
news:1155472497....@m79g2000cwm.googlegroups.com...
>
> I haven't tried that out yet, but I don't see any fundamental problems
> with it ( other than wasting BW vs. other modulation schemes. )
>
> Brian
>
Neat. I guess a problem could be that the signal has some data dependent DC
component. But 8B10B coding fixes that.
Cheers, Syms.
rickman
> What we need is a CPLD like the Freescale RS08, or the SiLabs
> C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :)
> [ ATF1502BE draws 2.3uA, but needs two rails.... ]
The Coolrunner XPLA3 parts are pretty good. Other than not having
schmitt trigger inputs, what don't you like about them?
> > How about some details on the RC oscillator? I have not seen a 3 pin
> > oscillator before.
>
> One Pin : Bidirectional pin, Open Collector, Res Pullup, Swings between
> Schmitt VthP and VthN - Tolerance is that of Hyst Band.
> Duty cycle is narrow. Hard to gate, as CAP is never 0V.
> Can VCO modulate.
If I understand correctly, this circuit would generate a sawtooth on
the cap with a very short low drive time on the output.
> Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups,
> Swings from GND to VthP, Nominally 50% duty cycle. Gates very well
> Can VCO modulate.
I don't get this one at all. I looked up the 4046 but all descriptions
I could find treat the VCO as a black box. I am guessing that the two
pins are driven with opposite polarity and the cap is grounded at one
end or the other all the time. So it would be charged like the one pin
approach and then discharged like the one pin approach. So this is a
pair of the one pin drivers to give you 50/50 duty cycle?
This seems simple. Any issues with startup? Does it need FFs anywhere
to make it work without noise? I would think that the lack of schmitt
trigger inputs would require a FF.
> Two Pin B : One IP, one OP, Classic HC14 Osc, single Rfb, and Cap,
> Swings VthP to VthN, Duty cycle is nominally 50%, Poor VCO modulation.
This one I know.
> Three Pin: One IP and 2 OPs. (See 4060, 4541 et al) Positive feedback to
> a CAP, negative feedback via resistor, with optional overshoot resistor
> from CAP to IP pin. Needs layout to have +ve FB next to RC IP pin.
> Has nominal immunity to pin thresholds, and some PSRR, poor VCO modulation.
>
> Gives lowest Icc, as the signal spends least time in high current IP
> regions.
>
> Simplest form, is a non-inverter, followed by inverter (order matters).
>
>
> Can have latches added, to 'de-fur' and can be gated with a little care.
>
> See the other link in this thread
> http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sTechX_ID=pa_six_easy&iLanguageID=1&iCountryID=1
>
> This is a 3 termal RC osc, with a SR latch.
This one is clear. Thanks.
Jim Granville
> Jim Granville wrote:
>
>> What we need is a CPLD like the Freescale RS08, or the SiLabs
>>C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :)
>> [ ATF1502BE draws 2.3uA, but needs two rails.... ]
>
>
> The Coolrunner XPLA3 parts are pretty good. Other than not having
> schmitt trigger inputs, what don't you like about them?
I like their JTAG enable pin, so you don't have to loose valuable pins
for JTAG - but they are narrow Vcc operation, and only promise < 100uA,
and Xilinx do not have them on the on-line store, and are sparse
elsewhere, so have that NFND look about them....
How long is your product lifetime ?
>>Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups,
>>Swings from GND to VthP, Nominally 50% duty cycle. Gates very well
>>Can VCO modulate.
>
>
> I don't get this one at all. I looked up the 4046 but all descriptions
> I could find treat the VCO as a black box. I am guessing that the two
> pins are driven with opposite polarity and the cap is grounded at one
> end or the other all the time. So it would be charged like the one pin
> approach and then discharged like the one pin approach. So this is a
> pair of the one pin drivers to give you 50/50 duty cycle?
>
> This seems simple. Any issues with startup? Does it need FFs anywhere
> to make it work without noise? I would think that the lack of schmitt
> trigger inputs would require a FF.
Yes, normally it is simply a SR latch, with some logic to catch S=R=H.
When running, S,R cross their thresholds only briefly, to trigger the
other phase.
-jg
rickman
> rickman wrote:
> > schmitt trigger inputs, what don't you like about them?
>
> I like their JTAG enable pin, so you don't have to loose valuable pins
> for JTAG - but they are narrow Vcc operation, and only promise < 100uA,
> and Xilinx do not have them on the on-line store, and are sparse
> elsewhere, so have that NFND look about them....
>
> How long is your product lifetime ?
Xilinx still sells much older CPLDs and the XPLA3 parts are 5 volt
tolerant which may not be in high demand in new designs, but you can't
easily design the part out with a non-5 volt tolerant part in its
place.
I can buy them from stock at Digikey, so someone is still buying them.
> >>Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups,
> >>Swings from GND to VthP, Nominally 50% duty cycle. Gates very well
> >>Can VCO modulate.
> >
> >
> > I don't get this one at all. I looked up the 4046 but all descriptions
> > I could find treat the VCO as a black box. I am guessing that the two
> > pins are driven with opposite polarity and the cap is grounded at one
> > end or the other all the time. So it would be charged like the one pin
> > approach and then discharged like the one pin approach. So this is a
> > pair of the one pin drivers to give you 50/50 duty cycle?
> >
> > This seems simple. Any issues with startup? Does it need FFs anywhere
> > to make it work without noise? I would think that the lack of schmitt
> > trigger inputs would require a FF.
>
> Yes, normally it is simply a SR latch, with some logic to catch S=R=H.
> When running, S,R cross their thresholds only briefly, to trigger the
> other phase.
Thanks for the tip. I think I will remember this circuit. It would
appear to me that this circuit has more dependance on Vth and so would
change frequency with temperature more than the three pin circuit which
is supposed to be independant of Vth (of which I am not totally
convinced). Peter's analysis of the three pin circuit looks pretty
good. Any numbers available on the two pin circuit above?
Jim Granville
>>>I don't get this one at all. I looked up the 4046 but all descriptions
>>>I could find treat the VCO as a black box. I am guessing that the two
>>>pins are driven with opposite polarity and the cap is grounded at one
>>>end or the other all the time. So it would be charged like the one pin
>>>approach and then discharged like the one pin approach. So this is a
>>>pair of the one pin drivers to give you 50/50 duty cycle?
>>>
>>>This seems simple. Any issues with startup? Does it need FFs anywhere
>>>to make it work without noise? I would think that the lack of schmitt
>>>trigger inputs would require a FF.
>>
>>Yes, normally it is simply a SR latch, with some logic to catch S=R=H.
>>When running, S,R cross their thresholds only briefly, to trigger the
>>other phase.
>
>
> Thanks for the tip. I think I will remember this circuit. It would
> appear to me that this circuit has more dependance on Vth and so would
> change frequency with temperature more than the three pin circuit which
> is supposed to be independant of Vth (of which I am not totally
> convinced). Peter's analysis of the three pin circuit looks pretty
> good. Any numbers available on the two pin circuit above?
Vth of CMOS does not change much with temperature, but the biggest
variable, is the absolute value of Vth : that is a process variable.
and being digital companies, FPGA vendors will not bother to band
Vth as anything other than logic levels....
To check the dependance on Vth, simply drop any of these into spice :)
On the 3 pin one, as Vth varies one half of the cycle lengthens, whilst
the other half shortens - so the frequency is nominally compensated, but
duty cycle varies.
-jg
Brian Davis
>
>This could work and would only use two pins, one in each direction.
>like to use.
>
Your four pin scheme is a simpler solution if you have the pins, then
you wouldn't need to find a small part with DLL/PLL.
>
>I assume I would need a 2x clock to generate the 90 degree skewing of
>the trailing edge or even a 4x clock if I don't want to play tricks
>with using opposite phases clocking FFs.
>
Yes; I'd probably try a 2x clock with DDR I/O for the transmit
waveform.
Symon wrote:
>
> Neat. I guess a problem could be that the signal has some data dependent DC
> component. But 8B10B coding fixes that.
>
Right, that clock modulation scheme duplicates the DC balance of the
transmit data; 8B10B should be a nice fit, giving both DC balance and
a sync mechanism for alignment.
Also, if you want to run near max cable/driver BW out & back, going to
a 4x multiply at the "slave" instead of a 2x would make the narrowest
modulated clock pulse width the same width as the bit period of the
return data path, giving 1/4 rate outbound and 1x inbound data rates.
Brian