Date: 2010-08-17

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

2398 passed.

2412 failed.

- New issues

- Issue resolution/discussion

2754: P1800-2009 : Can clock change in conditional branch of 'if' operator

2095: Clarify meaning of distribution as condition for "disable iff"

3117: make it clear that rewriting algorithm (F.4.1) applies to checker

and let

1763: The LRM does not define whether assertion control tasks affect

sequence methods and events

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:

n[xx--xxx] Laurence Bisht (Intel)

v[xxxxxx-] Eduard Cerny (Synopsys)

v[-xxxxxx] Ben Cohen

v[xxxxxxx] Surrendra Dudani (Synopsys)

v[-x-xxxx] Dana Fisman (Synopsys)

v[xxxxxxx] John Havlicek (Freescale)

v[xxxxxxx] Tapan Kapoor (Cadence)

t[xxxxxxx] Dmitry Korchemny (Intel ¿ Chair)

v[xxxxxxx] Scott Little (Freescale)

v[xxxxxxx] Manisha Kulshrestha (Mentor Graphics)

v[xxxxxxx] Anupam Prabhakar (Mentor Graphics)

v[xxx-xxx] Erik Seligman (Intel)

v[xxxxxx.] Samik Sengupta (Synopsys)

v[xxx-xxx] Tom Thatcher (Oracle ¿ Co-Chair)

|- attendance on 2010-08-17

|--- voting eligibility on 2010-08-17

Minutes:

- Reminder of IEEE patent policy.

Participants were reminded about the IEEE patent policy

-Minutes

Erik: Move to approve minutes

Samik: Second

Voting results: 10y, 0n, 0a

- Email ballot results

2398 Passed.

2412 Failed

Ed: The Mantis is not necessary. Clock inferences could be made from

$inferred_clk on sequence arg. This means that current proposal not

necessary. Simpler than all the rules.

(Manisha Joined)

Anupam: The proposal was design to give users a choice of how to write the

property

John: These rules already apply to properties. This proposal extends these

rules for sequences. It make things more consistent

Dmitry: What about within a checker?

How to infer clock for sequence when sequence is unclocked.

Problem when passing unclocked sequence as an actual arg to checker?

How can you infer clock from checker? How is that covered by

current clock inference?

Ed: Can you pass instance of sequence to checker? Don't think so.

Don't think you can put .triggered on sequence argument to checker.

Ed: Clock flow will override the sequence clock.

john: Would you leave cases where $inferred_clk not defined as unclocked?

john: Circular reasoning?

Current text reads:

"There is no inference for a sequence to which a method is applied"

If there is no inference, would $inferred_clk be defined?

Ed: The rules for $inferred clock should apply, regardless of whether

this is a formal argument of a property, sequence, etc.

John: Wouldn't $inferred_clock call generate an error in this case?

Ed: Would require one change to LRM to clarify $inferred_clk

Anupam: This proposal gives users a choice as to how to write

Manisha: Agree that proposal should treat formal arguments with

$inferred_clk

when no actual argument is provided.

Ed: Question is how clocks are resolved when the clock from clock flow is

diffferent from

Manisha: With new proposal, a sequence instance Will behave the same,

whether or not you use $inferred_clk

Ed: Also need to cover/clarify use of $inferred_clk ouside of assertions.

Anupam: Will update proposal and re-submit.

- Issue resolution/discussion

2754: Can clock change in conditional branch of 'if' operator

Tom: This Mantis was entered by Ben. He thought it was illegal for

the clock to change inside a property if operator.

A note was added by John. It is legal for the clock to change.

In fact, an example in the LRM shows the clock changing inside

the if and the else conditions of the operator.

Ben later added a note saying his question was answered, and he

thought no further action was needed

Tom: Move to resolve 2754 as "no change needed"

Erik: second

Voting Results: 11y, 0n, 0a

2095: Clarify meaning of distribution as condition for "disable iff"

Tom: We discussed this last week. Tom added a note to this Mantis

item, discussing the used of distributions inside a disable iff.

Don't think disable iff is a special case.

Scott: Has new mantis item been filed for change to distribution expression

semantics?

Tom: Not yet. Will file a Mantis item.

Tom: Move to resolve 2095 as "no change required"

John: Second

Reulsts: 11y, 0n, 0a

- Enhancements

2328:

Scott: Has sent out a proposal. Will send out to entire SV-AC in a week or

two.

3035:

Dmitry: Has sent out a proposal for checker argument sampling

Manisha: Paragraph should be changed because there is no longer any

sampling

on actual arguments.

Dmitry: Will update proposal, Manisha, and Ed will review it.

- Back to Issue Resolution

3117:

Manisha: Want to defer it, since it depends on the checker argument

sampling,

Which may change.

1763:

Erik: no progress

1853:

Surrendra: Has not worked on this one.

2412:

Anupam: Has added the sentence that ed suggested

John: Paragraph looks fine to me

Erik: Don't like the usage "used with" in the sentence

John: Could used "specified for" instead

Erik: Friendly amendment: use "specified for"

Anupam: Move to accept proposal for 2412 with friendly amendment

Ed: Second

Vote results: 11y, 0n, 0a

Meeting adjourned.