Mail Archives: geda-user/2016/01/08/07:39:01
--Apple-Mail=_925CD069-F4D3-483A-B72C-0BC5362FB8C7
Content-Type: multipart/alternative;
boundary="Apple-Mail=_EB71FDDF-6C5A-4ABE-A4EB-243977991AD4"
--Apple-Mail=_EB71FDDF-6C5A-4ABE-A4EB-243977991AD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jan 8, 2016, at 6:41 AM, Peter Clifton =
(petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] =
<geda-user AT delorie DOT com> wrote:
>=20
> On 8 Jan 2016 07:17, "DJ Delorie" <dj AT delorie DOT com> wrote:
> >
>=20
> > The net result of this is that you can assign a net named =
"nBL,A[8-2]" to
> > a pin labelled "A[0-7]" and numbered "1-4,10-7" and they'll all get
> > hooked up as appropriate.
>=20
> Presumably this operates with "normal" nets and pins, not gschem buses =
- which still (as far as I recall) don't netlist.
>=20
> > You can also have a pin named "GND" and numbered "1,15,18" connected
> > to net "GND" and it will connect all three pins to the one net.
>=20
> > Constructive feedback welcome!
>=20
> I think the solution you proposed looks useful and pragmatic.
>=20
> One potential disadvantage of using this, (user choice of course), is =
that until more work on applying new semantic rules is done in geda, =
schematics using this new attribute semantics will be less easily reused =
for other work like simulation.
>=20
>=20
You can do this kind of thing with a plug-in that wraps the appropriate =
gnetlist primitives. It=92s somewhat harder, but could apply to most =
back ends, not just pcb.
> Regarding bus pins & buses vs. Net pins and nets.... I start to wonder =
if we should aim to reduce that distinction in the future, and make all =
nets / pins / buses more equally handled in gEDA. (Up to the netlist =
backend / resolver).
>=20
>=20
Yes. And then, erase the distinction between nets, busses, pins, and =
lines. Move that into attributes: a line with netname=3D is a net, a =
line with pinnumber=3D is a pin =85
This would let the user decide the appropriate line style for nets, =
busses, and pins. Keep the old method for backward compatibility, of =
course.
> Optional stronger port typing like VHDL / verilog would also be nice, =
for schematics that drive hdl output.
>=20
>=20
That kind of thing belongs in a DRC script, I think.
> Please can anyone replying consider whether a new thread is =
appropriate if addressing my comments, not DJ's new feature.
>=20
>=20
> > DJ
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_EB71FDDF-6C5A-4ABE-A4EB-243977991AD4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jan 8, 2016, at 6:41 AM, Peter =
Clifton (<a =
href=3D"mailto:petercjclifton AT googlemail DOT com">petercjclifton AT googlemail DOT co=
m</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><p dir=3D"ltr"><br>
On 8 Jan 2016 07:17, "DJ Delorie" <<a =
href=3D"mailto:dj AT delorie DOT com">dj AT delorie DOT com</a>> wrote:<br>
><br></p><p dir=3D"ltr">> The net result of this is that you can =
assign a net named "nBL,A[8-2]" to<br>
> a pin labelled "A[0-7]" and numbered "1-4,10-7" and they'll all =
get<br>
> hooked up as appropriate.</p><p dir=3D"ltr">Presumably this =
operates with "normal" nets and pins, not gschem buses - which still (as =
far as I recall) don't netlist.</p><p dir=3D"ltr">> You can also have =
a pin named "GND" and numbered "1,15,18" connected<br>
> to net "GND" and it will connect all three pins to the one =
net.</p><p dir=3D"ltr">> Constructive feedback welcome!</p><p =
dir=3D"ltr">I think the solution you proposed looks useful and =
pragmatic.</p><p dir=3D"ltr">One potential disadvantage of using this, =
(user choice of course), is that until more work on applying new =
semantic rules is done in geda, schematics using this new attribute =
semantics will be less easily reused for other work like =
simulation.</p><div><br></div></blockquote><div><br></div>You can do =
this kind of thing with a plug-in that wraps the appropriate gnetlist =
primitives. It=92s somewhat harder, but could apply to most back ends, =
not just pcb.<br><blockquote type=3D"cite"><p dir=3D"ltr">Regarding bus =
pins & buses vs. Net pins and nets.... I start to wonder if we =
should aim to reduce that distinction in the future, and make all nets / =
pins / buses more equally handled in gEDA. (Up to the netlist backend / =
resolver).</p><div><br></div></blockquote><div><br></div>Yes. And then, =
erase the distinction between nets, busses, pins, and lines. Move that =
into attributes: a line with netname=3D is a net, a line with pinnumber=3D=
is a pin =85</div><div><br></div><div>This would let the user decide =
the appropriate line style for nets, busses, and pins. Keep the old =
method for backward compatibility, of course.<br><blockquote =
type=3D"cite"><p dir=3D"ltr">Optional stronger port typing like VHDL / =
verilog would also be nice, for schematics that drive hdl =
output.</p><div><br></div></blockquote><div><br></div>That kind of thing =
belongs in a DRC script, I think.<br><blockquote type=3D"cite"><p =
dir=3D"ltr">Please can anyone replying consider whether a new thread is =
appropriate if addressing my comments, not DJ's new =
feature.<br><br></p><p dir=3D"ltr">> DJ<br>
</p>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><p style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">John Doty<span =
class=3D"Apple-converted-space"> <span =
class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_EB71FDDF-6C5A-4ABE-A4EB-243977991AD4--
--Apple-Mail=_925CD069-F4D3-483A-B72C-0BC5362FB8C7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWj63CAAoJEF1Aj/0UKykRAegP/j6+RNOP2hlVrQge1AxYne3w
yH2YlbZUPh40Q6VAid1uvu3oc0KoYPh2j+BT7rd3yRiZhi8SprF28C6gQPHBPnx0
+RJsi5wDVG3Dbe0IVgQdx6SYmQSvkkF5mFHvWyJTfleH9iKcTfpRaiVSb+iqG4Xv
6ZXxMgJ/wyxFeoMdqOXkZkLDOINX5+qaTGa2rgeJQHrgmb4l7wTNn8y7fjPgS+Z+
G5PJcCGP2EZXLDzBrA11pP/rpyK2oq8jhG2qqn77DLOGJCPLUgu7HBAnKIuSXS89
x3GYJrN7KqsqD1oGOftIoVQOTC0TTxADUTgkDvfcZYRNmmroFXbfl/QgPIwGMkd+
3Hlrw6+tEPNXEHdEBn8/lMnaH19Lrt29ZBDmywPu0mqyfWRiA1xIIqd7FGHr7jaG
6uvhrSbSdI3KXuUmWvp8QmXbPTIwSyUs2knJ0VupQVOFAHyd5EozJdUgJSb0z68W
iWVA0zqPNEWFJ0XO8mlt5xjzfh7ZLFM+8UW2dR4P1HWHhTkF2uG1gbpfKOiPdtJ0
E28OgqGmvlhiCoxSWPZ4blP5VuXaIOhuLwh2leheyDqDuuWktorJ1oolLcwQ90h7
0yG0SLjCwczhbGR5HVE513rFBw52U8dkGvIfwE19nEpiNQbhxUVYbd8KKRcPv9Eo
6vnCW21MXQ1e9+TXDhGy
=1jT7
-----END PGP SIGNATURE-----
--Apple-Mail=_925CD069-F4D3-483A-B72C-0BC5362FB8C7--
- Raw text -