Subject: Meeting Minutes 01/14/03
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Jan 14 2003 - 10:10:55 PST
---+ SV-CC minutes 01/14/03
---++ Attendee list
* Swapnajit
* Joao
* Ghassan
* Kevin
* Michael
* Andrzej
* Stuart
* Francoise
* Joe Daniels
* John Amouroux
* Doug
---++ Procedural Issues
Michael proposes accepting meeting minutes from 01/07/03 (Doug seconds)
Doug proposes accepting meeting minutes from 01/08/03 (Andrzej seconds)
---++ General Discussion
Swapnajit: Notes Doug's comments on the C-to-SV aspects of
Andrzej's proposal.
Andrzej: Yes they are valid comments, and some of the issues
are not easy to answer. It will take a while to work out the issues.
Swapnajit: Perhaps we should delay voting on the proposal?
Andrzej: Yes, at least a couple days
Swapnajit: OK, will delay the vote
Doug: Will some SV-side changes be needed?
Andrzej: Most likely yes, but you guys shouldn't depend on me
for cleaning up all those issues in addition to the C side issues.
Andrzej: We are depending on the SV-BC (or SV-EC) committee to
clean up definitions of:
- opaque pointers
- strings
- export/extern syntactic issues
Swapnajit: In light of all the SV meetings next week, should we
cancel our normal teleconferences?
Many: Not a bad idea...
Swapnajit: Cancel Tuesday 1/21. Just do the face-to-face on Thu 1/23.
Ghassan: Worried about delaying votes, since deadline is looming fast.
Swapnajit: We need to carefully look at all the items on our plate,
and consider removing some of them to SV 3.2.
Doug: Swapnajit, how can we expedite getting information out of BC/EC
needed by Andrzej:
Swapnajit: Joao is working those issues with those committees.
---++ Joao's Assertion spec presentation, cont'd.
Joao: First change is the VPI constant indexes provided by Charles/Francoise
Michael: Requests using change bars to identify changes.
Joao: MS Word docs have the change bars, OK to send that format?
Several: Just send both.
Joao: Next change is that VPI handles are used more extensively.
Previously, string names had been used.
Another change is on page 6, sec 4.2, assertion callbacks.
the contents of the VPI property structure has changed.
Explains some of the details <too much to record here>.
Array of expr handles, array of source information corresponding
to each expression. (Intended for source debugger implementation)
Joao explains some details on special states, such as starting
and accepting state. (e.g. starting state in Joao's implementation
is always '0', and accepting state is always '1').
Francoise: States 1 and 2 not portable across simulators?
Joao: This stuff is totally implementation dependent, may even
vary inside one implementation.
Michael: Not very comfortable with the limited identifiability
of various accepting states (since they are always '1').
Joao: Yes we need to discuss that before moving on much further.
Joao: Explains how to control stepping behavior.
Currently the only stepping granularity is "clock stepping".
Andrzej: Concerned about steppability of certain assertions.
How can client code know if an assertion is steppable?
Joao: Steppability and Debugability are pretty much the same.
At the beginning, no assertions are steppable. In the Synopsys
implementation, if you use the API, the assertion becomes steppable.
Michael: If I have an enabled but unsteppable assertion,
I can just *not* look at intermediate stages, right?
Joao: Right, but it's better to avoid unsteppable assertions.
This would be left to the implementations to handle gracefully.
Believes that the document states assertions should become
steppable once they are accessed with the API.
Andrzej, Michael: Wondering about assertion clocks?
Joao: The assertion clock is the event control specified in
the assertion declaration. It has the exact same semantics
as normal event expressions. When the event expression fires,
a "step" occurs.
Michael: Suggests cross-ref to SV-AC LRM about assertion clocks.
Joao: Yes will do.
Andrzej: SV Interfaces seem to be ignored here.
Joao: Interfaces have nothing special to do with assertions.
Interfaces have instance names, and thus can have handles.
Andrzej: So you mean interface and module instances to be
equivalent as per this API?
Joao: This spec will remain unchanged, regardless of what
happens will VPI extensions TBD in the future.
Michael: Worried about opening a loophole here.
Suggests limiting usability of the current API to "modules"
and disqualify interfaces as parent scopes. Once VPI is
extended to handle interfaces, we can address them in
this assertions API.
Andrzej and Joao discuss if assertions are module or instance
based concepts. Joao states that assertions are strictly
instance based. An assertion may be present in all
instances of a module, or maybe not.
Andrzej believes assertions are an abstract property
of IP, which makes it associated with the IP's module.
Joao says you have to specify the properties for each
instance of that IP when you instantiate it.
Francoise suggests some changes regarding module/instance
traversal (not understood by minutes taker), Joao seems
agreeable.
Joao: Two ways to configure assertion instances
1) Instantiate an assertion inside a module.
Then each instance of that module will have an
instance of an assertion.
2) Binding
Binding syntax is instantiated in $root.
Binding attaches a property to a specific instance of a module,
or can hit all instances of that module.
---++ Michael's proposal for Issue 1.13
Michael: Proposes adding const qualifiers to input parameters in
Andrzej's C side proposal. Footnote that says when the decls
are auto-generated, const is required. Also would like to use
const in the examples.
Kevin: const doesn't make sense except for auto-generated headers.
Joao: We are saying that when a tool generates a header, const is
required - it's just a constraint to make the header more useful
to users.
Andrzej: I will make these changes.
Swapnajit: Any objections?
None - the issue 1.13 is accepted.
---++ Closing issues
Andrzej worried about mapping actual to formal arguments in complex
cases of unpacked arrays.
Francoise: SV-EC wasn't aware of some of our syntax extensions
to SV, such as open array syntax in formal argument declarations
for DirectC functions.
Swapnajit asks Joao to bring this up with SV-EC in his dealings
with them.
Joao wants to change our syntax for extern/export slightly.
Since there are some other uses of those keywords in SV
in conflict with our use.
This archive was generated by hypermail 2b28 : Tue Jan 14 2003 - 10:11:33 PST