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=1607694995;
	bh=NuhYAGbtNy6ujII/55FQk+fyHreeC3SJxDMKYziiSDQ=;
	h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To;
	b=c9YBcGFTmzCVUGIURoELaTUUe2bTifVHaTS3cFjWvC2v4/lcbqX/JFlOPqxZ2P1U8
	a/EnM8K0iLu1sumnoG0iawGy7IFbkvNeyIJzrkKyB8Wv1zqe124hWQaED3jGIehLde
	kWWChm36QT1iNsyyTQ3xRzE0vss2JfL55Cysq8ds=
X-UI-Sender-Class:	01bb95c1-4bf8-414a-932a-4f6e2808ef9c
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>
From:	"Klaus Rudolph (lts-rudolph AT gmx DOT de) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
Message-ID:	<ce08e8ac-cdc1-9ed4-420a-c52a750baa3c@gmx.de>
Date:	Fri, 11 Dec 2020 14:56:32 +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.2012091338400.1205@nimbus>
X-Provags-ID:	V03:K1:rcWuJSVdaAwcU0Hno6yN8eniASvcyw9aNsJfs96xwBLUj6rMBfH
	B4RYVRzedFs89y8OxdRThGNxuF8OrVrJKY/SbmKAQcSysYtAe4eQSr6CDMFzivtVuLq+NK3
	moLtJKSKs+1ORAlQKFpGvdyohEVrBvF7/EW1aKTcwJZefKTWet2qp/4pfVGwgNWJu1IVikB
	VG+mh1QFDCiQBgSaJ61iQ==
X-Spam-Flag:	NO
X-UI-Out-Filterresults:	notjunk:1;V03:K0:jUh81EQPoIs=:qLhNvTOLjN/gKGQVA65qmp
	PgG68eFtsScYP1O3Uku5F4q7B93Hcth0bbw3n9RuNIwIem2tM/Br57pGLEseq1fFRcJ+op1l1
	c4Fokb34IfDAjYHX7AqmX27SJLMbg/wLRlYbC98fGh+b/sm35FnAzjbpz7cMxGF7yPAcPN5rl
	VA+K5C0IlhNf+PuAQ349P+6ZVQRixlKGP9FJ7pYA5Qti/KELYqUuM77RZMfMlP6b00RfHhDTc
	YgO0Jj+WgMsXyRzJhtFtd6mz6W2gBeuDusRgkCK9ZAU9cCWZRGsCo0F+6O3Eet3KOi8JCVYt1
	53Hr43p15OFCpY1lGGKSUKEM9K42oA1CtbtnFxQfxRQEOx+zpkht3Z0Ereek9hgoz94a6YQKS
	KccV5Ud1aw+QBfm6YUUyhik4VwIB5RZ1bJYHdL6P64bqmQKFvTVOhI2YjIm86/aABnamqyT0v
	TzW96Lf3aCEz5jIaIxSwvURgxAs6dFXNKY+fGYGmU0ybwvvLC3HZvx4SBhoj8QdovaBBdBGsw
	pJxxhtzntiaM+yicWDGrO+jp1mghOnMqOBbzSlanin+WdF8fWhxPjPPKvJz8SkpK0TvwlI2Er
	78a+Uk5m6cjDzVItpCX+oPukfQ/oMPd5HMh4b/bvl1H8PzocQRfRGog8jTfZPMANUxropghBR
	bENaoANtF3IACHr9V1c5YCX/QL7tsTXK3KQjwshj9ZxgkiaK+8uWoky0aOoHLd7M3VLhvmww8
	h5oL99QSdjnBTB8orBkYIKnv5IYkMbOPrLHJOdGlhJh7kvNn/5Swp7UFovmAvZa+aMW7z6WJX
	uqpXR7/alJbA5jlby7M8olz10qKJe1RRnhv6VigYjVPYztqbFwAVx7fd4L/3v4o3QoIUcyeZS
	8Kdy6auTh0Kau5f6qORQ==
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id 0BBDvRZv006281
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 09.12.20 um 14:08 schrieb Roland Lutz:
> Hi Karl,
>
> On Wed, 9 Dec 2020, karl AT aspodata DOT se [via geda-help AT delorie DOT com] wrote:
>> All thoose things with net/netname/portname is simply confusing,
>> why not only use one attribute name for all this ?
>
> a net name is a conceptually different thing from an I/O port.  (That
> said, it may actually be a good idea to change that.  Hmm.)
>
>> Also confusing if the talk about "power symbols". It is all about
>> some named net, which is useful for power nets _among other forms of
>> nets_.
>
> That's true, sorry about the unfortunate choice of words.


I have a general problem of understanding the syntax for nets and net
attributes.

Somewhere we see that "net=xyz:1" defines a line on a bus which is names
xyz and this is the line number 1 on that bus. Per definition all and
everything is a bus and not a net. OK, if so, no problem.

BUT:
If we now take a look on symbols which are used in connection with the
"source=sub.sch" to use sub schematics, the symbol can take also
attributes "net=xyz:1" where now xyz is a busname which line defaults to
1! Scarry! The 1 in the net attribute here refers to the pin number and
NOT to the line on the bus. That is totally confusing and did not work
in the moment, you want to use an other line as #1 from a bus.

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!

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.




>
>> Why not get rid of the "netname attribute attached to a net", since
>> you can simply attach a net symbol instead to get the same thing ?

Absolutely agree! Dealing with netname is very unhandy, especially
because a netname will gone by accident  without any notice. It is much
clearer to use connected Symbols with their net attribute.

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".

>> Regarding the ugly ":1", cannot a missing :<number> just default to :1
>> (this has been up to discussion before) ?

Ugly or not, it was the convention sometimes ago and is now more or less
complicated by additional attributes which do not use the line number of
a bus. Even if it looks nicer it breaks the earlier conventions.

>> Regarding portname, I have not heard about it before but I can find it
>> in http://wiki.geda-project.org/geda:symbols,
>> <<
>> I/O port symbols
>> Subschematics are hooked up to the schematic from which they are
>> instantiated via port symbols. Instead of a refdes= attribute,
>> port symbols have a portname= attribute; for each pin on the
>> subschematic symbol, there should be exactly one I/O port in
>> the subschematic whose portname= attribute matches the pinlabel=
>> attribute of the pin. Port symbols mustn't have a pinnumber=
>> attribute on their own pin.


That is, for my point of view, unhandy.

It will result in having a lot of symbols only because you need a
different amount of pins inside. That fits well as long you want to
connect each of the pins in the master schematic to get the connection
to the sub schematics. But this is not longer nice if you want to
connect a (longer) list of signals only by name, which is currently done
with "net:<pinnumber" attribute. At the end you have a symbol with a lot
of visual unconnected pins which looks ugly.

But at all, everything works even if it is not the perfect world :-)


If someone would start from scratch and must define something new, I
would recommend:

I unique syntax for net, bus and connection.
In addition, some syntax for something like a "namespace".

A net, for example, will not longer have :1, as it is already a single
"wire".

By introducing namespaces, a user will be able to define something like:

"my_global:power+15v" and use this net description also in sub schematics.

It would then also be possible, to define some "automatic" namespaces,
like <upper>:somename, which connects from a sub schematic to the next
higher level in the hierarchy to the net with the name "somename". Quite
easy without going over net=name:pin -> pin with pinlabel -> port +
portname.

In addition, a symbol which is used for hierarchical designs ( contains
source= attribute), can have something like:
connect=<netname_here>:<netname in subschem>

This makes it possible to connect named nets/ nets with added symbols
with net= attribute directly.

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.

Only my two cent :-)

Klaus

... but as said: Everything works, it has its history and all of my
thoughts are not in the intend of blaming at all. geda is a great suite
of progs which enable us to do electronic designs. I am very thankful to
have all these tools on hand! Especially the very simple text formats of
all the tools data files enables so much scripting which is much more
powerful as all other tool suites I know!

- Raw text -