Time: 16:00 UTC (9:00 PDT)

Duration: 2 hours

Dial-in information:

Toll number: +1 916-356-2663

Toll free number (US): 888-875-9370 (U.S. toll-free)

Bridge: 5 Passcode: 5047788

Agenda:

- Reminder of IEEE patent policy.

See: http://standards.ieee.org/board/pat/pat-slideset.ppt

- Minutes approval

- Effort estimation for top priority issues.

- Issue resolution and discussion.

3020: Recursive property Restriction 4 is not consistent between

Clause 16.13.17 and Annex F.7

2955: Checker example is wrong

2804: Need to clarify rule (b) in 16.15.6 to allow inferred clock

when expression appears in procedural assertion

2732: Clarify timing diagram in Figure 16-4?Future value change

1933: 16.13.6 reference to triggered method can be improved

2387: Layout of 16.11 is inconsistent

2291: the description of $assertoff blurs assertions and attempts

2330: Clarify that number_of_ticks argument to $past must be

compile-time constant

2362: 16.14 mention of assertion control system tasks is unconnected

- 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-04-13:

v[xxxxx] Laurence Bisht (Intel)

v[xxxxx] Eduard Cerny (Synopsys)

v[-xxxx] Ben Cohen

v[-xx-x] Surrendra Dudani (Synopsys)

v[xxxxx] Dana Fisman (Synopsys)

v[xxxxx] John Havlicek (Freescale)

v[xxxxx] Tapan Kapoor (Cadence)

t[xxxxx] Dmitry Korchemny (Intel - Chair)

v[xxxx.] Scott Little (Freescale)

v[xxxxx] Manisha Kulshrestha (Mentor Graphics)

v[xxx..] Anupam Prabhakar (Mentor Graphics)

v[x-xxx] Erik Seligman (Intel)

v[xxxxx] Tom Thatcher (Sun Microsystems ¿ Co-Chair)

|- attendance on 2010-05-25

|--- voting eligibility on 2010-05-25

Minutes:

- Reminder of IEEE patent policy.

See: http://standards.ieee.org/board/pat/pat-slideset.ppt

- Minutes approval

Eric: move to approve

Second: John

11 in favor, opposed 0, abstain 0,

- Effort estimation for top priority issues.

Need to provide effort estimation: How much can we accomplish before

Oct 2011

Dmitry, John and Ed have submitted effort estimation.

1. AMS assertions

Tom: What's the difference between 2328 and 3058?

John: 2328 should be simple. It allows for comparisons of real-valued

variables which create a boolean result

3058 is more complicated. It could involve changes for continuous time,

additional operators, etc.

John: If we work on 3058 too soon, it may take us too long

We should delay work on 3058 until the AMS committee has had time to

do work.

Ed: Estimate 2 weeks for 2328

John: That leaves 3 1/2 months for 3058

2. Checker usability

Tom: Estimate 6 months for this group

Many of these items may involve other committees.

Ed: We can probably these items in two groups:

easier: continuous and blocking assign

harder: output arguments and forcing

Dmitry: But continuous & blockcing assign: may introduce races.

Dmitry: 4 months may be enough to do a representative

Scott: Their estimates assumed that not all mantis items would be resolved

but a subset

Dmitry: leave estimate at 4 months, but note that not all items will be

completed?

john Ok

In other committees: Dave Rich saying "we are not committing to

completing everything"

3. Assertion system function

Ed. Unpacked structures may be tricky

John Once these have been introduced, how can these be referenced.

If things have to be limited, thinks will be complicated.

Dmitry 1.5 monthts?

John Yes.

Ed. Proposal for unpacked data types may not be necessary: We can already

do this with proper type casting.

Dmirty Several problems: bit streaming

Dmitry Also, the LRM doesn't specify whether unpacked types are allowed

or not

Ed: Normally you would cast to bit vector

Dmitry This is not intuitive.

Ed Actually it may be more intuitive if the casting is explicit.

4. Inference

Dmitry estimated 2 weeks

5. Sampling

Dmitry 1 month

May involve other committees.

Ed If we remove the checker input sampling it might be easier

Dmitry This will still involve other committees

John Changing sampling of checker arguments will raise backward

compatibility issues.

May want to create an $unsampled() function instead

Dmitry We may not be able to use disable iff within checkers.

(can't get unsampled value for disable iff)

Tom Schedule at least 2 months

Dmitry OK

6. Local varialbes

Dmitry 1.5 months

7. Scoping

Dmitry 6 months

Tom 3030 estimate of 2 weeks optimistic.

Dmitry Handle only the most basic case

John Aren't checkers allowed in task alreay?

Dmitry No

John May be somthing in the LRM that forbids it explicity.

However, In most cases if the task was inlined, then the checker

instantiation would be allowed.

Ed What about recursive code?

John We fixed concurrent assertions in procedural code, so this should

be ok.

When execution reaches point where assertion is, the attempt gets put

in the assertion queue

Ed What about reporting?

John Reporting problem not different from that of immediate assertions.

Dmitry I agree that 2 weeks is too short

John Putting checker instantiations in functions may be more complex than

tasks. Infrastructure is there to support it for tasks not sure for

functions.

John Six months reasonable over all. Maybe not all items will get done.

Dmitry Leave at 6 months for entire group

8. Type system

Dmitry 2.5 montsh

John Items will generate contention with other committees

Tom 4 months is agressive, but reasonable.

9. Covergroups

Dmitry Estimate was 3 months. We can make it four.

Tom Agree on four

10. Formal semantic

Dmitry 2 weeks

John Abstract grammars for unclocked, clocked things.

Mantis item suggests re-writing the annex

Some issues with non-overlapping. Some inconsistencies.

We put 1 month. Assumes we don't re-write.

We just put in missing derived forms and fir non-overlapping case.

Dmitry 1 months

11. Vacuity

Dmitry 1 month

John We didn't thik there would be that much text

2 weeks.

12. Temporal logic

Dmitry 1 month

(no discussion)

Summary:

Dmitry: total time in our schedule would be 30 months.

Tom 17 months till Oct 2011

Dmitry: We also have to fix errata, proof-read, etc.

John: If issues have separate drivers, then we could work on multiple items

at once.

Dmitry: We don't have to commit to doing everything

Eric: Will AMS assertions be done by DC? Or do we still have to do it.

John If we wait, we won't have to invent much.

We let the AMS group address as much as they can. We just have to

make adaptation for synax, etc.

Dmitry: We 17 months to address all issues assuming we can work on 2

issues

at once.

We would like to ask work group to permit us to work on issues listed

Eric Schedule is approximate.

John: Not sure whether we need to make statemtn to work group. We may just

need a sentence to say we may not complete everything.

John: Will compose a statement to the working group.

(While waiting for John to compose the statement)

Dmitry: Bi-weekly meeting not sufficient: weekly?

Tom Is it necessary yet? Are we authorized to work on these major items,

or are we just working on erratta.

Dmitry ony errata

Ed limit to 1 1/2 hours?

Dmitry: Should be reasonable.

Dmitry: Next meeting next week.

Dmitry: John has created a statement to the working group and mailed it out

to the reflector.

John: (Reads the statement)

Eric: Do we need to vote on this?

John: If we approve the statement, Dmitry can present this as the opinion

of the committee.

John Move to approve

Eric Second

11 in favor, 0 opposed, 0 abstain. Motion passed.

- Issue resolution and discussion.

2804: Need to clarify rule (b) in 16.15.6 to allow inferred clock

when expression appears in procedural assertion

Eric: Proposal was uploaded

Ed: What about $display

Eric: Maybe generalize "sampled value functions" to "any system funciton"

Ed Should be "any system task"

Dmitry: Why do we need all these execptions explicit

Eric: Yes it is messy,

Why not

Eric: Everyon e-mail him possible missing exceptions

Will re-visit this next week.

3020: Recursive property Restriction 4 is not consistent between

Clause 16.13.17 and Annex F.7

John: Simply changing F.7 to be consistent with 16.13.17

Adding 3rd condition

Manisha: Isn't first condition covering the last one?

John: No

First condition: e is a formal argument of p

third (new) condition: e is bound to a local variable

Ed: Third case is a pass by value, it's not a reference

John This was the missing capability needed for recursive properties.

Ed: Looks good

Ed Move to accept proposal

Tom Second

11 in favor, 0 opposed, 0 abstain Passed

2955: Checker example is wrong

Tapan: Changes were added as a note to the mantis item.

John: We will need a document that descibes these changes in a format that

the editor can used.

Tapan: Will add PDF of change

Dmitry: Other issues:

Generate item cannot be a formal argument. Could be a parameter, but

checkers don't have parameters.

May need new mantis item to say that generate item could be a formal

argument.

Manisha: There is a mantis for adding parameters for checkers. Would

that cover this case?

Dmitry Parameters to checkers not really needed

Ed What about backward compatibility? Existing checker libraries written

as modules currently have parameters.

Dmitry Will add mantis item for allowing generate items to be formal

arguments.

Discussion of Other issues without resolution yet

2732: Clarify timing diagram in Figure 16-4: Future value change

Ed Does the diagram show sampled values?

Tom No The diagram shows waveforms that the designer would see.

Ed No change necessary

Tom Agree: no change necessary

John Could explain more "The assertion fails because $changing_gclk(sig) is

1 at time 80, but $falling_gclk(clk) is 0."

Dmitry Who can write a proposal?

John Will write a proposal

Dmitry Next meeting in one week.

Will try to resolve several errata type mantis items

-- ErikSeligman - 2010-05-28