Re: idt reset issue

Peter,
    You bring up a very important point. Allow me to reframe your point
into the following question:
Should assert be level sensitive or edge triggered?

Either is valid, but there are some important consequences to the choice.

Assume it is level sensitive. Then you can model the idt function as
follows:



In this case,
    V(out) <+ idt(0, V(in), 1);
is a valid implementation of a unity gain buffer. As a result, the
implementation must include the path from the assert input to the output
in the Jacobian when assert is high. Since the Jacobian includes all the
right terms the basic issue with convergence is avoided, but this
approach may be result in surprising behavior when /ic/ is dependent on
the /out/. Consider your example. If you make the /ic/ = -V(/out/), then
when /assert/ goes high the output will immediately jump to 0 because
that is the only value of V(/out/) with satisfies V(/out/)// = -V(/out/).

Now consider the case where it is edge triggered. In this case the idt
function keeps integrating as /assert /goes high. When /assert/ then
goes low, say at/ t/_a ,

where /y/ is the output, /x/ is the input, and
 
meaning that the /ic/ input is sampled at/ t/_a and /c/ becomes that
value for all time beyond (but not at) /t/_a .

I would expect that this would be the preferred implementation. If so, I
can add this description to the changes I proposed yesterday.

-Ken


Peter Liebmann wrote:
> I came across a problem (the bouncing ball) which works in VHDL_ams.  It
> is related to the example given by Ken for reset.  One has the case
> similar to:
>
>      reset=0;
>      @(timer(1,1))
>         reset=1;
>      V(out) <+ idt(1,-V(out), reset);
>
> V, in this case, behaves like a velocity which reverses when a ball hits
> the ground.
> If, at convergence, we reverse V and continue with NR iterations, we
> will never converge.  I wasn't sure if Ken's proposal meant to continue
> with the NR after convergence.
> NOTE: this situation will converge if, at convergence, we reset and then
> go to the next step, or reset, freeze the reset value and then
> continue with the NR.
>
> Peter Liebmann
>
> Ken Kundert wrote:
>> Sri,
>>     Yes, I think I can make it. I have created a proposal and Geoffrey
>> posted it on the website:
>> http://www.eda-stds.org/verilog-ams/htmlpages/public-docs/idt-proposal.pdf
>>
>>
>> -Ken
>>
>> Sri Chandra wrote:
>>> Hi Ken,
>>>
>>> Would you be available 9pm Pacific this thursday (Dec 7th) to discuss
>>> the idt proposal along with the proposed changes. If you can send the
>>> proposal across before the meeting that will be good.
>>>
>>> cheers,
>>> Sri
>>>
>>> Sri Chandra wrote:
>>>> Ken,
>>>>
>>>> By the way just thought will let you know that the timings of the
>>>> meeting has changed (from this week onwards). Now-a-days the meetings
>>>> are on thursday evenings at 9pm pacific.
>>>>
>>>> Please go ahead and send out a proposed change to the committee based
>>>> on the feedback that you received on the reflector. We can review that
>>>> as part of the meeting. Since idt is a very key item, and a fairly
>>>> major feature in Verilog-A quiet widely used, I would be very
>>>> uncomfortable changing the LRM without actually having a live
>>>> discussion in the call. So hopefully you would be able to attend one
>>>> of the upcoming meetings at this new time and we can discuss the new
>>>> document that you plan to post.
>>>>
>>>> Hope that is agreeable.
>>>>
>>>> Regards,
>>>> Sri
>>>>
>>>> cheers
>>>>
>>>> Ken Kundert wrote:
>>>>> Sri,
>>>>>     I have an on-going conflict that prevents me from calling into
>>>>> the
>>>>> meetings. I have published a description of the problem and the
>>>>> desired
>>>>> behavior. There has been some discussion on the reflector and
>>>>> nobody has
>>>>> presented any objections. Perhaps I should just send out a proposed
>>>>> change to the LRM and see what everyone thinks?
>>>>>
>>>>> -Ken
>>>>>
>>>>> Sri Chandra wrote:
>>>>>> Ken,
>>>>>>
>>>>>> I haven't been able to attend the recent calls but I hope to be back
>>>>>> online from this week onwards. I dont think this issue has been
>>>>>> discused
>>>>>> in the recent meetings. The committee has been reviewing independent
>>>>>> chapters and we are currently in the process of reviewing chapter 7
>>>>>> being edited by Marq Kole.
>>>>>>
>>>>>> The last I remember in the reflector was you were planning to
>>>>>> present
>>>>>> this item to go over it to the committee but you were unable to
>>>>>> attend
>>>>>> the meeting. If you are available and if you can present the
>>>>>> proposal at
>>>>>> one of the the committee meetings that will be great and we can
>>>>>> schedule
>>>>>> it in one of the upcoming calls.
>>>>>>
>>>>>> Regards,
>>>>>> Sri
>>>>>>
>>>>>> Ken Kundert wrote:
>>>>>>> Sri,
>>>>>>>      Was there any decision made on the idt issue? Would you like
>>>>>>> me to
>>>>>>> a cut at refining the description of idt in the LRM to avoid the
>>>>>>> ambiguity in its behavior?
>>>>>>>
>>>>>>> -Ken
>>>>>>>
>>>>>>> Ken Kundert wrote:
>>>>>>>> All,
>>>>>>>>    I apologize for missing the call this morning. It turns out
>>>>>>>> that
>>>>>>>> Thursday mornings are just too busy for me to attend.
>>>>>>>>
>>>>>>>> I have updated the document to include an model that patterns the
>>>>>>>> desired behavior. You can find the updated version at
>>>>>>>> http://designers-guide.org/private/vams-extensions/idt-issue.pdf
>>>>>>>>
>>>>>>>> Also, I would like to offer the use the my online forum for use by
>>>>>>>> the
>>>>>>>> Verilog-AMS committee. We used it when defining the compact model
>>>>>>>> extensions and I found it to be a very convenient way to carrying
>>>>>>>> on the
>>>>>>>> conversations about particular issues. It naturally separates the
>>>>>>>> discussion threads and makes them easy to follow. If you wanted
>>>>>>>> to do
>>>>>>>> this, I would give you a private board, so only invitees would be
>>>>>>>> allowed to see the board or contribute.
>>>>>>>>
>>>>>>>> -Ken
>>>>>>>>
>>>>>>>>
>>>>>>>> Geoffrey.Coram wrote:
>>>>>>>>> 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
>>
>