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

          1. 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

Topic revision: r1 - 2010-08-30 - 19:30:21 - ErikSeligman
 
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback