Mail Archives: geda-user/2020/12/09/01:03:46

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=IZ9C5Uma c=1 sm=1 tr=0 ts=5fd063bd
a=+cj0cO56Fp8x7EdhTra87A==:117 a=6nCCJP6eUAjU5VWlEGN4Vg==:17
a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=IkcTkHD0fZMA:10 a=zTNgK-yGK50A:10
a=FP58Ms26AAAA:8 a=a1KZgU7cAAAA:8 a=Mj1Xp5F7AAAA:8 a=j5nqAba_AAAA:8
a=BxmkjZKjJ4mWYlR8MP0A:9 a=bUnG7UR9CQuio4rg:21 a=QEXdDO2ut3YA:10
a=ng0hpkU2jXKPaRTLMVYJ:22 a=OCttjWrK5_uSHO_3Hkg-:22 a=G3NsWhPI6ntz9aATFwJT:22
X-SECURESERVER-ACCT: glimrick AT epilitimus DOT com
From: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] SAB processing patches
References: <e4ff3c96-939b-a93e-a32f-5e938b6daa63 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2011302045040 DOT 2894 AT nimbus>
<20201130220505 DOT 0AE4282C54FD AT turkos DOT aspodata DOT se>
<7c75ed03-456c-b408-8b50-0448f6b3a04f AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2012011606400 DOT 6785 AT nimbus>
<1b2c64b3-6a36-c1f3-dd54-bb583c6bea17 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2012021253440 DOT 1262 AT nimbus>
<475f980e-fddd-60d1-9a02-a5bc5fb5805b AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2012071333290 DOT 3907 AT nimbus>
<e6c5135f-b127-fd55-91b2-79aa357a5a07 AT epilitimus DOT com>
<alpine DOT DEB DOT 2 DOT 21 DOT 2012081644480 DOT 3649 AT nimbus>
To: geda-user ailing list <geda-user AT delorie DOT com>
Message-ID: <>
Date: Tue, 8 Dec 2020 21:42:08 -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.2012081644480.3649@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: MS4xfFKEazYG6utoD9paanBytRUskMkhVxJnP2SK1qKNUuNMlu3HlofmhSk0fhV3AQq96mUi//dE2BNpnlYIiL9z/fPlJI9PQeZ55edJ2cFJS+VBqWXQI2uy
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

My full answer with an additional point following and a new example:
> Roland,
> I'll answer these a bit out of sequence. This is going to take a bit
> of background so bear with me. I tried to answer these in a generic
> way in the overview section of the README file. So here I will focus
> on my thought process and how it evolved.
> ngspice as you know is the primary spice simulator for geda. It has
> some modes of operation which are currently unsupported by geda. In
> addition to the normal purely analog mode simulations for which spice
> was originally written, e.g. simulating LRC circuits up to op-amps
> etc, ngspice can also perform purely digital simulation, e.g. flip
> flops, logic gates, ram, etc. It is also capable of mixing the two to
> perform hybrid simulations, e.g. a transistor configured as an
> inverter driving an input of a logic gate, or a set of logic gates
> connected to an R-2R ladder.
> In order to do digital and hybrid simulation when you are building
> ngspice you pass the configuration script the --enable-xspice option
> (I may have listed this incorrectly as --with-xspice previously).
> There is one other piece required to use these modes, gnetlist has to
> be aware of them and generate a netlist that uses the features
> provided, this is the point of the xspice backend I am currently
> working on. The xspice code does not, at least at this point, depend
> on the sab code, but the sab code makes the xspice code more useable.
> My incentive to do the xspice code is that I have a private project I
> am working on that requires it.
> The hybrid simulation mode of ngspice (which my project needs) uses
> what are called 'bridge-devices' to connect purely digital to purely
> analog sections of the schematic. I'll refer you to section 25.1 of
> the ngspice manual
> <> for the
> reasons why this is done. However for the purposes of answering your
> questions: These bridge devices have no physical counterpart, they
> exist in the schematic solely for the purpose of simulation and
> depending on the complexity of the circuit there may be quite  few of
> them. So currently to use these modes of ngspice you are left with a
> several options.
> 1. Add them to the netlist manually each time the xspice netlist is
> generated.
> 2. Include them in the schematic and add/remove them manually as you
> pas through the various stages of the iterative design process.
> 3. Have them in the schematic and have the system remove them them
> while generating the netlist for non simulation uses.
> Options 1 & 2 are highly error prone, and tedious for a design of any
> real complexity. Which leaves option 3. Hence my initial impetus to
> start thinking about the SAB system.
> So the gnetlist backend to generate the xspice netlist needs the
> bridge devices in the schematic (the sim context) but other non
> simulation netlists (the ab context), e.g. pcd or partslist, need them
> removed. At the risk of starting another discusson, this is why the
> spice-noqsi backend was not going to work, it works in the sim
> context. To make option 3 work with the existing netlisting system
> would require the modification of all the existing backends. Which led
> me to the conclusion that a better solution was to move this
> modification stage out of the backends and make it independent of
> them. To do this requires some means of noting, preferably in the
> schematic, which parts need to be modified, how, and when which is
> what the sab-param attribute is for.
> Since these bridge devices connect two nets together you can't simply
> remove them. You have to reconnect the nets together after the
> component is removed, in other words you have to 'bypass' the device
> (the code actually does it on the opposite order). Other schematic
> components have no net connections, e.g. spice-include, and only need
> to be removed, i.e. 'discard'ed.
> Once I really started thinking about what could be done it occurred to
> me there were other use cases. For example, physical connectors are
> very important in the ab context but rarely (except for extreme fringe
> cases) have any place in a sim context so they have to be discarded if
> single ended, or bypassed if double ended, which brings you back to
> options 1-3 above. If you already have a system in place to remove
> things for the ab context there is no reason not to employ it for the
> sim context as well.
> This gives rise to the designation of contexts. 'sim' and 'ab' were
> chosen for what are hopefully obvious reasons, but don't actually have
> any special meaning as far as the code is concerned. So any label can
> be used as long as the same label is used in both the schematic and
> when designating the context for gnetlist. The only place 'sim' and
> 'ab' ever appear in code is in the SAB_CONTEXT constant which can be
> added to a backend to make it work transparently with the SAB system
> (which was the reason to call 'sim' and 'ab' "predefined"), but even
> here any label can be used. The side effect of the code making no
> distinction about the context labels (which there is no reason for it
> to do) is that the user is free to define their own contexts. As for
> where this could be used. I used it during the development phase, once
> I realized it was possible, for testing the error checking system. If
> you look at sab.sch you will see a bunch of resistors over on the
> right hand side. These resistors are all tagged with the 'error'
> context. So while testing, to see errors generated I could pass
> --sab-context=error to gnetlist. Most of the time I didn't want a
> bunch of meaningless errors being listed so they are all segregated
> under the 'error' context. As another example, let's say a user has
> some documentation describing the operation of their circuit and they
> want this document to accurately reflect the current refdes numbers,
> even if those numbers are changed by renumbering. This could be done
> using user defined 'doc' context (the label is arbitrary) and an
> external script to extract the refdes numbers and embed them into the
> document.
> One of the common tasks when running simulations is replacing a
> component in the schematic, e.g. a 555 timer, with a subcircuit. While
> geda supports the use of subcircuits these simulation subcircuits have
> no use in the ab context, and since they can be quite complex and
> extensive (check the schematic for the internals of a 555) they can be
> difficult to remove manually. Originally I had planned to implement a
> built in action to make the swap but I quickly realized that it was
> too complex of a task to write in a generic manner. So I decided to
> handle this with external scripts. It is possible that in time generic
> algorithms may become apparent for at least classes of devices but
> that will only become clear with time and use.
> The optional 'order' parameter came about because I encountered a
> situation during development where an error occurred as a result of
> the order in which changes were being made. In that case it was
> actually a bug but it got me thinking there could be cases where a
> user might need a specific sequence of actions to occur. A possible,
> admittedly slightly strained, example could be the documentation
> example from above. The documentation generation could be done at the
> same time as a netlist is being generated. If the component were to be
> removed before the documentation were generated an error would result.
> This is a case where I didn't really need it for what I was doing but
> I saw an easy way to implement it within the structure of what I had
> already written so I did.
> While I have tried to give examples for each of the user-defined
> context, external script, and order parameter questions my ultimate
> answer would be that my lack of imagination is not a barrier to their
> usefulness to users.
> Roland Lutz wrote:u
>> Hi Glenn,
>> I have a few questions about your patch series:
>> - You introduce "sim" (for simulation) and "ab" (for PCB) as
>> predefined contexts but state that user-defined contexts could be
>> used, as well. What kind of user-defined context would make sense
>> with this system?
>> - In what kind of situation would you want to use the "bypass" action?
>> - In what kind of situation would you want to use an external script,
>> and what kind of modification would it do on the netlist?
>> - What is the "order" parameter used for?
>> - What does the patch to "s_slot.c" / the code in "sab.c" do?
> Two things. The original purpose was to make slotting work seamlessly
> with the bypass action. If the slot changed the bypass pin numbers
> needed to change as well. Tedious and error prone to do by hand,
> Making that work required functions to parse the parameters etc, which
> in turn gave rise to a generic system to work programmatically with
> sab-param. It ended up in libgeda because that is where s_slot.c
> resided which is where I needed to hook in so it didn't matter *why*
> the slot was changed. Which is why I only wrote the SabUpdateBypassPin
> function. The basic infrastructure is in place in sab.c to allow for
> extension.
>> On Wed, 2 Dec 2020, Glenn (glimrick AT epilitimus DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>> If I understand correctly what you are describing could be done with an
>>> SAB exec script. It wouldn't be formalized but it could be
>>> accomplished.
>>> Kind of the whole impetus for SAB was to move the modification stage
>>> out
>>> of the backends making it backend independent.
>> What is your incentive to do this?
> Hopefully I answered this above. but TL;DR I need it.
>>> What header do I need to include to use the _() translation bit in C
>>> code? I can't find it.
>> This would be
>>   #include "libgeda_priv.h"
>> for libgeda code and
>>   #include "gschem.h"
>> for gschem code.
>> Also, I missed one thing before:  All C source files must have
>>   #include <config.h>
>> as their first include since other headers may define different
>> things depending on macros define here.
> Will do.
> I am close to having a public git repository set up. I'll keep you
> posted.
> I am working my way through the list of memory leaks.
> I found a better solution to the "force spice-title to use .TITLE"
> issue. In my new xspice backend I added a -O parameter to do this.
> Any chance of having your fix for the missing path bug in
> (
> merged into the master branch? I have it in my copy because I use it
> for doing the xspice development, but it is a bother keeping it from
> causing problems with commits etc. I almost lost a bunch of my memory
> leak fixes because of it.
> Glenn

> 2. The sub circuits that a component is replaced with in a spice netlist
> wil often come from an outside source. For example there are several
> spice subcircuits of varying levels of detail for a 555 timer widely
> available and all are in spice netlist form and so would not be
> available in gaf.netlist.netlist. These do not necessarily have the same
> structure etc. Hence the use of an external script to substitute them
> for simulation.
> Glenn

Another example that occurred to me while driving home yesterday for the
use of user defined contexts.

Let's say you have a circuit with several optional sections. You want to
be able to simulate different combinations of options and generate parts
lists for each. By designating each option with a different user defined
context you would be able to mix and match them as you like for both
simulation and as-built backends by using --sab-context= on the gnetlist
command line. Similar to optional software using #ifdef.


- Raw text -

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