SV-EC Meeting Minutes 2 September 2003 11:00 am. Monday (rrrr) Voting Members (3/4 or > 75%) (aaaaa) Arturo Salz (Synopsys) (-aaaa) Brad Pierce (Synopsys) (--aaa) Cliff Cummings (IEEE 1364) (aaaaa) Dave Rich (Synopsys) (aaaaa) David Smith (Synopsys) (-aaa-) Dennis Brophy (ModelTech) (aaaaa) Jay Lawrence (Cadence) (aaa-a) Michael Burns (Motorola) (-aaaa) Mehdi Mohtashemi (Synopsys) (aa-aa) Neil Korpusik (Sun) (--aaa) Ray Ryan (ModelTech) |||||_ 2 September ||||__ 18 Aug |||___ 4 Aug ||____ 21 July |_____ 7 July Non-Voting Members (attendance based) (-----) Chris Spear (Synopsys) (-----) Francoise Martinolle (Cadence) (--a-a) Jeff Freedman (ModelTech) (---a-) Stefen Boyd (IEEE 1364) (-a---) Stu Sutherland (IEEE 1364) Guests (non-voting) (-a-- ) Kevin Cameron (National) (--a-a) Don Mills (LCDM Engineering) Inactive Members (Missed last 4 meetings) r => Regular meeting x => Extra meeting (Presence counts for attendance, absence does not) a => Attended p => Attended by proxy - => Missed Action Items: [identified with AI (#) in this text, # refers to AI number] This week: AI-11 : Neil - Write-up the three different options for ERR-4. AI-12 : Arturo - Add order and number of evaluation for case (EXT-8) and an example using expressions, negative becomes 0, self-determined and sum issue. AI-13 : Arturo - Move 8.5.3 section of EXT-14 to a new proposal for EXT-15 (and remove from EXT-14 proposal). AI-14 : Arturo - Move 7.10.1 section from EXT-14 proposal in response to ERR-5 (and remove from EXT-14 proposal). AI-15 : David - Add errata for description of use of wait using, methods - Dave owns. Minutes 9/02/03 taken by Mehdi Mohtashemi 1. Review of meeting minutes from 18 August 2003 meeting Motion: Accept the minutes from 18 August 2003 meeting Moved: Brad Second: Jeff Abstain: Mike Burns Against: None Passed 2. Review of action items AI-5: Arturo and Cliff, scheduling, Arturo sent email. There is a problem Cliff is working on response. Keep as AI-5. AI-8: EXT-2 was resent by Arturo with changes. AI-10: EXT-2 was resent by Arturo with changes for kill. 3. Review of Inter-committee dependencies David: nothing to report 4. Review of Errata list: ERR-4: Lifetime of automatic variable and fork/join_none Jay: Neil's response was a cogent response. Explicit mechanism seemed like a good approach. Good compromise to allow consistency with other forms of fork...join. Ray: Sounds like a good idea as well. Also avoided fork..join_none being different from fork..join_any. Arturo: So what is the mechanism? Neil: Did not define a specific mechanism. More work needs to be done. Cliff: Can you describe the problem and response? Neil: Sharing of automatic variables in spawned processes may be illegal if parent process goes away. Proposal in ERR-4 was to make variables be automatically copied. Response was that this should be consistent with 2001 in form. 3 main points in email: 1. ALL sub-processes share/access to automatic variable as fork/join 2. LifeTime, auto variables in sub-processes, cannot go away until sub-process goes away. 3. User has to explicitly code for copy of variable in sub-process. Brad: If they exist why do you need to copy? Neil: This is related to Dave Rich's index example. Arturo: It is not enough to make sure that variables do not go away. You must make sure that the value is correct in the spawned process. In looping fork/join_none example each variable would not get their copy, share the same variable. Neil: You could have that problem. Arturo: In Vera you never see this. Dave Rich's example will work the same in Vera with either shadow or non-shadow. Mike: Is this the only place you can see the difference between copying or not? I thought that you needed to call a method. Arturo: Yes. Since the parent process does not block with join_none or join_any. Dave Rich's example with/without shadwoing you get same result. Ray: Currently no need to make copy of automatic variable. Arturo: Since parent process does fork/join, scope of variable is shared, by copying there is no sharing. Neil: By default it should be the same as V2k. Arturo: Cannot replicate the condition with V2k. Ray: Is this one copy per thread or one for all threads. Arturo: Could make for all cases and would not see a problem with this example. Ray: Can create example where you see it. Jay: Solution where we explicitely specify the copy would be good. I have to disagree with Neil on the lifetime issue. Keeping track of lifetime of variable is non-trivial. Arturo: You can wrap the variable in a class and deal with it just like other automatic variables. Garbage collection mechaninsm will take care of it. David: Desire to keep consistency between fork/join_none and _any also approaches to the solution. Trade-offs between solutions. Jay: Yes, you could keep track of scope etc... You would have to add code to protect it. Arturo: You could use garbage collection mechanism deal with it. Jay: Yes. You have to check everytime. Arturo: Only if you implement it this way. It removes the performance problem. Jay: Should you be able to access an automatic variable after the scope goes away? The answer should be no. Raise an error or statically determine it Arturo: How do you detect this? It would be a performance problem. Jay: V2k does not allow access to automatic variables in fork..join. Arturo: But v2k does not disallow it. The reason to use automatic variables is because the task is re-entrant. This is not a corner case. This is the normal mechanism. Jay: Life-time of automatic variables should be illegal to access. Arturo: You cannot detect it statically, this is usually how cshell, heap in unix works. Jay: We need a copy mechansim, but not change the automatic variables. David: good philosophical point, however we introduced new thread creation. Jay: Make a copy of it, with the yet to be done copy method. Arturo: If re-entrant task, passing arguements will allow. Ray: Case where sharing a variable that need. David: Problem with the parent process going away. Arutro: Hard to detect it. David: You have to explicitly declare it and copy it. Arturo: fork/join_none would be different from fork/join. Ray: Other than arg passing is there any other place you want to access it? Arturo: Task that forks checker threads, common, can do it with explicit synchronization. Ray: Flag in the parent process to make sure all sub-processes have all variables they need. Jay: Put a parameter list around fork, fork (a,b,c) ... copy these variables and available to sub-processes. Arturo: When you do not copy and fork, what is the result, illegal, or? Ray: Performance issue? does it become one? Jay: Number of cases is small, David: more concerned about how it can work in some implementation. Ray: Introducing a race condition, if it is done, you get inconsistency across implementation. David: Do we allow it or not, define a mechansim for copy. Also resolution to the life-time of automatic variables. We need to write-up the solution, as well as local copy syntax. Jay: It would be good to do it separately for each basis. Neil: Vera would do it consistenly for all sub-processes. Jay: Arguement list may work, and maybe reasonable. David: Need statement of what the three recommendations are. Neil: Will put it together the set of options. ERR-5: Add explanation that built-in classes can be redefined and to distinguish from built-in types in 13.1. Arturo: Delay until we review proposals on namespaces. Related to built-in class anonymous namespace. Jay: The discussion in separate compilation seems different. Arturo: Agreed. David: We will wait until we go through the other proposals. 5. Review of Extensions: EXT-5: Optional order of lifetime, datatype, and sign Arturo: I thought the issue was with respect to classes in which case there are a number of modifiers. With non-class the only issue is for sign. Would prefer to leave it as is. Jay: I agree on the topic. Dave Rich might disagree. Arturo: Talked with Peter and he agrees. Dave was in the discussion were it was tabled. Motion: Move that it remains as defined and close extension. Moved: Arturo Second: Jay Abstain: None Against: None Passed EXT-8: RandCase Ray: 32 bit restriction was due to expectation that the numbers would be small. The issue was more with expressions than with constants. Arturo: Ray suggested that negative number counts as a negative weight. Brad: I thought it was illegal. Ray: Cannot detect as a compilation error (since it is a variable). Arturo: My thought was that there was an implicit cast (so negative becomes positive number). David: Is it a run-time error (if we make it an error) since it cannot be detected as a compilation error? Jay: This is the category of this is an error and we will do something screwey with it. Arturo: Agreed. That is why 0 is just as screwey. So, if issue as an error then what happens? Terminate, make an error, or make a large number? Jay: Implementation dependent. Ray: Some rational for making it become 0 since it is likely this was due to reduction of probability. It would be useful to make it a value and not generate an error. David: for random generation what does portability mean? Ray: Second thread was on stability. One of the features was convenience. The other issue was ordering and how the random number is generated. Arturo: Did you see my other email? David: Stability is primary concern, the second, repeatability across multiple implementation/application. Arturo: Explicitly want thread stable. Then specify the order of evaluation. David: What conclusion? Ray: How important is repeatability? Arturo: It is important to have stability so that interaction between processes within a single vendor is important. Neil: It is usually important. With probability not sure as important. Ray: There are two parts. The randomness and the case evaluation. The order of evaluation could be specified. Arturo: And how many times is it evaluated. Ray: You mean it may be evaluated more than once? Arturo: Yes. The coding for the example shows caching. Appropriate to specify each evaluated once in the order they appear. Arturo: Need to add that: Each weight expression should be self-determined in terms of position. The sum of the weights should be calculated using standard verilog semantics (maximum precision of all weights). Ray: So there cannot be overflow? Arturo: No different than standard Verilog. Ray: Each of the weights are evaluated as an unsigned number and the sum is an unsigned sum. Arturo: Self-determined expression then cast to unsigned number. Neil - It would be useful to have this in the write-up. David: Let's the proposal out on email and then vote on it by next meeting. Jay - Not sure I like at all (the concept and not the issues). David: We can get the issues worked with, one of it was to show more complex example. David: The extension EXT-2,14, and 9 have been out for a few weeks. I want to open the discussion about the form/completeness/etc, vote to accept the proposals, and then have the technical discussions. EXT-2: Process Control David: Any discussions on Ext-2? Jay: No problem with this. Motion: Accept EXT-2 proposal. Move: Mike Burns Second: Arturo Abstain: None Against: None Passed EXT-14: Constraint completion Jay: Need to define the built-in global namespace (7.10.1) before it is used within this proposal. Move 7.10.1 and 8.5.3 to separate proposals. Arturo: Necessary for constraint, if we use them [foreach, ] it is usefull for general code. Ray: You could have them just for constraint only. Arturo: You could do them that way. The name-space because of randomize and how it is proposed, did not want to introduce new keyword. Jay: Built-in global name-space is trying to solve a fundamental problem. Mailbox, semaphore and the Errata, go through all other areas of 3.1. If this place exists, and what goes there? Arturo: $root is below it, name-space resides above it. Ray: The semantics is a little different between constraint vs procedural. Ray: Woul like to break 8.5.3 out since it does have some different issues. Agree that they should be the same. Proposal: Motion: Move 8.5.3 from EXT-14 to EXT-15 and handle separately but consistently with EXT14. Move: Jay Second: Neil Abstain: None Against: None Passed Propsal: Motion: Move 7.10.1 to proposal for ERR_5. Move: Jay Second: Neil Abstain: None Against: None Passed Proposal: Motion: Accept EXT-14 proposal as modified by previous two proposals. Move: David Smith Second: Arturo Abstain: None Against: None Passed EXT-9: Stream Generation David: any problems with proposal/self-consistency/form/ etc? Motion: Accept EXT-9 Move: Mehdi Second: Arturo Abstain: None Against: None Passed EXT-2: Technical discussion. David: Michael, does this meet the requirements? Michael: Yes. May need more work. David: Since it meets the requirements we now need to decide what additional work is required. Michael: Proposal as is meets the requirement but some more work needs to be done. The child thread has to start, use self function to pass its process object to parent. Issues with race condition, parent thread needs to wait till child starts up. Jay: This is the example that requires the copy of variable. Michael: The example demonstrates the problem we were discussing before. Neil: Except when spawning the process, j is one thing. Arturo: No automatic variable? Mike: All get the last value of J, Arturo: Only a looping construct that need the copy is required. using jay's pseudo example [fork(a,b..) ] may solve it. Ray: If fork off processes, how one knows about last process? David: Last process started .. Ray: Truely concurrent, may not have reached storing the value. Mike: The #0, how does it help? Arturo: Wait for job n to start, race condition is that job 1 may not exist. Mike: Can the parent get access to child? Arturo: Can have fork and processes in the loop, explicit. Dave: Instead of fixed size array for jobs, can we have dynamic or variable array, and then use array.size to find if they have all been created? Mike: Does it check every simulator cycle? Arturo: The wait would be sensitive to size (and therefore delete/add). Jay: Is this defined where we can put method call inside of wait? VHDL/primary erratta for sensitivity of object. Dave: It would be good to add this description. David: Are there any more issues with this proposal besides cleaning up the example? Arturo: Only other issue, from Michael, was to query all of the process objects. Michael: This proposal does not prevent that in the future. Jay: Would this leave in the anonymous namespace? Arturo: Not any different than for mailbox or semaphores. Jay: Do we want to use this as a keyword or call it by a different name since process was reserved for future use.? Ray: If placed in names-space, it does not have to be reserved/keyword. Arturo: If this lives in the namespace then it does not conflict with a keyword. David: This has the same issues as other built-in classes. Ray: Do you have other built-in classes that are also keywords? Arturo: No. There may be ambiguity. David: Looking in appendix B, it is not there as a keyword in 3.1. Cliff: It was removed from 3.1, was in 3.0. Arturo: Note in page 46? SV3.1 deprecated it so it was removed. David: Rework example, no other changes suggested. 6. Next meeting: 15 September 2003 at 11:00pm 7. Close of meeting at 1:04pm