Subject: RE: Proposal for rewriting Section 8.3.2
From: John Shields (john_shields@avanticorp.com)
Date: Mon Oct 29 2001 - 10:16:36 PST
Hi,
I am wondering what the thinking is behind the rules described in the LRM?
It seems to me that the issue should be defined in terms of properly
typing expressions, rules for promotion of types when the operands are
of mixed types, and proper grammer for the statements.
The rules for accessing digital values in an analog context
intends to insure that reasonable implicit type casting rules to promote
a digital value to a integer( or real) value exist, including defined error
conditions. Conversely, if there are statements that are defined to operate with
4 state values in an analog context, then no promotion of expressions
is required.
If that is the premise, and the case statements in an analog context are
defined to handle a 4 state value, then there should be no conflict with
any expression in the case stmt that produces a 4 state value. If you define that
a binary expression such as === or !==, if both operands are 4 state value
types(reg, wires promoted to reg, manifest constants,literals, etc.), remains
a 4 state value typed expression, then the case statement works in a
uniform way...no implementer discretion involved.
Defining when a 4 state value expression must be promoted to a integer value
in an analog context is necessary. It is those circumstances where an x,z bit
has to a) be coerced to a 0,1 bit value in order to effect the cast operation
--OR-- be called a runtime error.
It seems to me that a more uniform expression evaluation can be achieved. What
would change is that the BNF for a case statement in an analog context would
change slightly. The genvar expression, which implies promotion to an integer
value in its definition, would be split into a genvar and an integer_genvar. The
former would allow 4 state values but otherwise meet the globally static
requirement. The latter would be promoted to integer result. Perhaps a few other
grammer changes would be needed for consistency.
Finally, the reason why I am commenting is that the original and currently proposed
solution define special handling in a limited situation. In my experience,
there are often other similar situations that not explicitly identifed in the LRM,
where the special rule can be arguably applied. These lead down a confusing road to
gratuitous implementation variations. If you don't like my specific suggestion,
is there a way to express your desired result cleanly in the grammer?
Thanks,
John Shields
Avant! Corporation
-----Original Message-----
From: Srikanth Chandrasekaran [mailto:schandra@asc.corp.mot.com]
Sent: Sunday, October 28, 2001 7:25 PM
To: verilog-ams@eda.org
Cc: ghelwig@asc.corp.mot.com; schandra@asc.corp.mot.com
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.
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.
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.
--------------------------------------------------------------------------------
Let us know if you have any issues with this proposal.
Thanks & Regards,
Sri & Graham.
-- Srikanth Chandrasekaran Global Software Group, EDA SBU Motorola Australia. Phone: +61-8-8168 3592 Fax: x3501 email: schandra@asc.corp.mot.com
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 10:17:57 PST