Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!zephyr.ens.tek.com!orca.wv.tek.com!leia!opus!johnt
From: johnt@opus.WV.TEK.COM (John Theus)
Newsgroups: comp.arch
Subject: Re: Futurebus+ @ 500MBytes/sec
Keywords: Futurebus+
Message-ID: <286@leia.WV.TEK.COM>
Date: 15 Jan 90 20:09:07 GMT
References: <7863@dime.cs.umass.edu> <280@leia.WV.TEK.COM> <136.filbo@gorn.santa-cruz.ca.us> <285@leia.WV.TEK.COM> <6149@internal.Apple.COM>
Sender: johnt@leia.WV.TEK.COM
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 48

In article <6149@internal.Apple.COM> pauls@apple.com (Paul Sweazey) writes:
>FUTUREBUS EMBEDDED CLOCK: THE REAL SCOOP FROM A FALLEN ANGEL
>
>We each have different views of history, and I have tried to stay out of 
>these discussions, but the Futurebus discussion has led to issues that I 
>used to live and breathe for a living.
>
> [...]
>RV Balakrishnan suggested embedded-clock synchronization as the ultimate 
>solution to skew in February 1988.
>
>I devised and proposed embedded-clock synchronization to the SuperBus Study
>Group (now SCI) in March 1988, privately to Futurebus Committee members in
>May 1988, and at various times in Futurebus public forums through December
>1988.
>
>Emil Hahn devised a feasible implementation of embedded-clock 
>syncrhonization between November 1988 and January 1989.
>
> [...]
>
This article along with a follow-up phone call to Paul cleared up some
confusion I've had about who did what and when.  Unfortunately, a lot of
the events that Paul related were never published in the Futurebus
minutes.

Part of my confusion comes from the term "embedded-clock" and I want to
make sure this doesn't mislead anyone else.  The Futurebus+ packet mode
protocol does not actually use an embedded-clock protocol.  At one time Paul
said he called it "implied embedded-clock", which I think would have been more
accurate.  Paul is very good at inventing names and techniques to describe
new concepts.  Another name he had for this protocol that caught my ear
was "packet beaming".

Typically, an embedded-clock protocol had the originating clock encoded
into the data stream.  A receiver is then capable of extracting the
clock from data following transmission.  Good examples are the encoding
schemes used for disk drives such as MFM.

The Futurebus+ packet protocol does not encode the clock into the data
stream, but instead uses a starting sync bit to synchronize the receiver
with the sender.  Both the sender and receiver have previously agreed upon
the transmission frequency.

John Theus                                johnt@opus.wv.tek.com
Futurebus+ Parallel Protocol Coordinator
Tektronix, Inc.
Interactive Technologies Div. - shipping the Futurebus-based XD88 workstations