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 usefull 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
--
Alex Zamfirescu
azro@onebox.com - email
(877) 332-0676 - voicemail/fax
-----Original Message-----
From: Erich Marschner <erichm@cadence.com>
Sent: Wed, 15 Dec 2004 06:29:24 -0800
To: <azro@onebox.com>
Cc: <vhdl-200x@eda.org>
Subject: RE: RE: RE: [vhdl-200x] VHDL LRM issue re: S'Last_Value
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
| -----Original Message-----
| From: owner-vhdl-200x@eda.org
| [mailto:owner-vhdl-200x@eda.org] On Behalf Of azro@onebox.com
| Sent: Wednesday, December 15, 2004 7:58 AM
| To: vhdl-200x@eda.org
| Subject: FW: RE: RE: [vhdl-200x] VHDL LRM issue re: S'Last_Value
|
| Steve:
|
| I forwarded this via reflector because I got this delivery failure.
|
| SBailey@model.com
| Delivery failed
| 550-The address specified
| 550-in your email is not a recipient recognized by this
| 550-E-Mail system....
|
| Others might also want to read the explanation.
|
| Regards,
|
| Alex Z
|
|
| Alex Zamfirescu
| azro@onebox.com - email
| (877) 332-0676 - voicemail/fax
|
|
|
|
| -----Original Message-----
| From: azro@onebox.com
| Sent: Wed, 15 Dec 2004 07:44:31 -0500
| To: SBailey@model.com;azro@onebox.com
| Subject: RE: RE: [vhdl-200x] VHDL LRM issue re: S'Last_Value
|
| 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
|
| --
| Alex Zamfirescu
| azro@onebox.com - email
| (877) 332-0676 - voicemail/fax
|
|
|
|
| -----Original Message-----
| From: Bailey, Stephen <SBailey@model.com>
| Sent: Tue, 14 Dec 2004 22:14:49 -0800
| To: <azro@onebox.com>
| Subject: RE: [vhdl-200x] VHDL LRM issue re: S'Last_Value
|
| Alex,
|
| Maybe I'm missing something, but how can there be one or two deltas
| before time 0?
|
| -Steve Bailey
|
| > -----Original Message-----
| > From: owner-vhdl-200x@eda.org
| > [mailto:owner-vhdl-200x@eda.org] On Behalf Of azro@onebox.com
| > Sent: Tuesday, December 14, 2004 11:09 PM
| > To: erichm@cadence.com; Bailey, Stephen
| > Cc: Jim@synthworks.com; vhdl-200x@eda.org
| > Subject: RE: [vhdl-200x] VHDL LRM issue re: S'Last_Value
| >
| > 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 - email
| > (877) 332-0676 - voicemail/fax
| >
| >
| >
| >
| > -----Original Message-----
| > From: Erich Marschner <erichm@cadence.com>
| > Sent: Tue, 14 Dec 2004 12:16:21 -0800
| > To: "Bailey, Stephen" <SBailey@model.com>
| > Cc: "Jim Lewis" <Jim@synthworks.com>;"VHDL-200x"
| > <vhdl-200x@eda.org>
| > Subject: [vhdl-200x] VHDL LRM issue re: S'Last_Value
| >
| >
| > Steve,
| >
| > This is a reminder regarding the VHDL LRM issue that we noted
| > today during the IEEE 1850 Extensions SC meeting.
| >
| > Issue: Definition of S'Last_Value was apparently broken in 1993
| >
| > Summary:
| > - 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
| >
| > Details:
| >
| > 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.
| >
| > Recommendation:
| >
| > Restore the definition of S'LAST_VALUE to the form that
| > appeared in the VHDL 1076-1987 LRM.
| >
| > Regards,
| >
| > Erich
| >
| > -------------------------------------------
| > Erich Marschner, Cadence Design Systems
| > Senior Architect, Advanced Verification
| > Phone: +1 410 750 6995 Email: erichm@cadence.com
| > Cell: +1 410 294 2599 Email: erichm@comcast.net
| >
| >
| >
| >
| >
| >
|
|
|
|
|
|
|
|
Received on Wed Dec 15 21:22:43 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 15 2004 - 21:23:29 PST