Graham, 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. 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. -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 >>>>>> >>>>>> >>>> > >
This archive was generated by hypermail 2.1.8 : Tue Jun 06 2006 - 20:03:45 PDT