Subject: RE: [sv-ac] and, or, intersect
From: Erich Marschner (erichm@cadence.com)
Date: Thu Feb 13 2003 - 05:50:02 PST
Roy,
| My answer was that in both cases the interpretation is not obvious. What we
| should do is to define a precise precedence for all the additional sequence
| operators. In any case, it will not be a good idea to overload the language with
| redundant symbols for similar operators in order to solve issues of precedence.
| IMO, a better choice would be to define precedence and use parenthesis wherever
| necessary.
I agree with you that precedence is not obvious in any case. One way around this, as you say, is to define totally new operators, with newly defined precedence, so there is no confusion. But there is another alternative - using existing logical operators for the analogous functions on sequences, and requiring that the sequence operands of those operators are 'parenthesized' so they are evaluated in the correct order. This allows us to overload existing Verilog operators insead of extending the language, and it *ensures* that the precedence will be obvious - rather than depending upon the user to use parentheses "when necessary".
For example, in PSL we require the operands of the sequence conjunction/disjunction operators to be curly-brace-enclosed sequences. So
{a; b} && {c; d}
is clearly sequence 'and' (length-matching), while
{a; b && c; d}
is clearly the same as
{a; (b&&c); d}
because the arguments are not enclosed in braces.
This approach would work equally well with parentheses instead of curly braces. A parenthesized simple expression can be treated as either a boolean or a sequence of length 1; if both operands of a logical operator are parenthesized simple expressions, either the boolean or the sequence interpretation can be applied (pick one as the default) because they both have the same effect.
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Armoni, Roy [mailto:roy.armoni@intel.com]
| Sent: Thursday, February 13, 2003 8:05 AM
| To: Cindy Eisner; sv-ac
| Subject: RE: [sv-ac] and, or, intersect
|
|
| Hi all,
|
| In addition to Cindy's proposal below, I would like to make
| proposal d:
| or will be changed to || (same as Verilog).
| and will be changed to && (same as Verilog).
| intersect will remain as in the current LRM.
|
| The reasoning is as follows:
| From the specification point of view, the "and" operator on sequences
| actually agrees with the Boolean connective AND. When we
| specify ( s and t
| ) we mean that s has to happen AND t has to happen. Since this is an
| extension of the && operator of Verilog in the sense that
| for sequences s,t
| of length one, ( s and t ) agrees with ( s && t ), I propose
| to use the same
| notation.
|
| A similar argument applies to why "or" should be changed to ||.
|
| As for the intersect operator, IMO we should not choose anything that
| resembles AND. The reason is that ( s intersect t ) does
| not mean that we
| apply the Boolean connective AND to the sequences s,t. It
| means something
| stronger, which also requires a length match between the two
| sequences.
| When interpreting s,t as regular expressions, this is indeed
| intersection.
| Thus, in the absence of anything better that does not resemble AND, I
| propose to remain with "intersect".
|
| An additional point that was raised during our last meeting
| is that "and" on
| sequences should be different than "&&" on expressions. I
| believe that it
| was Erich who gave the example of
| a ; b && c ; d
| that would be interpreted as
| a ; (b && c) ; d
| while in
| a ; b and c ; d
| the interpretation would be of
| (a ; b) and (c ; d)
| My answer was that in both cases the interpretation is not
| obvious. What we
| should do is to define a precise precedence for all the
| additional sequence
| operators.
| In any case, it will not be a good idea to overload the language with
| redundant symbols for similar operators in order to solve issues of
| precedence. IMO, a better choice would be to define
| precedence and use
| parenthesis wherever necessary.
|
| Regards,
| Roy
|
|
|
| -----Original Message-----
| From: Cindy Eisner [mailto:EISNER@il.ibm.com]
| Sent: Thursday, February 13, 2003 12:21 PM
| To: sv-ac
| Subject: [sv-ac] and, or, intersect
|
|
|
| all,
|
| i am not sure that i understand the rules for what we can
| propose and what
| we cannot, or even if any such rules have been laid down and
| by who. i
| disagree strongly that arguing syntactic matters is going to
| take up a lot
| of time. making a proposal takes a few seconds, discussion
| can be by email
| since the matter is a simple one, and voting is going to be
| by email also,
| as i understand it, so will require typing one additional character.
|
| in addition, i feel strongly that syntactic matters are
| important. like a
| good gui for a tool, good syntax has a huge influence on how
| a language is
| received by the user community.
|
| therefore, i am going continue with my proposal for changing
| the keywords
| "and", "or", and "intersect", for the following reason:
|
| it really bothers me that "or" is the union of regular
| languages, but "and"
| is not intersection. i think that we should either have the
| correspondence
| or-union, and-intersection, or not. so i suggest one of the
| following:
|
| proposal a:
|
| union be represented by the keyword "union"
| intersection be represented by the keyword "intersection"
| current keyword "and" stays "and"
|
| proposal b:
|
| union be represented by the keyword "or"
| intersection be represented by the keyword "and"
| current keyword "and" becomes "pand" (for prefix-and,
| because it requires
| the intersection of a prefix of one with the entire length
| of the other.
| this is reminiscent of using "xor" for "exclusive or")
|
| proposal c:
|
| union be represented by "||"
| intersection be represented by "&"
| current keyword "and" be represented by "&&"
|
| note that proposal "c" is *not* what we have today in psl,
| which uses "|",
| "&&", and "&" for union, intersection, and current "and",
| respectively. i
| like the argument (sorry, i didn't identify the voice of
| whoever made it)
| that a verilog bit-wise operator is appropriate when the lengths must
| match, and a verilog logical operator when they needn't match.
|
| regards,
|
| cindy.
|
| Cindy Eisner
| Formal Methods Group Tel:
| +972-4-8296-266
| IBM Haifa Research Laboratory Fax: +972-4-8296-114
| Haifa 31905, Israel e-mail:
| eisner@il.ibm.com
|
This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 05:51:37 PST