[sv-cc] SV-CC Meeting minutes for 05/24/2006

From: Charlie Dawson <chas_at_.....>
Date: Wed Jun 07 2006 - 06:38:34 PDT
Hi All,

Sorry that these are coming out so late.  I accidentally sent them to sv-cc@eda.org
and did not notice that they never actually went out.  Agenda to come out shortly.

   -Chas


Minutes of 05/24/2006 SV-CC Meeting.

ATTENDEES
00000000000000
66666666665555
00000000001111
55443332212110
21212101010302
40629515157096
xxxxxxxxxxxxxx Charles Dawson
-x-xxxxxxx-xxx Ankur Kuchlous
xxxxxxxxxxxxxx Ralph Duncan
-xxxxxxxxxxxxx Jim Vellenga
x-xxxxxxxxxxxx Steven Dovich
x-xx-xxxxxx-xx Andrzej Litwiniuk
xxxxxxxxxxx-xx Abigail Moorhouse
xxxxxxxxx-xxxx Michael Rohleder
xxxxxxxxxx---- Ghassan Khoory
xxxxxx-------- Chuck Berking
xxxxxx-------- Bassam Tabbara
xxxxx--xxx---x Francoise Martinolle
xxx----------- Amit Kohli
------------x- Nasim Hussain
-------------x Sachchidananda Patel
--x--x-------- Stu Sutherland


1.  Reviewed Patent information.

   - Chas reviewed the patent information.


2.  Reviewed minutes of the 05/10/2006 Meeting.

   - Francoise commented that I should include link in agenda to the minutes.
   - Ralph/Micheal.  ACCEPTED


3.  Liaisons

   - Francoise talked about the P1800 committee meeting

   - Francoise to report on PASSED SV-BC items
     Nothing to report

   - Chas reported that there is an issue in SV-AC (Item 1361)
     that needs our attention.

   - No one reported on other meetings


4.  New business

   - ITC Issue (Item 1456)
     Ralph made some slight changes to C call chains as this was unclear in spec.
     Changes to 26.43 deal with DPI vs DPIc
       - Put as a separate Item 1488.

     In annex F we are always talking about DPI and DPIc.  Tried to make sure that
     there is no language like that in 26.43, so that we leave the door open for
     other languages, while annex F is always talking about C.

     Should invoking export functions be limited to the C call chain?
     The behavior should be defined more in terms of the context of the invoked
     import function and not the following C function call chain.
     Explanation was sought for the following scenario:

       a. A context import function is called, within this a setjmp() is done
       b. The import function makes a call to an export function
       c. This export function makes a call to another import function, which does
          a longjmp() back to the import function in a.

     In this case the behavior of function execution was sought to be defined as the
     scope and context of intervening import export(b) and the import function(c) is
     lost.

     It was thought that this was a programming issue that the application developer
     had to dealing with.  The application developer should exercise caution when
     such an execution thread is defined.

     Another related point that came up was in case of the import function waiting on
     a synchronization primitive after spawning some threads.  In this case calling
     the export functions was a valid behavior as per DPI.

     Committee members to review the Mantis item 1488 for the next meeting.

     Should execution of export functions from within a pure import function be an
     error?  A discussion ensued on what the behavior of pure functions was, and
     whether pure functions can innocuously cause some side effects.

     In effect, there are three scenarios that have been identified:
       a. Scope manipulating and export function execution from within a context
          import function.  This is defined behavior as per the LRM and there are
          no issues here.

       b. Scope manipulating and export function execution from within a non context
          import function.  This is undefined behavior as per the LRM (as per proposal
          in Mantis item 1456).

       c. Scope manipulating and export function execution from within a pure import
          function.  It was thought that this requires a separate Mantis item by
          itself, if it needs to be clarified.

     We are probably ready to vote on Item 1456, so we will try to do so
     next time.

Motion to adjourn.  1:02pm.  Steve/Michael.  PASSED (unanimous)

5.  Reviewed of items with proposals.

6.  Review SV-CC items with proposals (Straw poll only):

7.  Old Business

8.  Action items

   - JimV to look into other things which can have size changes as discussed in 0985.
   - Chas to send everyone the frame docs for the diagrams.
   - Chuck to write a document that describes the possible solutions for the
     compatibility issues, and they're pros and cons.
   - Francoise and Bassam to continue work on assignment patterns.
   - All to review Item 1488.

9.  Items for consideration at the next meeting (they already have proposals):

   - Item 1456 Clarify, circumscribe restrictions on use of DPI context utilities


10. Next meeting
   The next SV-CC meeting will be on 06/07/2006.
   The last P1800 meeting will continue on 06/12/2006.

--
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com
Received on Wed Jun 7 06:38:12 2006

This archive was generated by hypermail 2.1.8 : Wed Jun 07 2006 - 06:38:22 PDT