davidb@inmos.COM (David Boreham) (03/21/91)
Newsgroups: inmos.lists.transputer Subject: Tp links synchronous/asynchronous ? Message-ID: <14980@ganymede.inmos.co.uk> Date: 21 Mar 91 04:50:56 GMT Sender: uucp@inmos.co.uk Lines: 37 Andrew M Gillespie <Agillesp@Daisy.EE.UND.AC.ZA> writes: >I have been wondering whether the transputer serial-link communication is >synchronous or asynchronous, and what mechanism is then used to receive >data. The "TRANSPUTER DATABOOK 2nd ed 1989" states that "Data reception is >asynchronous, allowing communication to be independent of clock phase". No error in the book, links are *ASYNCRONOUS*. >Asynchronous systems function by scanning the incoming data line at up >to 64 * transmission clock rate (presumably 20 MHz for a 20 MBit/s link) to >determine the start of the data frame. It seems somewhat unlikely that this is >indeed the case as this would involve excessively high frequencies inside >the transputer (i.e. 320 MHz for 16* clock). Unlikley or not, the devices oversample at 5X the bit period. For 20Mbits links that is every 10ns. For the curious, this requires a 50MHz clock. >It seems obvious that if clocks conforming to a specified accuracy are >used in both transmitting and receiving transputers, and messages are kept >short (2 start + 8 data + 1 stop bits in this case), the small differences The stop bit doesn't matter. It's there to give a gap before the next start bit, otherwise you wouldn't always be able to see it. >in frequency will have negligible effect on the communication. >To compensate for phase differences between the Tx and Rx clocks, the receiver >has to detect the start of the transmission (synchronise with the Tx clock), >usually this is done as stated above, using a clock divided down from the >64* clock to receive the data. The uncertainty in this case is presumably >(1/64 * transmission clock period). Situation is as follows: Async serial lines (like V24 and so on) work by sending a bit to indicate a data packet is being sent. This is called the ``start bit''. the rest of the data will be sent as NRZ bits following the start bit. The receiver needs to sample the data bits at the correct time. It does this by using a clock running at the same frequency as the sender (to give the bit period) , and by starting sampling at some fixed time after the detection of the start bit (to get the position within the bits correct). The position within the nominal bit positions at which you sample depends upon what kind of line distortion you expect. We go for the middle of the bit. In the case of the transputer link, the data stream is sampled at 10ns to detect a start bit. The logic then proceeds to clock in eight data bits, starting from seven sample ticks after it saw the start bit. Of course, oversampling of the data stream is just one possible way to lock onto a start bit---it happens to be the way that UARTS and transputer links do it. Whether the oversampling is at 16X, 64X or 5X has nothing to do with the basic mechanism. In fact you can use 2X sampling with some success. The oversampling factor affects the accuracy with which you can place your sampling points. The objective is to receive every bit in a packet correctly. In order to achieve this, you need a sending clock which is close enough to the sending clock such that the eighth bit in a packet is still sampled correctly. You need a method of determining the start bit position which is accurate enough so that it works with the clock frequency difference present. In links, the clocks are PLL generated and the calculations to determine how much the sending and receiving clocks may differ at any one time is exteremely complex and well beyond my full understanding. >Does anyone out there know exactly how the transputer-link mechanism works, >and could describe both the mechanism and a circuit to implement such a >mechanism ? Not sure about ``exactly'' :) If you're doing a custom silicon implementation, you need a syncroniser cell. Same goes for gate arrays, except nobody seems to offer syncronisers in their cell libraries. In that case, you would need to characterise the metastability performance of the available cells. Various PAL and LCA implementations have been proposed and built. For an LCA version you would probably need to reduce the oversampling to 3X. Another interesting device is the Cypress CY7C361, which clocks at 125MHz and has syncronisers built into the inputs. David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos.com!davidb +44 454 616616 ex 547 | Internet: davidb@inmos.com