Subject: Re: Proposal for rewriting Section 8.3.2
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Wed Oct 31 2001 - 16:20:15 PST
>
> The discussion is not so easy to follow, but I believe
> if I understand Martin correctly, I agree with what he
> says below.
>
> In short, within the analog block, the restrictions arise
> to prevent propagate 'X' and 'Z' states through behavioral
> expressions expecting values in the real domain. The
> effect is that if the model developer wants to capture
> these 'X' and 'Z' states as part of the model behavior
> directly, he must use: case[xz], ===, and/or !==.
>
> Jon mentioned a degenerate case of "if (n == 1)" or something
> similar which would evaluate to 0 for net n = 'X' or 'Z'.
> Technically, this should also be allowed as it is only
> shorthand for "if (n !== 0 && n !== 1'bZ && n !== 1'bX)".
> The general idea was to prevent behaviors like:
> "V(o) <+ n;". If I recall, we weren't sure of all the
> implications to go through the NaN route.
>
> Either way, "vendor specific" is not a good idea here.
>
> --Dan
The reason for going the NaN is partly to get better symmetry
between the digital and analog behavior, it is as near as we
can get to an analog 'X' without actually inventing something
new. Anywhere the outcome of a calculation in the digital
domain depends on an 'X' or 'Z' the result is usually an 'X',
in AMS you just assign NaN instead if the LHS is real. For
general arithmetic NaN will get handled automatically by
your compiler and hardware - so not much to implement - and
you only have to check at the point where it gets assigned
to a branch for a run-time error.
Seems easier to me to use NaN than create a bunch of special
cases.
Kev.
This archive was generated by hypermail 2b28 : Wed Oct 31 2001 - 16:22:02 PST