Date: 2011-05-03

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

Live Meeting: https://webjoin.intel.com/?passcode=5426537

Agenda:


- Reminder of IEEE patent policy.

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

- Minutes approval

- LRM draft review

- Email ballot results

Mantis 3295 and 3385 passed with friendly amendments

Mantis 3069 and 3213 failed

- New issues

- Issue resolution/discussion

2556: Explicit package scope indication is not allowed for checkers

- Enhancement progress update

3476: Make drivers of inout ports accessible

3552: Sequence methods // .triggered need further clarification

3195: Local variables flow out issue in and/or/intersect/implies

3202: Support the system functios in classes and constraints.

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[--xxxx-xxx-xxx...........................] Ashok Bhatt (Cadence)

v[xxx-xxxxxxxxxx-xxx-xxxxxxxxx-x-xxxxx--xxx] Laurence Bisht (Intel)

v[xxx-xxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxxxxxx-] Eduard Cerny (Synopsys)

n[x--------xx---xxx--x-xxxxxxx-xxxxx-xxxxxx] Ben Cohen (Accellera)

n[----------------------xx-x-xxx-x--xxxxxxx] Surrendra Dudani (Synopsys)

n[x........................................] Shaun Feng (Freescale)

y[x-x-xxxx-x-x----x-x-x--xx---xxxx---x-xxxx] Dana Fisman (Synopsys)

n[--------------------xxxxx-xxxx-x-xxxxxxxx] John Havlicek (Freescale)

v[xx-xxxx-xxxxxxxxxxxxxxxx-xxx-xxxxxxxxxxxx] Tapan Kapoor (Cadence)

v[xx-xxxx-x-x..............................] Jacob Katz (Intel)

t[-xxxxxxxxxxxxxxxxxxxxxxx--xxxxxxxxxxxxxxx] Dmitry Korchemny (Intel

¿ Chair)

v[xxx-xxxx-xxxxxxxxxxxxxxx--xxxxxx-xxxxxxxx] Scott Little (Freescale)

v[xxxxx-xxxxxxxxxxxxxxxxx-xxxxxxxxx-xxxxxxx] Manisha Kulshrestha

(Mentor Graphics)

v[xxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx] Anupam Prabhakar (Mentor

Graphics)

v[xx-xxxx-xxx-xxx--x-xx-xxx-xx--xxxxxxx-xxx] Erik Seligman (Intel)

v[xxxxxxxx-x-xxx-xxxx-xxxx--xxxxxx-xxxxxxx.] Samik Sengupta (Synopsys)

v[xxxxx-xxxxxxxxxxxxxxxxx-xxxxxxxxxxxxx-xxx] Tom Thatcher (Oracle ¿

Co-Chair)

n[-----xx---xx-------x.....................] Srini Venkataramanan

(CVC Pvt Ltd)

|- attendance on 2011-05-17

|--- voting eligibility on 2011-05-17

Minutes:


- Reminder of IEEE patent policy.

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

Participants were reminded of the IEEE patent policy.

- Minutes approval

Erik: Move to approve minutes

Lawrence: Second

Vote results: 10y, 0n, 0a

- LRM Draft Review

- Email ballot results

Mantis 3295 and 3385 passed with friendly amendments

Mantis 3069 and 3213 failed

3295: Comments are mostly editorial. Manisha will implement changes.

3385: Erik implemented change for friendly amendment.

Anupam: Move to accept

Erik: Second

Vote results: 10y, 0n, 0a

Manisha: Should assertions contribute to sensitivity for always_comb?

1. Presence of assertion could change behavior. An always_comb

could be executed more times because of the assertion.

Erik: The LRM says:

" ...each variable or select expression that is read within the block"

Assertions read a variable, so variables appearinng only in

assertions should trigger the always_comb

Manisha: It would be good to clarify.

Anupam: Will file a Mantis item to clarify 9.2.2.2.1

Scott: Do we know what the clarification should be?

3069: Allow multiple global clocking

Anupam: Mentioning global clocking within generate or nested module

Jacob: Nested module should not interfere with enclosing module

Tom: True, but can global clocking in enclosing module affect the

nested module?

Erik: Nested module would inherit global clocking from enclosing module.

Jacob: Don't think so. It should only inherit global clocking from

parent module (where it is instantiated).

Anupam: Had tried to simplify proposal. Wrote up an alternate.

Jacob: Doesn't like that Anupam moved a sentence from secod paragraph to

first paragraph.

Anupam: Will send his proposal to the group. Jacob and Anupam will resolve

the difference.

3213: Defer discussion to next meeting: Dmitry is not present.

- Issue resolution/discussion

2556: Explicit package scope indication is not allowed for checkers

Laurence: Jacob and Manisha have reviewed the proposal.

Dmitry to call for an e-mail vote.

3202: Clarify on whether certain system functions are allowed in classes,

'let', and other corner cases

Erik: Dave Rich sent some information.

Will come up with a proposal.

Need a reviewer who is familiar with classes, constraints, etc.

Ben: Dave made a good point. Have done some VMM work.

Had to put things in an iterface in order to

Dave's point: classes are dynamic. May be an issue to allow these

functions to be called, since they assume static variables.

Erik, But you can declare a static member in a class.

Ben: Should be able to review proposal.

Anupam: Will also get someone familiar with classes to review it.

- Enhancement progress update

3478: Make drivers of inout ports accessible

Tom: We are not authorized to work on this item.

But give a justification or motivation for the proposal.

Ben: Can't write correct assertions on ports of a module.

From inside, don't know what the state is

Module could be tri-state, but you won't see value driven in from

outside. (if output port)

For inout port, don't know if this module actually tristated, since

you will see the value driven by an external module.

From outside can't tell which module is driving.

Idea would be to use a system function to get the module driver value.

Jacob: May be a problem with net merging in the simulator.

Scott: But still can trace driver.

Ben: Use case is checking that tri-state drivers are not driving when

they are not supposed to.

3552: Sequence methods // .triggered need further clarification

Ben: Proposal adds examples to show how using triggered() in procedural

code leads to unexpected results

3195: Local variables flow out issue in and/or/intersect/implies

Ben: This would change the ruls for flow out.

In certain cases, when an assertion needs to capture data to use

later, the local variable value won't flow out to where you can

use it.

Topic revision: r1 - 2011-05-20 - 17:37:03 - ErikSeligman
 
Copyright © 2008-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback