SV-EC Meeting Minutes 24 November 2003 11:00 am. Monday (rrrrrrrrrrxrxr) Voting Members (3/4 or > 75%) (aaaaaaaaaaaaaa) Arturo Salz (Synopsys) (-aaaaaaaaaaaa-) Brad Pierce (Synopsys) (--aaaa-aaa---a) Cliff Cummings (IEEE 1364) (aaaaa-aaaa-aaa) Dave Rich (Synopsys) (aaaaaaaaaaaaaa) David Smith (Synopsys) (-aaa-aaa-a-aap) Dennis Brophy (ModelTech) (aaaaapaaaaaa-a) Jay Lawrence (Cadence) (aaa-aaaaaaaaaa) Michael Burns (Motorola) (-aaaaaaaaaaaaa) Mehdi Mohtashemi (Synopsys) (aa-aaaaaaaaaaa) Neil Korpusik (Sun) (--aaaaaaaaaaaa) Ray Ryan (ModelTech) |||||||||||||_ 17 November ||||||||||||__ 11 November |||||||||||___ 3 November ||||||||||____ 27 Octobter |||||||||_____ 20 Octobter ||||||||______ 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) Doug Warmke (ModelTech) (-----s--------) Francoise Martinolle (Cadence) (--a-aaa-a-----) Jeff Freedman (ModelTech) (-----------a--) Peter Flake (---a----------) Stefen Boyd (IEEE 1364) (-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-45: David: Clean-up any SV-EC page with LRM change links. ERR-53: Arturo: Add BNF clarification on where a virtual interface declaration can occur. ERR-54: Arturo: Split 19.8.2 into Section 19.5.4 and 19.8.2. AI-46: Arturo: In EXT-7 remove the last sentence of second paragraph in 8.10.1 and in 17.15. Minutes 11/24/03 taken by Mehdi Mohtashemi 1. Review of the meeting minutes (5 Minutes) http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-November-11.txt http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-November-17.txt David: Folks did not have time to look at the minutes, now minutes from 11th and 17th, Neil: One comment on Nov 11.2003, one of the votes, Accept Errata 9, it should be Errata 19. [near the end of the minutes notes] David: Yes, I believe it should be Errata, 19. We will amend the minutes to show this. Motion: Accept Minutes of 11 November Moved: Ray Second: Neil Abstain: none Opposed: none Passes with above ammendment Motion: Accept Minutes of 17 November Moved: Michael Second: Neil Abstain: Jay - wasn't there Opposed: none Passes 2. Review of open Action Items (2 Minutes) AI-5 (Arturo/Cliff): Cliff Cummings email Cliff: In two weeks will have responce AI-18 (Unassigned): Waiting on built-in package proposal No action, waiting on built-in package proposal AI-39 (Unassigned): SV-AC assume and sequential constraints proposal There are some discussions, need to look at it after issues settle down in AC. 3. Review of Inter-committee dependencies (2 minutes) OCR-2: Discussion on inside proposal from SV-BC David: New one came out today, has anyone looked at it? Dave Rich sent out the new proposal, inside operator becoming more generic. Hold off on this till next week. Ray: Couple of items there that needs to be corrected. The BNF has braces missing in the first production. Dave: They are included in the open range production. Ray: Then it should not be included in the last production. Where is open_range defined? David: On the LRM changes 2, appendix A, it will bring up all the changes there. Arturo: Some of the links on the website does not work, some of the errata items does not work, points no-where. David: All the LRM links are different, that is the problem. OCR-3: Sequential constraints David: Next time 4. Review email vote and resolve (40 minutes) Errata: ERR-5 (Arturo): built-in package (10 minutes) David: Any comments or changes folks want? If not then I will ask for a motion. Motion: Accept ERR-5 (latest version) Moved: Doug Second: Michael Abstain: none Opposed: none Passes Extensions: EXT-3: Virtual interfaces (10 minutes) Jay: I guess I just do not understand it, all that is being done here is that we are creating a reference to an interface, and store it. Arturo: Yes, a reference is a way to implement this. Jay: So if that is the case, why are we restricting it to interfaces and not anything else. I prefer to see here is declration of ref interface so it is known that it is a reference to an interface, reference to an object, if we want to allow it for interfaces for now, that is fine, but in the future we want to extend it for other things, we can do it. The word virtual does not make sense. Michael: I agree. We seem to be overloading the term virtual in an inconsistent way. The use of virtual was used more for binding, not a data-type, the meaning of the word virtual is messed around with. Ray: I like the word ref better here. The way this is used in C++ is a reference. Arturo: We picked virtual since it seemed to cause less confusion. The issue is that an interface is not a datatype. By putting ref in front of a declaration you are turning it into a datatype. This seems irregular. This is called virtual port in Vera. Virtual converts a declaration to reference, and you can pass it as arguement. David: So there is a reason not to use ref, and a reason not to use virtual. The argument that this is not a data-type, Jay is making an arguement that virutal is not a regular argument. Jay: We are putting ref in front of something and getting a reference to something that is being instantiated. This is a reference to something that will exist. We are not declaring anything, only a pointer to this. Arturo: This is not really a pointer. If we were to use ref then this leads to wire, ref module which do not want to suppoort. It is confusing. Jay: Yes we do not want to confuse users. Ref may be the wrong word. We are using access in VHDL sense for our internal work. I would not mind virtual if we followed it by interface so that we could leave other options open. Arturo: We did consider that form, but because it is followed by an actual interface name it is not required. You can not just say reference to a generic interface. The name is required. Jay: If I say sbus ref, I do not know what type this is. Ray: To map this on things that I can understand. Interface is similar to a virtual class, a declared interface is an extended class, and with virtual you can reference it. Arturo: There is some parallel there, but not complete, it can have wire. Ray: Part of confusion here is that that an interface is almost as ao type, but not quite. Jay: If you draw a parallel to classes then yes. Arturo: The fact is that interfaces can also have tasks and functions, and initial blocks. Without that it would just an interconnect modeler. Jay: The other 'rat-hole' is whether interfaces contain wires. Can they be passed this way. I looked at pass by ref to functions, we do disallow passing wires by reference. I think we can have the same problem here if wires can be used here. Arturo: You can not unless you use a continuous assignment. Michael: Is the point here (Page 1 second to last paragraph) that this can only be used in a procedural context and is limited to what can be used here? Arturo: Yes, the limitation is that we are not going to create drivers dynamically, it was addressing that point, Michael: The first sentence I understand. The second sentence I understand. Maybe it is not so bad, discussion has clarified it for me. David: Two questions with the proposal: 1. the intent of what this proposal is doing, semantics; 2. what the syntax, usage of term virtual means. Are we getting clarity of what this thing does. Jay: I am ok with what this does (the semantics). Doug: I liked the syntax "virtual interface" so that future extensions can be done. I like the concept of actual indicating the interface. You would have to refer to the LRM to see that this refers to an interface (if you were new to the language). Arturo: We did discuss this internally. We thought about virtual interface. We could leave the interface optional. It is not ambiguous. Jay: It would be. Arturo: The type is not required since the identifier is sufficient to determine the type. Doug: It would allow for future extension. Arturo: You can do that now. Doug: I guess that I prefer the lengthiness. There are not going to be 100s of these. Jay: Why is this different than pass by ref? Arturo: When we first passed this by users the first thing they try to do is pass it through as a ref port. Then extend it to ref wires and ref modules. This is not what this is. This caused more confusion because the generalization is not correct. Doug: Having the ref wire seems to go where Cliff's and Karen's dicussion went. Arturo: This is different since they can change at run-time. Dave: This does not change the connection that a ref has it just changes procedural references. It should not change how sdf works. Doug: This is why we should not go the direction of using ref. Dave: The only place this is useful for a wire is for an array of wires and having procedural access to the index. Arturo: You can stick them in an interface now. Jay: You cannot identify the type by the identifier. You may not have seen it yet. Arturo: Only for interfaces or modules. Doug: This is better but I would prefer the explicit. Neil: Your objection is verbosity. It is not an issue of extensibility or confusion. Arturo: Correct. Ray: The interface identifier is sufficient to determine it is an interface. Arturo: Jay points out that interfaces are global and is correct. Michael: Can we do it so that if the identifier is not seen then we require the keyword and not otherwise. Arturo: It is informative, which is why we should not require. Ray: It was suggested that the interface keyword be required if the name is not known. That would give both the extendibility and clarity. Doug: This is not very Verilog like. Ray: I definitely like the interface there. David: After all these discussions does anyone what to push for ref instead of virtual. Ray: How about a straw poll on this? David: Ok, let's take a straw poll on using the inerface ter, Straw poll (for using the "virtual interface name"): For: Doug, Jay, Ray, Arturo (if optional) Against: Mehdi Abstain: Cliff, Michael, Neil, Dave Michael: I am not sure if this changes extesibliity. Jay: It makes the keyword interface for these. It might be an indentifer that has not seen. Arturo: Anything other type must be declared before use. Doug: I would still require it for clarification. Jay: For registeration we would do it for backward compabatitily, if we are designing something new lets not put it there. David: Compatiblity is not necessarily issue. Arturo: The user would say why do you make me write "virtual interface". It is already known. Michael: Addressing Jay's concern on identifier that has not be seen, Do we ask it to write it if it is not seen, adding another check, it may help for people who read the code. Jay: Are we always requiring the name to match exactly the name of an interface. Arutro: Correct, we do not allow generic interfaces. Ray: If the name is not known then you have to have the interface keyword. Doug: That is not like verilog-like. Jay: That refers to verilog that has scoping rules. David: Lets get closure on this, any definitive proposal on handling virtual interface. Arturo: I would make the motion to allow virtual interface identifier with the keyword interface optional. Ray: If the user uses virtual interface without keyword interface, we would not know. Jay: So in the future we wanted to make a virtual reg, then we had to declare it. Arturo: If you want to make it, it is a hierarchical reference. Motion: Allow "virtual interface identifier" with the keyword interface being optional. Moved: Arturo Second: Michael Discussion: Michael: This does not allow extensibility. Arturo: It does. Abstain: Cliff Opposed: Jay, Doug, Ray For: Arturo, Michael, Mehdi, Neil Vote: Personal: 5 for, 3 against, and 1 abstain. Motion passes. Company based: 3 companies for and 2 against. Motion passes. David: 9 eligible voters on the conference call. This is a technical change to a proposal. It is a personal and not company vote. Doug: It is big improvement, I am reasonably happy. Ray: Where can a virtual interface declaration occur? The first production in Syntax 19-2 (virtual_interface_declaration) is not used anywhere. Arturo: It can go anywhere function/task declaration is. Yes, it is not stated there. Let me go back to see which is the production. I can do that as an errata. David: Two things, one is the errata, the next is agreement on how it should be used. If we have an agreement and clarity on this usage, then we can put an errata on the BNF. Ray: Is it just any place that data-type is declared, you can declare it in a class, task, module and a function? Arturo: Yes. It can be used where you can have a variable declaration. David: Can you declare it in a package? Arturo: Good question. I do not think it should be since we cannot use hierarchical references. We do not allow interface declarations in the package. Ray: Since the interface identifier cannot be in the package then this is illegal. Arturo: Correct. Neil: Is this correct? So a virtual interface declaration in a class could not be used? Arturo: The question was if we can declare variable in package. Neil: If I declare a class in package, with interface in it? Michael: How does the symbol resolution work then? Arturo: Cannot. It would have to be postponed until elaboration. Packages are not post-elaboration. Jay: Yes, you can not use the thing inside the package at parse time. I think we should allow interface declaration inside package. If we disallow this, then disallow declaration inside class. Only virtual interfaces. Ray: But the virtual interface declaration requires a name [interface name]. If you do this, then the interface name must be hierarchical. Jay: Only at elaboration. Arturo: Yes, the interface names are that. You do the semantic check at elaboration. Ray: The interface name must be a hierarchical name. Arturo: Interface names are in the definitions name space. Ray: So the name is not in the package, it is a simple name, an it is not a hieararchical name. Should we have a an error on this if the name is not in the package? Arturo: It should be ok. It makes packages have a component which must be semantically checked at elaboration time. Jay: This is the same as modules. Ray: One of the features of having a virtual interface referring to a named interface means that this cannot be done until elaboration. Arturo: I think so when used in a package. The idea was that a generic interface can be different interfaces. This is one type only. David: So any proposed changes? Michael: in Sections 19.8.1 and 19.8.2, it appears that this is really part of interfaces and not virtual interfaces. The discussion seems to be more generic. Jay: I agree. This could be 1/3 the size. What is different between this and other places. Arturo: Most of the space is used by examples. Ray: Is there anything in 19.8.1 and 19.8.2 that is not just example? Arturo: No, I think it is informative. Michael: I was looking for new material. Arturo: 19.8.1 is informative. 19.8.2 is new. The ability to have clocking domains as part of interfaces. It should be 19.4.5 where modports are discussed. Michael: It needs to be touched up to talk about interfaces and not just virtual interfaces. Arturo: So I need to split it and keep some in Section 19.8. Michael: What about 19.8.1? Arturo: Leave it here. Motion: Approve EXT-3 with modification that 19.8.2 be split into 19.4.5 and brought back as an errata. Moved: Michael Second: Arturo Discussion: Jay: The contents of 19.8.2. This is a way to export the clocking domain with the modport. Arturo: Correct. Abstain: none Opposed: none For: Jay, Michael, Neil, Mehdi, Doug, Cliff Passes Doug: Going back to Errata-5, is there language that vendors do not add to it? Arturo: I am not sure that it is not allowed. David: Vendors can do what they want, but it is not standard. If the vendor adds to standard package, later someone else uses the same name and add it to standard, the vendor does not comply with standard. Jay: Adam was the first to bring this up, he was concerned about the attributes to the standard. Synopsys with the VHDL standard packages added attributes that it took a while to get standardized. Is it by language legal to add? David: Is that not a problem with attributes? Jay: We do not have attribute specification like VHDL. David: If someone wants to make a proposal please feel free. We need to move on to EXT-7. EXT-7: Reacting to Assertions (10 minutes) Jay: The changes in the latest are no better then the original wording. I think the whole sentence is unnecessary. The process resumes in whatever region it resumes in. The entire sentence in the second paragraph is unneeded. I would prefer to delete it. Arturo: Correct. I was trying to point out that the observe region is there. Can we remove the second sentence. Jay: That would be ok. Michael: We would have to change all the other event control if we kept this sentence. Jay: Same issue in 17.15. Neil: This is the same as before. Arturo: This is a slight change since the observe region can now trigger processing in any region. If you can wait for the completion of an assertion in a procedural statement then we can go back. We can have an assertion clocked by another assertion. Which means you go back to the observe region. An arrow feeding back to other regions. David: This is in Section 14.4. There is no change to the picture with this proposal (as ammended). Motion: Motion to approve EXT-7 with changes above. Moved: Arturo Second: Neil Abstain: IEEE (Cliff) Opposed: none Passes EXT-16: Event control for coverage (10 minutes) Jay: This will just be a religous discussion. I agree with Arturo's response on the reflector. I believe that there is a place where people will be sensitive to the event ordering and not understand it. If you trigger at the end point and copy out parameter values the copy out may not have happened. Arturo's response is that this is Verilog. Ray: The begin and end work a little different. Waiting for the end you will have finished the process. Jay: If you trigger the end and you are in the middle of copy out then it will not be correct. Ray: There are stuff that come from coding and some from LRM. Is this the later. Jay: Correct. Arturo: I proposed that we add in the LRM that if an event is triggered as the first or last statement of the procedure (which would be before the copy out). Jay: The output parameters would not be updated. Arturo: You cannot have it both ways. You either need to make this deterministic or live with it. Cliff: Anything I can do to make it deterministic. Arturo: The argument is that if you are using this as part of a design and you wish to trigger something on the activation of the task then you do not want ordering (this is hardware and things happen concurrently). For coverage in the testbench then the deterministic behavior is good. Ray: Where is this being introduced from? Arturo: To track in coverage. Ray: Is this stable from where this coming from? Jay: And, for example, in your coverage, do you bin before the task finishes? You might be using the data in the task. Michael: When I read it, rather than parameters passed to the task, you are trying to look for some result of the task. I would not expect the task to have done anything by the time calls are made. You might have seen some of the effects of task and not see some others. Jay: When you think it is triggered before start of task, it is not, and at the end of task, coverage block sensitive to the end of task, the values of the bins may not have gotten the updated values. Michael: Specific example does help here. Ray: What is the other behaviour, almost block the task? David: There is an errata to do this for coverage, Errata-52, it modifies one phrase in section 20.2 Jay: Oh that is bad. We have not voted for that errata. David: No, but there is an errata to get trrigering immediate, Arturo: Yes, one is the immediate, and the other is strobe. Jay: Are you imposing ordering, Arturo: Only for coverage, Jay: This is major impact, to the language and some of the ways that NC does things. Use one-step values, same as assertions use, we can have coverage do the same. Arturo: This is coverage. Here if you are triggering on a function call, happen to have called function multiple times, you may want to know the values. If you are using edge of clock, in essense you are getting the sampled values. David: From this extension-16, we either have inconsistent behaviour between simulation and HW. So the proposal that is.. Arturo: If you are covering the testbench, in the ractive region, only mechanism is mailbox, and race-prone. Jay: In this case go ahead use the event mechanism. Arturo: If you care about some modifications at the same time, function calls multiple time. Cliff: Neil what do you care about it? Neil: I do not care for non-determininsm that much. Cliff: I am kind of with Jay on this, Jay: If we approve this, there is an errata out there. With this people are triggering but not getting the right value. Arturo: How is it different from any other event? Neil: Because of the usage of begin/end, it should be right there. Arturo: The trigger is there. Cliff: That is why asking question from Neil, Jay is swaying me, but Neil can sway me back. Ray: I would like to talk about it next week. David: Arturo, does this exist in Vera? This behaviour? Is the predictability a problem? Arturo: Yes it does exist, no unpredictiblity. Doug: This has high value and there is another errata on this. Jay: Unlike some of the other things, scheduling semantics is core to this one, add them to this proposal. Arturo: I do not agree, all this says that there is an instrument for users to trigger at the beginning or end of tasks, I do not think we need to change scheuling semantics. David: If this is used in Vera, users have not had problems, what are we missing? Jay: Missing the fact that this is done in Vera, on very defined synchronization points. Arturo: This is not true. This was used in the testbench where things can be racey. Jay: If you put this in the middle of a Verilog description then the syncrhonization points are different. Cliff: Neil have you used it for coverage Tesbenches. Neil: Not too much. David: Two questions, the behaviour we want, and then how do we get the scheduling mechanisms. Looking at the actual proposal, not much about explicitly on scheduling semantics. Need to make a motion to do something with this. Do we want to have ability to instrument to deal with it. Jay: In the current form I do not think it is useful. David: The way it is written it does nothing to the scheduling semantics. The question is that, is this useful behaviour. Motion: Motion to approve EXT-16 as written Moved: Arturo Second: Cliff Abstain: none Opposed: Jay (Cadence), IEEE (Cliff), Neil (Sun) For: Michael (Michael), Mehdi (Synopsys), Doug (Mentor). David: Approval of extension is split, according to the Operating Guidelines I vote to break the tie. What I have not heard people say is that that they do not want the ability to trigger an event at the beginning or the end.. The capability is very good capability in coverage. The issue is when the execution of the action block associated with the event is executed and the data that can be used there. We need to get this resolved to get a consistent behaviour. ERR-52 was created to address this. So as a chair I am going to vote for it, there is a route to address the concern. Item to look at is to get agreement on scheduling semantics. Passes. (NOTE: After the meeting the Chair reviewed the operating guidelines and realized that, for company votes the TCC chair is the tie breaker. Based on this the vote is still a tie that will be resolved by Vassilios). David: I know we have pushing things, appreciate time folks are spending on this. It is not clear that we have all issues out. Next meeting on Monday, I would like to get comments before the meeting. We need to cover the bitstream extension (EXT_12) and ERR-52. Jay has sent out more comments on implication operators, ERR-44, scheduling for next week. So the priorities are: EXT-12 and ERR-52. 7. Meeting logistics (2 minutes) December 1 EXT-12: Bitstream support ERR-52 (Arturo): Events used within coverage are immediate ERR-4 (Arturo): automatics in fork/join_none ERR-45 (Dave): Wildcard equality ERR-50 (Arturo): Program visibility rules ERR-51 (Brad): Method calls and class parameter overrides December 8 Start LRM editorial review 8. Next Meeting Monday December 1, 2003, 12:00pm-2:00 pm PST 9. Meeting adjourned at: 12:57pm