SV-EC Meeting Minutes 10 February 2003 Voting Members (3/4 or > 75%) (rrrrrrrrrrrrrrrxrx) (-----a----aaaaaaaaaa) Arturo Salz (Synopsys) (-----aa-aaaaaaaaa-a-) Brad Pierce (Synopsys) (a-aaaa-aaa-aaaa-a-aa) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaaaaaa) David Smith (Synopsys) (-aaa-a-aaaa---a-aaaa) Dennis Brophy (ModelTech) (---aaa-a-aaaaaaaaaaa) Francoise Martinolle (Cadence) (------------aaaaaaaa) Jay Lawrence (Cadence) (aaaapaaaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (-aaaaaaaa-aaaaaaaaaa) Neil Korpusik (Sun) (-aaaaaaa-aaaaaa-aaaa) Stefen Boyd (IEEE 1364) (--------aa-a-a-aaa-a) Stu Sutherland (IEEE 1364) Non-Voting Members (attendance based) (----------------a---) Chris Spear (Synopsys) (----------------a---) David Rich (Synopsys) (----------------a---) Jayant Nagda (Synopsys) (-------------------a) Jeff Freedman (ModelTech) (aaaaaaaaaaaa-------a) Karen Pieper (Synopsys) (---a-aa-----a-------) Kurt Takara (0-in) (-------------------a) Michael Burns (Motorola) (aapaa----------ma---) Peter Flake (Synopsys) Guests (non-voting) (--a-----------------) Adam Krolnik (LSI Logic) (---a-a----------a---) Alec Stanculescu (Fintronic) (----------------a---) Alex Zamfirescu (ASC) (---------aa-a-aa-a-a) Don Mills (LCDM Engineering) (aa-aa---------------) Heath Chambers (HMC) (aaa-aaaaaaaaaaaaaaaa) Kevin Cameron (National) (-----a-a-a-a--------) Tim Corcoran (WHDL) Inactive Members (Missed last 4 meetings) (-aaa----------------) Dave Kelf (Synopsys) (--a--a-a------------) Michael McNamara (Verisity) (aaa-----------------) Paul Graham (Cadence) (a-------------------) Roy Armoni (Intel) (aapa-a--------------) Simon Davidmann (Synopsys) (aa---a--------------) Steven Sharp (Cadence) (-----a--------------) Stephen Meier (Synopsys) (-aaaaa--a-----------) Tom Fitzpatrick (Synopsys) (-----a--------------) Zeev Kirshenbaum (Verisity) r => Regular meeting x => Extra meeting (Presence counts for attendance, absence does not) a => Attended p => Attended by proxy - => Missed Action Items: Action items are documented on web site. New action items are: 1. Jay - create formal proposal for declaring automatic variables with application to how classes are declared. 2. Arturo - Section 11.4: add handling of null object as illegal and the behaviour is undetermied. 3. Arturo - Section 11.8: writeup a proposal to have c++ like namescope to access members. 4. Mehdi - Section 11.10: Clear up the confusion in shallo copy witin example. 5. Arturo - Section 11.13: Rework second sentence of first paragraph for clarity. 6. Jay - Explore use of super and parent in regression tests. Minutes taken by Mehdi Mohtashemi 1. Review and approve minutes from Feb 3 meeting Moved - ??? Second - ??? Abstain - Jay Passed 2. Review and resolve email voting results on var/ref/&. Result of vote was that ref is selected. Kevin suggested changing the order of declaration. David pointed out that the order follows the input/output order. No action. 3. Review open action item status a. Kevin's action item to exchange [] and [*] on dynamic and associative arrays was discussed. Arturo pointed out that an extension for the dynamic array might be to define a new initial value for the range such as [5:*]. This might be confusing to users since * would be used for an associative array and for the end of range on a dynamic array. Not a major point. Discussion continued on using other syntax for the associative array such as [?]. Discussion moved to the reflector to flesh out. Motion: Exchange [] and [*] on dynamic and associatiave arrays. Moved - Kevin Second - Stefen Against - Stu Motion passed b. Other action items acknowledged but no ETC provided. 4. Review LRM (Section 11). Section 11: Brad raised the issue of using the pronoun 'one'. Will be addressed on a section by section basis. Section 11.1: David: Neil's question 11.1, Neil: it is better to change SV 3.0 to just SystemVerilog. Change: Replace the first two sentences with: SystemVerilog introduces the object-oriented class framework. Section 11.2: David: nothing there except BNF. Section 11:3: David: Brad's question. Arturo: lets change it to ...collection that includes data. David: class is the type that includes data and subroutines that operate on that data. Change: Replace the first sentence of the first paragraph with: A class is a type that includes data and subroutines that operate on that data. Brad raised the question of changing the wording related to properties. Conclusion was to keep the original statement. Section 11.4: Discussion on static vs active nature of classes. Jay: Is there a reason not to create a static object, without new? Arturo: You need to create a pointer to it, inorder to do it. David: There is no static one. Jay: Looking for a coordination of what we have done with other variables, aggregate data and operators, just use it.. Arturo: You can just call the constructor and it gives you this. Stefan: It would have been good to have it static, Arturo: It is up to the compiler to allocate storage. Jay: There is some optimization concern to it, then I can use it. You may want to extend the ref to help us. David: The real issue, once the object is created, the name, it would work as static and dynamic. Jay: I prefer to see us declare a type that is dynamic that applies to all SV variable, any SV type, since we can get to it, this is ok. David: Verilog is not a generic language, the semantics of static is fundamental to HW vs the testbench domain which is more likely automatic. sounds like a good extension for the later versions 3.2 onward. Kevin: It maybe messy to do. How are you going to declare static? David: I can put static attribute to it, Verilog in modeling the hw does not look like c++. Jay: In the declration, it would be cleaner now if we require to use ref to make it clear. Kevin: I think you can use ref to clear things more. Arturo: Even the language does not say when the initialization occur. Stefan: For hw folks, it looks like static but in this one it is dynamic, I like to see it clarify at the declaration time. David: & has two meanings, overloaded concept, the arguement is gone. Kevin: Fef and static are doing the same job. David: They are not, static is storage declaration. Stefan: I like it to look like dynamic rather than static. Jay: If we use ref, other c folks would require more from it, passing by ref to tasks/functions -- same as defining outside, assinging to object, does it get, the fanout, Arturo: It will be required to declare ref ref, to the object, David: If you can do packet p=new; to give you the allocation. what is wrong with it. Jay: If you see the word packet you do not know if it is struct or class. Nf all other typedefs, you just instantiate you get it storage, class is the only one you have to use new. David: Which way is it more likely to use static class within systemVerilog? Is it something with common. Stefan: I wanted to use static classes many times. Jay: Without looking at typedef you can not determine it is dynamic. For future use declaring dynamic struct, you want handle followed by struct, if we do not make the decision now, it will be difficult. Neil: Overall it is not too common to use static classes, rare occasion users have said they may want it. David: There is this item from CC, with opaque handle. Jay: We can say handel void to accomadate it. David: We can use the handle packet p to do this. Jay: Since we have not done it yet, not hard to define it. David: If you do this, everywhere you declare class type you have to pass handle with it. Arturo: You run into confusing handle handle, Jay: I think you have to accomodate handle handle. David: When pass a ref to handle what would happen. and what would it mean with static? Neil: The handle will be the same but can change the content. Kevin: The proposal to place a handle in front of dynamic types. Jay: I would be willing to second it. Jay: All users like classes and inheritance, class mechanism, the way we do it consistent with Verilog, objects should be static, for dynamic we have to create new methods. Arturo: Classes are the dynamic natures. Kevin: I want to make it synthesizable. David: If you have both static and dynamic, which way do you go, arguement: make everything static, then put dynamic. or class being dynamic. Arturo: You can wrap the elements in class. Jay: Place struct in a class, one more reference to the struct. Arturo: If you have typedef struct, then you have the name there. Michael: Good thing about classes was group data and methods, dynamisim is orthogonal. Stu: It should be intutive to folks coming from c background. Michael [Motorola]: Default to be dynamic, Kevin: struct and class are not the same. David: Yes they are different, seems to have more problems being said, but what about others. there maybe cases. Arturo: The Vera model, is a lot less confusing for people to develop the testbench, it is the semantics. Kevin: The problem with c is the memory., memory protection. David: The concept of OO is 60s, it is something gives us encapsulation, all dynamics in Smalltalk, Simula, c++ and Java. Jay: I move that we require to put handle in front of class. Arturo: The most common case is the dynamic usage. Kevin: Agree with you on the testbench, but the hw design it will be used. Arturo: How do you initialize classes. Jay: I have not proposed to use classes statically in SV, not how dynamically create. All objects of a class type require a keyword handle in front to indicate they are dynamically allocated in SV. This allows us in the future other types dynamic. Arturo: Do we have to say handle when we pass it by reference. Jay: It gets ugly in task declaration. do we agree typedef can define it with handle. Arturo: Then you have to extend it to allow automatic. Jay: If I change it from struct to a class, if I change it, then static for struct, my code does not have to change it. Arturo: Why does it matter to do this? David: Going to the motion on Jay's proposal. Mehdi: Who can vote on this proposal? David: Nothing that has been discussed will change the fundamental behaviour of the language, with either way. Kevin: The polymorphism usage is different. David: I am trying to figure if this is a company vote, any objection: Stu, Arturo, Neil, Dennis, Mehdi: object to this proposal. Kevin: I think we should discuss it further. Cliff: abstain. David: Karen still has voting rights, I can double check. Stefan, Francoise, Jay: voting For the proposal. Kevin: Does not have voting rights. Motion: We require to put handle in front of class to indicate automatic . Moved: Jay Second: Francoise Abstain: Cliff Against: Neil, Dennis, Stu, Arturo, Mehdi For: Stefem, Francoise, Jay Motion failed Dennis: would like to see the formal opinion. Jay: I volunteer to do this. David: Jay will be creating such a document. Francoise: What about from CC request to have a handle? David: We will deal with it at our 4hr meeting. Jay: I will do the writeup above to be ready for discussion. Section 11.4 (continued): David: Chris Spear's comments. Access of class object with value of null. Arturo: the issue is valid, but debugging is not part of the language: David: Brad's comment, last section--> previous section. Arturo: We should keep it the same. David: Editor's note in the middle of 11.4, keywords of new. Stu: What do you do in c++? David: Yes you do use new in it. Arturo: You may want to use $this, but $new could create problem. Stu: Something like new$, this$ perfect names. Jay: Operators could be more appropriate. Stu: Keeping consistent with c++, but less keywords. Stefan: [back from ..] we can not solve the wholething stay with what we have. David: nothing to change. Section 11.5 No Change Section 11.6 No Change Section 11.7 Francoise: Why not use malloc instead of new. Kevin: Because no pointer is there, can you point to subclass? Arturo: Subclass you can put it in, super class with a cast. Change: Replace time in last example with cmd_time. Section 11.8: David: Fix typo semId should be fileId. Change: Replace semID with fileID in example. Arturo: Chris's namespace, context of static member, has implication to static member. Jay: Could that be combined to get rid of this. Arturo: Like what Kevin proposed, ^=. super is useful in of itself, you're extending from the class, calling the constructor of parent class. Kevin: c++, if you want to use the base constructor. Arturo: It is really due to multiple-inheritance. Kevin: Super gets you up one level., you can not get to the parent of parent. David: This is a policy issue, you can always do something later. Francoise: Question on new, for array we use this keyword as well. Arturo: It is same as c++, Francoise: Second question, no argument, then new; without (). David: We have added a section on functions like this. Arturo: New is operator, Section 11.9 Change: Change endfunction and endclass to bold in example. Section 11.10: Arturo: We need to clarify this on the new. It tags on the previous example. David: Francoise and Brad had questions. Change: Change section title use of re-naming to renaming. Change task test to integer function test. Section 11.11: No comments. Section 11.12: David: Comments? Suggestion to omit the final sentence and that it is due multiple inheritance. Arturo: It is not really true. It is irrelevant. Kevin: It is not true in c++. Arturo: If it is not virtual, you get the current method. Michael: Without virtual there is no polymorphism. Arturo: If method is virtual, then it behaves like one. Kevin: there is actual entry point. No change. Section 11.13: Neil: the second sentence, to re-write. to be clear. Arturo: modify the sentence for clarity. David: Brad's super question. Kevin: I still do not get the objection to classname::method. You know the name. Arturo: They have to change the parent, super is neutral, leaving it in is very usefull. Stu: In heiarchy module, there is only one level higher, in module heirarchy, if we can get an extension that allows the levels of heirarchy would be helpful. If we are adding ability to go up more than one scope. David: Issue is to allow keyword super or remove it. Arturo: I would suppose $super, like $root. David: We will leave the question about super. Like parent better super. Jay: It uses it for module, Stu: Parent is more intuitive. Neil: I would expect parent is used as well, something baseclass could be better. David: Just want to note that it is here and move on. 5. Next meeting David: I will review all of the comments in 11 and 12 and handle the changes that are typos so we do not have to handle in meeting. David: I will call a meeting for next Wednesday to make progress on reviewing Chapter 11 and 12. The meeting will be a non-penalizing, non-voting meeting. 6. Meeting adjourned.