SV-EC Meeting Minutes 18 August 2003 11:00 am. Monday (rrrr) Voting Members (3/4 or > 75%) (aaaa) Arturo Salz (Synopsys) (-aaa) Brad Pierce (Synopsys) (aaaa) Dave Rich (Synopsys) (aaaa) David Smith (Synopsys) (-aaa) Dennis Brophy (ModelTech) (aaaa) Jay Lawrence (Cadence) (aaa-) Michael Burns (Motorola) (-aaa) Mehdi Mohtashemi (Synopsys) (aa-a) Neil Korpusik (Sun) ||||_ 18 Aug |||__ 4 Aug ||___ 21 July |____ 7 July Non-Voting Members (attendance based) (----) Chris Spear (Synopsys) (----) Francoise Martinolle (Cadence) (--a-) Jeff Freedman (ModelTech) (--aa) Ray Ryan (ModelTech) Guests (non-voting) (--aa) Cliff Cummings (IEEE 1364) (---a) Stefen Boyd (IEEE 1364) (-a--) Stu Sutherland (IEEE 1364) (-a--) Kevin Cameron (National) (--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-8: Arturo: Modify to change new handling to be an error. AI-9: David: Create errata item to add explanation that built-in classes can be redefined and to distinguish from built-in types in 13.1. AI-10: Arturo: Update/add description for 'kill'. Minutes 8/18/03 taken by Mehdi Mohtashemi 1. Review of meeting minutes from 4 August 2003 meeting Motion: Accept the minutes from 4 August 2003 meeting Moved: Dennis Second: Mehdi Abstain: Neil, since was not there Against: None Passed/Approved 2. Review of action items AI-5: Aruturo: Cliff has been busy, not yet completed. AI-6: David: Separate compilation, bc or other committee. Discussed in chairs' mtg, primarily a BC issue, needs BC to figure out the case. Jay: to send it to Karen's for information. AI-7: Brad: Comments for the BNF for randcase were sent to the reflector. 3. Review of Inter-committee dependencies 4. Review of Errata list: ERR-4: Arturo Arturo sent out the proposal to the reflector. 'life time of automatic variables and fork/join-none' Jay: Disagree with forking automatic variables. This opens a pandoras box. In what other context will this apply. not allowed to be referenced in heirarchical way. Dave: This is not limited to hierarchical reference. Arturo: Direct reference to the scope. what would need be done. Should this be a compiler error? So, since we have this, how do we deal with it? Jay: Just make it a warning (or error) that this is undefined. Automatic variable in a named block, in this case you get an extra copy of the variable. Dave: Need this to be able to pass arguments to forked processes, otherwise the same copy is given. This is a required feature. Need to be able to personalize processes. Could use a mailbox. Arturo: Why make simple things complicated? David: We need to define either the behavior or warning. Arturo: Warning is not appropriate. Jay: The value is being copied in? Why not pass it to the function in the fork. Arturo: This is to late since it is non-deterministic. Dave: The problem exists since you do not know when the thread starts executing and they will all get overwritten. Arturo: This is the implemented solution in Vera and Superlog. Dave Rich: This is a needed feature, need to use the looping variable. Complicated way with other things (mailbox) Arturo: Like a functional call to pass the arguement. How does it get the copy? Function is within the fork. Dave Rich: We have looked at it in superlog, not an easy way to do this, ...all get overwritten. Jay: Is it only the automatic variables that get copied? What about the non-automatic/regular static variable? Arturo: So far, due to the uncertain lifetime of the automatic variable. The context may not exist when access is being made, hard to detect, the issue does not exist with static variables. Dave: This was the way that process worked. Jay: Not a problem in process. Do not like lack of symmetry with rest of fork..join options. Arturo: In the simple case it is the same. For the shared variable case would be different. Dave: Could restrict to read-only. Arturo: Why complicate it? This is the expected behavior we found when dealing with customers. David: Need more time? or wrap up. Jay: sent it to Steve Sharp, to see if there is response. David: There are two issues, is there requirement to have this, then if it is required, to make the solution better if can be. Ray: Why is this limited to fork..join_none and any? Dave: These are the only cases where the lifetime is an issue, it outlives the sending. Ray: Is it not a separate problem? Dave Rich: The issue is the problem with the loop outside of the fork, Ray: Going out of scope in join/none. Dave Rich: The processes will continue, re-executing the fork, multiple times and all at the same time. Arturo: fork/join-none and any should use this. David: Will look at it again in the next meeting and finalize. 5. Review of Extensions: EXT-8: RandCase David: Discuss and wrap up today (if possible). Jay: This extension is unnecessary, it provides a shorthand, you can directly write the case statement with $random Arturo: True, but more involved, specially if expression. The example should really show it explicitly, David: BNF has it in, Ray: Although in constraint section, but it is executible statement. Nested randcase... Arturo: This results in lengthly expressions even for simple statement. ????: Nesting of randcase acts as a random instead of a set of constraints. Cliff: Jay, why do you not like it? Jay: It is just bloat since the language already has the ability to do this. Can just use $random%2. Arturo: Not as easy as that. Need to take into account weights. Can do the same with procedural code. A bit more work since the full probability must be calculated. It is a short hand. Ray: Can do this in function. Cliff: Can see where Jay is coming from, on the other hand E language makes a big deal. Stefen: Think it is cool that vendor's want to do this but not sure want to added it to the language. Jay: What is stability here? Do we have to define this in terms of $random (write the function) so we have stable behavior? Neil: This is a good point. It would be problem if it were not. Getting different results is always a big problem. David: Does any one else have any comments on this? Arturo: Motion to accept the randcase as written. Jay: Do we vote on this as written or handle the randcase vs caser or caserand? Arturo: Not thought about caserand. Brad: Nothing to match in paranthesis. Cliff: I like the option of caserand. Dave Rich: Or case_w for weighted. Cliff: In other langugages, you were not guaranteed to get the exact number. Arturo: This is more of constraint in the e language, soft distribution. Discussion on hard vs. soft constraints - Cliff, Arturo, Jay Jay: Executing it 8 times, you are not hitting the it. Arturo: The cyclic nature is randc. Jay: Do we need one more syntax to do what can be expressed, not hard to do in easy cases. Brad: You can use this to do easy random distributions. Ray: you can do it in a sub-function, each of possible, would have a case for it, sum-values of all parameters, to correspond. Cliff: I do not know at this point about, and about e, I will have to abstain on this. Jay: on the function usage, stability between implementaions here, repeatability ... constraint is harder. In this case users want stable behaviour in multiple vendors. Neil: This would be an issue if it is not stable by different implementation. getting different results between simulators is always a problem. Stefan: New random functions not standard? Arturo: The code is out there. Jay: Synopsys refused to document. David: Synopsys documented it. Jay: Different constraint solver does not guarantee reproducibility. David: All the vendors had a lack of desire to standardize the constraint solver. Jay: Yes, do we want repeatability in this case? Cliff: That favors the algorithm in the standard. Arturo: That is fine, but if you come up with a better random number generator, you can not use it in part. Stefan: do i want to add new and more random function that are not the same across multiple simulators. Arturo: But this is specified, will be the same. Neil: Where does it say, defined to random call, it is not in the writeup, it would be on any implementation, Arturo: Based on urandom, on the thread stability. Ray: Any chance users want to specify their own random function. Arturo: There is no mechansim that allows the users to get the their own random functions instead. David: Process checkpoint, first: need to review the syntax, style, review of the submission. After all of these, we can then to vote to accept the submission, then refining process starts. The questions on the acceptacne, keyword, sounds like refinement. I would like to do the vote on Acceptance. Motion: To accept this submission. Moved: Arturo Second: Dennis Abstain: None Against: None Passed for acceptance David: The issues: 1. Syntax ( where it is placed in the LRM) 2. Name (case_r,w,..) 3. Repeatability across vendors (is there clarification requiered) 4. Is it required at all? Brad: Mehdi, I take it that this would not have been donated unless users liked it. Mehdi: Users do like it. It is being used at the top layer to generate multiple scenarios as well as for networking. It has been used heavily in the Vera environment. Arturo: This should go in the procedural statement sections. David: We will go through the next three items to familirize everyone with this. EXT-2: Process Control Arturo: Fine-grain process control. Mike had requested. Reuses process as a built-in class. Introduces enumeration, state of process, queried by other process, plus a set of control functions (status, kill, wait, suspend, resume). This gives the standard control over processes. The static function self is used to get a process id and then pass it to other processes that are sharing. Each process owns its own key and can pass it for manipulation. David: How to get access to process id. Arturo: Each process owns its own access key, to pass it to others. Brad: Does the status function need to be automatic. If user defined then could overwrite state. This is not user defined. Arturo: Only catch is that users cannot create objects of this type but just access. Processes are created by initial block, fork join etc. Neil: In the description it says that new returns a handle to an existing object and not a new object. This seems strange. I do not understand why. New does not create an object, you are re-defining the behavior of new, Arturo: In the new function of class, like assinging self. it is returning a copy of handle to the current process. one: To allow forking the process. or simply disallowing calling 'new'. David: Question: in the forked process, access to self? global reference to the process, process::self. Arturo: Or declare variable type process. David: Self, object of type process three of them, outside of a thread, what does the new mean, getting object of process bound to the thread we are in. Only thing to do with object, is state variables. It is an enum, no data: how are the objects different? Arturo: Could be done with only an intermediate class, but it can outlive the process itself, and then cannot collect the references. David: To solve this then new acts different. Ray: Should make new invalid since you may want to define it to do something else later. Not having a new is not unusual in other languages. Neil: That is what i would like to see, get rid of 'new'. Ray: Not creating it looks like a class with no visible constructor. It is not that odd not to have new. It would be an error to try and use it. Arturo: It would be default constructor. It could be ok for the proposal. David: can you determine at compile time that this 'new' is error? Not a run time check, by elaboration time it can catch it. Ray: When it was caught not important, return an error, to make it more useful in the future. Neil: I agree with that as well. Arturo: Shall we change the verbage, to say it is an error. David: Then need to update: AI-8: Arturo: Update the write-up to include 'calling new result is an error' Jay: What is meant by a built-in class. Is it defined in a header like we did with list? Arturo: The list is parameterized and therefore needs the definition. What I meant was that this is a type that can be refdefined but is just included in the root. Jay: Is this the same as mailbox, semaphore, and process? The current LRM does not define the ability to redefine built-in classes. Arturo: Process is a keyword, you can redefine the mailbox as well. The intent was that built-in classes should be redefinable. David: mailbox is not a keyword, it is a built-in or pre-defined class. Jay: I do remember, that users can re-define their mailbox. David: LRM section 7-10, built-in methods, Arturo: Semaphore and mailbox defined as built-in classes. David: Built-in types are not documented so that you can redefine. Ray: With the process, you will not be able to extend it. Jay: With mailbox,semaphores, 13.1 (page 115 LRM) it says these are built-in type? Users can not redefine 'int'. Neil: The third paragraph, it says, can be used as base class to define higher level classes. Jay: This may be an erratta topic. Arturo: The intent was to allow re-defining these [built-in class], that is why it was not keyword. I do not believe we allow redefining built-in types. AI-9: David: Create errata item to add explanation that built-in classes can be redefined and to distinguish from built-in types. Neil: Enum has several different states. May need to have a distinction between normal completion and killed. Arturo: We did review this, we do not currently keep track of the process, makes it hard to distinguish between the two, it could be useful. Jay: Please do not make us keep track of this. It would cause a memory leak. Jay: Does this talk about reuse of ids? Arturo: This is why they are handles and not ids. Jay: Is there a requirement on uniqueness? Are you guaranteed that each time through you get a new one. Arturo: All references to existing process must go away before the handle can be reused. Jay: Use a static variable and set it to handle and then the fork ends. Can you reuse the handle in the static variable? Arturo: When the variable is reassigned then the handle can be reused but not before. Jay: Need to make sure that the user sees these as unique. David: If they are referrenced. Ray: May need a statement about the lifetime here. They need to be unique, specify, system can optimize to reuse the space, for the user' the concern is that they appear unique. Neil: It needs to be clarified. Arturo: So, we can add "objects of type process can be reused or destroyed when the process dies and are no references to the process". Neil: It appears that there is some ambiguity about when the process is killed. Is this correct? Arturo: Yes. This is a multi-threaded environment. They need to explicitly synchronize. from the process that issues the kill, it happens immediately, but there are other parallel processes happening. Ray: When does the kill happen? Arturo: From the process point of view immediately. For other concurrent threads (separate processors) it will happen at a synchronization event. Neil: The section on 'kill' does not go into detail. I would prefer to see more explanation, more like 'suspend'. Arturo: Is the wording of Suspend ok? Neil: Yes. It looks good. AI-10: Arturo: Update/add description for 'kill' in EXT-2. Arturo: should we create errata for 2001 disable statement? Cliff: Yes, lots of problem. lousy right now. Neil: The example uses array notation, 1 to N, for the process. Is this legal? Not able to find in the BNF. Arturo: Yes, on page 25 of 3.1. Neil: Is there a description of referencing an enum within a class? Arturo: Yes, see section 11.21 page 89, example bottom of page.. David: We will vote on accepatnce at the next meeting. EXT-14: Constraint completion EXT-9: Stream Generation David: The last two items require more time to get them started. Please review for next meeting and we will discuss them at that time. 6. Next meeting: David: The next meeting, september 1st, is not a good date due to the labor day vacation. We could reschedule it on Monday 25th Aug, Monday 8 Sept, or Tuesday 2 Sept. After discussion we decided to hold the next meeting on: Tuesday Sept. 2, 2003 from 11:00 am to 1:00 pm. 7. Close of meeting at 12:47pm.