Ken, Why isn't this just a matter of carefull modelling? The signal to disable/enable the cross can be fed through a transition filter @(cross(transition(active, 0, 10p) * V(smpl) - 0.5, +1)) state = V(in); or it can be part of another cross event that does nothing: @(cross(active - 0.5, +1)); or just issues a discontinuity warning: @(cross(active - 0.5, +1)) $discontinuity; Regards, Marq Ken Kundert <ken@designers-guide.com> 07-06-2006 20:06 To Marq Kole/EHV/RESEARCH/PHILIPS@PHILIPS cc Verilog-AMS LRM Reflector <verilog-ams@server.verilog.org> Subject Re: Merged version of chapter 6 Classification Marq, Your proposed solution has the issue that the act of disabling the cross will often cause a threshold crossing, and that crossing occurs on at a abrupt discontinuity, which cause the simulator a lot of work as it tries to resolve the crossing in the fact of the discontinuity. At a minimum this could cause a substantial slow down, or it could result in the simulator crashing. -Ken Marq Kole wrote: > > Sri, Ken, > > I could also switch off the generation of cross events by changing the > expression argument of a cross of above event: > > module sh_select1 (in, out, smpl, select) ; > output out; > input in, smpl, select; > electrical in, out, smpl, select; > > real state; > integer active; > > analog begin > active = V(select) > 0; > @(cross(active * V(smpl) - 0.5, +1)) > state = V(in); > V(out) <+ transition(state, 0, 100p) ; > end > > endmodule > > Based on the value of select the cross function will either do nothing > (expr is a constant negative value) or select events based on the rising > edges of the V(smpl) signal. No error control will be invoked as no > crossing happens, so the overhead in simulation should be as small as > when using an expression in the "dir" argument in a Cadence simulator: > > module sh_select2 (in, out, smpl, select) ; > output out; > input in, smpl, select; > electrical in, out, smpl, select; > > real state; > integer active; > > analog begin > active = V(select) > 0; > @(cross(V(smpl) - 0.5, +1 + (1 - active))) > state = V(in); > V(out) <+ transition(state, 0, 100p) ; > end > > endmodule > > Or is there anything I overlooked here? > > Cheers, > Marq > > > Marq Kole > Competence Leader Analog Simulation, Philips ED&T > > > > > > > > > > *Ken Kundert <ken@designers-guide.com>* > > Sent by: > owner-verilog-ams@server.verilog.org > > 07-06-2006 07:15 > > > To > Sri Chandra <srikanth.chandrasekaran@freescale.com> > cc > Verilog-AMS LRM Reflector <verilog-ams@server.verilog.org> > Subject > Re: Merged version of chapter 6 > Classification > > > > > > > > > > Sri, > I have embedded my responses below. There are two responses. > > -Ken > > Sri Chandra wrote: >> Ken, >> >> Ken Kundert wrote: >>> Sri, >>> Hmmm. I was the one that originally defined the behavior of the >>> cross function, and it was definitely the intent that the function be >>> disabled when a value other that +1, -1, or 0 was provided for the >>> direction. Otherwise it keeps performing error control even when the >>> events are not needed, slowing down the simulation. I know the Cadence >>> implementations provide this functionality because I have used it. I >>> have also documented this behavior in my book. It is unfortunate that >>> this important detail was overlooked when writing the LRM. I strongly >>> encourage the committee to consider making this change to the >>> description of both the cross and last_crossing functions. >>> >> >> I guess this intent was never documented in the LRM, that any other >> values to direction argument would disable the cross functionality. And >> so this aspect has not been considered at all for the @above >> functionality given that we dont have a direction argument for this >> event. I am not sure how many implementations interpret it in that >> fashion ie. arguments not +1, 0, -1 disable the cross, and this is going >> to lead to compatibility issues with existing implementations. >> >> There are two aspects to it in my opinion: >> >> 1. We would need a consistent way to enable/disable events than basing >> it on the values of the certain arguments like direction etc. I agree >> setting a very high period for timer is equivalent to disabling it. I >> guess the other alternative that Graham was suggesting in one of our >> conversations is to allow events in an conditional statement. Currently, >> I don't think events like cross/timer etc are allowed in conditional >> if-else, which i believe is allowed in digital. Graham can comment more >> on this syntax change. >> >> 2. Secondly, the behavior should be clearly defined when events like >> cross is switched on and off, instead of just providing a means to turn >> them on/off. > > Agreed, however while it is conceptually possible to place a timer > function in a time or signal dependent conditional, it is not a good > idea to put the cross function in such a conditional. The reason being > is that it cannot observe the signal except at the time steps chosen by > the simulator, and it is possible for the signal to cross its threshold > between when the conditional becomes active and when the simulator > decides to actually evaluate the conditional. In this case the cross > would not catch the transition. Consider the following code > > if ($abstime > 1.5) begin > @(cross(cos($abstime))) begin > ... > end > end > > In this case assume that the simulator places timepoints at 1.4s and > 1.6s. Then the user has every right to expect the cross function to fire > at 1.57s but it won't. That is because the first time it will see its > argument (at 1.6s) it will be beyond the crossing at 1.57s. > >>> Concerning the timer function, that question is answered at least >>> partially in the LRM. Read the section on "Constant versus dynamic >>> arguments". It clearly states that the start_time and period arguments >>> of the timer function are dynamic, meaning that they are allowed to >>> change though out an analysis. This rules out the first choice, that the >>> time of the next event would be based on the original start time >>> (start_time would have to be a static parameter for that to be the >>> case). However, there is another choice you did not list, and that is >>> that the next event would be tentatively scheduled for the time >>> associated with the current value of start_time and period. What I mean >>> by this is that the timer function does not remember previously >>> scheduled events. Rather the timer function would only register an event >>> at the current time Tnow if it is such that >>> Tnow = n*period + start_time >>> for some integer n and for the currently specified values of period and >>> start_time, the values that are present at Tnow, not the values that >>> were present when the last timer event occurred. >> >> Yes, the LRM does state that the start_time and period are dynamic >> arguments, but once again not very clear in terms of how the simulators >> are meant to behave when this condition is exploited ie. when these >> values change. >> >> Isnt the above the same as scheduling the timer with approach #1 that i >> mention where we use the original start_time and the new period. In your >> formulation, lets assume that the time period changed for "period1" to >> "period2" we are still using the scheduling of next event based on the >> original start_time which hasn't changed in the particular example i am >> considering. I am not saying that this is a wrong approach, but needs to >> be documented properly. Sorry if all this is very confusing and i am not >> being clear in bringing out my point. >> >> The other way of looking at the start_time for a timer event is, its >> considered only for the first trigger of the timer. Once a timer event >> is triggered the start_time value does not have any bearing on the >> future time events (if the start_time is constant during the >> simulation). If the "period" argument is the only dynamic aspect in a >> particular example model, then any changes to the period is relative to >> when the timer triggered last. Of course, if the start_time is changing >> then we need to consider the new start_time. >> >> cheers, >> Sri > > Does the timer function trigger an event at > Tevent = Tstart + N*Tperiod > or at > Tevent = Tstart + Tperiod1 + Tperiod2 + Tperiod3 + ... > Is that your question? > > I think this is ambiguous in the LRM, though I believe we were thinking > the former rather than the latter when the behavior of the timer > function was first defined. Considering the issue in retrospect, the > first definition has the the following benefits > 1. it is not subject to phase drift > 2. its behavior is well defined if the simulator start time is greater > than Tstart > 3. its behavior is well defined if the simulator skips over one or more > events, as an envelope analysis would likely do. > >>> This is the original >>> intent of the timer function, that it react instantly to the values >>> specified by the user and not that the user has to wait for an event to >>> occur before the changing the settings for the next event. This allows >>> the user to disable the timer function and then re-enable it later. You >>> can disable it by setting either the period or the start time to a very >>> large value, and then you re-enable it by setting them back to >>> reasonable values. If you have to wait for an event before resetting >>> them, then the timer would never be re-enabled. >>> >>> -Ken >>> >>> >>> >>> Sri Chandra wrote: >>> >>>> Hi all, >>>> >>>> Interesting point about turning off the cross operator...But from my >>>> understanding the language intent was to allow +1, 0, or -1 and has been >>>> like that for a while...I am not sure whether direction argument value >>>> should be used for that purpose, infact above does not even use a >>>> direction operator. >>>> >>>> Now coming to something bit related, we have had a few queries from >>>> users regarding the timer event especially in the case of dynamically >>>> changing period. Once again "dynamic"... :-) Here, by dynamic i mean, a >>>> timer has been triggered with start_time st1, and period p1. During the >>>> transient simulation the period is now changed to p2 for that timer. >>>> >>>> How does one calculate the next event that needs to be triggered for the >>>> timer? Is it based on the very original start_time and calculating the >>>> next event based on that or is it based on when the timer event fired >>>> last? >>>> >>>> ie. >>>> >>>> next_timer_event = st1 + N*p2; N=1,2,3,... >>>> >>>> or >>>> >>>> next_timer_event = last_time_event_fired + N*p2 >>>> >>>> cheers, >>>> Sri >>>> >>>> >>>> Sri Chandra wrote: >>>> >>>>> Ken, >>>>> >>>>> Thanks for the detailed feedback for Chapter 6. I will try to >>>>> incorporate the corrections/comment you have noted in this email >>>>> before we do the review. (Since you have volunteered i will discuss >>>>> with you which points you can help me with in updating this chapter). >>>>> >>>>> On a more general note, with regards to the discussions on >>>>> genvar_expression vs constant expressions, the genvar_expressions are >>>>> strictly used to refer to expressions that use the genvar identifier. >>>>> So this is strictly used only in the context of analog for loops where >>>>> we have the initialization, conditional and increment expressions >>>>> based on genvar, and in the digital for loop for the generate blocks. >>>>> For any other expressions which can be evaluated pre-simulation we are >>>>> using constant expressions syntax. I guess "dynamically executed" is >>>>> probably a bit vague on what it means - probably we should say that if >>>>> the expression can be evaluated to a constant value pre-simulation or >>>>> something like that... >>>>> >>>>> Graham might have further thoughts on this from a syntax point of view >>>>> and introducing a "genvar" conditional as you have suggested. >>>>> >>>>> cheers, >>>>> Sri >>>>> >>>>> >>>>> >>>>> Ken Kundert wrote: >>>>> >>>>>> Geoffrey, >>>>>> In reading your chapter 6 I noticed the following things ... >>>>>> >>>>>> 1. On the top of page 112 it says "The left-hand side shall not use a >>>>>> port access function from Section 5.1.4.". I'd sure like to get rid of >>>>>> that restriction. As a restriction it does not provide any real >>>>>> benefit, >>>>>> but it does take away a nice capability. For example, if I had the >>>>>> ability to assign to a port branch, then I could easily make a series >>>>>> resistor or inductor using >>>>>> V(<d>) <+ rd*I(<d>) + ld*ddt(I(<d>); >>>>>> This is nice for semiconductors because it eliminates that whole >>>>>> internal node/external node confusion. It also makes it easy to add >>>>>> series parasitics from outside an existing module without modifying >>>>>> the >>>>>> module or knowing anything about its internal structure >>>>>> V(<inv.out>) <+ rout*I(<inv.out>); >>>>>> I believe that one can already do this with shunt parasitics, but not >>>>>> with series parasitics. This addresses that inconsistency. >>>>>> >>>>>> 2. In that same paragraph, where it says "unless the conditional >>>>>> expression is a constant expression", shouldn't it use the term >>>>>> "genvar >>>>>> expression" rather than "constant expression"? >>>>>> >>>>>> 3. The example at the end of page 112 seems out of place. The >>>>>> paragraph >>>>>> that precedes it is talking about branches and flows, yet the example >>>>>> does not really demonstrate branches or flows. In fact, the example >>>>>> could just as easily be a signal-flow example if you change the >>>>>> electrical discipline to voltage. I was kind of expecting the >>>>>> author to >>>>>> introduce the branch declaration and then give an example that uses >>>>>> explicitly declared branches, perhaps the same resistor and capacitor >>>>>> examples reformulated with explicit branches. >>>>>> >>>>>> 4. In the switch example on page 114 it is said that the value >>>>>> retention >>>>>> rules somehow apply in the switch example, but this is incorrect as >>>>>> the >>>>>> example never assigns to both branch voltage and current at the same >>>>>> point in time. This example seems to suggest that the value is >>>>>> retained >>>>>> by the branch over time, which is incorrect. >>>>>> >>>>>> 5. At the bottom of page 114 the indirect branch assignment >>>>>> statement is >>>>>> described with no introduction. Another paragraph is needed that >>>>>> describes why the fixed-point form described in the first paragraph is >>>>>> insufficient, which necessitates the indirect assignment statement. >>>>>> >>>>>> 6. Later in that same section it is said that using a normal >>>>>> contribution statement results in the wrong tolerances, but no >>>>>> description of how the indirect branch assignment handles >>>>>> tolerances is >>>>>> given. >>>>>> >>>>>> 7. At the bottom of page 115 is the constant expression / genvar >>>>>> expression thing. Also the restriction about not changing during a >>>>>> single analysis is weird (seems arbitrary and unnecessary). >>>>>> >>>>>> 8. On page 116, the comment "Analog filter functions cannot be used as >>>>>> part of the analog_expression syntax if the statement is dynamically >>>>>> executed during simulation." seem ambiguious. What does "dynamically >>>>>> executed" mean? Perhaps if we define a "genvar" conditional? >>>>>> >>>>>> 9. On page 124 in the "event_expression" syntax definition, can >>>>>> "expression" be an expression that returns a real number? I hope >>>>>> so, but >>>>>> if so, it does not seem like it should be allowed to derive from the >>>>>> analog context where it could be continually varying. Also, what would >>>>>> posedge or negedge real_expression mean? >>>>>> >>>>>> 10. In synatax 6-11 the following syntax is allowed for an >>>>>> event_expression: event_expression, event_expression. But it is never >>>>>> defined what that means. Nor is @* or @(*) described. >>>>>> >>>>>> 11. On page 127 in the section on the cross function, it says that the >>>>>> direction argument can only evaluate to +1, -1, or 0. That was not my >>>>>> understanding. I thought it could evaluate to other values, and if it >>>>>> did it would act to disable the cross function. This is necessary so >>>>>> that you can turn the damn thing off. >>>>>> >>>>>> 12. In general, the words "can not" should be replaced with "cannot" >>>>>> everywhere, and in most cases the word "which" should be replaced with >>>>>> "that (unless the which follows a comma). >>>>>> >>>>>> 13. I think much of the ambiguity concerning "constant expressions" >>>>>> would go away if we defined "genvar expressions" and then defined >>>>>> genvar >>>>>> conditionals as we did with the for loop. That way we could easily say >>>>>> things like analog operators are allowed in genvar conditionals and >>>>>> genvar loops, but not conventional conditionals and loops. >>>>>> >>>>>> Some of these comments represent a fair amount of work, let me know >>>>>> if I >>>>>> can help out. >>>>>> >>>>>> -Ken >>>>>> >>>>>> >>>>>> Geoffrey.Coram wrote: >>>>>> >>>>>> >>>>>>> The file was saved to the public-docs area as >>>>>>> > http://www.verilog.org/verilog-ams/htmlpages/public-docs/merged_beh.pdf >>>>>>> >>>>>>> >>>>>>> (Sri - I removed the "2.3" to conform with the naming convention, >>>>>>> as per my action item from last week.) >>>>>>> >>>>>>> -Geoffrey >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sri Chandra wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please find merged version of chapter 6 which we can discuss in >>>>>>>> tomorrow's call. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Sri >>>>>>>> >>>>>>>> -- >>>>>>>> Srikanth Chandrasekaran >>>>>>>> DTO, Tools Group >>>>>>>> Freescale Semiconductors Inc. >>>>>>>> Ph: +61-(0)8-8168 3592 Fax: x3201 >>>>>>>> >>>>>>>> >>>>>> >>> >>> >> > [attachment "ken.vcf" deleted by Marq Kole/EHV/RESEARCH/PHILIPS] [attachment "ken.vcf" deleted by Marq Kole/EHV/RESEARCH/PHILIPS]Received on Thu Jun 8 02:07:31 2006
This archive was generated by hypermail 2.1.8 : Thu Jun 08 2006 - 02:07:36 PDT