X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 3 Apr 2017 09:06:50 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] [dev] Gnucap and Google summer of code. In-Reply-To: <20170403015521.7f0c4509@floyd.freeelectron.net> Message-ID: References: <20170330125608 DOT 7d04622a AT floyd DOT freeelectron DOT net> <20170402235928 DOT 7143c5f4 AT floyd DOT freeelectron DOT net> <20170403015521 DOT 7f0c4509 AT floyd DOT freeelectron DOT net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 3 Apr 2017, al davis wrote: > On Mon, 3 Apr 2017 06:30:21 +0200 (CEST) > gedau AT igor2 DOT repo DOT hu wrote: > > For a complex net, encapsulate it: > > module net123 (a, b, c); > net #(.width(.5m)) aaa01 (aaa1, aaa2); > net #(.width(1.0m)) aaa02 (aaa2, aaa3); > place (.$xposition(0), .$yposition(0m) place_aaa1 (aaa1); > place (.$xposition(0), .$yposition(8m)) place_aaa2 (aaa2); > place (.$xposition(10m), .$yposition(8m)) place_aaa3 (aaa3); > // etc .. > endmodule > This seems to be implementable in a few hours on pcb-rnd side. >> And the good old question remains: what software would convert the pure >> geometry to a netlist, extracting all the capacitance, resistance, etc. >> values? Or is this the part the SoC project is for? > > One thing at a time .. > > For the first step, get it so the wires go point to point, with the > correct end points. Then we will fill in the parameters. I agree to split up the task in small steps. However, I'd like to see a few steps forward, even if we'd implement the first step first. The reason is that I don't want to start on a road where we'd hit a road block in 2 steps. For me it's important to see who will do this part (but not when). For example if it turns out it'll be pcb-rnd that needs to handle this, I'd not start on the first step until I see someone joining the project with both expertise on this field and a lot of free time at hand. If you say this part will be handled by gnucap, or by some 3rd party tool, then I am fine with implementing the exporter as the first step, knowing this part will be done in a subsequent step. Similar questions for the same reason; I only need to know if you have plan for these, not the detailed specifications yet: 1. Trace arc; this seems like a simple extension to the linear traces 2. Copper polygons that are part of the net. Polygons are very often mixed with lines and arcs, especially on "power planes" sharing a single layer (e.g. 1 or 2 layer boards). Are there provisions for complex nets with lines, polygons and arcs? 3. 3rd party copper polygons around our current net on the same layer; typical for a signal crossing a power gnd plane on a layer (the polygon has a clearance cutout around the trace); I can export the polygons with their final (complex cutout) shapes, so geometrically there wouldn't be a short between the nets of the trace and the polygon. 4. Trace end cap; I am not sure this matters, maybe only for real wide traces and corners: most traces have round end caps in most PCB tools I've seen. 5. Trace overlap; your 'L' example showed an overlap of two traces in the corner. Will this work generally, with arbitrary amount of trace elements (lines, arcs, polygons) overlapping randomly? 6. Real low prio: polygon corners; in pcb-rnd we have sharp corners but I've seen formats that had round corners.