Minutes from John

John sent these minutes from an un-authorized email account, so it did not
go through. Forwarding on John's behalf.

Attendees:
   Per Bojsen
   Edmund Fong
   Shabtay Matalon
   Jason Rothfuss
   Bryan Sniderman
   John Stickley

Minutes:
   - Deferred discussion of support for time consuming tasks to
     next week to give members some more time to consider it.

   - Had a short discussion of semantics for calling exported
     tasks and SV utility functions from C code other than inside
     imported DPI 'context' functions. Although much of this
     discussion up until now has been centered around SystemC,
     the committee agreed that if we can provide semantic
     definition in SCE-MI 2 for when exported DPI functions
     and certain SV DPI utility functions without being specific
     to just SystemC, that would be preferable.

   ACTION:
       Shabtay had some ideas about how to do this and will
       take a stab at it in his next revision of the DPI
       section of the SCE-MI 2 working draft (before next
       week's meeting).

   - There was also a short discussion on further defining
     "undefined" behavior as per the SystemVerilog LRM when
     calling certain SV utility functions, specifically
     svGetScope() and svGetUserData() from within non-context
     imported DPI functions.

     JohnS pointed out that this would support quite a useful
     use model and that currently, because it is "undefined"
     as per SV LRM, we can possibly take the lead on adding
     definition. Shabtay said he thought it was explicitly
     forbidden in the LRM, JohnS thought not.

   ACTION:
       Shabtay to try to find text in LRM that states
       where it is forbidden.

   ACTION:
       JohnS to provide informational text as to why it would
       be useful (assuming it is not forbidden).

   - Had a long discussion on semantics of automatic flush-on-eom
     for non-blocking sends (try_send()'s). This arose from
     different understandings between Shabtay and JohnS as to
     how automatic flush-on-eom is handled for non-blocking
     sends.

     JohnS assumed that there is no special processing for
     eom's on non-blocking calls - even for pipes on which
     automatic flush-on-eom is enabled, and that the eom only
     has its flushing effect on the next blocking call after
     an eom transaction has been written to the pipe.

     Shabtay's assumption was that if a try_send is attempted
     on a transaction with eom set and there is already
     a previous transaction with eom set in-transit in the
     pipe (i.e. that has not been taken yet by the consumer),
     then the try_send should return a status indicating
     that the attempt failed just as it would have had
     the pipe been full.

   ACTION:
       Both modes of operation are clearly understood and
       workable. We need to choose one and stick with it.
       It was decided to think about this a bit more and
       resolve one way or the other by next week's meeting.

-- johnS