Date: 2010-07-06

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

Duration: 1.5 hours

Agenda

- Reminder of IEEE patent policy.

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

- Minutes approval

- Email ballot results

- New issues:

3134: sequence and property range parameters are erroneously defined

3135: Verbal explanation of nexttime and always is misleading for

multiple clocks.

- Issue resolution/discussion

- Enhancement progress update

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

v[-] Eduard Cerny (Synopsys)

v[x] Ben Cohen

v[x] Surrendra Dudani (Synopsys)

v[x] Dana Fisman (Synopsys)

v[x] John Havlicek (Freescale)

v[x] Tapan Kapoor (Cadence)

t[x] Dmitry Korchemny (Intel ¿ Chair)

v[x] Scott Little (Freescale)

v[x] Manisha Kulshrestha (Mentor Graphics)

v[x] Anupam Prabhakar (Mentor Graphics)

v[x] Erik Seligman (Intel)

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

|- attendance on 2010-06-22

|--- voting eligibility on 2010-06-22

Minutes

1. Minutes from last meeting:

Eric: Move to approve minutes

Ben: Second

Voting results: 11y, 0n, 0a

2. Results of E-mail vote: both passed

3. Voting rights

Dmitry: Note that voting rights will be reset, as we are now a working

group.

4. New issues:

Dmitry: Dana entered two new Mantis items: 3134, and 3135

5. Issue Resolution Discussion

Manisha: Would like to discuss 1627

Expect is a blocking statement, therefore cannot appear within

functions.

Tom: Revised sentence still doesn't exclude blocking statements from

functions

Dmitry: Suggest "expect can appear anywhere where event controls appear."

Manisha: what about final block?

(Dana joined)

Ben: What about always_comb? May expect statents appear here?

Manisha: Will update sentence to "anywhere where event controls may

appear"

2255

MANISHA: UNderstanding is that expects are not assertion statements,

therefore

no counters are required for them.

Surrendra: Expects are not static. They may execute from dynamiclly

allocated classes. It might be difficult to define counters fro them.

Erik Do we need any clarification that expects are not assertions?

Dmitry Assertion definiton lists assert, assume, cover (pp. 309)

doesn't include expect.

Erik That might be good place for a clarification.

manisha We can put clarificaiton in two places: assertion definition, and

in the expect section.

John: It does say that execution of expect may be controlled by assertion

action control tasks.

Dmitry: What is the meaning of assertion tasks for expect?

Manisha: The tasks would unblock the process and allow following code to

execute.

Tapan How would you name an expect statement inside a class.

Manisha: But you still have a static name. within the class

(same as when you label any statement within class code)

But you can't control using object handles. You can only turn on

or off all expect statements at that line of code.

Ben: Does expect have a label? NO example in LRM with labeled expect

Dmitry & Manisha: Any statement can have a label.

Dmitry: Don't think people will use $assertpassoff for an expect statement.

3134

Dana: Definition of "constant" would include real numbers and negative

integers.

Dmitry: BNF may not need to be exact

Dana: If it is not difficult, we should fix the BNF

Surrendra: We could follow definitions for delays e.g. 9.4.1

Tapan: Statement in LRM explicity says that delay range must be 0 or

positive

integer. (p. 321

Everyhing is correct, right?

3135:

Dana: Formula for nexttime is confusing in the case of multiple clocks.

Surrendra Definition applies to single clock behavior

Dana: Should not be difficult to explain multi-clock behavior clearly.

Dmitry: Suggest assigning 3134 and 3135 to Dana.

Enhancements progress update

1. Real Types support in assertions:

John: Haven't really started

2. Output arguments

Ben: Some discussion: Need to prevent output arguments from

affectiong RTL simulation.

Tom: Perhaps a restriction is required that an output argument

cannot be connected using a bind.

Surrendra: Agree: When you instantiate a checker, you would

create signals within a block for the instance to connect to.

With bind, you are affecting the operation of a block from

a completely different piece of code.

John: Don't like restriction on bind

Could get the same problem today with assertion outputs.

Ben: Lots of concern about verification code affecting the behavior

of the design.

Next meeting next week. Will use the Synopsys Bridge.