Geoffrey.Coram wrote: > The existence of multiple dc operating points is generally > swept under the rug. The fact is, the results of the > simulation of such a circuit can depend on the initial > guess in Newton's method, or whether one is even using > Newton or another solution method. > I agree. > So, you can either decide that @above has no meaning, because > you expect your simulator to evaluate a dc sweep by randomly > picking an order to evaluate the points, or you can be > pragmatic about it and decide that every spice-like > simulator I know of uses the previous sweep point as a > starting point for the current one, and therefore @above > could give you useful information. > In practice, I agree. But... > I suppose there's really no reason to assume that a simulator > uses Newton's method to solve the circuit, in which case the > fact that the ddx() operator requests the symbolic derivative > is making some unwarranted assumption about how the simulator > works; how dare we assume it needs a Jacobian? > ... this is the problem. Clause 8.2.2 states "Most circuit simulators use the Newton-Raphson (NR) method to solve this system." To me that says "don't assume". The point about the DC (or AC) sweep is that there is an unwritten assumption. That makes me uncomfortable. On this exact point, there may never be a problem because the pragmatic way to implement a sweep is to do it in order and there is no clear incentive to parallelize the algorithm. The general point, however, is that Verilog-AMS (and VHDL-AMS) deliberately does not specify the algorithms used. That's OK. We know that in practice and for the foreseeable future, Verilog-AMS will be sitting on top of a SPICE-like (and probably SPICE-derived) simulator. OK, but there are assumptions. Some of those assumptions are not written down anywhere. I cannot find *any* written evidence (other, I guess, than source code) that a sweep is performed in a monotonic order. The use of "can" or "may" might be correct according to the strict interpretation of the IEEE guidelines. In the context of clause 5.10.3.2, there is an implicit assumption being made. But the next sentence makes the algorithm explicit: "During a dc sweep, the above() function shall also generate an event when the expression crosses zero from below; however, the step size of the dc sweep is not controlled to accurately resolve the crossing." Notice the use of the word "shall". In other words, the algorithm is defined. This would seem to go against the philosophy of the LRM. One other point. I did a Google search on "spice sweep hysteresis" and found this from "SPICE for power electronics and electric power" by M. H. Rashid, Hasan M. Rashid, p499 on Google Books: "The most common cause of failure of the DC sweep analysis is an attempt to analyze a circuit with regenerative feedback, such as a Schmitt trigger. The DC sweep is not appropriate for calculating the hysteresis of such circuits, because it is required to jump discontinuously from one solution to another at the crossover point." It's slightly off-topic, but they've clearly been burned by this. A DC sweep is not the right way to explore hysteresis! Mark > -Geoffrey > > > Ian Wilson wrote: >> Suppose we run two simulations at values a,b,c for some swept variable, x. >> >> Surely the results for the simulation with x=b should be the same >> regardless of >> whether x had the value a or c in some previous simulation? >> >> I would expect all DC simulations of a circuit with hysteresis to >> produce the >> same result (for the same parameter values), since there is no concept >> of a previous >> state (unless you allow the simulator to start from the operating point >> calculated in some >> other step). >> >> --ian > > -- =================================================================== Professor Mark Zwolinski Electronic Systems & Devices Group Tel. (+44) (0)23 8059 3528 Electronics & Computer Science Fax. (+44) (0)23 8059 2901 University of Southampton Email. mz@ecs.soton.ac.uk Southampton SO17 1BJ, UK http://www.ecs.soton.ac.uk/~mz -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 19 02:51:02 2009
This archive was generated by hypermail 2.1.8 : Thu Nov 19 2009 - 02:51:59 PST