Subject: meeting minutes
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Nov 20 2002 - 06:57:15 PST
To: sv-cc@eda.org Subject: Fwd: meeting minutes
To: mittra@juno.com
From: Francoise Martinolle <fm@cadence.com>
Subject: meeting minutes
Cc: fm
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.
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
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 06:58:44 PST