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=1607782269;
	bh=qiPR3RmlQ1dt0HmO5YXaQdxnl+PAPFfy6HWe/5YrQ0k=;
	h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To;
	b=I+N8ebBqrxXS7ACtZd+Yd6mOtSeFxATwflOe5UWrYjSeAwJGNZkB9U+mqVq0Z6mgz
	 ni1vB0jrO/bKSjO/8IMIYP+OMCPHpL7MhLilCmu1JUCCX1HMX4KfHmryi+Fo3OInrO
	 oywnpEcMLaNk3VPoobumZUmJF4CIv9R7Ao6LIdHA=
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>
 <ce08e8ac-cdc1-9ed4-420a-c52a750baa3c AT gmx DOT de>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012111629350 DOT 12695 AT nimbus>
 <bb2887ac-06cb-1d7f-ff3f-a73c8b0bf8b4 AT gmx DOT de>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012121250160 DOT 1221 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: <b7d591b9-9f89-4ec6-4115-72608dec59f4@gmx.de>
Date: Sat, 12 Dec 2020 15:11:08 +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.2012121250160.1221@nimbus>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Provags-ID: V03:K1:fGHSc+AvDvG90jKfoOoGQcw6cDHHxT5d1zqrxOn/ILbEk+3GflK
 A9Rzo+lRJdHvY4+TvJgNJ9UntpHWP9xLnox05SkK5I3qFKkolcbdYg4O4hdRAaVPuMC+UaR
 FBPZ4lTomQD671UBVaYs2ziYkbNuRmmkhKVw12WJ36WLOYWWUCBgv+7qJGbTBomWDl8WibV
 BsyGn8kp/pDJoMPdHP7ZA==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:G9H0JgL6ReI=:VHG0xs6zZeDSYPbYjAsjV0
 nko5Fn5ccEyH1Ebojx9SwUa32XE89nTyyVvB+7cvpDNF8xs6nLxkVENVh6WOvr6l6sJTdxe5z
 oxDuur73gAJpQpyDclTu5EbEZg/oE0Rg3B6Szwkq17CMYfnJPyurVqkA5XHHN+hFATbcI4UOu
 UuH91SNFhoOw2vQqBjICXaXCR8CXHU1Ur/7mOXBeVgNUh7TkRPviWr4Y5Hq3hMx35i8e79EmO
 ND09C/w2X7SqMefpUmQtPkmcJOOYqW0qzjzKCTrastrBPEWQun0Ojz9gVfxP0ES7K0XWBrbup
 W18BaXNOMcoVQQqMvS7ujtLuujm+H7kBR815Sz4Utmd/RWKPG7WEIEwE4p53vcd4UX1lVozoo
 WBoGLatWnTLk5xXgZuutZy2ksXd+KyCof06Cg1YiguuFo3tJ0ZMFun0TdlwJgcgAAxi/KkaZC
 kviKnc4DyuGgkZGhqbl6fR0LD/RQ9kuc+T2NONYFqfZvkc16lgij1My6PibOBAbnsZxbEFhqw
 Xgf89CmOva5W7DNfWkFjv6dkgavgN29o92MnHhYHxo5EcdLAzvwxiXZ/veyhC3LychJ1NiD8R
 zFrxuSzd80gewuhiwxmJAszcSYwuLPzIZ46PUSu0gPVEOAA9SFJ+G5ZhohYxZOKBVJZ4ssjug
 tMvLn02bpaMvlQ5t0H9LcN0Ke9HY4bpdU9ZH5HpFQ24vFIMv5AIfjTr9wv4EGGhxIVRsgbaKu
 Z92f1fAJT/SQqytUUYHkb4izWBauXJgps+OneUgJDankQFZbw0iqiajQXwiZgdrxfLn1GYMpG
 soqfkke0TGreiycj3BNtOsplNYfpVnHfe2K14laASKNDvJ82TzJIsIzXhWy6Sp6GXz/hqp0+7
 9hsmvdKeaTX0NdMHAW9g==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 0BCEBk3R019776
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
Precedence: bulk



Am 12.12.20 um 13:00 schrieb Roland Lutz:
> On Sat, 12 Dec 2020, Klaus Rudolph (lts-rudolph AT gmx DOT de) [via
> geda-help AT delorie DOT com] wrote:
>>> 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?

OK

>
> Using refdes= for ports isn't deprecated because there are some things
> which can't be achieved with a portname= attribute, like having a
> component be a port in some situations and a connector in others.

No idea what that really means...
>
>> 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.
>
> But that's exactly what I/O ports are for!  So you want to have an
> "invisible pin" on the subschematic symbol which connects to a named
> net, and an "invisible port symbol" inside the subschematic which
> connects the port to a local net?

I didn't know how to achieve this. I have no idea how to create a symbol
with has less pins but can connect to a sub schematic. I only know how
to do it with a pin.
>
>> 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.
>
> I have already implemented that as part of my (at the time) experimental
> netlister features, but I haven't merged it yet, mostly because of
> different conflicting conventions for pin numbering.
>
> What pin numbering scheme do you use?

Sorry, no idea what that means? All symbols I noticed have pinnumber and
pinsequence the same value. Is it something related to that?

Klaus