[mod.vlsi] Magic on a Sun3

mayo@RENOIR.BERKELEY.EDU (Bob N. Mayo @ U.C. Berkeley Computer Science) (02/15/86)

Dear Magic users:

Several mods are needed in order to run the 1986 release of Magic on
a Sun3 workstation.  I'm sending these out over 'info-vlsi' in hopes
that it will help other people get Magic running on their machines.

The mods are:

	1) In the graphics directory, add the following line to the files 
	   grMain.c, grSun1.c, grSun4.c, grSun5.c, grSunW1.c, grSunW2.c,
	   grSunW3.c, grSunW4.c and grSunW5.c.  The line should go after
	   the section which includes Sun's header files, and before the
	   include of "magic.h".

		#define Rect MagicRect   /* Avoid Sun's definition of Rect. */

	   This change overrides Sun's definition of "Rect", which is new with
	   the Sun3 release of the software.

	2) Do the same change to the file windSun.c in the windows directory.

	3) In the file grSunW1.c, comment out the body of the routine
	   "GrSunFigureLocation" and replace it with:

		rect->r_xbot = 150;
		rect->r_xtop = 1150;
		rect->r_ybot = 224;
		rect->r_ytop = 899;

	   This bypasses a problem with calling Sun's wmgr_figuretoolrect().

	4) If you are using an attached graphics terminal over the RS232
	   port, you need to enable Magic's special "flsbuf" procedure.
	   To do this, change "#ifdef" lines in the file "utils/flsbuf.c" so 
	   that Magic's "flsbuf" procedure will be used on the sun.

	5) Recompile the files that were changed and relink magic.

We haven't actually tried these changes out here at Berkeley.  The changes 
were provided to us by Walter Scott of LLNL and Paul Basset of BBN.  Thanks.

--Bob Mayo

info-vlsi@ucbvax.UUCP (02/20/86)

This message is empty.

elh@VU-VLSI.UUCP (Edward L. Hepler) (03/04/86)

Subject: Experiences in porting 1986 VLSI Dist. to Pyramid 90X

John Ousterhout, et. al.:

Thank you for the 1986 distribution of Berkeley's VLSI tools.

We currently are running them on a Pyramid 90X in the EE Dept at Villanova
University.  I thought the feedback concerning the problems I ran into in
installing the tools on our machine might be helpful to you or others who
will be doing the same on a Pyramid:

esim:	1.  Had to modify Makefile to rm gentable after it was used.
	2.  Had to modify gentable.c around line 108 to have fopen
		open the file with "w+" instead of just "w".
	3.  Had to modify gentable.c to exit with exit(0) around line
		124 to satisfy the Makefile.
	4.  Had to modify nsim.c to provide 4 byte alignment during memory
		allocation around line 148 - changed to:
		    n = (n+3) & ~3;
	5.  Had to modify the line:
		for(i=0;i<HASHSIZE;i++)uhash[i] = (uptr)hash[i] = 0;
	    to:
		for(i=0;i<HASHSIZE;i++)
			{
			uhash[i] = 0;
			hash[i] = 0;
			}
	    to satisfy the Pyramid compiler.

magic:	1.  calma/calmaInt.h:  Added "null definitions (#define ntohs(x) (x))
			for ntohs ntohl htons htonl since Pyramid doesn't
			distribute network header files unless you have 
			purchased the networking hardware (which we have
			not done (yet)).
	2.  tech/scmos.tech:
		a.  line 1575 changed ppn to ppd
		b.  line 1588 changed nnp to nnd
		c.  line 1643 changed nwell, pwell to nwell,pwell
		d.  commented out line 1676 since I couldn't determine
			what was wrong with it.
		   Reads: sideoverlap allMetal2 space allMetal1 70

		All the above caused fatal errors to occur in magic (except
		d).  These proved very difficult to find since the error
		message printed was corrupted, and magic attempts to 
		continue.  The "bad" data eventually causes a segmentation
		violation, etc.

		The error message corruption (actually the message was
		eaten) is due to the fact that _doprnt must work differently
		on the Pyramid (we are checking into this now).  I suspect
		it has to do with varargs and the register window method
		of passing parameters.

		If the above changes (ppn to ppd, and nnp to nnd) are 
		incorrect, I would appreciate being notified.  Also
		could you let me know about line 1676.

	3.  utils/malloc.c  Had to put #ifdef MALLOCTRACE around
		mallocTraceWrite.

	4.  I have added a plot interface to our QMS (actually Talaris)
		laser printer. (It's almost complete.) I'd be happy to
		talk to others about it.

	5.  We run magic using AED 767s, Summagraphic bitpads, and VT 240s.
		We have a problem in that when we run sleeper, then magic,
		we can't seem to get out of sleeper when we are done. The
		only solution so far has been to su and kill the process.
		Previously, we were able to get out of sleeper after running
		caesar by power cycling the AED terminal.  None of the
		^C, etc. seem to work.  Any thoughts?

	6.  We don't have gremlin, so online documentation has to have
		pictures "pasted" in.  Can you send gremlin (does it
		"translate" to Talaris (QMS)?) or a good definition of
		gremlin format so we can write a filter?

	7.  The grid command seems to have non-predictable behaviour.

Thanks much.  Please keep us informed (via Usenet?) on changes/updates/etc.

Do you have a list of organizations who are currently working on CAD tools,
simulators, etc. which interact with magic?  I am very interested in doing
some silicon compiler work.

Dr. Ed Hepler
Adjunct Professor, Villanova Univ., Villanova, Pa.

Work phone (Full time job) (215) 354-1775
{pyrnj,psuvax1}!vu-vlsi!elh