| blob | 81aa71fcefa4e2baec4d406a3e6c51749cc07245 |
3 <html>
4 <head>
10 </head>
11 <body>
15 <ul>
16 <li class="level1"><div class="li"> hierarchy in schematic and netlist and pcb -- modules that can be reused, arrayed.</div>
17 </li>
18 </ul>
20 <p>
21 The classic example of this is a stereo amplifier. You enter the schematic of an amplifier channel and a second one showing controls and power. You enter a symbol for the unit that points to three schematic pages.
22 </p>
23 <pre class="code"> Page 1 is the control/power , Page 2 is the amplifier with macro substitutions of right and U100 for all nets and Refdes, Page 3 is the amplifier with macro substitutions of left and U200 for all nets and Refdes.
26 Extra credit if the number of channels is controlled by an attribute set when you instantiate the unit symbol. This is comparable to the verilog generate command.</pre>
28 </div>
30 <h2 id="intermediatetranslationfileformatvhdledif">intermediate translation file format VHDL? EDIF?</h2>
33 </div>
38 <p>
39 In an *AMS language, nets have types. It's not just "wire". The schematic needs to be extended so that pins on symbols can have types. It is not prohibited to mix types. Verilog has something called a "connectmodule" to define how to resolve mixed types. <strong>gschem attributes need to have types.</strong> [Al Davis]
40 </p>
42 <p>
43 I certainly agree that the (gnetlist-ed.) Verilog output is not 'lossless' -- it's only an interchange format for the interconnect...[Mike Jarabek]
44 </p>
46 <p>
47 He's not actually proposing to use VHDL (as modeling language-ed.) but to steal some <strong>syntax from VHDL</strong> and interpret it as he sees fit for the task. In particular, he's only interested in the <strong>entity-architecture separation</strong>[Steve Williams]
48 </p>
50 <p>
51 More useful, (than creating intermediate file formats-ed.) is to <strong>refactor libgeda and define an API</strong> which can be exposed via C, scheme, DBus, and other scripting languages directly modifying the underlying design. [Peter Clifton]
52 </p>
54 <p>
55 Any extraction should preserve hierarchy, in hopes that the target tool also benefits from it. Translation must be 100%, lossless, from netlist to PCB refdes, and from PCB refdes used to create a module or back annotate a schematic. [Al Davis] [paraphrased heavily by JGriessen -- correct?]
56 </p>
58 <p>
59 The <strong>file format should be designed as a language</strong> meaningful and expressive of IC, programmable logic, and printed circuits. File formats that are data structure dumps cause big problems. We need an interchange file format..[Al Davis]
60 </p>
62 <p>
63 If EDIF has layout objects or schematic objects
64 built-in, that is actually a weakness. Just like SPICE having
65 resistors and transistors built-in has become a weakness.[Al Davis]
66 </p>
68 <p>
70 one reason for my preference. It's not all technical[Al Davis]
71 </p>
73 <p>
74 <strong>PCB behavior with a hierarchic netlist</strong> Right click on a symbol, select "go inside", and another drawing opens up showing what's inside. gschem also should act this way. [Al Davis] Display in place what's inside, <strong>turn on/off the visibility</strong> or "editability" of any subcells. [Igor] <strong>Ability to visually toggle</strong> [Dan McMahill] <strong>"blocks" should be translucent.</strong> (To show in place)ed. even when you're not editing it. [DJ Delorie] Yep. [John Griessen] Dive into a block so you can edit it. When done, <strong>close and updated in place</strong>. [DJ Delorie]
75 </p>
77 <p>
78 <strong>how to handle re-use blocks?</strong> [Stuart Brorson] That is, if I have a sub-schematic which I instantiate four times, how should it be refdesed in the netlist?
79 </p>
81 </div>
86 </div>
91 <p>
92 (InterProcess Communication -ed.) between gschem and PCB using DBus will benefit from netlisting changes (certainly cross probing and back annotation).[Peter Clifton]
93 </p>
95 <p>
96 Peter Brett and I put together a graphical frontend to gsch2pcb which uses gsch2pcb's output to feed changes into a live PCB layout. [Peter Clifton]
97 </p>
99 <p>
100 For <strong>cross-probing</strong> / interactive simulation / back annotation, we require libgeda to <strong>give gschem, gattrib etc.. the circuit representation</strong> underlying your schematic drawing.[Peter Clifton]
101 </p>
103 </div>
108 <p>
109 libgeda could/should evolve - as a backend to different tools. Since the PCB file-format is PCB's, and may change, it is wiser to use a defined API to PCB to make PCB write the file. This entails adding to PCB's action interface as necessary, and making gsch2pcb output a script of actions rather than a "PCB" file. [Peter Clifton]
110 </p>
112 <p>
113 I'm hoping to separate much of the GUI structure and cram that back in the applications it belongs in, re-structuring libgeda to be design data-oriented.[Peter Clifton]
114 </p>
116 <p>
117 <strong>function library with bindings to users language of choice</strong> a proper, "official" Perl-callable library to parse a layout file, a footprint file, or a schematic file, and load the data into an in-memory data structure. Such a library to read and write these file formats would dramatically reduce the activation energy hump to write a rich set of tools for all of us. [CP Tarun]
118 </p>
120 <p>
121 It would not fall out of sync with the changing file-formats, because you wouldn't write yet another implementation of the parser, data-structures etc, nor would you copy-paste code. You would have one library which is used by all tools (probably in C as this is what the suite mostly uses), then you would provide language bindings so people can write the useful utilities they want. If this means having to split code out of existing tools and into a library, that is the way forward in terms of code reuse. [Peter Clifton]
122 </p>
124 <p>
125 I completely agree. [Dan McMahill]
126 </p>
128 <p>
129 Also consider libgpmi which currently supports 8 languages, will support guile [Igor]
130 </p>
132 </div>
137 <p>
138 It is very useful I think to let DRC run to completion and <strong>have a DRC layer</strong> (or perhaps 1 DRC layer per copper layer as you suggest) that identifies exactly the <strong>offending feature</strong>.[Dan McMahill]
139 </p>
141 <p>
143 </p>
145 <p>
146 have a block (in PCB)ed. that is a modular entity. Normally, you can't do anything but move it around as a whole. A special action "opens" this block (and hides everything else) so you can edit it. When you're done, it's closed again - and any copies of the block are automatically updated in place. [DJ Delorie]
147 </p>
149 <p>
150 <strong>be able in the netlist to tell pcb which slots are swapable</strong>, which i/o pins are swapable and which pin pairs can function as differential pairs (these last two have to be able to be limited to specific banks) such that pcb could correctly change the net list itself. Then I would like PCB to be able to tell me what pins and in what order the pins were swapped so that this could be imported back into the original design.[Steve Meier]
151 </p>
153 <p>
154 <strong>gschem attribute editable as symbols placed</strong>, (such as description of the layout footprint attribute) [CP Tarun]
155 </p>
157 <p>
158 <strong> recesses in boards, (holes in PCB layers)</strong>[Steve Meier] Required for straight leads out side of packages and flex circuits.
159 </p>
161 <p>
162 Yeah, you'd need the "layer types" patch to really manage that, as you'd be able to tag multiple pcb layers as "outline" layers[DJ Delorie]
163 </p>
165 <p>
166 <strong> PCB should be able to do hidden vias</strong>, buried vias and micro vias. [Steve Meier]
167 </p>
169 <p>
170 Answered by non-copper layers, multi-pin projects in SoC list [DJ Delorie]
171 </p>
173 <p>
174 Use padstack to build elements with copper and non-copper layers independent.[Levente]
175 </p>
177 <p>
178 <strong>a PCB interface for presenting dynamic dialog boxes</strong> for importers [Igor] I think this is part of having easy scripting of user's choice, so an important design flow consideration[John Griessen]
179 </p>
181 </div>
186 <p>
187 <strong>change only the top of hierarchy string</strong> of a layout module to netlist correctly.[Steve Meier]
188 </p>
190 <p>
192 </p>
194 <p>
195 PCB doesn't care what the refdes is, a heirarchical one is just as valid [DJ Delorie]
196 </p>
198 <p>
200 </p>
202 <p>
203 Can be putoff and done as a GUI plugin script -- a detail of easy scripting wants [JGriessen]
204 </p>
206 <p>
207 <strong>In gschem, more control over printed or exporting</strong>, as in CAM files a la Eagle.[CP Tarun]
208 </p>
210 <p>
211 Can be putoff and done as a GUI plugin script -- a detail of easy scripting wants [JGriessen]
212 </p>
214 </div>
219 <p>
220 <strong>What kind of data structures are desirable?</strong> How would they look? [Stuart Brorson]
221 <strong>Once a datastructure is decided upon, then what does the file format look like?</strong> Preserving the current close mapping of files to data structures is a desirable goal. The data structures defining hierarchy dictate what the file format should look like. [Stuart Brorson]
222 </p>
224 <p>
225 Right now, the main data structure for a schematic is a linear linked list of graphical objects (for each schematic page). Some list items point to others (i.e. to support component attributes). How would that change to support hierarchy? [Stuart Brorson]
226 </p>
228 <p>
229 PCB has a second format it uses called a "resource file". It's a semi-lisp-ish format that allows for arbitrarily nested data. It could be used to hold pretty much anything, but it isn't "designed for the data".[DJ Delorie]
230 </p>
232 <p>
233 <strong>How should gschem behave once hierarchy is architected in?</strong> Right now you attach a source= attribute to a symbol. Then you do "schematic down" on that symbol to dive into the sub-schematic. Is that OK? Or what's a better scheme?
234 </p>
236 <p>
237 <strong>Some work has already been done using gnetman by Bill Cox,</strong> but it has never been part of the distribution gnetlist. Dan McMahill wrote: "a reason to use the gnetman database as opposed to one designed by one of us" is that without availing Bill Cox's substantial tested work, we may "find that the underlying database structure and methods for accessing it still aren't complete enough, fast enough, or scalable enough."
238 </p>
240 <p>
241 <strong>Some work has already been done by Steve Meier</strong> to enable practical work on FPGAs.
242 </p>
244 <p>
245 <strong>Some design work has been done by Peter Brett and Peter Clifton,</strong> producing a concept diagram of a sub-circuit oriented data-structure based on gnetman's structure diagram for netlisting. See <a href="geda-datastructuredesigndiscussion.html" class="wikilink2" title="geda-datastructuredesigndiscussion.html">data structure design discussion</a>
246 </p>
248 </div>
249 </body>
250 </html>