[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

XL400 Multiprocessing?



Norm:

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.

Rich Krueger
XL400 Product Marketing Manager

	----------------------------------------

	Date: Mon, 22 May 89 19:47 EDT
	From: Norman Haas <NHAAS@ibm.com>
	To: slug@Warbucks.AI.SRI.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.

	Norm