X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f X-Recipient: geda-help AT delorie DOT com X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: "karl AT aspodata DOT se [via geda-help AT delorie DOT com]" To: geda-help AT delorie DOT com Subject: Re: [geda-help] attributes for nets (was: using net names on multiple sub schematics used by single symbol) In-reply-to: References: <3e21c34b-571c-8762-7e68-f096bcf10a37 AT gmx DOT de> <20201209082005 DOT 8890C8512092 AT turkos DOT aspodata DOT se> Comments: In-reply-to Roland Lutz message dated "Wed, 09 Dec 2020 14:08:42 +0100." Mime-Version: 1.0 Content-Type: text/plain Message-Id: <20201209172337.BDA12824114E@turkos.aspodata.se> Date: Wed, 9 Dec 2020 18:23:37 +0100 (CET) X-Virus-Scanned: ClamAV using ClamSMTP 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 Roland: ... > > 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 ? > > Having a name written next to a net is one of the net naming conventions > used in schematics. You *could* use an invisible symbol for that, but > what's wrong with attaching the netname= attribute directly to a net? Why I tend to avoid netlabel: Consider http://aspodata.se/electronic/netlabel/... In netlabel_01.sch I have a netlabel attatched to the net, which is perfectly fine. For some reason I'm forced to reroute the net lines in 02, so naive as I am, I move the label near one of the components and get 03. Then working on some other part of the net, I reroute some that part the net in 04, and oops, the netlabel is gone and I didn't notice. Usgin a net symbol in 05, would have avoided that, since moving the net thing doesn't make it attached to some other remote part of the net lines. Now, solution 05 isn't perfect, but it is better than having your netlabel wanishing under your feets. /// > > Regarding the ugly ":1", cannot a missing : just default to :1 > > (this has been up to discussion before) ? > > Using net= attributes to define virtual pins as well as named net symbols > always felt like a kind of hack to me. Virtual pins typically don't have > a corresponding pin object in the schematic, and more importantly, they > define an actual physical connection of a real component, whereas pins on > named net symbols have to exist as pins objects in order to make sense and > don't show up in the final netlist. One way to handle and/or think about this could be: a, net (or whatever attribute name) attached to some object (this is like the current "netlabel") object { T .... net=signal } b, net attached to a virtual pin (in a symbol) (this is like the current "net") T ... net=signal:1 c, net attached to a actual pin, well that would be as in a, alt. one could add an invisible flag to P, and remove the current : syntax altogether. /// ... > It should be possible to use zero or multiple port symbols in the > subschematic(s), but since this is most often an error, gnetlist issues a > warning about this. Well, if it is legal to not use a symbols pin, it should be legal for the symbol (subsheet) itself to not use a pin. If you want to complain about it, use a warning instead. Trust the user. > > From what I can see, the portname is just a net attribute without > > the ugly :1 > > The _netname_ attribute is just a net= attribute without the ugly :1. > > > so what does the portname way of doing it solve versus the "old" net way ? > > As for netname: well, it removes the ugly :1. If the only cause is for netname and portname is the ugly :1, I couldn't care less. > The portname= attribute replaces refdes= as the attribute used for > subschematic I/O ports. I see why in certain situations, it would make > sense to use refdes= for defining ports, and that's still supported, but > I've seen (and experienced) just too many errors caused by a mismatch > between pinlabel= and refdes= attributes to ignore this. portname= tells > gnetlist that this is intended to be a port and nothing else--if there is > not a matching pinlabel= on the instantiating component, that's an error. I have a program for that. It generates booth the source symbol (with pins), and the subsheet (with net symbols), so that is not an issue for me. For thoose who can't type, consider using http://aspodata.se/git/openhw/pdftosym/pintosym.pl And nothing hinders anyone to include that in geda or ripping out the hier...al (however that is spelled, just me and my typing skills) part and make it in whatever language you prefer. It could even be a menu item in gschem/lepton. Regards, /Karl Hammar