Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!sco!gorn!ucscc!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.arch
Subject: Re: Futurebus+ @ 500MBytes/sec
Message-ID: <136.filbo@gorn.santa-cruz.ca.us>
Date: 8 Jan 90 13:30:47 GMT
References: <7863@dime.cs.umass.edu> <280@leia.WV.TEK.COM>
Organization: R Pentomino
Lines: 40
X-Claimer: I >am< R Pentomino!

In article <280@leia.WV.TEK.COM> John Theus writes:
>The transfer protocol is very similar to the asynchronous protocol used on
>RS-232.  If we just think about an individual bit for now, the sender
>transmits its data at the frequency of an on-board clock.  As with RS-232,
>the frequency must be known by both the transmitter and the receiver in
>advance.  The Futurebus+ protocols provide a mechanism for selecting one
>of two such frequencies on a transaction by transaction basis.
> [...]
>The receiver has its own on-board clock that runs at the same frequency as
>the sender.  Both sender and receiver must have clock frequency tolerances
>of 0.01% or better.  When the receiver sees the sync bit at the start of a
>packet, its logic sets a precision delay equal to the phase difference
>between the sync bit and its on-board clock.  Thereafter, the logic uses
>the on-board clock plus the delay to define the datum cell positions for
>sampling the rest of the data.  The maximum packet length is limited by
>the drift that occurs between the 2 clock sources.

Why isn't one more line used to transmit the sender's idea of the data
clock?

  clock  +++---+++---+++---+++  "111111"
  data0  +++++++++---+++------  "001110"
  data1  +++------+++------+++  "101101"
    :
  dataN  ++++++------------+++  "010001"

The receiver could still choose to ignore the clock line and use the
above method.  It could also use the above method, but dynamically
adjust the delay, tracking the guaranteed transition of the clock line
at the start of each cell.  This would eliminate the requirement for
closely matched clock frequencies and would seem to provide much better
reliability.

I'm not a bus designer; not even a hardware person.  Maybe I'm missing
something really obvious.  If so, how about explaining it instead of
flaming me to toast?  ;-}

Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CI$: 73047,1112 (slow)
     @       * *     //  belal@sco.com  ..ucbvax!ucscc!{gorn!filbo,sco!belal}
R Pentomino    *   \X/  Filbo @ Pyrzqxgl +408-476-4633 and XBBS +408-476-4945