Subject: SV-CC Minutes 12/11/02
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Dec 11 2002 - 10:22:46 PST
SV-CC Minutes 12/11/02
General ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Rolling 12 Week Attendance List:
[xxxx---------] Yatin Trivedi (ASIC Group)
[xxx-x--------] Tarak Parikh (AT HDL)
[xxxxx-xxxxxxx] Francoise Martinole (Cadence)
[xxxxx-x-xxxxx] Stuart Swan (Cadence)
[-xxxxxxxx-xxx] John Amouroux (Mentor)
[-x--xxx------] Emerald Holzwarth (Mentor)
[xxxxx-xxxxxxx] John Stickley (Mentor)
[------x------] Duaine Pryor (Mentor)
[-xxx-xxxxxxxx] Doug Warmke (Mentor)
[xxxxxxxxxx-xx] Michael Rohleder (Motorola)
[xxxx-xxxxxxxx] Kevin Cameron (National Semi)
[-------------] Tayung Liu (Novas)
[-xxxxxxxxxxx-] Bassam Tabbara (Novas)
[xxxxxx-xxxxx-] Swapnajit Mittra (SGI)
[--xx---------] Darryl Parham (Sun)
[-------------] Simon Davidmann (Synopsys)
[-------------] Peter Flake (Synopsys)
[xxxxxxxxxxxxx] Joao Geada (Synopsys)
[xxxxxxxxxxxxx] Ghassan Khoory (Synopsys)
[-xxxxxxxxxxxx] Andrzej Litwiniuk (Synopsys)
[xxxx-x-------] Alain Reynaud (Tensilica)
[-xxx--x------] Mike McNamara (Verisity)
[-----x-------] Kurt Takara (0-in)
[------x------] Dave Rich (?)
[------xxxxxx-] Joe Daniel (LRM Editor)
Action Items ::::::::::::::::::::::::::::::::::::::::::::::::::::::::
1. Andrzej to send missing parts of proposal on open arrays
2. Andrzej and Joao will send clarification of memory ownership
3. All to continue discussion of topics on email
Detailed Minutes :::::::::::::::::::::::::::::::::::::::::::::::::::::
Proposal to approve minutes of 12/10 meeting by Michael.
Seconded by Doug.
Discussion of deadlines coming up.
Deadline Kevin C's proposal is discussed.
Kevin objects to the poll deadline since we haven't
had in-depth discussion on the proposal.
Ghassan makes the point that the proposal has been
circulating for at least two weeks, and it has been
discussed in part several times.
The team in general feels that it would be fair to
give Kevin the chance to present his proposal in
full before doing the vote.
Andrzej will be gone on vacation starting next week.
We all agree to prioritize his C-side proposal and
postpone the presentation of Kevin's until next week.
*** Andrzej's bit-select and part-select additions ***
Describes need for having a collection of functions to
access single-bits, part-selects in both 2-state and
4-state modes. Presents details of functions.
Agreement on changing current proposal such that two
different typedefs for svScalarBit and svScalarLogic
(Michael: in order to get compile-time checking).
Andrzej asks questions about our preferences regarding
functions providing part-selects. In general there
are source and destination pointers. There are also
starting index and width. One is a pointer to the
simulator's representation. The other is a pointer
to canonical storage buffer. Andrzej's question is
"Should we make a special optimized provision for
part-select modifications in which the part-select
is a 'small select' (i.e. fits into one 32-bit chunk,
aka a C "int")?" (Note: this is described in a comment
in Andrzej's email "DirectC: C layer - support for bit
and part selects")
Some discussion ensues.
Joao: Most part-select accesses will be done on "bit".
Francoise: Most part-selects will be small (< 32 bits)
Michael: Defer this discussion to email.
Note that the part-select functions are "composites"
rather than "primitives". They are only useful for
small part-selects, <= 32 bits.
Both the bit-select and part-select functions are
composites provided for programming convenience as
well as small performance optimizations.
***** Strings and memory handling discussions *****
Andrzej explained this in email response to Michael
yesterday. He recaps the explanation here.
JohnS: Problem with calling a C function that
provides a string as an output argument is that
there is no way to avoid leaks. The problem is
that the C function goes out of scope, and then
the memory is ownerless. This would force the
user to implement some kind of garbage collection
to track the allocated string memory.
Joao: The rule is that C always owns the memory
it creates, and SV always owns the memory it creates.
Andrzej: This is the same issue that is always present,
even with "C calling C" semantics.
Michael: We need to define in a crystal-clear manner
about how memory is handled. He feels the current
memory semantics have unacceptable limitations.
Doug: We shouldn't define any additional semantics
beyond Joao's rule above. The current proposal is
totally consistent w.r.t. existing C programming and
memory ownership problems. Any further semantic
support for memory ownership would be infringing
on the space of user issues. (i.e. in C, the user
is responsible for maintaining and tracking memory
ownership using his/her own tactics).
Joao: SV has no memory allocation system other
than calling C.
Michael: In SV, we will be at least dereferencing
the string pointers. So we need to have memory
lifetime rules laid out clearly to avoid any
ambiguities and inconsistencies between implementations.
Joao: Joao and Michael will get together and put out
a clarification proposal for memory ownership across
the languages by tomorrow (12/12).
Kevin: Wants all vector access done by VPI.
Doug: In the name of API self-containment and efficiency,
we should have special API calls for dealing with vectors
in our SVC (aka DirectC) interface.
JohnS: Agrees with Doug - backs having a standalone interface.
Joao: Similar
Kevin: We will have to implement these capabilities in VPI
sooner or later. Doesn't want the two different ways of
getting at this information to be inconsistent. Wants to
re-use code.
Joao: Is OK, but VPI is much heavier weight.
Doug: Also, it is not being addressed in this round of SV 3.1.
Michael: Wants to limit dependencies on other interfaces
(VPI, TF, ACC) to a minimum.
Joao: In a nutshell, DirectC is a convenience and performance
interface. You can do all these things using old-fashioned
techniques. Our API should fit into the vein of convenience
and performance.
Doug, Joao, JohnS: No need for VPI-like style in our API's.
Kevin: Wants our interface to look like VPI.
Others: That would be confusing for users, since this
is precisely not VPI.
Michael: Now in favor of a standalone, straightforward
interface as well.
Doug: Andrzej, will you be sending out the handle-based
API for accessing open (unsized) arrays?
Andrzej: Yes definitely by this week.
Doug: Could this handle-based API also be used for
arrays of known dimension? (For consistency of
programming model when there is a mix of the two
types of arguments)
Andrzej: There are differences between standalone array
arguments and arrays inside of struct arguments.
[Doug: Sorry - I got lost and couldn't follow this
further when typing the minutes]
Kevin: Wants to have both pass-by-value and pass-by-ref
semantics in our API. Based on & and * symbols in SV.
His argument is that the pass-by-value could automatically
construct canonical form arguments without need for
C calling back to SV in order to get this job done.
Joao and Kevin discuss struct layout commonality between
SV and C. Andrzej's proposal makes it clear that SV and
C struct layouts will be identical across the interface.
This can be achieved in several ways (maybe copy-by-value,
maybe copy-by-ref). It is up to the implementation.
Kevin: What you guys are saying is that there is no
abstract access mode for structs.
Doug: Remember, we agreed on using direct access mode
for function parameters on the C side whenever possible.
Andrzej's proposal does this.
Kevin: But, you are then forcing implementations to
use copy-by-value.
Several: Maybe, maybe not. It's an implementation choice.
Joao: Give me the freedom as an implementor to do a
good job in meeting the spec in my simulator.
Ghassan wraps up meeting, goes over action items, encourages
further discussion of the various topics on email.
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 10:32:55 PST