Embedded clocks
in [FPGA]
|
Prev: Cyclone I & II memory fmax
Next: JOP as SOPC component
From: rickman on 11 Aug 2006 17:16 Frank Buss wrote: > rickman wrote: > > > Is self clocking on a single pin possible? I am thinking that the > > extra info has to be presented in some manner that requires either a > > timing or amplitude measurement. > > As Jim wrote, the one-wire bus can do this. With this concept you need only > one wire (and ground) to power and communicate with a device: > > http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf > http://www.maxim-ic.com/appnotes.cfm/an_pk/126 Thanks to everyone for their posts. Each of the above solutions require timing of the signal and so will not work without a clock (or timer) of a specified rate. The key is "specified". To decode a machester stream you need a time interval of about 3/4 of the bit time in order to blank the edge detector on the edge between bits. That interval can be somewhat broad, but must be known to at least better than 33%. So I can't read a Manchester stream at 10 Mbps and one at 1 Mbps with the same timer. Of course I can design a circuit that will synchronize the clock to a fixed rate bit stream. But that is a lot more complex. I am looking for something that will just plain clock the data across the interface without a requirement to know the frequency whether by measuring it, or a priori.
From: Frank Buss on 11 Aug 2006 17:46 rickman wrote: > Thanks to everyone for their posts. Each of the above solutions > require timing of the signal and so will not work without a clock (or > timer) of a specified rate. With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and 1. Should be easy to generate with an op-amp and to detect with another one. But I think it is easier to use a clock and normal digital signals. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Jim Granville on 11 Aug 2006 17:51 rickman wrote: > Frank Buss wrote: > >>rickman wrote: >> >> >>>Is self clocking on a single pin possible? I am thinking that the >>>extra info has to be presented in some manner that requires either a >>>timing or amplitude measurement. >> >>As Jim wrote, the one-wire bus can do this. With this concept you need only >>one wire (and ground) to power and communicate with a device: >> >>http://pdfserv.maxim-ic.com/en/an/onewirebus.pdf >>http://www.maxim-ic.com/appnotes.cfm/an_pk/126 > > > Thanks to everyone for their posts. Each of the above solutions > require timing of the signal and so will not work without a clock (or > timer) of a specified rate. The key is "specified". To decode a > machester stream you need a time interval of about 3/4 of the bit time > in order to blank the edge detector on the edge between bits. That > interval can be somewhat broad, but must be known to at least better > than 33%. So I can't read a Manchester stream at 10 Mbps and one at 1 > Mbps with the same timer. Of course I can design a circuit that will > synchronize the clock to a fixed rate bit stream. But that is a lot > more complex. I am looking for something that will just plain clock > the data across the interface without a requirement to know the > frequency whether by measuring it, or a priori. Why do you need such a loose frequency spec ? ALL schemes will clearly need some time-element. What you need is to reduce the Clock _tolerance_ and _power_ costs, to minimal levels. The one-wire (PWM data) designs change from a classic clock (which draws power all the time ) to a more async-based monostable ( so can idle at very low powers ). It also drops the clock tolerance to quite slack levels, met by the cheapest components. The overhead, is slightly less bandwidth efficency than other modulation methods. With one wire, the master provides the edges, and the slave the data (sometimes), and the slave can use very cheap / low power / fast wakeup RC oscillator. one-wire designs are implicitly duplex, and so are better suited than manchester to low cost slave nodes. They also work well with CAN transcievers, as that is a 'OR' BUS -jg
From: Jonathan Bromley on 12 Aug 2006 04:55 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. To achieve this I need only two things: (a) some means to measure the time between transitions, to a good enough precision; (b) enough memory to remember what's going on until I see a bit transition from 0 to 1 or back. Condition (a) means, in digital-land, some kind of oversampling and so it implies a *minimum* sampling clock rate; but measurement of edge-to-edge times imposes no lower limit on the data rate. I suspect rickman is looking for a scheme in which the data line can provide its own clock using some method other than oversampling. Pulse-position or pulse-width modulation does that well enough, as do a whole raft of PSK techniques, but all of them require some kind of phase-locked loop or related means to act as a "flywheel" so that you can detect deviations of the line signal from an average clock that's also delivered by the line. Once you've introduced a PLL you are, of course, in something like analogue territory; and once you're there, a whole world of modulation techniques opens up. Amplitude-shift keying sounds about as self-clocking as it gets; there are ternary codes (positive-going pulse for 1, negative-going to 0), ....... And in the absence of any interfering signals these schemes are, trivially, self-timed. Of course, as soon as you have other signals present on the same line, the obvious way to sort out one from another is by prior knowledge of the clock frequency. Ask the radio guys about that - they are probably likely to speak of a "carrier" rather than "clock", and they may talk about "tuning" to choose a given signal! -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley(a)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.
From: rickman on 12 Aug 2006 07:12
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 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. |