SV-EC Meeting Minutes 27 January 2003 Voting Members (3/4 or > 75%) (rrrrrrrrrrrrrrrxrx) (-----a----aaaaaaaaa) Arturo Salz (Synopsys) (-----aa-aaaaaaaaa-a) Brad Pierce (Synopsys) (a-aaaa-aaa-aaaa-a-a) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaaaaa) David Smith (Synopsys) (-aaa-a-aaaa---a-aaa) Dennis Brophy (ModelTech) (---aaa-a-aaaaaaaaaa) Francoise Martinolle (Cadence) (------------aaaaaaa) Jay Lawrence (Cadence) (aaaaaaaaaaaa-------) Karen Pieper (Synopsys) (aaa-aaaaaaaaaaaaaaa) Kevin Cameron (National) (aaaapaaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (-aaaaaaaa-aaaaaaaaa) Neil Korpusik (Sun) (-aaaaaaa-aaaaaa-aaa) Stefen Boyd (IEEE 1364) (--------aa-a-a-aaa-) Stu Sutherland (IEEE 1364) Non-Voting Members (attendance based) (----------------a--) Chris Spear (Synopsys) (----------------a--) David Rich (Synopsys) (----------------a--) Jayant Nagda (Synopsys) (---a-aa-----a------) Kurt Takara (0-in) (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-) Don Mills (LCDM Engineering) (aa-aa--------------) Heath Chambers (HMC) (-----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. AI-46: Arturo - Rework 10.4 to use static by default. Provide example of using automatic. 2. AI-47: Arturo - Add Const to 10.5.2 (plus example), include comment on simulation semantic for var updates, add restriction on wire usage. 3. AI-48: Arturo - Add clarification in 10.5.4 about mixed named and default argument usage. 4. AI-49: David - Email vote on usage of &, var, and ref. 5. AI-50: David - Remove use of process statement. (CH-88). 6. AI-51:David - Change use of fork..join all/none/any to fork..join, fork..join_none, fork..join_any in LRM (CH-89). 7. AI-52: David - Change function return value per discussion (CH-90). Minutes taken by Stefen Boyd with some help from Mehdi Mohtashemi 1. Review and approve minutes from Jan 27 meeting Moved - Neil Second - Arturo Abstain - Brad Passed 2. Review and resolve email voting results (CH-34 and CH-36 in particular, see attached) David - Primary object left on term singular. Any other suggestion? Neil - I suggested non-composit Jay - Non-composite has same problem of definition of composit Arturo - Could use aggregate and non-aggregate. Francoise - It shocks because you don't know what singular means. David - Need to look at composite if singular fails. Will take vote on CH-34 CH-34 singular Proposal - David Second - Dennis Against - Neil, Kevin, Francoise Passed CH-36 compatable types Proposal - David Second - Brad Against - Francoise Abstain - Kevin Passed 3. Review open Action Items (see Action Item list at http://www.eda.org/sv-ec/ActionItems.html) Items AI-1, 2, 4, 5, 8, 9, 10, 12, 13, 14, 15, 16, 41 have been closed with new change requests as appropriate. 4. Approve Changes: CH-23, CH-33, CH-43, CH-59, CH-66, CH-67, CH-70 through CH-82 These are all either changes done before Draft 2 or the result of action items that have been completed. The vote will be done as follows: a. Request any issues with the listed changes b. For those changes with no issues they will be voted on as a group c. For those changes with issues they will be discussed and resolved (with either vote or a change to the item). Neil - I had a few comments ona few of these starting on p45. I can't see underscores well in web or documents. last sentence at bottom of page talks about calling methods should be built-in method calls. David - So adding "built-in" before method calls? Neil - Next page, I didn't understand "applies to specific data". Example was ok, but text isn't clear. Arturo - Method preffered to system task. Universal .size method would be a good idea. Neil - What is the specific cases? Arturo - If it applies to all data types is when it is preferred. Or if there is a functionality specific to one data type. Neil - Why do we need both? Arturo - They are different. Some may only apply to a couple data types. Neil - The example that optionally allows leaving off parens. Do we really want to do that in examples? Arturo - There are both types of examples. David - For 1364 examples, would you want to show examples. The example Neil was referring to in 7.10 where none of them show the parentheses. Cliff - If they aren't required, it doesn't bother me. David - Comments I have seen are that we should add "built-in" before method. Add the word type after specific data. Likewise we should put it in last sentence as well. Will add that to CH-33 Neil - CH 43 where it says Verilog forces left to right, do we need associativity? Can we just strike that part of it? David - Was that suggested by Kevin or Steven? Neil - Was that for more clarity? Kevin - Yes. David - Most things are left to right associativity aren't they? Dennis - Except for assignments. Neil - If it's ok with everyone else, I'm ok with it. It doesn't look like we need both variables. f(a) and g(b) are exclusive. David - You don't know if there are side effects Arturo - I have an example that might be good where there was an optimization that gave different results. David - Should we change the example so the order on the display is clear. Arturo - You don't need side effects to show this. You can't see side affects on globals. Francoise - is the precedence of left to right defined here or in Verilog? Arturo - Yes it's in verilog Neil - The text should mention the global variables. David - It could be global variables or xmr. You don't know how. We could mention global variables and xmr in note. Neil - For me, that improves it and maks it a better writeup. I also had a question on CH56 David - That's not one of the onese we are voting on, but go ahead and mention your issue. Neil - I thought it was 14.4 not 14.2. Looks like a mistake. David - Two are related, 64 and 56 Neil - 61, 62 and 63 are all done on the same section Arturo - You are right, that is more for 14.4 David - So CH56 should be deleted. There are some other corrections going on for items that haven't been completed from other meetings. Neil - On CH-74 in the text of the change: when no arguments, parens are optional. This is true for all methods, not just builtins, right? David - There were two sections that needed to be updated to get builtin and non-builtin. I split it to make it clear Neil - Ch 75 - should that be assigning fixed-sized unpacked arrays? Arturo - Yes David - That's in the first paragraph. Neil - CH79 - $tf_dofinish vs tf_dofinish. Need dollar in both places or in none. David - Remove $ from $tf_dofinish Neil - CH80 - Correction for bnf doesn't look quite right still. You could specify something like input posedge given this bnf. I think you need two skews - one for default and one for specific. Arturo - Should be the same. There is a little font typo, bracket is in italics. Jay - So are we trying to accept changes and then we re-review the sections. David - We won't be reviewing those chapters again, we're just including the updates that need to be in the first 11 chapters. Changes: CH-33: Create new CH-87 to replace "method" with "build-in method" in the third, fourth, and last paragraph of 7.10. Add the word type after "specific data in the fourth paragraph. (New change required since CH-33 already in LRM). CH-43: Add global or hierarchical reference to comment on side effects. CH-56: Delete (was a mistake) CH-75: Change fixed arrays to fixed-size unpacked arrays. CH-79: Remove $ on tf_dofinish. CH-80: Change italic bracket to regular. Motion - Accept changes as amended above. Proposed - David Second - Dennis No abstains No Objections Passed 4. Vote on process/thread spawning options: 5 items to vote on (See attached document) David: Fork-join has 5 options now. All 5 options specifies default behaviour, if we want to remove all [option] then we can do it. Option 5 provides expression as opposed to number. Francoise: Make it constant expression, can we do it by email. Cliff: Walk through and see who favors it. David: Options 1 , 2 Neil, Cliff, Arturo, Mehdi: vote 1, and 2, Dennis: Option 2. David: Option 3: any supporters option4: Francoise, Kevin: yes Cliff: How could you? looks ugly... Francoise: Other than -1, it reads easily Arturo: One other option was string literal. option5: Kevin: My vote..process was ok. David: Anyone else Kevin: Option 5 is the most extinsible syntax. David: We do not want to depracate fork join. Jay: I would abstain, i like the capability, Result of first pass (pick multiple): Option 1: Cliff, Mehdi, Neil, Arturo Option 2: Neil, Cliff, Arturo, Mehdi, Dennis Option 3: - Option 4: Francoise, Kevin Option 5: Stefen, Kevin David: We're down to two, options 1 and 2. Kevin: I would vote for 1. David: We have removed 3,4,5, choose 1 or 2. Cliff: I would for 2, based on what Dennis and Jay said. Neil: I would vote for option for 2. Mehdi, Arturo: option 2 is ok David: which one you want to vote for Stefan. Stefan: I would pick 5 and 2. Result of vote (pick one) Option 1: Kevin Option 2: Neil, Cliff, Arturo, Mehdi, Dennis, Jay, Stefen David - So pruning votes got down to fork/join_all, join_any, join_none. Separate vote on join_all removal. Does anyone want to propose this? Motion: Remove join_all from options Proposed - Kevin Second - Cliff Abstain - none No - Mehdi, Arturo Passed David - So now we can drop discussion of fork/join Neil - Arturo made a proposal for process control. David - Officially we had moved it to a later date. If there was concenses, it would be worth it, but we don't have time to deal with alternate proposals. Neil - I liked it. David - Would you like to take a straw poll? Arturo - I'd like to consider Mehdi - Like to consider Cliff - like to abstain Jay - Have these discussions with marketing guys. Yes I like it, but we only have three weeks... Arturo - Perhaps we can recast vote to hold Jay - I'm going to vote against since we don't have time. Francoise - Isn't it completely the same as fork join_none? David - Yes. Francoise - then I would vote against it. David - We have two different definitions of process. Motion - Deprecate process as used in lrm, but retain keyword for future use. At end of document review, if we have time will consider use as object. Propose - David Second - Mehdi Abstain - Kevin Passed David - Will remove from 8.7 and 9.6 (which was already removed). 5. Review LRM a. Review 10.1, 10.3.2, 10.4, 10.5, 11, 12 b. Vote on acceptance of Chapters 1-11, 12 (with condition that all relate action items will be approved) Section 10.3.2 Neil - A non-void function can be used in a statement where it's return value is discarded. Why would you give a warning? David - It means use like a task Jay - The syntax of void = function, why would you want this? I don't see why you need the second one. Kevin - No reason to have both ways. I would rather not have either. I just want to make assignment and don't need cast syntax. Jay - There is a conflict here. calling function without making assignment gives both error and warning. David - So if we make the first to say that it may be a warning, second sentence will be removed as redundant. Neil - The second one I find cleaner. Francoise - This is the first time we see a type equal to an expression. Arturo - That is what makes it difficult when you see it. Kevin - The first one is consistent with C, but the second is not useful. Motion - Remove assignment version of cast Propose - Kevin Second - Francoise Against - Neil, Arturo, Mehdi Abstain - Cliff, Dennis Support - Jay, Stefen, Francoise, Kevin Passed Section 10.4 Jay - Assuming we've got a program block, having two different defaults in different places doesn't make sense. If I declare a task inside a program block having it be automatic vs static. Arturo - What about methods? Jay - It's clearer there because the class itself is dynamic. Arturo - It seemed more confusing to have a mix of static tasks and functions vs automatic methods on objects. Neil - I think we said methods and tasks are not that way, so we would have to change the text. Motion - Make the default declaration for all tasks and functions to be static in modules, interfaces, and program blocks. Propose - Jay Second - Kevin Against - Mehdi, Arturo passed Arturo - Can we delay this discussion until after we decide program block? David - Let's assume program block's existence for the purpose of this vote. Neil - There was an editors note saying there wasn't an example, should we have one? David - We have action item to reword 10.4 and provide example. Section 10.5.2 Neil - In 10.5.3 it uses scalar in first sentence, that should be singular. In 10.5.2 it says that data is accessed indirectly. The word indirectly should be dropped. David - So indirectly will be removed from two locations. Francoise comments suggested adding const var arguments. Jay - This is apparently a new direction, but I'd like to see it as a modifier instead. Kevin - I half agree, for const on a port. I'm looking for consistency with c. with cc, external calls could be implemented in either c or verilog. It'll make it easier to use c headers. Arturo - The cc committee threw out the direction variable. Kevin - The way we were looking at it was that you could declare any function as external. Arturo - You are really suggesting a change in semantics that now would be a protection against writes. David - const var then allows combination of protection. I have heard agreement that we need protection. Jay - I could live with const var. David - Let's add const to that section. Francoise - I was looking for section on what kind of objects can be passed by reference. We should start with output or inout, when do we perform update. It's well defined in 1364 for copy-in and copy-out. Arturo - What is the question? Francoise - What are the restrictions on passing objects by reference into a task or function? Arturo - I would eliminate wires since I clearly haven't thought about it. Jay - Is it legal to pass a wire to a function today? Arturo - There is no reason to preclude it. David - Do we put a restriction on what we can pass by reference? Kevin - The problem with a wire is the question of if you are pointing to a driver or the resolved value Francoise - You can't pass wire to function or task today? Stefen - Certainly, you can. Kevin - It's passed by value. Jay - write to output of task passed by reference, would the fanout happen now vs when the task returns? David - So something needs to be added to make it clear. Arturo - This could be done with a code example. David - If we need to do it, we should add an action item. Kevin - Would like more of a c syntax using & instead of use of var keyword. Francoise - Can it be used as an operator there? In a function call, would you use the &? Kevin - No, it would be clear from function prototype. I believe you can use var to declare objects that are references. Francoise - I have seen that in the headers. Jay - The only problem with var is that we might want to use it later if we transition away from reg. Arturo - Why not logic? Jay - Because I would like to have it be a type that I can use on wires or variables. I would like a future place to put var in front - it's something I would like to use in verilog two thousand something? David - Wanting to know if there is enough interest in Kevin - I don't like the syntax as it requires a separate declaration for the reference. Eventually, we'll use it in other places. Arturo - That would make it an infix instead of a prefix Jay - It's a prefix operator on the object name. David - Can you do that on declarations now? Jay - It's even worse than that, input i,j,k where input is used on all three. Kevin - There are a bunch of things you will want to do and this will limit you. David - Can we see if there is a problem with using '&'? Jay - I would like to pass on '&' and instead use ref instead of var. David - The issue is much bigger than Francoise - I think my comment on 10.5 proposed illegal syntax. Neil - Default arguments are worthless. We internally have coding guidelines that say that you should't do that. David - The defaults on the rhs is used, but lhs isn't. Arturo - In vera you use asterisk. Kevin - When you have by name, you don't need positional. I would enforce that you either use positional or named. Jay - I would make a rule that if you have positional and named, then the positional must come first. David - Action item will be created to clarify usage of default and named arguments. David - We need to review these on a new meeting in the next two weeks. Discussion on schedule issues with other meetings. Possibility of additional meeting called. Not an option due to other committments. Will start with Section 11 in next meeting (as well as try to finish 12). Jay - Need to make sure event handling section doesn't refer explicitly to scheduling semantics. All questions and issues must be sent to the email reflector by Friday for Monday's meeting! 6. Next meeting is 10 February 2003. 7. Meeting closed.