delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |