X-Authentication-Warning:	delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient:	geda-help AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1607765012;
	bh=TCGhJ5NTPZI+eb4PvkIGarPMXFz8nJQg3s4NNcFASco=;
	h=X-UI-Sender-Class:From:Subject:To:References:Date:In-Reply-To;
	b=C2xB4LPGlqZutZWNK1gAB4dGolATMRjdoQwJZUlwye91YeWdw8mHOz9Z3banrE3pR
	NbaqMYTzXvOwai4bbIfU36/P6VJBCa+g3STQ/YmAmh3g/PZxyaSCbMcp0BdQw9e/oB
	uCeux7O22FZ9d6oyX4HN9/P5X+J2b8X9xcw02nv8=
X-UI-Sender-Class:	01bb95c1-4bf8-414a-932a-4f6e2808ef9c
From:	"Klaus Rudolph (lts-rudolph AT gmx DOT de) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
Subject:	Re: [geda-help] using net names on multiple sub schematics used by
	single symbol
To:	geda-help AT delorie DOT com
References:	<c6376b29-a72c-6ae0-1b39-081ecb97ec1c AT gmx DOT de>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012041901490 DOT 1174 AT nimbus>
	<3e21c34b-571c-8762-7e68-f096bcf10a37 AT gmx DOT de>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012081605590 DOT 1246 AT nimbus>
	<20201209082005 DOT 8890C8512092 AT turkos DOT aspodata DOT se>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012091338400 DOT 1205 AT nimbus>
	<ce08e8ac-cdc1-9ed4-420a-c52a750baa3c AT gmx DOT de>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2012111629350 DOT 12695 AT nimbus>
Message-ID:	<bb2887ac-06cb-1d7f-ff3f-a73c8b0bf8b4@gmx.de>
Date:	Sat, 12 Dec 2020 10:23:30 +0100
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
	Thunderbird/78.5.0
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.21.2012111629350.12695@nimbus>
X-Provags-ID:	V03:K1:WHLgkEIZ0S/lgaIRaTP2zTXa4hv2C04To06aBkhWzXbV9wDDs6t
	8xc7jviO55xqx86ec57WdQZsTAzTrOu1+miaM5fkNbAY/E0yKGaSE2wVDfURccPtCWeSQiF
	kHDqNgn5eJxae66/7Z75Y2VV/mtG6HVbU0XYYENygLjre1DdCI2IyKcEXp/ePKG8I1KBtfd
	+62xEsuS2uzjKDYnKUCRQ==
X-Spam-Flag:	NO
X-UI-Out-Filterresults:	notjunk:1;V03:K0:4wk6MhC4Djc=:5yydaX5JdI3QwoKO63vGLP
	OodewqW5li2hnwPeVZFL0B1Al7xX6iFRKPAfEmTU5yqnewkkyIcL5MpxanhKOlbZAIIBPx8MU
	QdbCTUuKltIOLqw3njlc88NodRc69qpsAYRgUNB9zHEaLNhwQz7WWSv+QxD9hOe+1ji4npwTP
	tSpI/OckY1Qzh8t+oFFCExTXgEBjnI9fklhNvr3uPDl3ylR4QIFT4EW1cDNzdHTM6AY6yPZiA
	BSmk7UZ/C5VYrUvOgG7lm3uA9KQY6iKZg4oF353O2U1/MA7FPEZNaNbVoXZYGNLONokNOqXrp
	rA6ZPFnZNujDeBLEtbqeyYat9IeHN6615Qw9sViCbc6Q0QOO9FXfKdRruJR4dWHOw5UZtottz
	Prr8+BWQJOXCPvgs6VcgamG7gH8km/7uyQj1tq0TLVfFSuHasrj4r49usKXP/5WeCUycUTjXe
	tObO0OIjIEB5yyBzmaSgR7iDf5nhZsZU7rql58XHRVnMmr4lQqBujd/4tO1ol+lzcWaLtzq72
	6OxbvZrluQUVKruCjHVAI+9yN8vJeOzFvGisSgpqMHXEIreyzCRUhh71NVoFHBWgtKo+Xukfa
	6IH0KzK1jnMCSx7t/5hMt/7veBHtc+VkUeulSBAZP9OKLpbCzi+3itqDSROIp19a8L4Mw6eZ5
	aZFemZtPgiIxhVEu1u7Xp4NRPC+dO8cKxLHKHBppSHeeqS+wKSWyjPUL6G6XDYkzuX7qJjn90
	fHGsbCf3qxP4/XaD45008dESdU0DmIdTOPelb/lrf+5usmsk8jkuBTh40/XDjVXyrOW9RBMls
	3omFMWiP4wzN1cKMg1zusl/cOedLlKfXqhIFj5sTkxoQpfn696OtG5r0keglXBO60+SuMa8oV
	MFQkhOKrxg1HQo4g5vrg==
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id 0BC9O7LU030339
Reply-To:	geda-help AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-help AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Am 11.12.20 um 16:42 schrieb Roland Lutz:

> ... the part behind the
> colon is (always) a list of pinnumbers in the symbol which should be
> internally connected to the net named before the colon.

OK! That was a big misunderstanding on my side. And this makes the
things much clearer. It seems I have to go again through the docs :-)

>
>> Than I learned that I use portname=xyz instead of refdes=xyz. OK, that
>> sounds better, as refdes should be refdes and not a net connection. OK!
>> But the wiki and other documentation did not know about and only
>> describes the refdes=xyz attribute. That is very bad!
>
> That's still valid, but I agree that it would be a good idea to update
> these resources to use the newer convention.

... and maybe add a "deprecated" warning while processing these kind of
schematics?


>
>> Next problem I see is, that there is simple way for connections between
>> different levels of hierarchy for sub/master schematics. It is a typical
>> use case that we have at minimum the power rails connected between the
>> hierarchy, but there is no way to make such nets "global" while other
>> nets are local to their hierarchy level.
>
> The problem here is that you want to do two conflicting things at the
> same time: on the one hand, separate subschematics from the embedding
> schematic by using different refdes/netname namespaces, and on the other
> hand, have things implicitly connected.  gEDA/gaf allows you very
> precise control over *how* these namespaces are separated; how you use
> that to achieve your goals is up to you.

> "implicitly connected."

No! I want an explicit access on the namespace. Every level of hierarchy
should be seen as local, but each of these level should be in some way
*explicit* addressable but giving additional information in some syntax
to the name of the net. Something like net=<upper>#<some_net_name> or
"net=<global>#<some_net_name> " whatever syntax you like.

>
> I prefer using completely separated namespaces (all three of refdes=,
> netname=, and net= mangling enabled) and connecting things explicitly,
> i.e., having a "GND" and a "Vdd" port and connect these to power symbols
> both on the embedding schematic and the subschematic.  This way, I know
> there are no implicit connections which are not visible in the schematic.
>
> If you prefer to have implicit connections, you basically have two
> options: disable net= mangling and have all implicit pins connect to
> top-level nets (e.g., net=GND:1 always connects to the global GND), or
> disable netname= mangling and have all netname= attributes connect to
> global nets (which connects your virtual power pins inside the subsheet
> but allows you to explicitly connect nets via e.g. netname=GND).

But these are global flags for all or nothing. This is not what I search
for :-)

>
>> In connection with my points above, I dislike the "netname" attribute,
>> as it also breaks the naming conventions for "is a line on a bus".
>
> Isn't it the reverse?  If I understand you correctly, you are unhappy
> about the syntax of net= attributes being too similar to the bus syntax
> used in other places; using the netname= would avoid that ambiguity.

This was based on my misunderstanding that we sometimes single wires on
a bus adressed and sometimes the pin number. That you already have
clarified! Thanks!


>
>> In addition, a symbol which is used for hierarchical designs ( contains
>> source= attribute), can have something like:
>> connect=<netname_here>:<netname in subschem>
>
> That should be doable, even though it's way too implicit for my taste.

Giving two explicit names is to implicit? Mater of taste I believe. If
something like this will be implemented, it is an addition only and will
not disturb anything. If someone else like the idea? Don't know. Up to
now I am able to do my work and having the unconnected pins in the
schematic by giving net= attributes in the symbol to connect to sub
schematic is my only concern. As this: Everything works!

>
>> If now net and bus has a given defined syntax, all the above could also
>> be used to directly connect a bus to a sub schematic which is currently
>> impossible.
>
> Buses are currently purely decorative; connecting them to anything
> doesn't have an effect.

But it would be nice if buses can be used as nets. Connecting them via a
element ( maybe a pin ) may connect the whole bus to the sub schematic.
If you have a design with some address and data bus and you can simply
connect all your sub schematic peripherals with the pins would be nice.
I am currently did not have such jobs to realize, but it looks "natural"
to me. Maybe we can define a "bus" element instead of the "pin". But
this is also matter of taste. The first one makes it clearer I believe
and we don't run in the syntax trouble for wires on buses vs net and pin
number.

Thanks
  Klaus

- Raw text -