The tools have been tested with the scripts contained in the testar shell archive file. These scripts are minimal; they test bdsyn, bdnet, misII, octflatten, padplace, wolfe, and mosaico. The results can be viewed with vem and simulated with musa. To unfold the archive, type "sh testar"; this will create a directory called time. RANDOM OBSCURITIES Ignore checksum complaints while running the PREINSTALL script. HP-UX: The Unix utilities df and touch may appear to behave strangely. This is because the Octtools makefiles use them, and expect the BSD versions of these utilities. For the HP-UX release, BSD versions are installed in $OCTTOOLS/bin. If $OCTTOOLS/bin is in your path you'll get these Octtools BSD versions, not the HP-UX ones. HP-UX: The makefile for misII does not correctly set the protection on the binary $OCTTOOLS/bin/misII, which should be executable. HP-UX: The tools musa and octopus do not load -- /bin/ld fails. This appears to be a problem with the loader. The C compilers for various architectures give various harmless warning messages. On sun4's: in utility cc ... texpand.c "texpand.c", line 117: warning: illegal combination of pointer and integer, op = in ace cc .. genMove.c "genMove.c", line 215: warning: statement not reached ... along with various ranlib warnings (no symbol table) On hpux's: in yal2oct cc ... -c getmodule.c cc: "getmodule.c", line 692: warning 537: Return expression incompatible with function type. in puppy cc ... analogOctIO.c cc: "analogOctIO.c", line 431: warning 546: Enumeration type clash. cc: "analogOctIO.c", line 456: warning 546: Enumeration type clash. in spider cc ... -c main.c cc: "main.c", line 11: warning 525: Redeclaration of identifier "no_compact". cc: "main.c", line 12: warning 525: Redeclaration of identifier "circuitName". cc: "main.c", line 13: warning 525: Redeclaration of identifier "channelIdname". cc: "main.c", line 14: warning 525: Redeclaration of identifier "routerName". cc: "main.c", line 15: warning 525: Redeclaration of identifier "routerfile". cc: "main.c", line 16: warning 525: Redeclaration of identifier "router_type". cc: "main.c", line 17: warning 525: Redeclaration of identifier "oCellFacet". in misII, Making pld ... cc ... act_init.c cc: "act_init.c", warning 475: Variable "arg" declared on line 87 is not initialized before being used. cc ... act_map.c cc: "act_map.c", warning 475: Variable "arg" declared on line 2318 is not initialized before being used. cc ... xln_k_decomp.c cc: "xln_k_decomp.c", warning 475: Variable "arg" declared on line 795 is not initialized before being used. On mipses: in oct cc ... fsys.c cpp: warning /usr/include/sys/param.h:389: MIN redefined cpp: warning /usr/include/sys/param.h:390: MAX redefined in fb cc ... fb.c cpp: warning /vol/cad/cad1/octtools/mips/include/Maxport.h:46: XtNmaxHeight redefined cpp: warning /vol/cad/cad1/octtools/mips/include/Maxport.h:47: XtNmaxWidth redefined in misII, Making map ... cc ... fanout_opt.c uopt: Warning: fanout_opt_get_fanout_alg: this procedure not optimized because it exceeds size threshold... cc ... prim.c ccom: Warning: prim.c, line 155: statement not reached ... along with various ar warnings (creating ...) INSTALLING THE TOOLS ON THE IBM RS/6000 The IBM RS/6000 is not supported, but some users have installed the Octtools successfully... You must use xlc to compile the Octtools, configured to resemble a bsd unix compiler. The tool attache will not link as is. Remove the reference to termlib.a in the attache Makefile. Note that #ifdef unix preprocessor commands do not interpret AIX to be a 'unix'. Therefore, add -Dunix to the options line for the bsdcc configuration in the /etc/xlc.cfg file. This will take of the various places where #ifdef unix is present (Packages/utility, Packages/port, Synthesis/bdsyn and port.h). COMMON INSTALLATION AND INITIAL USAGE PROBLEMS vem dies immediately with the message: XIO Error: Broken Pipe You must xhost the machine running vem on the machine you are using for display, to wit: % xhost + vem dies immediately with the message: Can't open display NAME Either your DISPLAY environment variable is incorrect (it is the wrong name or has not been set) or you have specified a bad display name on the vem command line. Set the environment variable correctly: % printenv DISPLAY dent:0 <-- wrong display name % setenv DISPLAY shambhala:0 % vem vem (or the X server) dies randomly under OPEN LOOK version 3: Complain to Sun or use version 2. vem beeps whenever certain commands (but not all commands) are tried. Make sure that you are in the correct window for that command. Some commands in vem are window-specific, for example, save-all only works in the console window and create-geometry only works in physical editing windows. An rpc application is invoked from vem, but does not start. First, check to see if the message "NAME: Command not found" appears in the window that you started vem from. This means that the location specified for the rpc application (either at invocation time via rpc-any or in the vem.bindings file) is incorrect. Second, check to see if the message "Permission Denied" appears in the window that you started vem from. rpc uses the UNIX rsh mechanism for spawning off remote commands and rsh requires a file called .rhosts with a list of the machines (and optionally the users) that can remotely execute commands (and remotely login) to your account. This file is in your home directory. For example, if you are running vem on a machine called "shambhala" and want to spawn off a remote application to a machine called "dent", you would need a .rhosts file in your home directory on "shambhala" containing the line dent. Finally, if after a minute or two, you get the error message: bad inet connect your rpc application and vem have been built with different versions of the operating system. This has been seen between ULTRIX 2.2 and ULTRIX 3.0, and between SUN OS 3.2 and SUN OS 4.0. SOME KNOWN BUGS (this list is by no means inclusive) anchor and octpla: do not work reliably. bdnet: {\tt TECHNOLOGY}, {\tt EDITSTYLE}, and {\tt VIEWTYPE} are keywords and thus must be quoted if used for property names. does not handle joined bags properly. gem: does not place well contacts and the layout is too sparse. mag2oct: does not correctly handle point or line terminals. misII: read\_oct throws away mapping information. write\_oct does not handle joined bags properly. mizer: does not understand `-o :view' only `-o cell:view'. musa: runs into problems if you have a circuit in which two nets are electrically connected at lower levels of the hierarchy (it quits gracefully with an explanation). mustang: too many encodings will cause a core dump. oct: you get a seg fault if you try to reopen an interface facet that does not exist. octpla: It has been seen enter infinite loops. octmm: does not understand `-o cell:view' only `-o :view'. oct2ps: does not handle {\em pac man} shapes. puppy: does not understand `-o :view' only `-o cell:view'. vem: Items can be entered via vem that sparcs will complain about. Solution: run symhelp occasionally. vem will not correctly reset after an rpc application dies and the user must issue the rpc-reset command before running another rpc application. vov: the defaults for dialog display are not right, because they cause dialogs with illegal size (zero or negative). This means that dialogs may not pop-up. The fix is to use, for example, the defaults shown at the end of the VOV tutorial. AN OBSCURE BUG There is one bug related to the external id's of terminals in different facets of the same view. The current OCT does not guarantee that these XID's are consistent across all facets of the same view, and some tools get confused, in particular those using oh, symbolic, or symlib. The bug manifests itself when the tool exits with a strange error like: Nothing more to generate with no other explanation. The bug occurs if you modify the master of an instance after instantiation. Solution: yous should first try inconsistent and symhelp, because the problem might not be that serious: % inconsistent cell:view or % symhelp -d cell:view The first command gives you a list of instances without a master. These inconsistencies occur if you delete or move a master after instantiation. The inconsistency can generally be resolved with octmvlib. If even symhelp does not help, you should refresh all instances in the cell:view that is having problems. You can do this with octmvlib: % octmvlib -rc cell:view This is always a safe thing to do. Warning: do not interrupt octmvlib, or the facet may become corrupted. In general you should never interrupt a tool while it is writing out a facet. The c option says that you want the contents facet to be instantiated. That is always the safest thing to do. Sometimes you can help vem run faster if you feed it cells that instantiate the interface facet. If that is what you want you can say: % octmvlib -rc cell:view to refresh all instances, followed by % octmvlib -ri cell:view to instantiate the interface facets.