Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!ames!sgi!rpw3@rigden.wpd.sgi.com
From: rpw3@rigden.wpd.sgi.com (Robert P. Warnock)
Newsgroups: comp.arch
Subject: Re: Futurebus+ @ 500MBytes/sec
Keywords: Futurebus+
Message-ID: <48327@sgi.sgi.com>
Date: 16 Jan 90 08:40:42 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> <286@leia.WV.TEK.COM>
Sender: rpw3@rigden.wpd.sgi.com
Reply-To: rpw3@rigden.UUCP (Robert P. Warnock)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 31

In article <286@leia.WV.TEK.COM> johnt@opus.WV.TEK.COM (John Theus) writes:
+---------------
| 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...
| 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.
+---------------

Then shouldn't this be called "embedded phase"???   ;-}  ;-}

For those with a bit of deja vu about now: Yes, RS-232 async works this
way, only slower...

-Rob

p.s. Or for another way to look at it, think of each bus line as having
a >60 megabaud "UART" on it, with *big* "bytes". Note that the .01% clock
spec means that practically you're limited to about 2000 bits per start bit
(assuming 20% skew is acceptable, which it probably is if you have at least
5 clock phases to choose from -- that gives you a total of 40% skew), or
about 16K bytes per burst on the bus (64-bit-wide bus). That's probably
enough.  ;-}

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311