[Indigo]<Dragon>Documentation>VME>VMEDiscussion.tioga!3

VMEDiscussion.tioga

Created by: Ken Pier, January 10, 1985

Edited by: Ken Pier, January 21, 1985 3:53:06 pm PST

Edited by: Neil Gunther January 22, 1985 10:49:08 am PST

Last Edited by: Neil Gunther February 1, 1985 5:56:55 pm PST

DRAGON VME SUBSYSTEM DISCUSSION

DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY

VME Subsystem Discussion

Preliminary notes

Release as [Indigo]<Dragon>Documentation>VME>VMEDiscussion.tioga

Abstract: These are notes regarding the strategy for purchasing and bringing up both the Dragon/VME system and a useful development environment for it. At this time, there appear to be several partial solutions to this problem, either commercially available or available within Xerox. There is no single complete system that we know of today. We invite interested parties to comment or add other pertinent information.

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

For Internal Xerox Use Only

Introduction

The Dragon requires an autonomous computer system coupled to a Dragon cluster. This system is to be used for three major functions: to cold start the Dragon cluster, to perform low speed IO for the cluster (primarily disk and Ethernet), and to act as a service processor to command and control the Dragon for debugging and maintenance. It is our intention to build this system around a MC68020 computer interfaced via a VMEBus to memory, local area network controller, disk controllers, and the like. Components for this system are available commercially. There will be a coupler which will allow data to pass between the VMEBus and the Dragon MBus. This coupling is to be implemented using a Dragon cache chip and some other logic.

Before we can get a VMEBus system to control Dragon, we have to be able to control it and develop software for it. It is our current intention to put relatively little in the 68020, at least at first, and to write just enough resident software to allow the 68020 to exchange data with a host over the Ethernet. We would then acquire (write?) a development system to work remotely between the host and 68020, leaving most of the intelligence for service functions in the host development system.

Note: We understand that Ed McCreight has signed a non-disclosure agreement with Motorola regarding the 68020 processor and possibly other Motorola products. This fact may provide us with leverage with respect to issues involving various internals of the 68020 &/or VME subsystem modules.

It would be a large effort to write a development environment from scratch. We are looking at a number of alternatives which are available in the short term for dealing with this problem. We attempt to describe and evaluate the alternatives, and look for a path to follow. One reason for writing this document is to find out if there are other alternatives we do not yet know about.

An ideal model

An ideal system would allow us to do all the development and debugging using a Dorado running Cedar. Desirable modules may include a cross-compiler, a cross-assembler, a debugging facility modeled on the existing teledebugger with symbolic interface for breakpoints and manipulating state variables. In short, we could use all the facilities that the Cedar environment provides for programming in Cedar. This is impractical in the short run but possible in the long run if sufficient programmer power becomes available. The VME system would have to be "healthy" enough to support a nucleus or kernel which would use the Ethernet to respond to teledebug commands, read and set state in both the VME and Dragon subsystems, and include IO modules to service the Dragon cluster directly. Eventually, the VME kernel would be able to cold start a Dragon without the aid of a Dorado.

What we are going to do first

We are ordering from Motorola a VME chassis and VME modules including RAM, ROM, 68010 processor with RS232 communications interface, local area network board which implements Xerox XNS protocols, system controller and power supplies. The ROMs will contain a small debugging kernel written by Motorola, called MVME115BUG, and should allow us to get on the air once the modules have arrived and without having to mess with Ethernet. Once we are up and running, we will figure out how to get simple Ethernet traffic between the VME system and a Dorado, perhaps by using a protocol similar to the "breath of life" for booting Altos and by writing a small hand-coded booting kernel to run in the service processor. After that, the questions of a development environment and kernel become immediate.

Existing pieces of the pie

1. Smalltalk ST68K development system

Peter Deutsch has a working environment used to create the Smalltalk system for the Sun Microsystems terminal. The environment is written in Smalltalk, and includes a macro-assembler, a debugger, a 68000 simulator, and a facility for linking to the Sun 68000 via Ethernet, using the Xerox internal EFTP protocol. Peter has expressed interest in making the system available to other users, and would probably be willing to upgrade the system to 68010 and eventually 68020 capability. Advantages: this system is real and it works, and would be supported (presumably) in house. It is essentially code-compatible with the Sun assembler (as) since they both have the same roots. It could be very useful for a while. It could be run by anyone wanting to do development at any time using the simulator. Uses and encourages cross-laboratory interaction; byte order is compatible with Cedar/Dragon. Disadvantages: we would rely on Peter or some other Smalltalk wizard for support; no HLL compiler; plan to (eventually) rid the Dragon world of research protocols like EFTP and PUP.

2. VAXC based development system

We have access to a VAX running UNIX 4.2 BSD. We have been told that there are "numerous" cross facilities that run under UNIX and can produce 680x0 object code, and perhaps even support symbolic debugging ( at least post mortem debugging). There is a portable C compiler that can be configured to produce 680x0 code. Advantages: HLL languages and assembler would be supported; we have some VAX wizards in CSL willing to help out; there is multi-user access to VAXC; we could implement the linking protocol for VAXC. Disadvantages: it is not a fully integrated environment; users would have to learn UNIX to use the development system; we would have to acquire source code in order to install and maintain the development system; we would rather work directly on our Dorados instead of using them merely as VAXC terminals; as load increases it will be increasingly painful to use VAXC; protocol compatibility (TCP/IP/PupFTP vs. NS); VAX byte order is different than Cedar/Dragon byte order.

3. Sun based development system

Since UNIX also runs on Sun terminals, a similar system to the VAXC based one could be developed on a Sun. Since the Sun 2 is also 68010 based, we may be able to directly compile HLLs and assemble for the 68010 without crossing. We should find out if Sun has plans to go to 68020 systems within a year or so. Advantages: integrated system for early development; compilers, assemblers and debuggers may be useful without too much modification; other UNIX based tools could be acquired and used; byte order is compatible with Cedar/Dragon. Disadvantages: have to buy one or more Sun terminals; Sun software not supported in house; users would have to learn UNIX to use the development system; we would have to acquire source code in order to install and maintain the development system; we would rather work directly on our Dorados; protocol compatibility (TCP/IP only ??). We are uncertain about the level of support currently offered by Sun.

Note: For Dorados & 68000's, data organization in memory is (16-bit)word-oriented with the same byte-ordering. Similarly for Dragons & 68020's data organization in memory is (32-bit)word- /longword- oriented. In addition to the higher clock speed of the 68020(cf 68000), word orientation represents another important reason to go to the 68020 as the service processor for the Dragon. Moreover, data organization in the 68000 & 68020 is compatible with PrincOps and DragOps respectively.

4. Proposed Cedar based development system

We have a facility for translating Pascal programs into Cedar. We have acquired a Modula 2 compiler targeted at the 68000 and written in Pascal. We translate the compiler, fix it up, run it in the Cedar environment, and use the compiler for all programming of the service processor. If we can find other Pascal based or Modula based useful systems, we can translate or compile them into Cedar as well. Advantages: system is Cedar based, supported in CSL, and allows HLL programming for the service processor; all other development tools written in Cedar; CSL could use a retargetable development system for microprocessor systems. Disadvantages: no assembler (if we need one); we will have to develop our own loader and teledebugging facilities similar to Midas or Burdock; uses very little leverage from existing outside sources; protocol development needed (NS in Cedar or Lupine on the 68020 ??).

5. Motorola VME/10 development system

Motorola has ported AT&T Unix System V to a development station of their own called VME/10. This is a turnkey system for developing 680x0 code. We don't know anything about how it works or how good it is. We mention it here for completeness. Advantages: already targeted to VME based 680x0 systems; no byte order issues. Disadvantages: yet another system to be bought and learned.

Pieces of the pieces

It seems like, foregoing a little integrated systems advantage, we could use pieces of all these proposals to cover all the areas. It would be possible to do assembly and debugging using the Smalltalk system, translate HLL to assembly code on the VAX or Dorado (and pass it on to the Smalltalk system via file servers), and get useful tools from software vendors or universities to run on the VAX or Sun for debugging and development. This isn't clean, but may be practical.

Conclusion

The purpose of this memo is to distribute thinking thus far on this topic. If there are any showstoppers or things we have overlooked, please point them out. We have discovered that this is not as simple as it might first appear. Watch the Dragon/VME whiteboard for further developments.

Appendix A: More on Suns

The following information is largely derived from discussions with Glenn Krasner(SCL) and Tom Merrow(SCLN). SCL has considerable experience dealing with Sun Microsystems. Keeping in mind the objective of having integrated development tools, the following is a brief review of Sun's current systems and how they might factor into the VME development work. There are currently three flavors of Sun machine available.

Sun 2/50

Diskless work-station, 68010, MMU, 1Mb mem, b/w-display, Unix 4.2 bsd (~$10K).

Disk server with Sun ethernet connection can support several work-stations (~$5K/station).

Sun appearently does not point out that the Unix board may be purchased alone and is VME plug compatable in some sense).

Sun 2/120

As above but, in addition has a local disk and Multibus backplane (~$25-30K)

Sun 2/160

Color display with VME backplane (.~$30-40K).
Expect upgrade to the 020 later this year.
8 - 12 VME slots available.

SCL expects to make several purchases of Sun 2/50's (at 10-15% discount) throughout 1985 for their research effort to run Smalltalk on Unix. Like us, they will have to confront the issue of supporting NS protocols if they want to be product compatible with Xerox. They are operating under the assumption that writing the appropriate Unix drivers will not prove too formidable. They confirm that the resident Unix development system is well integrated(by commercial standards at least) and would offer a reasonable initial approach to do serious mc680x0 development work for the VME subsystem. A novel, and perhaps cheaper, variant might be to purchase the Sun 2/50 Unix board alone, slot it into our VME card-cage(if that is possible) thereby creating our own Unix-based multi-user development system. This configuration could always be modified at some later stage if desired. One of the first obligations then would be to bring up a mass storage subsystem. This approach, however, looks like a retrograde step because it involves development of the development system! Alternatively, we could make a joint discounted purchase of say 2 workstations and a disk-server with SCL. This would provide the added margin of having some common hardware and common goals with SCL. Besides cost, the most significant drawback with the joint purchase aspect is that SCL will not submit their next purchase order until some time in April. With lead time included it may be preferable to purchase separately foregoing the discount. With regard to customer support there seems to be general agreement that Sun could do better(and may be trying) but if you do things pertaining to Unix it helps to keep their attention.