SV-EC Meeting Minutes 15 December 2003 11:00 am. Monday (rrrrrrrrrrxrxrxrr) Voting Members (3/4 or > 75%) (aaaaaaaaaaaaaaaaa) Arturo Salz (Synopsys) (-aaaaaaaaaaaa-aaa) Brad Pierce (Synopsys) (--aaaa-aaa---a-aa) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaaaaa) Dave Rich (Synopsys) (aaaaaaaaaaaaaaaaa) David Smith (Synopsys) (-aaa-aaa-a-aap-p-) Dennis Brophy (ModelTech) (aaaaapaaaaaa-aaaa) Jay Lawrence (Cadence) (aaa-aaaaaaaaaaaaa) Michael Burns (Motorola) (-aaaaaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (aa-aaaaaaaaaaaaaa) Neil Korpusik (Sun) (--aaaaaaaaaaaaa--) Ray Ryan (ModelTech) ||||||||||||||||||_ 15 December ||||||||||||||||__ 8 December |||||||||||||||___ 1 December ||||||||||||||____ 24 November |||||||||||||_____ 17 November ||||||||||||______ 11 November |||||||||||_______ 3 November ||||||||||________ 27 October |||||||||_________ 20 October ||||||||__________ 13 October |||||||___________ 29 September ||||||____________ 15 September |||||_____________ 2 September ||||______________ 18 Aug |||_______________ 4 Aug ||________________ 21 July |_________________ 7 July Non-Voting Members (attendance based) (------a----------) Chris Spear (Synopsys) (-------------s-s-) Doug Warmke (ModelTech) (-----s-----------) Francoise Martinolle (Cadence) (--a-aaa-a--------) Jeff Freedman (ModelTech) (-----------a-----) Peter Flake (---------------a-) Ron Goodstein (First Shot Logic Simulation and Design) (---a-----------aa) Stefen Boyd (IEEE 1364) (-a---a----------a) Stu Sutherland (IEEE 1364) Guests (non-voting) (--a-a-a----------) Don Mills (LCDM Engineering) (-----a-----------) James Young (HP) (-a---------------) Kevin Cameron (National) r => Regular meeting x => Extra meeting (Presence counts for attendance, absence does not) a => Attended p => Attended by proxy s => Attended as proxy - => Missed Action Items: [identified with AI (#) in this text, # refers to AI number] Added this week (please see the site for existing action items): AI-53 (David): Extend annex B to include reserved package names and other reserved identifiers. AI-54 (Arturo): Update EXT-16 as voted on and send to David for LRM inclusion. Minutes 12/15/03 taken by Mehdi Mohtashemi 1. Review of the meeting minutes (5 Minutes) http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-December-8.txt Motion: Accept Minutes of 8 December Moved: Dave Second: Neil Abstain: None Opposed: None Passed David: Draft 2 is out, will be reviewing and place on the url site. 2. Review of open Action Items (2 Minutes) AI-39 (): Review SV-AC Assume proposal David: Any issues to be raised today. We will close this if none is raised. 3. Review of Inter-committee dependencies (10 minutes) All closed 4. Review Errata list (55 Minutes) Proposals: ERR-8 (Dave): Using event control with methods David: It is up on the web-page reflector. Sent out Friday Dec 12th. Dave: This is an errata, event control on either @ or wait on event when using a method or object handle. You can use an object as a handle. Only restricting on the result of expression to be singular value. Using method to access class members, then event expression evaluation after the method modifies the data member. If member is written to that could also cause expression to be evaluated. Similiar to a memory write, for example an element of memory being written. Jay: So you can write object.method and if method returns a value, you wake up. Dave: Yes, you can call the method and any write to that class causes expression to be re-evaluated. Expression has to be evaluated if it refers to the data member. Jay: Even objects that are not referenced, we have to evaluate the method. Dave: Yes, exactly like access to memory (write to it). Jay: May cause confusion, Dave: We are saying that expression could be evaluated, if you have written the method correctly, you will not get an event. Jay: If a function has side-effect, object outside the function got changed, we have to re-evaluate the function. Dave: If a function call, arguement is memory reference, Jay: I do not mind that, but if it is not those, any other element in the class, so not other things that might be referenced in the class. It may be correct in the text. Dave: We do specify object data members, text is sufficient. David: Any other questions. Neil: Couple of typos: third paragraph with section. You want to drop the handle, methods are part of the object not the handle. You can get rid of the handle. Arturo: You are differentiating between static method Michael: The methods do not belong to the handle, but object. Dave: I can remove the word. Neil: The example, packer instead of Packet. Further, p=q, and then @q, p is being updated. Arturo: Yes it is backward, it should q=p. Changes: In third paragraph remove handle from "object handle" In example change Packer to Packet In the last assignment in the example change "p = q" to "q = p" Motion: Accept EXT-8 as modified Moved: Dave Second: Neil Abstain: None Opposed: None Passed ERR-47 (Brad): Keywords as identifiers Brad: There are various examples that are not accepted by the BNF. This combines two kinds of task enables into a task enable statement. Rather than have void' as a special create a function_call_statement Adds the task_method_call and removed array_method_call In function_call_statement, added void' for function methods and system function calls. Also added function method call and system function call as statements. Added method_call_root to allow implicit class handles before the .. Call function_method_call and task_method_call and defined method_call as its own production (instead of an expression). This subumes the array_call_method and adds note for with clause. Removed . from implicit_class_handle to match style of rest of BNF. Add this.supper to implicit_class_handle Add implicit_class_handle for variable_lvalue (due to change in hierarchical variable identifier). David: Questions or issues? Neil: In the first part, array_call is removed. Is that in the updated LRM version? David: Yes. Motion: Accept EXT-47 Moved: Brad Second: Arturo Abstain: None Opposed: None Passed ERR-52 (Arturo): Events used within coverage are immediate Arturo: The wording was not explicit, this makes it explicit. Neil: Comment on the last sentence. I think you meant: Add one between only and sample in the last sentence. Cliff: This may not satisfy Jay's concern. Arturo: This clarifies the request from Michael. Michael: I think this clarifies the proposal better, but I do not think it addresses Jay's concern. Neil: I do not understand how this changes the scheduling. (Jay's arguement). Arturo: It does not change the scheduling algorithm. Cliff: I do not remember Jay saying that it changes the scheduling, does anyone remember Jay saying in the actual meeting this changes actual scheduling. David: This was in the minutes of Dec 8th, 2003 (minutes were read). Arturo: I believe Jay was talking about regular event control. This is not regular event control. Cliff: I have a feeling that this will pass over objections Jay, or I may or maynot have. Do we want to specify which regions. Arturo: No. Cliff: I thought postpone was for recording not sampling, observed or reactive was for sample. Arturo: I am reading the text of proposal. If you want to add 'in the postpone region' we can add. Cliff: You want to add sample, if we at least change 'at the end of time slot' to 'postpone region'. Cliff: Is this by company vote, like last time. David: Extension 15 was with a company vote, do not remember that Err-52 was company vote. Change: In last sentence change 'at the end of time slot' to 'postpone region' Motion: Accept ERR-52 with indicated change Moved: Arturo Second: Neil Abstain: None Opposed: None Passed ERR-56 (David): Fix all locations in LRM for built-in package to use std:: ERR-57 (David): Create appendix for std package David: Annex-C was added, defines the declration currently in the standard package. One email came on this, about list not included here. List is well-defined and it was not quite as fundamental as the other items. Any questions on either Err-56 or Err-57? Brad: I would like to make sure that in BNF std is syntaxed, either red or bold. Could you note this. David: Stu how are you handling this. Courier in text, std is name of standard package. Stu: Good quetions, we did not have this before, option is bold, new in draft 2. David: This is really not keyword, but a reserved package name. Stu: There is no specific rule, we can bold/courier other things that are not keywords. Brad: There is a precedence for this, $setup/$hold, not system function, not keywords, but are bold. Stu: In annex-B, reserved keywords, like to extend it to list other packages. David: I will have action item to extend annex-B to include reserved package name and other reserved packaged names. Stu: Only allowed two more keywords! Neil: First page comment spills over to the next page. David: We will make sure that does not spill over, lots of tabulation. Motion: Accept ERR-56 ERR-57 Moved: David Second: Arturo Abstain: None Opposed: None Passed ERR-58 (Arturo): State that constraints deal with 2-state values David: Any discussions? Motion: Accept ERR-58 Moved: Arturo Second: Mehdi Abstain: None Opposed: None Passed ERR-61 (Brad): Expect property statement David: Has SV-AC has approved expect related item? Brad: The change property item, item 17 passed, we can now do this. Two issues, BNF does not require a ; in action blocks, statement and null, this change makes the action block required, so ; is required. The second issue, the look and feel BNF says to take it out as non-terminal statement. Also change to property statement, you can get rid of property instance, it is redundant. In the () no longer property instance is not there, inherited from property_statement Motion: Accept ERR-61 Moved: Brad Second: Arturo Abstain: None Opposed: None Passed ERR-62 (Brad): New copy constructor not in grammar Brad: This is about the new keyword. Class constructors are not supported in BNF currently. Class constructor is now allowed. Dyanmic array initialization is allowed, with dynamic array new. You can have expressions, not just list of arguement, since we need to support shallow-copy. In dynamic array new, the change there says dynamic_array_identifier. Blocking assignment, class new and dynamic array new are not optional. Reference to annex-4, in 5.4 was not correct. All places where new was used in text or example. In text it should be bold, new is a keyword, always on the list. If it is a keyword you can not use it to overwrite it. Only as a class constructor, still a keyword. David: Keyword binding to a class method. Brad: Yes it is a keyword. David: Will update on the Draft 3, since Draft 2 is completed for review. Stu: It is not clear when it is a keyword. So new should always be marked as a keyword. The list is not quite correct for Draft 2. Motion: Accept ERR-62 Moved: Brad Second: Neil Abstain: None Opposed: None Passed ERR-63 (Dave): Add block variable to automatic default Dave: This is a simple change. Variables can also be made automatic in procedural blocks. This proposal moves the section to the place scope is discussed. And makes corrections to indicate that this is so. Jay: It is just allowing it not changing any definition? Dave: Yes. Also another clarification, last sentence, for-loop variable are also automatic, regardless of module-type, no way to change it. You cannot put a life-time in for-loop definition. Jay: Is it allowed to reference as an XMR? Dave: No. Motion: Accept ERR-63 Moved: Dave Second: Arturo Abstain: None Opposed: None Passed 5. Review 3.1a Extensions and discussion (50 minutes) Discuss and re-vote on EXT-16: Event control for coverage David: Jay were you and Arturo able to synchronize? Jay: No. Arturo: We left this as a coverage item only and not generalized control. This would limit it so that it does not get confused with coverage. Jay: This was were we were at. Arturo: Move this to the coverage section, move the BNF. David: Any specific wording. Arturo: We have to move it back to coverage section, remove this BNF, move it into function BNF. Jay: I do think we need to change it from a regular event control, otherwise users will think this will work just like an event control. Dave: Any suggestions Jay? Jay: No, I do not have any suggestion. Like a regular event control, will be confusing. Neil: Seems to have unique syntax, begin and end. Jay: Yes, but people want to use it in other places. David: Yes they will find out with compiler error, i understand the confusion you mention, but not know what to do about it. Jay: This is different sensitivity from before, we are creating this new immediate sensitivity. Arturo: We could just put a note that that is not allowed. Jay: If it is actually a different event control, then make it different from the regular one. Cliff: My concern is that are we rushing it in. Jay: Let me just make the proposal of @@ for this. David: What about that suggestion? Arturo: That is fine with me, David: We need to formulate a motion, if we need to vote on it. David: This is a company vote and Mentor is not present. Motion: Accept EXT-16, move into Section 20, and add BNF for clock_synchronization, use @@ instead of @ as part of the covergroup declaration (from EXT-16), and change the verbiage as appropriate. Moved: Arturo Second: Neil Abstain: None Missing: Mentor Opposed: Cliff (IEEE) Passed 6. Additional items: Michael Burns proposal (ERR-64) David: Michael you sent out an email about constraint ordering. Michael: There was confusion using the solve before causing the solver to fail. Additional clarification is required in the LRM to clarify. Jay: I tried to follow the debate. Is it that it is solved before or not? Michael: You are not solving before looking at the rest of the constraints. You construct the solution space first with regard to the solve before. Then use solve..before to decide which variables to solve first. The second change is to describe a slightly different ordering on function call arguments. This can cause an overconstrained solution. Arturo: I agree but have some comments on verbiage. In the first change I would like to simplify it by: Change: Replace the ", and so cannot introduce ...". with ", and so cannot cause the solver to fail." Arturo: It would be more 'change by sub-dividing the solution space'. Michael: You want to add something. Jay: I like the terminology, defining the ordering of solving variables within the solution space. Michael: The second change is just describing the function call. Jay: Ok, ignore what i said (driving 60mph...)! Michael: Even though the problem was not over-constrained, it would still fail the constraint-solving, it would it take it to the sub-space that has no solution. Arturo: I would just add some editorial there. David: So, change is: Instead of describing the solution can change the solution space... "can change the solution space" "subdivides the solution space thereby changing it. Since... this subdivision can cause the overall constraints to fail" Michael: This is fine to me. Changes: In first addition: Replace ", and so cannot introduce ...". with ", and so cannot cause the solver to fail." In second addition: Replace "can change the solution space, since constraints on higher-priority variables are solved without considering lower-priority constraints at all." with "subdivides the solution space thereby changing it. Since constraints on higher-priority variables are solved without considering lower-priority constraints at all this subdivision can cause the overall constraints to fail" Motion: Accept proposal with changes Moved: Michael Second: Arturo Abstain: None Opposed: None Passed Brad: array method names should not be keywords (ERR-65) Brad: Array method names, uniq instead of unique, and reduced, and xor reduced for array methods that are reduction. Neil: uniq gives you the unique enteries in the array. Stu: I like reduced better than reduction, do not like uniq. Cliff: I like reduced better reduction. Brad: Can we change reduction to reduced. Change: Change reduction to reduced in names in proposal. Motion: Accept proposal with ammendement to use reduce. Moved: Brad Second: Michael Abstain: None Opposed: None Passed Brad: optional () in subroutine call Brad: Thomas Kruser brought up, sub-routine call, dropping () from function call can be ambiguous. Whether name refers to register value, implicit register or recursive function call. My proposal, allow dropping (), except the function calls. Cliff: Have you passed this by the Intel folks? Brad: No, they are doing this as a statement. Cliff: They give names like step1, step2, step3, Brad: That makes sense, how about when it is not a statement. Jay: You can not wait inside a function. Brad: You can use the current value inside the function. Maybe there is no consensus. The proposal was just to not allow empty(), on the function calls. But Cliff raised the point that a function used as a statement, function with a void return value. Jay: When we allow dropping (), was questionable, given that we have allowed it then we let it live, Brad: I withdraw this. Cliff: Clocking and Scheduling changes (ERR-42) David: Cliff you are next on Agenda. Cliff: Finally got it in the email this morning. The main issue, sections 14 and 17. Clocking-domain be changed to clocking-block. I think I have found everywhere in the LRM. Sections 14-15 and 17. In 14.3, numbered items, fourth paragrah after that. In section 15.2 I added two examples. What is not clear, if we do not have the posedge, are we allowed to use negedge. Is this legal? Arturo: Yes. Cliff: Everyone agreed? Jay: Yes we agreed, might be crazy to do, but we can. Cliff: Arturo, did we say we need to change any wording just above the example. Arturo: We needed to change to 'as specific edge'. Cliff: Does that take care of beginning of the sentence, we will propose that we change opposite to specific. also add two examples, clear it up. In 15.3, 3 paragarphs after the figure. change, inputs with explicit #0 skew, and clocking with no-skew. Does that look right. Arturo: Yes, because no-skew defaults to 0. What happens if you put explicit #0 skew. Cliff: Does next paragraph clarify that. Should we add () in above. Arturo: You would add it above, ' explicit #0 skew, ...) Cliff: Is that true, #0 does not put in the active region? Arturo: Yes. Should the word 'clocking' be bold. David: Should the clocking be bold. Michael: About the program, is it bold Stu: I have tried to make it bold when we are refering to it. Cliff: In 15.12, Neil: This does not look right. Cliff: As long as #0, you are looking at the Arturo: As long as you do not use #0, values just before, if you use step, then just before the prepone region. Neil: If I do not specify #0, it is not a #0 skew. Cliff: Yes, wording needs to be exact. I may have put the next one without anyone approving it. Arturo: I think this is not right, you changed it to say ' in the postpone region' that is not true. I would leave it the way it was before. Cliff: I can take it off from this proposal. In 15.14, just before 15.14.1, NBA. The next one, is it right? Arturo: I think that is wrong, Cliff: I will remove it. Now in section 16.1, third item, changed the exectuion in reactive, to 'scheduling'. David: Should we put it in as it is? Cliff: On to the next items in the modifications. On 16.5.1, is that correct. Arturo: We call it observed-region. (change from observe-region) Cliff: Figure 14.1 it is called observed region. In 16.5. Is there any place where 'blocking-task' is defined? David: Is blockig-task used in 1364 at all. Cliff: No, we are thinking of blocking assignment. If we change to task that has blocking statement. Michael: Do we have to worry about task that may or maynot block? David: How do we define a blocking task. Stu: A task that does not execute in zero-simulation time. If it is waiting for event you have to block. Not for an event that has already occurred. Blocking statements are not defined anywhere. Cliff: I think it is at least in a BNF. Shall I kill that for now. Arturo: I like Stu's definition. Stu: I searched 1364-2001 c, blocking statement is not there. Cliff: So, task that does not execute in zero-simulation time. David: You have a few more that are typos. Cliff: %0t, if $time format would fail. Dave: 0t is not legal. Cliff: Bolean may need to be capitalized. David: We will get it straight for this. Brad: Why can we not make a cross reference, is this a different meaning of pure. David: I have no problem with getting the word 'pure'. Brad: The function should be automatic and pure. Dave: I do not know if we need any of this since we have defined function Cliff: Remove the whole sentence? Arturo: Change 'they do not need be automatic ..' to 'they should not be automatic.. Dave: I would remove the whole sentence. Cliff: OK. David: Rest of your changes are clocking-block changes. Dave: Where is %d or %0d is defined for $error. Cliff: I am not sure for %0d, Dave: %t does not require that $time format, there is default on that. Cliff: We will leave the t there. I will remove the 0, and keep the t. Motion: Accept proposal with above changes Moved: Cliff Second: Arturo Abstain: None Opposed: None Passed 7. Meeting logistics (2 minutes) Next meeting scheduled for 5 January 2003 from 11:00am until 1:00pm Start LRM editorial review Glossary Verification of all cross references Check all changes for consistency and correctness 8. Next Meeting Monday December 15, 2003, 11:00am-1:00 pm PST 9. Meeting adjourned at: 1:10pm