Subject: RE: [sv-ac] and, or, intersect
From: Erich Marschner (erichm@cadence.com)
Date: Thu Feb 13 2003 - 20:44:42 PST
Bassam,
| 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 ?
I don't know what "only ... if no parenthesis precedence wins ...".
The PSL syntax says, roughly,
SERE ::=
| ...
| Sequence '|' Sequence
| Sequence '&' Sequence
| Sequence '&&' Sequence
| ...
and
Sequence ::= '{' SERE '}'
That is, the operands of the sequential 'and/or/intersect' operators are syntactically required to have delimiters - in this case, curly braces.
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: Bassam Tabbara [mailto:bassam@novas.com]
| Sent: Thursday, February 13, 2003 11: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 - 20:45:16 PST