Sri, You are correct. Neither choice is ideal. I wonder if it would be possible to check some of the current implementations to see what is available today. -Ken Sri Chandra wrote: > Ken, > >> Does the timer function trigger an event at >> Tevent = Tstart + N*Tperiod >> or at >> Tevent = Tstart + Tperiod1 + Tperiod2 + Tperiod3 + ... >> Is that your question? > > Yes. > > I agree with the benefits you have stated with version 1, however there > is an issue with it (well, probably issue is a strong word for it, but > possibly some confusion may arise for people writing the models). > When the period changes from Tperiod1 to Tperiod2 at some time during > the simulation, then there is one time interval in between where the > period of the clock may not represent either Tperiod1 or Tperiod2 since > we calculate N*Tperiod2 from the start_time. Say you have a period1 = > 3ns and then after a time it changes to 4ns, there will be one period in > between (based on the start_time value) that will not correspond to > either of these two period events. This problem does not occur in the > second formulation of the next event (Tevent), where the period of the > signal automatically follows Tperiodx, since we base the new period from > the last event. > > cheers, > Sri > > > Ken Kundert wrote: >> 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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> >> >
This archive was generated by hypermail 2.1.8 : Thu Jun 08 2006 - 13:11:51 PDT