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 >
This archive was generated by hypermail 2.1.8 : Thu Oct 05 2006 - 15:16:58 PDT