SV-EC Meeting Minutes 27 January 2003 Voting Members (3/4 or > 75%) (rrrrrrrrrrrrrrrxrx) (-----a----aaaaaaaa) Arturo Salz (Synopsys) (-----aa-aaaaaaaaa-) Brad Pierce (Synopsys) (a-aaaa-aaa-aaaa-a-) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaaaa) David Smith (Synopsys) (-aaa-a-aaaa---a-aa) Dennis Brophy (ModelTech) (---aaa-a-aaaaaaaaa) Francoise Martinolle (Cadence) (------------aaaaaa) Jay Lawrence (Cadence) (aaaaaaaaaaaa------) Karen Pieper (Synopsys) (aaa-aaaaaaaaaaaaaa) Kevin Cameron (National) (aaaapaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (-aaaaaaaa-aaaaaaaa) Neil Korpusik (Sun) (-aaaaaaa-aaaaaa-aa) 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 Note: This is an extra meeting. No votes may be taken and attendance does not affect voting rights. Action Items: 1. Arturo: Add discussion of optional use of () to 7.10. 2. Arturo: In 4.7 make change on compiler error in comment to be a prose description. 3. David: Get clarification of use of slice notation with unpacked arrays from SV-BC. 4: Arturo: Define the order of evaluation for the new operator when used with dynamic arrays. 5. Arturo: Add a short sentence at the start of 4.8 that specifies dynamic arrays passed by value are passed a copy. 6. Jay: Add discussion of use of canonical form for ints in determining an index. 7. Jay: Define order of 01xz and define both integer and in indices for associative arrays. 8. Arturo: Clean-up Table 4-5 so it is clearer. 9. David: Confirm with Stefen to add Action Item in last meeting minutes for clarification of motivation and rationale for program block. 10. Mehdi: Review Verilog-AMS final event, finalize the "final" proposal, and submit for review and incorporation in LRM. 11. Arturo: Clarify Section 7.5 for compare and zero-filled or sign extend. 12. Arturo: Write up statement of process options for voting. Minutes taken by Mehdi Mohtashemi. Please be patient with the notes (did not always get peoples names on comments). 1. Review Action items (see minutes from 21 January meeting) 3) Francoise: find all types with ranges on them. Check to see if shorthand notation can be specified and if it's already present. The review turned up no cases of range declarations that constitute a problem. The BNF needs to be updated to separate ranges for declaration and ranges in expressions with the decleration range incorporating the shorthand notation. Reviewed other action items but there was no action. 2. Review open items raised since last meeting Questions raised on clocking domain by Kevin Cameron. There were three issues. First was due to an error in example 2 Section 13.11 which was identified during the 21 Jan. meeting. Second was that clocking domains should be available within interfaces. They are as was clarified at 21 Jan. meeting. Third issue was with the meaning of 1step and "optimistic" behavior. Explanation was provided by Arturo and Jay that the behavior is not "optimistic" since a "stored" value is always kept so that if a clock does trigger the value is available. This was also a topic of conversation at the 21 Jan. meeting. Final block proposal Mehdi sent in a proposal on the final block. Some discussion ensued. Kevin recommended looking at the "final" event within Verilog-AMS to see if it would be an appropriate model. Mehdi took an action to review this, finalize the proposal, and incorporate it. 3. Review LRM (7, 8, 9) Francoise: Voting, email voting, items refer to what. What does CH- refer to? David: Change list on the web-site, changes to the LRM. Every change to LRM is documented. Mostly syntax and clarification issues, so the verbage created, but not yet approved in the committee. These are more of a bookkeeping issue, should not really create lots of issues. Froncoise: So that is the guideline on the vote. David: Guideline are taken from the bc guideline, on email voting, with the addition of majority of eligible quorem. Francoise: Bc meeting for vote by everyone in the committee, chair for breaking the tie [who is not eligible to vote]. David: I have updated the voting base on the guidelines by Vassillios, make sure we record things. For company based voting the IEEE members vote as part of the IEEE "company". In this case the chair does not vote anyway and Vassillios will break any ties. For non-company based votes the chair does not vote except to break a tie. The votes up until now have not been affected by this. Jay: In the minutes, attributed to Jay on clocking domain/program block. Waiting for clarification from board, and it is here. David: There were two items, comments from Dennis-- wanted to see responses to come, about Cliff's comments on scheduling semantics, and i heard that you were to provide proposal. Jay: My impression was that clocking domain we got clarification. those two chapters should be combined, I do not have much objection to it. Can be done as syntactic production vs. short-hand, like to see a clearer spec. Overwhelming opinion was program block. David: Not overwhelming opininon, but 50/50. David: clocking domain will be separate from the program block, if you can do a proposal for the program block that what would be good. Dennis: Someone promised to, stefan wanted -- motiviation and what the benefits of having it are, what it buys you for a separate name as object. David: I am adding to the minute: more clarification to the program block and its benefits. Ask Stefan for clarification of what he requested. Any more issues? Section 7.3 Assignment, incrementor and decrementor operations David: On to chapter 7. 7.3, any discussion, Kevin's comments on page 43 of draft2. Kevin: Suggestion that there are some side-effects on the function. Arturo: I think kevin's verbage was more appropriate for this section. Change: Replace last paragraph of 7.3 with "Verilog enforces left-to-right evaluation in accordance with the associativity to avoid the ambiguous results; functions f() and g() may have side effects on variables a or b." Section 7.5 Wild eqaulity and wild inequality Jay: In section 7.5, second to last paragraph, zero filled for operator, is that the case with operator that fill sign, do we want to fill it with sign. Arturo: Backward compatibility mode for 2001, it should do what ever it does to 2001 for comparison. Jay: We do not need to fix it now, clarification on this. David: Action item to clarify it; whether zero-filled or sign-filled. David: On 7.3, we should take the side-effect in the paragraph. Arturo: Intent was to clarify what verilog already does. David: Anything else on 7.5? Section 7.9 Operator Precedence and associativity. David: 7.9 has table with addition of operators, changes were a few removals, operators were added for section 20, random constraints, inside distribution. Section 7.10 Built-in methods David: Section added for built-in method to describe it. Section 7.11 Concatenation David: Concatenation operation and strings. no-comments -- move to chapter 8.k Section 8.4.1/8.4.2 Th do..while loop and Enhanced for loop David: In 8.4.1, and 8.4.2: Stu did some sub-titles, so no issues. In 8.4.2, addition for loop mechansim. Section 8.7 Processes David: Deprecated in one place but not other places. Stefan: It is up-in the air for deprecation. David: We can skip 8.7, and get to section 9, and we will keep track of it and apply it ot 8.7 as well. Now to chapter 9. Section 9.1 Processes/Introduction David: Need to look at process control. Jay: If assignment statement inside expression, if assign = 1, some how makes in non-interruptible, sort of buried, concept of non-interruptible statement. Arturo: Thought we decided to drop this, Jay: If someone wanted atomic operation, use a semaphore. David: Is this a SV-BC change or SV-EC change, SV-BC can make a recommendation. Arturo: Forward it to bc, Jay: I will forward to the bc. David: The additon to that paragraph is not related. One of the proposals is to remove dynamic processes statement and use fork join. Stefan: It was part of donation to deprecate 'process'. David: There as well, kevin had proposed it as well. Kevin: Granularity control, such as id for the process. Stefan: For process id, referring to an email this morning, Kevin: Not sure return value to a fork is needed. David: Using a fork, more options of behaviour than a process. Stefan: Return a value was my statement, it looks uglier than process id =. David: WIth process id you can have it. Stefan: Some iteration as Kevnin looked at alternatives, I like the numbers even though initially it was awkward, seems like a better solution than context-sensitive. Arturo: Since fork-join already verilog, implementation is an issue, do not see much value in expression. Kevin: No new keyword. Arturo: I have not looked at the syntactically issue. Stefan: Going and changing it to integer expression ... Arturo: We are compile expression, compiler knows what to create, if you now change that it may behave differently, it is an issue to make it run-time expression where we do not know what kind it would be. David: Using join_all, join_none, and join_any would not cause problem, Brad had sent out email as to how it makes it easier for user to view. Kevin: My issue was to look/get the process id. Arturo: You want fork thread in the background. Kevin: So you can just do join none, what i proposed was a method to get you the process id, name of label, to extend it to be any block. Stefan: I think you are dealing with the statement block. Kevin: You would use a name of scope. Arturo: That is what we wanted to avoid. You want to make these to be atomically created. Kevin: I do not have any problems for the fork to return id. David: Lets work with the semantic of what is to be done. Named for, and return mechanism to return id Kevin: No restriction on using it in automatic scope. If you call a function calling a fork, if you wanted to kill those, you need to be able to return a process id or handle. Arturo: Process id, the idea is to handle the memory manangement issues, Froncoise: All the process ids? David: All the ones created by the fork, process handles. Arturo: Built-in class for process. David: The methods become built-in methods on the process. Jay: The email that arturo sent, brought this new process class into existence. David: Have not had chance to reveiw, it extend fork join. Kevin: Do not have objection to what Arturo proposed. Jay: Would like to go through at least part of it, page 60, below editors'note, is it redundant. Arturo: yes, it is redundant. David: It looks like it has created confusion for Stu. Jay: Fork-join is valid statment, Arturo: Do we need to mention it explicitly, Jay: Just say valid statement, whole paragraph can be removed. The sentence should go away. Change: In Section 9.7. Remove paragraph starting with "The statement(s) can ..." Jay: Order of these executing is known. Arturo: The simulators do it, I do not have a problem with leaving it out. Jay: It should not be anywhere, source not added here. David: page 60, last sentance to the paragraph. 'Nevertheless....' problem if you leave it in there, people use it,.. Arturo: Why that way:: you can choose to delay, suspend the parent proecess, if default parent process spawns parallel processes, Kevin: If you can get the fork to create it, and then start them in any order you want. Something like fork join none. If you are doing that you do not need 'Nevertheless...' Arturo: Those are the same thing, we are trying to save the implementors work. David: If there are no dependecnies on the order, why then. Arturo: Users move these codes to different simulators and want the same order. Do not rely on this. David: The behaviour of vendor to make it predictible. Jay: Only predictible in extreme cases, like this. lots of other cases where vendors do not match each other... giving illusion of source-order execution, we should not give this promise. David: Another way is to put this here... Arturo: It does exist today, implementors have worked to match each other, to save time. fork join none is new... Kevin: If vendors want to do source order it is ok for users. Arturo: For the last statement, if you do not want to rely on if there is an implicit block, it is an instance of determinisim, users can Jay: Use the process id to control the process, children processes into existence, handles to them to control them, what kind of control Kevin: It is usefull to create the process until I decide what to do with it. Arturo: It is not a hw concept, you can look at the handles and be ready. Kevin: If you have all the process handles and a join method, only going to apply to join none. Jay: Issue, I have created the dynamic process, next statement is assignment, I am allowed to do this, not much about order of concurrent statement. Spawn off concurrently and do not say when. Arturo: Process handles to be atomically created before anything executed, child to query them. Jay: That would be fine, need to look at the proposal. Arturo: If you want to leave it non-deterministic, Jay: Yes, Arturo: We do know what the forked off processes would be running, there are times when you would want granularity control, we are introducing determininsm and concurrency. Jay: You are introducing that the child processes are now spawned, but the state of simulation is not known. Arturo: Your objection is to the blocking statement, Jay: Yes, essentially to that statement, Arturo: So if we say blocking statement? Stu: Verilog language allows simulators to jump around statments, without any time control, Jay: If there is expectation that there is stable after none, that the paragraph be removed. Change: In Section 9.7. Remove paragraph starting "The spawned processes start" and paragraph starting "A fork..join none statement causes ..." Stefan: Any comments to having expression on none. Jay: Having expression or not on fork does not matter, it is nothing that it is unsolvable. Stefan: The expression is in parenthesis, Arturo: There maybe some ambiguity, we have not looked at all of it. Jay: It is not clear there. Arturo: It is either fork join none or all, not really seen many of the other variations. David: What is the objection for join_all join_any ... ? Stefan: Looks ugly, if you want to create more than one process, it is ok so long as to use expression as to how many of them. If the most common thing is fork join none, then we can use the process. David: Have you looked at the latest item from Arturo, doing what Kevin wants? Arturo: Would raise strong objection to using process. Stu: Fork join_any is a very good. Stefan: I find it more pleasing with fork join. David: One is I want to do these and wait until one comes back. Stefan: The way wait_children is putting in the background. Had to create a task just for the fork join, not to be killed. Arturo: That is why the process ids are there to do this, fine grain control to do what you want. Stefan: We can do the same thing with the process, the old process. David: Why do you want to keep around, whole discussion on returning on the count, fork join 0 ugly, if you want to do a count, do fork join_count. Kevin: You are asking for extra syntax. Arturo: Optimization is what we are after with fork join none. Kevin: You have to learn how the language works, so it is not an issue of usage. David: Have to make a choice about these. Francoise: Should we use the #define to work through them? David: What is so bad about join_all, you do not want to add keywords, no context sensitive expressions, we do hacks all over this bloody language so what is the deal about adding this! Stefan: Like to resolve this, some group look at the context sensitive words, do not want to make it global keywords. Kevin: If you have process control, you do not need the global. David: We have two mechanisms to do the same thing, if we can extend what is in the language to give us the same, more appealing to, rather than creating some thing that does .. 1: syntactical arguement to fork join related to semantic 2: what type of control over the process once they are forked, Kevin: Arguement for not having expressions. David: Fork join none, is what i meant. Arturo: Fork join any is quite usefull, David: Wriority was there in the proposal. Arturo: I did not get around to get it formalized. David: You have a syntax problem there. Jay: Not true. David: You have to change the existing process to do what you say. Jay: If we make process into class, instead of writing fork join, you create processes, new process control, do not play with fork join at all. David: Need a new yway to do like atomic staring of a group processes. You have to distinguish between process creation and start of process(s). Kevin: You can create a process and query the state of it, is my process running. David; Better to say, here are the processes that I want to start together. Stefan: I do not think users are opininiated about global keyword, vendors could work with global context sensitive keywords, as in not a global keyword for any all none, Arturo: We can just make the keyword optional. no ; at end of Stefan: As long as it is not global keywords, context sensitive, then i am inclined to go fork join all none, if not that way, with _ to be less readable and desirable than 0, 1. Stu: Opposite of Stefan. no context sensitive keywords, users will be confused, 0, 1, is not good, the _ is more usable, readable, the only thing express can be usefull, the _count would be giving the extension, so _all _none _any would be valuable Francoise: What about fork join all? Arturo: We need to look at the implementation since we do not have ; at the end. Stu: The (*), we already regret it, not make it any worse. Arturo: We can propose something, but Stu seems to have objection to it. David: Do i hear any new arguments, need to get something written as counter proposal. You have to do it as context sensitive keywords, and it is hard to do it, Kevin: The parsers would not be able to do it. Jay: The parser wants to get the answer. Arturo: It is not rocket science to look at the context sensitive word following the keyword., you need some syntax, ; is a possiblity, such as stating the following is operator. David: Need to have Jay: Separate the two, fork join what users do today. David: The only reason that users do not have any process control mechanisms is that the processes do a fork join all. No control in parent thread. Jay: Process control explicit. Don: Question, if we use join_all _any _none to be new keywords. Jay: Two choices. Either with _ or with 0,1. Arturo: I will write up the options, David: You can document the two issues, and we will vote on it. Arturo: I prefer to have the email discussion. David: The first action item on next week's meeting is to resolve this Stefan: Regardless of syntax 9.9 we should look at rest of chapter. Section 9.9 Process control David: 9.9 suspend thread, I was hoping to have alternative writeup to 9.7 and 9.9 to make a decision on it. Time is important. Jay: Arturo, did you see my comments on wait_, $task all, users can overwrite them, most part it exist, wait_child, is wait_fork and $terminate is disable_fork and only $suspend_thread problem, what is it if it is not #0. David: Can Arturo and Jay go through these through emails, and resolve it. Kevin: I do not have any issues with process and methods operating on them. David: I want it resolved by next Monday as well as chapter 10, make sure you review and try to get it resolved we go to classes. Jay: Questions on the meeting minutes last time, voting/schedules. David: It is up on the web-site. 4. Next Meeting Will meet next on Feb. 3rd. This is a regular meeting for two hours. We will start the meeting with a vote on the fork..join extension syntax and on the Process Control mechanism. Rest of meeting will be on Chapters 10 and 11.