FW: [sv-ac] RE: Mantis 928 Proposal

Resend for Lisa

-----Original Message-----
From: owner-sv-ac@server.eda-stds.org
[mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Lisa Piper
Sent: Friday, June 16, 2006 7:17 PM
To: Bassam Tabbara; Eduard Cerny; sv-ac@server.verilog.org
Subject: RE: [sv-ac] RE: Mantis 928 Proposal

Bassam,

Thanks very much - comments below.

Lisa

________________________________
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
Sent: Thursday, June 15, 2006 10:07 PM
To: Eduard Cerny; Lisa Piper; sv-ac@verilog.org
Subject: RE: [sv-ac] RE: Mantis 928 Proposal

Hi Lisa,

Thx for the reminder, I started this last week but never finished it :).
Here's some feedback:

1) VPI: Ed about your question I don't think there is any fundamental
change here from previous. However looking at the VPI diagrams, it bugs
me why 27.33 propertyinst does not have "vpiArgument" like sequenceinst
of 27.35, also 27.34 should have this added like it is 27.36.

[Lisa Piper >>>] this is a new issue unrelated to this.

2) Remove the "In addition ..." added sentence. We should not be adding
(partial) semantic check descriptions here, the chapter already adds
that detail when needed, and we already say things will be semantic
checked, this is one among many, see (3).

[Lisa Piper >>>] done

3) Remove the added "for typed formals" in the sentence beginning with
"Semantic ....". The sentence is not just meant to talk about formals
but rather anything passed and "inlined" will be semantic checked e.g.
passing a wrong arg to a range etc..

[Lisa Piper >>>] done

4) Just color property_actual_arg (also sequence) as one new blue
addition, remove this extra crossed our arg, confusing to editor for
sure. See (6) and (7) below.

 [Lisa Piper >>>] done

5) The *, (*): I think this can be easily confused with the implicit
connection .* and the like, better remove for simplicity, it's not like
there will be that many clocks on average :). The implicit connection is
worthwhile but also too messy better force user to specify clearly and
minimize strange and insidious reports of semantic check failures say,
same argument actually goes for clocks too ...

 [Lisa Piper >>>] I don't have a problem with that if nobody else
expresses a need.

6) Let's not add more baggage here keep things simple/clean instances
and simple expressions only, also why are we adding the named event
trigger ... these are concurrent assertions, event_expression is what we
need.

property_actual_arg::=
| property_instance
| sequence_instance
| expression
| event_expression


7) Sequence

sequence_actual_arg ::=

| sequence_expr
| expression
| event_expression

 [Lisa Piper >>>] As far as sequence expression versus sequence
instance, I guess I was giving the equivalent PSL functionality.  In PSL
you can
pass a sequence expression. I don't have a problem with eliminating that
if nobody expresses a need for it.

As far as the named event trigger, it is possible that a subroutine
called on sequence completion would want to set some named event. I
don't have a problem with eliminating that for simplicity if nobody
expresses the need for it.

As far as the "*" goes, I don't have a problem with eliminating that if
nobody expresses a need for it. 

8) sequence_expr -- remove added sequence_inst, it's already there.

 [Lisa Piper >>>] done. I did not see it before!

** The theme being let's fix what's broken with this ID, focusing on
important cleanup/corrections for consistency with LRM, avoid seemingly
simple enhancements add only what's needed to get the original intent
back in, put those in other proposals for more study if really needed.

Thx.
-Bassam.