X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Thu, 16 Jul 2015 09:37:59 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Chris Smith (space DOT dandy AT icloud DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: [geda-user] Net attributes (was: The new to do)
In-Reply-To: <4DD9C29A-2105-45DC-9F17-82DA23433919@icloud.com>
Message-ID: <alpine.DEB.2.11.1507160907360.3383@nimbus>
References: <CAM2RGhQ70Pex5aNeQ86vKHc7sKf_Vpws69__CPb2QKg6fJTeHg AT mail DOT gmail DOT com> <304D9D86-3CF6-4D61-A5CA-6CE414EA0661 AT sbcglobal DOT net> <20150712224637 DOT 2d4cc2de AT wind DOT levalinux DOT org> <55A2E9B7 DOT 9040502 AT neurotica DOT com> <CAM2RGhSmFhz9=oRaaj2EDL79c5XVmeuwmX_RdLqMv0evEHCyTw AT mail DOT gmail DOT com>
 <CACwWb3DbmOZbtb9Hrp2JvvG7-toryXuequQA=YV7X6ss762zsw AT mail DOT gmail DOT com> <20150713131707 DOT GA782 AT recycle DOT lbl DOT gov> <CAM2RGhTT__nWCkA4y36rb24yT8xP=o1nR04H=DNqTJiu=naSGA AT mail DOT gmail DOT com> <55A4042E DOT 5060402 AT neurotica DOT com> <CAM2RGhS=5xq0_oN4e0M55Kor4bcnXNn3NfLvRZoi7Vw9Aq1ZXg AT mail DOT gmail DOT com>
 <55A41B30 DOT 50602 AT neurotica DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1507151114560 DOT 2113 AT nimbus> <254F9AFE-1A3E-4D88-BABF-E6E0F87A56B1 AT icloud DOT com> <1436960577 DOT 1072 DOT 6 DOT camel AT ssalewski DOT de> <EE9F72D6-E17A-4F5C-8E9E-45F12C901C9F AT noqsi DOT com> <201507151820 DOT t6FIKYME001704 AT envy DOT delorie DOT com>
 <201507152007 DOT t6FK7lv8005229 AT envy DOT delorie DOT com> <24AD56C6-B7C2-4D7E-B69A-F68DBACCBFDC AT noqsi DOT com> <4DD9C29A-2105-45DC-9F17-82DA23433919 AT icloud DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1648758483-1437030885=:3383"
Content-ID: <alpine DOT DEB DOT 2 DOT 11 DOT 1507160914500 DOT 3383 AT nimbus>
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1648758483-1437030885=:3383
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine DOT DEB DOT 2 DOT 11 DOT 1507160914501 DOT 3383 AT nimbus>

On Wed, 15 Jul 2015, Chris Smith (space DOT dandy AT icloud DOT com) [via geda-user AT delorie DOT com] wrote:
> On 15 Jul 2015, at 21:37, John Doty <jpd AT noqsi DOT com> wrote:
>> And this is exactly the problem I see. A proper general mechanism would 
>> allow one to associate *properties* with net segments, not just trace 
>> widths.
>
> Where¢s the problem that you see?  That ¡proper general mechanism¢ was 
> exactly what was being discussed: the ability to split a net into 
> segments, each of which could have generic attributes which could in 
> turn be passed on to other tools.  Trace widths was just a real-world 
> example of where this might be useful.

I currently see the problem of over-generalizing a feature on basis of a 
single application in a way that isn't helpful in other situations.  So 
IMHO, the first question which should be asked here is: what kind of 
real-world situations are there where net attributes may be helpful?

I can currently come up with the following:
   - managing voltage drop, oscillation, and heat by
     - keeping trace resistance low and
     - keeping common trace segments short, and
   - improving signal quality in differential pairs by minimizing signal
     run time differences

I'm not an electronics engineer, though, so please correct me if I got 
this wrong.

The first is actually an attribute of type "from point/pin A to 
point/pin B", the second of type "splitting a net into connected subnets", 
and the third of type "A1 to B1 relates as A2 to B2".

For the second problem, there could be an elegant solution: define a 
special attribute which marks a symbol as a "net attribute directive", 
which is similar to "graphical=1" but makes a symbol treated as a net 
segment by default.  A subnet-aware gnetlist backend could then 
differentiate between the subnets separated by the symbol.  This doesn't 
apply to the first problem, though, as it couldn't tell which of the pins 
on either side require the thick trace and which don't.

Are there other situations where net attributes may be useful?

Roland

--8323329-1648758483-1437030885=:3383--