=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 4 Topic Addressed: Analog solver Related CRs: 34, 39, 42 (Ernst Christen, Analogy, negative changed to affirmative) 181, 182, 184, 185 (Stephen A. Bailey, Veribest, negative changed to affirmative) 229 (Hisashi Sasaki, Toshiba Corp., affirmative) 231, 232, 233, 234, 235, 236 (Prasad Subramaniam, Lucent Technologies, negative) 237 (Lun Ye, Lucent Technologies, negative) Relevant LRM Sections: 12, 15 Resolution Status: Partly in review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR034 The simple simultaneous statement implied by the definition of a simultaneous procedural statement is missing from the list of things to be elaborated at line 1940. Proposed Resolution ~~~~~~~~~~~~~~~~~~~~ Modify text accordingly. ---------------------------------------------------------------------- CR039 The last sentence in the paragraph starting at line 2084 says: "A model is erroneous if, at any time T, there is not exactly one analog solution point." This appears to rule out discontinuities, where different solutions exist at t- and t+. Proposed Resolution ~~~~~~~~~~~~~~~~~~~~ Reword this sentence such that discontinuities are allowed. ---------------------------------------------------------------------- CR042 Discontinuities during initialization are not handled correctly in the paragraph starting at line 2259 and the following numbered list. The discontinuity augmentation set must be determined only if DOMAIN is TIME_DOMAIN. Therefore, the break set is applied either to the set of equations saved in step 1 (INITIALIZATION_DOMAIN), or to the set of equations produced by step 2 (TIME_DOMAIN). Proposed Resolution ~~~~~~~~~~~~~~~~~~~~ Replace this paragraph and the first three items of the numbered list by the following: When the analog solver resumes at time Tc, if the driver of the implicit break signal is active the following steps occur: 1. The present set of equations is saved. 2. If the value of the predefined DOMAIN signal is TIME_DOMAIN, the discontinuity augmentation set is determined and applied to the basic set. 3. The break set is applied to the now present set of equations. ---------------------------------------------------------------------- CR181 It is impossible to tell if a vendor has a 1076.1 compliant simulator. There is no semantic specification of the analog solver. The semantics of the interaction between the analog solver and the digital simulator are not sufficiently specified (how is the next time determined exactly?, how are thresholds reached resulting in event propagation to the digital simulator, etc.). In short, I don't know how to build a 1076.1 compliant simulator. ---------------------------------------------------------------------- CR182 I understand that there is no desire to specify the analog solver's algorithm. However, mathematics is universal and it is not a computer algorithm. I expect to see mathematical specifications for the analog solver and its interaction with the digital simulator in a standard for an analog description language intended for use in analog and mixed analog/digital simulators. ---------------------------------------------------------------------- CR184 Tolerances are treated as unstructured string values with no meaningful semantic interpretation. Thereby compromising the portability of designs. ---------------------------------------------------------------------- CR185 The term sufficiency is used in the context of the analog solver, but it is not defined. Even if the definition were to be implementation- dependent, then that must be stated. ---------------------------------------------------------------------- CR229 "a) The analog solver is executed. b) The current time, Tc is set equal to Tn. Simulation is complete when Tn = TIME'HIGH and there are no active drivers or process resumptions at Tn. c) Each active explicit signal in the model is updated. (Events may occur on signals as a result.) d) Each implicit signal in the model is updated. (Events may occur on signals as a result.) e) If the value returned by the function DOMAIN'EVENT is False, the remainder of this step is skipped. Otherwise, ***the time domain augmentation set is determined*** for Tc and applied to the basic set; this set of equations becomes that used by the analog solver." Simulation cycle only refers the determination of time domain augmentation set for Tc. The analog solver must mention also about the determination for each Ti. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ [12.6.5, AV] "Otherwise, when the analog solver resumes at time Tc it simultaneously resets Tn to a new value Tn' and determines a sequence of analog solution points for times Ti in the interval [Tc, Tn']. *** If, during the evaluation of any characteristic expression at a given time Ti in that interval, the analog solver executes the procedure LIMIT_NEXT_STEP, the first Tj in the interval [Ti, Tn'] must be less than or equal to all values given as the single parameter of LIMIT_NEXT_STEP for all executions of that procedure in all characteristic expressions during the determination of the solution point at Ti. An implicit signal Q'Above(E) is said to be contradictory when Q-E is sufficiently greater than 0.0 and Q'Above(E)=FALSE, or when Q-E is sufficiently less than 0.0 and Q'Above(E)=TRUE. Tn' is the lesser of Tn and the least value in the interval [Tc, Tn] at which any signal Q'Above(E) becomes contradictory. The times Ti must include Tn'." Insert at ***: "The time domain augmentation set is determined for each Ti, and applied to the set of characteristic expressions (set of equations) to be solved by the analog solver." ---------------------------------------------------------------------- CR231 The analog solver should not be restricted to be solved for time Tn' less than Tn. It should be allowed to go beyond time Tn. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ The analog solver should not be restricted to be solved for time Tn' less than Tn. It should be allowed to go beyond time Tn. ---------------------------------------------------------------------- CR232 In the simulation cycle the analog solver need not to be called before processes are executed. The order calling analog solver should not be determined by the language. This is simulator specific details. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Clearly mention that the given order "a" through "f" is not necessary to follow, and it can be in any order. ---------------------------------------------------------------------- CR233 The step "6" need not to come before step "8" in the intialization phase. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Correct the above problem. ---------------------------------------------------------------------- CR234 Why is it necessary to go through step "1" and then go through step "5" in case of discontinuity augmentation? Proposed Resolution ~~~~~~~~~~~~~~~~~~~ It should not be necessary to do steps 1 and 5. ---------------------------------------------------------------------- CR235 The analog solver need not to be called every time in the simulation cycle. The solver should be called if needed. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Please change step "a" to following: a) The analog solver is executed, if needed. ---------------------------------------------------------------------- CR236 The simulation cycle and the analog solver description will result in inconsistencies once there are more than one analog block. Seems like the language is suggesting solution for a description where all the analog blocks are solved together for. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Please clarify with an example proving otherwise. Other comments made with this feedback will avoid this problem. Clarification ~~~~~~~~~~~~~ I believe it is the intent of the language to provide implementers the freedom of selecting simulation algorithms. It is not clear to me if the language limits the presence of more than one analog block in the circuit , i.e., forces all analog blocks to be combined and solved simultaneously. This is not always necessary as the example below will indicate. Secondly, the language should not preclude the use of multiple algorithms for analyzing different analog blocks in the circuit. In the simple circuit below, analog block A and analog block B should not be forced by the language to be solved simultaneously, or to use the same analog solver. |--------| |----------| |---------| | | | | | | | A | | Digital | | B | -------| |-----------| |----------| |--------- | | | | | | ---------- ------------ ----------- I hope this clarifies my concern. ---------------------------------------------------------------------- CR237 The LRM defined a simulation paradigm by saying: "Tn' is the lesser ... contradictory." The LRM should not dictate any particular simulation paradigm, just as it does not dictate any numerical methods for solving the DAE set. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Re-word the paragraph between lines 905 and 915 (2267-2275, AV) such that the definition of any particular simulation paradigm is not present. ---------------------------------------------------------------------- =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR034 Section 12.4.5 has been rewritten following the resolution proposed in CR034. ---------------------------------------------------------------------- CR039, CR042 CR039 and CR042 deal with the determination of analog solution points (ASPs) at discontinuities. The definition of the analog solver in 12.6 has been reworked to allow several ASPs at the same time. The test for an erroneous model has been moved to 12.6.6. ---------------------------------------------------------------------- CR181, CR182 Rather than providing a closed form mathematical specification for the analog solver, we have chosen to define its behavior through a combination of specifications. The most important are: - a specification of what equations are to be used by the solver when and how (through the definition of characteristic expressions) - a specification of the qualities of the results the solver must produce: the value of each characteristic expression must be close to zero, and the set of characteristic expressions must be stable (this second part was not in the ballot version of the LRM and has now been added) - a specification of its behavior in the case of discontinuities We have used this approach because we have not found any mathematical specification of a solver that would have allowed us to describe the impact of simultaneous conditional statements on the solution. Such statements may cause the set of characteristic expressions to change from one iteration to the next while finding an analog solution point. Nevertheless, we believe that the definitions jointly provide an unambiguous specification of an analog solver as a black box. The determination of whether a simulator is compliant is indeed tricky. The underlying principle of the specification has been to define a solver that in the limit (i.e. given enough time and unlimited precision) produces a unique solution. An implementation will not in general yield such idealized results, because in practice an implementation is bound by a finite precision arithmetic, and a user is willing to compromise accuracy for speed. Our approach makes a simulator compliant if in the limit it would produce the idealized results. We are aware that this approach will put a burden on validation suites. CR181 also asks specific questions about how the next time is determined by the analog solver, and how thresholds reached result in event propagation to the digital solver. In response to the first question we have included a note saying that the times Ti are implementation- dependent. In practice, analog simulation algorithms select these times based on the tolerances specified by a user. Since quantities are analytical functions of time the exact times when this function is sampled are usually of no interest; what matters is that the quantity value at a sample point is accurate. The same can be said about the time of a discontinuity: it must be determined as accurately as possible. By construction discontinuities can only happen at the universal times where processes resume. Such times are either exactly representable in physical type TIME, or they are offset times that are a consequence of threshold events. The time of threshold events is again subject to tolerances, while the propagation of threshold events is described by the simulation cycle and the definition of the analog solver: The analog solver determines the time of the earliest threshold event between Tc and Tn, resets Tn to this time, Tn', and suspends. Then, the simulation cycle proceeds to first update the corresponding signals Q'Above(E) and then resume the processes that are sensitive to these signals. A more detailed explanation of this interaction can be found in the white paper on Mixed-Mode Simulation. ---------------------------------------------------------------------- CR184 To allow an user to make his compromise we have defined the concept of tolerances. This concept allows a model writer to group quantities whose values are to be determined with the same accuracy. The tolerance definition is intentionally vague because different solver algorithms use tolerances in quite different ways: although many algorithms use the concepts of an absolute ans a relative tolerance, the details how these concepts are used in an algorithm vary widely. The suggestion was in fact made to define the concepts of absolute and relative tolerance in the language, but it was rejected because the close interdependency of these concepts and a particular simulation algorithm would either have required to define an algorithm in the language, or the presence of the concepts would have suggested a false assurance of portability. For these reasons we chose to leave the mapping of the string expression in a tolerance aspect to numerical values suitable for the specific algorithms to the implementation. ---------------------------------------------------------------------- CR185 To address the issue raised in CR185 we have included a note describing that sufficiency is implementation-dependent. The revised definitions are included below. It has to be noted here that the purpose of tolerances is to allow a user to control how close to zero the values of the characteristic expressions at an analog solution point must be. To address the issue raised in CR229, we have reworked the handling of characteristic expressions. There are now three sets: - a structural set, as a consequence of quantity and terminal associations and branch quantity declarations - an explicit set, as a consequence of simultaneous statements - five augmentation sets, as before. The definition of an analog solution point has been reworked to take the issue raised in the comment report into consideration. ---------------------------------------------------------------------- CR231, CR232, CR233, CR234, CR235 The comment reports, CR231, CR232, CR233, CR234 and CR235, appear to take objection to the precise language definition as it relates to an analog solution point or the initialization phase. We believe that all these part of the language definition are fundamental to one of the design objectives, the definition of a language that is easy to use and a simulation environment that yields portable results. More specifically, the precise definition of Tn' (CR231) guarantees that time during a simulation always advances, i.e. that Ti+1 >= Ti under all circumstances. This principle simplifies model writing considerable, because a model writer doesn't have to worry about backtracking and similar issues. The order of execution in the simulation cycle (CR232) has the same purpose, giving a model writer a foundation for writing portable models. Portability is also the reason for the precise definition of the handling of discontinuities (CR234). CR235 asks for an unspecified optimization in the language definition (how should "if needed" be defined?). Finally, CR233 suggests that step 6 of the initialization does not have to precede step 8. The proposed formulation of the definition in these areas is of central importance for providing results that are portable between simulators _in the limit_, i.e. given enough time and precision to determine a solution. However, an implementor is free to use any optimization imaginable in his implementation, provided that a model cannot detect that the optimization has been made. This principle also applies to the initialization phase: an implementation can reorder the different steps or interleave them provided the modification has no effect on the model. In other words, there is a clear distinction between the _definition_ of the language and an _implementation_. For these reasons we are not planning to change the precise definition of the interaction between the analog solver and the digital kernel, although some adjustments have been made to the language in response to comments by other balloters. ---------------------------------------------------------------------- CR236 With respect to CR236, we have analyzed the language definition in the light of the concern raised. We have concluded that the only pieces that could be construed to preclude different time steps in different parts of the design is the definition of the time step limiting. We have reformulated this limiting as a specification on a quantity with the syntax *limit* quantity_list: type_mark *with* real_expression ; where words between *s are reserved words. The expression is evaluated at the end of the determination of an analog solution point, and the semantics require that the quantities named in the quantity list be updated at the latest at T + expression. In other words, time step limiting now has a local meaning where before its impact was global. We believe that there is no need to change the definition of an ASP because the language definition is vague about how the values of the quantities are determined. For example, an implementation can solve a system of equations simultaneously or in portions, or it can even guess the quantity values. In other words, the determination of an ASP does not mandate a solver to find a simultaneous solution of a system of equations. ---------------------------------------------------------------------- Email discussion on CR231-236 (balloter's text is prefixed by a '>') >We have carefully studied the comments made by the VHDL 1076.1 BRC. > Thank you very much for your quick response. We have analyzed your refined comments and have come up with the following response. >We disagree with the comments and still request that change >be made in accordance with the suggestions made by us under CR231, >CR232, CR233, CR234, and CR235. > We believe that the differences between the perspectives of the balloter and the BRC are due to the precise language used in the LRM. The language designers have made a clear distinction between the _definition_ of the language (which includes its execution semantics) and an _implementation_. This distinction is fundamental to an understanding of the Language Reference Manual. We must first state explicitly what it means for an implementation to "conform" to the definition provided by the Language Reference Manual. The LRM describes a "canonical engine" that, if implemented literally, will yield a conforming implementation. But any other engine that yields the "same" result for a given model is equally a conforming implementation. For example, an optimized implementation will eliminate dead code and unused variables within processes. We claim that the results are the "same" if it not possible to devise any model that will yield a result detectably different from that predicted by the canonical engine. The idea of "sameness" is only applicable in the limit, i.e., as numerical precision grows and the time steps taken decrease. The idea of "detectability" does not extend to the internal state of the algorithm, but only to the visible results on the time history of the values of signals, quantities and variables. An implementation need not create and maintain a complete time history of these values; it only needs to create and maintain those portions that matter to the particular model at hand. It is possible to overconstrain the problem using this definitional approach; that is, it is possible that the canonical engine has detectable side effects that are irrelevant to the task at hand, but none the less must be slavishly imitated by an implementor. It has been argued that the base VHDL 1076-1987 simulation engine is overconstrained in this sense. The designers of 1076.1 are acutely aware of this problem and have taken great pains to avoid it. >We agree that model need not have to worry about keeping track of time. >It should be the simulator's job to restore the states of the model and >inputs to reflect time as seen by model. We however object to the >condition put by the language that requires monotonic increase of >time. Your comments imply that the language forces the simulator to use a >lockstep algorithm. > It seems we all agree that a model shouldn't have to worry about keeping track of time. This is the reason why the language _definition_ specifies a monotonic increase of time: the model writer must be able to rely on this fundamental principle. However, as we pointed out previously, an _implementation_ is free to use any optimization the implementor can imagine, including what you are suggesting, i.e. running ahead and restoring the states of the model should it become necessary. The definition simply states that such implementation choices must be transparent to a model. From this perspective we do not agree that a simulator (i.e. an _implementation_) must use a lockstep algorithm to implement the 1076.1 execution semantics, although the _definition_ may specify one. >As long as the behavior in the model produces outputs >dependent on current states (which are correctly restored by the >simulator if time was backtracked) and inputs at the current time >there should be no problem writing simple portable models. > We are in agreement about this point, but again we must make a distinction between the _definition_ and an _implementation_. The _definition_ does allow backtracking of the sort you describe, but doesn't mandate it. >This is also essential to prevent the analog solver from taking >the smallest timestep based on events anywhere in the circuit. >The present definition of the language prevents the simulator from making use >of latency in one part of the circuit when another non related >part is very active. > We agree entirely that avoiding overspecification in this respect is essential. Besides the truncation error control, which is completely outside the language, there are two factors that may influence the time steps taken by a simulator. The first is the new limit specification limit quantity_list: type_mark with real_expression; which mandates that the quantities listed in the quantity list must be updated at the latest at T + expression_value. The _definition_ doesn't say how this happens. In particular, it does not prescribe whether at an analog solution point a simulator guesses the values of the quantities, computes them by extrapolation, interpolation, or by solving a system of equations, and it doesn't say that all quantities must be updated using the same method. For these reasons we disagree with the assertion that the _definition_ prevents a simulator from exploiting latency in a circuit. The change in the definition of the limiting mechanism was made precisely to allow an implementation to exploit latency or decoupling between portions of a model. The second factor influencing the time steps is the time of the events. If a process resuming at time T evaluates an expression in which the name of a quantity appears, then this quantity must have a value at time T. From the definitional perspective the only way this can happen is by means of an analog solution point. However, as before the _definition_ does not specify how such quantity values should be determined; this is left to the _implementation_. In particular, an _implementation_ can provide only the values of those quantities that are needed by the resuming processes: a model has no other way to find out whether a quantity value is available. Therefore, we disagree that the time steps to be taken by the solver in an _implementation_ are necessarily dependent on the time of the events of the event-driven part of the model. >We once again request the committee to review this matter and >accept the suggestions made by us earlier. In the light of this analysis we do not see the need for any further action by the BRC. ---------------------------------------------------------------------- CR237 CR237 suggests a modification of the definition of an analog solution point, specifically the definition of Tn', the time at which the analog solver suspends. We believe that this part of the language definition is fundamental to one of the design objectives, the definition of a language that is easy to use and a simulation environment that yields portable results. The precise definition of Tn' guarantees that time during a simulation always advances, i.e. that Ti+1 >= Ti under all circumstances. This principle simplifies model writing considerable, because a model writer doesn't have to worry about backtracking and similar issues. It is also of central importance for providing results that are portable between simulators _in the limit_, i.e. given enough time and precision to determine a solution. However, an implementor is free to use any optimization imaginable in his implementation, provided that a model cannot detect that the optimization has been made. In other words, there is a clear distinction between the _definition_ and an _implementation_. For these reasons we will not remove the precise definition of the interaction between the analog solver and the digital kernel, although some adjustments have been made to the language in response to comments by other balloters. ---------------------------------------------------------------------- Email discussion on CR237 (balloter's text is prefixed by a '>') >I studied the resolution by BRC for CR237, and I disagree with the BRC about >the comments made by BRC. We believe that the differences between the perspectives of the balloter and the BRC is due to the precise language used in the LRM. The language designers have made a clear distinction between the _definition_ of the language (which includes its execution semantics) and an _implementation_. This distinction is fundamental to an understanding of the Language Reference Manual. In our original response to the balloter we have given detailed reasons why the precise language describing the 1076.1 simulation cycle is essential for guaranteeing the portability of models, which is one of the 1076.1 design objectives. We have also pointed out that the language _definition_ does not preclude an _implementation_ from making any optimizations along the lines suggested by the balloter. >In CR237, I pointed out that the language should not define a simulation >paradigm by the current definition of ASP at Tn'. i. e, in the current language >definition, in the description of the definition of Tn' ASP, it also defines a >simulation paradigm, forcing the suspension of the analog solver at time Tn'. >In fact, what the analog solver (or any other entity) needs to do is to update >the driver of each contradictory signal, and simulation continues, without >explicitly forcing the analog solver to suspend. This way, Tn' is a time for an >ASP, and time for update signal drivers, but not for suspending the analog >solver. When the analog solver suspends should be beyond language definition. > We believe that this paragraph suggests that the balloter may have a misunderstanding about the details of the interaction between the analog solver and the event-driven engine. The balloter is correct in stating that the analog solver must update the driver of each contradictory signal Q'Above(E). However, the VHDL LRM makes a clear distinction between updating a _driver_ (during the execution of a process) and updating a _signal_ (in steps b and c of the VHDL 1076 simulation cycle, or steps c and d of the VHDL 1076.1 simulation cycle). Therefore, the analog solver must suspend at Tn', the earliest time at which a signal becomes contradictory, in order for the _signal_ to be updated. This in turn may cause events on other signals. If the analog solver did not suspend at Tn', the model would be out-of-date after Tn' if the name of any of these signals appears in a simultaneous statement. >The language definition gives precise definition of Tn' for generating a >sequence of ASP and for updating contradictory signal drivers. I suggest BRC >consider modifying the language definition such that it definies no simulation >paradigm. > In the light of this analysis we do not see the need for any further action by the BRC. =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ In the following, the unparenthesized line number refers to the stand-alone LRM, the number in parentheses to the integrated LRM. Italicized text is enclosed in exclamation marks, and bold text is enclosed in asterisks. new section 5.4 at line 1346 (1394) 5.4 Step limit specification A step limit specification specifies a maximum amount of time that is permitted to elapse between the determination of the values of a quantity and the next determination of the value of that quantity. step_limit_specification ::= *limit* quantity_specification *with* !real!_expression ; quantity_specification ::= quantity_list : type_mark quantity_list ::= !quantity!_name { , !quantity!_name } | *others* | *all* Each quantity name in a quantity list in a step limit specification must be a locally static name that denotes a quantity. Each quantity must be an explicitly declared quantity or a member of such a quantity. If the quantity is a declared quantity or a slice thereof, the type mark must be the same as the type mark indicated in the quantity declaration for that quantity. If the quantity is an array element of an explicitly declared quantity, the type mark must be the same as the element subtype indication in the (explicit or implicit) array type declaration that declares the base type of the explicitly declared quantity. If the quantity is a record element of an explicitly declared quantity, then the type mark must be the same as the type mark in the element subtype definition of the record type declaration that declares the type of the explicitly declared quantity. Each quantity must be declared in the declarative part enclosing the step limit specification. Subject to the aforementioned rules, a step limit specification applies to a quantity Q whose type mark denotes the type T under the following circumstances: ‹ For a scalar quantity Q, if an explicit or implicit step limit specification of the form *limit* Q: T *with* !real!_expression; exists, then this step limit specification applies to Q. ‹ For a composite quantity Q, an explicit or implicit step limit specification of the form *limit* Q: T *with* !real!_expression; is equivalent to a series of implicit step limit specifications, one for each scalar subelement of the quantity Q. Each step limit specification in the series is created as follows: it has, as its single quantity name in its quantity list, a unique scalar subelement of Q. Its type mark is the same as the type of the same scalar subelement of Q. Its time expression is the same as that of the original step limit specification. The characteristics of the step limit specification must be such that each implicit step limit specification in the series is a legal step limit specification. ‹ If the quantity list in an explicit or implicit step limit specification contains more than one quantity name, the step limit specification is equivalent to a series of step limit specifications, one for each quantity name in the quantity list. Each step limit specification in the series is created as follows: It has, as its single quantity name in its quantity list, a unique member of the quantity list from the original step limit specification. Its type mark and time expression are the same as those in the original step limit specification. The characteristics of the step limit specification must be such that each implicit step limit specification in the series is a legal step limit specification. ‹ An explicit step limit specification of the form *limit* *others*: T *with* !real!_expression; is equivalent to an implicit step limit specification where the reserved word others is replaced with a quantity list comprised of the simple names of those quantities that are declared quantities declared in the enclosing declarative part, whose type mark is the same as T, and that do not otherwise have an explicit step limit specification applicable to it; the remainder of the step limit specification is otherwise unchanged. If there are no quantities in the enclosing declarative part whose type mark is the same as T and that do not otherwise have an explicit step limit specification applicable to them, then the above step limit specification has no effect. The characteristics of the explicit step limit specification must be such that the implicit step limit specification, if any, is a legal step limit specification. ‹ An explicit step limit specification of the form *limit* *all*: T *with* !real!_expression; is equivalent to an implicit step limit specification where the reserved word all is replaced with a quantity list comprised of the simple names of those quantities that are declared quantities declared in the enclosing declarative part and whose type mark is the same as T; the remainder of the step limit specification is otherwise unchanged. If there are no quantities in the enclosing declarative part whose type mark is the same as T, then the above step limit specification has no effect. The characteristics of the explicit step limit specification must be such that the implicit step limit specification, if any, is a legal step limit specification. A step limit specification with the quantity list others or all for a given type that appears in a declarative part must be the last such specification for the given type in that declarative part. No quantity of the given type may be declared in a given declarative part following such a step limit specification. It is an error if more than one step limit specification applies to the same quantity. If, by the aforementioned rules, no step limit specification applies to a scalar quantity Q whose type mark is T (including a scalar subelement of a composite quantity), then the following default step limit specification is implicitly assumed: *limit* Q : T *with* X; where X is the universal time corresponding to REAL¹HIGH. Thus the step limit expression for any quantity is always defined, either by an explicit step limit specification or by an implicit one. If the value of a quantity is determined at time T, it is an error if the value of that quantity is next determined at a time greater than the value of T plus the value of the step limit expression evaluated at time T (see section 12.6.6 for the process by which the analog solver determines the values of quantities, and 12.6.4 for the role that the analog solver plays in the simulation cycle). NOTES 1‹-A step limit specification supplying either the reserved words others or all may apply to none of quantities in the current declarative part, in the event that none of the quantities in the current declarative part meet all of the requirements of the step limit specification. 2‹-Since step limit specifications are based on declarative parts, not on declarative regions, quantity ports declared in an entity interface cannot be referenced by a step limit specification in a corresponding architecture body. Cross-References: Quantity declarations, 4.3.1.6; The analog solver, 12.6.6. section 12.1 at line 1801 (16) The elaboration of a design hierarchy creates a collection of processes interconnected by nets and certain !characteristic expressions! that are an implicit consequence of the declaration and association of quantities and terminals; these characteristic expressions are said to be in the !structural set! of characteristic expressions. The behavior of the design can be simulated by executing the collection of processes and nets and determining the values of the quantities using the structural set of characteristic expressions, an explicit set of characteristic expressions (see 15) and an augmentation set (see 12.6.5). section 12.2.4 after line 1822 (125) If a given port is a quantity port or a terminal port, the association of the formal and the actual consists of the creation of characteristic expressions. If the port is a quantity port, the difference between each scalar subelement of the formal and the corresponding scalar subelement of the actual is a characteristic expression of the structural set. Its tolerance group is the tolerance group of the corresponding scalar subelement of the formal. Similarly, if the port is a terminal port, the difference between each scalar subelement of the reference quantity of the formal and the corresponding scalar subelement of the reference quantity of the actual is a characteristic expression of the structural set. Its tolerance group is the tolerance group of the corresponding scalar subelement of the reference quantity of the formal. Additionally, if the port is a terminal port, the contribution expression of each scalar subelement of the formal is symbolically added to the contribution expression of the corresponding scalar subelement of the actual. section 12.2.5 remove section [Editorial: The first two paragraphs of this section have been moved to section 12.6.6 (formerly 12.6.5), because they must be enforced for each analog solution point. The third section has been moved to section 1.1.1.2] section 12.3.1.4 at lines 1911 (243) and 1913 (245) remove "or subnature". This will make the step unchanged. after line (252) The elaboration of a terminal declaration also includes the creation of a !contribution expression! corresponding to each scalar subelement of the terminal. The contribution expression is initialized to the literal 0.0; it may be modified by other steps of the elaboration process. Similarly, the elaboration of an across quantity declaration includes the creation, for each scalar subelement q of the across quantity, of the expression (q minus the reference quantity of the plus terminal of q plus the reference quantity of the minus terminal of q). This expression is a characteristic expression of the structural set. Its tolerance group is the tolerance group of q. Finally, if the object is a through quantity, then for each scalar subelements q of the through quantity the string "+" and the name of q are appended to the contribution expression of the plus terminal of q, and the string "-" and the name of q are appended to the contribution expression of the minus terminal of q. section 12.4.1 at line (324) ...of the block statement part, followed by the creation of certain characteristic expressions of the structural set. after line (334) A scalar terminal is a !root terminal! if it is not a reference terminal or a connected terminal. The contribution expression of each scalar subelement of any root terminal of the block is a characteristic expression of the structural set. Its tolerance group is the tolerance group implied by the type of the contribution expression. In addition, the difference between each scalar subelement of each quantity T'Contribution and the contribution expression of the corresponding scalar subelement of terminal T is a characteristic expression of the structural set. Its tolerance group is the tolerance group of the scalar subelement of T'Contribution. section 12.4.5 at line 1938 (431) The elaboration of a simple simultaneous statement consists of the evaluation of the string expression that determines the tolerance group of its characteristic expressions. The elaboration of a simultaneous procedural statement consists of creating the type and subprogram declaration and the simple simultaneous statement implied by the simultaneous procedural statement, and elaborating each in turn. The elaboration of any other simultaneous statement has no effect. section 12.4.6 remove section. [Editorial: Its placement under section 12.4 was inappropriate because the actions are not related to the elaboration of a statement part. The corresponding information is now in sections 12.2.4, 12.3.1.4, and 12.4.1] section 12.6 at line 2085 (587) ... The analog solver is said to determine an !analog solution point! when it determines these values. [Editorial: the qualification "at time T" has been removed because there may be several ASPs at a particular time, for example at time 0.0 while finding the quiescent point, or at a discontinuity. Also the test for an erroneous model has been moved to to section 12.6.6 (formerly 12.6.5) where it seems to fit better after the modification.] section 12.6.4 at line (787) ... In each cycle, the values of all signals and quantities in the description are computed. ... at line 2185 (807) remove step 2 [Rationale: quantities get their default initial value as part of elaboration] at line 2200 (822) 8. The quiescent state augmentation set is determined. [Editorial: this will become step 7 after removing step 2] at line 2212 (852) e) If the value returned by the function DOMAIN'EVENT is false, the remainder of this step is skipped. Otherwise, the model is said to be at a !quiescent point!. If the value of the DOMAIN signal is TIME_DOMAIN, the time domain augmentation set is determined. after line 2246 (886) 5--There are two quiescent points that differ in the value of the DOMAIN signal. new section 12.6.5 12.6.5 Augmentation Sets An !augmentation set! is a set of characteristic expressions, each corresponding to the scalar subelement of a source quantity or the scalar subelement of an implicit quantity of the form Q'DOT, Q'INTEG, and Q'DELAYED(T). The corresponding scalar subelement is said to be the !tag! of the characteristic expression. The tolerance group of the characteristic expression is the tolerance group of the tag. There are five different augmentation sets. The !current augmentation set!, together with the structural set and an explicit set, is used by the analog solver to determine the values of the quantities. The determination of an augmentation set consists of the creation of the corresponding characteristic expressions and the determination of their tag and their tolerance group, and it makes the augmentation set the current augmentation set. new sections 12.6.5.1 through 12.6.5.5 these sections correspond to sections 12.4.6.1 through 12.6.4.5 in the current version of the LRM, updated according to another change request. current section 12.6.5 renumber to 12.6.6 at line 2249 (888) The analog solver is said to determine an !explicit set! of characteristic expressions when it evaluates the simultaneous statements appearing in the statement part of each block in the model. The !characteristic number! of an external block is the number of scalar free quantities, scalar through quantities, and scalar interface quantities of mode *out* declared in the block, its entity, or its internal blocks, minus the number of scalar quantities associated with formal quantities of mode *out* in the external block. It is an error if the number of characteristic expressions obtained by the evaluation of the simultaneous statements appearing in all statement parts of an external block and its internal blocks is not equal to the characteristic number of the external block. The analog solver has successfully determined an analog solution point when it has determined an explicit set of characteristic expressions and a value for each quantity such that another determination of an explicit set will yield the same explicit set and the evaluation of each characteristic expression of the model will yield a value sufficiently close to zero. A model is erroneous if, for any analog solution point, no such values for the quantities exist, or if the values are not unique. after line 2258 (897) An implicit signal Q'Above (E) is said to be !contradictory! when Q-E is sufficiently greater than 0.0 and Q'Above(E)= FALSE, or when Q-E is sufficiently less than 0.0 and Q'Above(E)=TRUE. at line 2261 (900) 1. The current augmentation set (which may have been modified by the application of a break set) is saved. 2. If the value of the predefined DOMAIN signal is TIME_DOMAIN, the discontinuity augmentation set is determined. 3. The break set is applied to the current augmentation set. 4. The analog solver determines an analog solution point. 5. The analog solver evaluates the expression in each *limit_step* specification in the model. 6. The augmentation set saved in step 1 is restored and becomes the current augmentation set. at line 2267 (906) Otherwise, when the analog solver resumes at time Tc it simultaneously resets Tn to a new value Tn' and determines a sequence of times Ti in the interval [Tc,Tn']. Tn' is the lesser of Tn and the least value in the interval [Tc, Tn] at which any signal Q'Above(E) becomes contradictory. The times Ti must include Tn'. At each time Ti the following steps occur: 1. If the value of the predefined DOMAIN signal is TIME_DOMAIN, the time domain augmentation set is determined. 2. The analog solver determines an analog solution point. 3. The analog solver evaluates the expression in each *limit_step* specification in the model. at line 2276 (915) Next, the analog solver assigns the waveform (*not* Q'Above(E) after 0 sec) to the driver of each contradictory signal Q'Above(E) and updates the variables corresponding to each quantity in the kernel process. Finally, the analog solver suspends. at line 2278 (917) delete paragraph as it contradicts 12.6-2074 (575) after line 2279 (918) NOTES 1--Each evaluation of the simultaneous statements appearing in all statement parts of a model may yield a different explicit set of characteristic expressions. 2--The times Ti are not specified by the language. They are determined by the analog solver, typically based on the solution accuracy requested by the user. However, *limit_step* specifications place an upper limit on the distance between two times Ti and Ti+1. 3--The criteria determining sufficiency (as used in the phrases "sufficiently close to", "sufficiently greater than" and so on) are intended to be implementation-dependent and may vary from time to time and quantity to quantity to effect tradeoffs between simulation time and accuracy of the result. section 15 at line 3316 (1308) Simultaneous statements express explicit differential and algebraic equations that together with implicit equations constrain the values of the quantities of a model. at line 3326 (1318) remove paragraph as it duplicates information. section 15.1 at line 3331 (1323) The evaluation of a simple simultaneous statement creates one or more characteristic expressions of an explicit set. section 15.5 at line 3474 (1466) The evaluation of a simultaneous null statement has no effect. ... ===============================================================================