RE: meeting minutes - 6-8-06

Hi John,

Thanks for publishing these well structured minutes.

Inserted few comments below. 

Shabtay

>-----Original Message-----
>From: owner-itc@verilog.org [mailto:owner-itc@verilog.org] On Behalf Of
>John Stickley
>Sent: Thursday, June 08, 2006 3:48 PM
>To: itc@verilog.org
>Subject: meeting minutes - 6-8-06
>
>Attendees:
>   Per Bojsen
>   Edmund Fong
>   Shabtay Matalon
>   Jason Rothfuss
>   Bryan Sniderman
>   John Stickley
>   Russ Vreeland
>
>-----------------------------------------
>SV-CC Issue
>- SV-CC issue of IM has now been resolved in sv-cc committee
>
>Action: JohnS to forward resolution text
>
>-----------------------------------------
>Copyright headers in reference model
>- Cadence had concerns about playing with reference model if
>   headers are still in there.
>
>- JohnS said from the Mentor P.O.V. they're there with the
>   idea that they are protected should the standard not be
>   approved and will be removed upon approval.
[Shabtay] I view this as permission to all ITC members (Cadence
included) to use and experiment with the code example in the context of
our Accellera ITC work. We will remove the code either upon Mentor's
request or if Mentor claims the code example back from Accellera. 
>
>- Per said Zaiq headers were there and now that he's gone
>   has no authority to remove
>
>- Observed that SystemC and TLM headers had special OSCI
>   copyright headers.
>
>Action: JohnS to check into removal of headers of Mentor
>   supplied code and replacement with Accellera headers
>   pending standard approval.
>
>Action: Per to check with Zaiq to see of there are issues
>   with removing headers from Per's pipes reference model.
>
>Action: Brian needs to check if there is a standard Accellera
>   header that can be used with the reference model code
>
>-----------------------------------------
>Comments on updated reference model and specification
>
>- Discussion of whether we want to support non-blocking pipe interface
>   on H/W side. JohnS stated that this might be best left undone
>   for now. Shabtay stated that he see's no reason not to since
>   it is symetric with the C side and easily specified. He also
>   made that case that they improve ease-of-use in cases where
>   a transactor might want to poll for presence of data in the pipe.
>   JohnS illustrated that this could be equivalently done with
>   export DPI calls posting to variables.
[Shabtay] Worth adding that:

John agreed that using the non-blocking interface will be easier over
the equivalent export DPI call approach. 

John raised some performance concerns with nb interface on the HDL side
that have been addressed by Shabtay. Per raised some concerns with the
complexity of implementing non-blocking flush on the HDL side. Shabtay
stated that he raised some questions on non blocking flush in general in
the last email that needs to be addressed. We also agreed to look into
past minutes or IMs to find the issues associate with non_blocking
flush. 

John, Can you address my flush questions in the last email?

>
>- Clarified that blocking calls to pipes in the HDL side are equivalent
>   to 0-time function calls but that non-blocking calls could work
>   over time advances should we chose to add them to the HDL side.
>
>- Disagreement remains between object pipes proposal and retaining
>   function based proposal - this may need to come to a vote.
>
>Action: Shabtay to send example of how to use equivalent
>   of dynamic index with the object pipes proposal.
>
>-- johnS
>______________________________/\/            \     \
>John Stickley                   \             \     \
>Mgr., Acceleration Methodologies \             \________________
>Mentor Graphics - MED             \_
>________________________________________________________________