Hello Ken, From the examples below, AMS/1364 has a different definition of "constant expression" compared to the 1364 definition. See below: - A digital "constant expression" /always returns the same value throughout a simulation/. (The 1364 never had any concept of multiple analyzes within a single simulation.) - An analog "constant expression" /always returns the same value throughout an analysis in a simulation, but may change between different analyzes within the same (multiple analysis) simulation./ (This change (wrt 1364) occurred when analysis() and analysis specific behavior was introduced into the LRM a long time ago but it appears it was never added to the LRM). // Does everyone agree with the definitions of analog and digital constant expressions? If yes, then this needs to be document in the LRM, because the 1364 definition of constant expression has been assumed to be the same in analog (even after analysis() function and analysis specific behavior was introduced into the language a long time ago). The question now is how to clearly differentiate digital and analog constant expressions in the syntax and body of the AMS LRM. Here is how I would approach this: 1) I would allow the use of analysis() function calls and analysis specific behavior in analog_block and analog_function_declaration syntax only. Module scope parameter, variable and net declarations cannot use analysis() calls in its expressions. Also the 1364 module scope generate statements(for, if, etc) will remain analysis independent even if the committee decides to allow the use of analysis dependent analog blocks and analog function declarations within the 1364 generate constructs. 2) I would define the new term "analog constant expression" to represent constant expressions within analog behavior of a module declaration and in order to differentiate it from 1364 version of "constant expression". This definition needs to be clearly in the LRM. All references to "constant expression" needs to be checked to make sure it is not actually meaning a "constant analog expression" (eg.. analog operator's usage restriction should be based on "constant analog expression" not "constant expression"). 3) The "constant analog expression" can be implemented in the syntax in one of 2 ways: 3.A) Keep the analysis_functional_call syntax item in the constant_expression syntax. But document in the body of the LRM that analysis() call are only allowed within analog_block and analog_function_declaration syntax. Two different types of constant expression is represent with one syntax. As a result minimal syntax changes are required. 3.B) Remove the analysis_functional_call syntax item in the constant_expression syntax and creating a constant_analog_expression syntax. The constant_analog_expression will use constant_expression and analysis_functional_call syntax items. Then this new syntax is replaces all occurrences of constant_expression within the analog_block and analog_function_declaration syntax. This will result in existing syntax (like variable_declaration and parameter_declaration, etc) to be duplicated in order to support constant_expression and constant_analog expression because the same syntax is used in module and analog scope declarations. There will be potentially other (yet unidentified) changes like this in the language. As a result more significant syntax changes are required. Regardless of which of the above ways is selected, the addition of the analysis_function_call into the analog_expression syntax will be required. (this fixed an either identified problem with the merged syntax). I prefer method A to be implemented. Would the above changes to the LRM resolved your concerns with constant expressions in analog behavior or am I missing something? Regards Graham Ken Kundert wrote: > Graham, > The issue is that dynamic operators such as ddt need access to past > values of their arguments. So the conditionals that contain dynamic > operators need to be constrained so that they are time invariant. They > do not have to be constant between analyses, just constant versus time. > Thus, both of your examples are acceptable and in fact are both > supported today. > > -Ken > > Graham Helwig wrote: > >> Hello Ken >> >>> The analysis function was made "constant" to allow it to control >>> conditionals that contained analog operators that needed to maintain >>> internal state (cross, transition, slew, laplace, z, etc.). However the >>> 2.2 LRM clearly states (pg. 64) that the only conditionals analog >>> operators can be contained within are conditionals controlled by genvar >>> expressions. Thus the only thing that we seem to need to do is to make >>> analysis() (and perhaps some others like simparam, temperature, vt, >>> etc.) genvar expressions. I think in doing so we would simply be >>> completing a job started some time ago. >>> >> In short genvar expression in 2.2 AMS LRM is the same as constant >> expression in 1364-2005. Both are constant_expression with genvar >> references. I would anticipate that this use of genvar expression be >> replaced with constant expression when this section is updated as part >> of the AMS merger with 1364-2005. >> >> In light of the analysis() usage problems discussed in this thread, it >> is unclear to me how "constant" a constant conditional statement should >> before analog operators can be used inside its conditional statements. >> It obvious analog operators are allowed in conditional statement that >> are constant for the entire simulation. For example: >> >> parameter param = 3; >> analog begin >> if (param>5) begin >> V(a) <+ ddt(V(b)); >> end >> else begin >> V(a) <+ 0.0; >> end >> end >> >> But are analog operators allowed in conditional statements which are >> constant for an analysis of a simulation but may change in a different >> analysis of the same simulation? For example: >> >> analog begin >> if (analysis("ic")) begin >> V(a) <+ 0.0; >> end >> else begin >> V(a) <+ ddt(V(b)); // or any other analog operator. >> end >> end >> >> Also there is an error in the merged_syntax.pdf w.r.t analysis() usage >> in the module. This problem was identifier in a earlier email thread >> titled "What to do with the analysis() function" (April 2006). There >> will have to be changes to the syntax fix the problem, but before this >> occurs I'm trying to nail down exactly where the analysis() function >> can and can not be used within a module declaration. So here is some >> questions: >> >> Do we want to be able to call the analysis() function outside of the >> analog blocks and analog function blocks? If yes, then where can it be >> used. >> Do we want to be able to call analysis function in any expression >> (constant or non-constant) within the analog blocks and analog function >> blocks? If no, then where is it disallowed >> >> Regards >> Graham >> >> >>> Graham Helwig wrote: >>> >>> >>>> Hello Ken, >>>> >>>> My mistake for not reading you're example correctly. >>>> >>>> What part of the syntax allows declaration of nets within the analog >>>> block? Both the 2.2 and merge syntax allows the type net declarations >>>> that you have described in the module scope but not within the analog >>>> block. Only real, integer and parameter declarations are supported with >>>> the analog block (see section A2.8 and A.6.3 of the merged syntax). >>>> >>>> Hmmm, I think I agree with you. 1364 defines an expression to be >>>> constant when its value is same throughout the life the simulation. AMS >>>> has pick up this definition and then added that a simulation may consist >>>> of a number of different analyzes. But the analysis() function is used >>>> in the constant expression even though it may return different values >>>> during a simulation. The analysis() function returns non-constant >>>> values. >>>> >>>> Instead of making another variant of constant_expression in the syntax, >>>> I would move the non-constant analysis() function out of >>>> constant_expression into the analog_expression with all of the other >>>> non-constant functions. This type of change is significant because a lot >>>> of developed models use analysis(), so careful checking to make sure >>>> that existing usage of analysis() will not break because of this change. >>>> >>>> Regards >>>> Graham >>>> >>>> >>>> >>>> >>>> Ken Kundert wrote: >>>> >>>> >>>>> Graham, >>>>> I was not trying to suggest that using the analysis function to >>>>> affect the dimension of a buss was desirable. Rather I was starting >>>>> with >>>>> the premise that it was undesirable and impractical, and pointing out >>>>> that the existing syntax allows it. Notice that in my example the >>>>> analysis function is contained within an analog block and used in a >>>>> setting that requires a constant expression, which analysis() is. Thus, >>>>> through this example I was suggesting that analysis should not return a >>>>> "constant" because its output is not constant enough to be used in all >>>>> settings that require constants. Rather that its output should be >>>>> denoted time invariant. And in my original post I was suggesting that >>>>> genvar be the mechanism for codifying time-invariance, but now I am not >>>>> so sure that it is the right mechanism. >>>>> >>>>> And I guess I did not believe that adding this new time-invarience >>>>> concept in the syntax would result in the syntax growing by an >>>>> appreciable amount. In fact I though it would make things simpler >>>>> overall and less ambiguous. >>>>> >>>>> -Ken >>>>> >>>>> Graham Helwig wrote: >>>>> >>>>> >>>>> >>>>>> Hello Ken, >>>>>> >>>>>> >>>>>>> Actually, I think the question of whether the transient analysis >>>>>>> has >>>>>>> one part or two is not a concern in regards to the question of >>>>>>> whether >>>>>>> the return value of analysis() is a constant or not. Consider the >>>>>>> following case: >>>>>>> >>>>>>> analog : name; >>>>>>> electrical [0:analysis("ac") ? 10 : 4] buss; >>>>>>> ... >>>>>>> >>>>>>> I know virtually all circuit simulators will not be happy if the >>>>>>> number >>>>>>> of nodes declared in the AC analysis is different from in the other >>>>>>> analyses. In this case the range of buss should be constant over all >>>>>>> analyses. >>>>>>> >>>>>>> >>>>>> I'm not sure the authors of the analysis() function intended to allow >>>>>> the function to be used to declare a net declaration's range. I >>>>>> certainly have not used in this way before. Is it usage of analysis() >>>>>> common with other vendors? >>>>>> >>>>>> Since 1364 generate constructs have been merged into the language, the >>>>>> same analysis() dependent net declaration can be achieved. For >>>>>> example: >>>>>> >>>>>> module example; >>>>>> generate >>>>>> if (analysis("ac")) begin >>>>>> electrical [0:10] buss; >>>>>> end >>>>>> else begin >>>>>> electrical [0:4] buss; >>>>>> end >>>>>> endgenerate >>>>>> ..... >>>>>> endmodule >>>>>> >>>>>> Would it make more sense to: >>>>>> 1) entirely disallow the use of analysis() outside of the analog >>>>>> block? >>>>>> 2) allow analysis() to be used in net declaration ranges? >>>>>> 3) allow analysis() outside of the analog block but only in selected >>>>>> place like generate construct's conditional statements, but not in any >>>>>> declaration range expressions? >>>>>> >>>>>> Personally I prefer option 3, but this will dependent on if analog >>>>>> subset of the language can be used with generate constructs or not. If >>>>>> analog is allowed within generate constructs, then further >>>>>> investigation is required to make sure that analysis dependent >>>>>> generate >>>>>> construct processing is not going to introduce any more problems. >>>>>> >>>>>> >>>>>>> So in my mind, there are two types of constants. Those that can never >>>>>>> change during the course of a simulation, and those that cannot >>>>>>> change >>>>>>> with time, but can change between analyses and perhaps even during dc >>>>>>> sweeps and the like (functions like cross, transition, laplace, etc. >>>>>>> would not care if they were in a conditional whose state changed >>>>>>> during >>>>>>> a DC analysis). Seems like we should have syntactical categories for >>>>>>> both. I believe that there are other functions whose return value >>>>>>> would >>>>>>> fit into the category of constant with time. simparam and vt come to >>>>>>> mind. >>>>>>> >>>>>>> >>>>>> Agreed there are 2 types of constants in the analog context (analysis >>>>>> dependent and analysis independent). But I'm reluctant to insert this >>>>>> analysis() usage restriction into syntax because the complexity and >>>>>> size >>>>>> of the syntax needed to completely define its usage would explode. In >>>>>> previous versions of the LRM syntax, a similar situation with analog >>>>>> operator usage was tried. The amount of syntax did not explode, it >>>>>> just >>>>>> was incomplete, messy and as a result confusing. The solution to that >>>>>> problem was to move the analog operator usage restrictions out of >>>>>> syntax >>>>>> into the body LRM as a semantic restriction. I would suggest the >>>>>> same be >>>>>> done for analysis dependent and independent constant expressions. >>>>>> >>>>>> Regards >>>>>> Graham >>>>>> >>>>>> >>>>>>> -Ken >>>>>>> >>>>>>> >>>>>>> Graham Helwig wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hello Ken and Sri, >>>>>>>> >>>>>>>> Yes analysis() function in a constant expression can be >>>>>>>> confusing. I' >>>>>>>> not sure if the LRM clearly defines constant expression with >>>>>>>> respect to >>>>>>>> multiple part simulations like transient. >>>>>>>> >>>>>>>> So a transient analysis is made up of a "ic" and "tran" parts. Does >>>>>>>> the >>>>>>>> LRM treat them as 2 separate simulations ("tran" is always run >>>>>>>> immediately after "ic" simulation). If yes then the use of >>>>>>>> analysis() in >>>>>>>> a constant expression syntax is truly constant. If not then >>>>>>>> analysis() >>>>>>>> function within a constant expression is not truly constant and this >>>>>>>> needs to be taken into account every time constant expressions are >>>>>>>> used >>>>>>>> in the analog behavior. In either the relationship between >>>>>>>> analysis(), >>>>>>>> constant expressions and multi-part simulations needs to be clearly >>>>>>>> documented in the LRM. >>>>>>>> >>>>>>>> Regards >>>>>>>> Graham >>>>>>>> >>>>>>>> Ken Kundert wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Sri and Graham, >>>>>>>>> I guess I was suggesting that there is a difference between >>>>>>>>> constant >>>>>>>>> expression and what we need for conditionals & dynamic >>>>>>>>> operators. You >>>>>>>>> can't really say that the conditionals that contain dynamic >>>>>>>>> operators >>>>>>>>> can only be controlled by a constant expression because we need >>>>>>>>> to be >>>>>>>>> able to use the analysis function to control the conditional. I >>>>>>>>> know we >>>>>>>>> now say that the output of the analysis function is a constant, but >>>>>>>>> that >>>>>>>>> is kind of weird because it can change during the simulation. And >>>>>>>>> because it can change, you might not want to use it where constant >>>>>>>>> expressions are allowed, such as when defining bus widths. So it >>>>>>>>> seems >>>>>>>>> like we need an object that is constant versus time, but can change >>>>>>>>> during the course of a simulation. I was thinking that genvar >>>>>>>>> could be >>>>>>>>> that object. It always struck me as odd that genvars were >>>>>>>>> constrained to >>>>>>>>> for loops when we have the same, or at least a very similar issue, >>>>>>>>> with >>>>>>>>> conditionals. >>>>>>>>> >>>>>>>>> -Ken >>>>>>>>> >>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> -- ========================================================== Graham Helwig AMS Verification Australian Semiconductor Technology Company (ASTC) Pty Ltd Location: 76 Waymouth St, Adelaide, SA, 5000, Australia Phone +61-8-82312782 Moblie: +61-4-03395909 Email: graham.helwig@astc-design.com Web: www.astc-design.com ==========================================================Received on Thu Jun 8 22:10:29 2006
This archive was generated by hypermail 2.1.8 : Thu Jun 08 2006 - 22:10:34 PDT