Written by: Dmitry Korchemny

Date: 2010-06-01

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

Dial-in information:

Meeting ID: 38198

Phone Number(s):

1-888-813-5316 Toll Free within North America

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[xxxxxx] Laurence Bisht (Intel)

v[xxxxxx] Eduard Cerny (Synopsys)

v[x-xxxx] Ben Cohen

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

v[-xxxxx] Dana Fisman (Synopsys)

v[-xxxxx] John Havlicek (Freescale)

v[xxxxxx] Tapan Kapoor (Cadence)

t[xxxxxx] Dmitry Korchemny (Intel – Chair)

v[xxxxx.] Scott Little (Freescale)

v[xxxxxx] Manisha Kulshrestha (Mentor Graphics)

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

v[xx-xxx] Erik Seligman (Intel)

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

|- attendance on 2010-06-01

|--- voting eligibility on 2010-06-01

Agenda:

- Reminder of IEEE patent policy.

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

- Minutes approval

Surrendra: Move to approve the minutes from 2010-05-25.

Second: Ben

The motion passed: 0n/0a/9y.

- Issue prioritization

- Issue resolution/discussion

2804: Need to clarify rule (b) in 16.15.6 to allow inferred clock when expression appears in procedural assertion

Surrendra: Need to address inference of clocking block events also.

Erik: Addressing clock usage in checkers, tasks and clocking blocks may impose a heavy burden on compilers/simulators, and be problematic for separate compilation.

Dmitry: The case of separate compilation is not symmetric: checkers cannot be compiled without knowing their instantiation context, but modules can be compiled without having access to the source file of a checker they instantiate.

Ed: The event in a clocking block is triggered in the Observed region. Usually should not be an issue, but a problem may arise when an assertion uses a sequences and they both use an event from a clocking block, one as a clocking event, and the other directly.

Erik: Will need to submit a Mantis item

Ed: Should be a problem to analyze a clocking block for inference in the general case.

Manisha: Eliminate rule about posedge/... clock for clocking block events.

Ed: Events from clocking blocks are rarely used in always procedures. We may infer them in any case.

Discussion summary:

- If a clock is passed to a task called in an always procedure does not prevent clock inference in concurrent assertions instantiated in this procedure.

- The clock in an always procedure inside a checker will be inferred according to the checker instantiation context, as shown in the following example:

checker check(a, event clk);

always @clk

a1: assert property(a);

endchecker

module m(logic clock, x, y, ...);

check c1(x, clock); // check compilation error: no clock inferred for a1

check c2(x, posedge clock); // OK

endmodule

- If an event generated in a clocking block controls an always procedure then it will be inferred in assertions instantiated in thie procedure.

2955: Checker example is wrong

No proposal is ready yet.

Ben: Should we discuss parameters in checkers in the context of this example?

Dmitry: This enhancement request is in our top priority issues and we will be able to discuss it when the PAR id approved.

3113: Add port_identifier to constant_primary BNF for sequences, properties and checkers

Laurence: LRM explicitly specifies that this usage is legal in 16.8, 16.13, and 17.2. However, this is not reflected in BNF. BNF should allow this explicitly.

Ed: But the BNF should treat sequences and properties in the context of their instantiation.

Dmitry: Need to check this.

Dmitry: Instead of fixing the BNF (and this will require massive changes in the BNF) we could just add a note to Annex A that the BNF should be treated appropriately (according to the rewriting algorithm).

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

Dmitry, Scott: Postpone this issue until John is back

1933: 16.13.6 reference to triggered method can be improved

Ed: In the LRM 2009 the reference is correct.

Move: Ed: resolve 2009 as "No change required"

Second: Manisha

Motion passed: 9y/0a/0n

2387: Layout of 16.11 is inconsistent

Move: Ed: accept the proposal

Second: Erik

Motion passed: 9y/0a/0n

2291: the description of $assertoff blurs assertions and attempts

Ben, Erik: The proposal is correct.

2330: Clarify that number_of_ticks argument to $past must be compile-time constant

Dmitry: Need to fix the reference.

2362: 16.14 mention of assertion control system tasks is unconnected

The clause numeration in the proposal is out of date. Need to find the exact place.

The following issues have not been covered:

2825: 16.16 Disable iff: checkers not included in list of default extensions

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

2927: Precedence between sequence/property operator and normal expression operator

2452: No vacuity information about synchronous aborts

2557: Rules for passing automatic variables to sequence subroutines are not clear

- Opens

Actions:

Erik - update proposal for 2804

Laurence - prepare proposal for 3113

Ben - Create a PDF proposal for 2291

Dmitry - Fix 2330

Scott - Fix 2362