Embedded clocks
in [FPGA]
|
Prev: Cyclone I & II memory fmax
Next: JOP as SOPC component
From: Frank Buss on 12 Aug 2006 09:26 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(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Brian Drummond on 12 Aug 2006 12:05 On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4(a)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
From: Brian Drummond on 12 Aug 2006 12:10 On 12 Aug 2006 04:12:43 -0700, "rickman" <spamgoeshere4(a)yahoo.com> wrote: >Jonathan Bromley wrote: >> On 11 Aug 2006 14:16:19 -0700, rickman >> <spamgoeshere4(a)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
From: rickman on 12 Aug 2006 13:16 Brian Drummond wrote: > On 11 Aug 2006 14:16:19 -0700, "rickman" <spamgoeshere4(a)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.
From: Jim Granville on 12 Aug 2006 14:55
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 |