Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.sys.m68k
Subject: Re: CAS/CAS2 mapping to VME RMW
Message-ID: <2054@hoptoad.uucp>
Date: Sat, 25-Apr-87 22:32:56 EDT
Article-I.D.: hoptoad.2054
Posted: Sat Apr 25 22:32:56 1987
Date-Received: Sun, 26-Apr-87 22:34:37 EDT
References: <344@pecnos.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 22

Randy Banton asks a good question with regard to 68020's running
multiprocessor stuff on the VMEbus.  The VMEbus only supports the
68000 style of bus locking (keep address strobe active while jiggling
the data strobes), but this only allows an atomic read and write of a single
address.  The 68020 allows bus locks on unaligned addresses and also provides
an 8-byte read-compare-and-swap operation.

Sun faced this when designing their 68020 based VMEbus systems.  As I
recall, the answer was the same as proposed by Randy -- the board inhibits
arbitration of the VMEbus while the 68020 RMC (bus lock) signal is active,
preventing any other VMEbus master from interspersing cycles.
This is NOT sufficient to lock accesses in a dual ported memory (e.g.
the on-board memory of a Sun-3, which can be accessed by the CPU directly,
or via the VMEbus).  We decided that if you wanted multiple CPUs to talk
to the same memory, it had better be a global VMEbus memory board that none
of the CPUs had preferential (dual port) access to.  This sidesteps the 
problem at the expense of a small memory board in multi-CPU systems.
(This is from memory; your mileage or Sun CPU boards may vary.)
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu