Minutes of the 10/14/02 SV-BC Meeting. This is my list of attendees and voting status - please submit corrections: (a--------) Johny Srouji (Intel) (aaa-aaaaa) Cliff Cummings (Sunburst Design) * (aaaaaaaaa) David Smith (Synopsys) * (----aa--a) Heath Chambers (HMC) (aaaaaaaaa) Karen Pieper (Synopsys) * (aaaaaaa-a) Kevin Cameron (NSC) * (----aa---) Medi Mohtashemi (Synopsys) (----aa---) Paul Graham (Cadence) (----aaaaa) Peter Flake (Co-Design) (----aaaa-) Simon Davidmann (Co-Design) (---aaaaaa) Stefen Boyd (Boyd Technology) (aaaaaaa-a) Steven Sharp (Cadence) * (-----aaa-) Dave Kelf (Co-Design) (aaaa-aaa-) Dennis Brophy (Model Technology) * (-aa--aa--) Mike McNamara (Verisity) (-a---aaaa) Tom Fitzpatrick (Co-Design) * (------aaa) Vasisilios Gerousis (Seimens) (a-a----aa) Francoise Martinolle (Cadence) (a-------a) Don Mills (LCDM Engineering) (aaaa----a) Gord Vreugdenhil (Synopsys) (aaaa-----) Brad Pierce (Synopsys) * indicates eligible to vote on consensus issues Minutes from the 10/14 Meeting (can be found at http://www.eda.org/sv-bc). Steven moves that we approve the minutes. Gord seconds. No opposed. No abstains. Passes. Action Items: Karen has organized a meeting for 11/15 for SV-BC face to face. We will discuss interfaces and any other issues where we need to ask for information on Co-Design's implementation. Steven needs to drive the creation of the document with the arguments for deleting the "static" keyword. He will work with Gord on the document. The document was mailled 10/14/02 at 21:05. Steven moves we take the document to Vassilios. Gord seconds. No opposed. Kevin and Don abstain. Passes. Steven will check with Stuart Swan on the 11/15 meeting. Stuart is planning on being there. Steven will consider the synthesis impacts of automatic variables at the named block level. Automatic and static tasks are equivalent for the Cadence implementation. Gord will query the VCS team on the impacts of SV-BC18c. Issues: SV-BC18b: Automatic declarations at the module level and initial block level. The agreement is that automatic declarations do not make sense in the module level, $root, or interfaces. We are unclear on named and unnamed blocks. Automatic variables cannot have hierarchical reference to them and that provides a reason to have them at the module level. Straw pole: Is hiding variables from hierarchical reference important? Gord: Yes, but not enough for automatics. Steve: Yes, but not enough for automatics. Cliff: Yes. David: Yes. Karen will add this issue to the issue list. Steven will champion the removal of automatic variables in places not covered by 2001. Gord agrees. Steven moves that we remove from SystemVerilog the declaration of individual variables as automatic in favor of the existing IEEE 2001 behavior of declaring only tasks and functions as automatic. Gord Seconds. Karen opposes because of the potential for synthesis variable locality. Cliff abstains; he is concerned about current Superlog users. Kevin abstains. Passes. This resolution addresses SV-BC18d as well. SV-BC18c: Variable initialization does not cause events. Gord went to the VCS team to see how people reacted. The discussion reflected the sv-bc discussion. Front-line support says please don't change anything. People who stepped back a little further could not see how to find a testcase that would obey SystemVerilog and violate 2001. Steven indicated that here was an initialization difference between XL and NC and no one noticed, so there isn't a strong argument that old code will be a problem. An issue remains with always block activation. Cliff believes initialization should behave as VHDL initialization does. Gord is in favor of leaving the SystemVerilog description alone. Steven moves that remove the last two paragraphs in section 5.4 to leave the initialization behavior it is in Verilog 2001. Cliff seconds. Gord, Cliff, David, Karen oppose. Don, Johny abstains. Kevin, Steven, Francoise votes for. Motion fails. SV-BC18d: Implicit initialization of large arrays and structs. Closed with Steven's agreement. SV-BC18e: Automatic variables cannot be used to trigger events. Steve indicated that the only way to achieve this given the pass for SV-BC18b is to have a fork/join waiting on an automatic variable. Steve is ok with leaving this language in the standard. Cliff is willing to delete this if someone wants to. Steve will not move anything on it, so we will close it. SV-BC18f: The logic type appears superfluous. It is needed to declare a 4-state bit vector in a struct. Cliff would like multiple drivers, but there are no strengths on them. What is the semantics of a struct (as a wire or reg?). Cliff would like to be able to have something be neither a reg nor a net, but instead either. He would like it to be able to have multiple drivers. Cliff will make a proposal to expand the functionality to multiple drivers for logic datatypes. Next meeting is in two weeks, on 11/11/02.