From MAILER-DAEMON Sat Nov 03 06:19:47 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gIt1v-00074O-3R for mharc-gnucap-devel@gnu.org; Sat, 03 Nov 2018 06:19:47 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIt1s-00074G-QF for gnucap-devel@gnu.org; Sat, 03 Nov 2018 06:19:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIt1p-0000uu-Hb for gnucap-devel@gnu.org; Sat, 03 Nov 2018 06:19:43 -0400 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:49650) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gIt1h-0000hF-Rp for gnucap-devel@gnu.org; Sat, 03 Nov 2018 06:19:37 -0400 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gIt1W-0001QQ-LG; Sat, 03 Nov 2018 11:19:22 +0100 Date: Sat, 3 Nov 2018 11:19:22 +0100 From: Felix Salfelder To: al davis Cc: gnucap-devel@gnu.org Message-ID: <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181102212235.0f9881a6@z> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: [Gnucap-devel] incmode, orderings, convergence X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 10:19:46 -0000 On Fri, Nov 02, 2018 at 09:22:35PM -0400, al davis wrote: > On Sun, 28 Oct 2018 11:49:19 +0100 > Felix Salfelder wrote: > > the incmode hack was meant to make the solver more robust overall. > > my other idea was to set non-incmode only in TRLOW and also in TRHIGH, > > which is usually not reached. this curiously helped produce results in > > this example, but took more iterations than 6 12 18.. > > TRHIGH almost makes sense. Perhaps it should be iteration number > > itl[TRHIGH]. > > This would be impossible in transient, except for initial DC. In > transient, a step rejection sets incmode to "BAD", which means to > revert to non-incmode on the next step. So this is already done. > In DC (which includes the initial DC of a transient analysis, an > iteration count this high often means trouble, so it sort of makes > sense. It might also make sense to revert to non-incmode when in > homotopy mode, but also it might not. It might also be interesting to > play with damping. (options dampmax, dampmin, dampstrategy, vmin, > vmax). I can see the mark_inc_mode_bad in s_tr_swp.cc +473. somehow the additional non-incmode in itl[TRHIGH] still made a difference. will revisit this. > > I kind of agree that this is the wrong approach. But it's not just the > > switch as you suggest. if i remove S3 and replace S4 with a resistor, > > r=1e-10, it does not converge (including wrong results) in the initial > > dc. not even with r=1e-5 (OPT::short). but finally with r=1e-3. > OK .. then it's the resistor!! Really, as you verified, it is a matter > of numerics. With a wide spread of admittances, values, whatever, > numeric precision becomes an issue. When you are getting strange > results that you cannot explain, consider that numeric precision is > likely to be the problem. > Most of the time, failure to converge means the circuit does not work. > In DC, it usually means there is no stable operating point. In this > case, failure to converge is the correct result. Any result that looks > stable is incorrect. the circuit is too simple for this. > OPT::short is only used to substitute for a resistance of 0. It is not > an "Rmin". If you explicitly specify R= (smaller than OPT::short) it > will be left as you specify. this is not happening in the switch. it has a hardwired value for OPT::short. is it intentional or an oversight? > > Also interesting: the node order makes a difference. i remember some > > experiments with alternative static orders in -uf, nothing really worked > > perfectly yet. i will have to port it to know better. obviously, > > changing the component order by hand gets more tricky when using > > schematic drawings eg. gnucsator. > > yes it does .. numeric precision again. The problem is figuring out up > front what order works better, in an efficient way. The cost of > finding a better order is likely to exceed the savings of having the > better order, and the order that looks better in one way may be worse > in another way. > > Example ... > suppose I want to solve ... x = a+b-c; > That could be (a+b)-c or a+(b-c) . > In theory, both should give the same results, but depending on the > values of a, b, and c one or the other will be better, and I cannot say > in general which one. yes. it's a tradeoff between numerical stability and speed. for once it takes time to compute the ordering. then, depending on when this happens, the matrix would have to be refilled, or shuffled accordingly. > Originally, I had intended to make the ordering algorithm pluggable. but it's a bit tricky. currently, the ordering is computed before the components have announced their needs (iwant_matrix calls). also, the incidence graph is not stored, only a lower bound for each spike a good ordering could be computed (pretty quickly) from the incidence graph and a loaded matrix. but if it is done only after load, then the matrix rebuild will take some extra time. all this needs to be done in plugin space. and it needs to support solutions in between the above. > I considered making the matrix solver pluggable, but there is too much > speed penalty to do that. The speed penalty of plugins is that > associated with virtual functions, which are real function calls that > cannot be inline. That would add a real function call to every > external matrix access. If you compile with -O0 (no optimization) you > get real function calls, and a 2x slower run time on average. doing *_load through raw double pointers instead of function calls with matrix coordinates could make pluggable solvers feasible. there would be some additional overhead in storing these pointers associated to branches alongside the matrix coordinates. a real use for this would be to compare matrix solvers easily. but there seems to be none avaliable. KLU (the one most hyped for circuit simulation) does not implement partial updates.. ignoring speed penalty for a moment, i have hacked s__solve.cc to pass the numerics to UMFPACK. a corresponding transient command s_tr_umf.cc in [1] now helps with attributing convergence issues. cheers felix [1] https://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/log/?h=sim From MAILER-DAEMON Fri Nov 09 06:51:40 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gL5K8-0004RZ-A4 for mharc-gnucap-devel@gnu.org; Fri, 09 Nov 2018 06:51:40 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gL5K5-0004RD-SN for gnucap-devel@gnu.org; Fri, 09 Nov 2018 06:51:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gL5K2-0006Kr-Ij for gnucap-devel@gnu.org; Fri, 09 Nov 2018 06:51:36 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:33642) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gL5Jt-0006CN-HE for gnucap-devel@gnu.org; Fri, 09 Nov 2018 06:51:27 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gL5Jn-0002OI-6X; Fri, 09 Nov 2018 12:51:19 +0100 Date: Fri, 9 Nov 2018 12:51:19 +0100 From: Felix Salfelder To: al davis Cc: gnucap-devel@gnu.org Message-ID: <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: [Gnucap-devel] orderings X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 11:51:38 -0000 Hi Al. On Sat, Nov 03, 2018 at 11:19:22AM +0100, Felix Salfelder wrote: > a good ordering could be computed (pretty quickly) from the incidence > graph and a loaded matrix. but if it is done only after load, then the > matrix rebuild will take some extra time. did something in that direction. some ordering is pluggable in the plug_order branch. with this, a static odering can be computed from the incidence graph. when the incidence graph is not constructed (forward, reverse), there is some overhead in the virtual iwant calls. i can't measure it. (but that's it). i wrote plugins that intercept and store the incidence graph, then pass it to algorithms shipped with boost. i have uploaded test diffs for reverse cuthill mckee [1]. perhaps interesting - the density gets better in most cases, eq*fg2.ckt is the notable exception, all others are not too bad. - the extra running time is still negligible, even without much tweaking. solving time drops a bit, perhaps compensating for order computation. - the numerical quality increases. it's not visible in many places, but some numerical zeroes are closer to zero, and sometimes the number of iterations goes down. it never goes up. my incmode example also seems to work with rcmk. have fun. felix [1] https://www.boost.org/doc/libs/1_68_0/libs/graph/doc/cuthill_mckee_ordering.html From MAILER-DAEMON Fri Nov 09 18:48:18 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLGVe-0001jc-3W for mharc-gnucap-devel@gnu.org; Fri, 09 Nov 2018 18:48:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLGVR-0001HB-V5 for gnucap-devel@gnu.org; Fri, 09 Nov 2018 18:48:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLGI3-00081p-5D for gnucap-devel@gnu.org; Fri, 09 Nov 2018 18:34:21 -0500 Received: from 11.freeelectron.net ([74.208.209.19]:42720) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLGHz-0007sQ-9L for gnucap-devel@gnu.org; Fri, 09 Nov 2018 18:34:13 -0500 Received: from [24.148.126.233] (helo=z) by 11.freeelectron.net with esmtp (Exim 4.80) (envelope-from ) id 1gLGHi-0005tt-TT; Fri, 09 Nov 2018 17:33:55 -0600 Date: Fri, 9 Nov 2018 18:33:49 -0500 From: al davis To: Felix Salfelder Cc: al davis , gnucap-devel@gnu.org Message-ID: <20181109183349.519bba7c@z> In-Reply-To: <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.208.209.19 Subject: Re: [Gnucap-devel] orderings X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 23:48:14 -0000 On Fri, 9 Nov 2018 12:51:19 +0100 Felix Salfelder wrote: > > a good ordering could be computed (pretty quickly) from the incidence > > graph and a loaded matrix. but if it is done only after load, then the > > matrix rebuild will take some extra time. > > did something in that direction. > > some ordering is pluggable in the plug_order branch. with this, a > static odering can be computed from the incidence graph. > > when the incidence graph is not constructed (forward, reverse), there is > some overhead in the virtual iwant calls. i can't measure it. (but > that's it). The run time overhead of a virtual call is that of a real function call, which means if it was going to be a real function call anyway the virtual overhead is insignificant. It becomes significant when it would have been inlined otherwise, and the function is so small that the code inside takes less time than a function call. Also, if you compile with "make debug", that's "-O0" (oh zero) which means no optimization, which means always real function calls. To measure speed, you need to compile with full optimization and debug off. Also, with small circuits this doesn't matter. It's only when the circuits get large that it matters. The tests in gnucap/tests are intended as correctness tests, not benchmarks. They are all too small to be meaningful as benchmarks, and must be that way so the test suite runs in a reasonable time. Back when I did the initial work, with the large circuits being considered, Spice run time would be measured in days. Having the same benchmark run in hours on what was to become gnucap was quite an achievement. > i wrote plugins that intercept and store the incidence graph, then pass > it to algorithms shipped with boost. i have uploaded test diffs for > reverse cuthill mckee [1]. perhaps interesting > > - the density gets better in most cases, eq*fg2.ckt is the notable > exception, all others are not too bad. These examples are too small to be significant, but what I see is maybe 50-50 in terms of density getting better. On eq* ... Reordering to overlap blocks improves the density number, but hurts incmode. Since this circuit is all linear, incmode is all or nothing, so you probably won't see the difference in this example. > - the extra running time is still negligible, even without much > tweaking. solving time drops a bit, perhaps compensating for order > computation. > - the numerical quality increases. it's not visible in many places, but > some numerical zeroes are closer to zero, and sometimes the number of > iterations goes down. it never goes up. my incmode example also seems > to work with rcmk. I am not sure what that means. What I see is arbitrary small differences that seem to be related to rounding errors. Which is really better could go either way. I can't tell without further study. It looks to me that the incmode example still doesn't work. > have fun. I think you will eventually conclude as I did back in 1985, and again back in 1992. ... that the fancy ordering algorithms really don't work as well as the simple ones. The existing ordering algorithm is not nothing at all. It's a "nearest neighbor" algorithm, on read-in. When you need to create a new node, just take the next one in line. Then reverse the whole thing. Considering how netlists are built, this actually results in a decent order, keeping nearby nodes nearby. It is not guaranteed to be optimal, actually not guaranteed to be anything at all, but it usually outperformed the common published algorithms at the time, especially when considering the run time of the ordering algorithm. To improve the algorithm, I think the best approach is to make one more pass to sort nodes within a block by degree, and leave it at that. You could do multiple passes, but I think even one fixed pass would do. Even that should be done before expansion. Suppose we have a degree array for a block something like this: 21432.33 ... 5 internal nodes, two connection nodes. The two connection nodes cannot be moved, but the internal nodes can be. The ideal order would have a degree array: 12234.33. So, if the numbers were 12345.67, the updated order would be 21543.67. I think this is as ideal as you can get. Try a bubble sort ... 21432.33 12324.33 .. one pass, not optimal but better. 12234.33 .. second pass, now optimal in this case. I really don't think you can do better than this. (Yes I know .. it's a challenge to try). Now .. how does all this relate to incmode? The sort I just proposed improves it, and that should be the highest priority. To further improve the algorithm, note how nonlinear the various connections are, and take the most linear ones first. Incmode isn't just incremental matrix update. It enables the possibility of not solving the whole matrix, and not processing some models. Of the test circuits provided the eq* are the only ones that are complex enough to be at all significant. Then you need some bigger circuits that might take hours or days to run. From MAILER-DAEMON Sat Nov 10 01:32:52 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLMpA-0001Lg-KO for mharc-gnucap-devel@gnu.org; Sat, 10 Nov 2018 01:32:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLMp7-00018O-TZ for gnucap-devel@gnu.org; Sat, 10 Nov 2018 01:32:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLMp6-0003eY-TY for gnucap-devel@gnu.org; Sat, 10 Nov 2018 01:32:49 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:35306) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLMp6-0003ck-JZ for gnucap-devel@gnu.org; Sat, 10 Nov 2018 01:32:48 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gLMp4-0003Yr-0d; Sat, 10 Nov 2018 07:32:46 +0100 Date: Sat, 10 Nov 2018 07:32:46 +0100 From: Felix Salfelder To: al davis Cc: gnucap-devel@gnu.org Message-ID: <20181110063245.ruhtg44exqal7xfb@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> <20181109183349.519bba7c@z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181109183349.519bba7c@z> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: Re: [Gnucap-devel] orderings X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 06:32:50 -0000 On Fri, Nov 09, 2018 at 06:33:49PM -0500, al davis wrote: > > when the incidence graph is not constructed (forward, reverse), there is > > some overhead in the virtual iwant calls. i can't measure it. (but > > that's it). > > The run time overhead of a virtual call is that of a real function > call, which means if it was going to be a real function call anyway the > virtual overhead is insignificant. It becomes significant when it > would have been inlined otherwise yes, currently, the iwant calls (to the matrix) are inlined. now, in plug_order they are not. my observation is, that the overhead is not significant. this will be more irrelevant if the ordering could be done before expand, as you suggest below. > Also, with small circuits this doesn't matter. It's only when the > circuits get large that it matters. it all happens during CARD_LIST::*_iwant, and the relative overhead there is independent of the circuit size. > I am not sure what that means. What I see is arbitrary small > differences that seem to be related to rounding errors. Which is > really better could go either way. I can't tell without further study. perhaps no longer necessary. > It looks to me that the incmode example still doesn't work. the original test works, mainly the dc convergence. i have added it to the branch. still, it is a fluke. it needs more thought to actually take numerical stability into account. ("incmode" is the wrong name for the test) > I think you will eventually conclude as I did back in 1985, and again > back in 1992. ... that the fancy ordering algorithms really don't > work as well as the simple ones. > > The existing ordering algorithm is not nothing at all. It's a "nearest > neighbor" algorithm, on read-in. When you need to create a new node, > just take the next one in line. This works for handwritten circuits. and i am not questioning how well it works. in some situations, manual intervention is really hard. the failing circuit has been created from a random (but simple enough) schematic. > when considering the run time of the ordering algorithm. it's not too bad. the untweaked global rcmk takes 0.01s on eq7 (589825 nodes). as a result the total simulation time drops from 0m30.252s to 0m26.289s. the drop seems to be purely due to density, but still. > To improve the algorithm, I think the best approach is to make one more > pass to sort nodes within a block by degree, and leave it at that. You > could do multiple passes, but I think even one fixed pass would do. > > Even that should be done before expansion. Certainly anything done before expansion will be (much) more efficient. i couldn't figure it out. it will likely introduce some other overhead. > Suppose we have a degree array for a block something like this: > 21432.33 ... 5 internal nodes, two connection nodes. > The two connection nodes cannot be moved, but the internal nodes can > be. The ideal order would have a degree array: 12234.33. >[..] > I really don't think you can do better than this. > (Yes I know .. it's a challenge to try). perhaps not in the 5 node example. i have seen extracted subcircuits with many more nodes. even if i can't do better than random, rcmk (or anything like that) might well do better. i am not sure i fully understand the implications on incmode, especially when circuits are deeply nested. > Now .. how does all this relate to incmode? The sort I just proposed > improves it, and that should be the highest priority. well, I somehow need to store the matrix stamps locally and lift the order to pre-expand. > To further improve the algorithm, note how nonlinear the various > connections are, and take the most linear ones first. my idea was to prioritize large elements on the diagonal. looks like a similar objective. lets discuss this another time. thanks felix From MAILER-DAEMON Sat Nov 10 04:27:52 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLPYW-00024z-K4 for mharc-gnucap-devel@gnu.org; Sat, 10 Nov 2018 04:27:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLPYT-0001rl-Sp for gnucap-devel@gnu.org; Sat, 10 Nov 2018 04:27:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLPYS-0000kl-4s for gnucap-devel@gnu.org; Sat, 10 Nov 2018 04:27:49 -0500 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]:33206) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLPYR-0000jR-VN for gnucap-devel@gnu.org; Sat, 10 Nov 2018 04:27:48 -0500 Received: by mail-oi1-x231.google.com with SMTP id x204-v6so3538388oia.0 for ; Sat, 10 Nov 2018 01:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UF+u4p1DRFnHz3q+GnxJdjiECOZNVd4BeANP9tNA9EY=; b=mXfpgsjn1RHwwqHDtVp4icUEWfdFmyDfItnHkBprtx+fvqkSHcZWhtPta3daUyX5+n 7454yd3UjCDpZW6G0bNH7d6hNVDkMoK4wKm9dkVlFrQO0UAjQFyZW6HVqQet/HLheh/9 UMwIkLbjRH1ehyx45Bb2kvSfKIwcn92h5ERwWOcOamlOq+XMD4N/4BrqcOQD2Q515tCY 8OUmDFh8kpneQt0aztAfg9tcwjT4RFJvYvG5Om6Vrz6p8PqPS10fDWO+hyv6RuNeDvsq 1CX2rtOmQf30xBYf50d3TNL20UMeuShud1u1aRyb5zggVcD1HgpkxBEXcTo75vC/B/2o +JHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UF+u4p1DRFnHz3q+GnxJdjiECOZNVd4BeANP9tNA9EY=; b=umcAtwDRyddNkxNws6nCo+DCR0Q5xh9xIb8hnqWqaVx34Um1Tac648ej658nzTTbQ8 rp6KDUzD4+WYeUQQaAlNZHK+j7aMREQGLxLUOCKmmnW/unYp9fN11YgaGYFZ6vKlhWM8 NYaPmVqr0FfCpm+AgQT8z+WCkYEhgTElsewZascrHdJxarj60yE0WVbmsOuf7NkS0Nap CDRbmC/VAyr2vrWPpv/YSVjxJ/FhdISFzn4aLjBIQ8mkqBSSOK3NFIRzMa+zB5rnyv+C Qt3XRq/VrKZaKyoGs93tB6P8radCn1OD6IrNhao4EQdYNyeT80oIzA5FWV6putYocxNe ZvdA== X-Gm-Message-State: AGRZ1gKlXhmTg72xilXtQ3iA6ejdfTOf1wkN223WMIpUmGrsK+oj7TL6 3hW57Y7YAbAPo75i14jE+GMPGbWy1IvNOLm9Ot6UUL02 X-Google-Smtp-Source: AJdET5foz3W5E72zJqciXLGvuUb+YV2DQu1oJ6H4yL2a3SySR44Rk0eO6/87Z5DqNgEKCxRdI+U/w7TSeEpQzF8ES5c= X-Received: by 2002:aca:62c3:: with SMTP id w186-v6mr7166011oib.320.1541842065536; Sat, 10 Nov 2018 01:27:45 -0800 (PST) MIME-Version: 1.0 From: Ruben Undheim Date: Sat, 10 Nov 2018 10:27:34 +0100 Message-ID: To: gnucap-devel@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::231 Subject: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 09:27:50 -0000 Hi, I've been playing around a bit with CMOS transistor models. Using some commercial BSIM4 models for NMOS and PMOS, I was surprisingly able to get it to load in ngspice without much trouble at all. It even simulated with reasonable results! When loading it in gnucap, I get a number of warnings and then gnucap crashes. Using the bsim465 model from gnucap-models [1], it seems like gnucap understands all the model parameters in the model, but it still gets some problems.. I get thousands of messages like this: parameter # not specified, using default parameter # not specified, using default .. .. and some like this: parameter ad not specified, using default parameter ad value is "NOT_INPUT" .. and then thousands of these: parameter # recursion too deep parameter # recursion too deep ... At last, it crashes with: gnucap: /usr/include/gnucap/spice-wrapper.cc:1074: virtual void DEV_SPICE::precalc_last(): Assertion `_maxEqNum == ckt()->CKTmaxEqNum' failed. Any ideas where I should start to debug? or if this is some kind of known issue/expected behaviour? Best regards Ruben [1] https://git.savannah.gnu.org/git/gnucap/gnucap-models.git From MAILER-DAEMON Sat Nov 10 05:02:20 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLQ5s-0002oh-Md for mharc-gnucap-devel@gnu.org; Sat, 10 Nov 2018 05:02:20 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLQ5q-0002oZ-KX for gnucap-devel@gnu.org; Sat, 10 Nov 2018 05:02:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLQ5p-0001YG-PC for gnucap-devel@gnu.org; Sat, 10 Nov 2018 05:02:18 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:35644) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLQ5o-0001Tj-6R for gnucap-devel@gnu.org; Sat, 10 Nov 2018 05:02:17 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gLQ5m-0000vD-OG; Sat, 10 Nov 2018 11:02:14 +0100 Date: Sat, 10 Nov 2018 11:02:14 +0100 From: Felix Salfelder To: Ruben Undheim Cc: gnucap-devel@gnu.org Message-ID: <20181110100214.mk7izlzzan2ol7i5@rip.d-labs.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 10:02:19 -0000 On Sat, Nov 10, 2018 at 10:27:34AM +0100, Ruben Undheim wrote: > I've been playing around a bit with CMOS transistor models. Using some > commercial BSIM4 models for NMOS and PMOS, I was surprisingly able to > get it to load in ngspice without much trouble at all. It even > simulated with reasonable results! When loading it in gnucap, I get a > number of warnings and then gnucap crashes. Hi Ruben. Thanks for your feedback. > At last, it crashes with: > gnucap: /usr/include/gnucap/spice-wrapper.cc:1074: virtual void > DEV_SPICE::precalc_last(): Assertion `_maxEqNum == ckt()->CKTmaxEqNum' > failed. > > Any ideas where I should start to debug? or if this is some kind of > known issue/expected behaviour? Disclaimer: i have never tried BSIM4. beyond that, the README file says BSIM4 passes tests. there are modelcards supplied in ls BSIM465/modelcard.*mos, do these work for you? from there, you could try to bisect. sometimes there are odd constraints, like number of connections (is not mentioned for BSIM465 though). all of it is essentially implemented in /usr/include/gnucap/spice-wrapper.cc, if it crashes, it could have to do with a parameter you used to switch on some feature with weird demands on the wrapper. the same happened to me recently with bjt. unlike ngspice17, ngspice28 has the bsim models you are looking for. perhaps it's time for a models-ngspice28? i have done models-ngspice28/bjt, but only to find that they made compilation harder, without changing the model at all. (note that newer models are distributed in verilog-A, and the priority is to implement a model compiler, together with all the other priorities.) thanks felix From MAILER-DAEMON Sat Nov 10 20:35:51 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLefH-0007XF-61 for mharc-gnucap-devel@gnu.org; Sat, 10 Nov 2018 20:35:51 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLefE-0007Wc-0u for gnucap-devel@gnu.org; Sat, 10 Nov 2018 20:35:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLefC-0005TG-PK for gnucap-devel@gnu.org; Sat, 10 Nov 2018 20:35:47 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:36924) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLefC-0005Li-IJ for gnucap-devel@gnu.org; Sat, 10 Nov 2018 20:35:46 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gLef3-0003uF-HI; Sun, 11 Nov 2018 02:35:37 +0100 Date: Sun, 11 Nov 2018 02:35:37 +0100 From: Felix Salfelder To: al davis Cc: gnucap-devel@gnu.org Message-ID: <20181111013537.damxal5l7yiquy6h@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> <20181109183349.519bba7c@z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181109183349.519bba7c@z> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: Re: [Gnucap-devel] orderings X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 01:35:49 -0000 On Fri, Nov 09, 2018 at 06:33:49PM -0500, al davis wrote: > Even that should be done before expansion. > > Suppose we have a degree array for a block something like this: > 21432.33 ... 5 internal nodes, two connection nodes. > The two connection nodes cannot be moved, but the internal nodes can > be. The ideal order would have a degree array: 12234.33. > So, if the numbers were 12345.67, the updated order would be 21543.67. > I think this is as ideal as you can get. I figured out ordering before expansion. conceptually, this is working. just after declaring a subcircuit there is enough structure available to do some ordering. the code for this could go into a DEV_SUBCKT plugin, e.g. virtual void BASE_SUBCKT::finish(). i don't know where to hook it, so i used a hack in CARD_LIST::push_back for testing. similarly, i managed to reorder the top level nodes. unlike subcircuit instances the top level cardlist does not go through new_subckt, the reindexing could possibly be done through _sim->_nm instead. (i used a hack, for now). it is much less obvious to me, where to put pluggable code for the top level node ordering. i guess this is important. I copied in the cmk ordering code, with some adaptions to connection nodes. it's not magic, but it deals with randomly ordered netlists well enough to be useful. it does not break eq3.fg2 as the global rcmk did. thanks felix From MAILER-DAEMON Sun Nov 11 14:32:30 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLvTC-0002WT-Pd for mharc-gnucap-devel@gnu.org; Sun, 11 Nov 2018 14:32:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLvTA-0002Vm-F0 for gnucap-devel@gnu.org; Sun, 11 Nov 2018 14:32:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLvT7-0005lW-Rv for gnucap-devel@gnu.org; Sun, 11 Nov 2018 14:32:26 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:38513) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLvT7-0005iN-4H for gnucap-devel@gnu.org; Sun, 11 Nov 2018 14:32:25 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gLvT1-00026D-K8; Sun, 11 Nov 2018 20:32:19 +0100 Date: Sun, 11 Nov 2018 20:32:19 +0100 From: Felix Salfelder To: al davis Cc: gnucap-devel@gnu.org Message-ID: <20181111193219.2vqd3vzz3zhcqhgj@rip.d-labs.de> References: <20181027232605.49ec506b@z> <20181028104919.cs3akmxqqlsjq4ar@rip.d-labs.de> <20181102212235.0f9881a6@z> <20181103101922.6bqpxktq5xo6i7hg@rip.d-labs.de> <20181109115119.gwcczckj7xa6aokr@rip.d-labs.de> <20181109183349.519bba7c@z> <20181110063245.ruhtg44exqal7xfb@rip.d-labs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181110063245.ruhtg44exqal7xfb@rip.d-labs.de> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: Re: [Gnucap-devel] orderings X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 19:32:29 -0000 On Sat, Nov 10, 2018 at 07:32:46AM +0100, Felix Salfelder wrote: > Certainly anything done before expansion will be (much) more efficient. > i couldn't figure it out. it will likely introduce some other overhead. now i could. it's in a command plugin I have added to gnucap-custom. the cmk command can be used to order the nodes in (individual) subckt models or in the top level circuit. it does not require changes in gnucap. however, i had to break into NODE_MAP, to access the private map. please consider a public void NODE_MAP::permute(int* p); in the official header. it permutes the user numbers, and plays nicely with the rest of it. > > To further improve the algorithm, note how nonlinear the various > > connections are, and take the most linear ones first. > > my idea was to prioritize large elements on the diagonal. looks like a > similar objective. lets discuss this another time. i'd be happy to know how you intend to address this. it's more important to me than speed, right now. thanks felix From MAILER-DAEMON Sun Nov 11 15:02:47 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLvwV-0000nC-B7 for mharc-gnucap-devel@gnu.org; Sun, 11 Nov 2018 15:02:47 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLvwT-0000n2-Sl for gnucap-devel@gnu.org; Sun, 11 Nov 2018 15:02:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLvwR-0004XT-Tn for gnucap-devel@gnu.org; Sun, 11 Nov 2018 15:02:45 -0500 Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]:43409) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLvwQ-0004Wx-GX for gnucap-devel@gnu.org; Sun, 11 Nov 2018 15:02:43 -0500 Received: by mail-oi1-x232.google.com with SMTP id j202-v6so5538885oih.10 for ; Sun, 11 Nov 2018 12:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ko1gWX9MMqdQT0EuTnt2W8GfDRRL6DqN52u0sB9ZtRk=; b=hlBV8arCFVh6JxnJ2DDndHhuWY4PAxzqxwIMLMWphDJQgkVyds01LQ7Dajh+wxCimn AF7kdvZ6O7muyFR6GjUwPaOdF7DfQpIIeKmaxeJsmhkZ7p9cq25sAW5AnQLwyjVyZuvm udDZjjnQFyLByI8slaBzAEv9FnV3D1wEj892YSyyI5SVz58jFIJlLTL693vXfMr6gHdq kkGA+9WMm1pT3kKnRDNVFLkVCu4bR5LLuni2mPXHJNevYccRnjRT7sSyiGNq5MAcYy2x QAU1t/M8VtjVXY8BY2AHxKQxDlfIg2Y26LcDcz7IVHlbmBc+lKbGO8AEItip2pZQbVCt +FHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ko1gWX9MMqdQT0EuTnt2W8GfDRRL6DqN52u0sB9ZtRk=; b=cZeCH63uUVuwjp/lGUxaagHORZVU9QYQ3ETPHA64dbXZwVQVPaJ8j113Bxc++lyx2r ciLPaDgg42e6Hi8t/boXJN0eYyolnv5IN/XBR2nfwvL+loi1ikq4onnydnCw6OnsYTt8 wOZUGWm48NhHNJNLbvC9vqtWV6WtMDX2U/VbmSk8dwXglXMka8gIMtxTCIB/051pFe9s v87sckmWVggti84y/HLDuJY/vcHTxaqQN1KtVFwAhiNNgkXW/eCkhynxcgcmrNuZHVEk W+YSGI9QDA5qSbEkn/r5tF3Zm0h+0c85StfD+FNyj6a70n3xHMvqbDWcd1eRkSUUTec2 kjig== X-Gm-Message-State: AGRZ1gKxX2tGgJQLfcUDZPg+Vp5oH2mSBdamb3LFkkaPIZklWScfKWgu P8SpnU9j7RqzfE8hUIg/yrInWvGgw5bJfYQNao6WpJ66 X-Google-Smtp-Source: AJdET5fnvMsFUn6mElA1vbnXcDVvWg8VnzlO1piIHWlVNXZWPmf3VluJ78Frn6qTxFWFNbvw2yRX8jrg4q3tqOEiPaA= X-Received: by 2002:aca:c646:: with SMTP id w67-v6mr8894679oif.122.1541966559983; Sun, 11 Nov 2018 12:02:39 -0800 (PST) MIME-Version: 1.0 References: <20181110100214.mk7izlzzan2ol7i5@rip.d-labs.de> <20181111134535.z3zq6624j22c63y3@rip.d-labs.de> In-Reply-To: <20181111134535.z3zq6624j22c63y3@rip.d-labs.de> From: Ruben Undheim Date: Sun, 11 Nov 2018 21:02:29 +0100 Message-ID: To: Felix Salfelder , gnucap-devel@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::232 Subject: Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 20:02:46 -0000 Hi, Thanks for info. So modelcard.nmos contains literal values for all the model paramaters, while my model use .params all over the place. I tried replacing some of the numbers with expressions, and then I get some messages also for that: parameter mismatchflag-4 not specified, using default parameter mismatchflag-4 not specified, using default parameter mismatchflag-4 value is "NOT_INPUT" parameter mismatchflag-4 not specified, using default parameter mismatchflag-4 not specified, using default parameter mismatchflag-4 value is "NOT_INPUT" parameter mismatchflag-4 not specified, using default after setting: TCJ = 'mismatchflag-4' So, maybe just gnucap does not support using .params like this? Is the syntax just different or is that functionality missing maybe? Best regards Ruben From MAILER-DAEMON Sun Nov 11 16:01:13 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gLwr3-0001gI-5m for mharc-gnucap-devel@gnu.org; Sun, 11 Nov 2018 16:01:13 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLwr1-0001eY-5U for gnucap-devel@gnu.org; Sun, 11 Nov 2018 16:01:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLwr0-0001cS-Cf for gnucap-devel@gnu.org; Sun, 11 Nov 2018 16:01:11 -0500 Received: from rip.d-labs.de ([2a01:4f8:d15:2cc8::2]:38648) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLwqz-0001aH-Pr for gnucap-devel@gnu.org; Sun, 11 Nov 2018 16:01:09 -0500 Received: from felix by rip.d-labs.de with local (Exim 4.89) (envelope-from ) id 1gLwqx-0005wU-9N; Sun, 11 Nov 2018 22:01:07 +0100 Date: Sun, 11 Nov 2018 22:01:07 +0100 From: Felix Salfelder To: Ruben Undheim Cc: gnucap-devel@gnu.org Message-ID: <20181111210107.yex5dnafrmrqqsoc@rip.d-labs.de> References: <20181110100214.mk7izlzzan2ol7i5@rip.d-labs.de> <20181111134535.z3zq6624j22c63y3@rip.d-labs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:4f8:d15:2cc8::2 Subject: Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 21:01:12 -0000 On Sun, Nov 11, 2018 at 09:02:29PM +0100, Ruben Undheim wrote: > So modelcard.nmos contains literal values for all the model > paramaters, while my model use .params all over the place. I tried > replacing some of the numbers with expressions, and then I get some > messages also for that: > > parameter mismatchflag-4 not specified, using default > [..] > > after setting: > TCJ = 'mismatchflag-4' Dear Ruben. this is a bit odd. but i can't say much without a complete example. note that you can declare parameters before or after the model. while both ways work, in the second case you see the warning. Gnucap sessions are interactive. this way a warning as an immediate response to the input read. > So, maybe just gnucap does not support using .params like this? Is the > syntax just different or is that functionality missing maybe? in spice language mode, gnucap should process spice like parameters as the usual spice implementations do. note that there are some differences in how well that works. spice has been designed for punch cards, and tweaked in many different directions since then. Gnucap also understads verilog. to get an incomplete idea, spice is to verilog is to system-verilog roughly like fortran is to C is to C++. hth felix From MAILER-DAEMON Tue Nov 13 21:35:27 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gMl1a-0002qC-SQ for mharc-gnucap-devel@gnu.org; Tue, 13 Nov 2018 21:35:26 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gMl1Y-0002pz-NB for gnucap-devel@gnu.org; Tue, 13 Nov 2018 21:35:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gMl1T-0001jZ-MG for gnucap-devel@gnu.org; Tue, 13 Nov 2018 21:35:24 -0500 Received: from 11.freeelectron.net ([74.208.209.19]:49186) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gMl1T-0001fU-Fv for gnucap-devel@gnu.org; Tue, 13 Nov 2018 21:35:19 -0500 Received: from [24.148.126.233] (helo=z) by 11.freeelectron.net with esmtp (Exim 4.80) (envelope-from ) id 1gMl1I-00024D-DO; Tue, 13 Nov 2018 20:35:08 -0600 Date: Tue, 13 Nov 2018 21:35:02 -0500 From: al davis To: Ruben Undheim Cc: gnucap-devel@gnu.org Message-ID: <20181113213502.6539d933@z> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.208.209.19 Subject: Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 02:35:25 -0000 On Sat, 10 Nov 2018 10:27:34 +0100 Ruben Undheim wrote: > Hi, > > I've been playing around a bit with CMOS transistor models. Using some > commercial BSIM4 models for NMOS and PMOS, I was surprisingly able to > get it to load in ngspice without much trouble at all. It even > simulated with reasonable results! When loading it in gnucap, I get a > number of warnings and then gnucap crashes. > > Using the bsim465 model from gnucap-models [1], it seems like gnucap > understands all the model parameters in the model, but it still gets > some problems.. > > I get thousands of messages like this: > parameter # not specified, using default > parameter # not specified, using default Is # supposed to introduce a comment? Your file may have some tail-comments .. .model noo nmos fffr=3344 fgt=94 # tail comment + more=3e4 Try editing the file to remove them. Whole line comments introduced by # should work, but sometimes the mid-line # doesn't. There are a lot of variants of spice syntax. Keeping track of them all can be crazy. Gnucap uses a single pass that sometimes misses the # as a comment in the middle of a line. > and some like this: > parameter ad not specified, using default > parameter ad value is "NOT_INPUT" This could also be related to the single pass parsing. Look for a # somewhere that might have turned the parameter ad into a comment. > and then thousands of these: > parameter # recursion too deep > parameter # recursion too deep Parameter recursion is supported, but with a limit to block infinite self-recursion. You might try setting option recursion higher. The default value is 20. But really, I think something happened in parsing that turned something into infinite recursion. > At last, it crashes with: > gnucap: /usr/include/gnucap/spice-wrapper.cc:1074: virtual void > DEV_SPICE::precalc_last(): Assertion `_maxEqNum == ckt()->CKTmaxEqNum' > failed. Something went wrong between the line : _maxEqNum == ckt()->CKTmaxEqNum; and the line assert(_maxEqNum == ckt()->CKTmaxEqNum); ????? If you send a file that demonstrates the problem I can look at it. All that stuff is probably due to one detail in file parsing. The optional plugins are not tested to the same high standard used for gnucap core. I can't keep up with them all. "spice-wrapper.cc" was really quite a challenge, mapping the incompatible interfaces, so gnucap can use the spice models from Berkeley, and 4 different variants of Spice that are incompatible with each other, without changes other than two small config files. It's time to add a fifth spice variant (a new NGspice), but working with spice code is not a pleasant experience. From MAILER-DAEMON Sat Nov 17 03:53:30 2018 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gNwM6-0005yV-A3 for mharc-gnucap-devel@gnu.org; Sat, 17 Nov 2018 03:53:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNwM3-0005yI-WF for gnucap-devel@gnu.org; Sat, 17 Nov 2018 03:53:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNwM3-0003d4-0V for gnucap-devel@gnu.org; Sat, 17 Nov 2018 03:53:27 -0500 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]:46940) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gNwM2-0003cZ-Qs for gnucap-devel@gnu.org; Sat, 17 Nov 2018 03:53:26 -0500 Received: by mail-oi1-x22a.google.com with SMTP id x202so10198469oif.13 for ; Sat, 17 Nov 2018 00:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fat4Gfs2DXee+tE245E1FhZPK5R1uhKU+sMfwh3hFHU=; b=Fi3NmgswpNajcHuxAhxHLBhGIrN7TaqtRl7fRKnKO1Avb1AuQns+EE05errhaH4Y2V 9Cvy8nr1N+L+aC4LZMVt55jQM6M34GB3Bz5nVAt43W8N06zJPiBLUfZwcD6XWXo3qGhr tYVZWUBbJwq0DQH+gv+1695/4OCXirnuWBGcgD+Q8wyMauD03M7Me8pyGxw2dwO1WuDM frbSHtm91KIX8k9knV3wVyP/JNH0/8EqL6feYxoqOcW/ChIKTeIlT+3tpyikhdNbvuht UTj5fHu5U1Kac0H7vRcGVNrVBee7KpSxIqf71WC9J/7/ye712wqsk8FHZVg3uTcb7oAJ Pm1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fat4Gfs2DXee+tE245E1FhZPK5R1uhKU+sMfwh3hFHU=; b=ZPkBzwZ4hFjzihmVJ0ytNI1KDWafwMzkE6Bn1U5+wHINFl8iXi27OrcBvRdQmr4sdW M+4vZWZbKVsO6IXIVY67ZMp9+qgizcM2FeHbwNyisQNuPokS0jxUwOBcbe5qB1YrvJoU gZMxRZKhrc8i+ayhE9Rlc3+opLIFKEbBH2FNhHAsc/NpNgfPchoKOEbQTNsaO5zS4w4n 1ccy94jZXS/+bb4sPyeqPEs7NIGKpM5zi3kkr+0Zgz1F3AEV0e/Wh3ioR5J/0TxPb8ll E7F3vdixEJVvdxqsTOHRIIGI2KgpuiKwCwSK3LBU0+cZoqauFG9hMgFz+kLMvqbIVjFB DGxQ== X-Gm-Message-State: AGRZ1gJ0orrC/SynDQ6C49mraph2mJmBybGV3scixNjfM6qlKyaKqKTK 0MkluNIY/tjhjQs3LA/LFi2+yVB40R7eB9Qf5l1BMAGD X-Google-Smtp-Source: AJdET5ey7LuzS/W8gRjPYmUnFLYHwrrGluKYwUa1cnbgq4OOIjnsBcrJ+DQTrPnqHeZBrzHXC0PQKfUhj/tYx/ywOiY= X-Received: by 2002:aca:bdc1:: with SMTP id n184-v6mr2922960oif.321.1542444805506; Sat, 17 Nov 2018 00:53:25 -0800 (PST) MIME-Version: 1.0 References: <20181113213502.6539d933@z> In-Reply-To: <20181113213502.6539d933@z> From: Ruben Undheim Date: Sat, 17 Nov 2018 09:53:16 +0100 Message-ID: To: ad211@freeelectron.net Cc: gnucap-devel@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::22a Subject: Re: [Gnucap-devel] Commercial BSIM4 model crashes gnucap X-BeenThere: gnucap-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for gnucap." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 08:53:29 -0000 Hi! > > I get thousands of messages like this: > > parameter # not specified, using default > > parameter # not specified, using default > > Is # supposed to introduce a comment? > Your file may have some tail-comments .. Actually the character "#" is not present at all in my input file. > .model noo nmos fffr=3344 fgt=94 # tail comment > + more=3e4 > > Try editing the file to remove them. > > Whole line comments introduced by # should work, but sometimes the > mid-line # doesn't. > > There are a lot of variants of spice syntax. Keeping track of them all > can be crazy. That is understandable :) > Gnucap uses a single pass that sometimes misses the > # as a comment in the middle of a line. > > > and some like this: > > parameter ad not specified, using default > > parameter ad value is "NOT_INPUT" > > This could also be related to the single pass parsing. Look for a # > somewhere that might have turned the parameter ad into a comment. > > > and then thousands of these: > > parameter # recursion too deep > > parameter # recursion too deep > > Parameter recursion is supported, but with a limit to block infinite > self-recursion. You might try setting option recursion higher. The > default value is 20. But really, I think something happened in parsing > that turned something into infinite recursion. I tried increasing the recursion default value, but then even worse problems appear (some memory corruption or similar). > > At last, it crashes with: > > gnucap: /usr/include/gnucap/spice-wrapper.cc:1074: virtual void > > DEV_SPICE::precalc_last(): Assertion `_maxEqNum == ckt()->CKTmaxEqNum' > > failed. > > Something went wrong between the line : > _maxEqNum == ckt()->CKTmaxEqNum; > and the line > assert(_maxEqNum == ckt()->CKTmaxEqNum); > ????? > > > If you send a file that demonstrates the problem I can look at it. All > that stuff is probably due to one detail in file parsing. I have not been able to narrow down a test file yet. I cannot send the file I have because I have it via an NDA unfortunately. I will see if I can demonstrate the problem in a custom file. > The optional plugins are not tested to the same high standard used for > gnucap core. I can't keep up with them all. > > "spice-wrapper.cc" was really quite a challenge, mapping the > incompatible interfaces, so gnucap can use the spice models from > Berkeley, and 4 different variants of Spice that are incompatible with > each other, without changes other than two small config files. It's > time to add a fifth spice variant (a new NGspice), but working with > spice code is not a pleasant experience. It is quite impressive actually. My input file contains this structure (from top to bottom): * load modules (in the top) * "spice" * Multiple global ".param" * Then some ".param"-s which use other params: - .param blabla = '5*another_param' * ".subckt mynch n1 n2 n3 n4 l=length w=width scale='some_param*3' ........" * Multiple ".param" within .subckt * a "main" device in the .subckt: "main n1 n2 n3 n4 nch w=w l=l ad=ad as=as .." * More ".param"s within .subckt * ".model nch.1 nmos (level = 54 lmin = '0', lmax = '0.1' cjd='cjn_ms*5' ........ )" * ".model nch.2 nmos (level = 54 lmin = '0.1', lmax = '0.2' cjd='cjn_ms*5' ........ )" * . .... * ".model nch.25 nmos (level = 54 lmin = '1.2', lmax = '1.3' cjd='cjn_ms*5' ....... )" * ".ends mynch" * Then the netlist using "mynch" * And in the bottom (my own lines not under NDA): R1 1 3 10000 V2 2 0 dc 0 X1 3 2 0 0 mynch l=70n w=280.0n m=1 nf=1 sd=220.0n ad=5.46e-14 as=5.46e-14 pd=9.5e-07 ps=9.5e-07 nrd=0.393 nrs=0.393 sa=195.00n sb=195.00n sca=4.23662 scb=0.000258052 scc=2.17139e-08 V1 1 0 dc 1.3 .PRINT DC V(VCC) V(1) V(3) i(ig) .DC V2 0 1.3 0.01 > dcsweep.out .control .END Best regards Ruben