RE: Verilog-AMS question regarding retention

From: Muranyi, Arpad <arpad.muranyi_at_.....>
Date: Fri Oct 14 2005 - 13:06:29 PDT
Marq,

The short answer to your question below is probably "all of the above",
because this thread spiraled into each of those areas.  But a better
answer would be a short summary of this thread.

My problems started when I wrote a capacitor model the following way:

  analog begin
    if (analysis("static"))
      V(Out) <+ V0;
    else
      I(Out) <+ Scale * Cval * ddt(V(Out));
  end

I expected this to give me V0 at t=0 and then go with the
usual capacitive response from there.  Our in-house simulation
tool started at V0 at t=0 and then abruptly jumped to zero volts
for the next time step.  This is what you showed under "b".
In attempt to get this fixed in our tool I got into a dispute
with the developer, who quoted Section 5.3.1.3 "Value retention"
from the LRM as a justification for discarding the V0 value for
the second part of the IF statement.

This is when things started to spiral, because all kinds of
other comments and questions arose.  Now that the dust has
settled, it seems that we agree that Section 5.3.1.3 needs
to be fixed in the LRM to prevent this confusion.  This would
be something like you showed under "a".

In addition to providing a good example to section 5.3.1.3,
it would be useful to define how the simulator should resolve
the case you brought up in your example under "c".  There
seems to be no mention in the LRM what to do in that case.

This part of the discussion blew up in this thread because
I happened to use the idt() operator in my examples, and
there was an additional problem with its IC definition.
The LRM should probably also spell out more clearly that
the IC is only calculated once in DC or IC analysis, and
if the idt() operator happens to be absent during that
part of the simulation, the IC will be ignored as if it
wouldn't have been written down.  This may be somewhat
unintuitive from a physical or mathematical point of
view (at least to me) but I can live with that as long
as I am told that that is the case.

The biggest of all of these is the problem with the
example in Section 5.3.1.3 for which I just submitted
a MANTIS request.  I wish the rest of the clarifications
could be addressed too, but I do not want to overload
the MANTIS database with relatively small problems.
Or should I enter them all, and let another prioritization
step sort things out for what will be fixed in LRM 2.3?

Thanks,

Arpad
===========================================================

________________________________

From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole
Sent: Thursday, October 13, 2005 1:55 AM
To: verilog-ams
Subject: RE: Verilog-AMS question regarding retention



...
...
...

I think I start to understand your question. Could I rephrase your question as to what retention means? 

Is it that: 

a. If you provide contribution statements to both flow and potential branches, only the last one will be used in the solution. So: 

  branch b_in(plus, minus); 
  branch b_out(plus, minus); 

  analog begin 
    V(b_out) <+ I(b_in) * R; 
    I(b_out) <+ V(b_in) / R; 
  end 

would result in just one resistance, not two. 

b. If you provide a contribution statement in one time-step to the flow of a branch and in the next to the potential of the same branch, the previous values (and derivatives) of the flow will be discarded, as these should/can not influence the solution of the potential. 

  branch b_sw(ctrl, gnd); 
  branch b_out(plus, minus); 

  integer closed; 

  analog begin 
    closed = (V(b_sw) > vth ? 1 : 0); 

    if (closed) 
      V(b_out) <+ 0; 
    else 
      I(b_out) <+ 0; 
    end 

Like shown in the example in 5.1.5. 

c. Is the switch from implicit DC to regular transient (detected through the analysis() task) similar to an ordinary time-step, or is it a special situation? 

  branch b_cap(plus, minus); 

  analog 
    if (analysis("ic")) 
      V(b_cap) <+ initial_value; 
    else 
      I(b_cap) <+ ddt(C * V(b_cap)); 
  end 
Received on Fri Oct 14 13:06:35 2005

This archive was generated by hypermail 2.1.8 : Fri Oct 14 2005 - 13:07:09 PDT