X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 29 Apr 2017 09:59:40 +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: <alpine.DEB.2.00.1704030844310.27212@igor2priv>
Message-ID: <alpine.DEB.2.00.1704290953590.27212@igor2priv>
References: <20170330125608 DOT 7d04622a AT floyd DOT freeelectron DOT net> <alpine DOT DEB DOT 2 DOT 00 DOT 1703301916570 DOT 27212 AT igor2priv> <20170402235928 DOT 7143c5f4 AT floyd DOT freeelectron DOT net> <alpine DOT DEB DOT 2 DOT 00 DOT 1704030619050 DOT 27212 AT igor2priv> <20170403015521 DOT 7f0c4509 AT floyd DOT freeelectron DOT net>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1704030844310 DOT 27212 AT igor2priv>
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, igor__ wrote:

>
>
> 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:
>> 
>
> <snip>
>
>> 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
>> 
>
>
> <snip>
>
> 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.


Any news on this? I'm finishing the current portion of the layer rewrite 
this weekend. I could find some time on a gnucap exporter before the 
release, but I need to know the answers (especially the parameter 
extraction part) before I start.

TIA,

Igor2