Subject: Afternoon meeting minutes for Dec 3rd meeting
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Tue Dec 03 2002 - 18:01:47 PST
SV-CC Meeting Minutes for Dec 3, 2002 [afternoon]:
[The ? marks last week's meeting which I missed; Swapnajit/Ghassan, can you
please fill these in?]
********** Rolling Attendance List **********
[xxxxxxx-----?-] Yatin Trivedi (ASIC Group)
[---xxx-x----?-] Tarak Parikh (AT HDL)
[xx-xxxxx-xxx?x] Francoise Martinole (Cadence)
[x--xxxxx-x-x?x] Stuart Swan (Cadence)
[----xxxxxxxx?x] John Amouroux (Mentor)
[----x--xxx--?-] Emerald Holzwarth (Mentor)
[---xxxxx-xxx?x] John Stickley (Mentor)
[---------x--?-] Duane Pryor (Mentor)
[----xxx-xxxx?x] Doug Warmke (Mentor)
[xx-xxxxxxxxx?x] Michael Rohleder (Motorola)
[x-xxxxx-xxxx?x] Kevin Cameron (National Semi)
[------------?-] Tayung Liu (Novas)
[xxx-xxxxxxxx?x] Bassam Tabbara (Novas)
[---xxxxxx-xx?x] Swapnajit Mittra (SGI)
[x----xx-----?-] Darryl Parham (Sun)
[x-x---------?-] Simon Davidmann (Synopsys)
[-xx---------?-] Peter Flake (Synopsys)
[xxxxxxxxxxxx?x] Joao Geada (Synopsys)
[x-xxxxxxxxxx?x] Ghassan Khoory (Synopsys)
[xxx-xxxxxxxx?x] Andrzej Litwiniuk (Synopsys)
[-x-xxxx-x---?-] Alain Reynaud (Tensilica)
[----xxx--x--?-] Mike McNamara (Verisity)
[--------x---?-] Kurt Takara (0-in)
[---------x--?-] Dave Rich (?)
[---------xxx?x] Joe Daniel (LRM Editor)
<<<<insert Joao's morning minutes here>>>>
********** Joao's assertion proposal **********
Francois: Why not just use VPI?
Joao: This is non-overlapping, and only enabling this subset of
functionality makes optimizations much better. Could simply replace sva
with vpi.
Doug: Why not have a simulation option that would enable just a subset of
VPI for optimization purposes.
Francois: What is a client here?
Joao: It is the calling module; cannot have multiple clients in the same
module. [?]
JohnS: What about iteration? Have you thought about simply extending VPI for
this?
Joao: Yes, but does not want to get into memory allocation/management here.
Stuart: Since it is our (sv-cc) charter to also manage VPI, why don't we do
this here?
Swapnagit: Our baseline is the assertions proposal. We need to start with
this.
Joao: How about if we just extend the VPI handles that come from iterators
to be able to obtain assertion info, and no others? This is suggested as a
phased approach for implementation.
Joao: Assertion data is instance-based not module based, and can even be
bound in instance-specific ways.
Andrzej: How can we tell the difference between a module or an instance?
Consider where they have the same name.
Joao: This matches the name %m if given to $display. This should be made
clearer.
Joao: This proposal allows for a separate initialization of assertions
separate from elaboration. If we move the interface into a VPI model, might
consider dropping the system "initialization/started" states. [Referring to
the dynamic setup.] But the "started" might be useful for delayed
assertion-check enabling.
Francois: Why have id's on callback registration?
Joao: To optimize simulation setup - especially if the same callback is
registered multiple times.
Bassam: Is worried about the assertion implementation dependency.
Joao: Non-deterministic automata pretty much guarantee that we cannot solve
this.
Stuart: Maybe we should push this to SV-AC?
Bassam: Agrees. (* ACTION-Bassam: to take this to sv-ac)
Andrzej: Why have special callbacks for these?
Bassam: One answer is that assertion granularity may change when callbacks
are invoked (i.e. single-stepping with a debugger vs. a higher-level
start/stop of the simulator). [?]
Francois: It will be very expensive to keep track of all this data.
Joao: Simulator does not keep track of assertions, but uses the callback to
inform the user. The attemptid's only are valid during the assertion
callback time.
Francois: How will users use this?
Joao/Bassam: System developers will use this, not users.
Andrzej/Francois: Why not only have this attemptid data if debug is turned
on?
Joao: Fine.
Francois: Why not add the assertion control to the VPI simulation control
API's instead of here?
Joao: Sounds good.
(*ACTION-Swapnajit: Send out the latest assertion document to the
committee.)
********** Scheduling **********
Swapnagit: By 12/18 we want to deliver DirectC contents proposal to Joe.
[See Swapnajit's doc for all the other relevant dates]. But basically the
schedule is extremely tight.
All: We want something good, even if we don't get everything in.
(* ACTION:-Andrzej: to send out a draft of the c-side points by Friday's
end.)
Swapnagit: We will have multiple extra meetings, some of them even two hours
long, in order to keep the schedule.
Ghassan: (* ACTION-Joao - send out updated coverage doc by 12/13).
********** Back to queued issues **********
Issue 1.2b - names of external functions ($'s in names)
Joao: Join this with the Issue 1.8 resolution.
Andrzej: This means that we can indeed override $sv functions. (i.e
$display) Don't want, and we previously disallowed this.
Joao/Kevin: Why not?
POLL: Should we allow extern fcns to map to $ fcns, including built-in fcns,
to be overridden by DirectC? Multiple definitions are still illegal.
Y: 2
N: 3
A: 4 (The abstains win!)
Issue 1.1 - JohnS/Joao's proposal (1.1a) & Kevin's extension (1.1b)
Swapnagit: 4-1-1 on-line vote for the JohnS/Joao proposition.
JohnS: Quick summary - Kevin's extension is for dynamic binding.
Kevin: This is a bit too simple. Also want instance-specific linking which
is not easy/fast in the JohnS/Joao system.
Kevin: other advantages
- Per-line instance support
- Less indirection levels
- Doesn't pollute C namespace
Kevin: Prefers to finish his proposal before voting.
All: There was much confusion over what was voted on for JohnS/Joao. We all
finally agreed that the vote was good.
POLL: Should we give Kevin more time to complete his proposal?
All: Yes
(* ACTION-Kevin: to deliver update by 12/9).
(* ACTION-Swapnajit: Decide next face to face meeting date in December)
********** End of meeting **********
This archive was generated by hypermail 2b28 : Tue Dec 03 2002 - 18:02:36 PST