Mail Archives: geda-user/2020/12/09/01:03:46
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
> <http://ngspice.sourceforge.net/docs/ngspice-32-manual.pdf> 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 backend.py
> (http://git.geda-project.org/geda-gaf/commit/?h=stable-1.10&id=fc147a39f53b57d400989e44cd0e308208e79ac1)
> 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.
Glenn
- Raw text -