Re: [sv-ac] Minutes from SV-AC Meetin 9/21/2010

One more thing: On Checker outputs, we agreed that type wire is not allowed
in checkers, both in ports and in the checker_or_generate_item_declaration.
Ben

On Tue, Sep 21, 2010 at 10:49 AM, Thomas J Thatcher <
thomas.thatcher@oracle.com> wrote:

> 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.