RE: [sv-ac] call to vote on 1549

From: Bassam Tabbara <Bassam.Tabbara_at_.....>
Date: Tue Aug 14 2007 - 15:02:25 PDT
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