VHDL Issue Number: IR1.99.06 Classification: Request for Clarification Language Version: VHDL-1076.1'99 Summary: What is the value of S'Event and S'Active in an ASP Related Issues: Relevant LRM Sections: 14.1, 12.6 Key Words and Phrases: simulation cycle, S'Event, S'Active Current Status: Analyzed 1076.1-99 Disposition: Unknown Closed (All Issues Completely Addressed) Bugs Fixed, Enhancements Outstanding (No ISAC Issues) Superseded (ISAC Issues Outstanding) Disposition Rationale: Superseded By: N/A ----------------------- Date Submitted: March 13, 2002 Author of Submission: Craig Winters Author's Affiliation: Cadence Design Systems Author's Post Address: Author's Phone Number: Author's Fax Number: Author's Net Address: cwinters@cadence.com ----------------------- Date Analyzed: 02 May 2002 Author of Analysis: Ernst Christen Revision Number: 3 Date Last Revised: 02 May 2002 EC: initial analysis 06 Jul 2005 EC: new numbering 10 Jul 2005 EC: added recommendation, changed status Description of Problem ---------------------- My question concerns the predefined attributes S'EVENT and S'ACTIVE described in LRM 14.1, page 200. The definition of 'EVENT is S'EVENT returns the value TRUE if an event has occurred on S during the current simulation cycle; and a similar definition exists for 'ACTIVE. My question involves how this definition applies when the function is accessed from an expression in the analog solver, such as a simple simultaneous expression or the conditional part of a simultaneous if or case. First the definition seems to imply that the attribute would have the same value for an entire cycle and would change value on a cycle basis. In the cycle described in 12.6.4 the entire execution of the analog solver is one step of a cycle so it would appear that the value of this function would be the same from Tc to Tn. This is counter to the intuitive notion that S'EVENT (or ACTIVE) would be true at exactly the time of the event (or activity). Can we clarify which is the case? Second question has to do with what is meant by "the current simulation cycle". Again, referring to LRM p 200, if each cycle is defined as steps a) through i), then the current simulation cycle in which S'EVENT is true would include the analog solver execution that preceded the event, rather than the one that followed the event. Wouldn't this require analog solver to look into the future? For the purposes of this definition it would seem reasonable to define the cycle as being from one signal update (steps c & d) to the next signal update, so that the analog solver execution included in the S'EVENT cycle would be the one following the signal update step that generated the event. Is that a correct interpretation? Proposed Resolution ------------------- None. 1076.1-ISAC Analysis & Rationale -------------------------------- The questions are about the values of S'Event and S'Active as seen by the analog solver and the meaning of the term "current simulation cycle". There is no salient ambiguity about what constitutes a simulation cycle: "A simulation cycle consists of the [ordered execution of the] following steps: a)...i)...". The parenthetical notation here and below clarifies the reading; no change in the wording is proposed. The "current" simulation cycle is the cycle under way at the time the truth value of a proposition is determined. We are depending on the common language meaning of "current" for this interpretation. The definitions for the two functions S'Event and S'Active given in section 14.1 of the LRM are: S'Event: For a scalar signal S, S'EVENT returns the value TRUE if an event has occurred on S during the current simulation cycle; otherwise, it returns the value FALSE. For a composite signal S, S'EVENT returns TRUE if an event has occurred on any scalar subelement of S during the current simulation cycle; otherwise, it returns FALSE. S'Active: For a scalar signal S, S'ACTIVE returns the value TRUE if signal S is active during the current simulation cycle; otherwise, it returns the value FALSE. For a composite signal S, S'ACTIVE returns TRUE if any scalar subelement of S is active during the current simulation cycle; otherwise, it returns FALSE. To understand the intended behavior of these functions we have to look for information in other places of the LRM. We do this separately for S'Event and S'Active. The LRM defines the occurrence of an event in section 12.6.2 (p171): If updating a signal causes the current value of that signal to change, then an event is said to have occurred on the signal. Further, the definition of the simulation cycle in section 12.6.4 says: 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.) This implies that the interpretation of S'event is based on the assumption that the proposition (in the definition of S'event) "...an event has occurred on S during the current simulation cycle..." should be read "...an event has occurred on S during [a step in] the current simulation cycle [prior to the evaluation of S'event]..." "has occurred" refers to a discrete action which either happened or did not happen in the past. Since nothing that can cause an event can happen before step "a)" of the current cycle, we can conclude that S'event is always false when evaluated by the analog solver. Similarly, the LRM defines an active signal in section 12.6.2 (p169): As simulation time advances, the transactions in the projected output waveform of a given driver (see 12.6.1) will each, in succession, become the value of the driver. When a driver acquires a new value in this way, regardless of whether the new value is different from the previous value, that driver is said to be active during that simulation cycle. For the purposes of defining driver activity, a driver acquiring a value from a null transaction is assumed to have acquired a new value. A signal is said to be active during a given simulation cycle -- If one of its sources is active -- If one of its subelements is active -- If the signal is named in the formal part of an association element in a port association list and the corresponding actual is active -- If the signal is a subelement of a resolved signal and the resolved signal is active Step g) of the simulation cycle (section 12.6.4) says: g) If the break flag is set, the time of the next simulation cycle, Tn, is set to Tc. Otherwise, Tn is determined by setting it to the earliest of: -- The value of type universal_time corresponding to TIME'HIGH -- The next time at which a driver becomes active -- The next time at which a process resumes Finally, section 12.6.6 says: 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'. These statements would suggest that S'Active could not return True unless Tc = Tn, where Tn = Tn'. The implication would be that S'Active returned False when called in an expression evaluated by the analog solver except when Ti = Tn', where a return value True is possible. This situation occurs at the last ASP in each simulation cycle, including delta cycles where Tc = Tn and consequently Ti = Tn. This behavior would cause isolated discontinuities for some quantities in the ASP at Tn, something that is highly undesirable in continuous-time models. Since great care has been taken in other parts of the language definition to avoid discontinuities, this appears to be an oversight. In other words, the behavior just described for S'Active is not the intended behavior. To avoid discontinuities S'Active should always return False when called in an expression evaluated by the analog solver. There are conceptually three ways to achieve the desired result: 1) The definition of an active driver is changed such that the driver is active only after the driver has acquired a new value (regardless of whether the new value is different from the previous value). This approach is problematic because: - LRM 12.6.3 defines updating implicit signals as a consequence of the driver of the implicit signals being active - LRM 12.6.4 defines step c) of the simulation cycle as: c) Each active explicit signal in the model is updated. (Events may occur on signals as a result.) That is, a signal is updated only when it is active. The contemplated change to the definition of what constitutes an active driver would reverse cause and effect, with possibly far reaching consequences. We will not pursue this approach any further. 2) The definition of S'Active is changed such that the function always returns FALSE when called during step a) of the simulation cycle. 3) The definition of S'Active is changed such that the function returns TRUE if signal S is active and has been updated. We propose that the third alternative be adopted. This change in the definition of 'ACTIVE is completely transparent to models where step a) of the simulation cycle is a no-op, i.e. models that are compliant with IEEE Std. 1076. For models compliant with IEEE Std. 1076.1 the change ensures that 'ACTIVE always returns FALSE when called in step a) of the simulation cycle. Additionally, it affects the value returned by 'LAST_ACTIVE, which is defined as follows: For a signal S, S'LAST_ACTIVE returns the smallest value T of type TIME such that S'ACTIVE = True during any simulation cycle at time NOW - T, if such value exists; otherwise, it returns TIME'HIGH. With the proposed change to the definition of 'ACTIVE, the value of 'LAST_ACTIVE when called in step a) of the simulation cycle monotonically increases at subsequent analog solution points in a simulation cycle. 1076.1-ISAC Recommendation for IEEE Std 1076.1-1999 --------------------------------------------------- No action is required for S'Event because the definition appears complete and correct. The definition of S'Active should be changed such that it always returns False when called in an expression evaluated by the analog solver. No action is required about the current simulation cycle. 1076.1-ISAC Recommendation for Future Revisions ----------------------------------------------- The definition of S'Active is changed as follows: S'ACTIVE Kind: Function. Prefix: Any signal denoted by the static signal name S. Result Type: Type Boolean. Result: A value that indicates whether signal S is active and has been updated. Specifically: For a scalar signal S, S'ACTIVE returns the value TRUE if signal S is active during the current simulation cycle and S has been updated; otherwise, it returns the value FALSE. For a composite signal S, S'ACTIVE returns TRUE if any scalar subelement of S is active during the current simulation cycle and has been updated; otherwise, it returns FALSE.