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
-
-
-
-
- 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.
--
ErikSeligman - 2010-08-30