FreeCalypso > hg > ueda-linux

comparison ueda/doc/netlisting.txt @ 0:cd92449fdb51

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial import of ueda and ifctf-part-lib from ifctfvax CVS
author Space Falcon <falcon@ivan.Harhan.ORG>
date Mon, 20 Jul 2015 00:24:37 +0000
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:cd92449fdb51
1 How uEDA tracks electrical interconnect (netlist) information
2
3 Whereas the MCL (see mcldoc.txt) is the authoritative source of information
4 about all components making up a board design, information about the way they
5 are interconnected is stored in the schematic sheets (.usch files) in the
6 language described in uschemlang.txt. Electrical connections are declared by
7 way of assigning component pins to named or unnamed nets and may or may not be
8 represented graphically. The following two constructs in the uschem language
9 connect component pins to nets:
10
11 * Net and GraphNet objects
12 * PinToNet decorations on component instance objects
13
14 Whichever method is used (see uschemlang.txt for the syntax details), the
15 declaration of an electrical connection effectively consists of the following
16 3 parts:
17
18 * Identification of the component involved;
19 * Identification of which pin to connect;
20 * The name of the net. (Net and GraphNet objects can create unnamed nets -
21 those connect together everything listed in the respective object, but
22 nothing else can connect to such nets.)
23
24 While it's possible for the component identification to be equal to the refdes
25 as given in the MCL and for the pin identification to be the "raw" pin number,
26 uEDA provides two mechanisms that allow the interconnect information to be
27 entered in a slightly more high-level form: component instances and pinout
28 mapping.
29
30 Component instances
31
32 In uEDA a component instance is essentially a reference from a schematic sheet
33 to a component in the MCL. In a graphical schematic each component instance
34 would normally be represented by a graphical symbol, and all net connections
35 made in schematic sheets actually refer to component instances rather than to
36 MCL components directly.
37
38 For trivial components like resistors and capacitors as well as some simple
39 ICs there is normally only one instance per component, hence the component in
40 the MCL and the instance in a .usch sheet are one and the same for all practical
41 purposes. However, for many of the more complex components it is generally
42 desirable to break the component up into multiple sections (which may be
43 identical or heterogeneous) represented separately in the schematic source code
44 for the design. That's what the component instances in uEDA are for.
45
46 In the case when there are multiple component instances referring to the same
47 component, these instances may appear either in the same schematic sheet or in
48 different sheets. If a given schematic sheet contains only one instance of a
49 given MCL component, regardless of whether or not there are other instances for
50 the same component in other sheets, the instance name may be equal to the refdes
51 of the component - that's what happens when the user doesn't make use of the
52 component instance mechanism. However, if a single schematic sheet contains
53 more than one instance for a given component, there needs to be a way to
54 distinguish between them.
55
56 When uEDA tools process a uschem sheet and match it to the MCL, the following
57 algorithm is used to match component instances to components:
58
59 1. All component instance names appearing in a given schematic sheet are
60 required to be unique.
61 2. Each component instance name is stripped of any trailing lowercase letters to
62 obtain the corresponding refdes.
63 3. Each refdes is looked up in the MCL - if not found, that is an error.
64
65 Thus if you need to put multiple instances for a given component in a single
66 schematic sheet, give each a unique name consisting of the refdes with a unique
67 all-lowercase suffix appended to it.
68
69 Pinout mapping
70
71 uEDA allows one to use two different alphanumeric strings to identify the
72 individual pins of a component: pin name and pin number. Both are arbitrary
73 alphanumeric strings (actually strings of any printable ASCII characters subject
74 only to common sense limitations); the pin number string doesn't have to be
75 purely numeric. (For example, PGA and BGA packages normally use alphanumeric
76 pin numbers.)
77
78 Pin numbers are what appears in the final netlist output from uschem-netlist(1),
79 and they may also be used in the schematic source code. If the source only uses
80 pin numbers for a given component, then there is no need for uEDA to know the
81 pinout of that component. However, uEDA also allows one to specify the pinout
82 mapping for a component and to use pin names instead of pin numbers.
83
84 Pinouts are specified in dedicated pinout mapping files and brought into the
85 design via pinout= attributes in the MCL. Pinout mapping files use a very
86 straightforward format: each pin mapping is given on a separate line; each such
87 line consists of two fields separated by tabs or spaces: the left field is the
88 pin name and the right field is the pin number. Comments are marked by '#';
89 all blank lines and comment lines are ignored. Any additional fields past the
90 pin number are currently ignored as well, but this behavior should not be relied
91 upon; any such line-appended comments should begin with a '#' character.
92
93 The name of the pinout mapping file specified in the pinout= attribute is only
94 the base filename, not a pathname. uschem-netlist and uschem-print (the only
95 two programs in the uEDA suite that need pinout mappings) locate pinout mapping
96 files using the same mechanism that is used to locate graphical symbol files -
97 see uschem-netlist(1) and uschem-print(1).
98
99 In addition to making the schematic source code more readable, pinout mappings
100 make it easy to support components that come in several different packages with
101 different physical pin numbers for the same logical functions. It is no longer
102 necessary to create multiple versions of the same graphical symbols with
103 different pin numbers embedded inside or to edit pin references in Net objects;
104 instead all those references can now be made by the logical pin name. If a
105 decision is made to change to a different package with a different pinout, only
106 the pinout= attribute in the MCL entry for the respective component needs to be
107 changed - at the same time when you change the manufacturer_part_number= and
108 footprint= attributes.
109
110 By the same token it is no longer necessary to create special PCB footprints
111 with logical pin names embedded in them where pin number strings normally go:
112 instead one can take the natural approach of having footprints identify pins or
113 pads by their physical position, having schematics and symbols refer to pins by
114 their logical function only and using pinout mapping files to bridge the gap.
115 The pinout mapping feature is one of uEDA's main advantages over gEDA.
116
117 Slotting
118
119 The concept of slotting (and the term) originates in gEDA, but uEDA implements
120 it in a very different manner. uEDA's approach to slotting combines component
121 instances with pinout mapping in a special way. But first, what is slotting?
122
123 Suppose that you have a physical component (typically an IC) that consists of
124 multiple identical logical blocks such that each of those blocks should be
125 treated as a separate device in the schematic source code. 74xx logic ICs are
126 a classic example. When one needs to describe the use of such a component in a
127 design, it is normally desirable to represent each slot as its own component
128 instance and furthermore to do it in such a way that one doesn't have to decide
129 upfront which slot will be used for what, allowing slots to be reassigned with
130 ease.
131
132 In uEDA this feat is accomplished by combining component instances with pinout
133 mapping. When each slot is declared as a component instance, all connections
134 to it are made by logical names only: for example, a NAND gate that is 1/4th of
135 a 7400 would have connections made to A, B and Y rather than to specific pin
136 numbers. So far, so good. But how would the tools know whether A for example
137 should be mapped to pin 1, 4, 9 or 12? That is where the slot= attribute comes
138 in. It is one of the few attributes defined in the component instance
139 declaration (Component object) in a schematic sheet rather than in the MCL.
140 When uEDA tools map a pin name to a pin number for a component instance that has
141 the slot= attribute defined, the value of this attribute is appended to the pin
142 name after a colon, e.g., if the pin name is A and slot=1, the pin name looked
143 up in the pinout mapping table will be A:1. The pinout for a 7400 quad NAND
144 gate looks like this:
145
146 #pin name pin number
147 A:1 1
148 B:1 2
149 Y:1 3
150 A:2 4
151 B:2 5
152 Y:2 6
153 GND 7
154 Y:3 8
155 A:3 9
156 B:3 10
157 Y:4 11
158 A:4 12
159 B:4 13
160 Vcc 14
161
162 Note the GND and Vcc pins which are not slotted. It is perfectly legitimate to
163 have some component instances which have the slot= attribute selecting one of
164 the logic slots, yet have other component instances referring to the same
165 component (e.g., for the power pins) without slotting.
166
167 The following pinout for an SN75LBC784 EIA-423 transceiver is a more complicated
168 example of heterogeneous slotting:
169
170 #pin name pin number
171 Drvr_In:3 1
172 Rcvr_Out:3 2
173 BIAS1 3
174 Drvr_In:4 4
175 Rcvr_Out:4 5
176 BIAS2 6
177 Vss 7
178 GND 8
179 Rcvr_In_N:4 9
180 Drvr_Out:4 10
181 Rcvr_In_N:3 11
182 Drvr_Out:3 12
183 Rcvr_In_P:3 13
184 Rcvr_In_P:4 14
185 Rcvr_In_P:1 15
186 Rcvr_In_P:2 16
187 Rcvr_In_N:2 17
188 Drvr_Out:2 18
189 Rcvr_In_N:1 19
190 Drvr_Out:1 20
191 Vdd 21
192 Rws 22
193 Drvr_In:1 23
194 Rcvr_Out:1 24
195 BIAS3 25
196 Drvr_In:2 26
197 Rcvr_Out:2 27
198 BIAS4 28
199
200 This IC has 4 driver sections, 4 receiver sections and a set of common pins.
201 The pinout file given above allows it to be represented schematically using a
202 separate component instance for each driver section (with slotting), a separate
203 set of component instances for the receiver sections (an independent set of
204 slots) and one or more non-slotted component instances for the common pins.
205
206 It is also worth noting that slot names (the value of the slot= attribute) are
207 not restricted to numbers only and may in fact be arbitrary ASCII strings. For
208 example, it would be sensible to define the pinout for a bicolor LED with slots
209 named "red" and "green", having complete pin names such as A:green and C:red
210 with connections being made to just A and C on the proper instances.
211
212 Netlist generation
213
214 When uschem-netlist processes a set of schematic sheets and an MCL to compile a
215 complete netlist, it first resolves all pin names (with or without slots) to
216 physical pin numbers and tracks the connection information at the component
217 level, i.e., the information is effectively moved up from the instance level at
218 which it is specified in the schematic source code to the component level. The
219 netlist data structures constructed by uschem-netlist maintain a hard
220 requirement that every physical pin of every component listed in the MCL be
221 either connected to exactly one net or left unconnected; thus any attempt to
222 connect the same physical pin to more than one net will be detected and flagged
223 as an error regardless of how each connection was specified in the source code.
224
225 One may use the NoConnect decoration on a component instance object to declare
226 explicitly that a given pin shall be left unconnected. uschem-netlist will note
227 such declarations and flag an error if an attempt is made anywhere else in the
228 source code to connect the same physical pin to some net.
229
230 Differences from gEDA
231
232 The main difference between gEDA and uEDA with regard to netlisting is that in
233 uEDA graphical elements such as symbols and net lines do not create electrical
234 connections, they merely illustrate them. The uschem language (documented fully
235 in uschemlang.txt) is designed so that the graphical information and the
236 electrical interconnect information are mostly orthogonal. The electrical
237 interconnect information must be fully specified in the .usch files, not
238 inferred from symbol files, to the point that the latter files are not needed
239 for netlist generation and are not read by uschem-netlist at all. Thus gEDA
240 constructs such as auto-connected hidden power pins have no place in uEDA; the
241 closest one can get to that would be to insert a non-graphical component
242 instance with the necessary net connections into an otherwise graphical
243 schematic sheet.
244
245 By a similar token the graphical symbols for power rails and such do not cause
246 a net to be connected to a rail, instead that connection is made by having the
247 proper netname set on the GraphNet object in the .usch file; the symbols merely
248 illustrate it graphically for those looking at the printout rather than the
249 source code.
250
251 The downside with uEDA's approach is of course the very real possibility that
252 the netlist and the graphics will get out of sync, i.e., that the set of
253 electrical interconnections mentally inferred by someone looking at the
254 graphical schematic printout will differ from the set of interconnections
255 embodied in the source code processed by uEDA tools. See drc.txt for the
256 discussion of how uEDA addresses this problem.