Re: idt reset issue

From: Ken Kundert <ken_at_.....>
Date: Thu Oct 05 2006 - 15:16:40 PDT
Ilya,
    The assert argument can indeed be bias dependent. But I don't see
how this implies that there need be a delay between when the reset is
applied and when it can take effect. Are you trying to avoid having to
modify the Jacobian during reset? I'm afraid this is unavoidable as the
reset might be applied during DC, in which case time steps cannot save
you as there are no time steps. In fact, this is another problematic
aspect of the Cadence implementation. It does not correctly include in
the Jacobian the dependency of the output on the reset input when reset
is asserted. This makes the reset feature of the idt function unusable
in small-signal analyses, such as the RF small-signal analyses.

-Ken

Ilya Yusim wrote:
> Ken,
> 
>     The assert argument in idt can be bias dependent. (Is that correct?)
> So it takes a solution on one step to determine that idt should be reset
> and then only the next step can use the new reset idt value.  We would
> have to specify a way of resolving on the same step with the new idt
> value.
> 
> Ilya
> 
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Geoffrey.Coram
> Sent: Wednesday, October 04, 2006 1:18 PM
> To: VerilogAMS Reflector
> Subject: idt reset issue
> 
> Resending for Ken Kundert; original message bounced (too long).
> Attachment has been saved as
> http://www.verilog.org/verilog-ams/htmlpages/public-docs/idt-issue.pdf
> 
> 
> ----------------- Original Message ------------- All,
>     I'd like to join the meeting tomorrow and discuss the reset feature
> of the idt function. I have not had much luck using this feature through
> the years, and recently had a situation where I really needed it.
> Unfortunately, I found the Cadence implementation unsuitable once again,
> and when I dug in to it I found the LRM silent on critical aspects of
> this feature. I have attached a very short document that illustrates the
> issue and proposes what I believe to be the desirable behavior. If you
> all agree I will work on coming up with the needed modifications to the
> LRM.
> 
> -Ken
> 

Received on Thu Oct 5 15:16:54 2006

This archive was generated by hypermail 2.1.8 : Thu Oct 05 2006 - 15:16:58 PDT