Subject: Re: Proposal for rewriting Section 8.3.2
From: Dan FitzPatrick (dkf@synopsys.com)
Date: Wed Oct 31 2001 - 15:29:42 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
Martin O'Leary wrote:
>
> Sri,
>
> before we discuss this proposal on tomorrow, could you outline the
> reasons why you want to change section 8.3.2??
>
> Also could you outline the specific changes you want to make,
> desirably in terms of impact.
>
> As I mentioned in my previous email, there is a typo in a paragraph
> in 8.3.2 which should read;
>
> "All operators, functions and statements which are allowed in continuous
> context,
> except for case-equality, case-inequality, case, casex, casez,shall
> report an error if the expressions they operate on contain x or z bits".
>
> With this ammendment, what other issues do you have with 8.3.2?
>
> In terms of your proposal I have included comments in the attached message.
>
> Thanks and talk to you tomorrow,
> --Martin
>
> On Oct 29, 1:55pm, Srikanth Chandrasekaran wrote:
> > Subject: Proposal for rewriting Section 8.3.2
> > Hi Committee Members,
> > We have worked a proposal for rewriting section 8.3.2 which refers to
> >
> > Proposal:
> > =========
> > --------------------------------------------------------------------------------
> >
> > 8.3.2 "4-state logic processing in continuous context"
> >
> > The Verilog-AMS HDL provides limited support for accessing and comparing
> > 4-state-logic values in the analog context. The following operands
> > return 4-state-logic values:
> >
> > * digital net access (section 8.3.1)
> > * binary, octal, hexadecimal numbers (section 2.5).
> >
> > When the above operands are used in analog context expressions,
> > 4-state-logic to integer values conversion are performed (section 8.3.1)
> > when the expression is solved.
>
> >Processing of 'x' and 'z' states is
> > vendor specific.
> In the ammended 8.3.2, this is defined as erroreous unless such states
> are being operated on by case[xz], ===, !===. In the committee we decided
> to be restrictive in this way so that X, Z access in the analog block could
> be liberalize in the LRM at some later point without concern for breaking
> existing modules at that point. Changing 8.3.2 so that "Processing
> of 'x' and 'z' states is vendor specific" defeats this intent.
>
> >
> > Comparisons of 4-state logic values are limited to case, casez, casex
> > statements (section 6.5). All other analog context comparison
> > operators (ie. ===, !==) and statements (ie conditional) use real and
> > integer types only.
>
> In the 8.3.2 (ammended and unammended) suggests that ===, !==,
> case[xz] can be used to operate on 4-state expressions. In the proposal
> '===', '!==' were removed from that list. Can you explain why?
>
> >
> >
> > Example:
> > input net[1:2];
> > analog begin
> > case(net[1])
> > 1'b1: $strobe("net[1] = 1");
> > 1'b0: $strobe("net[1] = 0");
> > 1'bz: $strobe("net[1] = z");
> > 1'bx: $strobe("net[1] = x");
> > net[2]:$strobe("net[1] == net[2]");
> > endcase
> > end
> >
> > If "net" is discrete, the "1'bx" and "1'bz" cases are solved without error.
> > If the "net" is continuous then the processing of the "1'bx" and "1'bz" cases
> > will be vendor specific.
>
> If a net is continuous, the above code is erroreous. Section 5.1.1
> states that; "Flows and potentials on nets, ports, and branches are accessed
> using access functions."
> The value of "net" is not accessed using an access function.
>
> Another question I have is how could "net" become continuous?
> Based on the usage of "net" above, when a simulator is resolving the
> domains of nets in a circuit, it should assume that "net" is discrete.
>
> Thanks,
> --Martin
--Dan FitzPatrick | Voice: (425) 576-4105
This archive was generated by hypermail 2b28 : Wed Oct 31 2001 - 15:33:21 PST