| www.delorie.com/archives/browse.cgi | search |
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
| X-Recipient: | geda-user AT delorie DOT com |
| X-Envelope-From: | paubert AT iram DOT es |
| Date: | Wed, 14 Oct 2015 10:06:39 +0200 |
| From: | "Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> |
| To: | geda-user AT delorie DOT com |
| Subject: | Re: [geda-user] A lesson from gnet-makefile |
| Message-ID: | <20151014080638.GA4949@visitor2.iram.es> |
| References: | <1042003D-82E2-40F0-AB60-8186580C46AD AT noqsi DOT com> |
| <201510121905 DOT t9CJ5T9W026297 AT envy DOT delorie DOT com> | |
| <CAM2RGhTMnybSnYgnNhVZGA6PTvyJu+=Kzd5LX2HMqxT1F4LoRg AT mail DOT gmail DOT com> | |
| <88EA58F5-2B23-498A-9E5B-84054976DBED AT noqsi DOT com> | |
| <CAM2RGhTPPtqmWVa3=Kf-PeN+WS5Tn4J+D0Ri6R_4OrQOk+LFKQ AT mail DOT gmail DOT com> | |
| <4D3CD563-D8EE-4B2A-975A-AC2B573960FF AT noqsi DOT com> | |
| <CAM2RGhT8WzhwvzFx3Rfv8vN-f=i1=uWuLF+48VygSRtfdzdo-A AT mail DOT gmail DOT com> | |
| <34B17816-9EA5-45FD-BFB4-9D623A8D3D87 AT noqsi DOT com> | |
| <201510132039 DOT t9DKdN4L007713 AT envy DOT delorie DOT com> | |
| <4E6FB777-8298-4C7D-B99A-61D99C62A9E8 AT noqsi DOT com> | |
| MIME-Version: | 1.0 |
| In-Reply-To: | <4E6FB777-8298-4C7D-B99A-61D99C62A9E8@noqsi.com> |
| User-Agent: | Mutt/1.5.21 (2010-09-15) |
| X-Spamina-Bogosity: | Unsure |
| X-Spamina-Spam-Score: | -0.2 (/) |
| X-Spamina-Spam-Report: | Content analysis details: (-0.2 points) |
| pts rule name description | |
| ---- ---------------------- -------------------------------------------------- | |
| -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP | |
| 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% | |
| [score: 0.4997] | |
| 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. | |
| See | |
| http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block | |
| for more information. | |
| [URIs: delorie.com] | |
| Reply-To: | geda-user AT delorie DOT com |
| Errors-To: | nobody AT delorie DOT com |
| X-Mailing-List: | geda-user AT delorie DOT com |
| X-Unsubscribes-To: | listserv AT delorie DOT com |
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
On Tue, Oct 13, 2015 at 03:09:25PM -0600, John Doty wrote:
>
> On Oct 13, 2015, at 2:39 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
> >
> >> 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.
> >
> > What about exposing attributes-on-nets to the backends?
> >
>
> I’ve 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:
>
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Ω transmission lines,
- one with two pins for differential lines.
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).
Here is a the net generating part of gnet-rinf.scm (for
CadStar):
;;
;; 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)))))
;;
;; 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)))
;;
;; 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=Netlist_Directive"
"net_route_code"))
(grouping (gnetlist:graphical-objs-in-net-with-attrib-get-attrib
(car netnames)
"device=Netlist_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))))))
;;
;; 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))))
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.
> So, I see no urgency to exposing attributes on nets.
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Ω symbols, even very small,
clutter the schematics.
Gabriel
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="50Ohm-1.sym"
Content-Transfer-Encoding: 8bit
v 20111231 2
P 200 0 200 90 1 0 0
{
T 400 0 5 10 0 0 0 0 1
pinseq=1
T 400 200 5 10 0 0 0 0 1
pinnumber=1
}
T 400 800 8 10 0 0 0 0 1
device=Netlist_Directive
T 400 1000 8 10 0 0 0 0 1
graphical=1
T 340 150 9 8 1 0 0 4 1
50Ω
T 400 600 8 10 0 0 0 0 1
net_route_code=50Ohm
B 200 90 280 120 3 0 1 0 -1 -1 0 -1 -1 -1 -1 -1
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="diff-1.sym"
v 20111231 2
P 200 0 200 130 1 0 0
{
T 400 0 5 10 0 0 0 0 1
pinseq=1
T 400 200 5 10 0 0 0 0 1
pinnumber=1
}
T 400 1000 8 10 0 0 0 0 1
graphical=1
P 200 400 200 270 1 0 0
{
T 400 300 5 10 0 0 0 0 1
pinseq=2
T 395 450 5 10 0 0 0 0 1
pinnumber=2
}
B 80 130 240 140 3 0 1 0 -1 -1 0 -1 -1 -1 -1 -1
T 200 200 9 8 1 0 0 4 1
Diff
T 400 600 8 10 0 0 0 0 1
net_route_code=LVDS
T 400 800 8 10 0 0 0 0 1
device=Netlist_Directive
--wac7ysb48OaltWcw--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |