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
Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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
Precedence: bulk


--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--