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]" Subject: Re: [geda-help] using net names on multiple sub schematics used by single symbol To: geda-help AT delorie DOT com References: <3e21c34b-571c-8762-7e68-f096bcf10a37 AT gmx DOT de> <20201209082005 DOT 8890C8512092 AT turkos DOT aspodata DOT se> Message-ID: 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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== Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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=# or "net=# " 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=: > > 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