You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(5) 
_{Dec}
(4) 

2004 
_{Jan}
(12) 
_{Feb}
(9) 
_{Mar}
(2) 
_{Apr}
(9) 
_{May}
(15) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}
(4) 
_{Oct}
(5) 
_{Nov}
(4) 
_{Dec}

2005 
_{Jan}
(3) 
_{Feb}
(11) 
_{Mar}
(9) 
_{Apr}
(26) 
_{May}
(10) 
_{Jun}
(1) 
_{Jul}
(10) 
_{Aug}
(2) 
_{Sep}
(8) 
_{Oct}
(15) 
_{Nov}
(8) 
_{Dec}
(15) 
2006 
_{Jan}
(53) 
_{Feb}
(21) 
_{Mar}
(26) 
_{Apr}
(20) 
_{May}
(30) 
_{Jun}
(22) 
_{Jul}
(24) 
_{Aug}
(36) 
_{Sep}
(61) 
_{Oct}
(21) 
_{Nov}
(7) 
_{Dec}
(8) 
2007 
_{Jan}
(30) 
_{Feb}
(43) 
_{Mar}
(40) 
_{Apr}
(59) 
_{May}
(8) 
_{Jun}
(19) 
_{Jul}
(34) 
_{Aug}
(35) 
_{Sep}
(9) 
_{Oct}
(9) 
_{Nov}
(66) 
_{Dec}
(36) 
2008 
_{Jan}
(22) 
_{Feb}
(42) 
_{Mar}
(19) 
_{Apr}
(25) 
_{May}
(36) 
_{Jun}
(16) 
_{Jul}
(31) 
_{Aug}
(16) 
_{Sep}
(27) 
_{Oct}
(25) 
_{Nov}
(36) 
_{Dec}
(24) 
2009 
_{Jan}
(38) 
_{Feb}
(20) 
_{Mar}
(62) 
_{Apr}
(81) 
_{May}
(53) 
_{Jun}
(5) 
_{Jul}

_{Aug}
(1) 
_{Sep}
(2) 
_{Oct}
(9) 
_{Nov}
(8) 
_{Dec}
(5) 
2010 
_{Jan}
(1) 
_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(3) 
_{Sep}

_{Oct}
(2) 
_{Nov}
(2) 
_{Dec}
(10) 
2011 
_{Jan}
(4) 
_{Feb}
(6) 
_{Mar}
(29) 
_{Apr}
(19) 
_{May}
(4) 
_{Jun}

_{Jul}
(2) 
_{Aug}
(2) 
_{Sep}
(1) 
_{Oct}
(3) 
_{Nov}
(13) 
_{Dec}
(3) 
2012 
_{Jan}
(2) 
_{Feb}
(3) 
_{Mar}
(3) 
_{Apr}
(1) 
_{May}
(7) 
_{Jun}
(3) 
_{Jul}
(4) 
_{Aug}
(1) 
_{Sep}

_{Oct}
(6) 
_{Nov}
(6) 
_{Dec}
(4) 
2013 
_{Jan}
(41) 
_{Feb}
(8) 
_{Mar}
(14) 
_{Apr}
(15) 
_{May}
(15) 
_{Jun}
(95) 
_{Jul}
(91) 
_{Aug}
(20) 
_{Sep}
(19) 
_{Oct}
(47) 
_{Nov}
(29) 
_{Dec}
(55) 
2014 
_{Jan}
(56) 
_{Feb}
(7) 
_{Mar}
(16) 
_{Apr}
(14) 
_{May}
(3) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(2) 
_{Sep}
(4) 
_{Oct}
(10) 
_{Nov}
(35) 
_{Dec}
(51) 
2015 
_{Jan}
(31) 
_{Feb}
(28) 
_{Mar}
(4) 
_{Apr}
(31) 
_{May}
(6) 
_{Jun}
(23) 
_{Jul}
(16) 
_{Aug}
(2) 
_{Sep}
(10) 
_{Oct}
(9) 
_{Nov}
(3) 
_{Dec}
(6) 
2016 
_{Jan}
(14) 
_{Feb}
(8) 
_{Mar}
(11) 
_{Apr}
(7) 
_{May}
(1) 
_{Jun}
(6) 
_{Jul}
(5) 
_{Aug}
(6) 
_{Sep}
(3) 
_{Oct}
(10) 
_{Nov}
(12) 
_{Dec}
(9) 
S  M  T  W  T  F  S 


1

2
(2) 
3
(2) 
4
(7) 
5
(4) 
6
(6) 
7
(1) 
8

9

10

11

12

13

14
(8) 
15
(1) 
16
(8) 
17
(7) 
18
(8) 
19
(4) 
20

21
(6) 
22
(9) 
23
(16) 
24

25

26
(1) 
27

28
(1) 
29

30

31




From: Kevin Cameron <cameron.eda@gm...>  20130721 22:07:34

Just a couple of comments: While VerilogAMS needs discipline header files to work they are not really part of the language spec or any simulator, so the license isn't really import (just the copyright). You can also separate the the simulator distribution from the header distribution if needed. Al's approach with GNUcap is to make almost everything a "plugin", as such only the core needs to have the right licensing  the plugins can have different licenses and you can distribute them separately. Personally I'm envisaging the future of simulation as being an opensource core with more of an apps market where some tools are commercial. QuCs could do the same. Kev. PS: as a member of the VerilogAMS committee at Accellera I can't say I've seen any requests for license changes go by. On 07/19/2013 04:29 AM, Bastien ROUCARIES wrote: > On Thursday, July 18, 2013, Richard Crozier <r.crozier@...> wrote: >> All, >> >> Good news regarding this, I contacted Accellera and they are updating the >> manual regarding the .vams files to state they may be reused freely. Here >> is what will be added to start of Annex D containing the files: >> >>  Copyright(c) 20092013 Accellera Systems Initiative Inc. >>  1370 Trancas Street #163, Napa, CA 94558, USA. >>  >>  The material in this Annex is an essential part of the Accellera Systems Initiative ("Accellera") >>  VerilogAMS Language Standard. Verbatim copies of the >>  material in this Annex may be used and distributed without restriction. >>  All other uses require permission from Accellera IP Committee (iprchair@...). >>  All other rights reserved. >> >> >> Will this be sufficient from a debian point of view? > Non free and more important incompatible with gpl2 render qucs non distributable (and I am not willing to relicence my past and present > contribution to qucs in order to add an exception). > > Bastien >> Richard >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >  > See everything from the browser to the database with AppDynamics > Get endtoend visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Qucsdevel mailing list > Qucsdevel@... > https://lists.sourceforge.net/lists/listinfo/qucsdevel 
From: al davis <ad212@fr...>  20130721 14:55:30

On Sunday 21 July 2013, Soeren D. Schulze wrote: > Adding a series resistance to a voltage source seems both > more effective and more harmless to me  really, who is > going to notice 10u Ohm? It's a tossup. One way to model (I should say approximate) a voltage source is with a small series resistance, which is converted into a current source with shunt. Gnucap does it this way. It messes up the conditioning of the matrix somewhat. Another way is to add another equation, the equivalent of an extra node, representing the current. (Nullor model) Gnucap could do it this way, but doesn't. Another voltagesource plugin would give you a choice. It messes up the pattern of the matrix. Yet another way is to eliminate a node and solve the missing node by adding the voltage source voltage to the nearby node that you keep. All of these have their advantages and disadvantages, which may not be evident unless you look deeper and try to implement it. Similar reasoning applies to the inductor. Spice uses the internal node model of an inductor. Gnucap may use either. It adds the internal node only if there is mutual inductance. The spice method is a disaster in run time for a circuit with lots of inductors, like you get with parasitic extraction, the RLGC model of a system of coupled transmission lines. On Sunday 21 July 2013, Soeren D. Schulze wrote: > It's important for users to understand that leaving out > certain parasitic components sometimes doesn't simplify > things but actually makes them trickier. One of my favorite counterintuitive surprises here is the addition of transmission lines to a circuit to improve convergence. On the other hand, adding stray capacitance usually makes things worse. 
From: Soeren D. Schulze <soeren.schulze@gm...>  20130721 13:21:24

Am 21.07.2013 14:26, schrieb roucaries bastien: >> But of course "gmin" and "short" are modifications to the circuit. I >> think it would be possible to reduce the need for them by a better >> implementation of the algorithm. > > Gmin and gshort replace a lot of time the missing step not given by > the electrical engineer. In the case of biasing a tunnel diode, it > make sense from a phycical point of view: your source are not > perfectly constant but a heaviside step. Make sure not to confuse gnucap's "gmin" with Spice's "gmin". The former is similar to Spice's "rshunt". Is it always harmless to add a resistance of 1e12 Ohm to ground in each node? In most cases, it probably is, but users of circuit simulation programs should be educated about it, so there won't be any surprises. Adding a series resistance to a voltage source seems both more effective and more harmless to me  really, who is going to notice 10u Ohm? It's perhaps a good idea to either add this as a global option or incorporate it as a parameter in the ideal voltage source model. Currently, Qucs adds a virtual resistance on demand inside an integration step. I'm not sure if that's a good idea because it modifies the circuit while the simulation is already running, so the result from the previous integration step may be inconsistent. It's important for users to understand that leaving out certain parasitic components sometimes doesn't simplify things but actually makes them trickier. Sören 
From: roucaries bastien <roucaries.bastien+<qucs@gm...>  20130721 12:26:13

On Sun, Jul 21, 2013 at 2:03 PM, Soeren D. Schulze <soeren.d.schulze@...> wrote: > Am 21.07.2013 04:14, schrieb al davis: >> On Thursday 18 July 2013, Soeren D. Schulze wrote: >>> Thanks. I checked gnucap, which does the same thing, and if >>> I can trust some random web articles, Spice does it, >>> too. I haven't used Spice that much, but convergence seems >>> to be a bit better there, which I now can't explain any >>> more. >> >> Yes, that's the way they do it. >> >> Can you show me an example of a real working circuit that fails >> to converge in gnucap? I know that some do not converge. I >> want examples that I can study. > > Sorry, I meant to say that convergence in Spice is better than in Qucs. > In gnucap, it's even better. > > A set of "benchmark examples" would be actually nice. I know a test set > created by mathematicians > (https://pitagora.dm.uniba.it/~testset/report/testset.pdf) which has a > few electronic examples, but they solve the equations globally using > standard integrators. Yes it is really nice, we could now add a test suite to qucs. > For an academic example, take a differentiator: > > * Double differentiatior > .generator freq=10k phase=90 > V1 1 0 generator(1) > C1 1 0 10u IC=1 > H2 2 0 V1 1 > C2 2 3 10u IC=0 > V2 3 0 0 > H3 4 0 V2 1 IC=0.31831 > .print tran V(1) V(2) V(3) V(4) > .option reltol=0.001 method=trap short=10u > .tran 3u 1m uic > .END > > It fails once you lower "short". Mathematically speaking, the "short" > option makes a lot of sense because it lowers the index of the > underlying differentialalgebraic equation. > > To make things more difficult, add a third differentiator. > > If Qucs gets a gnucap backend for transient analysis anyway, maybe it's > better to implement improved algorithms in gnucap first? > > Are the goals of gnucap and Qucs compatible? Maybe it's even possible > to merge them into one. > >>> This is a bit surprising to me. For my Bachelor's thesis, I >>> had primarily looked at mathematical literature on this >>> topic, and they all write down the equation globally and >>> then apply some standard solver, avoiding the condition >>> problem. >> >> That works great for the simplest of simple problems. For the >> complex issues in circuit simulation there are other issues, >> leading to a need for a more heuristic approach. What you are >> talking about might have been state of the art about 1970, >> before Spice. > > Again, both approaches are mathematically equivalent, but the approach > that Spice (and gnucap and Qucs) uses is numerically at a disadvantage. > Things like that haven't really been researched until the 80's and > early 90's, so I doubt that Spice is stateoftheart concerning the > numerical integration algorithms. Yes I know they are few research on it. The problem as mthematician is the lack of physical sense. Sometimes the solution given by the math are not causal or are not good from a physical point of view. The problem lie mainly in use electrical engineer we forget to add constraint on the solutions. Another potential pitfall are pathological problem RS flip flop or dual state logic based on tunel diode are inherently hard to get DC solution. > Applying "gmin" and "short" to every node and every voltage source is a > very effective measure because it transforms the differentialalgebraic > equation into an ordinary differential equation. [Unless there is an > inductor in the circuit. Then you need to add "short" as a series > resistance to the inductor. But even without that, the worst thing you > can get is an index1 DAE, which is already much better than a > higherindex DAE.] > > But of course "gmin" and "short" are modifications to the circuit. I > think it would be possible to reduce the need for them by a better > implementation of the algorithm. Gmin and gshort replace a lot of time the missing step not given by the electrical engineer. In the case of biasing a tunnel diode, it make sense from a phycical point of view: your source are not perfectly constant but a heaviside step. > >> As a challenge to you .... Here's a really simple circuit, with >> some commands to analyze it. It should run in any simulator >> that supports spice syntax. I am curious what other simulators >> say, and how your algorithm would handle it. Gnucap gives a >> correct result. NGspice and LTspice do not. >> >> The "*>" lines are gnucap postprocessing commands. It >> calculates the period, rise time, and fall time. >> >> * switch as negative resistance oscillator >> SW1 1 0 1 0 SWITCH1 >> C1 1 0 1n >> I1 0 1 100u >> .MODEL SWITCH1 SW VT=2.5 VH=2.475 RON=1 ROFF=10MEG >> .print tran V(1) >> *>.print tran + r(SW1) iter(0) timef(sw1) control(0) >> *>.store tran v(1) >> .option method=trap numdgt=9 >> .tran 100e6 200e6 uic trace all >> *>.measure t2=cross("v(1)" cross=2 fall last) >> *>.measure t1=cross("v(1)" cross=2 fall last before=t2) >> *>.measure t0=cross("v(1)" cross=2 fall last before=t1) >> *>.measure tmin0=min("v(1)" arg last after=t0 before=t1) >> *>.measure tmin1=min("v(1)" arg last after=t1 before=t2) >> *>.measure tmax1=max("v(1)" arg last before=t1 after=t0) >> *>.param falltime=tmin1tmax1 >> *>.param risetime=tmax1tmin0 >> *>.param dt=t2t1 >> *>.eval falltime >> *>.eval risetime >> *>.eval dt >> .END > > Works for me in NGSpice, if I lower RELTOL. But the initial DC fails > everywhere. > > The circuit doesn't seem overly difficult to me, but gnucap has better > stepsize control, apparently. Bastien > > > Sören > >  > See everything from the browser to the database with AppDynamics > Get endtoend visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Qucsdevel mailing list > Qucsdevel@... > https://lists.sourceforge.net/lists/listinfo/qucsdevel 
From: Soeren D. Schulze <soeren.schulze@gm...>  20130721 12:03:32

Am 21.07.2013 04:14, schrieb al davis: > On Thursday 18 July 2013, Soeren D. Schulze wrote: >> Thanks. I checked gnucap, which does the same thing, and if >> I can trust some random web articles, Spice does it, >> too. I haven't used Spice that much, but convergence seems >> to be a bit better there, which I now can't explain any >> more. > > Yes, that's the way they do it. > > Can you show me an example of a real working circuit that fails > to converge in gnucap? I know that some do not converge. I > want examples that I can study. Sorry, I meant to say that convergence in Spice is better than in Qucs. In gnucap, it's even better. A set of "benchmark examples" would be actually nice. I know a test set created by mathematicians (https://pitagora.dm.uniba.it/~testset/report/testset.pdf) which has a few electronic examples, but they solve the equations globally using standard integrators. For an academic example, take a differentiator: * Double differentiatior .generator freq=10k phase=90 V1 1 0 generator(1) C1 1 0 10u IC=1 H2 2 0 V1 1 C2 2 3 10u IC=0 V2 3 0 0 H3 4 0 V2 1 IC=0.31831 .print tran V(1) V(2) V(3) V(4) .option reltol=0.001 method=trap short=10u .tran 3u 1m uic .END It fails once you lower "short". Mathematically speaking, the "short" option makes a lot of sense because it lowers the index of the underlying differentialalgebraic equation. To make things more difficult, add a third differentiator. If Qucs gets a gnucap backend for transient analysis anyway, maybe it's better to implement improved algorithms in gnucap first? Are the goals of gnucap and Qucs compatible? Maybe it's even possible to merge them into one. >> This is a bit surprising to me. For my Bachelor's thesis, I >> had primarily looked at mathematical literature on this >> topic, and they all write down the equation globally and >> then apply some standard solver, avoiding the condition >> problem. > > That works great for the simplest of simple problems. For the > complex issues in circuit simulation there are other issues, > leading to a need for a more heuristic approach. What you are > talking about might have been state of the art about 1970, > before Spice. Again, both approaches are mathematically equivalent, but the approach that Spice (and gnucap and Qucs) uses is numerically at a disadvantage. Things like that haven't really been researched until the 80's and early 90's, so I doubt that Spice is stateoftheart concerning the numerical integration algorithms. Applying "gmin" and "short" to every node and every voltage source is a very effective measure because it transforms the differentialalgebraic equation into an ordinary differential equation. [Unless there is an inductor in the circuit. Then you need to add "short" as a series resistance to the inductor. But even without that, the worst thing you can get is an index1 DAE, which is already much better than a higherindex DAE.] But of course "gmin" and "short" are modifications to the circuit. I think it would be possible to reduce the need for them by a better implementation of the algorithm. > As a challenge to you .... Here's a really simple circuit, with > some commands to analyze it. It should run in any simulator > that supports spice syntax. I am curious what other simulators > say, and how your algorithm would handle it. Gnucap gives a > correct result. NGspice and LTspice do not. > > The "*>" lines are gnucap postprocessing commands. It > calculates the period, rise time, and fall time. > > * switch as negative resistance oscillator > SW1 1 0 1 0 SWITCH1 > C1 1 0 1n > I1 0 1 100u > .MODEL SWITCH1 SW VT=2.5 VH=2.475 RON=1 ROFF=10MEG > .print tran V(1) > *>.print tran + r(SW1) iter(0) timef(sw1) control(0) > *>.store tran v(1) > .option method=trap numdgt=9 > .tran 100e6 200e6 uic trace all > *>.measure t2=cross("v(1)" cross=2 fall last) > *>.measure t1=cross("v(1)" cross=2 fall last before=t2) > *>.measure t0=cross("v(1)" cross=2 fall last before=t1) > *>.measure tmin0=min("v(1)" arg last after=t0 before=t1) > *>.measure tmin1=min("v(1)" arg last after=t1 before=t2) > *>.measure tmax1=max("v(1)" arg last before=t1 after=t0) > *>.param falltime=tmin1tmax1 > *>.param risetime=tmax1tmin0 > *>.param dt=t2t1 > *>.eval falltime > *>.eval risetime > *>.eval dt > .END Works for me in NGSpice, if I lower RELTOL. But the initial DC fails everywhere. The circuit doesn't seem overly difficult to me, but gnucap has better stepsize control, apparently. Sören 
From: al davis <ad212@fr...>  20130721 02:14:52

On Thursday 18 July 2013, Soeren D. Schulze wrote: > Thanks. I checked gnucap, which does the same thing, and if > I can trust some random web articles, Spice does it, > too. I haven't used Spice that much, but convergence seems > to be a bit better there, which I now can't explain any > more. Yes, that's the way they do it. Can you show me an example of a real working circuit that fails to converge in gnucap? I know that some do not converge. I want examples that I can study. As to Spice ..... often the models are the same, and in this case I expect convergence to be the same. Sometimes there are differences such as time stepping that result in convergence on one, and nonconvergence on the other. Convergence checking is not as strict in spice, so I have seen a few cases where gnucap reports a convergence failure and spice does not, but gives incorrect results. Which would you rather have .... a simulator that correctly tells you when there is a problem? .. or a simulator that glosses over it, giving you an incorrect result and the feeling that all is well? What behavior is correct for a circuit that does not have a stable DC operating point? > This is a bit surprising to me. For my Bachelor's thesis, I > had primarily looked at mathematical literature on this > topic, and they all write down the equation globally and > then apply some standard solver, avoiding the condition > problem. That works great for the simplest of simple problems. For the complex issues in circuit simulation there are other issues, leading to a need for a more heuristic approach. What you are talking about might have been state of the art about 1970, before Spice. As a challenge to you .... Here's a really simple circuit, with some commands to analyze it. It should run in any simulator that supports spice syntax. I am curious what other simulators say, and how your algorithm would handle it. Gnucap gives a correct result. NGspice and LTspice do not. The "*>" lines are gnucap postprocessing commands. It calculates the period, rise time, and fall time. * switch as negative resistance oscillator SW1 1 0 1 0 SWITCH1 C1 1 0 1n I1 0 1 100u .MODEL SWITCH1 SW VT=2.5 VH=2.475 RON=1 ROFF=10MEG .print tran V(1) *>.print tran + r(SW1) iter(0) timef(sw1) control(0) *>.store tran v(1) .option method=trap numdgt=9 .tran 100e6 200e6 uic trace all *>.measure t2=cross("v(1)" cross=2 fall last) *>.measure t1=cross("v(1)" cross=2 fall last before=t2) *>.measure t0=cross("v(1)" cross=2 fall last before=t1) *>.measure tmin0=min("v(1)" arg last after=t0 before=t1) *>.measure tmin1=min("v(1)" arg last after=t1 before=t2) *>.measure tmax1=max("v(1)" arg last before=t1 after=t0) *>.param falltime=tmin1tmax1 *>.param risetime=tmax1tmin0 *>.param dt=t2t1 *>.eval falltime *>.eval risetime *>.eval dt .END > Apparently, electronic engineers and mathematicians don't > talk to each other enough... Yes .. the mathematicians could learn a lot from the engineers if they would talk more. 