X-Authentication-Warning: delorie.com: 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]" Subject: Re: [geda-user] SAB processing patches References: <20201130220505 DOT 0AE4282C54FD AT turkos DOT aspodata DOT se> <7c75ed03-456c-b408-8b50-0448f6b3a04f AT epilitimus DOT com> <1b2c64b3-6a36-c1f3-dd54-bb583c6bea17 AT epilitimus DOT com> <475f980e-fddd-60d1-9a02-a5bc5fb5805b AT epilitimus DOT com> To: geda-user ailing list 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net X-AntiAbuse: Original Domain - delorie.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - epilitimus.com X-Get-Message-Sender-Via: a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com X-Authenticated-Sender: a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4xfFKEazYG6utoD9paanBytRUskMkhVxJnP2SK1qKNUuNMlu3HlofmhSk0fhV3AQq96mUi//dE2BNpnlYIiL9z/fPlJI9PQeZ55edJ2cFJS+VBqWXQI2uy tVg92Olz7umj+sLvZIdJ3NH54rBxxmDk3WowF+s/XBrTPEYQCQn7+ri3INrSeUuHA3ATeqzoY8dmB+7HmzMKBTUuibcH1j3RKoFfrysvV0MRJnzw+DeyVR9t 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 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 >> >> 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