Hi, The assumption that Verilog AMS is sitting on spice like or spice derived simulators is not true in the industry. Many of the fast spice simulators have verilog-ams support and while the term "spice" is used in the name the algorithms used are not really spice like or spice derived. There are other cases as well. This was the reason that VHDL-AMS was very careful to not prescribe the algorithms beyond an abstract definition. I agree with your comments on not assuming the algorithm implementation. That was one of the key requirements when both Verilog-AMS and VHDL-AMS were defined. Having one DC solution have a dependency on a different DC solution within a DC sweep seems like a bad idea to me and not consistent with the traditional definition of a DC sweep. The ability to paralyze or thread these analysis is removed if you do that. It would be similar to having one frequency point in an AC analysis be dependent on another frequency point (which is not how the analysis has typically been defined for small-signal AC). I have wondered what the meaning and intent of the phrase: 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 If it means that an event is generated going from one DC solution in a DC sweep to another then a rational would be helpful to understand the need. Regards David David W. Smith Synopsys Scientist Synopsys, Inc. Synopsys Technology Park 2025 NW Cornelius Pass Road Hillsboro, OR 97124 Voice: 503.547.6467 Main: 503.547.6000 Cell: 503.560.5389 FAX: 503.547.6906 Email: david.smith@synopsys.com http://www.synopsys.com Saber Accelerates Robust Design Predictable. Repeatable. Reliable. Proven. -----Original Message----- From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Mark Zwolinski Sent: Thursday, November 19, 2009 2:50 AM To: Geoffrey.Coram Cc: Ian Wilson; verilog-ams@eda.org Subject: Re: @above in analyses other than tran and dc sweep 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 19 08:52:40 2009
This archive was generated by hypermail 2.1.8 : Thu Nov 19 2009 - 08:52:58 PST