Page Numbers: Yes X: 530 Y: 10.5" First Page: 22
Margins: Top: 1.3" Bottom: 1"
Heading:
Sil, Analyze, Gobble, Build Reference Manual
GOBBLE

Gobble is a program that merges a number of node list files (.NL) created by Analyze to produce a wirelist for a single board. It also does automatic terminator assignment for ECL signals, and routes each net to achieve a minimum wire length. Gobble does not do automatic component placement: this information must be supplied by the designer in the original Sil drawing.

Gobble is invoked by typing:

Gobble/x file01.nl file02.nl file03.nl ...

to the Executive. The switch is a single letter (A to Z) that tells Gobble the
board type to use for the wirelist. Brief descriptions of boards are given below.

Gobble creates several output files, overwriting any previous contents. If file01.nl is the
first filename in the list of .NL files given to Gobble, the wirelist file will be written on file01.WL, the backpanel pin list will be written on file01.BP, and errors will be written on file01.GE.

While it is running, Gobble complements the cursor each time it begins processing a new net. This will start a few tens of seconds after the program is started (after all input files are read), and will continue until all processing is done. A few more seconds will elapse as the output files are written, and Gobble will finish. The amount of time spent processing a net depends on its length, and may be up to a few tens of seconds for nets that include many nodes.

The routing algorithms used by Gobble can be controlled by optional entries in the command line appearing just before the first filename:

number/HSpecifies amount of work the heuristic router will do
(default=20; 100 is "a lot")
number/ESpecifies the size of the net above which the heuristic router is
used and below which the exhaustive router is used (default=7)
name/MSpecifies the metric to use in computing net length
(name="Manhattan" or "Euclidean"; default is Manhattan)

ECL terminator assignment is normally performed on any net that has one or more outputs from ECL-family components, and does not visit any edge or cable pins. In addition, any net with a name that ends in the character ’!’ will not have terminators assigned automatically. These conventions will require you to draw explicit terminators for any net that either (1) visits an edge pin; (2) visits a cable pin; or (3) has a name that ends in !.

Gobble recognizes certain reserved net names, usually used for ground and various sorts of power. The reserved names are listed with the board type, below.

Reworking a board

When a board has already been constructed, and a rather small set of changes is required, Gobble is willing to generate a file of "adds and deletes" that will alter the already-constructed board to agree with the new drawings. For this purpose, invoke Gobble with \ rather than / preceding the board letter. Gobble will read all the .NL files
and the .WL file that corresponds precisely to the present board, and will create two new files: file01.AD, a list of adds and deletes to make to the current board, and file01.wlNew, a revised complete wirelist. This wirelist will represent "truth" only after the add/delete modifications have been accomplished on the board.

The Gobble re-work option requires rather careful attention to data-management to avoid careless errors while modifying a board several times. Although the Build subsystem will help with this chore, it is wise to understand the underlying principles. The most important point is that
it is essential to keep a .WL file that accurately represents the current state of the board, for it is from this file that Gobble determines what must be changed when updates are required. This .WL file cannot, in general, be reconstructed from the Sil drawings that agree with it, because automatic terminator assignment may place terminators differently.

GOBBLE board definitions

Information about geometric and electrical properties of various boards is "assembled into" Gobble, and can currently only be modified by modifying the program. The following list cites boards known to Gobble, and gives a brief description of their properties. All ranges are
inclusive.

B. Augat 8136 stitch-weld board.

C. Board specially designed to fit in Xerox 9200 engine control.

L. D1 main logic board. Board location letters range from a to l (ell); numbers range from 1 to 24 for 16-pin dips, 41 to 52 for SIPS, and 60 to 63 for 24-pin packages. Cable and edge pin numbers range from 1 to 188. There are five reserved net names, corresponding to various power supply voltages: GND (0), VCC (+5), VTT (-2), VEE (-5.2), and VDD (+12).

M. D1 memory storage board.

X. Wild card board -- allows all board positions (a-y, 01-63), and does no routing.

Care

The judicious user of Gobble will always be skeptical, and will examine carefully the output before stitch-welding. Special inspection should be applied to add/delete lists.

Error Messages

...to come...

BUILD

Build is a subsystem that helps with the data-management aspects of building boards and keeping the design-automation data files current. Suppose a board is currently "revision C" (or Rev C), two drawings are updated, and it is now time to undertake to get everything (drawings, wire lists, and board) updated to the new Rev D. Good practice will encourage us to change
all the drawings to show Rev D as the current version; but sheer tedium and errors will soon let chaos creep in. Build should help.

Let us first define a "built drawing" for a certain revision level as the drawing that accurately represents the particular rev level.
Built drawings are distinguished by a series of broad horizontal lines at the very bottom of the page: these lines mean that the drawing, as you see it, was used to build the board whose revision level is cited in the drawing. Sil will remove these markers whenever you change the drawing in any way. Thus the veracity of the "Rev x" label in the drawing is determined by the obvious markers.

Build is invoked with a command line that lists
all the files for a particular board. For example, "Build D/R \GL aabb*.Sil" will build the D revision of the board aabb. Build undertakes several steps:

1. All .Sil files are "edited" by Build, and changes are made in the title area of each drawing. The revision level is updated to xx if the phrase xx/R is present in the command line. The file name cited in the title area is changed to match the true file name. The page number is updated to match the ordinal position of the filename in the list of files provided to Build. And finally, unless the .Sil file was already built (i.e., unmodified since last Build), the date is updated. The file is marked "built," and the special marker lines are added to it. The first file specified always has the date updated. The specification on page numbers assigned may be modified by placing a num/p switch before some page, where num may be 0,1,2 etc or .+2, or .+0 etc..

2. Now Analyze is run on all the files that were not marked "built" at the start of step 1 above. The error messages will, as usual, be collected on one file aabb01.er, where aabb01.Sil was the first name passed to BUILD.

3. Any .PN files produced by Analyze are merged into the corresponding .Sil files unless the Tentative switch has been set. Build will terminate before appending pin numbers if Analyze reported any serious errors.

4. Gobble or Route is invoked on all the .NL files produced by Analyze. The "board letter" switch for Gobble is extracted from the /Gy switch in the command line (or \Gy for rework). Any other items in the command line that are of the form "xxx/Gyy" are passed on to Gobble as "xxx/yy". If you are using BUIILD for re-work, you must of course have aabb01.wl on your disk (this is the current wirelist file, for rev C in our example). In rework mode, you may explicidly give the name of the .wl file to be reworked by placing oldname.wl/CG in the command file.
5. If re-work has been specified and an old .wl file has not been given explicidly, aabb01.wl is copied into aabb01.wlOld (backup); then aabb01.wlNew is copied into aabb01.wl (critical step!!), and finally aabb01.wlNew is deleted. The critical step will be crash-protected with a restart procedure that copies aabb01.wlOld back into aabb01.wl so that no harm is done.
6. This step executes any number of commands according to the contents of a special file called BuildBackupTemplate.cm. If no such file exists, then Build will default to dumping all files it believes are critical to the build run on both IVY and MAXC. Build essentially reads in BuildbackupTemplate.cm expands some special escape sequence as defined below, and passes the results on to the Alto operating system in Rem.cm for further system expansion.
If a "$Z" is found in the template, then the template is expanded as follows:
N:name of the first file given to build with the extension stripped off.
$ZN.ad >> Foo01.ad
B:name of the first file given to build with the extension and numbers stripped off.
$ZBC.ad >> Foo.ad (only if running "change" mode - see below)
A:names of the files given to build.
$ZB.sil >> Foo01.sil Foo02.sil . . .
F:same as $ZB plus the string "-Rev-" and revision appended.
$ZF.dm >> Foo-Rev-Aa.dm
In addition, there are a number of characters that will modify whether an expansion is to take place attall.
C:Only if running in change mode
G:Only if using the Gobble program
R:Only if using the Route program
M:Only if using the Multiwire option of Route
Build can be invoked "tentatively" by saying Build/T ... In this case, only steps 2 and 4 are executed. This allows you to look at the .er, .ge and .ad files before committing to the revisions. If you are re-working, the new wirelist will of course be on aabb01.wlNew, i.e., no copying will have been done.
Build is designed to permit restarting at any time without damage to vital files. Thus, if the Alto disk fills up during one of the operations, you can delete some old files and retry the Build command. You specify the step at which Build is started by add the number to the global switches to build, thus "Build/6 . . ." will start Build up at level 6.
Build uses a rather general mechanism for passing phrases from its command line on to the subsystems it invokes (Analyze, Gobble, Sil/p, and Ftp). Phrases of the form xxx/qyy will be passed on as xxx/yy to the subsystem whose initial letter is q. Thus conn/fc is passed to Ftp as conn/c; maxc/f is passed to Ftp as maxc; 4/ge is passed to Gobble as 4/e. If the xxx phrase is empty, the switch phrase is passed as a global switch. Thus \gy is passed to Gobble as the global switch \y. So a real command to Build that might update a real board to rev F is:

Build \gl 6/ge f/r maxc/f conn/fc d1/f password/f d1pa*.sil

CONVENTIONS FOR USING THE DESIGN AUTOMATION SYSTEM

This section recommends several conventions for using the design-automation system. Although not every design group will want to follow them all, they have aided a number of large projects. Note that this information is supplemental to a great deal of detailed conventions mentioned elsewhere in this document (e.g., the rules that must be followed to please Analyze).

Drawing files have the extension .Sil, and are given reasonably short names of the form xxyydd.Sil, where xx is a code for the project, yy is a code for a specific logic board, and dd is a two-digit number that indexes the drawings for the board. The two-digit number three is 03 -- this convention assures that the Alto Executive * feature in filename recognition will always process drawings in numerical order. Thus "Sil/P D1CB*.Sil" will print the drawings consecutively.

In Sil, do all drawings on a grid of 4 units (↑G2).
Macros should be defined so that all connection points lie on grid points. Use a "title area" at the bottom of each drawing -- the file LogicBlock.Sil provides a template.

Component names should be all upper case. For example, MC101, N123 or H04 are good component names. Note that H04 is a component name and h04 is a board location.

Signal names should be mnemonic, pronounceable and meaningful. Names should begin with a capital letter, use upper case to separate words, and should contain no spaces, {, }, <, >, ;, or * characters (some of these confuse the stitch-welding program). Examples of beautiful signal names are:

MemoryDataReady BufferEnable CompareError

In order to name individual lines of buses and registers, follow the signal name with .dd, where . is the period character, and dd is a one or two digit number. Include the leading zero for buses wider than 10 bits to make name sorting convenient. Thus:

Video.0BMux.00
Video.1BMux.01
Video.2...
Video.3BMux.15

The active low version of a signal is denoted by appending the character ’ (single quote) to the name. Ready inverted is Ready’.

Signals that are driven differentially (often cable and edge signals) have + as the final character of the differential positive signal and - as the final character of the differential negative signal. For example, LineSync+ and LineSync- would be received differentially and produce LineSync as output.


Perhaps the largest single problem in managing a large design project is data management: keeping all the drawings, wire lists, macros, etc. together, especially as changes are made. The Build subsystem, described above, is an attempt to impose some order on the chaos. Even if you object to the specific actions Build takes, you should enforce some conventions for preventing disaster. The nexus of the problem concerns Gobble re-work: it is essential to have a wirelist that accurately reflects the current state of your board. As revisions fly thick and fast, it is surprisingly easy to get confused.

FILE FORMATS

SIL drawing format

The format of Sil files is considered "private" to the suite of design-automation programs.

Text file conventions

Most of the files used in the design-automation system are text files, for convenience in fixing problems, editing, seeing what you are doing, and the like. Several conventions apply to all such files:

Comments are embedded in files by putting semi-colon (;) as the first character in a comment line; the remainder of the line is ignored.

Dictionary format

The file Dict.Analyze is a text file which contains definitions for all components which may be used in a drawing. The file contains two sections, a header, which contains the names for all components in the balance of the file, and a body, which contains the association between groups, pin names, and pin numbers for each component. A (small) dictionary might have the form:

MC100=MC10100/16/E
MC136=MC10136/16/E
@
MC100
a,IN,4,5
a,c,9
a,OUT,2
b,IN,6,7
b,OUT,3
c,IN,10,11
c,OUT,14
d,IN,12,13
d,OUT,15
@
MC136
a,CC,13
a,D0,12,
a,D1,11
a,D2,6
a,D3,5
a,S1,9
a,S2,7
a,CI,10
a,C0,4
a,Q0,14
a,Q1,15
a,Q2,2
a,Q3,3
@

The first two lines are the header. The first string is the
print name of a component (MC100), which is the name Analyze expects to find in the drawing. Usually, these names are short versions of the real name, which is the second item. The real name is the manufacturer’s name for the component, and might be used for automatic preparation of purchase orders, for example. The "/16/E" following the real name is the number of pins on the IC and the family type. This information about the IC is required by the Gobble wirelister, so that it can do terminator assignment (ECL), power assignment, and routing properly. The family types currently supported by Gobble are (the term "PackPin" is the number of pins in the package, either 14 or 16):

E: MECL 10K (Gnd on pins 1,16; Vee on pin 8)
N,S,H: Normal, Schottky, and H TTL (Vcc on PackPin; Gnd on PackPin/2)
T: 8-pin SIP terminators (Vee on pin 1)
P: 16-pin pullup resistor newtorks (Vcc on pin 16)
M: MOS (Gnd on pin 16; Vcc on pin 9; Vdd on pin 8; Vee on pin 1)

The header is terminated with @.

The balance of the file consists of blocks describing each component. Each block begins with the print name of the component, and is terminated with an @. The first field in each line is the group id for the information on the balance of the line, the second entry is the pinname, and the third (and subsequent) entries are a list of the ic pins which can have the given group id and pin name. There may be multiple pins with the same group id and pin name if the pins are logically identical (i.e. if Analyze is allowed to permute them during the pin assignment process). The MC100, for example, contains four groups, one for each of the four gates in the package. The groups are lettered a-d. The IN signals in each group may be permuted. The MC136 has only one group, group a, and its pins may be assigned in only one way.

If a chip in a particular family does not obey exactly the power/ground rules for the family (stated above), it is possible to include information in the component blocks that describes the power requirements. This is accomplished with a line following the print name that begins with the word POWER, and cites pin numbers and power names. For example, the following line would describe an MC100, although it is identical to the normal rules:

POWER GND,1,VEE,8,GND,16

And the following line would describe an MC210:

POWER GND,1,VEE,8,GND,15,GND,16

The pin numbers should be in ascending order.

WARNINGS, UNIMPLEMENTED THINGS, ETC.

As of 25 July 1977, the following cautions apply:

1. Gobble makes no use of the special POWER entries in the dictionary, and will only perform with the "standard" powering rules. Gobble really understands very little about power: it is willing to wire power to N,S,H, and P components. Others are assumed to have power already wired. This is being fixed.

2. By the same token, Gobble will not issue instructions for "cutting" already-wired pins away from committed power buses. This too will be fixed.