Minutes of the September 29, 2003 SV-BC Meeting (Design Modeling Committee) 211 958 000 998 000 333 -----a Tom Kiley - Mentor a--aaa Matt Maidment - Intel aaaaaa Brad Pierce - Synopsis aaaa-a Karen Pieper - Synopsis a---aa Johny Srouji - Intel -aaaaa Dan Jacobi - Intel aaaaaa Dave Rich - Synopsys aa-aaa Francoise Martinolle- Cadence a-aa-a Jay Lawrence - Cadence aaaaa- Dennis Brophy - Mentor -a--a- Vassilios Gerousis - Infineon -aaa-- Cliff Cummings - Sunburst Design aaaa-- Mark Hartoog - Synopsys a--a-- Don Mills - LCDM Engineering aa---- Doug Warmke - Mentor aa---- Rishiyur Nikhil - Bluespec -a---- Stu Sutherland - Sutherland HDL Meeting Minutes: ================ We need to change the date on the title of the minutes to 9/15/03. Dave moves that we accept the minutes as amended. Nikhil seconds. No opposed. Jay abstains. Passes. ---------------------- Action Items from the Last Meeting -------------------------------------- ==> Karen to mark the type parameter mail from Nikhil as an issue. Done. ==> Karen move that place issue 4 in the "deferred" category due to lack of a drive for issue 4. Nikhil seconds. No opposed. No abstain. Passes. Done. ==> Karen: update the web to reflect today's changes. Done. ==> Issue # 14: Dave will drive this one. No update. ==> Francoise is concerned that the wording for issue 47 may not apply to object class instance. She will open an issue on this. Issues with Proposals: Issue 36: Jay to review. Issue 37: The issue filed here is not the issues for interface port expressions. Karen will open a new issue with this problem, and modify this problem to be interface port expressions. Dave presented his modport expressions proposal. The concern expressed with the proposal is that the type is not declared before you use it in Ansi-style module ports. Jay conceeds this proposal "is extremely cool." Dave: how about we split this up and pass the modport extensions, and let someone else work on applying it to ANSI-style ports? Jay is ok with splitting it up.... Dave moves that we accept the proposal as it stands. Brad seconds. Jay, Francoise are opposed becasue they want to check on the V2K stuff. No abstain. Passes. Issue 48: Function/Module exchangeability Steve and Synopsys brought up that the proposal needs to be limited to continuous and procedural assignments (i.e. it can't be used in an event expression or inside a sequence, property, or assertion). Dave is also willing to limit the usage of primitives as well. Jay raises the issue of visibility. What if there is both a function and a module with the same name? Also, parameter overloading with functions isn't defined. Dave moves that we postpone discussion on this until the proposal has had more work. Everyone agrees. Issue 49: Operator overloading One piece of feedback on this proposal is that we should extend it to functions. Add a section indicating that the type has to match exactly, or a cast would be required. The DPI statement does not need to be there. Jay is concerned also with the overloading of assignment. What about assignment semantics for copy-in for a task? The scoping a visibility rules need some work. We'll delay this until we have another proposal. Issue 53: Expand array querying functions Jay: :: for methods? Why is :: coming back? Jay: why add the methods in two ways? Dave: Need to be able to pass a type to system task. Are these expressions constant functions? Yes if used on a fixed size data type. In particular, are systemtasks allowed to be used as constant functions? Chairs need to decide on a unified syntax for generic methods associated with types. Perhaps we need to confer with Arturo and David that the issue is owned by the SV-BC. The $ version of the functions are overrideable on the command line. We would need to add info that they cannot be overridden to allow them in constant functions. Issue 58: Brad moves that we accept this proposal. Dave seconds. No opposed. No abstain. Passes. Issue 61: Danny is not here so we'll do this next time. Issue 67: Doug Warmke is not here so we'll do this next time. Issue 71: Tagged Unions Beyond packed unions because tagged unions add type safety. Is there anyway to get access to the tag? Matt: Why not replace unions with tagged unions? What is the motivation for the feature? Nikhil: Typechecking is the main motivation for the proposal. We should move discussion of this to the top of the next meeting. ---------------------- Open Action Items for the Next Meeting -------------------------------------- ==> Karen: update the web to reflect today's changes. ==> Francoise is concerned that the wording for issue 47 may not apply to object class instance. She will open an issue on this. Our next meeting is 10/13/03 at 9am Pacific.