Minutes from SV-AC Committee Meeting
Date: 2010-06-22
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
- New issues:
3117: make it clear that rewriting algorithm (F.4.1) applies to checker
and let
3120: "expect" construct to refer to virtual interfaces
- Issue resolution/discussion
3113: Add port_identifier to constant_primary BNF for sequences,
properties and checkers
2732: Clarify timing diagram in Figure 16-4?Future value change
2362: 16.14 mention of assertion control system tasks is unconnected
2825: 16.16 Disable iff: checkers not included in list of default extensions
2754: P1800-2009 : Can clock change in conditional branch of 'if' operator
2927: Precedence between sequence/property operator and normal
expression operator
2452: No vacuity information about synchronous aborts
2557: Rules for passing automatic variables to sequence subroutines are
not clear
2556: Explicit package scope indication is not allowed for checkers
2476: Need clarification about system functions $onehot, etc
1763: The LRM does not define whether assertion control tasks affect
sequence methods and events
2485: terminology related to immediate and deferred assertions
1756: The LRM does not indicate how the control tasks $asserton/off/kill
affect verification statements in initial blocks
2809: Checker instantiation in checkers' always procedure
2938: Surprising (to some users) interaction between deferred assertions
& short-circuiting
2353: 'classes' missing from description
2871: Clause 16 does not forbid assertion local variables within
clocking event expressions
2248: Champions feedback - items related to Mantis item 1683
1678: Clarify that rewriting algorithm doesn't replace name resolution
2934: Precedence and associtiativity of case operator is not shown in
the table
3008: In $past BNF, "expression" should be "expression1"
2479: Annex F.5.2.1 conflicts with changes from 2434
2494: 37.44 Assertion diagram missing restrict
2095: Clarify meaning of distribution as condition for "disable iff"
1627: 17.16: clarify that expect statement not allowed in functions
2904: Clarify when disable iff condition must occur relative to starting
and ending of an attempt
1853: BNF for calls to $rose and other sample value system functions
3015: Examples of $fatal have bad arguments
2839: Contradictory statement of increment/decrement operators usage.
2551: trivial example error
2558: Restriction inside checker construct
2340: clarifications needed on vpi_control for non-temporal and
immediate assertions
2271: sequence events require a clocked sequence
2255: clarifications on expect
2491: Conflicting rules in 16.17 (D7)
2552: Confusing comments regarding nexttime operator
2571: confusing assertion clock inference rule
2722: Errors in Figures 16-14, 16-15, and 16-16
2546: 'empty match' and 'vacuous success' are not clearly defined in LRM
2386: Rename 16.9 to "Local variables"?
- 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-04-13:
v[xxxxxxxx] Laurence Bisht (Intel)
v[xxxxxxxx] Eduard Cerny (Synopsys)
v[xxx-xxxx] Ben Cohen
v[-xx-xx-x] Surrendra Dudani (Synopsys)
v[-x-xxxxx] Dana Fisman (Synopsys)
v[x--xxxxx] John Havlicek (Freescale)
v[xxxxxxxx] Tapan Kapoor (Cadence)
t[xxxxxxxx] Dmitry Korchemny (Intel ¿ Chair)
v[-xxxxxx.] Scott Little (Freescale)
v[xxxxxxxx] Manisha Kulshrestha (Mentor Graphics)
v[xxxxxx..] Anupam Prabhakar (Mentor Graphics)
n[--xx-xxx] Erik Seligman (Intel)
v[xx-xxxxx] Tom Thatcher (Sun Microsystems ¿ Co-Chair)
|- attendance on 2010-06-22
|--- voting eligibility on 2010-06-22
Minutes:
--------
1. Minutes from last meeting:
Move to approve minutes: John
Second: Ben
Vote results: 8y, 0n, 0a
2. E-mail ballot results:
2291, 2330, 2955 Passed
3113 Failed
3113:
Manisha: It's not clear that re-writing algorithm applies to let.
If language is clarified, this should be clear.
John: Are there technical issues w/ applying rewriting algorithm to
checkers or let?
Manisha: Difference between sequence and property arguments:
Sequences cannot take a property argument
Checker arguments should be similar to property arguments.
Let arguments should be a subset of sequence arguments.
John We should look at and think about it.
Dmitry: Can we separate 3113 from new issue 3117?
John: Move to approve 3113
Second: Manisha
Vote results; 8y, 0n, 0a
New Issues:
Dmitry: Note that PAR is approved.
John: Any feedback from Working Group?
Had heard that Karen Piepers had expressed concern about how AC
had operated during the last PAR
Dmitry: We did slip schedule of last PAR because of significant
enhancements
That turned out to be complicated and all interdependent.
In current PAR, we can tread most issues separately.
We need to work more closely with other committees.
John: We did have trouble last time getting other committees to think about
our enhancements.
We need to do better in this respect this time around.
3099: Action block triggering is not well defined.
3117: Make it clear that rewriting algorithm (F.4.1) applies to checker
and let
(Created in response to issues from 3113)
Manisha: Will write a proposal for 3117
John: We need to think about it carefully, as we are applying re-writing
algorithm to two new structures: checkers & let
Manisha: John, can you review the proposal?
John: If you come up with a proposal, I will review it.
Dmitry 3120 "expect" construct to refer to virtual interfaces
Ben: In OVM/UVM/VMM you use classes. These classes use virtual interfaces
to tie the test bench code to the RTL. An question was asked in
the Verification Guild about whether an expect could be written which
refers to signals in one of these virtual interfaces
One vendor implements this: allows expect w/ virtual interfaces.
Other vendors don't allow this
Ed: Immediate asserts can be used on virtual interfaces
Ben: Expect is different from immediate assert, because expect will wait
for a pattern to match
Ed: Problem in the example is also that the variable was an automatic.
John: Some concerns: Entered a previous mantis item regarding expect
Thinks that there are some things broken with expect.
Ben: If interface not virtual, there would be not problem.
Why should it be an issue if it is virtual?
OVM and UVM will all use virtual interfaces in classes
The only thing that will work with classes is immediate
Could we allow this use case, but just restrict expect to access
only virtual interfaces?
John: Can't remember what his problems were with expect.
Will review
Manisha: Expect is already supposed to handle automatic variables
But handle for virtual interface may be null. This is not currently
defined. In Verif Guild example was the expect on a clock interface
or signal?
Ben Can a virtual interface be NULL?
Will show how the expect was used in the example.
Issue resolution:
2732: Clarify timing diagrams in Fig 16-4
John: The current proposal just clarifies what we had intended for
reporting the assertion failure time for assertions with future
time functions.
Ed: Don't like the requirement that tool must report earlier time
Requires storage to remember the time that the assertion failed.
It's doable.
John: What is your proposal?
Ed: Simpler: Report the current time when the message is being printed.
We had to wait for the next cycle to see if the assertion actually
failed, we should just report this time.
John: This requires user to think about when the assertion actually failed.
Dmitry: What about DPI behavior If you implement callbacks how can you get
the correct time for the assertion failure? Not implementable in DPI.
John: You just have to wait to see if the assertion failed.
Ed: The time reported by DPI is the time when the DPI function is called.
It is different from the time of failurefailure
John: Yes, but you'll have to figure that out somehow.
Ed: If the callback asks for current time, it will get current time, not
the time that the assetion actually failedfailed
John: We can't force omnicience.
Dmitry: I will call for e-mail vote:
2362 16.14 Mention of assertion control system tasks is unconnected
Ben: I agree with proposal
Tom: Move to accept proposal
John: Second
Vote results: 8y, 0n, 0a
2825:
Ben Will write a proposal
2756:
John: Nothing wrong with LRM. However, the original LRM was stricter.
2009 liberalized clock inheritance, but examples not changed.
All examples demonstrate code complying with stricter 2005 examples.
Ben: If there was an example with looser clock restrictions, it would be OK.
Tom: Will write a proposal
Ed: On p. 416, you can see that the rules are explained.
2927:
Ed: Table 16.3 seems to have both precedence and associativity:
Anupam: Question is about precedence when regular expression operators
combined with property/sequence operators
Ben Don't see the point
Logical expression have precedence over sequence operators.
Tapan: Precedence s only only needed when there are two ways of parsing an
expression. BNF rules dictate the rules for processing expressions
with both logical operators and sequence/property operators.
Dmitry: Would it make things more clear to specify
Dmitry: Who want's to own it?
Solution could be to just write a note on Mantis item explaining
why no change is needed to LRM.
Ben: Will take this one.
2452: No vacuity information about synchronous aborts
Dmitry: Assign to Dana for now. She can reassign it later
Dmitry: Other Mantis items:
Dmitry: Should I just assign people to mantis items so that we don't spend
meeting time?
I can allow two days for people to volunteer. After that, will assign
people to mantis items.
Tom: Will write a proposal for 2722.
Ed: Next meeting: Synopsys will be shut down. Won't be able to start
phone conference.
Dmitry: Will use the Intel phone conference, unless other people volunteer
to arrange a phone conference.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jun 22 16:41:20 2010
This archive was generated by hypermail 2.1.8 : Tue Jun 22 2010 - 16:41:24 PDT