docs/wiki/geda_data_structure_design_discussion.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
   4  lang="en" dir="ltr">
   5 <head>
   6   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   7   <title>geda:data_structure_design_discussion</title>
   8 <meta name="generator" content="DokuWiki Release rc2007-05-24" />
   9 <meta name="robots" content="index,follow" />
  10 <meta name="date" content="2007-05-24T22:27:27-0400" />
  11 <meta name="keywords" content="geda,data_structure_design_discussion" />
  12 <link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
  13 <link rel="start" href="http://geda.seul.org/wiki/" />
  14 <link rel="contents" href="http://geda.seul.org/wiki/geda:data_structure_design_discussion?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:data_structure_design_discussion" />
  18 <link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:data_structure_design_discussion" />
  19 <link rel="stylesheet" media="all" type="text/css" href="lib/exe/css" />
  20 <link rel="stylesheet" media="screen" type="text/css" href="lib/exe/001css" />
  21 <link rel="stylesheet" media="print" type="text/css" href="lib/exe/002css" />
  22 </head>
  23 <body>
  24 <div class="dokuwiki export">
  25 <div class="toc">
  26 <div class="tocheader toctoggle" id="toc__header">Table of Contents</div>
  27 <div id="toc__inside">
  28
  29 <ul class="toc">
  30 <li class="level1"><div class="li"><span class="li"><a href="#data_structure_design_discussion" class="toc">Data structure design discussion</a></span></div></li>
  31 <li class="level1"><div class="li"><span class="li"><a href="#concept_diagram" class="toc">Concept diagram</a></span></div>
  32 <ul class="toc">
  33 <li class="level2"><div class="li"><span class="li"><a href="#concepts_behind_the_structures" class="toc">Concepts behind the structures</a></span></div>
  34 <ul class="toc">
  35 <li class="level3"><div class="li"><span class="li"><a href="#design" class="toc">Design</a></span></div></li>
  36 <li class="level3"><div class="li"><span class="li"><a href="#circuit" class="toc">Circuit</a></span></div></li>
  37 <li class="level3"><div class="li"><span class="li"><a href="#mport" class="toc">MPort</a></span></div></li>
  38 <li class="level3"><div class="li"><span class="li"><a href="#instance" class="toc">Instance</a></span></div></li>
  39 <li class="level3"><div class="li"><span class="li"><a href="#attrib" class="toc">Attrib</a></span></div></li>
  40 <li class="level3"><div class="li"><span class="li"><a href="#netlist" class="toc">Netlist</a></span></div></li>
  41 <li class="level3"><div class="li"><span class="li"><a href="#net" class="toc">Net</a></span></div></li>
  42 <li class="level3"><div class="li"><span class="li"><a href="#page" class="toc">Page</a></span></div></li>
  43 </ul>
  44 </li>
  45 </ul>
  46 </li>
  47 <li class="level1"><div class="li"><span class="li"><a href="#brainstorms" class="toc">Brainstorms</a></span></div></li></ul>
  48 </div>
  49 </div>
  50
  51
  52
  53 <h1><a name="data_structure_design_discussion" id="data_structure_design_discussion">Data structure design discussion</a></h1>
  54 <div class="level1">
  55
  56 </div>
  57 <!-- SECTION "Data structure design discussion" [1-48] -->
  58 <h1><a name="concept_diagram" id="concept_diagram">Concept diagram</a></h1>
  59 <div class="level1">
  60
  61 <p>
  62  (Inspired by gnetman, by Bill Cox)
  63 </p>
  64
  65 <p>
  66 <a href="http://geda.seul.org/wiki/lib/exe/fetch.php?cache=cache&media=http%3A%2F%2Fwww2.eng.cam.ac.uk%2F%7Epcjc2%2Fgeda%2Fdatastructures.png" class="media" title="http://www2.eng.cam.ac.uk/~pcjc2/geda/datastructures.png"><img src="http://geda.seul.org/wiki/lib/exe/fetch.php?w=&h=&cache=cache&media=http%3A%2F%2Fwww2.eng.cam.ac.uk%2F%7Epcjc2%2Fgeda%2Fdatastructures.png" class="media" alt="" /></a>
  67 </p>
  68
  69 </div>
  70 <!-- SECTION "Concept diagram" [49-178] -->
  71 <h2><a name="concepts_behind_the_structures" id="concepts_behind_the_structures">Concepts behind the structures</a></h2>
  72 <div class="level2">
  73
  74 </div>
  75 <!-- SECTION "Concepts behind the structures" [179-222] -->
  76 <h3><a name="design" id="design">Design</a></h3>
  77 <div class="level3">
  78
  79 <p>
  80  This is might not exist as a “file”, as such, but exists as a data structure entity to be the owner of the circuits required in a particular design. The “root circuit” is the uppermost level of hierarchy.
  81 </p>
  82
  83 </div>
  84 <!-- SECTION "Design" [223-446] -->
  85 <h3><a name="circuit" id="circuit">Circuit</a></h3>
  86 <div class="level3">
  87
  88 <p>
  89  A <strong>circuit</strong> entity is the key concept in this model. It defines an electrical block by a its external connections (<strong>MPort</strong>s). A schematic is one way of representing a circuit, hence a circuit object may own or more <strong>page</strong> of schematics.
  90 </p>
  91
  92 <p>
  93 We may also define a <strong>symbolic</strong> (graphic) representation of a circuit - this is like a schematic <strong>page</strong>, however its representation should fit within a single sheet. The minimum a symbolic representation must contain is the <strong>pins</strong> which connect it to higher levels of circuit hierarchy.
  94 </p>
  95
  96 </div>
  97 <!-- SECTION "Circuit" [447-1004] -->
  98 <h3><a name="mport" id="mport">MPort</a></h3>
  99 <div class="level3">
 100
 101 <p>
 102  If it is to be useful as a re-usable block, a sub-<strong>circuit</strong> must expose electrical connectivity for a parent <strong>circuit</strong> to connect with. Each such connection is represented by an <strong>Mport</strong> (Master port). This term (re-used from gnetman) represents the fact that once a circuit is instantiated, we need to differentiate between the connections of each specific instance. This is done with instance specific <strong>Port</strong> structures. The <strong>port</strong>s point back at the <strong>Mport</strong>s (master ports) of the circuit representation.
 103 </p>
 104
 105 </div>
 106 <!-- SECTION "MPort" [1005-1541] -->
 107 <h3><a name="instance" id="instance">Instance</a></h3>
 108 <div class="level3">
 109
 110 <p>
 111  A <strong>circuit</strong> represents a re-usable electrical entity which we may replicate at various points in our design hierarchy. This is done by instantiating the sub-<strong>circuit </strong> in a higher level of hierarchy. Each instance is associated with an <strong>Instance</strong> structure, which is a placeholder for instance specific attributes such as the sub-circuit’s hierarchical refdes.
 112 </p>
 113
 114 </div>
 115 <!-- SECTION "Instance" [1542-1929] -->
 116 <h3><a name="attrib" id="attrib">Attrib</a></h3>
 117 <div class="level3">
 118
 119 <p>
 120  An <strong>Attrib</strong> defines meta-data attached which might be attached to a <strong>circuit</strong>, a <strong>circuit</strong>‘s <strong>Mport</strong>, a specific <strong>circuit</strong> <strong>instance</strong>, or a <strong>Net</strong>.
 121 </p>
 122
 123 <p>
 124 In a break from gEDA’s current <strong>attrib</strong> model, it makes sense to associate the meta-data directly with the particular entity it pertains to, rather than the graphic representation. This is because some forms of sub-<strong>circuit</strong> entity may be defined without a schematic, and could still require this meta-data. It will be possible to reference any <strong>attrib</strong> within the realm of a <strong>circuit</strong> for display on its schematic <strong>page</strong>(s) where that is desired.
 125 </p>
 126
 127 </div>
 128 <!-- SECTION "Attrib" [1930-2569] -->
 129 <h3><a name="netlist" id="netlist">Netlist</a></h3>
 130 <div class="level3">
 131
 132 <p>
 133  A <strong>Netlist</strong> defines the electrical connectivity of a <strong>circuit</strong>. It owns a number of <strong>Net</strong>s, which individually represent a single connection between <strong>Mport</strong>s belonging to this <strong>circuit</strong>, and <strong>ports</strong> of instantiated sub-<strong>circuits</strong>.
 134 </p>
 135
 136 <p>
 137 Initially, it is likely there will only be one netlist for a <strong>circuit</strong> - the one constructed from processing the electrically relevant objects on <strong>page</strong>(s) of the <strong>circuit</strong>‘s schematic.
 138 </p>
 139
 140 <p>
 141 Future developments may see multiple netlists for a circuit, possibly some generated / written in an HDL language, and critically, re-exported from a layout package (e.g. PCB). It will be possible to identify and flag up differences in connectivity throughout a design flow, be that from HDL to schematic, or schematic to layout.
 142 </p>
 143
 144 <p>
 145 This has real applications in back-annotation and in design verification.
 146 </p>
 147
 148 </div>
 149 <!-- SECTION "Netlist" [2570-3435] -->
 150 <h3><a name="net" id="net">Net</a></h3>
 151 <div class="level3">
 152
 153 <p>
 154  A <strong>net</strong> associates with structures forming a given electrical connection within this <strong>circuit</strong>.
 155 </p>
 156
 157 <p>
 158 As we also have a graphical representation of the wires (<strong>ConnSegment</strong>s) which make up this connection, each <strong>Net</strong> can be associated with multiple <strong>ConnSegment</strong>s. The association to <strong>Pins</strong> representing <strong>Mport</strong>s of this <strong>circuit</strong> and to the <strong>Pins</strong> of any instantiated sub-<strong>circuits</strong> is made via a <strong>net</strong>‘s association to the appropriate <strong>Mport</strong> and <strong>port</strong> structures.
 159 </p>
 160
 161 </div>
 162 <!-- SECTION "Net" [3436-3940] -->
 163 <h3><a name="page" id="page">Page</a></h3>
 164 <div class="level3">
 165
 166 <p>
 167  A <strong>page</strong> is a canvas for placing graphical objects representing a circuit. A <strong>page</strong> can be used to draw an electrically meaningful schematic, or it can be used to draw a symbolic representation of the circuit entity.
 168 </p>
 169
 170 <p>
 171 Whilst most objects on a <strong>page</strong> are graphic primitives, there are some which have a relation to the <strong>circuit</strong>‘s electrical specification.
 172 </p>
 173 <ul>
 174 <li class="level1"><div class="li"> <strong>ConnSegments</strong> (or <strong>net</strong>s) represent connected electrical signals within the circuit represented.</div>
 175 <ul>
 176 <li class="level2"><div class="li"> A connectivity representation (<strong>netlist</strong>) can be built by considering the end-point positioning of these objects.</div>
 177 </li>
 178 <li class="level2"><div class="li"> <strong>ConnSegment</strong> is intended to be a generalisation of <strong>net</strong>s and <strong>bus</strong>es for the purpose of this diagram.</div>
 179 </li>
 180 </ul>
 181 </li>
 182 </ul>
 183 <ul>
 184 <li class="level1"><div class="li"> <strong>Pins</strong> represent a connection outside this circuit.</div>
 185 <ul>
 186 <li class="level2"><div class="li"> When constructing a netlist, coincidence of a <strong>ConnSegment</strong> end on these implies an electrical connection to that external port.</div>
 187 </li>
 188 <li class="level2"><div class="li"> Each <strong>pin</strong> (or group of pins?) represent an external electrical connection with this <strong>circuit</strong>.</div>
 189 </li>
 190 <li class="level2"><div class="li"> There is a necessary link between a <strong>pin</strong> and the circuit’s <strong>Mport</strong> which it represents.</div>
 191 </li>
 192 </ul>
 193 </li>
 194 </ul>
 195 <ul>
 196 <li class="level1"><div class="li"> <strong>complex</strong> objects represent instantiating a sub-<strong>circuit</strong>, and will be linked to a specific <strong>instance</strong> structure.</div>
 197 <ul>
 198 <li class="level2"><div class="li"> Graphically, this means a <strong>symbolic</strong> representation of the instantiated circuit will be placed on the page.</div>
 199 </li>
 200 <li class="level2"><div class="li"> Nets ending co-incident with the <strong>pins</strong> of that embedded symbol represent electrical connectivity with the instantiated sub-<strong>circuit</strong> entity.</div>
 201 </li>
 202 </ul>
 203 </li>
 204 </ul>
 205
 206 </div>
 207 <!-- SECTION "Page" [3941-5460] -->
 208 <h1><a name="brainstorms" id="brainstorms">Brainstorms</a></h1>
 209 <div class="level1">
 210
 211 <p>
 212  (from conversation on MSN/<acronym title="Internet Relay Chat">IRC</acronym> on 10th April 2007 &ndash; Peter Brett / Peter Clifton)
 213 </p>
 214 <ul>
 215 <li class="level1"><div class="li"> In order to do back annotation, need to be able to change the board part references for anywhere in the schematic.  It then makes sense to dissociate the concepts of <strong>InstanceID</strong> and <strong>Board Reference</strong>, and use an <strong>override table</strong> that can override an attribute at any given path within the current <strong>circuit</strong> based on a path composed of <strong>InstanceID</strong>s.  <strong>InstanceID</strong>s would be special-cased throughout libgeda as a means for uniquely identifying circuits and instances.  An entry in the override table might have the form &quot;/id1/id2/id3:refdes:U3”</div>
 216 </li>
 217 </ul>
 218 <ul>
 219 <li class="level1"><div class="li"> It might be useful to allow nets to have attributes, for instance to specify minimum copper width and spacing for a net, independently from the attributes of net segments.</div>
 220 </li>
 221 </ul>
 222 <ul>
 223 <li class="level1"><div class="li"> The schematic editor needs to have sidebars for browsing hierarchy and inspecting attributes.  This needs to include a way of seeing where the attributes have been inherited from.</div>
 224 </li>
 225 </ul>
 226 <ul>
 227 <li class="level1"><div class="li"> We need to do lazy netlisting, on a circuit-by-circuit basis &ndash; the netlists should only be combined into a flat netlist when required by a tool (and even then, most tools can potentially make good use of hierarchy information).</div>
 228 </li>
 229 </ul>
 230 <ul>
 231 <li class="level1"><div class="li"> In order to make finding objects by hierarchical path fast (e.g. to implement override tables discussed above) there needs to be a fast way of generating unique identifiers for objects (e.g. 32-bit ints) that can then be used as keys in hashtables.</div>
 232 </li>
 233 </ul>
 234
 235 </div>
 236 <!-- SECTION "Brainstorms" [5461-] --></div>
 237 </body>
 238 </html>