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=1607790130;
	bh=VANhCyIYpSqGYkyCtbIntB0aBR/NbSHL3MFlFLId5SU=;
	h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To;
	b=EXrUFMwQicy7AajjnA7mwfwuJV+gmx3Lg9rP7wyrZllh5evtPcKcedK5g9+AbFEsu
	 lQmIYpstyBE/7NKRCav1lFf+tuCf39A+LJaKFttujXJ6GVDNZniC+e/kxHUXFI+/As
	 WeGjj+dYCuT62lz4Qbs5pjbB9uiHdn/FtR6Om7rc=
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>
 <b7d591b9-9f89-4ec6-4115-72608dec59f4 AT gmx DOT de>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012121600390 DOT 31572 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: <aaeefca8-49af-399a-2a93-5240c1848e53@gmx.de>
Date: Sat, 12 Dec 2020 17:22: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.2012121600390.31572@nimbus>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Provags-ID: V03:K1:S3ERIppNwV5rb+6ov17tNiWcPv0q/FjMpAKrlp1vZKHGYo4evsf
 12njbFTMdSDXyCdbqBEBQcSSSuiqth1eiK2tDregpdQGb5/7Mlnvhn9JleRpk1pN1l9Wzlu
 fJ9F1WUo/Dd7HUnbRTMeBblMPQsaU6eA43o5dOgIScEwmsgjnVzWqWj1S3O9PSu+0S0+/GY
 QFMi/lzqdbC9moJsqsFhQ==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:Q3Dahj2f+Nc=:Kv20K7rHfnJNZOjLlriyId
 Z9JSAoL21RxcGTrSG3KS/+98WouSu9l9uLJi3Usn4F3F6LKEJlWHjA6Jeme+T3+gFQhkaUf4s
 Ug0246k4RSvKueWrsSHUqqYUi8yByh/4zaxULsuDINOhUiFO8hCchkoMsZH+srMr9QmAjzqbg
 VEmjK5aLWP3Y1Sf7Gdp/u0IEkbht5VQoEdTUf2s0JhwzcRyep/F0s0kufHQF4hcxeSvqpN7nH
 oN2XCHrbB4zFJ4E7y2acZXyW/QiHiqPPJ1QNFKnQtrt9RQawhfU2RJyI8GFgSXOhL1TXq84lT
 FEAFa66X8rQjopVcmUNHQPJO6sEerrpDO8e+iu8ldkxYFHrfRlayboO1ECEeL5j4YMIAnwG2f
 N8slKh6MMnRDl6rP2k7g4ibLXE/ApHbwgd/U10tXyHxETcGlldFkzQyl8jNXbDHhzt6cDPaCW
 aTcfUsbFEmTK7pbxM+/DHL8y3clLVjQtxMlAccAP5a+mwKQqmS0lPrzA/7KB1v2hVginQWzjX
 38vgcHT8e6zTcTZXtHU4QDPmfj+Q9bjSaZ/CfPVsc9uhCMwnPV89COT6Im5BBNj/1c+PiEPo0
 T5PBi7kWztoYixoMjZs6tKN25haXF006TqEm4iXOHtgQMIdNscgl3SDKjajrvEBw1xNrQoiVK
 BFPufsrwsE+x+Fj6tX8rm70qk0vAAPdEcce1my0oL8Op24FfRoisteE92sSYCqu3XFXBpF0fy
 ZW0nIiR/dj4awY1711r4bEOzXaW53gA71NMck3zbS8dGzi4Xw7iCWQc0swUctAqlBAV4fRpSJ
 2usegzaMcpq9Jqk+dHIdF9+KTstE6SEoopfhWu6l3xZr8W3WEzplghKCogLFLnlyXrDap1HUD
 xcaeRA7L+X2AgRWiBzHw==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 0BCGN2iu005966
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 16:08 schrieb Roland Lutz:
>
> Currently, a pin on the subschematic symbol is required for each
> connection to the actual subschematic.  However, if that really bugs
> you, something along the lines of
>
>      connect-port-to=GNDPORT:GND
>
> could be implemented.  That would still require an actual port in the
> subschematic, but you wouldn't see the respective pins on the symbol.
>

Yes, that is what I suggested.

But I would go a step further and make the net directly accessible in
the subchematic. But this should be optional, of course. As said, it
would be possible to directly access the net instead of the port which
is connected to a net and requires the port symbol.

I am not a big friend of that indirection from
upperlevel-net/symbol/pin/port/lower-level-net. That is to much overhead
which did not enable anything. If I really want to have the additional
level of indirection like the port thing, I still can connect a new net
to a already available one and use this new net to connect via the symbol.


>>> What pin numbering scheme do you use?
>>
>> Sorry, no idea what that means?
>
> Assuming buses were already implemented in gEDA/gaf, how exactly would
> you expect to use them?

Well, I never had used buses before and never did a real world design
with buses in the past.

On a first thought, a bus something like an alias for a "set of nets".

Lets say, we have the nets named a0, a1 ... a15 for a address bus of a
memory subsystem and used to connect different peripherals to a cpu.

Maybe it is a simple idea to use a syntax well know from programming
languages like:

addressbus.a6 is the a6 line of a bus and a bus can collect all
required lines like adressbus[a0,a1...a15]

Now connecting a bus can use the same syntax as nets already did, maybe
"special" pins required, maybe name them busconnectors or whatever.

Important from my point of view is a easy to access single nets on a bus
and also the other way around to define a bus as a sequence/collection
of nets.

If I play with gschem, I see there are already buses and nets and
automatically there is a symbol inserted if I connect a net to a bus
called "busripper". So my assumption is, that I have to give a "net name
on the bus" if I connect a net to a bus within this device. If we
continue on the address bus example, it feels natural to give an
attribute like "a6" to the busripper. For the netlister it is quite easy
to read from the same bus the net in or back. Internally it may simply
use some syntax like introduced already above like addressbus.a6.

Maybe we can collect the net names from the nets directly without adding
them manually to a busripper. If the net already has the name "a6",
because "somewhere" a net= attribute is connected ( remember, I did not
want to add a name to a net directly, as this direct net naming is a bit
dangerous today in gschem ), the bus can take that name also directly.
So there may be the rule: If the ripper did not overwrite the name, we
take the name directly.

And to go a step further, it may be useful, to collect not only nets but
also buses to buses in a non limited depth. Maybe someone wants to add
the databus and the address bus to a new bus, lets name it memorybus and
so on. Now the bus ripper takes attributes like with "address" as value
and on another busripper "data". Internal representation will result in
memorybus.address.a6 the get the a6 net. Quite simple :-)

On the other way around someone may define
memory.[address[a0, a1, ... a15],data[d0,d1...d7]]

I believe, most of the work is done as gschem already provides the
busripper and it is added automatically if I connect a net to a bus.
Simply add the attributes to the busripper or take the names of the net
into the bus.

In hope I expressed it clear enough ;)

Regards
  Klaus