Embedded clocks
in [FPGA]
|
Prev: Cyclone I & II memory fmax
Next: JOP as SOPC component
From: rickman on 12 Aug 2006 07:48 Frank Buss wrote: > rickman wrote: > > > Thanks to everyone for their posts. Each of the above solutions > > require timing of the signal and so will not work without a clock (or > > timer) of a specified rate. > > With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and > 1. Should be easy to generate with an op-amp and to detect with another > one. But I think it is easier to use a clock and normal digital signals. The problem is lack of pins. We are looking at a situation where we don't want to make a connector any larger. We need to multiplex two separate bidirectional serial data streams and four discrete signals over four or less pins. I was thinking about ways of doing this and realized that I had to provide a clock in the decoder. So I either have to use a pin or I have to add an oscillator to the decoder. Since the decoder will be in a cable, I need to keep it minimal. Actually, decoder is a misnomer since it will have to both send and receive. So I don't see any way to get around the need for a timing reference, either on a pin or by supplying an oscillator. Most likely it will be on a pin. Right now I like the idea of using I2C, but I will need to perform a detailed analysis of the tradeoffs vs. standard async with separate clock, I2C, SPI and Manchester encoding. I see there are some very small packages for CPLDs, but they don't have much logic in them. I don't know if I can design such a transceiver in 64 logic cells.
From: Ralf Hildebrandt on 12 Aug 2006 08:24 rickman wrote: > Is self clocking on a single pin possible? What about a synchronisation pulse or word at the begin of every transmission? The fast clock sources a counter, that has to be active, while synchronisation pulse / word is been received. (In other words: The length of the sync pulse / word is measured - the reference time interval.) After this you know (with some error) the frequency of the incoming data stream. All you need is a short time stable (long time unstable) oscillator (RC oscillator). For every transmission a new sync pulse / word is needed. This kind of sync pulse / word is used for RFID transmission from interrogator to tag. With a manchester encoded data stream it is furthermore possible to stay synchronized. During reception the sync machine may work too and if a data symbol is received that has equal length to the reference time interval the new measured length of this symbol may be used as new (re-synchronized) reference time interval. The disadvantage: You need a fast clock - fast enough for even your highest data rates. Ralf
From: Frank Buss on 12 Aug 2006 08:51 rickman wrote: > If I am going to require a time reference at the receiver the simplest > scheme I know of is just async serial data with a start and a stop bit. > No point in using Manchester encoding if I am transferring the data > over a wire just a few inches long. A serial data protocol like RS232 needs exact timing on sender and receiver side. With the 1-wire protocol you need only one exact clock from the master, the slave can use inexpensive RC components for timing and clock. I've just implemented a VHDL program for reading the unique id of the DS2432, which sits on my Spartan 3E starter kit. Some real-time logic analyzer data: http://www.frank-buss.de/tmp/1wire.png As you can see, the timing precision of the device can varying by nearly a factor of 2 and it would be still possible to communicate with it. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Frank Buss on 12 Aug 2006 09:02 rickman wrote: > Actually, decoder is a misnomer since it will have to both send and > receive. So I don't see any way to get around the need for a timing > reference, either on a pin or by supplying an oscillator. Most likely > it will be on a pin. Right now I like the idea of using I2C, but I > will need to perform a detailed analysis of the tradeoffs vs. standard > async with separate clock, I2C, SPI and Manchester encoding. I see > there are some very small packages for CPLDs, but they don't have much > logic in them. I don't know if I can design such a transceiver in 64 > logic cells. Maybe you could use a microcontroller, like the MC9S08 from Freescale, which I've used in a project: It is inexpensive, has A/D converters integrated, so you don't need to use extra analog pins for the discrete signals, I2C is implemented in hardware on the controller and it is about 1cm^2 wide, so it should fit in a cable (no other external components are required, because it has lots of flash integrated and can generate the system clock internally, if you don't need crystal precision). Then the four pins of the cable would be: Vdd, Vcc, I2C data, I2C clock. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Jonathan Bromley on 12 Aug 2006 09:15
On 12 Aug 2006 04:12:43 -0700, rickman <spamgoeshere4(a)yahoo.com> wrote: >Actually, that is not correct. Here are two sequences sampled at 1 >MHz. Please tell me the clock rates. > >0101010101010101 >0011001100110011 I can't because (a) I don't know whether the data stream is too fast for me to measure with 1MHz, and (b) assuming there is no aliasing going on, both streams have no data transitions in them. I carefully pointed out in my post the need for (a) sufficiently fast sampling, and (b) a variety of bits in the data stream. >But I acknowledged that you could "measure" the data rate as long as >the bit stream allows for that. And surely, if I can measure it, I can then demodulate it? [...] >Pulse position and pulse with modulation still require a time >measurement which requires me to have a time reference on the receiver. I don't really know what you mean by "a time reference". My point about measurement is that you can demodulate ANY data rate up to some upper limit determined by the time resolution of your receiver, however that may be determined. (There was an interesting discussion about the relationship between that limit and the resolution - is the maximum data rate 1/3 or 1/4 of your clock rate??? - but that doesn't affect my argument.) You don't need any prior knowledge of the data rate whatsoever, except to be sure that it's slower than your upper limit. >If I am going to require a time reference at the receiver the simplest >scheme I know of is just async serial data with a start and a stop bit. > No point in using Manchester encoding if I am transferring the data >over a wire just a few inches long. Do I infer that you're looking for a scheme in which the clock can be extracted with NO timing components at all in the receiver, i.e. by combinational decoding of the data line? If so, I'm pretty sure it can't be done with any 2-level line discipline; but as soon as you permit 3-level signalling, I think it's possible. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley(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. |