SV-ACMinutes2010_07_20 < P1800

P1800 Web>SystemVerilogAssertionCommittee>SVACMeetingMinutes>SV-ACMinutes2010_07_20 (2010-08-10, ErikSeligman) (raw view)EditAttach
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.
Topic revision: r1 - 2010-08-10 - 16:43:42 - ErikSeligman
P1800