Mail Archives: geda-user/2015/10/14/11:55:59
--Apple-Mail=_563E2F07-7919-458D-85D3-DE6603B37E1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Great stuff! Is this published somewhere?
On Oct 14, 2015, at 2:06 AM, Gabriel Paubert (paubert AT iram DOT es) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On Tue, Oct 13, 2015 at 03:09:25PM -0600, John Doty wrote:
>>=20
>> On Oct 13, 2015, at 2:39 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>>=20
>>>=20
>>>> Please not in libgeda or the geda-gaf core tools. That has
>>>> tremendous potential to break things. geda-gaf is a mature toolkit
>>>> in production use: changes to the core should not be taken
>>>> lightly. New tools and new plug-ins are great. We have a =
transparent
>>>> schematic format and powerful scripting mechanisms to give us power
>>>> and to allow us to keep that power from interfering with each
>>>> other's objectives.
>>>=20
>>> What about exposing attributes-on-nets to the backends?
>>>=20
>>=20
>> I=E2=80=99ve wanted that for a long time, but I note that you can =
effectively attach attributes to nets using symbols. The fine primitive =
gnetlist:graphical-objs-in-net-with-attrib-get-attrib (the longest name =
in the gnetlist namespace) allows a backend to extract them. This is =
more versatile, as it allows the back end not only access to attributes, =
but allows a symbol to define relationships between nets. Consider the =
following, which could allow a backend to deduce that a pair of nets is =
a transmission line, and give it a name:
>>=20
>=20
> That's what I've been using for about 3 years to generate netlists
> with hints for the PCB designer. I have only two symbols:
> - one with a single pin for 50=CE=A9 transmission lines,
> - one with two pins for differential lines.
>=20
> I've attached them to this file. They are as small as I possibly could
> make them because I found that larger ones were too distracting (and
> also consuming too much space on schematics).
>=20
>=20
> Here is a the net generating part of gnet-rinf.scm (for
> CadStar):
>=20
>=20
> ;;
> ;; Display the individual net connections
> ;; starting from the third if they exist.
> ;;
> (define rinf:write-connections
> (lambda (netpins port)
> (if (not (null? netpins))
> (begin
> (format port " ~a ~a~%"
> (caar netpins)
> (cadar netpins))
> (rinf:write-connections (cdr netpins) port)))))
>=20
> ;;
> ;; Display all pins from the net starting from the passed one
> ;; which is the second one.
> ;;
> ;; This is the line with the .TER command.
> ;;
> (define rinf:write-net-pins
> (lambda (netpins port)
> (format port ".TER ~a ~a~%"
> (caar netpins)
> (cadar netpins))
> (rinf:write-connections (cdr netpins) port)))
>=20
> ;;
> ;; Write net: first line starting .ADD_TER
> ;;
> ;; Only write nets that have at least 2 pins: gnetlist
> ;; produces quite a lot of single pin nets, even when
> ;; a pin is explicitly connected to a No-connect symbol!
> ;; There are also cases where the list of pins is empty!
> (define rinf:write-net
> (lambda (port netnames)
> (if (not (null? netnames))
> (let ((netpins (gnetlist:get-all-connections (car netnames)))
> (routing =
(gnetlist:graphical-objs-in-net-with-attrib-get-attrib
> (car netnames)
> "device=3DNetlist_Directive"
> "net_route_code"))
> (grouping =
(gnetlist:graphical-objs-in-net-with-attrib-get-attrib
> (car netnames)
> "device=3DNetlist_Directive"
> "bus_name")))
> (cond ((> (length netpins) 1)
> (format port ".ADD_TER ~a ~a ~s~%"
> (caar netpins)
> (cadar netpins)
> (car netnames))
> (rinf:write-net-pins (cdr netpins) port)
> (if (not (null? routing))
> (format port ".ATT_TRE ~a ~a net_route_code ~a~%"
> (caar netpins) (cadar netpins) (car =
routing)))
> (if (not (null? grouping))
> (format port ".ATT_TRE ~a ~a bus_name ~a~%"
> (caar netpins) (cadar netpins) (car =
grouping)))
> (newline port)))
> (rinf:write-net port (cdr netnames))))))
>=20
>=20
>=20
> ;;
> ;; Write the net part of the gEDA format
> ;;
> (define rinf:nets
> (lambda (port)
> (let ((all-uniq-nets (gnetlist:get-all-unique-nets "dummy")))
> (rinf:write-net port all-uniq-nets))))
>=20
> But you have to know about one caveat: when the net traverses the
> hierarchy, you have to put these symbols on the highest level sheet
> where the net appears in the schematics. This could be construed as
> a bug in gnetlist.
>=20
>> So, I see no urgency to exposing attributes on nets.
>=20
> I still think it would be convenient. Not absolutely necessary, but
> convenient. However I like the fact that the differential symbol
> explicitly shows which nets form the differential pairs. For single
> ended transmission lines, I feel that the 50=CE=A9 symbols, even very =
small,
> clutter the schematics.
>=20
> Gabriel
> <50Ohm-1.sym><diff-1.sym>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_563E2F07-7919-458D-85D3-DE6603B37E1C
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
iQIcBAEBCgAGBQJWHnrYAAoJEF1Aj/0UKykR1FoQAIKoqDboWfaziCPjj0sNiuiF
osugiBCvjbrvoYZcznWKoDAP4w4FCE1a8eSMlIFYpAK3Bastf47C/Abq2Eu97dTi
OlOxEzRQIOQSgqONnfKW9bR8a4rZ4jL4CVV9Q+SGcGw/8DUS7Yj/RD17qoIBxkF/
Q3d3TLjFIdUPusKryNioROwjxc9lVYdoTXZSqjgMAMn6ChAgfP/j3DYRa2CJsOTk
Y0A+0Gpaoal58O+EGVSuggIhHpODZtuOcb8Pk5eFK6N6WUe+MjWUgKqWPZQqvf1P
JmP8pah/W0l5QD+LTJwRG5r6+bqAuYVUI62I8a533vaVVsOnJOt55PUXZM5lIQqH
G86CUnKyOFVi1OK1BrIm1M+Yt84Qy4Q/S2Vw0VydNf5bg23dGrFIOrCL4fkLKU1g
kAfzjLhm6eoyGyWP10mn9n4J9NCfFPTcIWVOfAcDljXTQ4beB4hSj1omb/aO+1bI
/44C8mtIeen2KOEAeflCrsdskXZy4fQdGdty6KHagF/8aG5hdKK76MReRyTGWbNK
u16D017QRsGNrYnXHzwTta0cqpXYqK30nJoJoY8FciDU+i8hUpW6m34nbMkb+6M5
/8ZvhdCMRxR5/DcRESrE0pmk7PbJ4225kdzCFI9o/XCJRrZCfWFwu6kyVZCIL74K
ilTI5uE/te8adHywdGRu
=aXy+
-----END PGP SIGNATURE-----
--Apple-Mail=_563E2F07-7919-458D-85D3-DE6603B37E1C--
- Raw text -