Mail Archives: geda-help/2020/12/09/12:37:31
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 :<number> 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 :<numbers>
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
- Raw text -