-------------BEGINNING OF IR---------------- VHDL Issue Number: 2050 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Definition of S'Last_Value was apparently broken in 1993 Relevant_LRM_Sections: Section 14. Related_Issues: Key_Words_and_Phrases: 'last_value Authors_Name: Erich Marschner Authors_Phone_Number: 410 750 6995 Authors_Fax_Number: Authors_Email_Address: erichm@cadence.com Authors_Affiliation: Cadence Authors_Address1: Authors_Address2: Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 14 December 2004 Date Analyzed: 18 March 2005 Author of Analysis: Peter Ashenden Revision Number: 03 Date Last Revised: 03 February 2006 Description of Problem ---------------------- - VHDL 87 defines the value of S'Last_Value at time 0 (and prior to the first change on S) to be equal to S. - VHDL 93 does not appear to define the value of S'Last_Value at time 0 / prior to the first change on S. - VHDL 2002 contains the same definition as in VHDL 93 The VHDL 1076-1987 LRM contains the following definition for S'Last_Value (on page 14-8): S'LAST_VALUE Kind: Function Prefix: Any signal denoted by the static signal name S. Result Type: The base type of S. Result: The previous value of S, immediately before the last change of S. Specifically: For a scalar signal S, S'LAST_VALUE = S'DELAYED(T) where T >= 0ns is the smallest value such that S'STABLE(T) is FALSE. If no such T exists, then S'LAST_VALUE is equal to S. For a composite signal S, S'LAST_VALUE is equal to the aggregate of the previous values of each element of S. Note that this defines the value of S'Last_Value at time 0, by saying that if no previous change on S occurred (i.e., no T>=0ns exists for which S'STABLE(T) = False), then S'Last_Value is equal to S. This applies at time 0, since all signals are presumed to be stable at time 0, and to have had their initial values for an infinite time into the past (see 12.6.4, The simulation cycle, first bullet of initialization phase), and furthermore continues to apply up until the first change on S. The VHDL 1076-1993 LRM contains the following definition for S'Last_Value (on page 188): S'LAST_VALUE Kind: Function Prefix: Any signal denoted by the static signal name S. Result Type: The base type of S. Result: The previous value of S, immediately before the last change of S. Note that the specific details were apparently deleted, so the new definition no longer addresses the issue of the value at time zero (and up until the first change), nor does it address the meaning of S'Last_Value for a composite signal S. It may be that it is unnecessary to define S'Last_Value separately for scalar and composite signals, but it is clearly important to define the value of S'Last_Value at time 0 (and prior to the first change on S). The VHDL 1076-2002 LRM contains the same definition of S'Last_Value (on page 198) as appears in the VHDL 1076-1993 LRM. Comment from azro@onebox.com: Erich: The definition from 1987 was not correct because it did not provide for the case where changes occurred two or more deltas before. Restoring to '87 (as you recommend) is not the correct solution. Regards, Alex Z -- Alex Zamfirescu azro@onebox.com Comment from Bailey, Stephen Alex, Maybe I'm missing something, but how can there be one or two deltas before time 0? -Steve Bailey Comment from azro@onebox.com: Steve: I did not claim that there are deltas before the first one at time zero. What I meant was that Erich's proposal to go back to the '87 definition should not be followed, because the '87 definition was wrong. It was wrong in not providing for the case where there is a change in a particular delta that is two or more deltas behind now. Going back to that definition (based on whatever reason to fix the first delta of the time zero) would bring back the problem for these other cases, and other problems with the composite types. Here is a simple example Signal S : integer := 0; begin S <= 100 after 5 ns; wait on S; -- Here S is 100 S <= 101; wait; -- Here S is 101; S <= 102; wait; -- Here S is 102 wait; -- Here S is also 102 wait; --S'last_value should be 101 here, --but S'Delayed(0 ns) is 102, and S'Delayed(5 ns) is 100. Besides the fact that the '87 explanation "For a scalar signal S, S'LAST_VALUE = S'DELAYED(T) where T >= 0ns is the smallest value such that S'STABLE(T) is FALSE. If no such T exists, then S'LAST_VALUE is equal to S." contradicts the intended well expressed definition "Result: The previous value of S, immediately before the last change of S." in cases like the one I described, there is a second problem with that (the '87 def) related to: "For a composite signal S, S'LAST_VALUE is equal to the aggregate of the previous values of each element of S." Using this definition S'LAST_value might take a value that the composite signal S never got. Does this require explanations too? Anyway, please do not revert last_value definition to its *last_value* (that before its last change in '93),. Regards, Alex Z Comment from Erich Marschner Alex, When S'Last_Value was originally defined (with the definition given in VHDL 87), it was well known that it did not track changes over a series of delta cycles. At the time, that was acceptable. If this is now considered a problem, then I agree that a new definition is required. However, the current definition is broken, because it no longer specifies the value of S'Last_Value prior to the first change on S. The definition Result: The previous value of S, immediately before the last change of S. presumes that there IS some 'last change of S' that determines which previous value of S should be returned. In the absence of any change on S, this definition does not apply. So at the very least this definition needs to be extended to say Result: The previous value of S, immediately before the last change of S, if any; otherwise the current value of S. Regards, Erich Comment from azro@onebox.com: Erich: The definition from '87 was *not* acceptable. IMHO that's why it was changed. It not only did not track changes over deltas, but also it had the problem with the composite last value that could be one that did not occur. So the definition was clearly flowed, and for all of us, unacceptable. Note that the fact that in that definition T could be also 0 means that people then tried to cover also 0 delay (deltas). Your simple second proposed fix is much better (and simpler) then going back to the unacceptable, then and now, '87 definition. However, I would formulate it differently. Instead of: Result: The previous value of S, immediately before the last change of S, if any; otherwise the current value of S. I would recommend: Result: The value of S in the simulation cycle immediately before the one where last change of S occurred, if such cycle exists, otherwise the current value of S. Here "before" and "last" have their meaning defined based on the standard cycle execution order. It is either that or the relation "before" should be extended for (time, delta) pairs as follows (time1, delta1) is before (time2, delta2) iff (( time1 < time2) or (( time1 = time2) and (delta1 < delta2))) where timeX is the simulation time and deltaX holds the value of an ascending counter for the simulation cycles occurring at the same time point. Delta counter is incremented as a new cycle is simulated for the same time point. The definition for "last" using this order can also be formalized. The approach using time/delta pairs is better then just a simulation cycle order or counter, which which will do it for this "before" and "last" The time/delta generalized time is better because it is useful for the formal definition of many other functions, signal attributes, process behavior, and new constructs. Yet another choice is to clarify what order is "before" and "last" referring to. There are: simulation time, the standard cycle execution order, and the wall clock time order. Note that "standard" is required in the second one because in some cases the cycle execution could be done out of order with correct result. Clearly defined relations become important when we want to build annotation languages on top of VHDL. Is that new to anybody ? :-) Note that there is another order relation that is implied by the VHDL semantic, and that is the order of evaluation, of signals over nets, guard expressions and guard signals. Regards, Alex Z Proposed Resolution ------------------- Restore the definition of S'LAST_VALUE to the form that appeared in the VHDL 1076-1987 LRM. VASG-ISAC Analysis & Rationale ------------------------------ The issue author (Marschner) is correct that the VHDL-2002 definition of 'last_value does not define the value of the attribute for the case where no change has occurred on the prefix since initialization. The commentator (Zamfirescu) notes that the definition in VHDL-87 was problematic. ISAC IR0039 describes the problems and proposes a resolution. However, the change in VHDL-93 does not implement the proposed change in IR0039 exactly; the annotated VHDL-93/C draft also refers to "Guyler 2", presumably comments from Guyler on a previous draft. The change to the definition of 'last_value in VHDL-93 deals with composite signals implicitly. It defines S'last_value in terms of the value of S before a change of S. A change is defined in terms of the predefined "=" operator for the type of S. That operator treats the value of S as a whole, so the attribute value is the whole value of S before the last change on any subelement of S. However, as commentators point out, in making the change, it appears that the VASG overlooked definition of the value of S'last_value before any change has occurred on S. Reverting to the VHDL-87 definition, as Zamfirescu points out, is not appropriate, since it would reintroduce the problems that the VHDL-93 revision attempted to solve. A rewording of the definition needs to take into account: - treating the prefix signal as a whole, - dealing with changes over multiple delta cycles at the current and previous simulation times - dealing with the possibility that an event has occurred at the current simulation cycle - dealing with the possibility that no events have previously occurred A wording that takes these requirements into account is: For a signal S, if an event has occurred on S in any simulation cycle, S'LAST_VALUE returns the value of S prior to the update of S in the last simulation cycle in which an event occurred; otherwise, S'LAST_VALUE returns the current value of S. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- Interpret the definition of S'LAST_VALUE as though it were as recommended for future revisions. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Change the definition of the result of S'LAST_VALUE to the wording proposed in the analysis. -------------END OF IR----------------