[I was not sure about who was talking when I took the minutes. I am still 
not familiar with the people voices. So I put ? for when I could not recognize 
the name. - fm]

Meeting minutes of last week were approved 
attendance? 

Meeting minutes approval of Thursday face to face will be approved by email. 
Discussion of issues: 

issue: resolution of relation to other APIs. 
=> not resolved 

Andrzej proposal: 
items not resolved, many other need clarifications in wording. 
Swapnajit: 
another round of discussion deferred to next meeting. 
Michael: agreed 

Issue 1.7: abstract access required 

John Stickley: not here 
Michael: seek for alternate possible solution; does not like abstract 
methods which require to rewrite the code 
Direct versus abstract: John proposed always an access function being 
needed for 
non scalar types 
Duane: most types can be supported with the direct mode, do not extend directC 
to handle structs and arrays 
michael: alternate proposal: functions are redefined (overloaded) with 
debug flag 
check flag checks validity of the parameter versus the function used, debug 
flag, 
Duane: proposing sticking with direct access as much as possible but not 
addressing safety from users point of view . 
Michael: have a different function for each value access (one for integer, 
one for real) 
Duane: for a packed array, one function call returns the value which layout is 
defined by the standard 
Michael: direct access, complex types 
Duane: very simple type, direct pointer based access 
Michael: in case of direct access, we just read the value, no checks 
problems,: arbitrary list of parameters, C preprocessor solution, 
C preprocessor flag: values of normal, check, debug flag 
the C preprocessor, just access the parameter values ifdef NORMAL 
Stuart: inline in C++, all of this is easier 
"get" function is overloaded with the type of the parameter 
Stuart: Andrzej proposal is only talking about scalar types. 
access functions only useful for structures 
Swapnajit: work with John and Joao this week; resolve issues with them 
Stuart: what does joao and andrzej think about this issue 
Stuart: after the face to face, it seems that we had decided to focus on 
the direct access. abstract access is useful for debugging. 

=> Michael to connect with Andrzej and Joao 

Issue 1.8: distinguish C and C++ code 

Swapnajit: do not want additional burden of C++ when only having C code. 
Derik?: C procedural interface at the boundary of the interface. 
inside can be C++ 
Micahel: agreed: 
Stuart: okay, but stated tremendous benefits to use C++ in the API. 
overloading can be 
used as well as virtual functions. 
if focus is on simplicity, C api at the boundary is okay 
design the API, with the idea we can support C++ in the future 
?: main problem with C++ is name mangling, initialization of global 
constructors, 
Stuart: you can turn off the name mangling with some C++ functions 
if consensus is to be based on C functions, it is fine. 
Pra?: talking to Ghassam, general agreement C style API but extending to 
C++ later on. 

voting on this next Tuesday? 
Swapnajit: Kevin will send out a C++ example, may defer this to 3.2 
=> agree for vote next week 

Issue : how to find C C++ code 

Michael: problem,in Verilog, statement is missing for how the CC++ objects 
are collected. 
experience with Verilog is bad. every vendor has a different methodology 
C code to be loaded from where? 
? no it is vendor implementation dependent 
Andrzej and Michael should talk? Michael should write a proposal, 
everything now is based on shared objects. 
Michael: okay I will write a proposal. 
? this is not a language issue but rather a tool implementation issue. 
Dennis: one more issue: C module versus external C task, are we going to 
give an issue 
number. => Needs to follow up offline 

Michael: lets' talk about the life cycle and LRM schedule 
Swapnajit: will focus on the path of the issue, assigned an owner, 
modify the LRM 
rejected, open or deferred to future versions 
other paths: open to transferred to another committee 
Michael; Verify status also needed 
Swapnajit: the voting procedure is the verification process 
Michael: some notification of the change, what text changed as [part of the 
verification 
step that the LRM has been documented accordingly to what was specified. 
Swapnajit: if status of the issue changed will be logged in the issue web page 
LRM schedule: 
our main emphasis is direct, assertion and then coverage 
proposal review date 12/10? for directC, start writing the lrm in parallel, 
these dates are deadlines 
send feedback on these dates proposed by Yatin. 
michael: what does need to be changed in the LRM to support DirectC needs 
to be done now, 
Swapnajit: The owner of the issue should drive the edition of the LRM 
modification 
Michael: in the SV lrm identify what are the modifications to support the 
Direct C 
document, for example the BNF needs to be changed. 
Swap: modifs to SV LRM due to directC changes which needs to be started now 
Michael and Swapnajit to talk offline