[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The following is in response to your questions concerning extended applications
of the XL400's VMEbus.
The XL400 main board requires a PAL change to change its address, so use
of the VMEbus for anything other than power requires a "work-around" solution
to permit more than one CPU to be installed. We agree that a multi-CPU XL400
might be an attractive option for a future product, and we are looking into
this and other options along this direction.
The XL400 requires two PAL changes to relocate the address of the slave
buffer and mailbox. With this PAL change, it is possible to have multiple
XL400 boardsets installed in the system. The XL400 was designed in accordance
with the VMEbus spec revision C.1 (IEEE P1014/D1.2). The interface has been
tested in our lab with 3rd party vendor products and VMEbus anomaly testers.
We believe we are in conformance with the VMEbus specification.
With regard to multiple boardsets in one XL400, our current manufacturing
process utilizes this configuration for exercising the VMEbus interface logic.
The XL400 backplane does not prewire any of the ununsed VMEbus bus lines on the
J2/J3 connectors. The A and C rows of J2 are unused, and the B row is dedicated
to the A32/D32 VME signals. The A and C rows of J3 are dedicated to power
connections (as defined by SUN), and the B row is unused. This allows the
customer to utilize these pins according to their application (i.e. 3rd party
"baby-backplanes" can be used to turn the unused pins into a VSBbus; 3rd party
board options can utilize the pins for a "clean" mechanical interface to the
outside world). The bus lines on the J2/J3 connectors are not being used in
such a way that would allow only one boardset in an XL400.
Should you have specific questions or concerns on the XL400's VMEbus interface,
please feel free to contact me or your local sales office, and we'll be happy to
put you in touch with a Symbolics technical representative.
XL400 Product Marketing Manager
Date: Mon, 22 May 89 19:47 EDT
From: Norman Haas <NHAAS@ibm.com>
Subject: XL400 multiprocessing?
At my site, we have an XL400, and we thought a nice cheap way to get
a second one would be to simply buy another board set and plug it into the
unused slots in our first one's chassis. However, Symbolics says that
we can't do this; it will lead to clashing between the machines- either
immediately or in the near future when the color systems come out.
Why should this be? The VMEBus architecture is specifically intended to
support multiple processors running simultaneously in the same chassis.
If Symbolics is conforming to the bus spec, then an XL400 board set added
into an existing VMEBus configuration will not interfere with the operation
of the other boards in that configuration (other than consuming some
bus bandwidth), provided that it doesn't step on the other boards'
addresses or interrupts, which is usually possible to achieve with VMEBus
products by means of on-board jumper blocks. And in that case, the
other boards could comprise one or more other Symbolicses. (VMEBus
permits up to 20 slots per chassis; you could make a Symbolics six-pack!)
And inter-board conflict should be particularly low for the Lisp-hacker,
since the XL400 makes no use of the VMEBus unless an application program
specifically requests it to (the board set having its own private bus
on the front edge, and disk I/O is through the Ethernet).
Is the problem that bus lines on the J2/J3 connectors are being used in
such a way that there can be only one Symbolics present? Is there actually
clashing if one doesn't have color hardware? (We don't need color.)
Whatever the reason, it's unfortunate, because this would certainly be
a nice way to configure a cost-effective, space-efficient multi-machine
system, and it would have the advantage that if several machines wanted to
collaborate on a task, a really fast, no-Ethernet communication channel
between them would come for free.