X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Amavis-Modified:	Mail body modified (using disclaimer) -
	mta-out04.sim.rediris.es
Date:	Mon, 19 Dec 2022 13:50:44 +0100
From:	"Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] net rules
Message-ID:	<Y6BeJHCq9ljWLOuH@lt-gp.iram.es>
References:	<20221218205934 DOT F3A2F85E2912 AT turkos DOT aspodata DOT se>
	<ee728596-cdb-3da5-2e5e-564eb7ac4bbb AT grinsen-ohne-katze DOT de>
	<20221219014740 DOT 18DEF85E2912 AT turkos DOT aspodata DOT se>
	<fc97f9d2-e838-3f56-dbe3-70b79d75256 AT grinsen-ohne-katze DOT de>
MIME-Version:	1.0
In-Reply-To:	<fc97f9d2-e838-3f56-dbe3-70b79d75256@grinsen-ohne-katze.de>
X-Proofpoint-ORIG-GUID:	X0VvvBnJNOcKoNpo_dgveK4Gt4N3gZew
X-Proofpoint-GUID:	X0VvvBnJNOcKoNpo_dgveK4Gt4N3gZew
X-Proofpoint-Virus-Version:	vendor=baseguard
	engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
	definitions=2022-12-19_01,2022-12-15_02,2022-06-22_01
X-Proofpoint-Spam-Details:	rule=outbounddefault_notspam policy=outbounddefault score=0 clxscore=1011
	phishscore=0 impostorscore=0 bulkscore=0 malwarescore=0 mlxscore=0
	lowpriorityscore=0 suspectscore=0 priorityscore=1501 spamscore=0
	mlxlogscore=992 adultscore=0 classifier=spam adjust=0 reason=mlx
	scancount=1 engine=8.12.0-2212070000 definitions=main-2212190113
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id 2BJCpU7J026441
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

	Hello,


On Mon, Dec 19, 2022 at 12:30:08PM +0100, Roland Lutz wrote:
> On Mon, 19 Dec 2022, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
> > wiki.geda-project.org/geda:gschem_ug:pins_nets_buses
> > 
> > says otherwise:
> > 
> >  Nets are made up of straight net segments, and net connections are
> >  formed either where two net segment ends meet, or where a net
> >  segment end meets a net segment midpoint.
> 
> Then the documentation is incorrect. :-/
> 
> 
> > It just sounds like an undocumented, illogical and unnecessary feature.
> 
> Unfortunately, it's a feature existing schematics may rely on.  Imagine
> someone connecting some parts of a schematic under time pressure and just
> drawing a diagonal net across the page.  If a connection happens to fall
> exactly on this net, changing gnetlist behavior would mean an incorrect
> netlist is generated for this schematic.  (I'm not saying connecting things
> this way is good practice, just people may conceivably do it.)
> 
> 
> > Just as two N's be merged to one if they can be,
> > a single N could easily be split in two when a new
> > connection is made ?
> > 
> > I suggest that nets are only made via the net endpoints.
> 
> There is something to be said in favor of this, and I wouldn't be opposed to
> changing gschem behavior so it splits slanted nets when trying to connect to
> them.  I had the impression slanted nets are a rare exception, though.  Do
> you use them on a regular basis?

I use them for two reasons:

- when I wantto mark that a connection is a sense point for example
  between the output of a voltage regulator and its feedback point.
  There I typically put a short, 45° line to make it clear that I don't
  want the net to be randomly reorganized when routing.

- when I have to swap the signals of a differential pair. This just
  takes the shape of an "X" somewhere along the path of the differential
  signals (I always keep both nets close together on the schematics).
  Very often it's for clocks where polarity doesn't matter but they turn
  out to be in the wrong order for routing.

	Cheers,
	Gabriel
 

- Raw text -