Subject: Request Clarification: Q'INTEG'DOT and Q'DOT'INTEG
From: Craig Winters (cwinters@cadence.com)
Date: Fri Jun 14 2002 - 12:44:20 PDT
Hello all,
In implementing the language, we ran into problems with
the constructs Q'INTEG'DOT and Q'DOT'INTEG.
We are currently not supporting these specific constructs, but
would like clarification from the language committee and the
community in general as how these are handled.
The LRM says we have an augmentation set entry for each Q'INTEG
and for each Q where there exists a Q'DOT in the text of the model.
In each of these cases we have an INTEG and a DOT expression
in the augmentation set. Based on this observation:
What happens with Q'INTEG'DOT?
In the case of Q'INTEG'DOT we have an X'INTEG and a Y'DOT
(where X is "Q" and Y is "Q'INTEG") with corresponding
expressions in the augmentation set. Each expression should
be selectable for a break element. The problem is they both
share the same break selector, Q'INTEG.
If we then have a break statement such as
BREAK FOR Q'INTEG USE x => 1.0;
the selector quantity, "Q'INTEG" could refer to Q'INTEG or
Q'INTEG'DOT. If a model requires a specific augmentation set
expressions to be replaced, or both expressions, how are the
expressions selected?
What happens with Q'DOT'INTEG?
In the case of Q'DOT'INTEG we have an X'INTEG and a Y'DOT
(where X is "Q'DOT" and Y is "Q") with corresponding
expressions in the augmentation set.
The quiescent state augmentation set entry for "X'INTEG" is
"X == 0" or its equivalent. The quiescent state augmentation
set entry for "Y'DOT" is "Y'DOT == 0" or its equivalent.
By substitution, Q'DOT'INTEG gives us two equations for the
augmentation set:
X == 0 produces Q'DOT == 0
Y'DOT == 0 produces Q'DOT == 0
Likewise, the discontinuity augmentation set entries for X'INTEG is
X'INTEG == X'INTEG(t-) and for Y'DOT is Y == Y(t-). By substitution,
Q'DOT == Q'DOT(t-) and
Q'DOT == Q'DOT(t-)
Again, we have identical equations producing a singular matrix.
Resolution:
If my analysis is correct, and these are ambiguous constructs, I see
two possible resolutions.
1. We simply make the constructs illegal
2. We declare both constructs to be identity expressions with Q,
and require the implementation to replace them with Q, thereby
produce no augmentation set expressions. This way we remove
both the break element possibility and the conflicting
Thanks to the language committee and members who can help resolve
this issue for us.
Craig Winters
Cadence Design Systems, Inc.
cwinters@cadence.com
This archive was generated by hypermail 2b28 : Fri Jun 14 2002 - 13:02:52 PDT