Ken, I did this work a number of years ago. If I remember correctly, I checked the reset value after convergence. I then reset if on, and continued to the next time point (I used "cross" so reset was set "on" at the present step then off at the next step). I think this fits into the rising edge model. I'm not sure if this messes up other applications, so use your judgment. Peter Liebmann Ken Kundert wrote: > 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 >>> >>Received on Thu Dec 7 17:43:10 2006
This archive was generated by hypermail 2.1.8 : Thu Dec 07 2006 - 17:43:23 PST