This shows you the differences between two versions of the page.
|
gnucap:user:netlist_import_and_export [2025/04/02 21:37] aldavis [PC boards] |
gnucap:user:netlist_import_and_export [2025/04/29 09:00] (current) felixs fix typo in Non-circuit items |
||
|---|---|---|---|
| Line 161: | Line 161: | ||
| module amp (.a(a0), .c(c0)); | module amp (.a(a0), .c(c0)); | ||
| + | ground gnd; | ||
| resistor #(.r(1k)) r1 (.p(a1), .n(b1)); | resistor #(.r(1k)) r1 (.p(a1), .n(b1)); | ||
| resistor #(.r(1k)) r2 (.p(b2), .n(c2)); | resistor #(.r(1k)) r2 (.p(b2), .n(c2)); | ||
| - | opamp741 #(.gain(100k)) u1 (.p(c3), .n(0), .ps(0), .pn(b3)); | + | opamp741 #(.gain(100k)) u1 (.p(c3), .n(gnd), .ps(gnd), .pn(b3)); |
| net a (a0, a1); | net a (a0, a1); | ||
| Line 180: | Line 181: | ||
| This definition gives us up to 6 connections (a,b,c,d,e,f) as seen from outside, all connected together internally, which has the effect of collapsing it all down to one. | This definition gives us up to 6 connections (a,b,c,d,e,f) as seen from outside, all connected together internally, which has the effect of collapsing it all down to one. | ||
| + | |||
| + | ==== The "rail" device ==== | ||
| + | |||
| + | We use rail devices with a single port to make connections to designated circuit nodes, possibly across hierarchy. This removes the need for "global" nodes, which are known from Spice and prone to error. | ||
| + | |||
| + | module amp(.a(a0), .c(c0), .vdd(vdd)); | ||
| + | [..] | ||
| + | electrical vdd; // rvv connects to here. | ||
| + | rail #(.node("vdd")) rvv(vv); | ||
| + | op #(.gain(100k)) u1 (.p(c3), .n(nn), .ps(b2), .pn(b3), .vdd(vv), .vss(nn1)); | ||
| + | rail #(.node("gnd")) rg1(nn); | ||
| + | rail #(.node("gnd")) rg2(nn2); | ||
| + | net nn(nn1, nn2); | ||
| + | [..] | ||
| + | endmodule | ||
| + | |||
| + | module top(); | ||
| + | ground gnd; // <= a0.rg1 and a0.rg2 connect to here. | ||
| + | amp a0(a, b, v); | ||
| + | [..] | ||
| + | endmodule | ||
| + | |||
| + | A possible rail implementation may look like this | ||
| + | |||
| + | module rail(n); | ||
| + | electrical n; | ||
| + | parameter string node = "(nothing)"; | ||
| + | analog initial begin | ||
| + | if(!$analog_node_alias(n, node)) | ||
| + | $error("dangling rail, cannot find %s\n", node); | ||
| + | end | ||
| + | endmodule | ||
| + | |||
| + | The rail connects to the node of the given name found by upwards traversal through the hierarchy. In particular, a rail does not create a node. | ||
| ==== Verilog "system" parameters ==== | ==== Verilog "system" parameters ==== | ||
| - | The Verilog standard defines some "system" parameters for all devices to show position. | + | The Verilog standard defines some "hierarchical system parameters" (HSP) for all devices to show position. |
| * $xposition (x coordinate, in meters) | * $xposition (x coordinate, in meters) | ||
| Line 190: | Line 225: | ||
| * $vflip (flag: flip vertically, +1=no flip, -1=flip) | * $vflip (flag: flip vertically, +1=no flip, -1=flip) | ||
| - | These "system" parameters are real parameters, so we won't use them here. We will use them as inspiration for "attributes" instead. | + | These HSPs are real parameters, i.e. carry a physical meaning. Hence we will not use them to store schematic markup. We will use them as inspiration for positioning "attributes" instead. |
| + | |||
| + | HSPs will generally be treated as ordinary parameters, but are subject to special semantics that attributes are not meant to carry. For backwards compatibility, all parameters with a name starting with '$' must be passed on like attributes and without interpretation where they have no meaning. | ||
| + | The current standard misses out on HSPs that correspond to global options in legacy tools. In the future, HSPs such as $temperature, $dtemp, $method or $mode should be supported to localise such global options as required, but without workarounds. | ||
| ==== Verilog "attributes" ==== | ==== Verilog "attributes" ==== | ||
| - | The Verilog standard gives a way to add "attributes" to just about anything. | + | The Verilog standard gives a way to add "attributes" to just about anything. We are referring to |
| + | //a mechanism [..] included for specifying properties about objects, statements and groups of statements in the HDL | ||
| + | source that can be used by various tools// in IEEE1364 Section 3.8. | ||
| (* attribute = value *) resistor r1 (.p(2), .n(3)); | (* attribute = value *) resistor r1 (.p(2), .n(3)); | ||
| Line 339: | Line 379: | ||
| In addition to this, nearly all schematics have text or drawings that are not part of the circuit. In this case use a dummy device, with type name beginning with the prefix. For text, the position is the point where the base line begins. | In addition to this, nearly all schematics have text or drawings that are not part of the circuit. In this case use a dummy device, with type name beginning with the prefix. For text, the position is the point where the base line begins. | ||
| - | (* S0_x=1.5u SO_y=1.5u S0_text="This is some text" *) S0_text; | + | (* S0_x=1.5u S0_y=1.5u S0_text="This is some text" *) S0_text; |
| ==== PC boards ==== | ==== PC boards ==== | ||
| Line 360: | Line 400: | ||
| This method could apply to chip layout too, but requires more study, because the symbol/footprint concept is not used in chip layout, and what you can do is more tied to process specifics. | This method could apply to chip layout too, but requires more study, because the symbol/footprint concept is not used in chip layout, and what you can do is more tied to process specifics. | ||
| + | |||
| + | ==== Examples ==== | ||
| + | |||
| + | - [[gnucap:user:netlist_import_and_export:geda|gEDA/Lepton schematics]] | ||
| + | |||
| + | - [[gnucap:user:netlist_import_and_export:qucs|Qucs (reworked) schematics]] | ||