RE: [sv-ac] Minutes from SV-AC Meeting 9/21/2010

Hi Erik,

No, we haven't. We can do it on Tuesday.

Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Thursday, September 30, 2010 5:12 PM
To: sv-ac@eda.org
Subject: RE: [sv-ac] Minutes from SV-AC Meeting 9/21/2010

Hi guys-- I just got back from vacation, & am catching up on email.
After 2476 passed, did we formally send it to sv-bc for review? I think we need to do that, since it touches on non-assertion parts of the language.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Thomas J Thatcher
Sent: Tuesday, September 21, 2010 10:49 AM
To: sv-ac@eda.org
Subject: [sv-ac] Minutes from SV-AC Meetin 9/21/2010

Minutes from SV-AC Committee Meeting
Date: 2010-09-21
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

- F2F meeting (discussion)

- Email ballot results
2476: Need clarification about system functions $onehot, etc
Passed: 13y/0n/0a

- New issues

- Enhancement progress update
Checker usability enhancements

- Issue resolution/discussion
3008: In $past BNF, "expression" should be "expression1"
1853: BNF for calls to $rose and other sample value system functions.
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"?
3117: make it clear that rewriting algorithm (F.4.1) applies to checker
and let

- 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-xxxxx--xxx] Laurence Bisht (Intel)
   v[xxxxxxxxxxx-] Eduard Cerny (Synopsys)
   v[xxxxx-xxxxxx] Ben Cohen
   v[x-x--xxxxxxx] Surrendra Dudani (Synopsys)
   v[xxx---x-xxxx] Dana Fisman (Synopsys)
   v[x-x-xxxxxxxx] John Havlicek (Freescale)
   v[xxxxxxxxxxxx] Tapan Kapoor (Cadence)
   t[xxxxxxxxxxxx] Dmitry Korchemny (Intel ¿ Chair)
   v[xxx-xxxxxxxx] Scott Little (Freescale)
   v[xxxx-xxxxxxx] Manisha Kulshrestha (Mentor Graphics)
   v[xxxxxxxxxxxx] Anupam Prabhakar (Mentor Graphics)
   v[-xxxxxxx-xxx] Erik Seligman (Intel)
   v[xxx-xxxxxxx.] Samik Sengupta (Synopsys)
   v[xxxxxxxx-xxx] Tom Thatcher (Oracle ¿ Co-Chair)
     |- attendance on 2010-09-21
   |--- voting eligibility on 2010-09-21

Minutes:
--------

- Reminder of IEEE patent policy.
See: http://standards.ieee.org/board/pat/pat-slideset.ppt
Participants were reminded of the policy.

- Minutes approval
Scott: Move to approve minutes
Tapan: Second
        Vote results: 12y, 0n, 0a

- F2F meeting (discussion)
     Silicon Valley: Tom, Anupam, Erik, Dmitry
     Ed, Surrendra: Suggested Boston

Dmitry: Would it help to move to coincide with DV-CON? (Feb 28--Mar 3)
Ed: May help, but can't know in advance. Would also have more things
        to discuss at this time.
Tom: Agree that we would have more to discuss in DV-con time frame.
Dmitry: Also, Nov date would coincide with IC_CAD as well.
Dmitry: Will conduct one more poll on the time-frame, Decide next time.

- Email ballot results
2476: Need clarification about system functions $onehot, etc
Passed: 13y/0n/0a
Dmitry: Has implemented two friendly amendments.
Dmitry: This proposal takes care of 3008 as well.

- Issue resolution/discussion
3008
Scott: Move to close 3008 as resolved by 2476.
Tom: Second
Vote Results: 12y, 0n, 0a

- Enhancements progress update
Checker usability

Dmitry: Discuss definition of sampling.
Dmitry: Current proposal: "Sampled" defined differently for different data:
        Example: checker rand variables, $sampled returns value assigned
                at beginning of Observed
                Automatic variables: $sampled(x) = x
Manisha: Definition seems fine: just confused about automatic variables.
        They have short life span. They may not exist at end of simualtion
        tick
Dmitry: Then it may be illegal to call $past on an automatic.
        May also be hard to define $past for local variables.

Dmitry: Continuous assignments and always_comb/blocking assignments.
Tom: Make things consistent. Continuous assignments in checkers always
        update in the Reactive region. Even if a checker input changes in the
        active region, the assignment would be scheduled for the Reactive
        region.
John: Will have to think about examples of interacting agents.
Manisha: Are you sure that design continuous assignments always update in
        the Active region?
Dmitry: Pg 31 of standard: 4.9.1
        We can ask other committees to be sure.
John: Will try to think of examples.
Dmitry: Who would like to work on proposal?
Anupam: 3034, currently assigned to me.
Manisha: Can volunteer to help.

Checker outputs
Lawrence: BNF of checker outputs. Need to specify input/output of each
port.
        To maintain backward compatibility, if direction not specified, first
        port would be considered an input.
Dmitry: But it would be inconsistent with everything else?
Ben: Can't it be like a module?
Lawrence: In modules, you need to specify direction.
Ben: But some people like to put outputs first in the port list.
Dmitry: You can do it, you just need to specify "output" for the direction
        of the first port.

Lawrence: Do we want to allow untyped outputs for checker?
Dmitry: Why not?

Scott: For modules: the LRM says if the direction is unspecified, the port
        type defaults to inout. this proposal is inconsistent with this.
Dmitry: We are not intending to introduce inout ports for checkers right
now.
Manisha: Would prefer to default to input. inout ports cause more overhead.
Anupam: So we plan to make input the default direction, and we are not
        proposing inout ports.
Ben: Dmitry was talking about using a checker as a model. For this
        application, It may need tri-state ports, inout ports, etc.

- Issue resolution/discussion

2904
Anupam: Simulation should not need to retract something that has already
        been evaluated. Proposed to change the line Dana had modified.
Anupam: In a single-clocked case, should be consistent. In multi-clocked
        case there would be a race, but don't want to deal with that.
        Proposed change is in e-mail
Dmitry: Should you mention Observed region?
Anupam: Sentence mentions assertion evaluation. This occurs in Observed
        region. Shouldn't be necessary to explicity mention Observed
        region.
John: You are not specifying an ordering between disable iff condition and
        the assertion evaluation?
Anupam: Correct. No ordering is implied.

Meeting adjourned.

- Enhancement progress update
Checker usability enhancements

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.