[sv-ac] SV-AC meeting minutes, 8/24/2010

Minutes from SV-AC Committee Meeting
Date: 2010-08-24
Time: 16:00 UTC (9:00 PDT)
Duration: 1.5 hours

Dial-in information:
--------------------
Meeting ID: 38198

Phone Number(s):
1-888-813-5316 Toll Free within North America

Agenda:
-------

- Reminder of IEEE patent policy.
See: http://standards.ieee.org/board/pat/pat-slideset.ppt

- Minutes approval

- Email ballot results

- New issues

- Issue resolution/discussion
1763: The LRM does not define whether assertion control tasks affect sequence methods and events
2494: 37.44 Assertion diagram missing restrict
2205: $asseroff, $assertkill and $asserton description is ambiguous
3117: make it clear that rewriting algorithm (F.4.1) applies to checker and let
1853: BNF for calls to $rose and other sample value system functions.
2452: No vacuity information about synchronous aborts
2904: Clarify when disable iff condition must occur relative to starting and ending of an attempt
3134: sequence and property range parameters are erroneously defined
3135: Verbal explanation of nexttime and always is misleading for multiple clocks
1678: Clarify that rewriting algorithm doesn't replace name resolution
2571: confusing assertion clock inference rule
2386: Rename 16.9 to "Local variables"?

- Enhancement progress update
2751: P1800-2009: checker formal arguments may not be connected to interfaces // WHY?
3035: More flexible definition of checker argument sampling
2328: Review and relax restrictions on data types in assertions

- Opens

Attendance Record:
------------------
         Legend:
                 x = attended
                 - = missed
                 r = represented
                 . = not yet a member
                 v = valid voter (2 out of last 3 or 3/4 overall)
                 n = not a valid voter
                 t = chair eligible to vote only to make or break a tie

Attendance re-initialized on 2010-07-06:

  v[xxx--xxx] Laurence Bisht (Intel)
  v[xxxxxxx-] Eduard Cerny (Synopsys)
  v[x-xxxxxx] Ben Cohen
  v[-xxxxxxx] Surrendra Dudani (Synopsys)
  n[--x-xxxx] Dana Fisman (Synopsys)
  v[xxxxxxxx] John Havlicek (Freescale)
  v[xxxxxxxx] Tapan Kapoor (Cadence)
  t[xxxxxxxx] Dmitry Korchemny (Intel, Chair)
  v[xxxxxxxx] Scott Little (Freescale)
  v[-xxxxxxx] Manisha Kulshrestha (Mentor Graphics)
  v[xxxxxxxx] Anupam Prabhakar (Mentor Graphics)
  v[xxxx-xxx] Erik Seligman (Intel)
  v[xxxxxxx.] Samik Sengupta (Synopsys)
  v[xxxx-xxx] Tom Thatcher (Oracle, Co-Chair)
    |- attendance on 2010-08-24
  |--- voting eligibility on 2010-08-24

Minutes:
--------

- Reminder of IEEE patent policy.
See: http://standards.ieee.org/board/pat/pat-slideset.ppt

Everyone was reminded

- Minutes approval
Erik: Move to approve
Tom: Second
                Vote results 10y/0n/0a

- Email ballot results
    No e-mail ballots

- Issue resolution/discussion
1763: The LRM does not define whether assertion control tasks affect sequence methods and events
Erik: This is an old Mantis item. We should vote to resolve it as "no change required".
Ed: Put note in

Ed: Move to resolve 1763 as "no change required".
Erik: Second
                Vote results; 10y/0n/0a

2494: 37.44 Assertion diagram missing restrict
Tapan: Have uploaded a proposal. There were a couple places where restrict was missing: One in a diagram, and one in a list.

Ed: Why there are no deferred assertions in the diagram? Are they covered by immediate assertions?
Erik: Text states that deferred assertions are a subset of immediate.
Dmitry There is a deferred qualifier for immediate assertions, see p. 953.
Ed: OK.
Anupam: Restrict doesn't apply to immediate assertions? Change is to the concurrent assertion diagram only.
Dmitry: Restrict is a concurrent assertion construct.

Tom: Move to accept proposal for 2494
Erik: Second
                Vote Results: 10y/0n/0a

2205: $asseroff, $assertkill and $asserton description is ambiguous

Erik: Uploaded a new proposal: Changed "assertion" to "assertion statements"
Erik: Assertion statement refers to assert, assume, and cover
Ben: Right above this section, the text defines "assertion" as an
                "assertion statement"
Dmitry: Might need to mention that these don't affect restrict.
Erik: Restrict property statements are not evaluated
Erik: Is this proposal overkill, or is it necessary clarification?
Ben: Thinks it is overkill.
Erik: Other sections in Ch 20 that mention assertions.
Scott: Glossary defines assertion as an assertion statement
Dmitry: Don't see harm in using "assertion statements"
                Happy w/ proposal
Anupam: Is there anything that applies to only assert, and not to assume or
                cover
John: Sequence strength is inferred differently in cover.
Ed: Suggest using "assertions", then referring to clause 16 where assertions is defined. In fact title of Clause 16 is "assertions"
Erik: Will post a new proposal that keeps "assertions", but refers to Clause 16.
Dmitry will call to email vote.

1678: Clarify that rewriting algorithm doesn't replace name resolution
Scott: Looks like no change is necessary
Scott: Will add note to Mantis item clarifying why no change is required.
John: Move to close as no change required
Erik: Second
                Vote results: 10y/0n/0a

2571: confusing assertion clock inference rule
Scott: Has uploaded a proposal. Implemented suggested re-wording.
                Did not address last part of Mantis. Felt that it would be a lot of
                effort to clarify that precisely, and not a lot of people would be
                confused by it.
Erik: Didn't we already approve a proposal that touches this section?
Scott: Yes, but previous proposal doesn't touch the line that is modified
                in this proposal.
Erik: Previous proposal was 2804
                2084 didn't touch condition C
Erik: Change doesn't seem necessary to me.
John: Mantis items states that condition C could be interpreted incorrectly
                Hopefully, change should be more clear.
Dmitry: Will call for an e-mail vote

- Enhancement progress update
2751: P1800-2009: checker formal arguments may not be connected to interfaces // WHY?
Ben uploaded examples.
Ben: There are several issues that should be addressed.
Dmitry: Suggest to write down the issues to enable their review and discussion.
Ben: Will do.
Dmitry: Need to understand the meaning of modport direction in checker. Since we do not want to modify an existing interface to validate it using a checker, the modport direction should have an opposite meaning for checkers.
Ben: This will be confusing.
John: In any case the interface should support connection of other models or testbenches. Therefore there should always be possible to connect a checker to the interface in the conventional way.

2328: Review and relax restrictions on data types in assertions
Scott: It is ready for review.
Reviewers: Ed and Samik.

3035: More flexible definition of checker argument sampling
Dmitry: I implemented all Manisha's comments, it should be ready for email vote.
Ed: Agree.
Dmitry: Will call to email vote.

Enhancements in assertion system functions and tasks.
Erik: First need to address 2476, to decide whether the usage system function such as $onehot should be limited to assertions or be legal in the entire language.
Dmitry: There is nothing special for assertions here. I think it should be legal to use them everywhere.
Erik: Then these enhancements should be done by SV-BC.
Dmitry: It is a low priority for SV-BC, and using these functions outside the assertion context is nice to have. Enhancing these capabilities for assertion needs a show stopper issue. We should own these enhancements, and to send their resolution to SV-BC for review.
Erik: I will assume ownership of 2476.

Ownership of next enhancements in the pipe:
2093: Checker construct (1900) should permit output arguments - Laurence
3034: Allow continuous and blocking assignments in checkers - Anupam. Dmitry will assist.
3033: Allow procedural control statements is checkers. Ben will study.

Anupam: Need to open a Mantis item regarding the example 17.9. triggered method currently may be applied to named sequence only.
Dmitry: Will open.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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