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

Hi Lisa,

 

What is a benefit of "strict" qualifier?  E.g., if you request a
sequence, a Boolean value will always do.

 

Thanks,

Dmitry

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Lisa Piper
Sent: Tuesday, September 26, 2006 6:05 PM
To: Bassam Tabbara; Kulshrestha, Manisha; sv-ac@server.eda-stds.org
Subject: RE: [sv-ac] IEEE 1800 SV-AC: vote on updated proposal for #1549

 

Hi all,

 

I apologize for being "quiet" on the subject.  My schedule has been very
hectic and I needed to study it more.  I will comment on the comments
below.  Hopefully we can discuss this live, if not this week, next week.

 

Lisa

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Thursday, September 21, 2006 2:58 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] IEEE 1800 SV-AC: vote on updated proposal for #1549

 

Hi Manisha, some comments on a couple of items below to help a bit as I
read this.

 

1. I think this can be taken out, I think remnant from before (we had
event_control instead of event_expression).

2. Falls under the Boolean < Sequence < Property umbrella.

[Lisa Piper >>>] I had not realized that this relationship existed.  It
is different in PSL, where a braced boolean or repeated boolean are
interpreted as sequences, but not a boolean by itself.  At least that is
our interpretation of the PSL standard (I talked with our PSL standards
representative.)  SVA is indeed different and this needs to be
clarified.  That said, I question how beneficial "typing" is at all.  I
think a 'strict" qualifier is needed that says it must be exact.

3. I think the "may" because you can use untyped ...  As far as Boolean,
the other data types (bit/byte/....) fill in for this role -- a
"Boolean" type in SV proper would be a true/false enum ... not what we
mean here ... so adding it might be confusing.

[Lisa Piper >>>] This is true.  The working was "may" since it can be
untyped.

4. Ok this needs some thought here, we've always had this issue of how
to describe, by ref comes close ....

[Lisa Piper >>>] agreed - needs discussion.

5. Agreed.

[Lisa Piper >>>] I was assuming strict typing so you a probably right.

6. Agreed on complex. As far as typing etc ... yeah back to (2) etc...

7. Yes this is hard on the eyes, I think 3 sentences could be one:
event_expression. As far as defining it, it refers to the BNF
event_expression, we have many places in LRM where we refer to something
in this way (e.g. property_spec), we typically italicize.

 

Thx for the detailed critique, I think (4) is the most serious. Hmm in
fact I think this is one of the main reasons why we postponed rushing
the typing last time :)! Discussion was too wrapped up this time with
the seq/prop types.

 

Thx.

-Bassam.

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Thursday, September 21, 2006 11:20 AM
To: sv-ac@eda-stds.org
Subject: 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