Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!linus!decvax!decwrl!sun!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.micro.68k,net.arch
Subject: Re: Multiple 68020's on VME not a problem.
Message-ID: <181@l5.uucp>
Date: Mon, 7-Oct-85 13:21:42 EDT
Article-I.D.: l5.181
Posted: Mon Oct  7 13:21:42 1985
Date-Received: Wed, 9-Oct-85 03:57:57 EDT
References: <442@rna.UUCP>, <552@spar.UUCP> <211@fas.ri.cmu.edu.ARPA>
Organization: Ell-Five [Consultants], San Francisco
Lines: 24
Xref: linus net.micro.68k:1153 net.arch:1668
Summary: problem is not with the bus or chip, but with lousy board design.

When I was at Sun, I and several hardware designers looked at some
VMEbus cards that had very poorly designed bus request circuits.  Their
designers had apparently not heard of metastability.  There is no
problem with the bus specs, just with brain-damaged implementations.
It's a shame that some of Motorola's boards are broken this way, since
it makes "their bus" look bad.

All Sun VMEbus cards have good arbiters, with metastability calculated
to be a problem once in a zillion years or so (based on the mfr's specs
on the flipflops that capture and synchronize the signals coming in from
the bus).  That gets looked at very closely in design reviews.

Mitch Bradley [designer of Sun's Ethernet and SCSI boards] comments:
> Apparently synchronization is poorly understood in the world at large.
> I had not even heard of it in school.  Andy [Bechtolsheim] taught it to me.
> I have seen lots of boards with synchronization problems - the Archive
> formatter, the Xylogics 450 (now fixed), ...

I might also mention the AMD 9513 counter/timer chip, which they fixed
by producing a 9513A and a new manual with a long chapter on metastability.

I can explain metastability and synchronization if people are interested
in a more technical discussion, say in net.arch.  [net.chips would be
better if we had it...it's probably not of interest to net.analog.]