![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ucds.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / Ucds|
Return to ucds.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / Ucds |
1.1 root 1: .so ../ADM/mac
2: .XX 33 549 "The UNIX Circuit Design System"
3: .TL
4: The
5: .UX
6: Circuit Design System
7: .AU
8: A. G. Hume
9: .AU
10: T. J. Killian
11: .AB
12: .SM UCDS
13: is a system for the design and prototyping of digital systems.
14: At the front end
15: it provides hierarchical schematic entry,
16: .SM PAL
17: design and board layout; at the back end it
18: produces data for various manufacturing technologies, in particular
19: wire-wrap and multiwire.
20: .AE
21: .NH
22: Introduction.
23: .LP
24: A design has a logical part and a physical part.
25: The logical part consists of circuit schematics, generally
26: supplemented by
27: .SM PAL
28: equations. The physical part includes board layout and routing.
29: .LP
30: A circuit contains
31: .I chips
32: each identified by
33: .I name
34: (which is arbitrary, and of mnemonic value to the designer) and
35: .I type
36: (which is generic, e.g.,
37: .CW 74LS74 ")."
38: Schematics can be hierarchical; what appears syntactically as
39: a chip is in fact an instance of a
40: .I macro ,
41: (i.e., another drawing) if the file
42: .I "type\c"
43: .CW ".w"
44: .R
45: exists.
46: Real chips have
47: .I pins ,
48: each identified by a
49: .I "pin name"
50: and
51: .I "pin number" ","
52: and a
53: .I "package type" "."
54: Pin names and their mapping onto pin numbers are a property of
55: the chip type; the mapping from pin numbers to physical coordinates
56: is a property of the package type.
57: .LP
58: Pins are connected by
59: .I nets ","
60: which have unique
61: .I "net names"
62: (assigned by the drawing package if
63: omitted by the user). It is an error for a pin to
64: be connected to more than one net.
65: Nets such as
66: .CW VCC
67: and
68: .CW GND
69: generally need different routing algorithms from ordinary nets;
70: these are called
71: .I "special-signal nets"
72: in cases where the distinction is important.
73: .LP
74: A
75: .I board
76: is a physical mounting for packages. It is mostly characterized by its
77: .I "pin holes"
78: (available for package insertion) and
79: .I "special-signal pins"
80: (connected to special-signal nets). An
81: .I
82: .SM I/O
83: .R
84: .I connector ","
85: where signals enter or leave the board, is simply a special case
86: of a chip.
87: .NH
88: Methodology.
89: .LP
90: These are the conventional steps in a design. Many are necessary simply to
91: maintain consistency between ``source'' and ``object'' files.
92: We will collect all of this into a
93: .CW mkfile
94: in a later section.
95: .nr P 0 1
96: .IP (\n+P)
97: The interactive program
98: .I jraw
99: is used to construct schematics, kept in files
100: whose names end with
101: .CW ".j" "."
102: The semantics of a circuit diagram (its
103: .CW ".w"
104: file) are derived from the
105: .CW ".j"
106: file by running
107: .I "jraw -w" "."
108: .IP (\n+P)
109: Any editor may be used to create files in
110: .CW lde
111: format for logic that is to be implemented with
112: .SM PAL "'s."
113: These filenames end with
114: .CW ".e" "."
115: Pin information resides in a corresponding
116: .CW ".p"
117: file, generated by
118: .I "lde -W" "."
119: .IP (\n+P)
120: A
121: .CW ".pins"
122: file, that matches pin names with numbers for each chip type, must
123: be constructed. Most pin information comes from standard libraries,
124: but the user must generally supply some of it, usually for
125: .SM I/O
126: connectors (\c
127: .CW io.pins ")"
128: or non-standard chips (\c
129: .CW my.pins ")."
130: .I Mkpins
131: reads
132: .CW ".w"
133: files,
134: .CW ".p"
135: files, and pin libraries to produce the
136: .CW ".pins"
137: file.
138: .IP (\n+P)
139: .I "Cdmglob -f -v"
140: reads the
141: .CW ".w"
142: and
143: .CW ".pins"
144: files to produce a
145: .CW ".wx"
146: file, in which all macros are expanded, and nets are described in terms of
147: pin numbers.
148: .IP (\n+P)
149: At this point one may do static circuit checks with
150: .I smoke "."
151: .IP (\n+P)
152: Most files discussed so far have to do with the logical part of the design, and,
153: except for
154: .CW ".e"
155: files, are in
156: .SM CDL
157: (Circuit Design Language). The remainder of the physical design files are in
158: .SM FIZZ
159: format. So, at this point, one uses
160: .I "fizz cvt"
161: to turn the
162: .CW ".wx"
163: file into a
164: .CW ".fx"
165: file.
166: .IP (\n+P)
167: As with the
168: .CW ".pins"
169: file, one creates a
170: .CW ".pkg"
171: file with geometric descriptions of each package type.
172: .IP (\n+P)
173: A geometric description of the board (\c
174: .CW ".brd"
175: file) is made.
176: .IP (\n+P)
177: Chip positioning information (\c
178: .CW ".pos"
179: file) is generated. This is usually done interactively with
180: .I "fizz place" "."
181: .IP (\n+P)
182: The wrap list (\c
183: .CW ".wr"
184: file) is now made, and one can physically wrap the board.
185: .IP (\n+P)
186: To make changes, one generates a new
187: .CW ".wr"
188: file;
189: .I rework
190: then compares the new and old wrap files and generates separate lists
191: for unwrapping and rewrapping.
192: .NH
193: Using
194: .BI jraw .
195: .LP
196: .NH
197: Signal Bundles and Macros.
198: .LP
199: Consider this buffer between two 8-bit busses:
200: .PS <fig1.pic
201: It illustrates several
202: .I jraw
203: conventions. The
204: .I chip
205: is indicated by a box; its
206: .I name
207: is
208: .CW buffer ;
209: its
210: .I type
211: is
212: .CW 74F244 .
213: These are simply unattached text strings that appear stacked inside the
214: box.
215: .I "Pin names"
216: (e.g.,
217: .CW D0 )
218: are strings that appear on the inside edge of the box.
219: .I Nets
220: are lines that end on a pin.
221: .I "Net names"
222: are strings that are placed on nets. A trailing
223: .CW "-"
224: conventionally indicates an active-low signal.
225: .LP
226: Even this trivial example involves repeated patterns.
227: A much more succint equivalent is:
228: .PS <fig2.pic
229: The
230: .I generator
231: .CW "x<0:7>"
232: expands into the ordered list
233: .CW x0 ,
234: .CW x1 ,...
235: .CW x7 .
236: The
237: .I pattern
238: .CW "D?\&"
239: matches two-character pin names that begin with
240: .CW D .
241: (The space of possible names comes from the
242: .CW .pins
243: file entry for the chip type.)
244: The names that match the pattern are
245: .I "sorted alphabetically"
246: and put into correspondance with the nets.
247: .LP
248: If connected sets of nets and pins do not have the same cardinality,
249: the smaller set is reused until the larger is exhausted. Thus in the
250: example, the
251: .CW drive-
252: net gets connected to both
253: .CW OE0-
254: and
255: .CW OE1- ,
256: as desired.
257: .LP
258: Frequently one has a group of chips that will be used or replicated as
259: a unit. In such a case it makes sense to define a
260: .I macro
261: that may be instantiated as required. A macro lives in its own file.
262: Here is an example,
263: .CW opm.j :
264: .PS <opm.pic
265: The dotted box (produced by selecting
266: .CW macro
267: in
268: .I jraw ")"
269: identifies the circuit as a macro. Strings outside of this box
270: (conventionally in upper case) are ``pin names'' visible to the
271: outside world. Most names inside the box will be made local to
272: each instantiation. Net names beginning with
273: .CW "/"
274: are ``globals,'' i.e., they represent the same signal throughout
275: the design.
276: .CW "/VCC"
277: and
278: .CW "/GND"
279: are the most common global signals.
280: .LP
281: Now we use generators to make several instances of
282: .CW opm.j :
283: .PS <opmcall.pic
284: Sixteen copies of the
285: .CW opm
286: circuit are made. The pattern
287: .CW "D?\&"
288: is at a lower, i.e., ``faster running,'' level than
289: .CW "opm<00:15>" ,
290: with the effect that all the
291: .CW D0 "'s"
292: are connected to
293: .CW "bd0" ,
294: all the
295: .CW D1 "'s"
296: are connected to
297: .CW "bd1" ,
298: etc; similarly, all the
299: .CW A0 "'s"
300: are connected to
301: .CW ba0 .
302: On the other hand, all the
303: .CW "CS-" "'s"
304: are separate:
305: .CW "opm00/CS-"
306: (the instance of
307: .CW CS-
308: in
309: .CW opm00 )
310: is connected to
311: .CW "ops00-" ,
312: .CW "opm01/CS-"
313: is connected to
314: .CW "ops01-" ,
315: etc. The manual entries for
316: .I cdm
317: and
318: .I cdmglob
319: should be consulted for all the details.
320: .NH
321: A Toy Example.
322: .LP
323: In this section we present a complete example. The design consists of
324: two
325: .SM I/O
326: connectors that route signals from a ribbon cable to a backplane.
327: Here is the schematic, followed by the
328: .CW ".w"
329: file:
330: .PS <toy.pic
331: .nr dP 2 \" delta point size for program
332: .nr dV 2p \" delta vertical for programs
333: .P1
334: .so toy.w.l
335: .P2
336: .LP
337: The comments (introduced by
338: .CW % )
339: are coordinates from the
340: .CW .j
341: file that can be used later to annotate the drawing with pin numbers.
342: Otherwise the
343: .CW .w
344: file is mostly just a compendium of the text strings in the
345: .CW .j
346: file.
347: In order to proceed further, we need a
348: .CW .pins
349: file:
350: .P1
351: .so toy.pins.l
352: .P2
353: .LP
354: It should be fairly obvious what is going on here. Note the appearance of the
355: .I "package type"
356: on the
357: .CW .t
358: lines.
359: Now the
360: .CW .wx
361: file can be made:
362: .P1
363: .so toy.wx.l
364: .P2
365: .LP
366: This is basically a listing, for each chip, of net\ name\-pin\ number pairs.
367: Package types are copied through from the
368: .CW .pins
369: file for use by the physical design tools, and
370: the pin names are left as an aid to humans.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.