[sv-ac] Minutes from SV-AC meeting: 7/20/2010

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

- Email ballot results
2557: Rules for passing automatic variables to sequence subroutines are
not clear
2722: Errors in Figures 16-14, 16-15, and 16-16
2839: Contradictory statement of increment/decrement operators usage

- New issues
3145: Need to clearly define "maximal property"
3147: Rule c) in 16.17 conflicts with the relaxed rules on clocking of
assertions with inferred leading clocking event.
3156: Conflict in description of clocking event of clocking block
behavior (SV-EC)
3157: Identifier usage before declaration in assertions

- Issue resolution/discussion
2732: Clarify timing diagram in Figure 16-4. Future value change
2398: Surprising (to some users) interaction between deferred assertions
& short-circuiting
2491: Conflicting rules in 16.17 (D7)
1756: The LRM does not indicate how the control tasks $asserton/off/kill
affect verification statements in initial blocks
1763: The LRM does not define whether assertion control tasks affect
sequence methods and events
1853: BNF for calls to $rose and other sample value system functions.
2485: terminology related to immediate and deferred assertions.
2558: Restriction inside checker construct
2452: No vacuity information about synchronous aborts
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
2871: Clause 16 does not forbid assertion local variables within
clocking event expressions
2353: 'classes' missing from description
1678: Clarify that rewriting algorithm doesn't replace name resolution
2571: confusing assertion clock inference rule
2386: Rename 16.9 to "Local variables"?

- Enhancement progress update
2412: Allow clock inference in sequences
2093: Checker construct (Mantis 1900) should permit output arguments

- 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[xxx] Laurence Bisht (Intel)
  v[xx-] Eduard Cerny (Synopsys)
  v[xxx] Ben Cohen
  v[xxx] Surrendra Dudani (Synopsys)
  v[xxx] Dana Fisman (Synopsys)
  v[xxx] John Havlicek (Freescale)
  v[xxx] Tapan Kapoor (Cadence)
  t[xxx] Dmitry Korchemny (Intel ¿ Chair)
  v[xxx] Scott Little (Freescale)
  v[xxx] Manisha Kulshrestha (Mentor Graphics)
  v[xxx] Anupam Prabhakar (Mentor Graphics)
  v[xxx] Erik Seligman (Intel)
  v[xx.] Samik Sengupta (Synopsys)
  v[xxx] Tom Thatcher (Sun Microsystems ¿ Co-Chair)
    |- attendance on 2010-07-20
  |--- voting eligibility on 2010-07-20

Minutes
---------

1. IEEE Patent policy: Attendees were reminded.

2. Minutes from last meeting:
     Eric: Move to approve minutes
     Tom: Second: Tom
     voting results: 10y, 0n, 0a

(Lawrence Joined)

3. E-mail ballot results:

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

Eric: Have uploaded a new proposal taking Manisha's comments into account:

(Dana Joined)
(Manisha Joined)

Manisha: I'm fine with the new proposal.
Eric: Move to vote on 2557
Manisha: Second:
Voting results: 13y, 0n, 0a

2722: Errors in Figures 16-14, 16-15, and 16-16
Failed:
Anupam: 3 comments
        Thought we should keep property the same
        Consistency with prior figures in displaying boolean expr match
Tom: Tried different things: Solid black line did not stand out
        because of super-imposed dotted black line.
        Solid green line with no arrow did not stand out against purple
        cycle boundary lines.
Anupam: Still prefers solid line for consistency.
John: Happy with green arrow.
Tom: Will try a thicker green line to make it stand out. Will upload

2839: Contradictory statement of increment/decrement operators usage
Failed:
John: Voted no because he was confused by proposal

John: Do += and ++ have lvalues?
Ed: Yes

John: It's the lvalue argument that must be a local varialbe
        +=, the right hand argument does not have to be a local variable
        ++ -- left hand argument must be local variable
        How do we express this?

Dana: Should we specify property and sequence
Ed: Sentence uses sequence match item, which is precisely defined
John: Only concern is whether sentence suggests that right-hand operator
        also must be local variable
Ed: Will upload new propolsal

Back to 2722

Tom: Uploaded new proposal

Tom: Move to approve 2722
Anupam: Second
Voting results: 13y, 0n, 0a,

Back to 2839
Ben: Is term lvalue defined?
Ed: Have seen it in the LRM before
Manisha: in BNF, it is called a variable lvalue. Should we call it that?
John: Probably an artifact of BNF. There are variable lvalue and net lvalue
        only need to specify if you need to distinguish net from variable
        lvalues.
Tapan: Does this code apply to action blocks
Ed: No. Action blocks are regular procedural code
Tapan: Can local variables appear within action blocks?
Ed: No
John Move to approve 2839
Anupam: Second
Voting results; 13y, 0n, 0a

4. New Mantis items

3145: Need to clearly define "maximal property"
3147: Rule c in 16.17 conflicts with the relaxed rules on clocking of
assertions
John: Haven't written proposal, solution is to strike last sentec in
rule c.

3156:
Scott: Submitted to sv-ec: Sec 14.10 Example says that @dram (dram is a
        clocking block) or @posedge clock are equivalent. However elsewhere,
        the LRM says they are not equivalent.

5. Open Mantis items

2732: Time reported when future value functions fail
Ed: We don't do any time shifting. Execution of future value function
        cannot complete until next clock cycle. Should therefore report
        the time at which it really fails. Would have to save the time at
        which the future value function
        In DPI, you won't get the proper time either
        Adds overhead, could be confusing
Dmitry:
Ed: a until b When does it fail?
Dmitry Should fail when we know it fails.
John; Text wasn't
Dmitry: Example: a ##1 $past(b): Could theoretically be evaluated on
first
        clock cycle and failure reported a cycle earlier.
Tom: But there's no reason to do that. We are delaying reporting of
        failure of future value functions only because it is necessary.

Dmitry: Move on to enhancements discussion in agenda

6. Enhancements

Clock inference in sequences: 2412

anupam: Have uploaded a proposal
        Sequence with a method must have clock defined
        Proposal will be similar to rules for sampled value function
Ed: Why only on triggered, not matched
Anupam Proposal should apply to matched as well
Lawrence Matched: requires two clocks

Ed: These are autonomous sequences: Clock would be inferred from
        the maximal sequence.
        Coule be inferring different clock for each call of $triggered
John: Same declared signals could be instantiated in different places
        with different clocks.

John: If you take off the triggered, you have a different rule
        With no triggered, clock will flow to "seq"
        (example 1 in motivation)
Manisha: What about procedural code: if (seq.triggered)
        Will it get the inferred clock?

Ed: On seq.matched: Convoluted: Would match on inferred clock, finish
        evaluating on sequence clock, then be referred back to clock of
        environment.
Ed: Is ther a logical way to infer clock for matched? If not,
             should we limit to triggered
Dmitry If seq used outside an assertion, we should apply default clocking
        Inside assertion, don't thing default inference
        It would be confusing
Anupam: We are just giving more capability.
John In 16.14.3 something will need to change
        "Scope of clocking event flows into embedded named sequence, provided
        neither triggered or ended is called"
Lawrence: Will create backward incompatibility
Anupam: This was an error before, so shouldn't cause problems
John: Agree

Dmitry: Would like to assign reviewer
Manisha: Will review
Dana: Will Reivew
Anupam: Will upload new proposal, and notify reviewers.

Checker output arguments:

Dmitry: Try to narrow proposal to make it simpler
        Things like rand can be deferred
        Still have problems with assignments.

Meeting adjourned.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.