Mail Archives: geda-user/2020/10/23/20:48:55

X-Authentication-Warning: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-CMAE-Analysis: v=2.4 cv=JoM0EO0C c=1 sm=1 tr=0 ts=5f937518
a=+cj0cO56Fp8x7EdhTra87A==:117 a=ak8qw4mXMovHqoTSgcj6Pw==:17
a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19
a=IkcTkHD0fZMA:10 a=afefHYAZSVUA:10 a=a1KZgU7cAAAA:8 a=Mj1Xp5F7AAAA:8
a=l4wZD_X8GGXfcoXQ7GwA:9 a=QEXdDO2ut3YA:10 a=ng0hpkU2jXKPaRTLMVYJ:22
X-SECURESERVER-ACCT: glimrick AT epilitimus DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:
bh=2/DhapTbZW3YeaFHJduf+G3gvxwmnN8WwJUEdJTUcVk=; b=ZfQqGokgmKHN+/xCh1J1vRe0x+
Subject: Re: [geda-user] submitted a new patch
To: geda-user AT delorie DOT com
References: <14f9e862-8ee0-4432-23b6-06e94215baa4 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010120958150 DOT 2535 AT nimbus>
<32bfe083-3604-b747-030a-48a13e2b1074 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010122312420 DOT 8245 AT nimbus>
<7c133ba2-5b09-91f3-808f-9f444c625278 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010151343310 DOT 1527 AT nimbus>
<aa7c0456-a606-be86-58c4-b8352cc66127 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010231526280 DOT 12318 AT nimbus>
<A61C3EBE-CBAA-4951-874D-F215EB5515CA AT noqsi DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010231755200 DOT 11745 AT nimbus>
<9b33084b-c548-a325-d14a-f6a4d659a596 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2010240053540 DOT 4744 AT nimbus>
From: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID: <>
Date: Fri, 23 Oct 2020 16:27:55 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.3
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2010240053540.4744@nimbus>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender: glimrick AT epilitimus DOT com
X-CMAE-Envelope: MS4xfOBgcbZsZykYHNR0dtW3Q1C3hH1gtHF8qpgmsWMeArbKrxK6Bv9rxxY+ldjN6laHpF+G8n0g5XMRni/vWjzY7Yny95XVScyKDcijJJrcE1+OJ8Oo3MT/
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

Roland Lutz wrote:
> On Fri, 23 Oct 2020, Glenn (glimrick AT epilitimus DOT com) [via
> geda-user AT delorie DOT com] wrote:
>> 2. Not all spice simulators work the same. It is up to each
>> implementation to decide if they want to use the first line, a specific
>> .TITLE card, or both/either as ngspice does. For example my reference
>> book on PSpice, fairly old so may be different now, requires the first
>> line of the netlist to be the title. So spice-directive-1.sym would not
>> produce a working netlist for such an implementation.
> Hmm.  I don't like the idea of simulator idiosyncrasies being coded
> into the schematic; this just doesn't feel like the right way to do it.
> How about changing the backend logic so the .TITLE directive, if there
> is any, is always placed first?  Would that work with all simulators?
> Are there other cases where directives need to be placed in a
> particular order or place?
Hence the use of the attribute to enable the use of the ".TITLE". As far
as I know the first line of the netlist is the traditional way of
setting the title in spice. As I said the ".TITLE" card isn't even
listed in my old PSpice reference book from when I was in college. So my
approach was to introduce the spice-title device which the backend uses
to to set the first line of the spice netlist. Then the optional
"comment" attribute was added to allow the use of ".TITLE" if required
by the simulator. Any simulator that doesn't recognize the ".TITLE"
would most likely issue an error, but may just ignore it.
Spice was originally a software package that has since been ported,
upgraded, and tweeked multiple times by multiple groups (PSpice is one
such variant, ng-spice is another) so there really isn't a "standard"
that all spice simulators adhere to. 
An alternate approach would be to not use the attribute, and have the
user put the ".TITLE" directly into the value attribute if their
simulator needs it. A spice-directive device could be used with ".TITLE"
to embed the title later but a) it only works if the simulator
recognizes ".TITLE" and b) it can not be used to set the first line of
the netlist if the spice implementation requires that. ng-spice can use
either but I would argue it would be a bad idea to force the user to
choose one specific spice implementation when it costs us so little to
support (almost) any implementation in this instance.
>> 3. Yes it was a minor change, intentionally so, to let me get familiar
>> with your process before I offered more substantial changes.
> I didn't mean to criticize this; on the contrary, I think it's a good
> idea.
Not taken as a criticism, just explaining my thinking.
>> 4. re: use of comment. I chose it as it seemed the most appropriate
>> without adding a new attribute, and param (my first choice) was used for
>> other things. If a new attribute would be preferred I have no problem
>> with that. As a gneral plicy use specific attributes would however tend
>> to lead to attribute bloat.
> If there is no existing attribute that makes sense to use, and you
> feel like need to use an attribute, then it's fine to introduce a new
> one.  In any case, that's better than using a conceptually different
> attribute like "comment=".
I will keep this in mind. In fact for what I am working on I have
already added one :)
>> 5. I will not be heart broken if you decide to remove spice-title et
>> al. :)
> We'll see.  I think you have a point, so your contribution is likely
> to result in a change in one form or another.  And even if it didn't,
> having the kind of discussion we're in right now is an integral part
> of the process with which you're looking to familiarize yourself.
> Roland

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019