Subject: RE: [sv-ac] and, or, intersect
From: Bassam Tabbara (bassam@novas.com)
Date: Thu Feb 13 2003 - 08:44:18 PST
Thanks Roy for writing this discussion down. I'd like to -second-
proposal d. My reasoning also stems from the thinking that this extends
"zero length" sequence meaning of boolean &&/|| (John calls this length
one for some reason).
Eric, I don't quite have a resolution for your wording below of
-requiring- (you only mean if no parenthesis precedence wins right ?
Same as always...), am I misinterpreting ?
-Bassam.
P.S. Just got Surrendra's note, I am -third-ing then :-)!
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Erich Marschner > Sent: Thursday, February 13, 2003 5:50 AM > To: Armoni, Roy; Cindy Eisner; sv-ac > Subject: RE: [sv-ac] and, or, intersect > > > 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 - 08:45:03 PST