SV-AC Ballot for 02/24/03, Vote due by 02/24/03 9PM Pacific Written by: Stephen Meier Ballot ====== 1 Sem1 Move sequence implication operator above sequence layer [] Yes []No 1.1 Sem1.1 Remove nested sequence implication [] Yes []No 2 Sem2 Remove Check construct [] Yes []No 3 Sem3 Do not allow initial and never to co-ocurr as directives [] Yes []No 4 Sem4 Require always to be explicitly declared [] Yes []No A yes vote is allowed on only one of items 9a or 9b 9a Syn4 Add an non-overlapping implication operator (Cindy's) [] Yes []No 9b Syn4 Change implication to non-overlapping form (Adam) [] Yes []No A yes vote is allowed on only one of items 10a or 10b 10a Change delay semantic to Cindy Eisner proposal [] Yes []No 10b Change delay semantic to Surrendra Dudani proposal [] Yes []No 11 Syn7 Remove named boolean feature [] Yes []No Ballot Notes: ============= Items require a simple majority of all cast votes to be approved. All items are minor items unless requested by 12noon Pacific Sunday to be major items. If minor items, then there is 1 vote per SVAC member in attendance. If major item then 1 vote per Accellera member company. Item 1: Move sequence implication operator above sequence layer ======= A yes vote would approve the following feature for sequence implication and => would be removed from the set of sequence operations. prop_declaration ::= ‘property’ named_prop { ‘,’ named_prop } ; named_prop ::= identifier [ ‘(’ identifier { ‘,’ identifier }’ )’] ‘=’ prop_spec prop_spec ::= [‘initial’] [‘accept’ ‘(’ expression ‘)’ ] [‘never’] clocked_expr | identifier [‘(’ expression_list ‘)’] // identifier must be a property clocked_expr ::= [event_control] ‘(’ prop_expr ‘)’ prop_expr ::= sequence_expr | implication | ‘(’ prop_expr ‘)’ implication ::= sequence_expr => prop_expr Intuitive semantics of the implication is as follows: 1) if there is no match for the sequence_expr, then the result is true. It has no length, as it is a property, not a sequence anymore 2) for every match of sequence_expr, prop_expr must be true at the end point of the match From the above description, prop_expr can be a sequence_expr. The prop_expr results in true, if there is at least one match of sequence_expr, and false, if no match if found. Item 1.1: Remove nested sequence implication ========= Contingent on approval of Item 1, then Item 1.1 would modify the syntax to disallow prop_expr on RHS of implication. A yes vote would restrict the syntax as follows. This would further restrict current dynamic variable support. implication ::= sequence_expr => sequence_expr Item 2: Remove check construct ======= A yes vote would remove the check construct from the LRM. Item 3: Do not allow initial and never to co-ocurr as directives ======= A yes vote would indicate that initial and never directives would not be allowed at the same time. Note that semantics group has unanimously reccomended that never keyword be changed to not to conform with its semantic description. If voted yes the syntax would appear something like the following: prop_spec ::= [‘accept’ ‘(’ expression ‘)’ ] [[‘initial’ |‘never’] clocked_expr | identifier [‘(’ expression_list ‘)’] // identifier must be a property Item 4: Require always to be explicitly declared ======= A yes vote would require that always be explicitly declared. Currently always is implict unless initial overrides the directive. A voted yes and independent of other issues the syntax would look something like this prop_spec ::= {‘initial’ | 'always'} [‘accept’ ‘(’ expression ‘)’ ] [‘never’] clocked_expr | identifier [‘(’ expression_list ‘)’] // identifier must be a property Item 9: Add an non overlapping implication operator ======= A yes vote on 9a would add a new non-overlapping implication operator where the RHS sequence is evaluated one sample tick later than the success of the LHS. A yes note on 9b would change current definition of implication operator to evaluate one sample tick later than the success of the LHS. Item 10: Change delay semantic ======== A yes vote on 10a would change the semantic to Cindy Eisner proposal as follows: here is an alternative proposal to "syn1", based upon an idea of john havlicek's that was proposed offline. like "syn1", it involves removing one kind of delay. but it chooses to remove the binary delay, rather than the unary delay. it is equivalent to "syn1" when a delay is used after a semi-colon, as in "a ; [3] b", but is different than "syn1" in that it allows a leading [n] as well. for example, in this proposal, "[3] a" is a legal sequence, whereas "[3] a" is not legal under "syn1". i have taken the liberty of changing the name from "unary delay" to "unary start-at", since the use of a leading [n] in this proposal no longer gives the meaning of a delay of "n" cycles, but rather has the inuitive meaning of "start at the nth cycle". the proposal assumes that we have two kinds of concatenation defined: BINARY CONCATENATION: "r;s" is defined to mean an occurence of "r" followed by an occurence of "s" such that the first cycle of "s" happens the cycle after the last cycle of "r". BINARY OVERLAPPING CONCATENATION (FUSION): "r;[0]s" is defined to mean an occurence of "r" followed by an occurence of "s" such that there is an overlap of one cycle between "r" and "s". that is, such that the first cycle of "s" happens the same cycle as the last cycle of "r". we now define the "unary start-at" operator as follows: informally: UNARY START-AT: "[n] r" means that r starts on the n'th cycle. thus "[1] r" is equivalent to "r", "[2] r" is equivalent to "1;r", etc. semi-formally: UNARY START-AT: If n > 0, then "[n]r" is defined and it means the same thing as "1*[n] ;[0] r". examples: [1] a means a [2] a means 1;a [3] a means 1;1;a a ;[1] b means a ; b a ;[2] b means a; 1; b a ;[3] b means a; 1; 1; b a ; ([1] b) means the same as a ;[1] b a ; ([2] b) means the same as a ;[2] b a ; ([3] b) means the same as a ;[3] b the second three examples show that the definition of "unary start-at" gives the same meaning to "a ; [n] b" as did the definition of "binary delay" in revision 0.79. the advantage of the current proposal over "syn1" is that in addition, it allows a "leading delay" as in the first three examples. finally, the advantage of the current proposal over revision 0.79 is that the definition of "unary start-at" does not put undue semantic responsibility on the parentheses, as shown by the last three examples. A yes vote on 10b would change the delay semantic as follows: After digesting the discussion so far, I would like to propose the following syntax for delay/concatenation. Please review and provide your feedback. Also attached are examples written in this syntax. The examples are borrowed from the vfv committee. sequence_expr ::= sequence_instance | '(' sequence_expr ')' | boolean_expr | range sequence_expr | sequence_expr { ';' range sequence_expr } | sequence_expr ‘*‘ range | boolean_expr '*=' range | sequence_expr 'within' sequence_expr | boolean_expr 'throughout' sequence_expr | sequence_expr and sequence_expr | sequence_expr or sequence_expr | sequence_expr intersect sequence_expr | first_match '(' sequence_expr ')' | '(' var_decl {,var_decl}; sequence_expr ')' range ::= ‘[’ constant_range_expression ‘]’ | ‘[’ constant_range_expression ‘:’ constant_range_expression ‘]’ | ‘[’constant_range_expression ‘:’ inf ‘]’ Main advantages: 1) Consistent notation for unary and binary delays 2) Single operator for concatenation 3) Minimum rules 4) No extra parenthesis required 5) overall less typing Disadvantage: 1) No default for concatenation with delay 1 (;) Following are the main differences from 0.80 version : 1) unary and binary delays are allowed 2) unary delay 0 means the current evaluation tick 3) binary delay 0 means overlapped concatenation 4) No extra parenthesis required to delineate sequences 5) No default delay 1 for concatenation Please note that 1) boolean operators have higher precedence than sequence operators 2) precedence of sequence operators in order as below: * , =* ; range and , intersect or throughout within 3) left to right association Item 11 remove named boolean feature ======= A yes vote would remove the named boolean feature in 11.7 would be removed from LRM.