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

Thanks for the comments Bassam. Responses below. I seem to be having
email issues because I wrote this last night.  It seemed to have gotton
stuck in the outbox.

 

Lisa

 

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Tuesday, August 14, 2007 6:02 PM
To: john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] call to vote on 1549

 

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).

[Lisa Piper >>>] Good addition. I also added a reference to the
definition of cast compatible:

 

"Actual arguments that consist of expressions are checked at compile
time for cast compatibility (refer to section 6.22.4) with the types of
the corresponding formal arguments."

 

2) Parentheses are always implicit for passing expressions as arguments.

 

>>> rewrite to: "When passing ..... parentheses ..."

 

[Lisa Piper >>>] Done.

 

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

[Lisa Piper >>>] another good comment, but I am keeping the word
substitute for Doron.  How is this

 

Argument passing is done by substituting each argument with the actual
argument cast to the specified type, and using the rewrite algorithm
defined in [Note to Editor - insert reference to the section on the
rewrite rules here - I think this is F.2.3] to flatten property and
sequence instances. When passing expressions as arguments, parentheses
are always implicit.

 

 

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.

[Lisa Piper >>>] I chose to simply strike this. The next paragraph
references the valid data types section so I think that covers what was
intended. But I'm curious what the original statement implied that you
were so against?

 

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 ....

[Lisa Piper >>>] thanks! 

 

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.

[Lisa Piper >>>] I agree with Doron's comment in that I don't want to
define this. I actually changed it and then decided (after seeing
Doron's comment) that I needed to look more closely. This is an example
of what could be an issue:

 

From 6.24:   "If the expression is assignment compatible with the
casting type, then the cast shall

return the value that a variable of the casting type would hold after
being assigned the expression"  

 

If I cast a boolean to a property, what does tnat mean?  Does that mean
that all aspects of a property are defined, such as the disable iff (for
a boolean expression, the disable iff could be defined as false so it
never happens.)  This is an issue since only the top level property can
have a disable iff.

 

I think we are safer not addressing this issue.

 

 

** formal semantics write-up

[Lisa Piper >>>]Doron and John own all of the following. Consider these
additional comments.

 

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 ?

[Lisa Piper >>>] I noticed this was missing when I fixed this above.
Perhaps we should use consistent wording:

 

Argument passing is done by substituting each argument with the actual
argument cast to the specified type, and using the rewrite algorithm
defined in [Note to Editor - insert reference to the section on the
rewrite rules here - I think this is F.2.3] to flatten property and
sequence instances. When passing expressions as arguments, parentheses
are always implicit.

 

s

 

 

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.

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.