| blob | 99502a86e6d462129a3849741d84dc7cf4a36d48 |
5 <head>
12 <link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
14 <link rel="contents" href="http://geda.seul.org/wiki/geda:design_flow_and_hierarchy_roadmap?do=index" title="Index" />
15 <link rel="alternate" type="application/rss+xml" title="Recent Changes" href="http://geda.seul.org/wiki/feed.php" />
16 <link rel="alternate" type="application/rss+xml" title="Current Namespace" href="http://geda.seul.org/wiki/feed.php?mode=list&ns=geda" />
17 <link rel="alternate" type="text/html" title="Plain HTML" href="http://geda.seul.org/wiki/_export/xhtml/geda:design_flow_and_hierarchy_roadmap" />
18 <link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:design_flow_and_hierarchy_roadmap" />
22 </head>
23 <body>
30 <li class="level1"><div class="li"><span class="li"><a href="#required_for_production_circuits" class="toc">Required for production circuits</a></span></div>
32 <li class="level2"><div class="li"><span class="li"><a href="#intermediate_translation_file_format_vhdl_edif" class="toc">intermediate translation file format VHDL? EDIF?</a></span></div></li>
33 <li class="level2"><div class="li"><span class="li"><a href="#hierarchical_buses" class="toc">Hierarchical Buses</a></span></div></li>
34 <li class="level2"><div class="li"><span class="li"><a href="#ipc_improvements" class="toc">IPC Improvements</a></span></div></li>
35 <li class="level2"><div class="li"><span class="li"><a href="#robust_function" class="toc">Robust Function</a></span></div></li>
36 <li class="level2"><div class="li"><span class="li"><a href="#other_improvements" class="toc">Other Improvements</a></span></div></li>
37 <li class="level2"><div class="li"><span class="li"><a href="#too_detailed" class="toc">Too Detailed</a></span></div></li>
38 <li class="level2"><div class="li"><span class="li"><a href="#implementation" class="toc">Implementation</a></span></div></li></ul>
39 </li></ul>
40 </div>
41 </div>
45 <h1><a name="required_for_production_circuits" id="required_for_production_circuits">Required for production circuits</a></h1>
47 <ul>
48 <li class="level1"><div class="li"> hierarchy in schematic and netlist and pcb – modules that can be reused, arrayed.</div>
49 </li>
50 </ul>
52 </div>
53 <!-- SECTION "Required for production circuits" [1-135] -->
54 <h2><a name="intermediate_translation_file_format_vhdl_edif" id="intermediate_translation_file_format_vhdl_edif">intermediate translation file format VHDL? EDIF?</a></h2>
57 </div>
59 <h4><a name="schematic_layout_logic_sim_analog_sim_etc" id="schematic_layout_logic_sim_analog_sim_etc">Schematic, Layout, logic sim, analog sim, etc</a></h4>
62 <p>
63 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]
64 </p>
66 <p>
67 I certainly agree that the (gnetlist-ed.) Verilog output is not ‘lossless’ – it’s only an interchange format for the interconnect…[Mike Jarabek]
68 </p>
70 <p>
71 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]
72 </p>
74 <p>
75 More useful, (than creating intermediate file formats-ed.) is to <strong>refactor libgeda and define an <acronym title="Application Programming Interface">API</acronym></strong> which can be exposed via C, scheme, DBus, and other scripting languages directly modifying the underlying design. [Peter Clifton]
76 </p>
78 <p>
79 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?]
80 </p>
82 <p>
83 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]
84 </p>
86 <p>
87 If EDIF has layout objects or schematic objects built-in, that is actually a weakness. Just like SPICE having resistors and transistors built-in has become a weakness.[Al Davis]
88 </p>
90 <p>
91 <strong>EDIF’s not mainstream.</strong> VHDL and Verilog are mainstream. That is one reason for my preference. It’s not all technical[Al Davis]
92 </p>
94 <p>
95 <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]
96 </p>
98 <p>
99 <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?
100 </p>
102 </div>
103 <!-- SECTION "intermediate translation file format VHDL? EDIF?" [136-2788] -->
107 </div>
108 <!-- SECTION "Hierarchical Buses" [2789-2821] -->
112 <p>
113 (InterProcess Communication -ed.) between gschem and PCB using DBus will benefit from netlisting changes (certainly cross probing and back annotation).[Peter Clifton]
114 </p>
116 <p>
117 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]
118 </p>
120 <p>
121 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]
122 </p>
124 </div>
125 <!-- SECTION "IPC Improvements" [2822-3368] -->
129 <p>
130 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 <acronym title="Application Programming Interface">API</acronym> 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]
131 </p>
133 <p>
134 I’m hoping to separate much of the <acronym title="Graphical User Interface">GUI</acronym> structure and cram that back in the applications it belongs in, re-structuring libgeda to be design data-oriented.[Peter Clifton]
135 </p>
137 <p>
138 <strong>function library with bindings to users language of choice</strong> a proper, “official” <acronym title="Practical Extraction and Report Language">Perl</acronym>-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]
139 </p>
141 <p>
142 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]
143 </p>
145 <p>
146 I completely agree. [Dan McMahill]
147 </p>
149 <p>
150 Also consider libgpmi which currently supports 8 languages, will support guile [Igor]
151 </p>
153 </div>
154 <!-- SECTION "Robust Function" [3369-4944] -->
158 <p>
159 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]
160 </p>
162 <p>
164 </p>
166 <p>
167 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]
168 </p>
170 <p>
171 <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]
172 </p>
174 <p>
175 <strong>gschem attribute editable as symbols placed</strong>, (such as description of the layout footprint attribute) [CP Tarun]
176 </p>
178 <p>
179 <strong> recesses in boards, (holes in PCB layers)</strong>[Steve Meier] Required for straight leads out side of packages and flex circuits.
180 </p>
182 <p>
183 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]
184 </p>
186 <p>
187 <strong> PCB should be able to do hidden vias</strong>, buried vias and micro vias. [Steve Meier]
188 </p>
190 <p>
191 Answered by non-copper layers, multi-pin projects in SoC list [DJ Delorie]
192 </p>
194 <p>
195 Use padstack to build elements with copper and non-copper layers independent.[Levente]
196 </p>
198 <p>
199 <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]
200 </p>
202 </div>
203 <!-- SECTION "Other Improvements" [4945-6847] -->
207 <p>
208 <strong>change only the top of hierarchy string</strong> of a layout module to netlist correctly.[Steve Meier]
209 </p>
211 <p>
213 </p>
215 <p>
216 PCB doesn’t care what the refdes is, a heirarchical one is just as valid [DJ Delorie]
217 </p>
219 <p>
221 </p>
223 <p>
224 Can be putoff and done as a <acronym title="Graphical User Interface">GUI</acronym> plugin script – a detail of easy scripting wants [JGriessen]
225 </p>
227 <p>
228 <strong>In gschem, more control over printed or exporting</strong>, as in CAM files a la Eagle.[CP Tarun]
229 </p>
231 <p>
232 Can be putoff and done as a <acronym title="Graphical User Interface">GUI</acronym> plugin script – a detail of easy scripting wants [JGriessen]
233 </p>
235 </div>
236 <!-- SECTION "Too Detailed" [6848-7493] -->
240 <p>
241 <strong>What kind of data structures are desirable?</strong> How would they look? [Stuart Brorson] <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]
242 </p>
244 <p>
245 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]
246 </p>
248 <p>
249 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]
250 </p>
252 <p>
253 <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?
254 </p>
256 <p>
257 <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."
258 </p>
260 <p>
261 <strong>Some work has already been done by Steve Meier</strong> to enable practical work on FPGAs.
262 </p>
264 <p>
265 <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_data_structure_design_discussion.html" class="wikilink1" title="geda:data_structure_design_discussion">data structure design discussion</a>
266 </p>
268 </div>
270 </body>
271 </html>