Subject: RE: [sv-ac] and, or, intersect
From: Bassam Tabbara (bassam@novas.com)
Date: Thu Feb 13 2003 - 08:47:26 PST
Oops, typo.
> boolean &&/|| (John calls this length one for some reason).
Roy calls it length one in the proposal, sorry Roy/John.
> -----Original Message-----
> From: Bassam Tabbara [mailto:bassam@novas.com]
> Sent: Thursday, February 13, 2003 8:44 AM
> To: 'Erich Marschner'; 'Armoni, Roy'; 'Cindy Eisner'; 'sv-ac'
> Subject: RE: [sv-ac] and, or, intersect
>
>
> 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:48:05 PST