Re: @above in analyses other than tran and dc sweep

For the purposes of reporting ($strobing) the first time a
quantity crosses zero, one could certainly write the
simulator such that, when it pieces together the chunks
from different processors, it determines when the message
should be printed.  Simulators already have to deal with
the fact that $strobe output has to be remembered during
iterations and only printed after a converged iteration.
One would also need to take care with @initial_step and
@final_step, if the sweep is broken up into pieces.

I haven't thought much about models where the actual
operation depends on the result of an event; it's not
something that should be done in a compact model, where
my expertise lies.

-Geoffrey


Marq Kole wrote:
> Hi Mark,
> 
> Your remark on parallelization is a good one. A reasonable approach to improve performance of a DC sweep on a multi-threaded or multi-CPU system is break up the sweep in successive chunks and assign each of these chunks to a separate thread or core. However, the assumptions apparently underlying the DC sweep for circuits with hysteresis , but also the handling of global events for DC sweep in Verilog-A invalidate this approach! Verilog-AMS is essentially confined to single-threaded execution by the standard. Perhaps (... opening another can of worms ...) there's some room to reconsider some of the standard text in the light of multi-threaded execution.
> 
> Cheers,
> Marq
> 
> -----Original Message-----
> From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Mark Zwolinski
> Sent: Thursday 19 November 2009 11:50
> 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
>>
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.