Re: Merged version of chapter 6

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
>>>>>>>
>>>>>>>                   
>>>>>           
>>
>>   
>