I vote yes -- assuming item 4 *** below is just an oversight and will be effectively stricken. Friendly amendments: 1) Actual arguments that consist of expressions are checked at compile time for compatibility with the types of the corresponding formal arguments. >>> What level of compatibility (see 6.22) ? Say *cast compatibility* to be clear (even if 2nd sentence talks of cast). 2) Parentheses are always implicit for passing expressions as arguments. >>> rewrite to: "When passing ..... parentheses ..." 3) Argument passing is done by substitution (refer to the section on formal semantics Refer to [Note to Editor - I think this is F.2.3] Parentheses are always implicit for passing expressions as arguments. >>> formal semantics write-up strikes out substitution in favor of *rewriting*. Use "cast-compatible rewriting/replace" instead 4) Also arguments to these sequences shall be static; automatic variables used as sequence arguments shall result in an error. >>> which sequences ? Sentence needs re-wording >>> rewrite to: Arguments .... . Automatic ... >>> *** Do we really want to have this restriction ? Why ? This is extreme. If you mean the operand types we have then fine, this is listed there strike this out -- in its current form it covers waaaay more than the operand type restrictions in 16.5.1. 5) The supported data types for sequence formal arguments are the types that are allowed for operands in assertion expressions (see 16.5.1) and the keyword context. ** The supported data types for sequence formal arguments are the types that are allowed for operands in assertion expressions (see ** >>> repetition .... 6) 16.5.1). In addition, sequence expressions may be typed using the sequence type and the event type. A formal type of sequence requires an actual argument that is either a Boolean expression or a sequence expression. An actual arg of type property would cause an error when the formal type is sequence. .... A formal argument of property type can accept a Boolean expression, sequence expression, or property expression actual argument. The rules for passing arguments to properties is the same as those for sequences. Refer to 16.7.1. >>> I suggest we say something to the effect of cast compatible as a general statement that we can use for other things in future. ** formal semantics write-up 7) if e is such an expression, then $var(e) behaves like e in all respects except that operations allowed on a reference to or instance of a named item declared with the same type as e are also allowed on $var(e). ** In particular, any operation that is allowed on a reference to a variable declared with the same type as e is allowed on $var(e). ** >>> repetition >>> do we want to mention type compatibility here or somewhere else in formal semantics ? 7) $var because opera- tions that are legal on a reference to a formal argument within the body of a declaration might no longer be legal when an actual argument expression is sub- stituted for the reference to the formal argument >>> use "replaced (with appropriate casting)" or use "rewritten" 8) then the part select operation cannot be applied when e is substituted for v because ((logic[0:3])'({a,b}))[1:2] is illegal. >>> use "replaced (with appropriate casting)" or use "rewritten" Thx. -Bassam. -----Original Message----- From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John Havlicek Sent: Monday, August 13, 2007 6:22 AM To: sv-ac@eda-stds.org Subject: [sv-ac] call to vote on 1549 All: This is the call to vote on the proposal for Mantis 1549. The proposal consists of two documents: 1549_new_types_14.pdf formal_semantics_arguments_passing.2007-08-06.pdf Please vote if you are eligible. See the details below. J.H. ------------------------------------------------------------------------ -- Ballot on Mantis 1549 - Called on 2007-08-13, final ballots due by 23:59 PDT on 2007-08-20. v[xx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Freescale) v[xxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys) n[---x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys) v[xxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale) t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair) v[xxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair) n[-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics) n[-----------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics) n[---x--xxx.....................] Joseph Lu (Altera) n[--------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale) v[xxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence) v[xx-x-xxxxx-x..................] Erik Seligman (Intel) n[----xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics) v[xxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys) v[xxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems) |------------------------------ attendance on 2007-08-07 |-------------------------------- voting eligibility for this ballot |--------------------------------- email ballots received Legend: x = attended - = missed r = represented . = not yet a member v = valid voter (2 out of last 3 or 3/4 overall) n = not valid voter t = chair eligible to vote only to make or break a tie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Aug 14 15:02:47 2007
This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 15:03:10 PDT