SvScMeetingMinutes20080520 < P1800

P1800 Web>SystemVerilogSpecialCommittee>SvScMeetingMinutes>SvScMeetingMinutes20080520 (2008-05-23, ErikSeligman) (raw view)EditAttach
<verbatim>
Minutes of the sv-sc sub-committee meeting, May 20, 2008

=================Attendance=============================

    20220 Day
    06817
    00000 Month
    55444
    00000 Year
    88888

--[----a]   Arturo Salz          - Synopsys
vv[a-aa-]   Abigail Morehouse    - Mentor
--[----a]   Bassam Tabbara       - Synopsys
--[----a]   Brad Pierce          - Synopsys
vv[a-aaa]   Cliff Cummings       - Sunburst Design
vv[aaaaa]   Dave Rich            - Mentor Graphics
vv[aa-aa]   Dmitry Korchemny     - Intel
vv[a-aa-]   Don Mills            -
vv[aaaaa]   Eduard Cerny         - Synopsys
tt[aaaaa]   Erik Seligman        - Intel (chair)
vv[aaaaa]   Francoise Martinolle - Cadence
vv[aaaaa]   Gordon Vreugdenhil   - Mentor Graphics
vv[aaaa-]   Jin Yang             - Intel
vv[aaaaa]   John Havlicek        - Freescale
--[----a]   Jonathan Bromley     - Doulas
--[--a-a]   Karen Pieper         - Accellera
vv[aaaaa]   Lisa Piper           - Cadence
vv[aaaaa]   Manisha Kulshrestha  - Mentor Graphics
vv[aaaaa]   Mark Hartoog         - Synopsys
vv[aaaaa]   Mehdi Mohtashemi     - Synopsys
vv[aaaaa]   Mirek Forczek        - Aldec
vv[aaaaa]   Neil Korpusik        - Sun Microsystems
--[---a-]   Ray Ryan             - Mentor
--[---aa]   Shalom Bresticker    - Intel
vv[aaaaa]   Steven Sharp         - Cadence
-v[--aaa]   Stu Sutherland       - Sutherland HDL
--[---aa]   Surrendra Dudani     - Synopsys
vv[aaaaa]   Tom Thatcher         - Sun Microsystems (co-chair)
v-[aa...]   Michael Burns        - Freescale
||
||---- Voting eligibility for current meeting
|------Voting eligibility for next meeting


The next meeting of the sv-sc will be held on Tuesday, May 20, 2008, 9am-11am (PDT).

     * Toll Free Dial In Number: (866)839-8145
     * Int'l Access/Caller Paid Dial In Number: (215)446-3660
     * ACCESS CODE: 9301228
====================Agenda==============================
Agenda:

    1. Review the patent policy
    2. Approve the minutes from last week's F2F meeting, available at http://www.eda.org/twiki/bin/view.cgi/P1800/SvScMeetingMinutes200805F2F
    3. Action Item Review
           * Reminder: Review current proposals as partitioned at F2F
           * Current work on proposal revision: who is working on these? 
Need additional help?
    4. Technical topics
           * Checker variables revisited
                 o Reconsider F2F decision to drop continuous assigns, based on Dmitry's recent concerns
                 o Move assignments within checkers into Observed region?
           * Self-defined types: still OK, in light of examples emailed by Dmitry?
           * Checkers in procedural code: will always blocks in checkers be fully free-running? Do we still need $inferred_enable in some cases? 
(Erik to send some motivating examples)


====================Notes==============================

1.  Patent Policy:
     Move:  Gord  Consider the patent policy read
     Second:
     Approved unanimously
     Ref:  http://standards.ieee.org/board/pat/pat-slideset.ppt


2.  Approve minutes.
     Move:  Dmitry:  Approve the minutes from the last meeting.
     second:  Gordon
     Approved unanimously

3.  Action Item Review
     Reminder of action items from face-to-face meeting.
     Most people still in the process of reviewing Mantis items.

     Checker proposal:  Need people to start revising the checker proposal.
	Dmitry will take core checker proposal
	Other pieces:  Instantiation semantics, random var, all the rest.
	Mike Burns:  random var semantics.
	Gord:  believes random stability issues are his.
		Gord and Mike will work together on this.
	Part 1:  No volunteer:  Wait for a week on this one.


4.  Technical Topics

       * Checker variables revisited
     Dmitry	- Problems:  Don't see how continuous variable assignments
		  in active region can work.
     		- He wants to be able to assign ended and triggered to
		  variables, and have these values trigger other assertions.
		- Worried about dumping of let.
		- His original proposal should work for Verilog.  Instead of
		  his original ordering semantics, consider assignments like
		  any other event.
     Steve	- This would introduce another small loop in observed region
     Steve	- May introduce loops in observed region.
     		- May cause latching behavior
     Dmitry	- Need assignments to execute before property
     Gord	- This means another region
     Mike:	- Sounds like a lexical region where execution is in order.
     Gord	- If you allow writing in Observed, you re-open race conditions
     Mike	- Event structure has grown enormously. It's almost ridiculous


     Gord	- If you have parent & child sequence  If parent provides
     		  and reads output, there might be issues.  May not be cyclic,
		  but there would be ordering requirements.
     Steven	- You would have to execute more than once.
     Dmitry	- What about scheduling non-blocking assignment updates in
		  Re-NBA region?
     Gord	- This should be fine
     Steven	- What about symmetry:  Usually NBA processed in Active
		  region update in NBA region, and NBA processed in Reactive
		  region update in the Re-NBA region.


Self-defined types: Dmitry had some concerns.

     Mark	- Still need to discuss this.  Some people have concerns.
     Gord	- We had agreed that checker would behave same as sequences
    		  and properties, whatever the solution is
     Mark	- Why does let behave differently?
     Gord	- Let is a macro
     Mark	- Need to discuss this in future.
     Mike	- Exposure at Freescale at worst is minor, maybe nothing.

Checkers in procedural code inferred enable

     Erik	- What about always block that counts attempts, etc
     Gord	- You will probably just have to have another argument
     		  that's assigned.
     Tom		- What about race conditions?  Always block in checker could
     		  run before enclosing procedure runs
     Erik	- Maybe we don't need inferred enable


Question
     Dmitry	- Would it be reasonable to limit checkers to always_ff
     Gord	- Would be more comfortable limiting to plain always
     		- Don't want to introduce synthesis semantics into checkers.

Meeting adjourned

</verbatim>



-- Main.ErikSeligman - 23 May 2008
Topic revision: r1 - 2008-05-23 - 14:25:02 - ErikSeligman
P1800