Subject: [sv-cc] SV-CC Minutes 01/20/04
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Jan 20 2004 - 10:08:39 PST
SV-CC minutes Jan 20, 2004
Attendees:
Michael
Avinash
Francoise
Bassam
Ralph
Doug
Joao
Headlines
=========
* Regularly scheduled meeting is on for tomorrow, Wed 1/21/04 *
* Voting deadline for VPI extensions is tomorrow, Wed 1/21/04 *
General
=======
Proposal to accept Monday's minutes: Ralph
Seconded by: Michael
Joao runs meeting in Swapnajit and Ghassan's absence.
Reminder: Company vote due on VPI extensions Wed 01/21/04
VPI extensions
==============
Michael's comments.
Michael went over IEEE-1364 carefully and compared it to
the SV VPI extensions. Issue about vpiMemory being changed
to vpiRegArray, Francoise, Joao, Michael have some discussion.
Michael requests that the table in the beginning of the
extensions be extended to include a list of any 1364 sections
being deleted. Also, he requests a note stating that any
section not mentioned in the table remains unchaged from 1364.
Joao agrees.
Michael brings up fact that modports should not be in instances.
They should go away from 31. Joao agrees, since packages do not
have modports. Also, there is a repeated note. Michael will send
an email with more detail.
Joao: 13.5 diagram has a problem with modports.
The problem is that modports are in module and instances currently.
They should only be in interfaces.
Michael: 30.9 (variables)
Confused about "range" on bottom right.
Iterating on range from array gives you unpacked dimensions.
The only way to get a vector is placing a range on bit or logic types.
That's why "range" is only associated with array, bit var, and logic var.
Francoise and Michael both request that a more detailed explanation to
this effect be given in the notes.
Francoise: vpiReftRange and vpiRightRange are only associated
with bit var. They should also be associated with logic var.
Michael agrees, so does Joao. Further, Joao says all var select
back arrows are wrong, and he will fix them. Some forward arrows
are wrong, too.
Michael's next comment on 30.9: Modules are same as instances, why even
have them? Joao says that it is needed. Francoise suggests dropping
plural form and using singular "instance" instead of "instances".
Sounds like Joao agrees.
In summary:
1. clarify ranges
2. fix up var select parent relationship
3. clean up notes
Francoise: Instead of calling something "var bit var", call it "var bit" or
"bit".
Joao: How about "bit select"?
This is delicate, have to watch distinction between the type "bit"
and performing a bit select on a variable. Also, there are
compatability issues with 1364. "var bit" can have multiple indexes
whereas 1364 "reg bit" can only have one index.
Francoise: Wants to consult with Charles on this and will
close the loop with Joao.
Michael: 30.10 Need to fix arrows in this diagram.
Michael discovered inconsistency with 1364.
Joao agrees.
Michael: A note should state that this derives from IEEE 26.6.8.
Michael: 30.11 Questions typespec arrows.
Francoise and Joao explain that you can go from a variable
to a typespec, but not the other way around. All OK.
Michael: 30.14 Some general questions and discussions
Joao, Francoise corrections here:
1. class should be classDefn.
2. replace memory with regArray.
3. add a tag called vpiMemory.
4. taskfunc should have a space.
5. missing iteration from begin to statement
6. missing iteration from fork to statement
Michael: 30.20 Question about relationships to classDefn.
Joao: There are two relationships. The pointer is typed,
and the pointee is typed (subtyped). The type of the pointer
may be different than what it actually points to. The first
type here is the type of the pointer. The second type is
the type of what it actually points to.
Joao: notes 3 and 4 are there, are they good enough?
Michael: sorry, not for me!
Joao: will make some improvements, perhaps an example.
Francoise: In 30.17, "task func" should be in italics
<CALL DISCONNECTS RIGHT HERE>
<RECONNECT>
Joao, Francoise: In 30.17, for modeling of supertypes, need to be
able to model both parameter assignments and argument assignments.
(Missing "extends" class)
Michael: 30.25 "Frames": Typo "funch call" should be "func call".
Michael: backward compatability: vpiOrigin used instead of vpiParent
Joao: Theoretically we are breaking backwards compatability.
However, in practice no one has actually implemented this yet,
so there is nothing to break.
Joao: Should put notes regarding back compatability.
Joao: In 1364, given a task call, there was no way of finding its frame.
In SV, any frame can find its origin.
Francoise: if you keep calling upwards "frame, frame, frame..." do you
eventually get a NULL?
Joao: Yes.
Francoise: This is not the same as 1364.
Michael, others: Summary -
vpiParent will have same access as 1364, but we will add vpiOrigin.
Francoise: Will consult with Charles on Frames diagram.
Conclusion
==========
Meeting finishes at 10:03am.
Minutes taken by Doug W.
Don't forget we have another meeting tomorrow 01/21 at 9am PST...
This archive was generated by hypermail 2b28 : Tue Jan 20 2004 - 10:12:56 PST