While we are on the subject of constant expressions ... it may be time to go back to a neglected request which allows one to solve differential equations, namely initial conditions. The 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 will initialize the output V(a) but in reality one wants: analog begin if (analysis("ic")) begin V(a) <+ 0.0; end I(a) <+ ddt(V(a)); which is not a switch branch. A better method is to give ddt a third argument which is the initial condition of the expr: I(out) <+ ddt(expr,abstol,ic_expr); Graham Helwig wrote: > 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > >Received on Fri Jun 9 08:05:28 2006
This archive was generated by hypermail 2.1.8 : Fri Jun 09 2006 - 08:05:40 PDT