RE: [sv-ac] IEEE 1800 SV-AC: vote on updated proposal for #1549

Hi Lisa/All,
 
Here are my comments on the proposal. I think we need to discuss some of
the issues further.
 
1. It says: Also, the change of Mantis 1532 is assumed: "Remove
@sequence_instance from event_control to take care of sequences with
arguments". In the proposal we passed recently, @sequence_instance is
replaced by @ps_sequence_identifier. I am not sure how this affects this
proposal. Please take it into account in case there are any changes
needed.
 
2. In section 17.6.1, it talks about semantic checks "When a type is
specified, that type is enforced by semantic checks.". It is not clear
from the description, what those checks would be. Could you refer to a
section where those checks are specified or describe them here. 
 
3. In section 17.6.1, it says: "Sequence instances may be typed using
the sequence type.". Probably it should use word "shall" instead of
"may". 
Another question is " Will an actual of type boolean be allowed, when
formal's type is sequence or actual has to be an instance of a declared
sequence ?" In PSL it is allowed. I think this section needs to clarify
that.
 
4. Another thing which is not very clear from the current LRM is the
statement: The assignment rules for assigning actual argument
expressions to formal arguments, at the time of sequence instantiation,
are the same as the general rules for doing assignment of a typed
variable with a typed expression (see Clause 4).
This is really confusing. It gives the impression that we have to follow
the same rules as pass by value rules in the functions (i.e. allow
truncation, padding etc.). For padding and truncation to happen, there
has to be an implicit signal which gets assigned (as is the case with
pass by value). But arguments passed to the properties/sequences are
more like pass by reference (or substitution). So shouldn't typed
arguments of property and sequence behave the same way as pass by ref
behaves (pass by ref arguments do not allow truncation or padding). In
clauses 6.9.1, 6.9.2, 6.9.3, some of the type compatibility rules are
specified. The pass by ref uses type equivalency rules specified in
6.9.2. 
 
5. In section 17.6.1, it says "two similar ways of passing
arguments....". I think word "similar" does not apply here. The two
sequences can give very different results depending on the actuals.
 
6. In section 17.6.1, it says "Parentheses are implicit for passing
complex expressions as arguments. Actual arguments that
consist of complex expressions are checked at compile time for
compatibility with the types of the corresponding formal arguments.". It
is not clear what you mean by complex expression here. I think this
section has to make references to an existing LRM section to clarify
what the type compatibility rules are ?
 
7. In section 17.6.1, When an argument type is event, semantic checks
ensure that the argument is a legal event expression and that it is used
for clocking purposes. Please clarify the semantic checks. Similarly it
says "Any legal event_expression is allowed.", what is a legal
event_expression ? Is it defined somewhere else in LRM ?
 
8. Section 17.11.1, this section also needs to clarify if an actual of
type sequence_instance be allowed in case formal is of type property ?
 
Thanks.
Manisha
 
 


________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Eduard Cerny
Sent: Thursday, September 21, 2006 1:19 AM
To: Lisa Piper; sv-ac@server.eda-stds.org
Cc: Eduard Cerny
Subject: [sv-ac] IEEE 1800 SV-AC: vote on updated proposal for #1549


Thank you, Lisa. 
All: please vote on the updated #1549.
Thank you,
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Lisa Piper
	Sent: Wednesday, September 20, 2006 1:20 PM
	To: sv-ac@eda-stds.org
	Subject: [sv-ac] 1549 New Formal Types Updated and 1601 created
for new keyword for untyped formals
	
	

	Hi all,

	 

	I have updated 1549: "add missing formal type arguments"  to
eliminate references to "implicit" and opened 1601: "add new keyword for
untyped formal argument".  Please review both proposals.

	 

	Ed,

	 

	I believe 1549 is ready to vote on again. 

	 

	Lisa